Nexus: Autopilot, parallele Arbeit und dauerhafte Läufe

Nexus ist der Orchestrator von Core. Er hat vier Rollen: Scrum Master (Sprints, Stories, Retrospektiven), Quick Flow (eine kleine Änderung mit minimalem Aufwand), Autopilot Controller (die Pipeline von der Idee bis zur Auslieferung, mit Checkpoints) und Parallel Supervisor (mehrere Agenten gleichzeitig, ohne Kollisionen). Darunter hält eine dauerhafte Laufzeit, bmad-plus nexus, Aufgabengraphen und Versuche auf der Platte, damit Arbeit eine geschlossene Sitzung überlebt und nichts als erledigt gilt, bevor unabhängige Prüfungen es bestätigen. Diese Seite richtet sich an alle, die die Arbeit von mehr als einem Agent automatisieren und genau wissen wollen, wie weit die Automatisierung geht.

Autopilot#

Sage autopilot im Chat deines KI-Tools und beschreibe dann das Projekt. Das sind Chat-Anweisungen, keine Terminal-Befehle. Nexus prüft Anfrage und Projekt, bevor es Stufen wählt: Eine kleine Änderung geht direkt zu Implementierung und Review, während ein fehlender Vertrag oder eine folgenreiche Unsicherheit tiefere Planung rechtfertigt. Für ein Projekt, das die volle Pipeline braucht, gibt es drei Phasen.

Jeder Checkpoint folgt der Einstellung in _bmad/config.yaml: require_approval hält an und wartet, notify_only meldet und macht weiter, auto macht weiter und protokolliert. Mit execution_mode: autopilot wird der Checkpoint story standardmäßig zu notify_only. Eine externe Benachrichtigung (etwa eine Nachricht aufs Handy) braucht einen konfigurierten Kanal und deine Erlaubnis: Eine nackte Installation hat keinen Hintergrund-Sender, eine Erinnerung wird also nicht von selbst verschickt.

Auch die menschliche Abnahme passt hinein. Mit uat.mode: advisory (Standard, auch wenn der Block fehlt) wird die Seite bei jeder Auslieferung gebaut und angeboten und blockiert nie; gate lässt den Auslieferungs-Checkpoint auf ein bestandenes bmad-plus uat gate warten; off erzeugt kein Protokoll, und der Auslieferungsbericht sagt das. Ein Pack kann außerdem in der Registry eine Pipeline deklarieren (geordnete Schritte, jeder mit einem Gate); der Autopilot führt diese Pipeline dann für die Arbeit des Packs aus, nach seinem Intake. In 0.23.0 deklariert kein Pack eine; es ist also eine Fähigkeit des Frameworks, kein mitgelieferter Inhalt.

Zustand, Wiederaufnahme und Fehler#

• Der maßgebliche Zustand liegt unter .bmad-plus/nexus/runs/. Die optionale Datei .bmad-plus/orchestrator-state.yaml ist nur eine Navigationszusammenfassung; sie kann weder beweisen, dass etwas akzeptiert ist, noch dass ein Prozess gestoppt hat.
• Es gibt keine ausführbare Datei autopilot --resume. Zum Fortsetzen prüfst du den gemeinten dauerhaften Lauf und den echten Zustand des Hosts und gleichst einen unterbrochenen Versuch ab, bevor du es erneut versuchst.
• Testfehler: Die fehlgeschlagenen Prüfungen bleiben erhalten, die Reparatur erfolgt im maxAttempts der Aufgabe, danach werden die geänderten Artefakte erneut verifiziert. Eine Fertigmeldung kann eine fehlschlagende Prüfung nicht bestehen lassen.
• Agent-Fehler: Teilarbeit und Versuchsidentität bleiben erhalten, und der Bericht sagt, was unsicher bleibt. Abhängige Aufgaben warten auf die Akzeptanz.
• Konflikt bei paralleler Arbeit: Überlappende Arbeit wird nicht mehr zugewiesen, die Besitzer werden geprüft, ihre Versuche abgeglichen und deine Änderungen bewahrt, bevor ein neuer Versuch folgt.

Parallele Arbeit#

Sage parallel im Chat oder lass den Autopilot es aufrufen, wenn parallel_execution true ist und unabhängige Aufgaben erkannt werden. Der Parallel Supervisor entscheidet, was gleichzeitig laufen kann; der Host entscheidet, ob er es kann. Echte Parallelität hängt von deinem Tool ab: Kann es keine Sub-Agenten starten, laufen die Aufgaben nacheinander.

Die dauerhafte Laufzeit#

bmad-plus nexus hält einen Aufgabengraphen und seine Versuche unter .bmad-plus/nexus/runs/ fest. Jede normale Änderung nimmt eine exklusive Projektsperre und schreibt eine Zustandsdatei mit Prüfsumme über eine geflushte Temporärdatei und ein atomares Umbenennen. Die Inspektion ist schreibgeschützt. Drei Ergebnisse werden getrennt gehalten, und diese Trennung ist der Sinn der Laufzeit.

Belege bleiben über die Zeit ehrlich. Eine akzeptierte Aufgabe gilt nur so lange als aktuell, wie ihre Artefakte, geschützten Ressourcen und jede transitive Abhängigkeit noch dem Verifizierten entsprechen: Die Änderung einer vorgelagerten Datei entwertet die Belege der abhängigen Aufgaben, und ein alter Eintrag „akzeptiert“ behauptet nicht, dass später bearbeitete Dateien noch bestehen. Eine Frist ist eine Beobachtung, kein Beweis dafür, dass Arbeit nie stattfand oder ein Prozess endete.

Die Plandatei#

Ein Plan ist eine JSON-Datei; strukturierte Eingaben laufen immer über Dateien, damit Shell-Quoting ein Befehls-Array nicht umdeuten kann. Dieser minimale Plan hat eine Aufgabe, deren Ergebnis eine bereits vorhandene Prüfung (checks/check-result.cjs) erfüllen muss und deren Quelle außerhalb des Schreibbereichs des Arbeiters liegt.

{
  "id": "example",
  "maxParallel": 1,
  "config": { "language": "English" },
  "tasks": [
    {
      "id": "result",
      "objective": "Produce the requested result in work/result.txt.",
      "acceptance": ["The result satisfies the independent check."],
      "dependsOn": [],
      "scope": ["work"],
      "artifacts": ["work/result.txt"],
      "resources": ["checks/check-result.cjs", ".agents/skills/agent-orchestrator/SKILL.md"],
      "checks": [
        {
          "id": "result-content",
          "command": "node",
          "args": ["checks/check-result.cjs"],
          "cwd": ".",
          "timeoutMs": 30000
        }
      ],
      "maxAttempts": 2,
      "deadlineMs": 3600000,
      "idempotent": true,
      "authorizations": ["Edit work/ and run the listed local check."]
    }
  ]
}

Pfade in einem Plan sind portabel, projektrelativ und nutzen /. Absolute Pfade, Aufstieg im Verzeichnisbaum, alternative Datenströme, reservierte Windows-Namen, Symlinks oder Junctions sowie Schreibzugriffe auf .git oder den Nexus-Zustandsbaum werden abgelehnt. Prüfungen laufen in einer eingeschränkten Umgebung: Nur PATH, SYSTEMROOT, WINDIR, TEMP, TMP und TMPDIR können übernommen werden (plus einige nicht geheime Identitäts- und Pfadvariablen unter Windows), die Locale ist C, die Zeitzone UTC, und NODE_OPTIONS, PYTHONPATH, Loader-Hooks und Zugangsdaten fehlen. Das schränkt die Umgebung ein; es ist keine Betriebssystem-Sandbox.

Der Ablauf im Host: create, start, record, verify, accept#

Das Standard-Backend ist der Host: Dein Assistent erledigt die Arbeit mit eigenen Mitteln und meldet zurück. Unten ein echter Lauf eines aus einem Schwarm exportierten Fanouts (drei Seiten-Einheiten; nur die erste wird durchlaufen). Lege die drei Schwarm-Dateien und host.json in einem Projekt an, um ihn nachzuvollziehen. Der „Arbeiter“ ist ein Platzhalter, der die Antwortdatei von Hand schreibt: Das Beispiel zeigt die Buchführung, nicht die Arbeit eines Modells.

{
  "schemaVersion": 1,
  "id": "site-pages",
  "kind": "fanout",
  "title": "One sub-agent per page of the site",
  "units": { "source": "input" },
  "brief": { "template": "briefs/page.md", "context": [] },
  "answer": {
    "required": ["id", "done", "words"],
    "fields": {
      "done": { "type": "boolean" },
      "words": { "type": "integer", "min": 0 },
      "note": { "type": "string", "max": 200 }
    }
  },
  "tally": { "rate": "done", "numbers": ["words"] },
  "disclosure": "Each page was written by a separate sub-agent from the same brief; read them together before publishing."
}

{
  "schemaVersion": 1,
  "units": [
    { "id": "about", "scope": "site/about", "title": "About us", "tone": "warm" },
    { "id": "pricing", "scope": ["site/pricing", "site/data/prices.json"], "title": "Pricing", "tone": "plain" },
    { "id": "contact", "scope": "site/contact", "title": "Contact", "tone": "short" }
  ]
}

# Page {{unit.id}}

Write the page "{{card.title}}" under `{{card.scope}}`, {{card.tone}} in tone. Touch nothing
outside that folder.

When the page is written, write a JSON object to `{{answer.path}}` with `id` ("{{unit.id}}"),
`done`, `words` (the word count) and an optional `note`.

{{disclosure}}

{ "backend": { "kind": "host", "id": "demo-worker", "sessionId": "demo-session-1" } }

$ npx bmad-plus swarm init --definition swarm/page-fanout.json --units swarm/units.json
site-pages-20261019-vwk0: fanout of 3 units, budget 26, approval not-needed.
Units listed, no seed.
Next: bmad-plus swarm briefs site-pages-20261019-vwk0
$ npx bmad-plus swarm plan site-pages-20261019-vwk0 --out .bmad-plus/swarm/reports/site-pages-20261019-vwk0/plan.json
/work/demo/app/.bmad-plus/swarm/reports/site-pages-20261019-vwk0/plan.json: 3 tasks, 10 in parallel.
Next: bmad-plus nexus create --plan /work/demo/app/.bmad-plus/swarm/reports/site-pages-20261019-vwk0/plan.json
$ npx bmad-plus nexus create --plan .bmad-plus/swarm/reports/site-pages-20261019-vwk0/plan.json
Nexus run site-pages-20261019-vwk0 — durable task coordination
about: not started; verification=pending; acceptance=pending
pricing: not started; verification=pending; acceptance=pending
contact: not started; verification=pending; acceptance=pending
Use inspect --json for recorded evidence and reconciliation observations.
$ npx bmad-plus nexus start site-pages-20261019-vwk0 about --input host.json
about: running; verification=pending; acceptance=pending
  Attempt: a4ec0495-660b-487c-8c83-e82ada22a857; host: demo-worker/demo-session-1
$ echo '{"id":"about","done":true,"words":120}' > .bmad-plus/swarm/runs/site-pages-20261019-vwk0/answers/about.json
# Der Platzhalter-Worker schreibt seine Antwortdatei von Hand. Schreibe dann rec.json (unter diesem Terminal gezeigt) mit der Versuchs-ID, die start ausgibt.
$ npx bmad-plus nexus record site-pages-20261019-vwk0 about --input rec.json
about: completed; verification=pending; acceptance=pending
  Attempt: a4ec0495-660b-487c-8c83-e82ada22a857; host: demo-worker/demo-session-1
$ npx bmad-plus nexus verify site-pages-20261019-vwk0 about
about: completed; verification=passed; acceptance=pending
$ npx bmad-plus nexus accept site-pages-20261019-vwk0 about
about: completed; verification=passed; acceptance=accepted
$ npx bmad-plus nexus inspect site-pages-20261019-vwk0
about: completed; verification=passed; acceptance=accepted
  Accept only after rechecking current artifacts and resources.
pricing: not started; verification=pending; acceptance=pending
  Start when dependencies have current accepted evidence.
# Jeder nexus-Befehl gibt außerdem die Kopfzeile, die Zeilen pricing und contact und den Schlusshinweis aus; hier bleiben nur die Zeilen, die sich ändern.

{
  "attemptId": "a4ec0495-660b-487c-8c83-e82ada22a857",
  "backend": { "kind": "host", "id": "demo-worker", "sessionId": "demo-session-1" },
  "outcome": "completed",
  "exitCode": 0,
  "summary": "The demo host reports the about page is written."
}

record braucht die exakte Versuchs-ID und dasselbe Backend samt Sitzung. Andere Ergebnisse sind failed, blocked (die Anfrage bleibt sichtbar und behält ihre Kapazität) und ambiguous (gewöhnliche Bestätigungen werden dann abgelehnt; gleiche ausdrücklich ab). verify endet mit 1, wenn die Verifikation nicht bestanden wurde, und accept lehnt eine Aufgabe ohne geeignete bestandene Verifikation ab. Der Exit-Code eines Arbeiters oder ein Satz „fertig“ ersetzt nie einen Prüfbeleg.

Unterbrechung, Abbruch und Wiederholung#

Das optionale Prozess-Backend und der Codex-Adapter#

Eine Aufgabe kann ein execution-Objekt tragen, statt dem Host zu gehören. Das ist eine vom Operator gelieferte Definition, nie ein aus dem Aufgabentext abgeleiteter Befehl. nexus launch RUN TASK bleibt dann im Vordergrund, bis die eigene Operation endet; ein Terminal, ein Coding-Host oder ein CI-Runner hält es am Leben. Der Aufgabeneintrag wird vor dem Start des Prozesses gespeichert und bindet eine frische Versuchs-ID an eine frische Supervisor-Sitzung, die exakte Definition und die Hashes seiner geschützten Eingaben. Der Supervisor behält begrenzte stdout und stderr, das reale Ende oder Signal und einen Beleg mit Prüfsumme. launch lässt das Einsammeln auch nach sauberem Ende offen: nexus collect RUN TASK --input attempt.json (die exakte attemptId und das ganze backend-Objekt) schließt es und lehnt einen fremden, wiederholten oder späten Beleg ab. Status 0 bei launch heißt nur, dass der Prozessbeleg „completed“ sagt; Akzeptanz bedeutet es nicht.

{
  "execution": {
    "adapter": "command",
    "command": "node",
    "args": ["workers/task.cjs"],
    "cwd": ".",
    "input": "inputs/task.json",
    "resources": ["workers/task.cjs"],
    "blockedExitCodes": [75],
    "outputLimitBytes": 262144
  }
}

{
  "execution": {
    "adapter": "codex-exec",
    "command": "/absolute/path/to/codex",
    "input": "inputs/task.md",
    "instructions": [".agents/skills/agent-architect-dev/SKILL.md"],
    "sandbox": "workspace-write"
  }
}

• Die ausführbare Datei wird zu einer regulären Datei aufgelöst und ihr SHA-256 im Plan festgenagelt. Argumente sind wörtliche Arrays, ohne Shell, ohne Umgebungsüberschreibung und ohne Zugangsdaten-Schnappschuss übergeben.
• Texteingaben sind je höchstens 256 KiB groß, das ganze Paket höchstens 1 MiB. Anweisungen werden mit ihren relativen Pfaden vor die Standardeingabe gesetzt.
• Ein Ende mit Null ist generischer Abschluss; ein in blockedExitCodes gelisteter Code ungleich Null gilt als blockiert. Diese Liste ist eine Konvention deines Wrappers, nie eine Freigaberichtlinie.
• Der Codex-Adapter baut -a never exec --json --color never --sandbox MODE --skip-git-repo-check --ignore-user-config -; model ist optional und fügt nur --model MODEL hinzu. sandbox ist read-only (Standard) oder workspace-write; kein anderes Flag, keine Umgehung der Freigabe und kein Shell-String wird akzeptiert. Nur HOME, USERPROFILE, HOMEDRIVE, HOMEPATH und CODEX_HOME dürfen über die minimale Umgebung hinaus geerbt werden, und Belege listen Variablennamen, nicht Werte.
• Der Codex-Abschluss braucht ein Ende mit Null, eine thread.started-Identität und ein turn.completed-Ereignis ohne abschließenden Fehler. Nur ausdrückliche approval_required-Fehlercodes werden zu blockiert; andere Anbieterfehler bleiben fehlgeschlagen.
• Der Abbruch ist an die zurückgegebene Identität gebunden. Nur der ursprüngliche Supervisor darf dem direkten Kindprozess, den er erzeugt hat, ein Signal senden; nichts tötet eine gespeicherte PID oder übernimmt ein altes Terminal. Eine Frist, übermäßige Ausgabe oder ein verlorener Supervisor ergibt ein mehrdeutiges Ergebnis und hält die Kapazität bis zum Abgleich.
• Ehrlicher Beleg: Der Flag-Vertrag wurde gegen Codex CLI 0.153.4 geprüft. Ein autorisierter Aufruf am 2026-09-11 erzeugte einen echten Thread und ein Abschlussereignis, doch der Host lehnte die gewünschte Dateiänderung als schreibgeschützt ab; Nexus sammelte den Beleg ein, der unabhängige Verifizierer scheiterte und die Akzeptanz wurde verweigert. Das zeigt die Verdrahtung und die Fehlereindämmung auf diesem Host; erfolgreiches Dateischreiben durch Codex wurde dort nicht nachgewiesen.

Grenzen und was nicht geschieht#

• Kein Daemon, kein Scheduler, keine unbeaufsichtigte Schleife. Jeder Start ist ausdrücklich und belegt einen Kapazitätsplatz; Kapazität ist kein Geldbudget.
• Keine Betriebssystem-Sandbox. Arbeiter teilen Projekt und OS-Nutzer mit Nexus und können deklarierte Scopes ignorieren; Prüfsummen erkennen versehentliche Änderungen, sie sind keine Signaturen. Schütze Plan und Verifizierer und nutze ein isoliertes Projekt oder eine Host-Richtlinie, wenn es darauf ankommt.
• Kein Git-Commit, kein Merge, kein Deployment. Akzeptanz heißt „der aktuelle Arbeitsstand hat die unabhängigen Prüfungen bestanden“, nicht mehr.
• Keine Aussage zur Modellqualität. Ein Beleg ist kein Nachweis, dass ein Modell irgendwo besser wurde.
• Ein Verifikations-Timeout signalisiert nur das direkte Kind und erfasst ein mehrdeutiges Ergebnis, weil die Abwesenheit von Nachfahren oder äußeren Wirkungen nicht bewiesen ist. Prüfprogramme müssen begrenzte Vordergrundbefehle sein.

autopilot. Das Projekt: eine kleine API, mit der Freiberufler Angebote senden und in Rechnungen umwandeln. Beginne mit dem Intake aller beteiligten Packs. Halte am Checkpoint des PRD und an dem der Architektur an und warte auf meine Freigabe. Halte jede Story klein, verifiziere jede gegen ihre Abnahmekriterien, bevor die nächste kommt, und sage mir am Ende, was unsicher bleibt.

parallel. Nimm die genehmigten Stories und teile sie in Aufgaben auf, die nicht dieselben Dateien berühren. Gib jeder Aufgabe einen exklusiven Schreibbereich, die lesbaren Dateien und eine Prüfung, die ich ausführen kann. Erfasse den Plan mit bmad-plus nexus create, führe nur unabhängige Aufgaben zusammen aus und zeige mir nexus inspect nach jeder Welle. Akzeptiere eine Aufgabe nicht, bevor nexus verify bestanden hat.