# Nexus: Autopilot, parallele Arbeit und dauerhafte Läufe

> Autopilot mit Checkpoints, überwachte parallele Arbeit, Plan-Export aus einem Schwarm und dauerhafte Laufzeit (create, start, launch, collect, verify, accept) mit Codex-Adapter und Grenzen.

Canonical: https://bmad-plus.rochetta.fr/de/docs/concepts/nexus-orchestration/
Language: de
BMAD+ version: 0.23.1
Documentation reviewed: 2026-10-19
Author: Laurent Rochetta
License: MIT

BMAD+ Dokumentation › [Konzepte](https://bmad-plus.rochetta.fr/de/docs/concepts/) › 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.

<a id="video-nexus-parallel"></a>
Video: [Nexus und parallele Arbeit](https://bmad-plus.rochetta.fr/media/nexus-parallel-en.mp4) — Wie Nexus unabhängige Aufgaben findet, jeder einen eigenen Schreibbereich gibt, echte Ergebnisse festhält und unabhängige Prüfungen vor der Annahme ausführt.
[Untertitel (WebVTT)](https://bmad-plus.rochetta.fr/media/nexus-parallel-de.vtt)

Transkript:

> Nexus koordiniert die Arbeit der übrigen Rollen. Es sucht unabhängige Aufgaben, solche, die keine gemeinsame Datei berühren. Jede Aufgabe bekommt ihren eigenen Schreibbereich, und diese Bereiche dürfen sich nicht überschneiden. Parallele Agenten liefert dein Host-Werkzeug. Ohne sie laufen die Aufgaben nacheinander. Nexus kann außerdem einen geplanten lokalen Befehl oder einen Codex-CLI-Prozess starten, unter einem Supervisor im Vordergrund. Es hält das tatsächliche Ergebnis fest und führt unabhängige Prüfungen aus, bevor etwas akzeptiert wird. Es läuft kein Scheduler im Hintergrund, und die Berechtigungen des Hosts gelten weiterhin. Im Autopilot läuft dieselbe Pipeline von der Idee bis zur Auslieferung, mit den Checkpoints, die du einstellst.

Transkript mit Bildbeschreibung:

- **0:00** Im Bild: Ein dunkler Raum. Dünne Bernsteinstrahlen schießen von den Rändern herein, laufen in einem Punkt zusammen und lodern zu einem hellen Stern auf. Zuerst erscheint die Einblendung „Nexus“, die dann durch „Independent tasks“ (auf Englisch) ersetzt wird. Sprechtext: Nexus koordiniert die Arbeit der übrigen Rollen. Es sucht unabhängige Aufgaben, solche, die keine gemeinsame Datei berühren.
- **0:10** Im Bild: Zwei Terminalbereiche nebeneinander. Links wird der Befehl bmad-plus nexus create --plan nexus-plan.json getippt. Er gibt „Nexus run demo — durable task coordination“ aus und eine Zeile für jede von zwei Aufgaben, „value“ und „notes“, die alle auf „not started; verification=pending; acceptance=pending“ enden. Dann gibt bmad-plus nexus inspect demo dieselbe Übersicht mit der Zeile „Start when dependencies have current accepted evidence.“ aus. Der rechte Bereich zeigt nexus-plan.json: einen Lauf mit „id“: „demo“ und „maxParallel“: 2 sowie zwei Aufgaben. Die erste, „value“, hat das Ziel „Write the value 7 into src/value.json.“ Die zweite, „notes“, hat das Ziel „Write the release notes into docs/notes.md.“, eine Abnahmezeile („docs/notes.md exists and is not empty.“), ein leeres „dependsOn“, „scope“: [„docs/notes.md“] (umrahmt), „artifacts“, „resources“, einen „checks“-Eintrag, der ein Node-Skript ausführt, „maxAttempts“: 2 und „idempotent“: true. Der gesamte Terminaltext ist englisch. Sprechtext: Jede Aufgabe bekommt ihren eigenen Schreibbereich, und diese Bereiche dürfen sich nicht überschneiden.
- **0:19** Im Bild: Ein Netz aus Glaskugeln, durch dünne Bernsteinlinien verbunden, hängt in einem dunklen Sternenhimmel mit bernsteinfarbenem Schimmer. Es wächst aus einer losen Streuung zu einem verbundenen Geflecht. Die Einblendung lautet auf Englisch „Parallelism comes from the host“. Sprechtext: Parallele Agenten liefert dein Host-Werkzeug. Ohne sie laufen die Aufgaben nacheinander.
- **0:26** Im Bild: Ein Terminal. Der Befehl bmad-plus nexus launch demo value zeigt die Aufgabe als „running“, mit einer Versuchs-ID und einer Prozess-ID. Dann zeigt bmad-plus nexus collect demo value --input attempt.json sie als „completed“, weiterhin mit „verification=pending; acceptance=pending“. bmad-plus nexus verify demo value; echo "exit code: $?" ändert die Zeile zu „verification=passed“ (umrahmt) und gibt „exit code: 0“ aus. Ein langer Befehl, bmad-plus nexus inspect demo --json, gefiltert mit grep, sed und awk, listet die Prüfung auf, die gelaufen ist: „command“: „/usr/local/bin/node“, „policy“: „minimal-local-v1“ (umrahmt), „exitCode“: 0 und „stdout“: „value.json holds 7\n“. Zuletzt wird bmad-plus nexus accept demo value getippt, und die Statuszeile endet mit „verification=passed; acceptance=accepted“, wobei „acceptance=accepted“ umrahmt ist. Der gesamte Terminaltext ist englisch. Sprechtext: Nexus kann außerdem einen geplanten lokalen Befehl oder einen Codex-CLI-Prozess starten, unter einem Supervisor im Vordergrund. Es hält das tatsächliche Ergebnis fest und führt unabhängige Prüfungen aus, bevor etwas akzeptiert wird.
- **0:45** Im Bild: Ein Knäuel dünner, verschlungener Bernsteinlinien richtet sich Linie für Linie zu einem quadratischen Raster mit einem hellen Punkt in der Mitte auf. Die Einblendung lautet auf Englisch „No background scheduler“. Sprechtext: Es läuft kein Scheduler im Hintergrund, und die Berechtigungen des Hosts gelten weiterhin.
- **0:50** Im Bild: Ein gedämpfter blauer Dunst mit einem leuchtenden Horizont, der langsam heller wird. Die Einblendung lautet auf Englisch „Discovery · Build · Ship“. Sprechtext: Im Autopilot läuft dieselbe Pipeline von der Idee bis zur Auslieferung, mit den Checkpoints, die du einstellst.

<a id="autopilot"></a>
## 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.

**Die Autopilot-Pipeline**

| Phase | Schritte | Checkpoint |
| --- | --- | --- |
| 1. Discovery | Schritt 0: der Intake jedes Packs, das die Anfrage betrifft. Dann Atlas (Analyst): Brainstorming und Domänenrecherche; Atlas (PM): Product Brief und PRD; Sentinel (UX): UX-Spezifikation. | `discovery`: du prüfst das PRD und die UX-Spezifikation. |
| 2. Build | Forge (Architekt): Architektur; Nexus (Scrum Master): Epics, Stories, Sprintplan; dann je Story, parallel wenn unabhängig: implementieren, testen, die Abnahmeschritte entwerfen, die ein Mensch beobachten kann. Eine fehlgeschlagene Prüfung behält ihre Belege und wird im Versuchslimit der Aufgabe repariert. | `architecture`: du prüfst die Architektur. `story`: eine Meldung je abgeschlossener Story. |
| 3. Ship | Vollständiges Code-Review, UX-Review, Dokumentation, fertiggestelltes und einem Menschen übergebenes Abnahmeprotokoll, Ergebnisse gelesen und jeder Fehler klassifiziert, Retrospektive. | `delivery`: du prüfst das Endergebnis, mit zitiertem Lauf. |

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.

<a id="autopilot-state"></a>
### 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.

<a id="parallel"></a>
## 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.

**Was parallel laufen kann und was nicht**

| Parallelisierbar | Nur nacheinander |
| --- | --- |
| Stories ohne gemeinsame Datei | Stories, die dieselben Dateien ändern |
| Unabhängige Recherchen (Markt und Technik) | Eine Aufgabe, deren Eingabe die Ausgabe einer anderen ist |
| Tests, während die Dokumentation entsteht | Architekturentscheidungen vor der Implementierung |
| Änderungen an getrennten Modulen oder Paketen | Code-Review nach der Implementierung |

**Die sechs Überwachungsaktionen**

| Aktion | Wann | Was geschieht |
| --- | --- | --- |
| Launch | Unabhängige Aufgaben erkannt | Parallele Agent-Sitzungen starten. |
| Monitor | Fortlaufend | Den Fortschritt im Nexus-Lauf verfolgen. |
| Pause | Konflikt erkannt | Den kollidierenden Agent anhalten. |
| Restart | Nach Lösung des Konflikts | Den bestehenden Versuch und seine Wirkungen abgleichen, dann im erfassten Limit mit neuer Host-Identität wiederholen. |
| Reallocate | Ein Agent wird früher fertig | Die nächste Aufgabe der Warteschlange zuweisen. |
| Escalate | Versuchslimit erreicht oder Abgleich blockiert | Den ungelösten Zustand und die Belege melden; unabhängige, erlaubte Arbeit fortsetzen. |

<a id="durable-runtime"></a>
## 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.

**Ausführung, Verifikation, Akzeptanz**

| Ergebnis | Wer es feststellt | Was es bedeutet |
| --- | --- | --- |
| Ausführung | Ein identifizierter Host meldet `completed`, `failed`, `blocked` oder `ambiguous`; oder ein ursprünglicher Supervisor im Vordergrund sammelt das reale Ergebnis seines Kindprozesses ein. | Eine Beobachtung. Keine unabhängige Verifikation. |
| Verifikation | Nexus führt die Prüfbefehle des Plans selbst aus, mit wörtlichen Argument-Arrays und ohne Shell, erfasst Exit-Codes und begrenzte Ausgabe und vergleicht Schnappschüsse von Artefakten und Schreibbereich davor und danach. | Das Ergebnis besteht die unabhängigen Prüfungen, mit Belegen. |
| Akzeptanz | Ein getrennter, serialisierter Vorgang prüft aktuelle Artefakte, Ressourcen-Hashes und Abhängigkeitsbelege erneut. | Der aktuelle Arbeitsstand wird akzeptiert. Es erfolgt kein Git-Commit, kein Merge, keine Kopie und kein Deployment. |

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.

<a id="plan-format"></a>
## 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.

**nexus-plan.json**

```json
{
  "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."]
    }
  ]
}
```

**Felder einer Aufgabe**

| Feld | Bedeutung |
| --- | --- |
| `id`, `objective`, `acceptance` | Kennung, was zu erzeugen ist, und die Bedingungen, die gelten müssen. |
| `dependsOn` | Aufgaben, die aktuelle akzeptierte Belege haben müssen, bevor diese beginnt. |
| `scope` | Dateien oder Ordner, die die Aufgabe schreiben darf. Die Scopes aller Aufgaben sind exklusiv und paarweise disjunkt, auch zwischen aufeinanderfolgenden Aufgaben. |
| `artifacts` | Dateien, die das Ergebnis bilden; ihre Hashes werden erfasst. |
| `resources` | Jede dem Host gelieferte Anweisung und Hilfsdatei, von Nexus gehasht. Sie müssen außerhalb des Schreibbereichs jeder Aufgabe liegen. Nexus kann nichts bezeugen, was nicht deklariert ist. |
| `checks` | Bis zu 30 pro Aufgabe: `command` (`node` oder ein absoluter Pfad einer ausführbaren Datei, deren Bytes an den Plan gebunden werden), `args`, `cwd`, `timeoutMs` (10 bis 300000). Dateiargumente müssen deklarierte Ressourcen sein. |
| `maxAttempts`, `deadlineMs`, `idempotent` | Versuchslimit (höchstens 10), Frist und ob eine Wiederholung ohne besondere Beobachtung sicher ist. |
| `authorizations` | Text zur bestehenden Berechtigung. Ein Arbeiter kann sie nicht ändern oder eine Freigabeabfrage beantworten. |
| `execution` | Optionaler Vertrag für eine prozessgestützte Aufgabe (siehe unten). Ohne ihn gehört die Aufgabe dem Host. |

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.

<a id="cli-flow"></a>
## 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.

**swarm/page-fanout.json (die Schwarm-Definition)**

```json
{
  "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."
}
```

**swarm/units.json (die drei Einheiten)**

```json
{
  "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" }
  ]
}
```

**swarm/briefs/page.md (die Briefing-Vorlage)**

```md
# 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}}
```

**host.json (Identität des Arbeiters und seiner Sitzung)**

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

**Eine Host-Aufgabe von der Anlage bis zur Akzeptanz**

```text
$ 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.
```

Ausgabe eines echten Laufs. Quelle: bmad-plus 0.23.0, 2026-10-19

**rec.json (was der Host meldet; die Versuchs-ID stammt aus start)**

```json
{
  "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.

<a id="interruption"></a>
## Unterbrechung, Abbruch und Wiederholung

**Befehle für die schwierigen Fälle**

| Befehl | Eingabedatei | Was er tut |
| --- | --- | --- |
| `nexus cancel RUN TASK` | `{ "reason": "..." }` (Host); exakte `attemptId`, `backend` und `reason` (Prozess) | Erfasst eine Anfrage. Ein Host-Versuch signalisiert keine PID und kein Terminal; der Host stoppt nur seine eigene Operation. Die Kapazität bleibt bis zum Abgleich belegt. |
| `nexus reconcile RUN TASK` | Der Versuch, `outcome` (`completed`, `failed` oder `cancelled`), `ownerStopped: true`, `retrySafe`, `summary` | Schließt einen unsicheren Versuch mit einer Operator-Beobachtung. Es ist eine Beobachtung, nie ein unabhängiger Beleg, dass der Besitzer gestoppt hat. |
| `nexus retry RUN TASK` | Eine neue Host-Identität | Startet nach dem Abgleich einen neuen Versuch. Er verbraucht `maxAttempts`; eine neue Sitzung setzt das Limit nicht zurück. Nicht idempotente Aufgaben brauchen außerdem `retrySafe: true`. |
| `nexus recover-lock` | Der exakte Sperr-Hash aus `inspect`, `ownerStopped: true`, eine nicht leere `note` | Entfernt eine unterbrochene Schreibsperre, nachdem du ihren Besitzer geprüft hast. Ein lebender lokaler Schreiber verhindert das Entfernen. Nie automatisch. |

<a id="process-backend"></a>
## 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.

**Eine Aufgabe mit dem generischen Befehlsadapter (execution-Objekt)**

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

**Der Adapter für das installierte Codex CLI**

```json
{
  "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.

<a id="limits"></a>
## Grenzen und was nicht geschieht

**Unterstützte Grenzen**

| Grenze | Wert |
| --- | --- |
| Aufgaben pro Lauf | 200 |
| Aktive Versuche pro Lauf | 32 |
| Versuche pro Aufgabe | 10 |
| Prüfungen pro Aufgabe | 30 |
| Erlaubte Zeit pro Prüfung | 10 bis 300000 ms |
| Erfasste Ausgabe pro Prüfung | 64 KiB (Kürzung wird markiert) |
| Dateien pro Scope-Schnappschuss; Größe einer erfassten Datei | 10000; 16 MiB |
| JSON-Eingabedateien | Höchstens 1 MiB, reguläre Dateien |

- 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.

<a id="example-nexus-autopilot-idea"></a>
### Nexus ein kleines Projekt mit Checkpoints führen lassen

Nutze es zu Beginn eines Projekts, mit `execution_mode` auf `manual` oder `hybrid`, damit du die Freigaben behältst.

**In deinem KI-Assistenten**

```text
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.
```

**Das solltest du erhalten** Zuerst läuft Discovery (Briefing, PRD, UX-Spezifikation) und hält am Checkpoint `discovery` mit etwas Lesbarem an. Nach deiner Freigabe schreibt Forge die Architektur, und Nexus hält erneut an. Danach werden Stories nacheinander implementiert und getestet; mit den Standard-Checkpoints wartet jede fertige Story außerdem auf deine Freigabe (`story`), es sei denn, du stellst sie auf `notify_only`, und die finale Auslieferung hält zu deiner Prüfung an (`delivery`). Eine fehlschlagende Prüfung wird im Versuchslimit repariert statt durchgewunken. Der Schlussbericht nennt, was verifiziert wurde und was offen bleibt.

<a id="example-nexus-parallel-split"></a>
### Genehmigte Arbeit in unabhängige Aufgaben aufteilen

Nutze es, wenn die Stories vorliegen. Der Host muss Sub-Agenten unterstützen, damit es echte Parallelität gibt; sonst laufen die Aufgaben nacheinander.

**In deinem KI-Assistenten**

```text
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.
```

**Das solltest du erhalten** Ein `nexus-plan.json` mit disjunkten Scopes und unabhängigen Prüfungen, ein von `nexus inspect` gelisteter Nexus-Lauf (jede Aufgabe `not started; verification=pending; acceptance=pending`) und danach eine Statuszeile je Aufgabe im Verlauf der Arbeit. Eine Aufgabe mit fehlschlagender Prüfung zeigt `verification=failed` und kann nicht akzeptiert werden; ein Konflikt hält die kollidierende Aufgabe an, statt sie zu überschreiben.

**Siehe auch**

- [Referenz: bmad-plus nexus](https://bmad-plus.rochetta.fr/de/docs/reference/cli-nexus/)
- [Schwärme aus Sub-Agenten](https://bmad-plus.rochetta.fr/de/docs/concepts/swarm/)
- [Code-Review und menschliche Abnahme](https://bmad-plus.rochetta.fr/de/docs/concepts/code-review-and-acceptance/)
- [Referenz: config.yaml](https://bmad-plus.rochetta.fr/de/docs/reference/config-yaml/)
- [Datenverarbeitung](https://bmad-plus.rochetta.fr/de/docs/security/data-handling/)

[BMAD+ Dokumentation](https://bmad-plus.rochetta.fr/de/docs/) · [Konzepte](https://bmad-plus.rochetta.fr/de/docs/concepts/)

[Quellcode auf GitHub](https://github.com/lrochetta/BMAD-PLUS)