0.205.0
2026-10-08- ChangedThe views no longer lean on the op log. The parent of an item, the weight of a thread link, the created and updated instants of an item and the order and date of a note are now kept in the folded rows themselves instead of being looked up in the log on every read, so the same views can be folded where no log is kept beside them. A message and a new thread now belong to the op that creates them: their id is minted from that op's own id, and another op claiming the same id never takes the message or the thread over, whatever its coordinate — where it used to be whichever op arrived first, so two replicas could show different messages under one id. For an id minted before this version, the claimant with the lowest coordinate is the message, and an op numbered below 1 is kept but never shown. The first time this version opens a workspace it rebuilds the board's and the chat's views once from the log; that also corrects messages an old build had recorded under the sender their payload claimed. An item's created and updated instants now count the ops this version folds; an op it keeps but cannot fold no longer moves them. The workspace schema goes to v8; older versions keep working on the same file — an item still shows one parent and a thread link one weight, and a parent or weight they set there takes effect when this version next opens the file — and that open rebuilds whatever they wrote. For embedding apps: a `Reducer` no longer folds into a connection — it returns the changes an op makes (`Reducer::changes`, built from `nxs_foundation::change`), and the substrate carries them out; a reducer declares `fold_revision` when its rules change. New: `Change::register_ranked`, `Store::emit_owned`, `Op::owns_target` and `ChatStore::open_new_thread`. `Image` gains `fold_revision` and `RefoldReason` gains `OtherRevision`.
- ChangedWhich tickets are ready, in progress, deferred or blocked — and how `next` tiers them — is now decided by one Rust library over the active tickets and their dependencies and parents (`nexus_flow_core::graph`). The board selects those tickets with SQL; a server can select them from its own index and get exactly the same lanes. One rule comes with it: a ticket that is not active — closed, archived or deleted — counts as closed wherever another ticket depends on it or hangs under it. Four answers change, all in states only a merge of concurrent edits — or an edge that arrives before its parent — produces: a dependency on an archived ticket that was opened again no longer blocks; an open ticket whose only parent was deleted, or whose parent no ticket has been seen for, rests as it would under a closed parent (`nxf search` files it under closed, and `nxf show` names the parent as the reason); and a dependency cycle that runs through a closed ticket no longer blocks anything. `nxf blocked` lists only active blockers, and the "blocks N" count in `nxs prime` counts only active dependents.
- AddedA server can now fold a stream itself, with the same rules as a local replica: the new `nxs-fold-ddb` crate carries the board's, the chat's and the memory's described changes out as conditional writes against one DynamoDB table, keeps two sparse indexes beside the rows — `active` (the active tickets and the dependencies and parents that touch one) and `dated` (the closed and the archived lanes, newest first) — and reads next, blocked and deferred through the same `nexus_flow_core::graph` library a local board uses, with one Query and no Scan. The order ops arrive in and ops delivered twice do not change the result, and a run that stops half way and folds its batch again ends where an unbroken run ends. An op too large for DynamoDB's limits is refused and reported instead of stopping the fold. A snapshot for starting such a fold is the tables plus the relay position they reach, without the log; one can be taken from a server stream or from a local replica's views. The table it expects is written down in the crate and in the sync spec. The DynamoDB adapter is behind the crate's `dynamodb` feature, so a build without it needs no AWS SDK. For embedding apps: `nxs_foundation::reducer::folder_for` is the one rule for which reducer folds an op, and `nexus_flow_core::model::is_active` the active rule over three cells. Finding dependency cycles now takes time linear in the board.