nxsflow

Die nxs Open-Source-Suite

Der Datenstand, aus dem deine Agenten arbeiten.

Ein Binary, drei Produkte — flow, memory und chat — auf einem einzigen offline-first CRDT-Substrat. Agenten-nativ, deterministisch, konvergent.

$ curl -fsSL https://nxsflow.com/nxs/install.sh | sh
macOS & Linux · Apple Silicon und x86-64 · signierte, same-origin Updatesnxsflow/nexus-flow

In Aktion

next und blocked — abgeleitet, nicht gespeichert

nxf — Agent-Session
$ nxf next
0001  P1  open  [epic]  Payments revamp
0002  P1  open  [feature]  Design new checkout flow
    ↳ 0001 · Payments revamp

$ nxf blocked
0003  P2  open  [chore]  Migrate billing webhooks
    ↳ blocked by: 0002 (open)

$ nxf next --json[{"archived":null,"assignee":null,"belongs_to":null,"closed_at":null,"closing_comment":null,"completion_criterion":null,"created_at":"2026-06-23T00:00:00Z","defer_until":null,"deleted":null,"description":"Rework the payments stack for v2.","design":null,"due":null,"id":"ab12.0001","parent":null,"priority":"1","priority_label":"P1","status":"open","title":"Payments revamp","type":"epic","type_label":"epic","updated_at":"2026-06-23T00:00:00Z"},{"archived":null,"assignee":null,"belongs_to":"ab12.0001","closed_at":null,"closing_comment":null,"completion_criterion":null,"created_at":"2026-06-23T00:00:00Z","defer_until":null,"deleted":null,"description":"One-page checkout with saved cards.","design":null,"due":null,"id":"ab12.0002","parent":{"id":"ab12.0001","title":"Payments revamp","type":"epic","type_label":"epic"},"priority":"1","priority_label":"P1","status":"open","title":"Design new checkout flow","type":"feature","type_label":"feature","updated_at":"2026-06-23T00:00:00Z"}]
$ 

Echte, in CI drift-gesicherte nxf-Ausgabe: die bereite Arbeit, die vom Graphen zurückgehaltene Arbeit und dieselbe Abfrage als --json.

Warum so gebaut

Eine Engine, der Agenten vertrauen

01

Offline-first von Haus aus

Alles liegt in einer lokalen Datenbank — Lesen und Schreiben sind sofort und funktionieren weiter, wenn das Netz weg ist.

02

Konvergente CRDT-Sync

Jede Änderung wird an ein Change-Log angehängt, nie überschrieben. Gleichzeitige Edits verschiedener Geräte verschmelzen ohne Last-Write-Wins-Datenverlust.

03

Abgeleitet, nie gespeichert

ready, blocked und next werden deterministisch aus dem Abhängigkeitsgraphen berechnet — die Arbeitsliste ist immer konsistent, nie ein veralteter Cache.

04

Plugin-deklariertes Vokabular

Item-Typen, Ranking und Präsentation leben in Plugins — ein Issue-Tracker und eine persönliche To-do-Liste sind dabei; eigene lassen sich deklarieren.

05

Überall --json

Eine deterministische, byte-stabile Maschinen-Schnittstelle auf jedem Befehl — der Vertrag, auf dem Agenten bauen, und der Maßstab der ganzen CLI.

06

Ein Binary, ein Substrat

flow, memory und chat teilen eine lokale Datenbank, eine Sync und ein Change-Log — Plan, Gedächtnis und Nachrichten eines Agenten konvergieren zu einer Wahrheit.

Changelog

Neu

0.27.0

2026-07-14
  • 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.
  • HinzugefügtWeitere `--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.

0.26.0

2026-07-13
  • BehobenWird 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.
  • Hinzugefügt`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ändertDie 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.

0.25.1

2026-07-13
  • HinzugefügtPlugins 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).
  • BehobenNachbesserungen 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.

0.24.2

2026-07-12
  • BehobenDas 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.
  • BehobenDer 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.
  • BehobenDie 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`).

0.24.1

2026-07-12
  • HinzugefügtEinen 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.
  • Hinzugefügtnexus-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.
  • BehobenChat-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.

Im Einsatz

Powered by nexus-flow

Zwei Produkte bündeln die Suite unsichtbar und setzen ihre eigene Oberfläche darauf.

Loslegen

Suite installieren

Ein Artefakt zum Installieren, Verifizieren und Aktualisieren — signiert und same-origin. Erkennt deine Plattform und legt nxs (mit nxf/nxm/nxc) in deinen PATH.

Neuestes Release herunterladenmacOS (Apple Silicon) · macOS (Intel) · Linux (x86-64) · Linux (aarch64)