Ein verlässliches Gedächtnis für jeden KI-Assistenten.

Neu

• Weitere --json-Reads führen jetzt dieselben additiven Felder wie die Hauptreads — für verbübergreifende Agenten-Konsistenz: blocked und search erhalten priority_label/type_label, der verschachtelte parent-Join von next erhält type_label, und blocked/deferred/closed/ archived sowie prime führen jetzt die sparse Plugin-custom-Feldkarte (identisch zu list/next/show). Kanonische Felder bleiben unverändert; alle Ergänzungen sind additiv und erscheinen nur dort, wo sie zutreffen.

Geändert

• nxs mcp serve ohne --workspace/--db legt sein automatisch initialisiertes Board jetzt an einem neutralen, nxs-eigenen Ort ab (com.nxsflow.nxs unter dem Plattform-Datenverzeichnis) statt im Datenverzeichnis einer bestimmten Consumer-App. Der OSS-Server nimmt keinen Consumer mehr an; ein Consumer mit eigenem Board richtet seinen eigenen --workspace-gepinnten MCP-Eintrag ein (und kann dieses Board importieren). Wer sich auf den bisherigen Standardort verlassen hat, verweist den Eintrag per --workspace explizit darauf.

Neu

• nxf show, list und next --json liefern jetzt zusätzlich die additiven Felder priority_label und type_label — die Anzeige-Labels des aktiven Plugins (z. B. P2, epic) — neben den kanonischen Keys priority/type, sodass ein Agent für die Anzeige keinen separaten schema-Lookup mehr braucht. create und update akzeptieren jetzt zusätzlich zum Label (P2) auch den kanonischen Ordinal-Key der Priorität (z. B. 2), sodass ein aus --json gelesener Wert als gültige Eingabe zurückläuft. Die kanonischen Keys priority/type, die Human-Ausgabe (ohne --json) und der Embedding-/MCP-Record bleiben unverändert.

Geändert

• Die Fehlermeldung „no embedded minisign public key" von nxs self-update und nxf verify-signature ist jetzt handlungsleitend: Sie erklärt, dass das Binary unsigniert ist (ein lokal gebauter oder Entwicklungs-Build), und verweist auf die offizielle signierte Release-Installation (curl -fsSL https://nxf.nxsflow.com/install.sh | sh) statt auf ein internes Spec-Dokument, das mit dem Binary gar nicht ausgeliefert wird. Die fail-closed-Verweigerung selbst bleibt unverändert.

Behoben

• Wird CLI-Ausgabe in einen Reader gepiped, der früh schließt (nxf blocked | head, nxf list | grep -m1 …), bricht das nicht mehr mit „failed printing to stdout: Broken pipe" ab. Der Prozess endet jetzt still per SIGPIPE wie jeder andere Unix-Filter — Agenten-Skripte, die Ausgabe kürzen oder blättern, bleiben sauber.

Neu

• Plugins können jetzt eigene Feldtypen zusätzlich zu den 16 eingebauten Feldern deklarieren. Ein Plugin gibt sie in einer [fields]-Tabelle an (je mit Typ — text/longtext/date/enum — optionalem on-Typ-Geltungsbereich, required und einem Anzeige-label); gesetzt werden sie mit nxf create/nxf update --set <name>=<wert> (typgeprüft; ein leerer Wert löscht). Sie erscheinen überall dort, wo gelesen wird: nxf schema --json listet jedes deklarierte Feld auf (mit custom markiert, samt kind/on/required/label und values bei einem Enum), und nxf show/list/next --json hängen eine schlanke custom-Map mit den gesetzten Werten an (ein nicht gesetztes Feld — oder eines aus einem anderen Plugin — wird schlicht weggelassen). Die MCP-Tools flow_schema/flow_show/flow_list/flow_next liefern dieselbe Struktur. Die menschenlesbare Ansicht von nxf show zeigt deklarierte Felder ebenfalls unter ihrem Label. Damit entfällt das Zweckentfremden von labels/description für Fachdaten (die uri einer Datei, die email einer Person, die stage eines Projekts).

Behoben

• Nachbesserungen zu Plugin-Custom-Fields (Review nach v0.25.0): nxf create --json - akzeptiert Custom-Felder jetzt über ein set-Array in der JSON-Payload (analog zum --set-Flag) — damit lässt sich auch ein Item, dessen Typ ein Pflicht-Custom-Feld hat, aus einer JSON-Payload erzeugen; zuvor ließ dieser Pfad Custom-Felder still fallen. Die Fehlermeldung „Custom-Feld gilt nicht für diesen Typ" nennt jetzt zusätzlich die Typen, für die das Feld gilt, sodass ein Agent sich ohne schema-Abfrage selbst korrigieren kann.

Behoben

• Das gleichzeitige Öffnen einer frisch erstellten Workspace-Datenbank durch zwei Verbindungen — z. B. nxs init / nxf init über einem bestehenden Workspace (oder ein E4-Sync-Reset), während eine laufende App sie beobachtet — schlägt nicht mehr sporadisch mit „duplicate column name: domain" fehl. Die Schema-Migration läuft jetzt unter einem Schreib-Lock, sodass gleichzeitige Öffner serialisiert werden, statt beide dasselbe ALTER auszuführen.
• Der Vorschlag „your first move" nach nxs init / nxf init nennt jetzt einen Typ, den das aktive Plugin tatsächlich deklariert (z. B. epic bei issue-tracker, project bei personal-todo) — der kopierte erste Befehl funktioniert also. Zuvor war --type task fest verdrahtet, das kein mitgeliefertes Plugin kennt: Der allererste vorgeschlagene Befehl schlug auf einer frischen Installation fehl.
• Die Bereit-Lane (next) ist auf größeren Boards drastisch schneller. Das Auflösen der Bereit-Menge stellt nicht mehr eine Abfrage pro Item (die je die Parent-Projektion neu materialisierte und die Lane O(n·edges) machte), sondern löst in einer einzigen Abfrage auf. Auf einem ~156-Item-Board sinkt read::next damit von ~0,7 s auf deutlich unter 100 ms — das beschleunigt jeden Board-Refresh und Session-Start (nxf next, nxs prime).

Neu

• Einen Bulk-Labels-Lesepfad zur Embedding-API hinzugefügt — Engine::labels_bulk(ids) (sowie read::labels_bulk, Store::labels_of_bulk) —, der die aktiven Labels vieler Items in EINER indexgestützten Abfrage liefert statt eines labels(id)-Aufrufs pro Item. Das Dekorieren einer ganzen Lane (die App-Bridge-with_labels-Naht) kostet jetzt eine Abfrage statt N. Die Label-Projektion von list/next --json nutzt ihn intern, sodass diese Lane-Reads ihre Label-Lookups pro Zeile auf einen Bulk-Read zusammenfassen — bei bytegleicher Ausgabe. Das bestehende labels(id) bleibt unverändert; die neue Methode ist additiv und abwärtskompatibel.
• nexus-chat kapselt seine nxc-CLI/Onboarding-Oberfläche jetzt hinter einem standardmäßig aktiven cli-Cargo-Feature. Ein Embedding-Consumer, der nur nexus_chat::engine::Engine einbindet, kann mit default-features = false bauen und den gesamten CLI/TUI-Abhängigkeitsbaum — clap, nxs-ui (samt inquire/crossterm), nxs-init, inventory, sha2 — weglassen; es bleibt die engine/facade/store/model/watch-Oberfläche über dem gemeinsamen Substrat. Das nxs-Binary und nxc bleiben unverändert (das Feature ist standardmäßig an).

Behoben

• nxc inbox (und der Inbox-Abschnitt von nxc prime) zeigt ungelesene Nachrichten jetzt in deterministischer, kausaler Reihenfolge an. Nach dem Fix der Nachrichten-Ordnung war die Anzeige-Reihenfolge der Inbox selbst noch an die rohe ULID-message_id gebunden, sodass zwei in derselben Millisekunde gepostete ungelesene Nachrichten in beliebiger, pro-Datenbank unterschiedlicher Reihenfolge erscheinen konnten. Sie sortiert nun nach der CRDT-Uhr (lamport, site, message_id) — dieselbe Garantie wie Kanal-, Thread- und Suchlesungen — während der Ungelesen-Cursor seine eigene message_id-Wasserstandsmarke unverändert behält.
• Chat-Nachrichten werden jetzt in einer deterministischen, kausalen Reihenfolge gelesen. Die Reads (Kanalverlauf, Thread-Zusammenbau, Suche und das M2-Review-Board) sind nach der CRDT-Uhr (lamport, site, message_id) sortiert statt nach der rohen message_id. Eine message_id ist m-+ULID (ein Millisekunden-Zeitstempel plus Zufallsbits); zwei in derselben Millisekunde gepostete Nachrichten — ein ask-Opener und seine erste Antwort oder ein schneller Send/Reply-Burst — sortierten sich vorher nach ULID-Zufall, also in einer beliebigen, pro-Datenbank unterschiedlichen Reihenfolge. Lamport ist die logische Uhr des Substrats (die Op einer Antwort wird nach der beantworteten Anfrage emittiert), sodass die Lesereihenfolge jetzt stets der Post-Reihenfolge entspricht und über Läufe sowie Sites/Merges hinweg reproduzierbar ist.

Neu

• nexus-chat (`nxc`) ist jetzt über die Suite auffindbar und einrichtbar. nxc — Messaging zwischen Agenten — erscheint im nxs init-Auswahldialog und, sobald aktiv, im einzelnen SessionStart-Fan-out: nxs prime bringt einen Agenten zu Sitzungsbeginn auf den gesamten ungelesenen Posteingang (sowohl „jetzt handeln“ als auch „nächste Sitzung“). nxc init richtet Chat in einem Workspace ein und verdrahtet den einen nxs prime-Hook (ein bestehender flow-/memory- Workspace bekommt keinen zweiten Hook), und nxc agent-manifest legt Chats Sitzungskontrakt als Daten offen. Der Suite-Querverweis läuft jetzt in alle Richtungen — wer flow oder memory einrichtet, wird auf chat hingewiesen, und wer chat einrichtet, auf flow und memory. Koordiniere Agenten über nxc statt über Ad-hoc-Notizen.
• nexus-chat (`nxc`)-Nachrichten wandern jetzt über deine Maschinen hinweg. Mit dem abgeschlossenen M1-Messaging-Substrat erreicht eine Agent-zu-Agent-Nachricht aus einem Workspace nach nxs sync einen Agenten auf einer anderen Maschine — Nachrichten nutzen dieselbe offline-first-Synchronisation wie deine Aufgaben und dein dauerhaftes Gedächtnis, ganz ohne Zusatzdienst. Die drei Engines teilen sich einen .nxs/-Workspace und bleiben dabei völlig unabhängig: deine Projekte (flow) und dein Gedächtnis bleiben von Chat-Verkehr byte-für-byte unberührt, und jede Nachricht trägt eine global eindeutige id, sodass Agenten auf jeder Maschine dieselbe Referenz auf sie behalten.
• nexus-chat lässt sich jetzt in Apps einbetten. Eine neue In-Process-App-Facade (nexus_chat::engine::Engine) erlaubt einem Frontend, Channels, Inbox, Nachrichten und Threads zu lesen, zu senden/antworten/als-gelesen-zu-markieren und Änderungs-Benachrichtigungen über ein langlebiges Handle zu abonnieren — ohne nxc-Subprozess. Sie leitet identisch zur nxc-CLI ab und liefert dieselben Fehler/Rejections (abgesichert durch einen App↔CLI-Paritätstest); Channel-Abfragen liefern Unread-Zähler pro Channel in zwei Queries, unabhängig von der Anzahl der Channels.
• MCP-Hosts können jetzt die Item-Typen des aktiven Plugins und ihre Container-Rollen entdecken. Ein neues flow_schema-MCP-Tool nennt die gültigen Item-Typen, welche davon Container sind (samt der erlaubten Eltern je Typ, der Eltern-Kardinalität und der Hierarchie-Tiefengrenze) sowie das Create/Update-Feldmodell — damit ein Agent, der ein Board über MCP steuert, ohne Raten weiß, was er anlegen kann. nxf schema erhält dieselbe Information als additiven hierarchy-Block, und beide Flächen rendern jetzt aus einem gemeinsamen Record (facade::read::schema), sodass sie nicht auseinanderlaufen können.
• Sobald alle angefragten Reviewer geantwortet haben, wird der Thread-Ersteller geweckt: nxc inbox und der nxs prime-Catch-up zeigen einen "Threads you opened"-Block mit dem fertigen Board und seinen Antworten (und einen Hinweis, wenn ein Board seine Frist überschritten hat, aber noch wartet). Eigene gesendete Nachrichten erscheinen nicht mehr im eigenen Ungelesen-Stand.
• nxc ask öffnet ein Review-Board in einem Schritt — Anfrage posten, festlegen wer antworten muss, optionale Frist setzen. nxc threads list/show zeigen das Antwort-Quorum (wer geantwortet hat, wer noch aussteht, ob das Board vollständig ist), und nxc threads expect deklariert den Reviewer-Kreis neu, um ein auf einen Nicht-Antwortenden wartendes Board flottzumachen.
• Anwendungen, die nexus-chat einbetten, können das Antwort-Quorum jetzt über die In-Process-Engine lesen, nicht nur über die CLI: ein Bulk-Read liefert den Reviewer-Stand für eine ganze Menge von Boards auf einmal (für einen Koordinations-UI-Quorum-Balken, kein N+1), ein einzelnes Board vollständig, sowie die Fertig-/Überfällig-Weckliste des Anfragenden — alles identisch zu dem, was nxc meldet. Über den subscribe-Änderungsstrom kann die UI das Quorum neu lesen und "vollständig"/"überfällig"-Übergänge live anzeigen.

Geändert

• Große Boards werden deutlich schneller gelesen. next, list und show nutzen jetzt abdeckende Indizes für die Label-, Notiz- und Abhängigkeits-Lookups, die sie einmal pro Eintrag ausführen, statt bei jedem Aufruf die gesamte Projektionstabelle zu durchsuchen. Eine Board-Spalte mit 159 Einträgen, deren Aufbereitung zuvor ~2,0s dauerte, wird jetzt in ~0,6s aufgebaut, und der Gewinn wächst mit der Board-Größe. Wird beim nächsten Öffnen des Workspace automatisch angewendet — ohne Migrationsschritt.
• Verfeinerungen der nexus-chat-App-Facade. Channel-Abfragen sind jetzt tatsächlich fixe zwei SQLite-Queries, unabhängig von der Anzahl der Channels (die Mitglieder-Liste wurde von einer Pro-Channel-Schleife auf eine einzige Query zusammengefasst). Store-Lesezugriffe liefern Datenbankfehler nun als strukturierten io-Fehler, statt die eingebettete Engine abstürzen zu lassen. Und send/reply nehmen benannte Request-Structs (SendRequest/ReplyRequest) statt einer langen Positionsargument-Liste, sodass gleich-typisierte Argumente nicht mehr vertauscht werden können.

Behoben

• `nxs init` funktioniert jetzt für das Chat-Modul bei einer echten Installation. Der nxc-Persona-Symlink wurde von den Produktions-Installationspfaden (install.sh und nxs self-update) nie angelegt — nur von In-Tree-Dev-Builds — sodass eine frische Installation beim Einrichten von Chat mit „is nxc installed?" fehlschlug. Alle drei Personas (nxf, nxm, nxc) werden jetzt bei Installation und Self-Update verlinkt, und ein Regressionstest fixiert das vollständige Set, damit eine künftige Persona die Lücke nicht stillschweigend wiederholt.

Neu

• nxs prime und nxf guide vermitteln jetzt die Defer-vs-Warten-Konvention: Ein Item nur für ein echtes Kalenderdatum zurückstellen und das Warten auf eine externe Lieferung als offenes WAIT:-Chore modellieren, auf das deine Items zeigen (geschlossen mit der gelieferten Version, um die Kette zu entsperren). Das neue Guide-Thema nxf guide deferring-and-waiting führt mit einem durchgespielten Beispiel hindurch.

Behoben

• Der Einbettungs-Handle Engine der Facade stellt jetzt die User-Labels (h89s) bereit, die v0.16.0 nur für die CLI/MCP-/Migrationspfade verdrahtet hatte: label_add, label_remove, labels, einen with_label-Filter sowie label-tragende Reads show_value / list_value / next_value (Labels als sparses labels-Feld, wie im CLI/MCP-JSON). Der Prioritäts-Write-Kontrakt ist klargestellt und dokumentiert: create/update erwarten die Plugin-Bezeichnung (P0..P4) — die Form, die schema ausweist —, nicht die Lese-Ordnungszahl, die Reads ausgeben; ein Consumer, der die Ordnungszahl speichert, übersetzt sie an seiner eigenen Naht in die Bezeichnung.

Neu

• Items können jetzt Nutzer-Labels tragen — frei wählbare Tags, getrennt vom Anzeige-Typ des Plugins — durch alle Schichten. Anlegen und entfernen mit nxf label add/remove <id> <label>, auslesen mit nxf label list <id>; Labels erscheinen im --json von show, list und next, und list/next akzeptieren einen --label <tag>-Filter. Labels bilden ein eigenes Observed-Remove- OR-Set, sodass gleichzeitige Änderungen wie bei Abhängigkeiten konvergieren (ein doppeltes Hinzufügen lässt genau ein Label; ein Remove entfernt nur das Beobachtete). Dieselben Werkzeuge stehen über MCP als flow_label_add, flow_label_remove und flow_label_list bereit. Die mitgelieferte Migration beads → nexus-flow überträgt die beads-Labels eines Tickets in dieses OR-Set.
• Plugins können jetzt im Schema pro Feld eine Merge-Strategie deklarieren — eine neue optionale [merge]-Tabelle ordnet einem Feld lww, crdt-text oder or-set zu, sodass die Zusammenführung gleichzeitiger Änderungen an einem Feld zur deklarativen Wahl wird statt einer fest verdrahteten Regel. Die mitgelieferten Plugins issue-tracker und personal-todo bleiben unverändert: jedes Feld bleibt Last-Writer-Wins. crdt-text ist für den kommenden kollaborativen Notiz-Body reserviert und foldet Last-Writer-Wins, bis der Text-CRDT-Reducer landet — die Deklaration ist heute also sicher und verlustfrei.

Geändert

• setup claude ist jetzt ein vollwertiges Umbrella-Verb: nxs setup claude ist der kanonische Befehl, nxf setup claude delegiert darauf. Host-Integration gehört ins Umbrella, weil der verdrahtete SessionStart-Hook nxs prime ist. Beide Oberflächen verhalten sich identisch — gleiche --json-Ausgabe, gleiche Workspace-Auflösung — und es gibt nur noch eine Implementierung, sodass die beiden nie auseinanderlaufen können.
• Der verwaltete nexus-flow-Block in AGENTS.md/CLAUDE.md beginnt jetzt mit einer Markdown-Überschrift (## nexus-flow tools for agents), sodass der Hinweis als eigener Abschnitt erkennbar ist statt als lose stehender Satz.
• Das Flow-Plugin-Set wird jetzt aus einer Compile-Zeit-Registry zusammengesetzt statt aus einer fest verdrahteten Liste — ein Consumer kann damit ein eigenes Plugin beisteuern, indem er ein Crate linkt, das eines registriert; die Plugin-Definition muss nie in diesem Repository liegen. Ein doppelter Plugin-Name über registrierte Crates hinweg wird laut abgelehnt (nie per Link-Reihenfolge-Zufall aufgelöst), und ein einzelnes fehlerhaftes Fremd-Plugin führt zu einem Fehler statt zum Abbruch des gesamten Tools. Die zwei mitgelieferten Plugins (issue-tracker, personal-todo) bleiben unverändert. Facade-API: available() ist jetzt fehlbar (liefert ein Result), und die Konstante PLUGIN_NAMES ist zugunsten einer registry-getriebenen Funktion plugin_names() veraltet (ein Release lang als Migrationsfenster erhalten).

Behoben

• nxs init und setup claude stellen eine gelöschte AGENTS.md wieder her. Bisher tat ein erneutes nxs init in einem Workspace, in dem bereits alle gewählten Tools eingerichtet waren, nichts (die Datei-Assemblierung hing am erstmaligen Einrichten), und setup claude verdrahtete nur den Session-Hook — eine entfernte AGENTS.md blieb also weg. Beide (re-)assemblieren die geteilten Agent-Dateien jetzt bei jedem Lauf, idempotent, und aktualisieren den verwalteten Verweis in einer vorhandenen CLAUDE.md (eine CLAUDE.md wird nie neu angelegt).
• Die Migration beads → nexus-flow (nxs init --from-beads) verwirft die Zurückstell- und Fälligkeitsdaten eines Tickets nicht mehr stillschweigend. Ein in beads zurückgestelltes Ticket (defer_until) wandert jetzt mit erhaltenem Datum in die Deferred-Lane — nxf deferred listet es, und es bleibt bis dahin aus nxf next heraus — und ein Fälligkeitsdatum (due_at) wird ebenfalls übernommen. Zuvor gingen beide Felder beim Import verloren, sodass ein zurückgestelltes Ticket als gewöhnliche offene Arbeit ohne Datum landete.
• Die Migration beads → nexus-flow (nxs init --from-beads) prüft die defer_until- und due-Daten eines Tickets jetzt, bevor sie übernommen werden: ein fehlerhafter Wert wird übersprungen und in einer neuen warnings-Liste im Migrationsbericht ausgewiesen, statt unverändert geschrieben zu werden. Da die Deferred- und Ready-Lanes diese Daten als Text vergleichen, hätte ein fehlerhaftes Datum ein Item sonst stillschweigend und dauerhaft in die falsche Lane einsortiert. Labels, die die Prüfung nicht bestehen, erscheinen ebenfalls unter warnings statt in der (nur für Kanten gedachten) skipped-Liste.

Behoben

• Der @nexus-flow/mcp-npx-Runner funktioniert jetzt mit der dokumentierten Host-Konfiguration npx -y @nexus-flow/mcp -- --workspace <pfad>. npx reicht den ---Trenner in die Shim-Argumente durch, wodurch der Server bisher nxs mcp serve -- --workspace <pfad> erhielt und dies mit „unexpected argument '--workspace'" ablehnte. Der Shim entfernt jetzt ein einzelnes führendes --, sodass --workspace und weitere Flags korrekt beim Server ankommen. Die Variante ohne Flags (npx -y @nexus-flow/mcp, der geteilte Standard-Workspace) war nicht betroffen.

Neu

• nxs mcp serve — ein Model-Context-Protocol-Server (read-only, über stdio) für MCP-native Hosts wie Claude Desktop. Er stellt die flow-Lesewerkzeuge flow_next, flow_show und flow_list über denselben geteilten .nxs/-Workspace bereit, den auch die CLI nutzt — ein Werkzeug-Ergebnis ist damit derselbe kanonische Datensatz wie nxf <befehl> --json. Beim Verbinden liefert er statische Nutzungs-Hinweise (Workflow-Regeln + Tool-Referenz + den Nudge „ruf zuerst flow_next auf") als Session-Instructions; der Live-Stand kommt über die Tools. Standardmäßig aktiv; mit --no-default-features weglassbar.
• Das Schließen eines Elternteils warnt jetzt vor den Kindern, die es still mitnimmt (Epic 07a). Da ein geschlossener Elternteil ein noch offenes Kind in die Geschlossen-Spur maskiert, ohne in es zu schreiben, konnte der Schließende nicht sehen, was er ausgelöst hat — besonders bei einem Kind, das mehrere Container teilen. nxf close (und das MCP-Tool flow_close) melden es nun: eine Warnzeile für Menschen und unter --json ein Feld swept_children, das jedes mitgenommene Kind mit Titel und seinen anderen Eltern (id + Status) auflistet, sodass du erkennst, ob das Kind noch irgendwo offen hängt, und es bei Bedarf wieder öffnen oder nachfassen kannst. Der eigene Status der Kinder wird nie verändert.
• Der MCP-Server stellt jetzt den Rest der flow-Lese-Oberfläche als Tools bereit und vervollständigt damit die Lese-Naht: flow_blocked (blockierte Items samt der offenen Blocker, die sie aufhalten), flow_search (lane-gerankte Teilstring-Suche über Titel/Beschreibung/Design/DoD/Notizen, mit denselben Status/Typ- und Archiv-Filtern wie die CLI), flow_note_list (die Worklog-Notizen eines Items) und flow_mention_list (die Kurz-IDs, die ein Item zitiert). Jedes ist eine dünne Hülle über derselben Lese-Berechnung wie die nxf-CLI, sodass sein structuredContent byte-identisch zu nxf blocked, nxf search, nxf note list und nxf mention list unter --json ist, und jedes trägt maschinenlesbare read-only-Annotationen. Eine id-adressierte Liste auf einem fehlenden Item ist ein not_found-Tool-Fehler, genau wie in der CLI. (flow_next deckt die Ready-Menge bereits ab und ist daher nicht Teil dieses Schnitts.) Die Facade erhält additive Helfer read::notes / read::mentions (samt ihrer *_to_value-Renderer), die CLI und MCP-Naht sich nun teilen.
• Der MCP-Server stellt jetzt den Rest der flow-Schreib-Oberfläche als Tools bereit und vervollständigt damit die Schreib-Naht: eine contributes-to-Kante über flow_contributes_add / flow_contributes_remove (n:m, blockiert nie) sowie die Batch-Archivierung flow_archive / flow_unarchive. Jedes läuft über dieselbe geteilte Schreibschicht wie die nxf-CLI, sodass die Quittung byte-identisch zu nxf contributes …, nxf archive und nxf unarchive unter --json ist, mit explizitem now und actor je Aufruf. Die Archiv-Tools sind partielle Batches: ein Root, der seine Vorbedingung verletzt (z. B. ein nicht geschlossenes Item archivieren), wird in den per-Root-results der Quittung mit einem Reason-Code gemeldet — nie als Fehler — genau wie in der CLI. Jedes Tool trägt maschinenlesbare Annotationen (read-only false; destructive/idempotent je Op), damit strikte Hosts es korrekt kennzeichnen.
• Der MCP-Server stellt jetzt auch flows Schreiboperationen als Tools bereit, sodass MCP-native Hosts (Claude Desktop, Claude Cowork, …) das Board nicht nur lesen, sondern ändern können: flow_create, flow_update, flow_claim, flow_close, flow_dep_add/flow_dep_remove, flow_mention_add/ flow_mention_remove und flow_note_add. Jedes Tool läuft über dieselbe geteilte Schreibschicht wie die nxf-CLI, sein Ergebnis ist daher byte-identisch zu nxf <befehl> --json, und jedes trägt korrekte maschinenlesbare Annotationen (readOnlyHint: false plus destructive/idempotent-Hinweise je Operation), damit ein Host Mutationen richtig kennzeichnen und absichern kann. Ein neues Flag nxs mcp serve --actor <id> (bzw. NXS_ACTOR) setzt den Standard-Autor für Schreibvorgänge, und jeder Tool-Aufruf kann ihn pro Schreibvorgang mit eigenem actor überschreiben — so weist ein langlebiger, vom Host gestarteter Server jede Änderung zu, statt alles unter einer Identität zu schreiben.
• Der neue Befehl nxs mcp install trägt diese nxs-Binary als MCP-Server in die Konfiguration deiner installierten Hosts ein, damit MCP-native Apps (Claude Desktop, Cursor, Windsurf) sie erreichen, ohne dass nxs in deren PATH liegt. Er schreibt einen idempotenten mcpServers.nxs-Eintrag mit dem absoluten Pfad der laufenden Binary plus mcp serve und lässt jeden anderen Server und jede andere Einstellung in der Datei unangetastet (der Schreibvorgang ist atomar, ein abgebrochener Lauf kann deine Konfiguration also nie abschneiden). Ohne Flags durchsucht er die bekannten Hosts und patcht jeden installierten; ein erneuter Lauf mit bereits passendem Eintrag ändert nichts, und eine einzelne beschädigte oder unlesbare Host-Konfiguration wird gemeldet und übersprungen, statt die übrigen abzubrechen. Mit --host <id> (wiederholbar: claude-desktop | cursor | windsurf) zielst du auf einen bestimmten Host, auch wenn er nicht automatisch erkannt wird, und mit --workspace <pfad> pinnst du einen Projekt-Workspace im Eintrag (weglassen → der Server nutzt seinen nutzereigenen Standard-Workspace). --json gibt das Ergebnis je Host aus (written / unchanged / skipped / error).
• nxs mcp install kann den Workspace jetzt im selben Befehl anlegen, der den Server registriert. Mit --setup (oder einfach --plugin <id>, das es impliziert) wird zusätzlich das flow-Board erzeugt, das der Server öffnet — ein Befehl registriert nxs also in deinen MCP-Hosts und legt das Board an und schließt damit das Ein-Befehl-Onboarding ab. Das Plugin ist standardmäßig personal-todo (die alltägliche To-do-Liste); mit --plugin issue-tracker wählst du den Coding-Fall. Der Server bleibt plugin-agnostisch und liest die Wahl aus der config.toml des Workspaces. Das Board entsteht genau in dem Verzeichnis, das der Server auflöst, sodass Setup und Server nie auf zwei verschiedene Boards zeigen: ohne --workspace landet es im nutzereigenen Standard-Workspace und der Host-Eintrag bleibt flag-frei; mit --workspace <pfad> landet es dort und genau dieser Pfad wird im Eintrag gepinnt. Das Setup ist idempotent und überschreibt ein bestehendes Board nie, und ein unbekanntes --plugin schlägt laut fehl, bevor irgendetwas angelegt wird. --json meldet das gewählte Plugin und den Board-Ort unter dem neuen Feld setup.
• Der MCP-Server stellt jetzt auch die Gedächtnismaschine als Tools bereit, sodass MCP-native Hosts (Claude Desktop, Claude Cowork, …) dauerhafte Agenten-Erinnerungen neben dem flow-Board lesen und schreiben können: memory_list, memory_search, memory_show, memory_add, memory_update und memory_close. Die memory-Tools werden über die aktiven Module ausgefächert — sie erscheinen nur, wenn der bediente Workspace das memory-Modul aktiv hat (nach nxm init); ein reiner flow-Workspace zeigt sie also nie. Jedes Tool läuft über dieselbe geteilte memory-Facade wie die nxm-CLI, sein Ergebnis ist daher byte-identisch zu nxm <befehl> --json, und jedes trägt korrekte maschinenlesbare Annotationen (Lese-Tools readOnlyHint: true; Schreib-Tools readOnlyHint: false mit destructive/idempotent-Hinweisen je Operation). Ist memory aktiv, weisen die Nutzungshinweise beim Verbinden den Host zusätzlich an, zu Sitzungsbeginn memory_list (neben flow_next) aufzurufen, um dauerhafte Fakten zu laden.
• Du kannst den nexus-flow-MCP-Server jetzt auch auf einem Rechner starten, auf dem nxs gar nicht installiert ist. Ein neuer npm-Runner-Shim, @nexus-flow/mcp, lässt eine Host-Konfiguration den Server mit npx -y @nexus-flow/mcp -- --workspace <pfad> starten: Er lädt das signierte nxs-Prebuilt für deine Plattform, verifiziert es (sha256 und minisign — ein manipulierter, unsignierter oder mit falschem Schlüssel signierter Download bricht ab, bevor irgendetwas läuft, ohne unsicheren Fallback), cacht es und führt nxs mcp serve aus. Der erste Start lädt und verifiziert (wenige Sekunden); spätere Starts nutzen den Cache und starten sofort, auch offline. Um diesen portablen Eintrag zu schreiben, führe nxs mcp install --runner npx aus (der Standard, --runner native, schreibt weiterhin den Absolutpfad-Eintrag für ein bereits installiertes nxs).
• Neuer Leitfaden „Einen MCP-Host verbinden" — als /docs-Portalseite und als nxf guide mcp — der zeigt, wie man Claude Desktop, Cursor und Windsurf mit nexus-flow verbindet. Er liefert Copy-paste-Konfigurationsschnipsel für beide Eintragsarten: den installationsfreien npx @nexus-flow/mcp-Runner (funktioniert, bevor nxs installiert ist) und den direkten Eintrag, den nxs mcp install schreibt. Er dokumentiert außerdem beide Bootstrap-Wege (das signierte install.sh-Ein-Zeilen-Skript und den npx-Runner), wie man den Workspace wählt, den der Server öffnet (den geteilten Standard, ein gepinntes --workspace oder einen Override pro Tool), und die fail-closed-Signaturprüfung hinter jedem Abruf.
• Jedes nxs mcp serve-Tool akzeptiert jetzt ein optionales workspace-Argument, das den beim Start festgelegten Workspace des Servers für genau diesen Aufruf überschreibt — ein laufender Server kann so mehrere Boards bedienen, ganz ohne Registry. Lässt du es weg (oder übergibst einen leeren String), löst das Tool wie bisher den Start-Default auf (den nutzereigenen App-Data-Home-Workspace oder den beim Start übergebenen --workspace). Gibst du einen Pfad an, liest/schreibt dieser Aufruf stattdessen das .nxs/-Board dort. Der Store wird pro Aufruf geöffnet, der Override ist also nur ein anderer Auflösungspunkt. Die Auflösung läuft (wie in der CLI) die Verzeichniskette hoch, ein Pfad ohne .nxs/ in sich oder einem übergeordneten Verzeichnis liefert also einen no_workspace-Fehler im Tool-Ergebnis (dort nxs init ausführen); der Server bedient weiter sein Start-Board — kein Startfehler.

Geändert

• nxs mcp serve funktioniert jetzt ohne --workspace von Haus aus: Der Server legt beim ersten Start einen stabilen, benutzereigenen Standard-Workspace an und bedient ihn (macOS ~/Library/Application Support/it.nexflow.app/.nxs/, Linux XDG, Windows %APPDATA%). So findet ein MCP-Host wie Claude Desktop — der kein sinnvolles Arbeitsverzeichnis hat — immer dasselbe Board. --db/NXS_DB und --workspace/NXS_WORKSPACE haben weiterhin Vorrang; ein Workspace wird nicht mehr aus dem aktuellen Verzeichnis erraten.
• nxf search gruppiert jetzt jedes Treffer-Item nach seiner effektiven Spur, sodass ein durch seine Eltern unterdrücktes oder maskiertes Kind nicht mehr aus den Ergebnissen verschwindet (Epic 07a). Ein unter einem blockierten Vorfahren verborgenes Kind erscheint nun in der Blockiert-Gruppe, eines unter einem zurückgestellten Vorfahren in der Zurückgestellt-Gruppe und ein noch offenes Kind, dessen Eltern alle geschlossen sind, in der Geschlossen-Gruppe — jedes weiterhin mit seinem eigenen gespeicherten Status, nur die Gruppierung verschiebt sich. nxf list und nxf next (sowie die entsprechenden MCP-Tools flow_list / flow_next und das Embed-Engine) führen jetzt zusätzlich die parent_closed_reason-Verknüpfung — bereits bei nxf show vorhanden — für ein solches maskiertes Kind, sodass ein Agent beim Durchgehen des Boards *sieht*, warum ein Item geschlossen wirkt (jeder geschlossene Elternteil und sein Schließungsgrund), ohne nachzuschlagen. Ein in Arbeit befindliches Kind eines noch nicht begonnenen (ready) Elternteils wird als ready gruppiert, statt den Fortschritt zu überzeichnen; sein gespeicherter Status bleibt unverändert.
• Das Beanspruchen eines Items markiert jetzt auch seine Eltern-Kette als in Arbeit (Epic 07a, „claim-up"). Wenn du ein Kind beanspruchst (nxf claim, flow_claim oder das Embed-Engine::claim), wird jeder noch offene Vorfahre die volle Eltern-Kette hinauf — alle Eltern, transitiv — auf in_progress gesetzt, sodass ein Container widerspiegelt, dass darin Arbeit begonnen hat. Ein geschlossener Vorfahre bleibt geschlossen (das Beanspruchen eines Kindes belebt einen bewusst geschlossenen Container nie wieder), und ein bereits in Arbeit befindlicher bleibt unverändert. Und nxf next/nxf ready (sowie die Embed-Engine) **unterdrücken jetzt ein Kind, dessen Eltern-Kette einen blockierten oder zurückgestellten Vorfahren enthält**: ist irgendein Vorfahre wartend (durch eine offene Abhängigkeit blockiert oder in die Zukunft zurückgestellt), fallen seine Nachkommen aus der ready/next-Empfehlung heraus, bis dieser Vorfahre fortfahren kann — so wirst du nicht auf Arbeit verwiesen, die unter einem Container liegt, der nicht starten kann. Eine verwandte Closed-Maske kommt ebenfalls: ein noch offenes Kind, dessen Eltern alle geschlossen sind, fällt auch aus ready/next heraus (es ist über seine Container effektiv geschlossen), und nxf show führt für ein solches Kind nun ein Feld parent_closed_reason, das jeden geschlossenen Elternteil samt Schließungskommentar auflistet — sodass du *siehst*, warum ein offenes Item fertig wirkt, und entscheiden kannst, ob du es wieder öffnest. Der eigene gespeicherte Status des Kindes wird nie überschrieben. Dies sind die ersten Scheiben des Eltern↔Kind-Statuskopplungs-Modells (docs/specs/07a-parent-child-status-coupling.md), in dem parent zu einer gatenden Containment-Kante wird, während contributes_to der nicht-gatende Ausweg bleibt.
• nxf prime (und die MCP-Session-Anweisungen) erklären jetzt die bewusste Wahl zwischen den beiden Containment-Kanten (Epic 07a): parent ist gatend — ein Kind ruht, wenn sein Container ruht, sodass ein zurückgestellter, blockierter oder geschlossener Elternteil nach unten durchschlägt und das Kind verbirgt oder maskiert — während contributes_to die nicht-gatende Zuordnung für „gehört hierher, trägt dort bei" ist. Ein einziges durchgespieltes Beispiel macht den Unterschied greifbar, damit Agenten ein Board nicht überbeschränken und Arbeit still verbergen.
• nxs prime / nxm prime formuliert die Memory-Regel jetzt deutlich nachdrücklicher. Die Zeile ist mit CRITICAL markiert, nutzt eine NEVER-Imperativform gegen das Anlegen einer MEMORY.md (oder einer anderen Ad-hoc-Memory-Datei) und benennt die Konsequenz: nxs liest eine solche Datei nie, sie wird daher beim Sitzungsstart nie erneut eingespielt, und dieses Wissen geht still verloren. Die Meldung stellt klar, dass nxm remember der eine dauerhafte Kanal für Projektwissen (Konventionen, Fallstricke, Entscheidungen) ist — verwende einen stabilen --key wieder, um einen Fakt an Ort und Stelle weiterzuentwickeln. Die frühere Formulierung war zu weich, und Agenten legten weiterhin MEMORY.md-Dateien an, deren Inhalt nie in die nächste Sitzung überlebte.
• Die Store-Lesepfade von flow und memory sind jetzt fehlertolerant: ein echter Datenbankfehler (z. B. SQLITE_BUSY nach Ablauf des Busy-Timeouts oder eine fehlerhafte Zeile) wird als strukturierter io-Fehler gemeldet, statt zu panicken. Bisher haben die listenförmigen Reads das SQLite-Ergebnis mit .unwrap() ausgepackt, sodass ein DB-Fehler den Aufrufer abwickelte — für eine einmalige CLI vertretbar, doch im langlebigen nxs mcp serve stdio-Server konnte ein Read-Tool (memory_list/memory_search, flow_list/flow_show) seinen Handler abwickeln. Die flow-Facade-Reads (list, blocked, closed, archived, search, prime, undeclared_types) und die Embedding- Engine-Reads (list/blocked/closed/archived sowie memorys memories) liefern jetzt ein Result, und ein DB-Fehler wird an der Store-Grenze auf den io-Kind abgebildet. Auch recall/get von memory verschlucken einen DB-Fehler nicht mehr zu einem irreführenden not_found — nur ein wirklich fehlender Schlüssel ist not_found, ein DB-Fehler ist io. Dies ist eine rückwärtsinkompatible Änderung der öffentlichen Read-API von crates/facade (ein Minor-Break).

Behoben

• Workspaces, die vor dem Plugin-Typsystem angelegt wurden, konnten Alt-Typen (project/task) tragen, die das aktive Plugin nicht mehr deklariert — solche Items zeigten ihren rohen Typ und ließen keine Parent-Kanten zu, ohne unterstützten Reparaturweg. type ist jetzt über das Retype-Primitiv nxf update <id> --set type=<deklariert> setzbar (gegen die Plugin-Typen validiert, mit erneuter Prüfung der Beziehungs-Kanten), und nxf prime zeigt beim Session-Start einen nicht-stillen Hinweis, wenn ein Workspace undeklarierte Item-Typen enthält (Vorschlag: project→epic, task→feature).
• Die Legacy-Typ-Reparatur (nxf update <id> --set type=) migriert jetzt auch einen Workspace, dessen *komplette* Hierarchie aus der Zeit vor dem Plugin-Typsystem stammt. Bisher prüfte das Retype beide Kanten (Eltern und Kinder) strikt, sodass auf einem reinen project/task-Board kein Ende umtypisierbar war — das Kind blockiert vom noch-legacy Elternteil, das Elternteil vom noch-legacy Kind (eine Sackgasse, nichts reparierbar). Das Retype überspringt jetzt eine Kante, deren anderes Ende noch ein nicht deklarierter Legacy-Typ ist, sodass das Board Item für Item in beliebiger Reihenfolge migriert.
• Die beim Verbinden gelieferten Anweisungen des MCP-Servers nennen keine nicht existierenden Tools mehr. Workflow-Regeln, die auf Schreibbefehle ohne lesendes Tool verweisen (claim, close, note, mention), bleiben jetzt einfache CLI-Hinweise, statt zu erfundenen flow_*-Toolnamen umgeschrieben zu werden; nur Befehle mit echtem Tool (z. B. flow_next) erscheinen als Toolname. Jedes in den Anweisungen genannte Tool ist nun garantiert auch in der Tool-Liste des Servers vorhanden.
• nxf schema weist jetzt für jedes Feld den exakten create --json-Payload-Schlüssel und die Wertform aus, sodass ein Agent beim Bau eines Payloads nicht mehr gegen deny_unknown_fields raten muss. Drei Create-Schlüssel folgen bewusst den CLI-Flags und weichen von der Lese-/show --json-/`update --set-Schreibweise ab — dod/defer/parent` statt completion_criterion/defer_until/belongs_to — und priority ist beim Anlegen ein benanntes Label (P0…P4), nicht die Lese-Ordinalzahl. Jedes Feld meldet nun create_json_key (und priority seine create_json_values) unter nxf schema --json und in der Menschenansicht, und ein mit dem kanonischen Namen versehenes Payload erhält einen gezielten Hinweis (z. B. „use 'dod', not 'completion_criterion' — see nxf schema") statt der bloßen „unknown field"-Liste. Der akzeptierte Payload-Vertrag bleibt unverändert (weiterhin strikt) — er ist jetzt auffindbar. Für einbettende Consumer: eure Create-Payloads sind nicht betroffen; wenn ihr Agenten ein Create-Formular anbietet, lest die exakten Schlüssel aus nxf schema --json.
• Der langlebige MCP-/Embed-Server stürzt nicht mehr ab, wenn die Datenbank während einer Ableitung oder einer Eltern-Kanten-Schreibprüfung stockt. Im Anschluss an die Härtung der Speicher-Lesezugriffe melden die Ableitungsschicht (next, ready, deferred, blocked, search, prime) und der Eltern-Validierungslauf zur Schreibzeit (die Zyklus-, Kardinalitäts- und Tiefenprüfungen bei create/update --parent) einen vorübergehenden Datenbankfehler — eine belegte Sperre, einen fehlerhaften Lesezugriff — nun als strukturierten io-Fehler, statt den Handler abstürzen zu lassen, genau wie es die Abhängigkeitszyklus-Prüfung bereits tat. nxf über einem geteilten Workspace zu lesen oder die Tools von einem Host aufzurufen ist jetzt robust gegen eine kurzzeitig umkämpfte Datenbank.
• Die letzten Eltern-Kanten-Lesezugriffe auf dem langlebigen MCP-/Embed-Server stürzen nicht mehr ab, wenn die Datenbank stockt. Als Abschluss der Härtung der Speicher-Lesezugriffe melden die Anzeige-Joins der effektiven Lane (die Closed-Mask-Gründe bei show/list/next, die Swept-Children-Warnung im close-Beleg und die Lane-Gruppierung von search), der Claim-Up-Lauf (claim propagiert „in Arbeit" die Elternkette hinauf) sowie die Retype-Revalidierung (update --set type=…) einen vorübergehenden Datenbankfehler nun als strukturierten io-Fehler, statt den Handler abstürzen zu lassen. Ein Einzel-Lookup, der auf einen echten Datenbankfehler trifft, meldet ihn jetzt ebenfalls als io statt als irreführendes „nicht gefunden". Das Arbeiten über einem geteilten Workspace oder das Ansteuern der Tools von einem Host ist damit auf allen Lesepfaden robust gegen eine kurzzeitig umkämpfte Datenbank.
• Die Read-Tools des MCP-Servers funktionieren jetzt mit strikten Hosts wie Claude Desktop und Claude Cowork. flow_list und flow_next lieferten ihren structuredContent bisher als JSON-Array auf oberster Ebene, was strikte Hosts als fehlendes Ergebnis zurückweisen — sie liefern nun ein JSON-Objekt mit der Liste unter items. Alle drei Read-Tools (flow_next, flow_show, flow_list) tragen zudem maschinenlesbare Annotationen readOnlyHint: true / openWorldHint: false, damit Hosts sie als sichere Reads einer geschlossenen Domäne erkennen, kennzeichnen und automatisch freigeben können.

Entfernt

• Das ausgemusterte Verb ready ist jetzt von jeder öffentlichen Oberfläche verschwunden. ready ging bereits in C4 in next auf — nxf next ist die gerankte Ready-Menge, und nxf next --include-in-progress zeigt zusätzlich beanspruchte Arbeit. Der CLI-Migrationsstub ist entfernt, sodass nxf ready nun schlicht ein unbekannter Unterbefehl ist (der MCP-Server hat es nie angeboten). Einbettende Apps: Engine::ready(now) und der Helfer read::ready sind aus der Facade-API entfernt — für dieselbe Ready-Menge Engine::next(now, false) aufrufen. Die interne Ableitung, aus der die Empfehlung gebaut wird, bleibt unverändert; nur die redundante, ready benannte Oberfläche wird ausgemustert.

Neu

• nxs init (und nxf/nxm init) erkennen jetzt ein Projekt, das noch beads nutzt, und bieten die Migration nach nexus-flow an. Nach Zustimmung werden alle beads-Daten gesichert (bd export --all, bleibt erhalten — wird nie gelöscht), die Tickets nach flow importiert (Titel, Beschreibung, Typ, Priorität, Status, Parent-/Abhängigkeits-Kanten über ID-Remapping sowie Schließgründe — mit erhaltenen Zeitstempeln) und die bd remember-Erinnerungen nach nxm (Keys bleiben erhalten); anschließend wird beads' verwaltete Konfiguration zurückgebaut (der BEADS INTEGRATION-Block in AGENTS.md/CLAUDE.md und die bd prime-Hooks) und nxs eingerichtet — handgeschriebener Text bleibt unangetastet. Zustimmung ist Pflicht: am Terminal wird gefragt; --json/nicht-interaktive Läufe migrieren nie ohne das explizite Flag --from-beads und zeigen stattdessen eine Dry-Run-Vorschau. nxs doctor weist zudem auf zurückgebliebene beads-Konfiguration (eine halb fertige Migration) hin, damit sie aufgeräumt werden kann.
• nxf create -q (Alias --id-only) gibt nur die ID des neuen Tickets in einer einzigen Zeile aus — kein JSON, kein Ausgaberahmen — sodass sie sich direkt in den nächsten Befehl übernehmen lässt (id=$(nxf create "..." -q)), ohne JSON zu parsen. Zusammen mit --json hat -q Vorrang (die ID gewinnt; --json wird ignoriert, kein Fehler). nxf prime weist Agenten auf dieses Muster hin und vermerkt, dass --jq eine gh-Konvention ist, die hier nicht existiert.
• Eine Parent-Kante, die einen Zyklus über die Eltern-Relation erzeugen würde (das Ziel erreicht die Quelle bereits über seine Parents), wird jetzt zum Schreibzeitpunkt mit einem lauten cycle-Fehler abgelehnt und nichts wird gespeichert — das Eltern-Analogon zum bestehenden Abhängigkeits-Zyklenschutz. Ein Item unter einen seiner eigenen Nachfahren umzuhängen wird damit an der Quelle verweigert, statt eine ungültige Hierarchie zu erzeugen.
• Das dauerhafte Agenten-Gedächtnis (nxm) lässt sich jetzt von Host-Anwendungen in-process einbetten — analog zur Embedding-API des Issue-Trackers. Ein langlebiger Engine-Handle besitzt den geteilten Workspace + Store über die App-Lebensdauer und stellt die Memory-Verben (recall/list/search + remember/forget) bereit, die den kanonischen Record als Wert zurückgeben, plus subscribe für die Live-Benachrichtigung über Fremd-Writes — eine Host-App (z. B. eine Tauri-Desktop-App) liest und schreibt Memory damit direkt, ohne nxm zu starten. Die Embedding-Oberfläche ist Byte für Byte identisch mit der nxm --json-CLI über denselben Store (durch einen Differenztest belegt) und trägt eine dokumentierte, versionierte Stabilitätszusage.

Geändert

• Die CLI zeigt Ticket-IDs jetzt für lokale Tickets nur mit ihrem Suffix — der 4-stellige Replica-Prefix ist über alle lokalen Tickets identisch und damit reines Rauschen — und behält die volle <prefix>.<suffix> nur für fremde, von einer anderen Replica hereinsynchronisierte Tickets. Nackte IDs werden auch als Eingabe akzeptiert: nxf show 0001 löst gegen den eigenen Prefix auf, eine volle ID (lokal oder fremd) bleibt unverändert. --json, die Engine und Embedding-Apps bleiben unverändert — sie geben und nehmen immer die volle ID, sodass Maschinenausgabe und Referenzen stabil bleiben. Das --json-msg von dep/mention/contributes meldet jetzt unabhängig von der Eingabeform die aufgelösten (kanonisch vollen) IDs. nxf prime nennt jetzt den eigenen Prefix und die Konvention. Die Facade erhält rückwärtskompatible display_id/resolve_id-Helfer (und passende Replica-Methoden); bestehende Aufrufer müssen nichts ändern.
• Das Onboarding von nxs/nxf init ist jetzt ein ruhiger, durchgängig gebrandeter manufakt-Forge-Moment. Der Plugin-Schritt von nxf init nutzt denselben geteilten Pfeiltasten-Chooser wie der Suite-Tool-Picker (kein eigener nummerierter stdin-Prompt mehr). Ember wird sparsamer eingesetzt — es markiert nur den Cursor, während eine Auswahl über Gewicht dargestellt wird, sodass eine Mehrfachauswahl nicht mehr wie eine rote Wand wirkt. Die Willkommens-Box hat einen ruhigeren Rhythmus: großzügiger Weißraum, Padding-Zeilen und ein mit dem Body bündig ausgerichteter Titel. Pro Tool gibt es jetzt ausführlichere „Erfahre mehr"-Entscheidungshilfe im Picker. AGENTS.md wird von Pro-Modul-Blöcken auf einen einzigen Discovery-Zeiger reduziert („run nxs prime …"), der die aktiven Tools nennt; bestehende Workspaces werden beim nächsten Init automatisch darauf migriert. Alle nicht-interaktiven Pfade (--json, Pipes, Nicht-TTY) bleiben byte-stabil.
• Das interaktive Onboarding von nxs/nxf init bekommt mehr Luft: zwei Leerzeilen unter der Willkommens-Box und unter dem „Was macht jedes Tool?"-Panel, eine Leerzeile zwischen der Frage „Which tools…?" und den Optionen, zwei Leerzeilen vor der abschließenden „nexus-flow is set up"-Zusammenfassung und vor deren „your first move"-Handlungsaufruf sowie eine abschließende Leerzeile, damit der Shell-Prompt nicht direkt an der letzten Zeile klebt. Rein optisch; nicht-interaktive Ausgabe (--json, Pipes, Nicht-TTY) bleibt unverändert.
• Item-Typen werden jetzt gegen das vom aktiven Plugin deklarierte Typ-Set validiert statt gegen ein festes Core-Enum project|task. Der Core ist typ-agnostisch: Er speichert den übergebenen Typ-String unverändert, und das aktive Plugin bestimmt, welche Typen gültig sind. Für die mitgelieferten Plugins issue-tracker und personal-todo bleiben die akzeptierten Typen und der --json-Record unverändert; ein unbekannter --type ist weiterhin ein lauter Validierungsfehler (nun mit den Typen des aktiven Plugins). Das ist das Fundament für das plugin-konfigurierbare Typsystem (E3).
• Die Hierarchie-Elternschaft liegt jetzt im konfliktfreien Kanten-Set statt in einem Einzel-Eltern-Register; das Datenmodell ist darunter n:m-fähig (die CLI erzwingt vorerst weiterhin einen einzigen Parent). Das ist ein brechendes Schema-Upgrade: Ein Workspace, der einmal mit dieser Version geöffnet wurde, wird automatisch und verlustfrei migriert — bestehende Eltern-Verknüpfungen bleiben erhalten — lässt sich danach aber nicht mehr mit einem älteren nxs/nxf öffnen; aktualisiere daher jede Maschine, die sich einen Workspace teilt. Der --json-Record und die Felder parent/belongs_to bleiben unverändert.
• Die Parent-Validierung wird jetzt von einer Plugin-Beziehungsmatrix gesteuert (erlaubte Parent→Kind-Typ-Paare, Parent-Kardinalität pro Typ und ein Tiefenlimit), zum Schreibzeitpunkt erzwungen, statt der fest verdrahteten Regel „ein Parent muss ein Project sein, und nur einer". Die mitgelieferten Plugins issue-tracker und personal-todo verhalten sich exakt wie zuvor — ein einziger Parent, Parent muss ein Project sein —, im Alltag also unsichtbar; nur der Wortlaut der Ablehnung hat sich geändert. Es ist das Fundament dafür, dass Plugins ihre eigenen Hierarchie-Formen deklarieren (z. B. Multi-Parent), was eine spätere Änderung anbindet.
• Jedes mitgelieferte Plugin deklariert jetzt sein eigenes Typsystem in einer [types]-Tabelle — die vollständige Menge der Item-Typen, die erlaubten Parent→Kind-Paare, wie viele Eltern jeder Typ haben darf und ein Tiefenlimit der Hierarchie — alles zum Schreibzeitpunkt erzwungen, nichts im Core fest verdrahtet. issue-tracker bietet nun epic, bug, feature, chore, decision: nur ein epic ist Container, und jeder andere Typ hat höchstens einen epic-Parent (oder keinen). personal-todo bietet project, todo, termin, wobei ein todo oder termin zu beliebig vielen Projekten gehören darf. Dieser Unterschied „ein Parent vs. viele" ist jetzt echtes Verhalten, nicht nur ein Label. Item-Typen werden unter ihren deklarierten Namen gespeichert, sodass --json z. B. feature/todo meldet statt der früheren Core-Typen task/project. Ein Item mit einem Typ anzulegen, den das aktive Plugin nicht deklariert, einen nicht erlaubten Parent zu setzen oder tiefer zu verschachteln, als das Plugin zulässt, wird mit einem klaren Validierungsfehler abgelehnt. Facade: PluginConfig erhält ein types-Feld und das matrix-Modul die [types]-Form (Typ-Liste + Kardinalität pro Typ, inkl. "many").
• Das next-Empfehlungs-Ranking ist jetzt vollständig deklarativ — keine Präzedenz ist mehr in der Engine fest verdrahtet. Ein Ranking-Schlüssel kann eine Enum-Index-Präzedenzliste ausdrücken (die Position eines Werts in der Liste ist sein Rang), neben den bestehenden Feld-Schlüsseln. issue-tracker nutzt das für eine Typ-Präzedenz: innerhalb einer Prioritätsstufe ordnet sich verfügbare Arbeit nun epic → bug → decision → feature → chore. Die zuvor fest verdrahtete Stufe „begonnene Arbeit zuerst" ist jetzt der führende Status-Präzedenz-Schlüssel, den beide mitgelieferten Plugins deklarieren — das Verhalten bleibt gleich, aber die Regel steht in der Config, nicht im Code. Die vollständige issue-tracker-Reihenfolge ist nun Status → Priorität → Typ → Fällig → id; personal-todo bleibt feldbasiert (kein Typ-Ranking). Der deterministische id-Tiebreaker und die --json-Reihenfolge sind unverändert. Facade: RankKey erhält ein precedence-Feld.
• Härtungs- und Klarheits-Folgearbeiten am E3-Typsystem. Wenn ein Item keinen Parent haben kann, erklärt sich die Ablehnung jetzt selbst — sie unterscheidet einen Top-Level-Typ von einem, den das aktive Plugin nicht deklariert (Cross-Plugin-/synchronisierte Daten) — statt eines undurchsichtigen „allowed parent types: (none)". Ein Ranking-Schlüssel, der eine Typ-/Status-Präzedenzliste mit dir/nulls kombiniert, wird jetzt beim Laden der Config laut abgelehnt (ein Präzedenz-Schlüssel ordnet nach Listenposition und ignoriert dir/nulls), statt diese still zu verwerfen. Intern ist die Hierarchie-Tiefenprüfung auf breiten zusammengeführten Parent-Graphen nun linear statt exponentiell, und eine ID, die das interne Kanten-Trennzeichen enthält, wird an der Schreibgrenze abgelehnt, statt still eine Kante zu erzeugen, die nie materialisiert. Die Facade erhält eine RankSpec::validate-Methode; bestehende Aufrufer müssen nichts ändern.

Neu

• nxf init richtet jetzt das Agenten-Onboarding im Projekt ein: Es schreibt einen verwalteten, klar gekennzeichneten nexus-flow-Block in AGENTS.md (anlegen oder ergänzen, idempotent), der Agenten auf nxf prime verweist. Existiert eine CLAUDE.md, wird oben ein @AGENTS.md-Import eingefügt; lagen beide Dateien bereits vorher vor (vermutlich doppelter Inhalt), wird der Block stattdessen direkt in CLAUDE.md eingefügt, um eine Dopplung zu vermeiden. Ein SessionStart-Hook ist nicht mehr nötig.
• Neuer Befehl nxf setup claude richtet die Claude-Code-Host-Integration in .claude/settings.json ein: einen SessionStart-Hook, der nxf prime ausführt, sodass der Projektkontext bei jedem Sessionstart automatisch eingespielt wird, plus einen nxf-Permissions-Allowlist-Eintrag, damit seine Befehle nicht nachfragen. Der Befehl ist idempotent und nur mergend — bestehende Hooks, Permissions und andere Schlüssel bleiben erhalten, und ein zweiter Lauf ändert nichts. Das ist das deterministische Gegenstück zum deklarativen AGENTS.md-Block von nxf init (das werkzeug-agnostisch bleibt); der Hook macht das Priming bei Sessionstart zuverlässig statt nur bestmöglich.
• Neuer Befehl nxf schema: eine maschinenlesbare (--json) Beschreibung des vollständigen Feldmodells des aktiven Plugins — seine Typen, Status und Prioritätsvarianten sowie pro Feld dessen Plugin-Label, ob es bei der Anlage verpflichtend und über update --set setzbar ist und wie es gesetzt wird (Flag / Alias). Das ist die agent-ergonomische Antwort auf „was akzeptieren create und update in diesem Workspace" — zur Laufzeit introspizierbar, was eine statische, zur Compile-Zeit feste --help nicht leisten kann. create --help und update --help verweisen jetzt darauf, und nxf prime listet es auf.
• Neuer Befehl nxf contributes macht die n:m-Beziehung trägt-bei-zu erreichbar, die der Core bereits abbildet: contributes add <from> <to>, contributes remove <from> <to> und contributes list <id>. Wie eine Mention blockiert sie nie (sie ist keine Abhängigkeit und taucht nie in blocked auf); beide Endpunkte müssen existieren. nxf show <id> listet die trägt-bei-zu-Kanten jetzt getrennt von deps — als CONTRIBUTES TO-Zeile in der Menschenansicht und als contributes_to-Array unter --json.
• nexus-flow bietet jetzt eine programmatische, in-process Engine-API für einbettende Applikationen (UI / Geschäftslogik — keine Agenten): das Crate nexus-flow-facade. Statt pro Aufruf die nxf-CLI zu starten, hält eine App einen einzigen langlebigen Engine-Handle über ihre gesamte Lebensdauer — sie öffnet und besitzt den lokalen Workspace + Store, liest die Ableitung (ready/blocked/next/show/list/prime), wendet Mutationen an (create/update/claim/close, Abhängigkeiten, Notizen) mit derselben op-log-CRDT-Konvergenz wie die CLI, und abonniert dateibasierte Change-Notifications, um auf Fremd-Writes (CLI-Agent, MCP-Server oder Sync) auf denselben Store zu reagieren. Die Surface ist ein bewusster, versionierter Bibliotheksvertrag (docs/specs/E5-embedding-host-api.md). Keine neue Semantik — Embed-API, CLI und MCP-Naht teilen einen Core und divergieren nie.
• Escaping-freie, agent-native Eingabe für die Langtextfelder (description, design, Definition of Done und Abschlusskommentar) bei nxf create, nxf update, nxf close und nxf note add. Kein Shell-Quoting mehr für mehrzeilige Prosa mit Backticks, Anführungszeichen oder !. Drei Quellen, an einer gemeinsamen Naht aufgelöst: (1) der STDIN---Sentinel — ein Flag-Wert - liest dieses Feld von STDIN (cat design.md | nxf create … --design -, nxf update <id> --set description=-, nxf close <id> --reason -, nxf note add <id> -), verbatim gespeichert; (2) Datei-Flags — --description-file / --design-file / --dod-file / --reason-file sowie nxf update --set-file feld=pfad (UTF-8, verbatim, mehrere Dateien pro Aufruf); (3) ein komplettes JSON-Objekt über STDIN — <json> | nxf create --json - und nxf update <id> --json - schreiben alle Felder als einen gepipten Payload. Pro Feld gilt genau eine Quelle (Mehrfachbelegung wird abgewiesen), und höchstens ein Feld pro Aufruf liest STDIN; jede Ablehnung greift vor dem ersten Write, es wird nie partiell geschrieben. Der JSON- und der Datei-Pfad nutzen dieselbe Validierung wie der Flag-Pfad — kein zweiter Codepfad, keine Divergenz.
• Der neue Befehl nxf agent-manifest gibt nxfs deklarierten Beitrag zu den geteilten Agent-Dateien (den AGENTS.md-/CLAUDE.md-Abschnitt, das prime-Kommando und den SessionStart-Hook) als Daten aus. Er braucht keinen Workspace und ist plugin-unabhängig; --json ist der maschinenlesbare Vertrag. Das ist der Manifest-Contract (Spec §6.2): Jedes nxs-Modul deklariert seinen Agent-Datei-Beitrag als Daten, damit die Plattform die geteilten Dateien daraus zusammensetzen kann, statt dass jedes Werkzeug sie selbst schreibt.
• Neues Plattform-Umbrella-Binary `nxs` mit seinen ersten, foundation-only Verben über den einen geteilten .nxs/-Workspace: nxs migrate hebt die geteilte DB auf die aktuelle Foundation-Schema-Version (der explizite CI/Repair-Hebel — Auto-Migrate-beim-Öffnen bleibt der Default — meldet den Übergang from → to und verweigert fail-loud eine DB, die ein neueres nxs als inkompatibel markiert hat), und nxs doctor (Alias nxs status) gibt eine Cross-Modul-Diagnose aus: die aktiven Module, die Schema-Version und den Stand dieses Binaries dazu (current/degraded/incompatible), die Replica-Identität, ob ein Sync-Stream gebunden ist, die Op-Anzahl und eine DB-Integritätsprüfung. --json ist überall deterministisch. Diese Verben laufen unabhängig davon, welche Produkte aktiv sind — nxs kennt nur den Suite-Roster (welche Produkte es gibt und ihre Binaries), niemals das Vokabular eines Produkts.
• Der per-Modul-Init weist jetzt auf den Rest der Suite hin. Nach nxf init oder nxm init zeigt ein interaktiver Lauf — wenn ein noch nicht eingerichtetes Tool verfügbar ist — eine kurze Handlungsaufforderung, es mit nxs init hinzuzufügen, und --json trägt ein neues additives advertisement-Feld, dessen Text den Agenten anweist, dich auf den Mehrwert aufmerksam zu machen — aber nichts ohne deine ausdrückliche Erlaubnis einzurichten. Beworben werden nur tatsächlich hinzufügbare Tools, sodass der Hinweis verschwindet, sobald alles aktiv ist. Kein bestehendes Feld und kein Verhalten ändert sich.
• Neuer Befehl `nxs init` — die primäre Erst-Begegnung mit der Suite. Er fragt, welche Tools im Workspace eingerichtet werden sollen (Pfeiltasten-Mehrfachauswahl, der Issue-Tracker ist empfohlen), fächert dann an die Inits der einzelnen Module aus und rahmt das gesamte Ergebnis: Die geteilten Agent-Dateien werden assembliert und der einzelne nxs prime-SessionStart-Hook gesetzt. Das Umbrella besitzt die gesamte sichtbare Ausgabe — Module werden still eingerichtet, sodass kein Sub-Init-Rauschen durchblutet. Für Agenten und Skripte ist er nicht-interaktiv: nxs init --module flow --module memory (oder --json) richtet denselben Stand ohne Prompt ein.
• Neues Produkt nexus-memory (Binary nxm) — agent-nativer, offline-first persistenter Projektspeicher auf dem geteilten nxs-Fundament. Pflege dauerhaftes Wissen (Konventionen, Fallstricke, Architektur-Entscheidungen) als per-Key adressierte Text-Fakten: nxm remember "<Fakt>" [--key <key>] (ein stabiler Key aktualisiert in-place; ohne Key dedupliziert ein Content-Hash byte-gleiche Fakten), nxm recall <key>, nxm memories [<Suche>] und nxm forget <key> (ein umkehrbarer Tombstone — ein späteres remember belebt ihn wieder). nxm prime ist der Session-Bootstrap, der alle Memories in den Kontext zurückspielt und die Regel festschreibt, dass dauerhaftes Wissen ausschließlich in nxm remember lebt, niemals in einer MEMORY.md. nxm init richtet das ein (ein managed AGENTS.md-/CLAUDE.md-Block + ein SessionStart-Hook), denselben Vertrag, dem auch nxf folgt. Memory teilt sich einen .nxs/-Workspace, einen Op-Log und eine Sync mit flow, sodass Fakten über Maschinen hinweg synchronisieren statt pro Repo gefangen zu bleiben; --json ist überall deterministisch.
• nxf init warnt jetzt, wenn es ein verwaistes Alt-Verzeichnis .nexusflow/ findet — eines mit db.sqlite, aber ohne replica.toml, die Spur eines init, der vor dem Abschluss abgestürzt ist. Ein solches Verzeichnis wird nicht automatisch migriert (es hat keine Replica-Identität, die übernommen werden könnte); die Warnung weist darauf hin, bevor ein frisches .nxs/ angelegt wird, statt die alten Daten stillschweigend ein Verzeichnis daneben liegenzulassen.
• Neuer Befehl `nxs prime` — das Session-Bootstrap-Fan-out, das der einzelne SessionStart-Hook ausführt. Es ruft das prime jedes *aktiven* Moduls (in Registry-Reihenfolge) mit einem geteilten now auf, sodass alle Module denselben Zeitpunkt sehen, und hängt die Ergebnisse aneinander. Es erscheinen nur die im Workspace eingerichteten Module: Ein flow-only-Workspace liefert genau flows prime; memorys kommt nach nxm init dazu. --json (das prime-Record jedes Moduls unter seinem Schlüssel verschachtelt) und die menschliche Form sind beide deterministisch und byte-stabil, sodass die Hook-Ausgabe nie rauscht. nxs erreicht jedes Modul, indem es dessen eigenständiges Binary ausführt (nxf prime, nxm prime), nicht durch Linken.
• nxf next und der next-Block von nxf prime zeigen jetzt den aufgelösten Parent eines Kind-Items, nicht nur dessen rohe belongs_to-ID — ein Kind liest sich damit nicht mehr wie ein Top-Level-Item. In --json bekommt jeder Record additiv ein parent-Objekt {id, title, type} (der rohe Core-Typ, nie ein Plugin-Label) bzw. parent: null, wenn es keinen Parent gibt. In den Human-Ansichten erhält ein Kind eine eingerückte ↳ <parent-id> · <titel>-Folgezeile. Die Auflösung ist live-only: zeigt belongs_to auf ein gelöschtes/fehlendes Item, ist parent = null, die rohe ID bleibt erhalten. Der generische Item-Record (show/list) bleibt unverändert — der Parent-Join hängt nur an der next/prime-Projektion — und die Ranking-Reihenfolge ändert sich nicht.
• nxm import übernimmt einen bestehenden Claude-Host-Memory-Bestand nach nexus-memory. nxm prime verbietet eine MEMORY.md (dauerhaftes Wissen lebt nur in nxm remember); dies ist die On-Ramp, die aus der Regel eine Tür statt einer Sackgasse macht. Es liest Claude Codes projektweites Memory-Verzeichnis (ein MEMORY.md-Index plus eine Frontmatter-Datei je Fakt) und übernimmt jeden Fakt unter seinem Frontmatter-name: als stabilen Key — ein erneuter Lauf aktualisiert in-place (idempotent, keine Duplikate) und die Quelldateien werden nie verändert (non-destruktiv). nxm init erkennt nun einen solchen Bestand und blendet einen einzeiligen Vorschlag ein, nxm import auszuführen (kein Rauschen, wenn keiner existiert); der Import selbst ist ein eigener, expliziter Verb. nxm import [--from <dir>] erkennt das Claude-Memory-Verzeichnis dieses Projekts automatisch oder nimmt einen expliziten Pfad; --json ist nicht-interaktiv und liefert eine deterministische Anzahl des Übernommenen.
• Neue Verben archive und unarchive bewegen Arbeit ins Archiv und zurück. archive <ids…> cascadet nach UNTEN: ein Root und sein ganzer belongs_to-Teilbaum werden gemeinsam archiviert, aber nur wenn der Root geschlossen ist und jeder Descendant geschlossen ist (ein bereits archivierter Descendant zählt als geschlossen) — ein offenes Epic mit geschlossenen Kindern muss erst geschlossen werden. unarchive <ids…> cascadet nur nach OBEN: ein Item und seine Ancestor-Kette werden wieder sichtbar, während seine Kinder und Geschwister archiviert bleiben (Sichtbarmachen ist deterministisch). Beide sind partielle Batches — atomar pro Root (ein Root, der seine Precondition verfehlt, schreibt nichts von seinem Teilbaum) und unabhängig zwischen Roots — und beide melden ein Ergebnis pro Root (archived/unarchived oder failed mit Grund: not-found, not-closed, has-open-descendants, not-archived) plus die vollständige Liste der tatsächlich bewegten Ids inklusive der cascadeten. Archivieren ist umkehrbar, weshalb ein archiviertes Item weiterhin über show auflösbar ist.
• Items tragen jetzt einen archived-Tombstone — einen nullable-Zeitstempel (der Archivierungs-Zeitpunkt), exakt wie der bestehende deleted-Tombstone mit konvergenter LWW-Semantik modelliert und als neues archived-Feld in jedem --json-Item-Record sichtbar. Archiviert heißt „geschlossen und weggeräumt": Die aufzählenden Reads (ready/blocked/next/list/search) schließen archivierte Items standardmäßig aus, aber ein explizites show <id> zeigt ein archiviertes Item weiterhin an und rendert einen ARCHIVED-Marker (anders als ein gelöschtes Item, das not_found bleibt) — denn es ist wiederherstellbar. Dies ist das Datenmodell-Fundament; die archive/unarchive-Verben und die eigene archived-Lane folgen in Anschlussarbeit. Das Workspace-Schema steigt von v1 auf v2 mit einer abwärts-lesbaren, additiven Migration (die Spalte ist nullable, ältere Binaries öffnen die Datenbank also weiter — die Kompatibilitäts-Untergrenze bleibt unverändert).
• Drei neue Read-Verben vervollständigen den Lane-Satz, sodass die Read-Verben den Live-Bestand sauber partitionieren: deferred (offene, nicht blockierte Arbeit, deren Defer-Datum noch in der Zukunft liegt — die Lane, die weder ready noch blocked ist, sortiert nach dem nächstfälligen Datum zuerst), closed (geschlossene Arbeit ohne archivierte, neueste Schließung zuerst) und archived (archivierte Items jeden Status, neueste Archivierung zuerst). Zusammen mit next und blocked garantieren sie eine saubere Partition des Live-Bestands über sechs Lanes — ready ⊎ blocked ⊎ deferred ⊎ in_progress ⊎ closed ⊎ archived — sodass ein Konsument jede Lane direkt liest, statt die engine-eigene Ableitung zu rekonstruieren. Die in_progress-Lane hat kein eigenes Verb: Sie ist die rohe status=in_progress-Menge, gelesen via list --status in_progress (next --include-in-progress ist eine Workflow-Sicht, die nur die *handlungsfähige* in-progress-Teilmenge neben ready zeigt, nicht die ganze Lane). Jedes Lane-Verb respektiert den --sort-Override der Ordering-Achse. Das Schließen eines Items hält jetzt zusätzlich einen closed_at-Zeitpunkt fest (ein neues Feld in jedem --json-Item-Record, neben archived), damit die closed-Lane nach Schließdatum sortieren kann; das Wiederöffnen (claim oder ein Status-Wechsel weg von closed) löscht ihn wieder, sodass das Feld genau dann gesetzt ist, wenn ein Item geschlossen ist. Das Workspace-Schema steigt von v2 auf v3 mit derselben abwärts-lesbaren, additiven Migration (die Spalte ist nullable, ältere Binaries öffnen die Datenbank also weiter).
• Sortierung ist jetzt eine eigene Achse: jedes aufzählende Read-Verb (list, next, blocked) nimmt ein optionales --sort-Override — --sort rank (die next-Ranking-Policy des aktiven Plugins) oder --sort id (lexikografisch, plugin-unabhängig). Ein unbekannter Schlüssel ist ein lauter Validierungsfehler, der die akzeptierte Menge nennt. Der Sortierer lebt in der geteilten Facade, sodass CLI und In-Process-Konsumenten dieselbe Reihenfolge sehen. Per-Verb-Defaults bleiben unverändert, wo sie schon sinnvoll waren (next rankt, list bleibt id-sortiert, damit list --json plugin-übergreifend byte-identisch bleibt); --sort wählt die andere Reihenfolge bei Bedarf.

Geändert

• nxf prime und die zugehörigen Hilfetexte geben Erst-Nutzern und Agenten jetzt mehr Kontext: prime beginnt mit einer einzeiligen Beschreibung, wofür nxf da ist und wie ready/blocked/next abgeleitet werden, sein create-Beispiel nutzt das Typ-Vokabular des aktiven Plugins (z. B. --type <epic|issue> bei issue-tracker, <list|todo> bei personal-todo) und sein dep-Eintrag macht die Abhängigkeitsrichtung explizit (A hängt von B ab, also blockt B das A). Die Hilfen zu create --type und dep wurden entsprechend präzisiert. Die --json-Ausgabe bleibt deterministisch.
• Der verwaltete nexus-flow-Block, den nxf init in AGENTS.md schreibt, ist jetzt deklarativ mit Recovery-Hinweis statt einer imperativen Anweisung. Er beschreibt, was nexus-flow ist und dass der Projektstand aus nxf prime kommt (das bei Sessionstart automatisch läuft, wenn der SessionStart-Hook via nxf setup claude eingerichtet ist), und weist den Agenten an, nxf prime nach einer Kontext-Kompaktierung erneut auszuführen, um den Stand wiederherzustellen. Eine Anweisung in einer eingecheckten Datei wird nur unzuverlässig befolgt; die deterministische Zustellung übernimmt der Hook, und dieser Block ergänzt ihn nun und deckt Hosts ohne Hook-Unterstützung ab. Das Vokabular ist generisch (projects and tasks).
• nxf show und nxf blocked erklären Blocker jetzt, statt nur ids aufzulisten. show annotiert jede Abhängigkeit mit dem Status ihres Ziels (z. B. deps: abc (closed), def (open)), sodass der offene Blocker sofort erkennbar ist; unter --json werden deps zu strukturierten Einträgen ({"id","status"}). blocked benennt jetzt die offenen Blocker jedes Eintrags inline — die menschliche Ausgabe hängt ↳ blocked by: <id> (<status>) an, und --json ergänzt je Eintrag ein blockers-Array (id + Status). Kein zusätzliches show pro Abhängigkeit mehr, nur um zu verstehen, warum etwas blockiert ist.
• Die menschlichen Listenansichten (nxf ready, nxf next, nxf list) zeigen jetzt je Eintrag den Typ in eckigen Klammern im Vokabular des aktiven Plugins an — [epic]/[issue] bei issue-tracker, [project]/[todo] bei personal-todo — sodass auf einen Blick erkennbar ist, ob eine Zeile ein Epic oder ein Issue ist. Die Spaltenreihenfolge ist plugin-bestimmt, und --json bleibt unverändert (kanonischer Core-Typ). Behoben: Das personal-todo-Plugin benennt ein project jetzt als „project“ statt fälschlich als „list“.
• nxf prime ist neu geformt, damit sich ein Agent in einem einzigen Lesen orientiert. Der erste Satz ist jetzt plugin-bestimmt („nexus-flow is a software issue tracker for epics and issues …“) statt generischer Positionierungs-Prosa, und der Ableitungssatz nennt priority und beginnt mit next. Die nackte ready-ID-Liste ist durch die echte next-Empfehlung ersetzt — die Top 7 im vollen nxf next-Format (id, priority, status, Typ, Titel), laufende Arbeit zuerst; --json liefert next als kanonische Records plus ein next_total, sodass Abschneiden nie verschwiegen wird. Der blocked-Abschnitt erklärt jetzt, *warum* ein Item blockiert ist, und macht Leverage sichtbar: jeder offene Blocker erscheint mit Status und der Anzahl der von ihm blockierten Items (↳ blocked by <id> (open, blocks 3)), höchste Leverage zuerst; --json führt strukturierte blockers mit blocks_count. Ein neuer create-Abschnitt zeigt ein vollständiges, plugin-bewusstes Beispiel mit --priority und empfiehlt, immer eine zu setzen (Items ohne Priorität landen unten in next). Die Befehlsreferenz ist nach Wichtigkeit sortiert (next vor ready), create darin nur noch ein Verweis auf seinen Abschnitt.
• nxf next zeigt jetzt auch bereits übernommene Arbeit an: aktionsfähige in_progress-Einträge erscheinen in der Empfehlung und werden über jeden noch nicht begonnenen open-Eintrag gerankt — so verliert ein Agent nie aus dem Blick, woran er gerade arbeitet. Blockierte oder in die Zukunft verschobene übernommene Arbeit bleibt ausgeschlossen, und nxf ready ist unverändert: Es zeigt weiterhin nur startbare, noch nicht übernommene Arbeit, damit nie zwei Agenten dasselbe Item als frei behandeln.
• Die Priorität ist jetzt eine benannte Variante des aktiven Plugins statt einer blanken Ganzzahl. nxf create --priority und nxf update --set priority=… erwarten ein Label (z. B. P0–P4 bei issue-tracker, now/soon/later/… bei personal-todo), das gegen die Menge des Plugins validiert wird; ein unbekannter Wert wird mit einem validation-Fehler abgelehnt, der die erlaubten Labels auflistet. Das next-Ranking respektiert die Variantenordnung des Plugins, und show/list zeigen das Label an. Der kanonische --json-Datensatz behält die plugin-unabhängige Ordnungszahl und bleibt damit über Plugins hinweg byte-identisch.
• nxf create legt jetzt ein vollständiges Item in einem einzigen Aufruf an. Titel, Beschreibung und Priorität sind verpflichtend (fehlt eines, schlägt der Aufruf laut fehl), und derselbe Aufruf kann zusätzlich das Design, die Definition of Done (--dod), einen Parent und eine oder mehrere Abhängigkeiten setzen (--depends-on <id>, wiederholbar — jede macht das neue Item von <id> abhängig, das existieren muss). Bisher waren bei der Anlage nur --parent/--priority/--due/--defer verfügbar und ein Item entstand immer ohne Body oder Beschreibung, was einen zweiten update-Aufruf erzwang. Abhängigkeitsziele und der Parent werden auf Existenz geprüft, bevor irgendetwas geschrieben wird.
• nxf update erreicht jetzt das vollständige Feldmodell. Die Langtextfelder description und design sind über --set setzbar (z. B. --set description="…"), --set parent=<id> wird jetzt auf belongs_to gemappt (dasselbe Wort wie create --parent; bisher war nur defer ein Alias und parent schlug stillschweigend fehl), und ein unbekanntes --set-Feld wird mit der aufgelisteten erlaubten Menge im Fehler abgewiesen, sodass ein Agent sich selbst korrigiert. Der body behält seinen eigenen Full-Replace-Pfad (--body/--body-file).
• nxf prime und update --help vermitteln jetzt die Stabilisierungs-Konvention: Korrigiere die Felder eines Items einmal kurz nach der Anlage (z. B. um ein Review einzuarbeiten) und halte sie danach stabil; was du während der Abarbeitung lernst, hältst du als Append-Only-Notizen fest (nxf note add) statt durch weitere Feldänderungen. Das ist vorerst eine Konvention — ein künftiges Release kann sie durch einen irreversiblen Per-Field-Lock erzwingen.
• nxf show zeigt jetzt das vollständige Feldmodell in der Sprache des aktiven Plugins, nicht nur einen Ausschnitt. Das Human-Layout besteht aus einem Kopf (<id> <priority> <titel>), den Inline-Feldern TYPE/STATUS (und PARENT/BLOCKED BY nur, wenn zutreffend) und anschließend den Abschnitten DESCRIPTION, DEFINITION OF DONE, DESIGN und NOTES — Notizen neueste zuerst. Die Abschnitts-Überschriften sind plugin-benannt: issue-tracker schreibt Description / Definition of Done / Design / Notes, personal-todo Why / Done when / Plan / Log. --json bleibt unverändert — es ist weiterhin der byte-exakte, plugin-unabhängige Maschinen-Contract und enthält ohnehin alle Felder.
• nxf close <id> verlangt jetzt einen --reason: Schließen ist der einzige Weg, auf dem ein Item das Board verlässt (kein Hard-Delete), der Grund ist daher Pflicht. Ohne Grund wird der Aufruf mit einem validation-Fehler im Standard-Error-Envelope abgewiesen (auch unter --json), und es wird nichts geschrieben. So entsteht die „so haben wir es am Ende geschlossen"-Hälfte des Paars aus Absicht und Ergebnis, aus dem man später lernt.
• `nxf prime` wird zu einem vollständigen Session-Bootstrap-Dokument im bd-Stil umgebaut — und `prime --json` spiegelt es jetzt 1:1. Die menschenlesbare Ausgabe (ohne --json) ist valides, strukturiertes Markdown: ein Titel # nexus-flow, ein Context-Recovery-Hinweis, Core Rules (angeführt von „alle Arbeit in nexus-flow führen"), die gerankte Next- und die leverage-bewusste Blocked-Sektion, eine Create-Sektion (mit der escaping-freien Langtext-Eingabe aus Epic 95d: --description -, --description-file, nxf create --json -), gruppierte Essential Commands, Common-Workflows-Rezepte, eine Sync-Sektion, die nur erscheint, wenn der Workspace an einen Stream gebunden ist (.nexusflow/sync.toml), und eine hybride Session-close-Klammer (offene Arbeit als Note festhalten, mit Grund schließen, bei aktivem Sync syncen, plus ein nicht-vorschreibender Hinweis „committen & pushen, falls versioniert" — keine von anderen Trackern kopierten git-Befehle). prime --json ist nun eine schlanke, strukturierte Sicht auf denselben Datensatz: next trägt nur noch die angezeigten Felder (id, type, status, priority, title) in kanonischer Form statt jedes Ticket-Felds — vollständige Records bleiben bei nxf next --json — und die neuen Sektionen werden als Felder gespiegelt (context_recovery, gruppierte commands, workflows, session_close; create.long_text_hint; sync nur wenn gebunden). Das ändert die Form von prime --json (die Facade read::prime / Engine::prime nehmen jetzt ein bound-Flag); nxf next/show/list --json bleiben unverändert.
• Die Workspace-config.toml hat die geteilte Plattform-Form (Spec §7) angenommen: eine generische active_modules-Liste, die das Plattform-Fundament besitzt, plus produktspezifische Config-Abschnitte. Die Plugin-Auswahl von flow liegt jetzt unter einem [flow]-Abschnitt (plugin = "..."), und flow — nicht das Fundament — besitzt den issue-tracker-Default. Bestehende Workspaces sind nicht betroffen: Ein altes plugin = "..." auf oberster Ebene wird weiterhin gelesen, es muss nichts migriert werden.
• nxf init und nxm init schreiben die geteilten Agent-Dateien und ihren eigenen pro-Werkzeug-Hook nicht mehr selbst. Sie delegieren jetzt an den einen nxs-Assembler, der AGENTS.md/CLAUDE.md aus dem Manifest jedes aktiven Moduls zusammensetzt und genau einen SessionStart-Hook → nxs prime verdrahtet — das Umbrella-Fan-out, das das prime jedes aktiven Moduls mit einer geteilten Uhr ausführt. Ein flow-only-Workspace bekommt so genau einen nxs prime-Hook, und ein anschließendes nxm init re-assembliert die Blöcke beider Module unter demselben einen Hook, statt einen zweiten nxm prime-Hook zu hinterlassen. nxf setup claude und der mitgelieferte hooks/session-start.sh-Wrapper verdrahten ebenfalls nxs prime. Beide inits erhalten einen --quiet-Modus (kein Banner/Prompt, strukturierte Ausgabe), damit die Umbrella sie treiben kann und Agenten einen nicht-interaktiven Einstieg haben. nxf prime/nxm prime existieren unverändert weiter — sie sind die Fan-out-Ziele, an die der Hook delegiert.
• Sync ist von `nxf` ins `nxs`-Umbrella umgezogen. Mit einem geteilten Op-Log pro Workspace ist Synchronisieren eine Plattform-Operation, keine flow-Modul-Operation — der Befehl heißt jetzt `nxs sync bind` / `nxs sync run`, und nxf sync wurde entfernt. Das Verhalten bleibt gleich; nur der getippte Befehl ändert sich. Skripte, die nxf sync … aufriefen, müssen auf nxs sync … umstellen.
• `nxs migrate` hebt jetzt einen vor-Umbrella-Workspace (v0.5.x) auf das v0.6.0-Modell — idempotent: Es schreibt einen alten nxf prime-SessionStart-Hook auf den einzelnen Umbrella-Hook nxs prime um und registriert flow als aktives Modul, damit nxs prime wie zuvor dorthin ausfächert. Ein bereits auf dem Umbrella laufender Workspace bleibt unangetastet, und nxs migrate setzt nie einen Hook, wo du keinen eingerichtet hast. Bestehende Workspaces aktualisieren ihren Hook beim nächsten nxs migrate.
• Das Workspace-Verzeichnis heißt jetzt .nxs/ statt .nexusflow/ — das Zuhause auf der Platte gehört der Plattform, nicht flow allein, im Vorgriff auf das geteilte nxs-Substrat.
• blocked rankt jetzt standardmäßig nach der next-Policy des aktiven Plugins, statt in id-Reihenfolge zu listen. Blockierte Arbeit ist echte Arbeit, die auf den Start wartet — also erscheint das höchstpriorisierte blockierte Item zuerst, dieselbe Ordnung, die next schon nutzt. Mit --sort id lässt sich die bisherige lexikografische Reihenfolge wiederherstellen.
• search liefert Treffer jetzt nach Lane-Priorität gruppiert statt in willkürlicher Reihenfolge. Treffer werden geordnet als next + in-progress → blocked → deferred → closed, jede Gruppe in ihrer natürlichen In-Lane-Ordnung; da die Lanes den Live-Bestand partitionieren, erscheint jeder Treffer in genau einer Gruppe ohne Duplikate. Die Selektion ist unverändert (ein Substring-Match ohne Groß-/Kleinschreibung über Titel, Beschreibung, Design, Definition-of-Done und Notizen). Archivierte Items sind standardmäßig ausgeschlossen; --include-archived hängt die archivierte Gruppe zuletzt an und --archived-only durchsucht nur das Archiv. Ein --sort-Override flacht die Gruppierung zu einer einzigen Reihenfolge ab, und --now setzt die Defer-Grenze für die Gruppierung deferred-Treffer. Das Ranking wird jetzt engine-seitig als geteilte Facade-Methode berechnet, sodass CLI und in-process-Konsumenten eine lane-ranked Implementierung teilen.
• Die Release-Notes haben jetzt einen eigenen Abschnitt Facade-Kontrakt. Ein Changelog-Fragment kann eine Änderung der öffentlichen nexus-flow-facade-API mit facade: changed oder facade: breaking kennzeichnen und einen Security-Fix mit security: true markieren; der Feed rendert diese in einem eigenen, maschinell auswertbaren Abschnitt (EN+DE), sodass ein einbettender Konsument auf einen Blick erkennt, ob ein Release ein Facade-Re-Review braucht oder auf der Patch-Spur durchgereicht werden kann. Eine facade: breaking-Änderung erscheint konstruktionsbedingt nur in einem Minor — ein Patch-Release, das eine solche trägt, wird abgewiesen.
• Die nexus-flow-CLI-Suite installiert sich jetzt als EIN einziges Binary. nxs enthält die ganze Suite, und die Befehle nxf und nxm sind schlanke Symlinks darauf — jeder funktioniert exakt wie zuvor (das Tool wird daraus erkannt, wie du es aufgerufen hast). install.sh und self-update liefern und aktualisieren dieses eine Binary und legen die nxf/nxm-Links automatisch (neu) an, sodass die Suite deutlich weniger Speicherplatz braucht und es nur noch ein Artefakt zu verifizieren, aktualisieren und vertrauen gibt. Das Verhalten und die Ausgabe aller Befehle bleiben unverändert; eine bestehende Installation wird beim nächsten self-update auf das Ein-Binary-Layout migriert.
• Das nxs-Umbrella ist jetzt die einzige Haustür für die zwei suite-weiten Verben. nxs prime ist der eine Session-Bootstrap-Befehl, den du und dein Agent ausführen: Jeder Prompt, jeder Hilfetext und die assemblierten CLAUDE.md/AGENTS.md zeigen nun dorthin statt auf das pro-Tool nxf prime/nxm prime. nxs self-update wird der kanonische, suite-weite Updater (er hat ohnehin schon die ganze Suite getauscht — das Verb passt jetzt dazu). Die pro-Tool-Befehle nxf prime, nxm prime und nxf self-update funktionieren weiterhin exakt wie zuvor, sind aber aus --help versteckt und deprecated; ein nxf self-update-Aufruf weist nun auf nxs self-update hin. An der Update- und Ein-Binary-Mechanik ändert sich nichts — nur welches Verb der beworbene Einstiegspunkt ist.
• Das Einrichten der Suite zeigt jetzt klarer, was bereits vorhanden ist und was als Nächstes zu tun ist. Ein erneuter init-Lauf in einem bestehenden Workspace erkennt die bereits aktiven Tools: Der interaktive Chooser hakt sie vor und markiert sie mit „(already set up)", die Zusammenfassung weist sie in ihrer Tool-Liste aus, und nxs init --json meldet sie in einem neuen Feld already_active — so ist ein Re-Run informativ statt ein stiller, mehrdeutiger Wiederholungslauf. Wenn du flow einrichtest (die Voreinstellung), endet der Rahmen jetzt mit einem prominenten, copy-paste-fähigen ersten Befehl zum Anlegen deines ersten Items, und die Welcome-Box trägt den kurzen Pitch jedes gewählten Tools. Die nicht-interaktive Ausgabe bleibt byte-stabil: Der --json-Datensatz erhält nur das additive Feld already_active, und Welcome-Copy sowie Erst-Befehl erscheinen ausschließlich im Menschen-Pfad.
• Wenn du die Suite interaktiv einrichtest — über nxs init, nxf init oder nxm init —, durchläuft jedes gewählte Tool jetzt seine EIGENE interaktive Konfiguration innerhalb des gemeinsamen Rahmens. Insbesondere erscheint flows Plugin-Auswahl (issue-tracker vs. personal-todo) jetzt auch über den Umbrella-Pfad, nicht nur beim direkten nxf init; die dort getroffene Wahl landet wie erwartet in der Workspace-Konfiguration. Intern komponiert das Umbrella die Module nun in-process statt stille Subprozesse zu treiben, sodass ein Setup-Fehler eines Moduls (etwa flow, das die Initialisierung in einem bestehenden Workspace verweigert) jetzt direkt und deutlich auftaucht statt als verpackter Subprozess-Fehler. Nicht-interaktive Läufe (--json, Pipe, CI) bleiben unverändert und prompt-frei.
• nxf init oder nxm init auf einem Terminal landen jetzt auf demselben nxs init-Suite-Chooser wie nxs init selbst — eine einheitliche Eingangstür — mit dem Tool vorausgewählt, über das man eingestiegen ist: nxf init startet mit angehaktem flow, nxm init mit memory, und man kann die anderen vor dem Bestätigen dazunehmen oder abwählen. Die Eingangs-Binaries re-exec'en das geteilte nxs-Umbrella (das das Terminal erbt), sodass es keinen separaten flow-eigenen Init-Screen mehr gibt. Nicht-interaktive Nutzung bleibt unverändert flag-gesteuert: --json, Pipe- und CI-Läufe von nxf init/nxm init behalten ihre bestehende modul-native, byte-stabile Ausgabe, und das neue Flag nxs init --preselect <tool> hakt ein Tool im Chooser vor (bzw. wählt es nicht-interaktiv direkt aus).

Behoben

• nxf update <id> --set parent=<id> (Alias für belongs_to) weist jetzt einen nicht existierenden Parent mit einem not_found-Fehler ab und schreibt nichts — wie nxf create --parent. Bisher wurde ein hängender struktureller Parent akzeptiert und erst später von nxf validate bemängelt; beide Befehle erzwingen die Existenzprüfung nun gleich vorab, bevor irgendeine Operation geschrieben wird. Ein Item, das sich selbst als Parent angibt, wird ebenfalls abgewiesen (ein validation-Fehler) — analog zur Selbstkanten-Sperre bei dep add.
• nxf create --parent <id> und nxf update <id> --set parent=<id> (Alias für belongs_to) weisen jetzt einen Parent ab, der kein Projekt ist, mit einem validation-Fehler, bevor irgendeine Operation geschrieben wird. Bisher wurde ein Parent, der auf eine Aufgabe (ein Plugin-„Issue") zeigt, akzeptiert und erst später von nxf validate bemängelt (die Invariante belongs_to_not_project); beide Befehle erzwingen die Projekt-Typprüfung nun vorab — analog zu den bestehenden Prüfungen auf fehlende und getilgte Parents. Die Invariante bleibt der Backstop zur Konvergenzzeit für einen verletzenden Zustand, der nur per Sync entstehen kann.
• Multi-Device-Sync zeigt jetzt die Änderungen eines Peers in lokalen Reads. Ein nxs sync-Pull bewegt den gesamten geteilten Op-Log, aber ein foundation-only Pull landet die Ops eines anderen Produkts (z. B. die Memories eines Peers oder Tasks) im Log, ohne sie in dessen materialisierte Views zu falten — sodass nxm/nxf-Reads auf dem empfangenden Gerät das gerade Gepullte verpassen konnten. Jeder Produkt-Store trägt nun eine pro-Store-Folded-Through-Wasserlinie (die höchste Op-Log-Zeile, die er gefaltet hat) und faltet beim Öffnen den Log einmal in seine Views neu, sobald der Log über diese Wasserlinie hinaus gewachsen ist — andernfalls bleiben Reads auf der reinen View (kein unnötiger Rebuild). Das Neufalten ist reihenfolge-unabhängig und idempotent (keep-if-beats-LWW + observed-remove), abgesichert durch das Differential-Oracle, sodass ein View-Refresh den konvergierten Wert nie verändern kann. Der geteilte Op-Log selbst wird nie beschnitten — er bleibt die geräteübergreifende Konvergenz-Wahrheit.

Entfernt

• Das generische Item-Feld body wurde entfernt — es ist durch das strukturierte Feldmodell vollständig ersetzt (description = Warum + Ziel, design = Weg zum Ziel, completion_criterion = Definition of Done, plus Append-only-Notizen). Die Flags --body/--body-file sind aus nxf update verschwunden, und der Schlüssel body taucht nicht mehr im kanonischen --json-Datensatz auf. nxf search durchsucht jetzt Titel + Beschreibung + Design + Definition of Done + Notizen. Kein Migrationspfad (keine Live-Daten): .nexusflow löschen und neu initialisieren.
• Der Befehl ready entfällt — er geht in next auf. next *ist* jetzt die Ready-Menge (offen, unblockiert, nicht zurückgestellt), gerankt nach der next-Policy des aktiven Plugins, und das neue Flag next --include-in-progress zeigt zusätzlich aktionierbare in Bearbeitung befindliche (in-progress) Arbeit, vor der Ready-Menge gerankt. Das ist ein harter Schnitt, kein deprecated Alias: nxf ready bricht mit einem lauten Fehler ab, der auf nxf next (und nxf next --include-in-progress) verweist. nxf prime nutzt jetzt next --include-in-progress für seinen Snapshot. Ein Board liest next --include-in-progress einmal und teilt die Spalten Ready/In-Progress am rohen, gespeicherten status-Feld auf.

Neu

• Die nexus-flow-Engine — ein offline-first, konvergenter Speicher für Projekte und Aufgaben. Projekte/Epics und Tasks, Abhängigkeiten zwischen beliebigen davon, belongs-to- und contributes-to-Beziehungen, Fällig-/Aufschub-Daten sowie vollständige Historie mit Abschlusskommentaren. ready, blocked und next werden deterministisch aus dem Graphen abgeleitet statt gespeichert und sind damit immer konsistent. Basiert auf einem append-only Op-Log-CRDT: gleichzeitige Änderungen verschiedener Replikate konvergieren unabhängig von der Reihenfolge (idempotent, observed-remove), Zyklen werden zum Schreibzeitpunkt abgelehnt.
• nxf, die agent-native CLI: init, create, update, claim, close, show, list, search, ready, blocked, next (mit deklarativer Ranking-Policy), dep add/remove, Markdown-Body-Bearbeitung, note add/list und prime, um den Arbeitskontext eines Agenten zu laden (optionaler SessionStart-Hook). Jeder Befehl unterstützt --json mit strukturiertem Fehler-Envelope für deterministische, agent-freundliche Ausgabe, und Tasks erhalten kurze, lesbare IDs (4+4 Crockford-base32). Eine Plugin-Config bildet das Vokabular auf deine Domäne ab und bringt Presets für Issue-Tracker und persönliche To-dos mit.
• Offline-first-Sync: vollständig offline arbeiten, dann gleicht nxf sync Replikate über nxf-relay ab — einen kleinen, selbst hostbaren Server mit SQLite- oder Postgres-Backend. Konvergenz gilt unabhängig von Reihenfolge oder Verbindung, und Short-ID-Präfixe bleiben über Replikate hinweg eindeutig.
• Signierte Multi-Plattform-Releases. Jedes Release wird für macOS (Apple Silicon und Intel) und Linux (x86_64 und ARM64, statisch) gebaut und kryptografisch signiert; der Signierschlüssel verlässt nie unsere Release-Secrets. nxf self-update prüft diese Signatur bei jedem Update mit einem in `nxf` eingebauten Verifizierer — kein externes Tool nötig — und verweigert alles, dessen Echtheit es nicht beweisen kann. Releases laufen über zwei Kanäle, zwischen denen du wählst: stable (Standard) und beta (das kommende Release, später aus genau denselben signierten Bytes nach stable befördert — nie neu gebaut).
• Ein-Zeilen-Installation: curl -fsSL https://nxf.nxsflow.com/install.sh | sh installiert das nxf-CLI ohne sudo. Es erkennt die Plattform per uname, ermittelt den neuesten Tarball über /latest (oder ein gepinntes NXF_VERSION) und verifiziert immer dessen sha256 (verpflichtend; bei Abweichung bricht es ab, bevor irgendetwas geschrieben wird). Für die Authentizität prüft es die Release-Signatur, wann immer es kann: mit dem Kommandozeilen-Tool minisign, falls vorhanden, sonst mit einem fähigen `openssl` (jedes Linux sowie macOS mit Homebrew-openssl) — die Friktion liegt also am *Binary*, nicht an der Krypto. Nur ein Host mit keinem von beiden (insbesondere Stock-macOS, dessen System-openssl LibreSSL ist und weder Ed25519 noch BLAKE2b mitbringt) bricht fail-closed ab, statt unverifiziert fortzufahren — minisign installieren (auf macOS: brew install minisign) und erneut ausführen, oder mit NXF_INSECURE=1 den Bootstrap bewusst allein auf der geprüften sha256 durchführen. So oder so ist die Lücke auf die Erstinstallation begrenzt: jedes spätere nxf self-update verifiziert die Signatur bedingungslos mit dem in nxf eingebauten Verifizierer. Installiert wird nach ~/.local/bin (per NXF_INSTALL_DIR änderbar), idempotent, optional zusätzlich nxf-relay (NXF_INSTALL_RELAY=1), und ein fehlender PATH-Eintrag wird angezeigt; Channel und Origin sind überschreibbar (NXF_CHANNEL, NXF_BASE_URL).
• nxf self-update aktualisiert die CLI an Ort und Stelle aus deinem Release-Channel. Bevor das laufende Binary atomar getauscht wird, prüft es jeden Download zweifach: sha256 für die Integrität und die Release-Signatur für die Authentizität — verifiziert von einem in `nxf` eingebauten Verifizierer gegen einen ins Binary einkompilierten Public Key, ganz ohne externes Tool. Die Prüfung ist bedingungslos und fail-closed: ein unsigniertes, manipuliertes oder herkunftsfremdes Build wird abgelehnt, nie stillschweigend auf eine reine Integritätsprüfung heruntergestuft, und ein Update führt nie auf eine ältere Version zurück. --check meldet nur, ob ein Update vorliegt, ohne zu installieren; --channel stable|beta|alpha wählt (und merkt sich) den Ring. Ein dezenter Hinweis einmal täglich auf stderr weist auf eine neuere Version hin — nie in der --json-Ausgabe, nie in CI oder bei nicht-interaktiver Nutzung und per NXF_NO_UPDATE_CHECK=1 abschaltbar.
• nxf guide [topic] zeigt eingebettete, offline verfügbare Anleitungen (getting-started, core-concepts, commands, plugins, migration); ohne Thema werden sie aufgelistet, und --json liefert Agenten eine deterministische Themenliste oder das rohe Markdown eines Themas.

Geändert

• nxf init verlangt jetzt eine bewusste Plugin-Wahl statt eines stillen Standards: im Terminal erscheint eine beschriebene Auswahl, nicht-interaktiv (--json/Pipe) ist --plugin erforderlich und die verfügbaren Plugins werden mit Beschreibungen aufgelistet. Nach dem Init werden Präfix, gewähltes Plugin und nächste Schritte ausgegeben (auch unter --json), und der Workspace ignoriert sich selbst über .nexusflow/.gitignore, sodass db.sqlite und die Replica-Identität nie eingecheckt werden.
• nxf gibt menschenlesbare Ausgaben (und Fehlermeldungen) jetzt mit einer Leerzeile davor und danach aus, damit Ergebnisse sich klar abheben statt direkt am Prompt zu kleben. Die Maschinenausgabe (--json) bleibt unverändert und byte-genau für Skripte und Agenten.