# nexus > Dauerhafte Task-Läufe: ein Plan aus Aufgaben mit disjunkten Schreibbereichen, nach einer Unterbrechung wiederherstellbare Versuche, unabhängige Prüfung und ein getrennter Abnahmeschritt. Canonical: https://bmad-plus.rochetta.fr/de/docs/reference/cli-nexus/ Language: de BMAD+ version: 0.23.1 Documentation reviewed: 2026-10-19 Author: Laurent Rochetta License: MIT BMAD+ Dokumentation › [Referenz](https://bmad-plus.rochetta.fr/de/docs/reference/) › nexus Wenn mehrere Aufgaben erledigt werden müssen und du den Beleg willst, dass jede erledigt wurde, kann der Agent Nexus sie in einem dauerhaften Lauf führen. Der Befehl `nexus` ist das Register dieses Laufs. Du beschreibst die Aufgaben in einem JSON-Plan; jede Aufgabe besitzt einen Ordner oder eine Datei, die sie schreiben darf (ihren Schreibbereich), und eine Liste von Prüfbefehlen, die entscheiden, ob ihr Ergebnis akzeptabel ist. Das Register hält fest, wer was versucht hat (ein Versuch), bewahrt den Zustand über Abstürze hinweg, führt die Prüfungen selbst aus und lässt dich die Aufgabe erst danach abnehmen. Ein Worker, der „fertig“ sagt, ist nie ein Beleg: die Prüfungen sind es. Diese Seite ist für alle, die Nexus von Hand oder aus CI steuern oder wissen wollen, was der Agent im Hintergrund tut. ## Syntax **Im Terminal deines Projekts** ```sh npx bmad-plus nexus create --plan [--json] [-d ] npx bmad-plus nexus inspect [run] [--json] [-d ] npx bmad-plus nexus recover-lock --input [--json] [-d ] npx bmad-plus nexus [--input ] [--json] [-d ] ``` **Optionen von nexus** | Option | Argument | Standard | Was sie tut | | --- | --- | --- | --- | | `-d, --directory ` | Ordner | aktueller Ordner | Das Projekt, das den Lauf enthält. | | `--plan ` | JSON-Datei | keine | Der Aufgabenplan. Nur `create` nimmt ihn. | | `--input ` | JSON-Datei | keine | Host-Identität, Beobachtung oder Wiederholungsanfrage für eine Aktion, die eine Aufgabe verändert, oder die Lock-Beobachtung für `recover-lock`. Reguläre Datei, höchstens 1 MiB, JSON-Objekt. | | `--json` | - | aus | Gibt den dauerhaften Zustand und die Belege als JSON statt der Kurzfassung aus. | ## Die Aktionen **Nexus-Aktionen** | Aktion | Argumente | Eingabedatei | Was sie tut | | --- | --- | --- | --- | | `create` | `--plan FILE` | nein (nutzt `--plan`) | Prüft den Plan und legt den Lauf an. Lehnt eine bestehende Lauf-ID ab. | | `inspect` | `[RUN]` | nicht erlaubt | Nur lesend. Ohne ID: Läufe und Lock-Zustand auflisten. Mit ID: Aufgaben, Versuche, Belege und Beobachtungen. | | `recover-lock` | - | erforderlich | Entfernt ausdrücklich ein verwaistes Schreib-Lock, nachdem du bestätigt hast, dass sein Besitzer gestoppt ist. | | `start` | `RUN TASK` | erforderlich | Eröffnet einen Versuch für eine vom Host getragene Aufgabe, gebunden an ein exaktes Host-Handle und eine exakte Sitzung. | | `launch` | `RUN TASK` | optional | Startet das Prozess-Backend der Aufgabe im Vordergrund und wartet. Mit `{"retry":true}` entsteht ein neuer Versuch. | | `collect` | `RUN TASK` | erforderlich | Nimmt den Beleg eines gestarteten Prozess-Versuchs entgegen (exakte Versuchs-ID und Backend). | | `record` | `RUN TASK` | erforderlich | Ein Host meldet das Ergebnis seines Versuchs: `completed`, `failed`, `blocked` oder `ambiguous`. | | `reconcile` | `RUN TASK` | erforderlich | Schließt einen unterbrochenen oder abgebrochenen Versuch als `completed`, `failed` oder `cancelled` ab, nachdem seine Wirkungen geprüft sind. | | `verify` | `RUN TASK` | nicht erlaubt | Führt die Prüfbefehle des Plans aus und hält echte Belege fest. | | `retry` | `RUN TASK` | erforderlich | Eröffnet nach einem abgeglichenen Fehlschlag einen neuen Versuch, im Rahmen des Versuchsbudgets. | | `cancel` | `RUN TASK` | erforderlich | Hält eine Abbruchanfrage mit Begründung fest. Signalisiert keinen Prozess des Hosts. | | `accept` | `RUN TASK` | nicht erlaubt | Nimmt den aktuellen Arbeitsstand für die Aufgabe ab, nachdem die Belege erneut geprüft wurden. | ## Ausführung, Prüfung, Abnahme Nexus hält drei Fragen auseinander. Ausführung: Ist der Worker fertig? Ein Host meldet es mit `record`, oder der Vordergrund-Supervisor erfasst das echte Ende des von ihm gestarteten Prozesses. Prüfung: Besteht die Arbeit die Checks des Plans? Nexus führt sie selbst aus, mit wörtlichen Argumenten und ohne Shell, und vergleicht die deklarierten Artefakte und den ganzen Schreibbereich davor und danach. Abnahme: Ist der aktuelle Arbeitsstand noch der, der bestanden hat? `accept` prüft Artefakt-Hashes, geschützte Ressourcen und den abgenommenen Zustand jeder Abhängigkeit erneut. Ein fehlgeschlagener Check verhindert die Abnahme, auch wenn der Worker erfolgreich war. Nexus macht nie Commits, Merges, Dateikopien oder Deployments. ## Die Plandatei **Ein minimaler Plan mit einer Aufgabe** ```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"], "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."] } ] } ``` **Planfelder und ihre Regeln** | Feld | Regel | | --- | --- | | `id` | Lauf-ID: 1 bis 64 Kleinbuchstaben, Ziffern, `_` oder `-`. Dieselbe Regel gilt für Aufgaben-IDs. | | `maxParallel` | Zwischen 1 und 32 gleichzeitig aktive Versuche. | | `config` | Nur nicht geheime primitive Einstellungen. Schlüssel, die nach Geheimnissen aussehen, werden abgelehnt. | | `tasks` | 1 bis 200 Aufgaben. IDs eindeutig; Abhängigkeiten müssen existieren und dürfen keinen Zyklus bilden. | | `objective`, `acceptance` | Was die Aufgabe liefern muss und welche Aussagen das Ergebnis erfüllen muss. | | `dependsOn` | IDs der Aufgaben, die zuerst abgenommen sein müssen. | | `scope` | Dateien oder Ordner, die der Worker schreiben darf. Bereiche verschiedener Aufgaben müssen disjunkt sein, auch wenn eine von der anderen abhängt. Nie `.git` oder der eigene Zustand von Nexus. | | `artifacts` | Dateien, die beim Prüfen im Schreibbereich der Aufgabe existieren müssen. | | `resources` | Geschützte Dateien: der Prüfer und jede dem Worker gegebene Anweisungsdatei. Sie werden gehasht und müssen außerhalb jedes Bereichs liegen. | | `checks` | 1 bis 30 pro Aufgabe. `command` ist `node` oder ein absoluter Pfad einer ausführbaren Datei; `args` ist ein wörtliches Array; jedes Dateiargument muss eine deklarierte Ressource sein; `timeoutMs` von 10 bis 300000. | | `maxAttempts` | 1 bis 10. Auch die Prüfrunden sind dadurch begrenzt. | | `deadlineMs` | 100 bis 86400000. Eine Frist ist eine Beobachtung, kein Beweis, dass die Arbeit stoppte. | | `idempotent` | Boolesch. Eine nicht idempotente Aufgabe braucht vor einem Retry einen ausdrücklichen Abgleich mit `retrySafe: true`. | | `authorizations` | Aussagen darüber, was erlaubt wurde. Worker können sie nicht ändern. | | `execution` | Optional. Wählt ein Prozess-Backend statt eines Hosts (siehe unten). | ## Backends: Host oder Prozess Standardmäßig gehört eine Aufgabe dem Host: Dein Assistent erledigt die Arbeit mit seinen eigenen Werkzeugen und meldet Nexus das Ergebnis mit `record`. Danach prüft Nexus. Ein `execution`-Objekt macht die Aufgabe zur Prozess-Aufgabe: `launch` startet das Programm im Vordergrund, wartet darauf und speichert einen prüfsummengesicherten Beleg dessen, was wirklich geschah. Es gibt zwei Adapter. **Ausführungsadapter** | Adapter | Felder | Hinweise | | --- | --- | --- | | `command` | `command`, `args`, `cwd`, `input`, `resources`, `blockedExitCodes`, `outputLimitBytes` | Du lieferst den Befehl; er wird nie aus dem Aufgabentext abgeleitet. Die ausführbare Datei ist per SHA-256 fixiert. Exit 0 bedeutet abgeschlossen; ein in `blockedExitCodes` gelisteter Code bedeutet blockiert. Keine Shell, keine Umgebungs-Überschreibung. | | `codex-exec` | `command` (absoluter Pfad des installierten `codex`), `input`, `instructions`, `sandbox`, optional `model` | Startet die installierte Codex-CLI nicht interaktiv. `sandbox` ist `read-only` (Standard) oder `workspace-write`. Abschluss verlangt Exit 0 plus die Ereignisse für Thread-Start und Turn-Ende; nur ein ausdrücklicher Fehler `approval_required` wird zu blockiert. | > **Warnung · Keine Sandbox** Worker teilen dein Projekt und deinen Betriebssystem-Benutzer. Sie können ihren deklarierten Bereich ignorieren; Prüfsummen erkennen versehentliche Änderungen, sind aber keine Signaturen. Es gibt keinen Daemon, keinen Scheduler und keine Prozessbaum-Überwachung: Jedes `launch` ist ein Vordergrundbefehl. `workspace-write` ist eine Bitte an den installierten Codex-Host, keine Nexus-Sandbox. Nutze ein isoliertes Projekt oder eine Host-Richtlinie, wenn der Worker nicht vertrauenswürdig ist. ## Grenzen **Unterstützte Grenzen** | Grenze | Wert | | --- | --- | | Aufgaben pro Lauf | 200 | | Aktive Versuche pro Lauf | 32 | | Versuche pro Aufgabe | 10 | | Checks pro Aufgabe | 30 | | Zeit pro Check | 10 bis 300000 ms | | Erfasste Ausgabe pro Check | 64 KiB | | Dateien in einem Bereichs-Snapshot | 10000, jede höchstens 16 MiB | | Zustandsdatei eines Laufs | 16 MiB | | Eingabe- und Plandateien | 1 MiB, reguläre Datei, kein symbolischer Link | ## Was gelesen und geschrieben wird - Zustand: `.bmad-plus/nexus/runs/.json`, ein prüfsummengesicherter Umschlag, geschrieben über eine auf Platte geleerte temporäre Datei und ein atomares Umbenennen. - Sperren: `.bmad-plus/nexus/writer.lock` (eine Änderung zur Zeit) und bei einer außerordentlichen Wiederherstellung `.bmad-plus/nexus/recovery.lock`. Eine entfernte Sperre wird unter `.bmad-plus/nexus/lock-recovery/` archiviert. - `inspect` schreibt nichts und funktioniert weiter, während eine Prüfung läuft. Alle anderen Aktionen außer `create` verändern einen bestehenden Lauf; `create` legt ihn an. - Liest deinen Plan und deine Eingabedateien, die deklarierten Ressourcen und Artefakte und macht Snapshots der Schreibbereiche. Die Prüfung führt deine Prüfbefehle aus; `launch` startet den Prozess der Aufgabe. Das sind die einzigen Prozesse, die Nexus startet, und nur auf deinen Aufruf. - Prüfbefehle erhalten eine minimale Umgebung (`PATH`, `SYSTEMROOT`, `WINDIR`, `TEMP`, `TMP`, `TMPDIR` sowie feste Locale `C` und Zeitzone `UTC`). Zugangsdaten und `NODE_OPTIONS` werden nicht weitergegeben. Lege keine Geheimnisse in Argumente oder Ausgaben. ## Exit-Codes **Exit-Codes von nexus** | Code | Bedeutung | | --- | --- | | 0 | Die Aktion war erfolgreich. | | 1 | `verify` bestand nicht; `launch` endete nicht mit `completed`; `collect` endete nicht mit `completed`; oder ein beliebiger Fehler. Ein Code ungleich null bei `launch` oder `collect` sagt, was der Prozess tat, nie, dass die Aufgabe akzeptabel ist. | ## Die Ausgabe lesen Der kürzeste vollständige Durchlauf braucht drei kleine Dateien neben `nexus-plan.json`. Der Prüfer ist derjenige, den der Plan als Ressource deklariert; `host.json` ist die Identität, die dein Assistent `start` übergibt; `rec.json` ist das Ergebnis, das er `record` meldet, mit der Versuchs-ID, die `start` ausgegeben hat. **checks/check-result.cjs, der Prüfer** ```text const fs = require("node:fs"); const text = fs.readFileSync("work/result.txt", "utf8"); if (!text.includes("done")) { console.error("work/result.txt must contain done"); process.exit(1); } ``` **host.json, an start übergeben** ```json { "backend": { "kind": "host", "id": "my-assistant", "sessionId": "session-1" } } ``` **rec.json, an record übergeben (die Versuchs-ID ist die, die start ausgegeben hat)** ```json { "attemptId": "c3bbafd1-62ef-4b8b-ac72-0d9b09932427", "backend": { "kind": "host", "id": "my-assistant", "sessionId": "session-1" }, "outcome": "completed", "summary": "Wrote work/result.txt." } ``` **Einen Lauf anlegen, starten, erfassen, prüfen und abnehmen** ```text $ npx bmad-plus nexus create --plan nexus-plan.json Nexus run example — durable task coordination result: not started; verification=pending; acceptance=pending Use inspect --json for recorded evidence and reconciliation observations. $ npx bmad-plus nexus start example result --input host.json Nexus run example — durable task coordination result: running; verification=pending; acceptance=pending Attempt: c3bbafd1-62ef-4b8b-ac72-0d9b09932427; host: my-assistant/session-1 Use inspect --json for recorded evidence and reconciliation observations. $ npx bmad-plus nexus record example result --input rec.json Nexus run example — durable task coordination result: completed; verification=pending; acceptance=pending Attempt: c3bbafd1-62ef-4b8b-ac72-0d9b09932427; host: my-assistant/session-1 Use inspect --json for recorded evidence and reconciliation observations. $ npx bmad-plus nexus verify example result Nexus run example — durable task coordination result: completed; verification=passed; acceptance=pending Attempt: c3bbafd1-62ef-4b8b-ac72-0d9b09932427; host: my-assistant/session-1 Use inspect --json for recorded evidence and reconciliation observations. $ npx bmad-plus nexus accept example result Nexus run example — durable task coordination result: completed; verification=passed; acceptance=accepted Attempt: c3bbafd1-62ef-4b8b-ac72-0d9b09932427; host: my-assistant/session-1 Use inspect --json for recorded evidence and reconciliation observations. $ npx bmad-plus nexus inspect example Nexus run example — durable task coordination result: completed; verification=passed; acceptance=accepted Attempt: c3bbafd1-62ef-4b8b-ac72-0d9b09932427; host: my-assistant/session-1 Accept only after rechecking current artifacts and resources. Use inspect --json for recorded evidence and reconciliation observations. # Die Wörter nach „acceptance=“ und die zusätzlichen Hinweiszeilen hängen vom Zustand des Laufs ab; lies sie mit inspect --json. ``` Ausgabe eines echten Laufs. Quelle: Mit dem Paket 0.23.0 in einem Wegwerf-Git-Projekt nachgespielt; die Versuchs-ID ändert sich bei jedem Lauf `verify` direkt nach `create` wird abgelehnt, weil noch nichts erfasst wurde: `Nexus: Nexus: Verification requires completed, unaccepted, reconciled work.` Starte und erfasse zuerst, wie oben. Beachte das doppelte Präfix: Die eigenen Meldungen der Laufzeit beginnen bereits mit `Nexus:`, und der Befehl fügt sein eigenes hinzu. Jede Aufgabenzeile lautet `: ; verification=; acceptance=`, gefolgt vom letzten Versuch mit seinem Backend. `inspect --json` ergänzt pro Aufgabe `resourcesCurrent`, `evidenceEligible`, `stale`, `staleReason` und `overdue`, damit ein alter abgenommener Eintrag nicht behaupten kann, später bearbeitete Dateien bestünden noch. Im JSON-Modus werden Fehler als `{"schemaVersion":1,"status":"error","error":"..."}` ausgegeben. ## Unterbrechungen, Abbruch, Wiederholungen - Ein unterbrochener oder getrennter Versuch behält seine Kapazität, bis `reconcile` ihn abschließt. Die Beobachtung verlangt `ownerStopped: true`, eine Aussage von dir, dass du geprüft hast, keine Telemetrie. Bei einer nicht `idempotent`en Aufgabe braucht ein Retry zusätzlich `retrySafe: true`. - `cancel` hält nur eine Anfrage fest. Bei einer Host-Aufgabe stoppt der Host seine eigene Arbeit; bei einer Prozess-Aufgabe darf nur der ursprüngliche Vordergrund-Supervisor dem von ihm erzeugten Kindprozess Signale senden. Nexus tötet nie eine gespeicherte PID. - `retry` (oder `launch` mit `{"retry":true}`) eröffnet einen neuen Versuch und verbraucht `maxAttempts`. Eine neue Backend-Sitzung setzt das Limit nicht zurück. - Eine Prüfung mit Zeitüberschreitung wird als mehrdeutig festgehalten, weil Nachkommen des Checks noch Wirkung haben könnten. Inspiziere vor einem Retry. - `recover-lock` nimmt den exakten Lock-Hash aus `inspect`, `ownerStopped: true` und eine nicht leere `note`. Ein lebender lokaler Schreiber blockiert es. Das Alter allein erlaubt nie das Entfernen. ## Fehler und was zu tun ist Fehler erscheinen als `Nexus: ` auf dem Fehlerstrom. Die eigenen Meldungen der Laufzeit beginnen bereits mit `Nexus:`, daher zeigen die meisten Fehler das Präfix doppelt (`Nexus: Nexus: Run ID must use ...`). **Fehler von nexus** | Meldung | Ursache | Was tun | | --- | --- | --- | | `Use nexus create --plan FILE, inspect RUN, or start\|launch\|collect\|record\|reconcile\|verify\|retry\|cancel\|accept RUN TASK.` | Unbekannte Aktion oder fehlende Lauf-/Aufgaben-IDs. | Syntax prüfen. | | `--plan requires a JSON file.` / `--input requires a JSON file.` | Die Option fehlt bei einer Aktion, die sie braucht. | Datei ergänzen; siehe Aktionstabelle. | | `--input must name a regular JSON file no larger than 1 MiB.` | Keine reguläre Datei, ein symbolischer Link oder zu groß. | Eine einfache JSON-Datei verwenden. | | `verify executes its recorded contract and takes no input file.` | `--input` bei `verify` oder `accept` angegeben. | `--input` weglassen. | | `Overlapping exclusive write scopes: and ` | Zwei Aufgaben teilen einen Pfad in ihren Bereichen. | Bereiche disjunkt machen. | | `Verifier/resource lies in a worker write scope: ` | Eine geschützte Datei liegt im Bereich einer Aufgabe. | Den Prüfer außerhalb jedes Bereichs ablegen. | | `Run already exists; inspect it instead.` | `create` mit bestehender Lauf-ID. | `inspect` nutzen oder eine neue Plan-ID. | | `Stale or missing attempt identity.` / `Backend handle/session does not own this attempt.` | Die Eingabe nennt einen anderen Versuch, ein anderes Handle oder eine andere Sitzung. | Exakte Versuchs-ID und Backend aus `start` oder `launch` kopieren. | | `Protected verifier or agent resource changed since the plan was created.` | Eine deklarierte Ressource wurde nach `create` bearbeitet. | Wiederherstellen oder einen neuen Lauf aus aktualisiertem Plan anlegen. | | `Dependency has not been accepted: ` | Eine Abhängigkeit ist noch nicht abgenommen. | Zuerst die Abhängigkeit prüfen und abnehmen. | | `Run capacity is occupied until active work is reconciled.` | Aktive oder unterbrochene Versuche füllen `maxParallel`. | Erfassen, aufzeichnen oder abgleichen. | | `Another mutation owns writer.lock; inspect before explicit recovery.` | Ein anderer Befehl läuft, oder einer wurde beendet. | Warten; bei Abbruch `inspect`, dann `recover-lock`. | | `Corrupt or foreign run state; original bytes were preserved.` | Die Lauf-Datei passt nicht zu ihrer Prüfsumme. | Datei aus einer Sicherung wiederherstellen; nichts wird automatisch repariert. | | `Current attempt has no eligible passed verification.` | `accept` vor einem bestandenen `verify`. | `verify` ausführen; bei Fehlschlag die Arbeit korrigieren. | | `Stale evidence: checked artifacts or write scope changed.` | Dateien änderten sich nach der Prüfung. | Erneut prüfen. | ## Beispiele ### Arbeit aufteilen und jeden Teil belegen Drei unabhängige Änderungen berühren verschiedene Ordner. Jede soll durch einen von dir geschriebenen Check belegt werden, nicht durch das Wort des Workers. **In deinem KI-Assistenten** ```text Nexus, teile die freigegebene Arbeit in unabhängige Aufgaben auf, jede mit eigenem Schreibordner und einem Prüfbefehl, den ich ausführen kann. Lege mit `bmad-plus nexus create` einen dauerhaften Lauf an, starte pro Aufgabe einen Versuch und nimm nichts ab, bevor `bmad-plus nexus verify` dafür bestanden hat. ``` **Das solltest du erhalten** Nexus schreibt einen Plan mit disjunkten Bereichen und führt `create` aus, das überlappende Bereiche oder einen Prüfer innerhalb eines Bereichs ablehnt. Für jede Aufgabe erledigt der Host die Arbeit und meldet das Ergebnis; `verify` führt deinen Check aus und speichert den Beleg; `accept` gelingt nur bei aktuellen Belegen. Eine Aufgabe mit fehlgeschlagenem Check bleibt unabgenommen und kann im Rahmen von `maxAttempts` wiederholt werden. ### Nach einem Absturz wiederherstellen Der Rechner wurde neu gestartet, während eine Aufgabe lief. Du weißt nicht sicher, ob der Worker noch Dateien offen hält. **In deinem KI-Assistenten** ```text Nexus, inspiziere den Lauf `release-prep` mit `bmad-plus nexus inspect release-prep --json`. Sag mir, welche Versuche ungeklärt sind und was ich prüfen muss, bevor du sie abgleichst. Wiederhole nichts auf eigene Faust. ``` **Das solltest du erhalten** `inspect` ist nur lesend und meldet jeden Versuch mit seinem Backend, dem festgehaltenen Ergebnis und den Beobachtungen (`stale`, `overdue`). Ungeklärte Versuche behalten ihre Kapazität. Hast du die Wirkungen geprüft und bestätigst, dass der Besitzer gestoppt ist, hält `reconcile` `completed`, `failed` oder `cancelled` fest; erst dann kann ein Retry einen neuen Versuch eröffnen. Blieb ein Schreib-Lock zurück, zeigt `inspect` ohne Lauf-ID seinen Hash für `recover-lock`. **Siehe auch** - [CLI im Überblick und Exit-Codes](https://bmad-plus.rochetta.fr/de/docs/reference/cli-overview/) - [swarm: einen Fanout als Nexus-Plan exportieren](https://bmad-plus.rochetta.fr/de/docs/reference/cli-swarm/) - [uat: das Abnahme-Gate als Check](https://bmad-plus.rochetta.fr/de/docs/reference/cli-uat/) - [Projektstruktur](https://bmad-plus.rochetta.fr/de/docs/reference/project-layout/) - [Fehlerbehebung](https://bmad-plus.rochetta.fr/de/docs/faq/troubleshooting/) [BMAD+ Dokumentation](https://bmad-plus.rochetta.fr/de/docs/) · [Referenz](https://bmad-plus.rochetta.fr/de/docs/reference/) [Quellcode auf GitHub](https://github.com/lrochetta/BMAD-PLUS)