Erste Schritte

flow — was zu tun ist

Der Issue-Tracker der Suite: Items, die Abhängigkeiten zwischen ihnen, Fälligkeits- und Aufschubdaten, ein append-only Notizstrom und der Grund, aus dem ein Item geschlossen wurde. Das ist die Aufzeichnung dessen, was ein Projekt tut — und warum.

Eine Eigenschaft unterscheidet ihn von einer Ticket-Liste, und sie gehört vor alles andere: die Arbeitsliste wird abgeleitet, nicht gespeichert. nxf next und nxf blocked werden in dem Moment, in dem du fragst, aus dem Abhängigkeitsgraphen berechnet; sie können deshalb weder veralten noch ihm widersprechen. Niemand setzt ein Item auf machbar — das Schließen seiner letzten Vorbedingung macht es dazu.

Das prägt den ersten Schritt. Er lautet nicht „schreib eine Aufgabe", sondern halte fest, was es gibt und worauf es wartet:

nxf create --type feature --title "Release 1.0 ausliefern" --priority P1
nxf dep add <item> <vorbedingung>
nxf next

Was ein Item ist, kommt aus einem Plugin: die Typen, die du anlegen darfst, das Vokabular, das du liest und schreibst, und die Rangfolge hinter next. Die Wahl fällt einmal je Arbeitsbereich, weil sie alles prägt, was du danach tippst — mitgeliefert werden ein Issue-Tracker für Code-Projekte und eine persönliche To-do-Liste, beide über derselben Engine.

Jeder Befehl antwortet auf --json mit byte-stabiler Ausgabe, und das ist die Fläche, auf der Agenten bauen: ein Agent kann das ganze Brett bedienen, ohne dass vorher ein Mensch eine Tabelle liest.

Wohin von hier

• Erste Schritte — vom leeren Verzeichnis zu einem geplanten, verfolgten Stück Arbeit.
• Kernkonzepte — Items, Abhängigkeiten, und wie die beiden Spuren abgeleitet statt gespeichert werden.
• Aufschieben und warten — die eine Unterscheidung, die leicht schiefgeht: ein echtes Kalenderdatum gegenüber dem Warten auf etwas, das erst geliefert werden muss.

memory — was das Projekt weiß

Durable Tatsachen, die die Sitzung überleben, in der sie gelernt wurden: eine Konvention, eine Falle, der Grund, aus dem eine Entscheidung so ausging. nxm remember schreibt eine, nxm recall <key> liest sie vollständig zurück, und ein stabiler Schlüssel lässt eine Tatsache an Ort und Stelle korrigieren, statt widersprüchliche Kopien von ihr anzuhäufen.

Der Zweck ist nicht Ablage, sondern Wiedervorlage. Erinnerungen werden zu Beginn jeder Sitzung zurückgegeben, damit der nächste Agent schon weiß, was der letzte gelernt hat. Nichts daran ist ein Suchproblem: kein Modell auf dem Schreibpfad, keine Embeddings, kein Ähnlichkeitsranking — derselbe Speicher antwortet heute wie in sechs Monaten gleich.

Der erste Schritt ist eine Zeile, und die Disziplin, die damit beginnt, ist eine harte Regel, die das Sitzungsbanner wiederholt: durables Projektwissen geht in nxm remember und nirgendwo sonst. Ein MEMORY.md oder eine andere zu diesem Zweck erfundene Datei wird nie zurückgelesen — das Wissen darin ist still verloren.

nxm remember "Die vier cargo-Tore laufen in CI, nicht lokal" --key gates
nxm memories                  # das Verzeichnis — eine Zeile je Erinnerung
nxm recall gates              # eine Erinnerung, vollständig

Was dabei ankommt, ist dieses Verzeichnis, nicht die Erinnerungen selbst: je eine Zeile, die sagt, was die Erinnerung sagt. Deshalb lohnt es sich, sie sorgfältig zu schreiben — niemand schlägt eine Regel nach, bevor er sie bricht, also muss die Verzeichniszeile sie aussprechen.

Wohin von hier

• Erste Schritte — was memory braucht, bevor es laufen kann, und deine erste gemerkte Tatsache.
• Kernkonzepte — Schlüssel und Auto-Schlüssel, die drei Register, die Abrufregel und der Grabstein.
• Agenten und MCP — die memory_*-Werkzeuge, die ein MCP-Host bekommt, und wohin ein Agent schreibt.

chat — wie Agenten sich abstimmen

Der Kanal zwischen den Agenten eines Arbeitsbereichs. nxc send --to <handle> beginnt etwas, nxc reply --thread <id> antwortet darauf, und --escalate ist die Art, wie ein Agent ich kann nicht sagt, statt zu raten.

chat ist ein Substrat, keine Chat-App, und dieser Unterschied ist der ganze Grund, warum es existiert. Eine Nachricht ist nicht unterwegs: sie ist eine Zeile in demselben Speicher des Arbeitsbereichs, in den auch flow und memory schreiben — also durable, mit allem anderen synchronisiert und wiedervorgelegt statt erinnert. Kein Daemon, den man laufen lassen muss, kein Server, auf den man zeigt. Das ist auch die Regel, die Agenten zum Sitzungsstart bekommen: stimmt euch niemals über Kritzeldateien oder Ad-hoc-Notizen ab — die werden nicht zugestellt, nicht synchronisiert und nie wiedervorgelegt.

Wer angesprochen werden darf und wie eine Gruppe von Agenten vorgeht, wird deklariert, nicht konfiguriert. Eine Persona-Datei je Agent unter .nxs-personas/ gibt ihm eine Identität, seine Prompt-Schichten, ein Modellband, seine Werkzeuge und die Liste derer, die ihn ansprechen dürfen; ein Kanal deklariert eine Gruppe — und ein geordneter (flow: sequential) ist der Arbeitsablauf, nicht seine Beschreibung.

nxc send --to <handle> "<was zu tun ist>"     # eine Thread-Id kommt zurück
nxc reply --thread <id> "<die Antwort>"

Weil Agenten unbeaufsichtigt laufen, gehören die Grenzen zum Entwurf und sind kein Nachgedanke: eine Hop-Obergrenze, damit ein Gespräch nicht ewig kreist, ein menschliches Tor vor dem, was ein Agent nicht entscheidet, und eine Reservierung auf der Arbeitskopie, damit nicht zwei Agenten gleichzeitig in einem Checkout arbeiten.

Wohin von hier

• Erste Schritte — eine Persona deklarieren und die erste Antwort bekommen.
• Personas und Kanäle — die beiden Deklarationen und der geordnete Kanal, der einen Ablauf trägt.
• Grenzen und Sicherheit — die Hop-Obergrenze, das menschliche Tor und was ein Agent nicht entscheidet.

Darauf bauen, oder mitbauen

Alles bis hierher beantwortet wie benutze ich das. Dieser Teil beantwortet wie ist es gebaut, und worauf darf ich bauen — und dafür stehen zwei Türen offen.

Darauf bauen. nexus-flow ist zuerst eine Bibliothek. Eine Anwendung bindet nexus-flow-facade ein, hält eine Engine und liest genau die Spuren, die auch die CLI liest — im selben Prozess, ohne Unterprozess und ohne Daemon dazwischen. Das überlässt das Repository nicht der Prosa: examples/tauri-board/ ist eine kleine, echte Desktop-Anwendung, die genau das tut, in etwa 120 Zeilen Rust und einer HTML-Datei. Ihr Fenster listet die Arbeit und zeichnet sich von selbst neu, sobald irgendetwas anderes in denselben Arbeitsbereich schreibt — weil sie den Änderungsstrom der Engine abonniert, statt ihn abzufragen. Wer hier ist, um eine eigene Oberfläche daraufzusetzen, nimmt dieses Beispiel als kürzesten Weg hinein.

Mitbauen. Das Projekt nimmt Beiträge an. Die Engine, die CLIs, die Anleitungen, die du gerade liest, und die Tests, die sie ehrlich halten, liegen in einem Cargo-Workspace, und die ganze Qualitätslatte sind vier Befehle, die du auf deiner eigenen Maschine fahren kannst — die nächste Seite zählt sie auf und sagt, welchen davon CI wann fährt. Die Nähte sind beschrieben statt geraten — dafür sind die Seiten unten da.

Beide Türen teilen sich den ersten Schritt: die Quellen holen, bauen, und etwas laufen lassen. Erste Schritte ist dieser Schritt, für beide Fälle.

Wohin von hier

• Erste Schritte — die Quellen auf deiner Maschine, die Tore und die Beispiel-Anwendung.
• Architektur — die Landkarte: fünf Schichten, wohin die Pfeile zeigen, und welche Nähte Verträge sind.
• Die Reise einer Operation — ein nxf close, verfolgt vom Verb bis zu einer abgeleiteten Antwort, die niemand geschrieben hat — und danach dieselbe Fahrt über zwei Maschinen.