0.205.0
2026-10-08- GeändertDie Ansichten stützen sich nicht mehr auf das Op-Log. Das Elternteil eines Tickets, das Gewicht einer Faden-Verknüpfung, der Erstellungs- und Änderungszeitpunkt eines Tickets sowie Reihenfolge und Datum einer Notiz stehen jetzt in den gefalteten Zeilen selbst, statt bei jedem Lesen im Log nachgeschlagen zu werden. So lassen sich dieselben Ansichten auch dort falten, wo kein Log danebenliegt. Eine Nachricht und ein neuer Faden gehören jetzt der Op, die sie anlegt: Ihre ID wird aus der ID dieser Op geprägt, und eine andere Op, die dieselbe ID beansprucht, übernimmt Nachricht oder Faden nie, gleich mit welcher Koordinate. Bisher gewann die zuerst angekommene Op, sodass zwei Replikate unter einer ID verschiedene Nachrichten zeigen konnten. Für eine vor dieser Version geprägte ID ist die Op mit der kleinsten Koordinate die Nachricht, und eine Op mit einer Nummer unter 1 wird aufbewahrt, aber nie angezeigt. Beim ersten Öffnen eines Workspaces baut diese Version die Ansichten von Board und Chat einmal aus dem Log neu auf; dabei werden auch Nachrichten berichtigt, die ein alter Build unter dem in ihrer Nutzlast behaupteten Absender abgelegt hatte. Erstellungs- und Änderungszeitpunkt eines Tickets zählen jetzt die Ops, die diese Version faltet; eine Op, die sie aufbewahrt, aber nicht falten kann, verschiebt sie nicht mehr. Das Workspace-Schema geht auf v8; ältere Versionen arbeiten auf derselben Datei weiter — ein Ticket zeigt weiter ein Elternteil und eine Faden-Verknüpfung ein Gewicht, und ein Elternteil oder Gewicht, das sie dort setzen, wirkt, sobald diese Version die Datei das nächste Mal öffnet —, und dieses Öffnen baut neu auf, was sie geschrieben haben. Für einbettende Apps: Ein `Reducer` faltet nicht mehr selbst in eine Verbindung, sondern gibt die Änderungen zurück, die eine Op bewirkt (`Reducer::changes`, gebaut aus `nxs_foundation::change`); das Substrat setzt sie um. Ändern sich seine Regeln, erhöht ein Reducer `fold_revision`. Neu: `Change::register_ranked`, `Store::emit_owned`, `Op::owns_target` und `ChatStore::open_new_thread`. `Image` bekommt `fold_revision`, `RefoldReason` bekommt `OtherRevision`.
- GeändertWelche Tickets bereit, in Arbeit, zurückgestellt oder blockiert sind — und wie `next` sie in Stufen ordnet —, entscheidet jetzt eine Rust-Bibliothek über die aktiven Tickets mit ihren Abhängigkeiten und Elternteilen (`nexus_flow_core::graph`). Das Board wählt diese Tickets per SQL aus; ein Server kann sie aus seinem eigenen Index auswählen und bekommt genau dieselben Spalten. Dazu gehört eine Regel: Ein Ticket, das nicht aktiv ist — geschlossen, archiviert oder gelöscht —, gilt überall als geschlossen, wo ein anderes von ihm abhängt oder unter ihm hängt. Vier Antworten ändern sich, alle in Zuständen, die nur das Zusammenführen nebenläufiger Änderungen erzeugt: Eine Abhängigkeit von einem archivierten, wieder geöffneten Ticket blockiert nicht mehr; ein offenes Ticket, dessen einziges Elternteil gelöscht wurde, ruht wie unter einem geschlossenen Elternteil; und ein Abhängigkeitszyklus über ein geschlossenes Ticket blockiert nichts mehr. Ebenso ruht ein offenes Ticket, dessen Elternteil noch nie als Ticket gesehen wurde (eine Kante, die vor ihrem Elternteil ankommt); `nxf search` ordnet ein ruhendes Ticket unter „geschlossen“ ein, und `nxf show` nennt das Elternteil als Grund. `nxf blocked` nennt nur noch aktive Blocker, und die Zahl „blockiert N“ in `nxs prime` zählt nur noch aktive abhängige Tickets.
- HinzugefügtEin Server kann einen Strom jetzt selbst falten, nach denselben Regeln wie ein lokales Replikat: Die neue Crate `nxs-fold-ddb` setzt die beschriebenen Änderungen von Board, Chat und Memory als bedingte Schreibvorgänge in einer DynamoDB-Tabelle um. Neben den Zeilen pflegt sie zwei dünn besetzte Indizes: `active` (die aktiven Tickets und die Abhängigkeiten und Elternteile, die eines berühren) und `dated` (die Spalten geschlossen und archiviert, neueste zuerst). Bereit, blockiert und zurückgestellt liest sie über dieselbe Bibliothek `nexus_flow_core::graph`, die ein lokales Board nutzt — mit einer Query und ohne Scan. Weder die Reihenfolge, in der Ops ankommen, noch doppelt gelieferte Ops ändern das Ergebnis, und ein Lauf, der mittendrin abbricht und seinen Stapel erneut faltet, endet dort, wo ein ununterbrochener endet. Eine Op, die die Grenzen von DynamoDB sprengt, wird abgelehnt und gemeldet, statt das Falten anzuhalten. Ein Schnappschuss zum Anlaufen eines solchen Faltens besteht aus den Tabellen und der Relay-Position, die sie erreichen, ohne das Log; er lässt sich aus einem Server-Strom oder aus den Ansichten eines lokalen Replikats ziehen. Die erwartete Tabelle ist in der Crate und in der Sync-Spezifikation festgehalten. Der DynamoDB-Adapter steckt hinter dem Feature `dynamodb` der Crate; ein Build ohne braucht kein AWS-SDK. Für einbettende Apps: `nxs_foundation::reducer::folder_for` ist die eine Regel, welcher Reducer eine Op faltet, und `nexus_flow_core::model::is_active` die Aktivitätsregel über drei Zellen. Zyklen in Abhängigkeiten zu finden dauert jetzt linear in der Größe des Boards.