nxsflow
ende
Alle Anleitungen
chat (nxc)

Befehle

Die vollständige Oberfläche von nxc: vierzehn Befehle, in der Reihenfolge, in der eine Sitzung üblicherweise nach ihnen greift. nxc <befehl> --help liefert die generierte Referenz (Flags, Typen, Vorgabewerte); diese Anleitung ergänzt die Erzählung und die --json-Formen. Zwei Flags sind global — --json an jedem Befehl, und --db <pfad> (auch NXC_DB), um eine Workspace-Datenbank direkt anzugeben, statt .nxs/ vom Arbeitsverzeichnis aus zu suchen.

Die Oberfläche ist absichtlich klein. Es gibt genau zwei Arten, etwas zu sagen — send beginnt ein Gespräch, reply antwortet darin — dazu withdraw, das eine Beauftragung zurücknimmt, bevor sie startet, und release, das die Arbeitskopie weitergibt, wenn die Kette, die sie hält, vorbei ist. Alles andere liest. Wenn Sie ein Verb suchen, das einen Kanal anlegt, einen Agenten registriert oder einen Workflow-Schritt weiterschaltet, siehe Was bewusst fehlt am Ende.

Einrichten

nxc init

Aktiviert chat im aktuellen Verzeichnis: stellt einen .nxs/-Workspace sicher, registriert das Modul chat und übergibt dann die gemeinsame Agentendatei und die SessionStart-Hooks dem nxs-Assembler, der sie für jedes aktive Modul neu zusammensetzt.

nxc init                 # für Menschen, mit Banner
nxc init --json          # die maschinenlesbare Quittung

--quiet ist stiller Erfolg — es gibt gar nichts aus, und genau das macht es steuerbar:

$ nxc init --quiet

nxc agent-manifest

Was chat als seinen Beitrag zur gemeinsamen Agentendatei deklariert — den prime-Befehl und den Hook — als Daten statt als Prosa:

$ nxc agent-manifest
nexus-chat agent manifest
  prime command:  nxc prime
  hook:           SessionStart → nxc prime

Run with --json for the machine contract the `nxs` umbrella assembles from.

--json ist dieser Kontrakt; das Dach liest ihn von allen drei Bausteinen und setzt eine AGENTS.md und einen Hook zusammen, sodass das Aktivieren eines zweiten Moduls den Block des ersten nie überschreibt.

Wer hier ist

nxc list

Das Verzeichnis: wer in diesem Workspace ansprechbar ist und wofür. Es ist eine Lesung über .nxs-personas/ und nichts sonst, zeigt also genau das, was deklariert ist.

$ NXC_ACTOR=alice nxc list
## Who you can address

Address any of them the same way: `nxc send --to <handle> "<your message>"`.

**Coder** (handle: `coder`) — Implements a work order on a branch and merges it.

**Build-And-Ship** (handle: `build-and-ship`, members: coder, review) — the declared order a work order runs through

**Review** (handle: `review`, members: general, integrity) — the review quorum — one round asks both reviewers and hands back one verdict

Ohne --persona sieht ein Mensch das ganze deklarierte Team, während eine Persona, die unter ihrer eigenen Sitzung läuft, ihr eigenes Adressbuch sieht — erkannt an eben dieser Sitzung. --persona <handle> projiziert die Sicht dieser Persona, gleich wer fragt — nützlich, um vor dem Start zu prüfen, was ein Agent tatsächlich sehen wird.

--json trägt personas (handle, job_title, job_description, direct), channels (name, members, description), ein Feld public_channels mit den sichtbaren Vordertüren (weggelassen, wenn es keine gibt, und aus der menschlichen Darstellung bewusst herausgehalten — eine Tür, die hier keine Deklaration benennt, ist auffindbar, nicht ansprechbar) sowie einen Block declarations, der den gelesenen Ordner und die Zahl der Dateien darin nennt. Dieser letzte Block ist der, den man prüft, wenn die Liste leerer ist als erwartet.

Etwas sagen

nxc send --to <persona|kanal> <BODY>

Ein Gespräch eröffnen. --to ist Pflicht, und sein Ziel muss deklariert sein: ein Persona-Handle oder ein Kanalname aus .nxs-personas/. Die Deklaration entscheidet, was als Nächstes passiert — eine Persona wird auf einer frischen Sitzung gestartet, ein Kanal fächert nach seiner eigenen Politik auf — und der Aufruf gibt in beiden Fällen die Faden-ID zurück.

$ NXC_ACTOR=alice nxc send --to coder --ref nxf_ids=ab12.0007 "Add a --since flag to the export command."
opened thread m-00000000000000000000000001 in dm:9445dbc93dfdad401585c42b — reply with `nxc reply --thread m-00000000000000000000000001 "…"`

Flags:

  • --ref k=v (wiederholbar) — worum es in diesem Gespräch geht: nxf_ids (ein flow-Item; wiederholbar, weil eine erste Nachricht mehrere benennen kann), branch, pr, session_id.
  • --no-ref — die ausdrückliche Antwort, dass es wirklich keinen Gegenstand gibt. „Ich habe nachgesehen" zu sagen, wo Schweigen nichts sagt.
  • --stream — dem Faden und den Verläufen der Personas zusehen, bis jemand antwortet, statt sofort zurückzukehren. Für einen Menschen an der Tastatur; innerhalb einer laufenden Persona abgelehnt.

Weder --ref noch --no-ref zu nennen sendet trotzdem und warnt — als Zeile auf stderr für einen Leser und als Feld refs_warning für eine App, damit der Hinweis nicht zwischen beiden verloren geht:

$ NXC_ACTOR=alice nxc send --to coder "One more thing." --json
{"thread_id":"m-00000000000000000000000002","message_id":"m-00000000000000000000000003","to":"coder","target":"persona","channel":"dm:9445dbc93dfdad401585c42b","session":"m-00000000000000000000000002","expects":["ab12/coder"],"spawned":true,"warnings":[],"refs_warning":"nothing was named as the subject of this conversation. Say what it is about — `--ref nxf_ids=<id>`, repeatable — or `--no-ref` if there really is nothing."}
warning: nothing was named as the subject of this conversation. Say what it is about — `--ref nxf_ids=<id>`, repeatable — or `--no-ref` if there really is nothing.

An einen Kanal zu senden liefert dieselbe Quittung mit target: "channel", der ID des deklarierten Kanals (decl:<name>) und dem Betreuer des Kanals als erwartetem Antwortenden:

$ NXC_ACTOR=alice nxc send --to build-and-ship --ref nxf_ids=ab12.0008 "Ship the export change." --json
{"thread_id":"m-00000000000000000000000003","message_id":"m-00000000000000000000000004","to":"build-and-ship","target":"channel","channel":"decl:build-and-ship","expects":["ab12/__channel__"],"spawned":true,"warnings":[],"refs_warning":null}

Die Felder der Quittung, in der Reihenfolge, in der sie ausgegeben werden: thread_id, message_id, to, target (persona oder channel), channel, session (die interne Sitzungs-ID, wenn eine Persona gestartet wurde), queued_behind / queue_position (nur vorhanden, wenn der Anstoß hinter einer Arbeitskopie-Reservierung geparkt ist), expects, deadline (wenn der Kanal ein timeout: deklariert), spawned, warnings, refs_warning. warnings und refs_warning sind immer vorhanden — auch leer und auch null —, damit ein Leser nie „kein Schlüssel" von „nichts zu melden" unterscheiden muss.

Ein Ziel, das keine Deklaration benennt, wird abgelehnt, und die Ablehnung sagt, wo gesucht wurde:

$ NXC_ACTOR=alice nxc send --to nobody --ref nxf_ids=ab12.0008 "Anyone there?" --json
? 1
{"error":{"kind":"not_found","msg":"no such target: nobody (not a declared channel, not a declared persona, not a channel in this workspace) — `nxc list` shows what can be addressed"}}

Ebenso eine Persona, die erklärt hat, nur über einen Kanal erreichbar zu sein — und zwar für alle gleichermaßen, Mensch oder Agent, benannt oder anonym:

$ NXC_ACTOR=alice nxc send --to general --ref nxf_ids=ab12.0008 "Have a look?" --json
? 1
{"error":{"kind":"validation","msg":"general is addressable only through review — send --to review instead"}}

nxc reply --thread <FADEN> <BODY>

In einem Faden antworten. --thread ist Pflicht: eine Faden-ID benennt ein Gespräch für sich, ohne Kanalkontext, und die Antwort wird an den zurückgeleitet, der auf der anderen Seite steht.

$ NXC_ACTOR=coder nxc reply --thread m-00000000000000000000000001 "Added the flag and a test; branch feat/export-since." --json
{"posted":true,"message_id":"m-00000000000000000000000002","thread_id":"m-00000000000000000000000001","resumed":false,"warnings":[]}

resumed ist nur dann true, wenn die Antwort die eigene Rückadress-Sitzung des Ziels geweckt hat — der direkte Eins-zu-eins-Weg. false deckt zwei verschiedene Dinge ab (es gab keine Sitzung zum Wiederaufnehmen, oder es gab eine und die Wiederaufnahme kam nicht an), und wake_skipped daneben trennt sie. Das Wecken beim Abschluss einer Quorum-Tafel ist in diesem Sinn keine Wiederaufnahme und setzt es nie. posted ist nur im No-Op von --if-unanswered unten false.

  • --escalate — „das kann ich nicht ausführen." Eines von drei Dingen, die ein Agent mit reply sagen darf; die anderen sind „ich bin fertig" (eine blanke Antwort) und --needs-rework weiter unten. Es ist ein deklariertes Signal, und genau das macht es brauchbar: der Betreuer eines Kanals verzweigt an einem Bit, dessen Bedeutung aufgeschrieben ist, nicht an einer Formulierung, die er deuten müsste. Der Zug ist so oder so eingelöst — verschieden ist das Ergebnis.

    An einem geordneten Kanal ist das Ergebnis, dass die Kette endet. Der Schritt nach Ihrem wird nicht gestartet, die Runde geht so nach oben, wie sie ist, und wer sie beauftragt hat, entscheidet. Genau dafür gibt es die Marke: eine Aufgabe, die nicht ausgeführt werden konnte, darf nicht die Arbeit beauftragen, die auf sie folgen sollte.

    Es ist kein Weg, „noch nicht" zu sagen. Dafür gibt es an reply keine Schreibweise — jede seiner Antworten beendet den Zug, und ein Aufrufer liest diese als Arbeit, die nicht kommen wird. Hat Ihr Schritt eine eigene Runde beauftragt und wartet auf sie, dann warten Sie: antworten Sie, wenn deren Ergebnis vorliegt.

  • --needs-rework — „was du mir übergeben hast, genügt nicht." Die dritte Antwort, und die einzige über fremde Arbeit statt über die eigene. Nennen Sie im Rumpf, was in Ordnung zu bringen ist: diese Worte werden an die Stelle gereicht, die die Arbeit erzeugt hat, und sie sind deren nächste Aufgabe.

    Angeboten wird es nur, wo der Kanal einen Weg dafür erklärt (steps: → on_needs_rework:) — genau das macht es zu einem Signal und nicht zu einem erfundenen Token. Ein Schritt ohne diese Kante erfährt von zwei Ausgängen, nicht von dreien; dort gesetzt fällt das Bit weg, mit einer Warnung verdict_dropped auf der Quittung der Antwort. Mit --escalate zusammen ist es nicht erlaubt: die beiden sind Aussagen über verschiedene Arbeit mit entgegengesetzten Folgen. Siehe nxc guide channels.

  • --if-unanswered — nur posten, wenn der Aufrufer auf diesem Faden noch eine Antwort schuldet; sonst ein bewusster No-Op (Exit 0, posted: false, nichts geschrieben), nie ein Fehler. Es gibt ihn für einen einzigen Aufrufer: den Abbau des Agenten-Sidecars, der etwas sagt, wenn eine SDK-Sitzung endet, ohne den geschuldeten Faden je beantwortet zu haben, damit dieser nicht für immer verstummt. Sie brauchen ihn nicht.

    Er ist die Rückfallebene, nicht der erste Zug. Bevor der Abbau im Namen des Agenten spricht, gibt er der Sitzung ihren Zug einmal zurück und sagt es ihr — mit dem konkreten Faden, beiden Arten einen Zug zu beenden, und jeder von ihr beauftragten Runde, die noch offen ist. Die meisten Sitzungen antworten dann. Eine, die erinnert wurde und erneut stumm endet, wird als Eskalation zurückgegeben: dann gibt es kein Ergebnis, und jemand muss über die Runde entscheiden — eine andere Tatsache als ein Zug, der schlicht nichts hervorbrachte, und escalated: true in nxc status ist, wo der Aufrufer es liest.

    Was durch diese Tür geschrieben wird, ist als Werk der Laufzeit gekennzeichnet. Jede so gesetzte Antwort trägt substituted: true in nxc status, sodass eine App nie einen Nachrichtentext lesen muss, um eine vom Agenten geschriebene Antwort von einer in seinem Namen gesetzten zu unterscheiden. Zum Zusammenspiel mit escalated siehe Grenzen und Sicherheit.

  • --stream — wie bei send: der Antwort beim Eintreffen zusehen.

Es gibt kein --kind, kein --priority, kein --disposition und kein --ref an reply. Eine Antwort erbt ihren Gegenstand: der Faden sagt bereits, worum es geht — deshalb sitzt die --ref-Pflicht an send und sonst nirgends.

nxc withdraw --thread <FADEN>

Eine Beauftragung zurücknehmen, die noch auf die Arbeitskopie wartet — eine, die nie startete. Es druckt eine Zeile je zurückgenommener Beauftragung (withdrew <Rolle> on thread <id> (never started)); --json trägt dasselbe als withdrawn / started_meanwhile.

Eine Persona oder ein Kanal mit working_tree: exclusive lässt eine Kette zur Zeit laufen; eine Beauftragung, die eintrifft, während eine andere Kette hält, wird geparkt und startet, sobald die Halterin loslässt. Bis dahin ist nichts geschehen: keine Sitzung, kein Verlauf, kein Modellaufruf. Genau das nimmt dieses Verb zurück, und deshalb ist es gefahrlos.

Nennen Sie den Faden, den send Ihnen gegeben hat. Jede geparkte Beauftragung darunter wird zurückgezogen, und jeder wartende Faden wird mit einer Nachricht entlastet, die sagt, wer sie zurückgenommen hat — es ist also ein Eintrag im Gespräch, keine Leerstelle.

Wurde jede Beauftragung der Runde zurückgenommen, wird auch der genannte Faden auf demselben Weg entlastet und zählt in nxc status nicht mehr als offener Vorgang. Das ist keine Konsolidierung — es wird nichts ausgeliefert, denn es gibt keine Antwort —, sondern das Register sagt, dass keine Runde mehr da ist. Ohne das galt ein zurückgenommenes send --to <kanal> weiter als laufend, weil der Kanalfaden noch auf einen Betreuer wartete, dem man gerade die Runde weggenommen hatte.

Was es nicht tut: eine bereits gestartete Runde anhalten. Die hat Arbeit unterwegs und eine Sitzung mitten im Zug; das ist eine andere Frage mit anderen Antworten. Startet eine Beauftragung zwischen dem Lesen der Warteschlange und dem Schreiben, wird sie als started_meanwhile gemeldet und strikt in Ruhe gelassen — es gibt kein Zeitfenster, in dem dieser Befehl etwas anhalten könnte, das bereits begonnen hat.

Ein Faden, unter dem nichts geparkt ist, ist ein not_found, das das sagt.

nxc release --thread <FADEN>

Die Arbeitskopie dieses Workspace zurückgeben, wenn die Kette, die sie hält, vorbei ist und nichts sie mehr von selbst zurückgeben wird. Das andere Ende von withdraw: das nimmt die wartende Beauftragung zurück, dieses hier bewegt die, die im Weg steht.

Eine Eskalation hält die Arbeitskopie mit Absicht — die Aufgabe ist noch in der Luft und die Antwort wandert noch nach oben. Sind alle Sitzungen dieser Kette beendet, bleibt nichts übrig, das je sagen könnte, dass sie fertig ist, und was dahinter wartet, wartet für immer. (Die Eskalation zu beantworten löst den Halt in einem Kanal; auf einem direkten Faden nicht — siehe Grenzen und Sicherungen, wo bisher etwas anderes stand.)

Nennen Sie einen Faden aus der haltenden Kette — nxc status markiert den Vorgang, der eine hält, mit holds working tree, und nxc threads show <id> sagt working tree: holding am Faden selbst. Den wartenden Faden zu nennen, wird ausdrücklich abgelehnt: das ist die Kette, die die Kopie will, nicht die, die sie hat.

Der Aufruf lehnt ab, solange irgendeine Sitzung der haltenden Kette noch einen lebenden Prozess hat, und sagt welche. Einer Kette, die noch arbeitet, die Arbeitskopie wegzunehmen, ist genau die Kollision, gegen die der Anspruch existiert; dieses Verb ist für den anderen Fall. Ob das Register ordentlich aussieht, fragt es nicht — das Register einer toten Kette kann alles Mögliche sagen, und entschieden wird nach „läuft noch etwas".

Wer geparkt war, startet, und die Quittung sagt es (started, dazu failed für eine Beförderung, die nicht gestartet werden konnte — ihre Nachricht ist persistiert und ihre Sitzung geprägt, es benennt also, wonach zu sehen ist). expired: true heisst, der Anspruch war schon über seine Zwei-Stunden-Grenze hinaus; dieser Aufruf hat dann die Warteschlange dahinter geleert.

Ins Gespräch wird nichts geschrieben, anders als bei withdraw. Der Anspruch gilt für Dateien auf einer Maschinenplatte — eine Zeile in der Datenbank dieses Workspace, die nie synchronisiert —, eine Nachricht darüber würde also zu Replikaten synchronisieren, auf denen die Tatsache nicht stimmt. Sichtbar ist danach die Folge: der Vorgang meldet kein holds working tree mehr, und die Kette, die gewartet hat, läuft.

Lesen

Keine dieser Lesungen schreibt etwas, und keine verbraucht eine Nachricht. --consumer <handle> liest als ein anderes qualifiziertes Handle; ohne das liest ein Befehl als der Aufrufer selbst.

Hier standen nxc inbox und nxc read, und beide sind weg (nxf 6j6v.1gm9). Es gibt kein Verb mehr, mit dem man nach den eigenen Nachrichten fragt, und keines, mit dem man sie bestätigt, denn Menschen ziehen, Agenten bekommen geschoben: die Nachricht eines Agenten steht in dem Prompt, der seine Sitzung startet, oder in dem Zug, der sie wieder aufnimmt — ein Abrufverb war also die Doppelung dessen, was ohnehin schon zugestellt war, gemessen mit je 0 Verwendungen in 66 Rollensitzungen. Ein Mensch liest stattdessen das GESPRÄCH, und dafür sind die beiden Verben darunter da. Der Ungelesen-Datensatz selbst bleibt an der App-Naht unangetastet (prime --json trägt ihn); über seine Zukunft entscheidet nxf 6j6v.4d2z.

nxc threads list / nxc threads show <FADEN>

Die Quorum-Tafeln. list sind alle Tafeln, in denen der Aufrufer Mitglied ist, je mit ihrem Sammelzustand; --channel engt ein.

$ NXC_ACTOR=alice nxc threads list
m-00000000000000000000000003  decl:build-and-ship  0/1 in  [waiting]  · waiting for working tree (#1)
m-00000000000000000000000004  decl:build-and-ship  0/1 in  [waiting]  · waiting for working tree (#1)
m-00000000000000000000000001  dm:9445dbc93dfdad401585c42b  1/1 in  [complete]
m-00000000000000000000000002  dm:9445dbc93dfdad401585c42b  0/1 in  [waiting]  · holding working tree

show ist eine Tafel in voller Länge — der Quorum-Zustand plus die Antworten in ihrer Reihenfolge:

$ NXC_ACTOR=alice nxc threads show m-00000000000000000000000001
thread m-00000000000000000000000001 in dm:9445dbc93dfdad401585c42b
  expects:     ab12/coder
  replied:     
  outstanding: ab12/coder
  complete:    false
  working tree: holding
  · ab12/alice Add a --since flag to the export command.

Die --json-Datensätze tragen thread_id, channel_id, opener, expects, replied, outstanding, complete, stale, working_tree und working_tree_queue_position. Viele Tafeln zu lesen kostet dieselbe Zahl an Abfragen wie zwei zu lesen — diese Eigenschaft wird von einem Test gemessen, nicht bloß beabsichtigt, weil eine Koordinationsoberfläche alle auf einmal liest.

nxc status

Wo ein Vorgang steht: der ganze Fadenbaum von seiner Wurzel abwärts, über Kanalgrenzen hinweg. Eine Tafel erzählt Ihnen von einem Gespräch; status erzählt vom ganzen Stück Arbeit, das es angestoßen hat.

$ NXC_ACTOR=alice nxc status
operation m-00000000000000000000000001  dm:9445dbc93dfdad401585c42b  1 thread(s), 0 open
  m-00000000000000000000000001  dm:9445dbc93dfdad401585c42b  awaiting you (answered by ab12/coder)

$ NXC_ACTOR=alice nxc status --json
{"operations":[{"root":"m-00000000000000000000000001","channel_id":"dm:9445dbc93dfdad401585c42b","live":true,"open":0,"needs_decision":false,"holds_working_tree":false,"threads":[{"thread_id":"m-00000000000000000000000001","channel_id":"dm:9445dbc93dfdad401585c42b","depth":0,"state":"answered","awaiting_human":true,"escalated":false,"substituted":false,"opener":"ab12/alice","expects":["ab12/coder"],"stale":false}]}]}
  • --thread <id> — der eine Vorgang, zu dem dieser Faden gehört, von dessen Wurzel aus gezeigt, ob er noch läuft oder schon fertig ist.
  • --channel <name> — die lebenden Vorgänge, deren Wurzel in diesem Kanal sitzt; ein deklarierter Kanalname oder eine rohe Kanal-ID. Ein Einstieg, kein Anker: ein Vorgang überschreitet Kanäle, und der Baum folgt ihm.
  • keines von beiden — alles, was hier noch läuft.

Jeder Faden trägt einen state aus open / answered / stale, dazu awaiting_human, das nur an der Wurzel eines abgeschlossenen Vorgangs true ist. Genau darum gibt es das Feld: eine stehengebliebene Kette und eine fertige, die auf einen Menschen wartet, sehen für einen Zähler gleich aus und bedeuten Gegenteiliges.

Zwei Kennzeichen sitzen am Vorgang statt an einem Faden, und beide beantworten eine Frage, die die Faden-Zeilen sonst nur einzeln nacheinander beantworten:

  • needs_decision — irgendwo unter dieser Wurzel wurde eine Aufgabe zurückgegeben, und niemand hat sie aufgenommen. Lesen Sie es neben awaiting_human: beide sagen „der Mensch ist dran", über Lagen von völlig verschiedener Dringlichkeit. Ein fertiger Vorgang, der gelesen werden will, ist das normale Ende; einer, dessen Wurzel genauso aussieht, während darunter eine unbeantwortete Eskalation liegt, ist eine Kette, die steht — und eine Eskalation hält die Arbeitskopie, hält also auch die Maschine an. Es räumt sich selbst ab: Runde neu beauftragen, Kennzeichen weg.
  • holds_working_tree — irgendwo unter dieser Wurzel wird die Arbeitskopie gehalten. Es sagt Ihnen, ob Sie überhaupt nachsehen müssen; das Feld working_tree am Faden sagt weiterhin, welcher Faden.

nxc search <SUCHTEXT>

Groß-/kleinschreibungsunabhängige Teilzeichenkette über die Nachrichtentexte in den Kanälen des Aufrufers, deterministisch sortiert.

$ NXC_ACTOR=alice nxc search "since flag" --json
[{"message_id":"m-00000000000000000000000001","channel_id":"dm:9445dbc93dfdad401585c42b","sender":"ab12/alice","body":"Add a --since flag to the export command."}]

Gesucht wird nur in Texten, und nur in Kanälen, in denen der Konsument Mitglied ist. Um zu finden, was eine Sitzung getan hat statt was sie gesagt hat, lesen Sie ihren Verlauf.

Sitzungen und Verläufe

Das sind die Innereien der Rollen-Laufzeit. Geschrieben werden sie vom Agenten-Sidecar; eine davon ist eine Lesung, die Sie beim Namen kennen wollen.

nxc session bind <INTERN> <ECHT>

Bindet eine interne (von nxc geprägte) Sitzungs-ID an die echte Sitzungs-ID, die das Claude Agent SDK zurückgegeben hat. Das Sidecar ruft das auf, sobald eine Sitzung startet. Eine unbekannte interne ID wird als not_found gemeldet.

nxc session state <SITZUNG> / --thread <ID>

Läuft diese Sitzung noch, oder ist sie tot? Die Lese-Seite zu den beiden Schreibvorgängen, die das Sidecar auf dieser Naht macht — session bind oben und das session ended, das es als letztes aufruft.

nxc session state m-01M0…            # eine Sitzung
nxc session state --thread m-01M0…   # alle Sitzungen eines Fadens, beendete eingeschlossen

Drei Antworten, und die dritte ist kein Ausweichen:

  • running — hinter ihr steht ein lebender Prozess.
  • ended <Zeitpunkt> — die Sitzung hat ihr Ende selbst gemeldet, und zwar dann. Das ist die Tatsache, auf die ein Kanal mit working_tree: exclusive seinen nächsten Schritt öffnet.
  • unknown — niemand hat ein Ende gemeldet, und kein lebender Prozess antwortet für sie: eine hart getötete Sitzung, oder eine, die diese Maschine nie ausgeführt hat. ended zu melden hieße, eine Tatsache zu behaupten, die niemand festgestellt hat.

unknown hat eine dritte Lesart, und die Antwort sagt Ihnen, wann Sie sie vor sich haben. Ob eine Sitzung läuft, beantwortet der Worker — und nicht jeder kann das: wer keinen Prozess startet, hat auch keinen anzusehen. Deshalb trägt die Antwort worker_answers_liveness: false heißt, hier wurde nie gefragt, und kein unknown darunter sagt etwas über eine Sitzung aus. Der ausgelieferte Sidecar beantwortet die Frage, auf der normalen Kommandozeile steht das Feld also auf true und ein unknown ist wirklich eine Sitzung, die wortlos gestorben ist.

Die Sitzungsform an einem still gewordenen Faden, bevor Sie ihn für gescheitert halten. Die Form --thread, bevor Sie eine Arbeitskopie anfassen, an der ein vorheriger Schritt noch die Hände haben könnte: sie listet, was dort lief und was daraus wurde — die Frage, die nxc status nicht beantworten kann, weil es ein Nachrichtenbrett liest und dies einen Prozess. Eine unbekannte Sitzung ist not_found; ein Faden, auf dem nichts lief, ist eine leere Antwort und kein Fehler.

nxc transcript show <SITZUNG>

Der normalisierte Strom einer Sitzung als Zeitleiste: Assistenztext, Denken, Werkzeugaufrufe und deren Ergebnisse, wobei die Einträge eines per Task gestarteten Unteragenten unter dem tool_use verschachtelt sind, der ihn gestartet hat. Die Sitzungs-ID ist die interne — das, was send --to <persona> als session zurückgibt.

$ NXC_ACTOR=alice nxc transcript show m-00000000000000000000000001
transcript m-00000000000000000000000001  role=coder  (0 entries)

--from-seq <n> und --limit <n> blättern eine lange Sitzung: übergeben Sie das größte seq, das der letzte Abschnitt gezeigt hat; ein Abschnitt kürzer als --limit ist das Ende. Eine unbekannte Sitzung liefert einen leeren Verlauf statt eines Fehlers — eine Sitzung, deren Sidecar nie geschrieben hat, ist von einer, die nichts zu sagen hatte, nicht zu unterscheiden.

Zwei Dinge sollten Sie wissen, bevor Sie so etwas irgendwohin einfügen. Ein Verlauf enthält rohe Werkzeug-Eingaben und -Ergebnisse — alles, was der Agent gelesen, geschrieben oder ausgeführt hat. Behandeln Sie einen Auszug also wie die Workspace-Datenbank, nicht wie ein Nachrichtenprotokoll. Und er ist bewusst nicht mitgliedschaftsgeprüft: ein Verlauf hat keinen Kanal, an dem man prüfen könnte, und die Tabelle ist gerätelokal und wird nie synchronisiert — eine Prüfung erkaufte also nichts, was wer die Datei hat nicht ohnehin mit sqlite3 täte.

nxc transcript append --session <ID>

Hängt normalisierte Einträge an, als JSON-Zeilen von STDIN gelesen. Das ist der Rückruf-Kontrakt des Sidecars — der Flag-Name, die stdin-Rahmung und der --json-Datensatz sind alle tragend, weil ein bereits ausgelieferter Erzeuger davon abhängt. Eine Zeile, die sich nicht parsen lässt, ist ein lauter validation-Fehler, der die Zeile benennt, nie ein stilles Überspringen.

nxc transcript prune

Räumt die Verläufe von Sitzungen ab, in die seit einer Weile niemand geschrieben hat, und sagt, was weg ist. Ganze Sitzungen, gealtert an ihrem letzten Eintrag: eine Sitzung, in die noch geschrieben wird, ist nie ein Kandidat, wie lange sie auch schon läuft, und eine lange wird nie halbiert.

nxc transcript prune --dry-run          # melden, nichts entfernen, keine Schreibsperre nehmen
nxc transcript prune --keep-days 7      # enger als das konfigurierte Fenster

Sie müssen das nicht ausführen, um die Tabelle zu begrenzen — dieselbe Aufbewahrung läuft beim ersten Schreiben jeder neuen Rollensitzung mit. Greifen Sie danach, um einen still gewordenen Workspace aufzuräumen oder einmalig ein engeres Fenster anzuwenden. Es stoppt das Wachsen der Datenbank; es macht die Datei nicht kleiner (dafür bräuchte es ein VACUUM, das hier nicht läuft, weil es den ganzen gemeinsamen Workspace unter exklusiver Sperre neu schreibt). Sitzungen ohne lesbaren Zeitstempel sind von unbekanntem Alter, werden also behalten und gesondert gemeldet — eine sichtbare Lücke statt einer stillen.

Dokumentation

nxc guide [THEMA]

Die Anleitungen, die Sie gerade lesen, ins Binary kompiliert. Kein Workspace nötig, kein Netz:

nxc guide                     # die Themen von chat auflisten
nxc guide core-concepts       # eines ausgeben
nxc guide --json              # [{topic, summary}, …] — der Agenten-Kontrakt

nxs guide fächert über die aktiven Module auf und listet die Themen aller drei Bausteine auf einmal. Wo ein Themenname in mehr als einem Baustein vorkommt — getting-started und commands tun das —, wählt es nicht für Sie aus, sondern nennt die Befehle je Werkzeug.

Keine Verben, die man tippt

Zwei Unterbefehle existieren und sind aus --help ausgeblendet, weil niemand sie tippen soll:

  • nxc prime — der Sitzungsstart. Der eigene SessionStart-Hook von chat führt es direkt aus, und nxs prime fächert dorthin auf, wenn Sie die Klammer von Hand fragen.
  • nxc tick --thread <id> — ein Uhrzeiger. Der Einmal-Job, den das deklarierte timeout: eines Kanals plant, führt ihn aus, um einen Faden erneut zu prüfen und ihn, wenn fällig, durch die on_complete-Politik des Kanals zu leiten. Er ist idempotent: ein bereits behandelter Faden ist ein sauberer No-Op, nie ein zweites Wecken.

Sie stehen hier, damit es kein Rätsel ist, wenn man sie in einer Prozessliste oder einem Protokoll findet. Bauen Sie nichts darauf.

Was bewusst fehlt

Die Hälfte einer vertrauenswürdigen Referenz ist das, wovon sie sagt, dass es nicht da ist. Diese Verben gab es, und sie wurden entfernt; jeder Eintrag sagt, was man stattdessen tut.

  • nxc ask — in send --to aufgegangen. Ein Kanal wird genau wie eine Persona angesprochen, und ein Verb, das einen Faden prägt, schlägt zwei, die sich uneins sind, ob sie das tun.
  • nxc channels create / dm / join / leave — mit den rohen Kanälen entfallen. Ein Kanal ist eine Deklaration in .nxs-personas/channels.yaml; die Mitgliedschaft ist seine members:-Liste. Ein direktes Gespräch wird für Sie geprägt, sobald Sie send --to an eine Persona richten, unter einer aus den beiden Handles abgeleiteten ID — es gibt also nichts anzulegen. Die projektübergreifende Entdeckung öffentlicher Kanäle hat die Agentenoberfläche ganz verlassen und ist Sache einer App; nxc list --json trägt die Vordertüren weiterhin, die es sieht.
  • nxc agents register / list / search / show — ein Team wird deklariert, nicht registriert. nxc list ist die Lesung, und sie durchsucht dieselben Felder job_title / job_description, die agents search durchsuchte. Eine zur Laufzeit registrierte Profilzeile lag in der Datenbank einer Maschine, niemand prüfte sie, und sie überlebte den Lauf nicht.
  • nxc workflow start / step / status / tick / done / bind / append / show / expect — die deklarative Lauf-Engine ist weg, samt Lauf-Datensatz. Ein Kanal deklariert seinen eigenen Ablauf (flow: sequential), send --to <kanal> startet ihn, und nxc status ist der Ort, an dem die Position eines Vorgangs gelesen wird. Siehe Kanäle.
  • send --role / --session — --to ist der eine Weg, ein Ziel zu benennen. --role ist darin aufgegangen; --session ist eine festgehaltene Lücke und kein Zusammenfallen, und im Quelltext auch als solche benannt.
  • send --kind / --priority / --disposition / --model / --deadline sowie reply --kind — gemeinsam entfernt. Die ersten drei ließen einen Aufrufer eine Frage beantworten, die ihm niemand gestellt hatte; die letzten beiden sind an der Persona und am Kanal deklariert, und eine Übersteuerung je Aufruf neben einem deklarierten Wert sind zwei Antworten auf eine Frage. Wie viel Denken eine Aufgabe wert ist, sagt das stage: oder model: der Persona; wie lange eine Tafel warten darf, das timeout: des Kanals.

Weiter

Tippen, um zu suchen. Gefunden wird nach Wortlaut und nach Bedeutung — ein Abschnitt kann also eine Frage beantworten, die er nicht ausspricht.