@the-bearded-bear/claude-craft 8.23.3 → 8.26.0-next.2a54921

package/Dev/i18n/de/QA/commands/status.md

@@ -1,6 +1,6 @@
 ---
-description: "QA Recette Sitzungsstatus und Fortschritt anzeigen"
-argument-hint: "[--session=<id>|--all] [--scope=<story|sprint>] [--status=<running|completed|paused|failed>]"
+description: "QA Recette Sitzungsstatus und Fortschritt anzeigen oder Berichte erzeugen (--report)"
+argument-hint: "[--session=<id>|--all] [--scope=<story|sprint>] [--status=<running|completed|paused|failed>] [--report] [--format=<md|html|json>] [--output=<path>] [--compare=<id>]"
 ---
 
 # QA Recette Status - Sitzungsstatus und Fortschritt
@@ -17,6 +17,11 @@ Zeigt den Status und Fortschritt von QA Recette Sitzungen an. Einzelne Sitzungsd
 - `--status=<status>` : Nach Status filtern (running, completed, paused, failed)
 - `--format=<type>` : Ausgabeformat (table, yaml, json) — Standard: table
 - `--watch` : Live-Aktualisierungsmodus (alle 5 Sekunden)
+- `--report`: Berichtsmodus (ehemals `/qa:status --report`): Bericht aus einer Sitzung erzeugen; erfordert `--session=<id>`
+- `--format=<type>`: mit `--report`: md, html, json (Standard: md)
+- `--output=<path>`: mit `--report`: benutzerdefinierter Ausgabepfad (Standard: `.recette/reports/`)
+- `--include-screenshots`: mit `--report`: Screenshots in den HTML-Bericht einbetten
+- `--compare=<id>`: mit `--report`: mit einer anderen Sitzung für ein Regressions-Diff vergleichen
 
 ## Hauptfunktionen
 
@@ -83,6 +88,128 @@ Generierte Regressionstests: 3
 Behebungsstatus: completed (2/2 Bugs behoben)
 ```
 
+## Verwendung
+
+| Modus / Option | Was es tut | Ersetzt |
+|---|---|---|
+| `/qa:status --all` / `--session=<id>` | Sitzungen auflisten oder eine Sitzung im Detail anzeigen | — |
+| `/qa:status --report --session=<id>` | Markdown-/HTML-/JSON-Bericht erzeugen (`--format`, `--output`, `--include-screenshots`) | `/qa:status --report` |
+| `/qa:status --report --session=<id> --compare=<id>` | Zwei Sitzungen vergleichen, um Regressionen zu erkennen | `/qa:status --report --compare` |
+
+## Berichtsmodus (--report)
+
+Erzeugt detaillierte Berichte aus den Sitzungsdaten. Ausgabe in mehreren Formaten (Markdown, HTML, JSON), Abschnitt zur Einhaltung der Golden Rule, eingebettete Screenshots, Rückverfolgbarkeit von Akzeptanzkriterien zu Tests und Erfolgs-/Fehlermetriken. Ohne `--format` ist der Bericht Markdown.
+
+### Berichtsprozess
+
+```
+┌─────────────────────────────────────────┐
+│  1. load_session_data(session_id)       │
+│     - Read .recette/sessions/{id}/      │
+│     - Load state.yaml                   │
+│     - Load fix-state.yaml if present    │
+│     - Collect screenshots and logs      │
+│     - Load regression registry          │
+├─────────────────────────────────────────┤
+│  2. generate_report(format)             │
+│     - Build summary, test results,      │
+│       error details, regression tests   │
+│     - Build Golden Rule statement       │
+│     - Apply format template             │
+│     - Write to output path              │
+└─────────────────────────────────────────┘
+```
+
+### Berichtsstruktur
+
+```markdown
+# QA Recette Report — REC-20260130-143022
+
+## Summary
+| Metric | Value |
+|--------|-------|
+| Session | REC-20260130-143022 |
+| Scope | story → US-001 |
+| Duration | 14m 48s |
+| Passed / Failed / Skipped | 12 (80%) / 2 (13%) / 1 (7%) |
+
+## Test Results
+### Failed Tests (2)
+- TC-008: Login validation error display ✗ (ERR-001)
+
+## Error Details
+### ERR-001: Login validation not displayed
+- Type: visual · Severity: medium · Screenshot: screenshots/err-001.png
+
+## Regression Tests Generated
+| ID | Error | Test Type | Path |
+|----|-------|-----------|------|
+| REG-001 | ERR-001 | behat | features/auth/login_validation.feature |
+
+## Golden Rule Compliance
+All detected errors have generated regression tests.
+Registry updated: .recette/regression/registry.yaml
+```
+
+### Vergleich (--compare)
+
+Vergleicht zwei Durchläufe: Metrik-Deltas, behobene Fehler, neue Fehler und Verstöße gegen die Golden Rule.
+
+```
+## Comparison: REC-20260130-143022 vs REC-20260201-140000
+
+| Metric | Session 1 | Session 2 | Delta |
+|--------|-----------|-----------|-------|
+| Passed | 12 | 14 | +2 |
+| Failed | 2 | 0 | -2 |
+
+### Resolved Errors / New Errors / Regression Status
+```
+
+### Datenquellen des Berichts
+
+| Quelle | Pfad | Beschreibung |
+|---|---|---|
+| Registry | `.recette/regression/registry.yaml` | Registry der Regressionstests |
+| Vorlage | `Tools/Recette/templates/report.md.template` | Berichtsvorlage |
+
+### Berichtsfehler
+
+| Fehler | Lösung |
+|---|---|
+| "Template not found" | Prüfen, ob `Tools/Recette/templates/` existiert |
+| "Compare session not found" | Die ID der Vergleichssitzung prüfen |
+| "No test results" | Die Sitzung hat keine abgeschlossenen Tests für den Bericht |
+
+### Berichtsbeispiele
+
+```bash
+# Markdown-Bericht erzeugen (Standard)
+/qa:status --report --session=REC-20260130-143022
+
+# HTML-Bericht mit Screenshots erzeugen
+/qa:status --report --session=REC-20260130-143022 --format=html --include-screenshots
+
+# JSON-Bericht für die CI-Integration erzeugen
+/qa:status --report --session=REC-20260130-143022 --format=json
+
+# Benutzerdefinierter Ausgabepfad
+/qa:status --report --session=REC-20260130-143022 --output=./reports/sprint-3/
+
+# Zwei Sitzungen vergleichen
+/qa:status --report --session=REC-20260201-140000 --compare=REC-20260130-143022
+```
+
+### Ausgabestruktur des Berichts
+
+```
+.recette/reports/
+├── REC-20260130-143022-report.md       # Markdown report
+├── REC-20260130-143022-report.html     # HTML report (if --format=html)
+├── REC-20260130-143022-report.json     # JSON report (if --format=json)
+└── REC-20260201-vs-20260130-diff.md    # Comparison report (if --compare)
+```
+
 ## Datenquellen
 
 | Quelle | Pfad | Beschreibung |
@@ -96,25 +223,25 @@ Behebungsstatus: completed (2/2 Bugs behoben)
 
 ```bash
 # Alle Sitzungen auflisten
-/qa:recette-status --all
+/qa:status --all
 
 # Detaillierten Status einer Sitzung anzeigen
-/qa:recette-status --session=REC-20260130-143022
+/qa:status --session=REC-20260130-143022
 
 # Laufende Sitzungen filtern
-/qa:recette-status --all --status=running
+/qa:status --all --status=running
 
 # Nach Umfang filtern
-/qa:recette-status --all --scope=sprint
+/qa:status --all --scope=sprint
 
 # Live-Ueberwachung einer Sitzung
-/qa:recette-status --session=REC-20260130-143022 --watch
+/qa:status --session=REC-20260130-143022 --watch
 
 # Ausgabe als YAML
-/qa:recette-status --session=REC-20260130-143022 --format=yaml
+/qa:status --session=REC-20260130-143022 --format=yaml
 
 # Ausgabe als JSON (fuer Scripting)
-/qa:recette-status --all --format=json
+/qa:status --all --format=json
 ```
 
 ## Ausgabestruktur
@@ -138,9 +265,9 @@ Behebungsstatus: completed (2/2 Bugs behoben)
 | Befehl | Beschreibung |
 |--------|--------------|
 | `/qa:recette` | Akzeptanztests ausfuehren |
-| `/qa:recette-fix` | Bugs aus einer Sitzung beheben |
-| `/qa:recette-regression` | Regressionstests anzeigen |
-| `/qa:recette-report` | Bericht generieren |
+| `/qa:fix` | Bugs aus einer Sitzung beheben |
+| `/qa:regression` | Regressionstests anzeigen |
+| `/qa:status --report` | Bericht erzeugen (`--report`) |
 
 ## Fehlermeldungen
 
@@ -170,7 +297,7 @@ Behebungsstatus: completed (2/2 Bugs behoben)
 ║    Identifizierte Bugs beheben                           ║
 ║                                                          ║
 ║  Wenn die Sitzung abgeschlossen ist:                     ║
-║  → /qa:report                                            ║
+║  → /qa:status --report                                   ║
 ║    Recette-Bericht generieren                            ║
 ║                                                          ║
 ╚══════════════════════════════════════════════════════════╝

package/Dev/i18n/de/QA/commands/tdd.md

@@ -397,7 +397,7 @@ Fixes #XXX
 ║    Nach Korrekturen erneut testen                        ║
 ║                                                          ║
 ║  Siehe auch:                                             ║
-║  • /common:pre-commit-check — Vor dem Commit validieren  ║
+║  • /gate:check commit — Vor dem Commit validieren  ║
 ║                                                          ║
 ╚══════════════════════════════════════════════════════════╝
 ```

package/Dev/i18n/de/Workflow/commands/analyze.md

@@ -1,209 +1,9 @@
 ---
-name: workflow-analyze
-description: Die Analysephase durchführen - Recherche, Exploration und Identifikation von Einschränkungen
-arguments:
-  - name: focus
-    description: Spezifischer Bereich zur Analyse (market, technical, competitors)
-    required: false
+description: "Veraltet (Entfernung in 9.0): /workflow:plan --research verwenden"
+deprecated: true
+replaced-by: /workflow:plan
 ---
 
-# /workflow:analyze
+> ⚠️ `/workflow:analyze` ist veraltet und wird in 9.0 entfernt. Verwenden Sie `/workflow:plan --research`.
 
-## Mission
-
-Die Analysephase des Enterprise-Workflow-Tracks durchführen. Diese Phase konzentriert sich auf Recherche, Exploration und die Identifikation von Einschränkungen, bevor die detaillierte Planung beginnt.
-
-## Wann verwenden
-
-- **Enterprise-Track**-Projekte
-- Neue Plattformen oder größere Initiativen
-- Wenn das Domänenwissen begrenzt ist
-- Vor der Festlegung auf einen technischen Ansatz
-
-## Plan-Modus
-
-> Der Plan-Modus wird automatisch aktiviert, wenn der Umfang mehrere Module umfasst oder eine modulübergreifende Untersuchung erfordert.
-
-## Workflow
-
-### Schritt 1: Analyse-Setup
-
-```
-╔══════════════════════════════════════════════════════════╗
-║            ANALYSEPHASE - START                           ║
-╠══════════════════════════════════════════════════════════╣
-║ Track: Enterprise                                         ║
-║ Phase: 1 von 4 - Analyse                                  ║
-║                                                           ║
-║ Ziele:                                                    ║
-║ • Die Problemdomäne verstehen                             ║
-║ • Bestehende Lösungen recherchieren                       ║
-║ • Technische Einschränkungen identifizieren               ║
-║ • Risiken und Chancen dokumentieren                       ║
-╚══════════════════════════════════════════════════════════╝
-```
-
-### Schritt 2: Recherchebereiche
-
-**Geführte Recherchefragen:**
-
-```
-┌─────────────────────────────────────────────────────────┐
-│ DOMÄNEN-RECHERCHE                                        │
-├─────────────────────────────────────────────────────────┤
-│ 1. Welches Problem lösen wir?                            │
-│ 2. Wer sind die wichtigsten Stakeholder?                 │
-│ 3. Was sind die geschäftlichen Treiber?                  │
-│ 4. Wie sieht Erfolg aus?                                 │
-└─────────────────────────────────────────────────────────┘
-
-┌─────────────────────────────────────────────────────────┐
-│ MARKT-RECHERCHE                                          │
-├─────────────────────────────────────────────────────────┤
-│ 1. Welche bestehenden Lösungen gibt es?                  │
-│ 2. Was machen die Wettbewerber?                          │
-│ 3. Was sind die Best Practices der Branche?              │
-│ 4. Welche aufkommenden Trends gibt es?                   │
-└─────────────────────────────────────────────────────────┘
-
-┌─────────────────────────────────────────────────────────┐
-│ TECHNISCHE RECHERCHE                                     │
-├─────────────────────────────────────────────────────────┤
-│ 1. Welche Technologien könnten wir einsetzen?            │
-│ 2. Welche Integrationsanforderungen gibt es?             │
-│ 3. Welche Skalierbarkeitsanforderungen bestehen?         │
-│ 4. Welche Sicherheits-/Compliance-Anforderungen gibt es? │
-└─────────────────────────────────────────────────────────┘
-```
-
-### Schritt 3: Context7-Recherche (Optional)
-
-Wenn MCP Context7 konfiguriert ist, für technische Recherche verwenden:
-
-```
-Context7 MCP für aktuelle Dokumentation verwenden...
-
-Recherche:
-• Neueste Stripe API Best Practices
-• Aktuelle Sicherheitsstandards für Zahlungsverarbeitung
-• PCI DSS Compliance-Anforderungen
-```
-
-### Schritt 4: Identifikation von Einschränkungen
-
-Entdeckte Einschränkungen dokumentieren:
-
-```
-╔══════════════════════════════════════════════════════════╗
-║          IDENTIFIZIERTE EINSCHRÄNKUNGEN                   ║
-╠══════════════════════════════════════════════════════════╣
-║                                                           ║
-║ TECHNISCHE EINSCHRÄNKUNGEN:                               ║
-║ • Muss in bestehendes Symfony 7.x Backend integriert werden║
-║ • Datenbank: PostgreSQL (bestehend, nicht änderbar)       ║
-║ • Muss Mobile Apps über bestehende API unterstützen       ║
-║                                                           ║
-║ GESCHÄFTLICHE EINSCHRÄNKUNGEN:                            ║
-║ • Budget: Auf bestehendes Team beschränkt                 ║
-║ • Zeitplan: MVP benötigt in Q2 2026                       ║
-║ • Abwärtskompatibilität muss erhalten bleiben             ║
-║                                                           ║
-║ REGULATORISCHE EINSCHRÄNKUNGEN:                           ║
-║ • DSGVO-Konformität erforderlich (EU-Benutzer)            ║
-║ • PCI DSS für Zahlungsverarbeitung                        ║
-║                                                           ║
-║ RESSOURCEN-EINSCHRÄNKUNGEN:                               ║
-║ • Team: 2 Backend-, 1 Frontend-Entwickler                 ║
-║ • Keine dedizierte DevOps-Ressource                       ║
-║                                                           ║
-╚══════════════════════════════════════════════════════════╝
-```
-
-### Schritt 5: Risiko- & Chancenanalyse
-
-```
-╔══════════════════════════════════════════════════════════╗
-║            RISIKEN & CHANCEN                              ║
-╠══════════════════════════════════════════════════════════╣
-║                                                           ║
-║ RISIKEN:                                                  ║
-║ ┌─────────┬──────────┬────────────┬───────────────────┐  ║
-║ │ Risiko  │ Auswirk. │ Wahrsch.   │ Maßnahme          │  ║
-║ ├─────────┼──────────┼────────────┼───────────────────┤  ║
-║ │ Stripe  │ Hoch     │ Niedrig    │ Fallback-Anbieter │  ║
-║ │ Ausfall │          │            │                   │  ║
-║ ├─────────┼──────────┼────────────┼───────────────────┤  ║
-║ │ Zeitplan│ Mittel   │ Mittel     │ MVP-Umfang        │  ║
-║ │ Verzug  │          │            │ reduzieren        │  ║
-║ └─────────┴──────────┴────────────┴───────────────────┘  ║
-║                                                           ║
-║ CHANCEN:                                                  ║
-║ • Stripe's neue Payment Elements nutzen                   ║
-║ • Potenzial für Abo-Modell-Erweiterung                    ║
-║ • Mobile Payment (Apple Pay, Google Pay) bereit           ║
-║                                                           ║
-╚══════════════════════════════════════════════════════════╝
-```
-
-### Schritt 6: Analyse-Artefakte erstellen
-
-Analysedokumente erstellen:
-
-```
-project-management/
-└── analysis/
-    ├── research-summary.md      # Wichtigste Ergebnisse
-    ├── constraints.md           # Alle identifizierten Einschränkungen
-    ├── risks-opportunities.md   # Risikoregister & Chancen
-    └── technical-options.md     # Technologiebewertung
-```
-
-### Schritt 7: Phasenabschluss
-
-```
-╔══════════════════════════════════════════════════════════╗
-║            ANALYSEPHASE ABGESCHLOSSEN                     ║
-╠══════════════════════════════════════════════════════════╣
-║                                                           ║
-║ Erstellte Artefakte:                                      ║
-║ ✅ research-summary.md                                    ║
-║ ✅ constraints.md                                         ║
-║ ✅ risks-opportunities.md                                 ║
-║ ✅ technical-options.md                                   ║
-║                                                           ║
-║ Wichtigste Ergebnisse:                                    ║
-║ • 4 technische Einschränkungen identifiziert              ║
-║ • 3 geschäftliche Einschränkungen identifiziert           ║
-║ • 5 Risiken mit Maßnahmen dokumentiert                    ║
-║ • 3 Chancen zur Berücksichtigung                          ║
-║                                                           ║
-║ ─────────────────────────────────────────────────────────║
-║ NÄCHSTE PHASE: Planung                                    ║
-║ Befehl: /workflow:plan                                    ║
-║ ─────────────────────────────────────────────────────────║
-║                                                           ║
-║ Die Analyse wird die PRD-Erstellung und Architektur       ║
-║ informieren.                                              ║
-╚══════════════════════════════════════════════════════════╝
-```
-
-## Beteiligte Agenten
-
-- **research-assistant**: Technische Recherche und Dokumentationssuche
-- **product-owner**: Geschäftskontext und Stakeholder-Analyse
-
-## Ausgabedateien
-
-| Datei | Zweck |
-|-------|-------|
-| `analysis/research-summary.md` | Zusammengefasste Rechercheergebnisse |
-| `analysis/constraints.md` | Technische, geschäftliche, regulatorische Einschränkungen |
-| `analysis/risks-opportunities.md` | Risikoregister mit Maßnahmen |
-| `analysis/technical-options.md` | Technologiebewertung und Empfehlungen |
-
-## Verwandte Befehle
-
-- `/workflow:init` - Workflow initialisieren (muss zuerst ausgeführt werden)
-- `/workflow:plan` - Nächste Phase: Planung
-- `/workflow:status` - Fortschritt prüfen
-- `/common:research-context7` - Vertiefte Recherche mit Context7 MCP
+Führen Sie `/workflow:plan --research $ARGUMENTS` aus: Lesen Sie `.claude/commands/workflow/plan.md` und folgen Sie der Datei mit diesen Argumenten.

package/Dev/i18n/de/Workflow/commands/auto-sprint.md

@@ -1,6 +1,6 @@
 ---
 description: End-to-End-Sprint-Orchestrator (Start -> Zerlegung -> Validierung -> Implementierung -> PR -> CI -> Review -> Retro -> Merge)
-argument-hint: "<N> [--auto-merge] [--max-fix-attempts=2] [--max-workers=3] [--base=main] [--dry-run] [--overnight]"
+argument-hint: "<N> [--from-prd] [--auto-merge] [--max-fix-attempts=2] [--max-workers=3] [--base=main] [--dry-run] [--overnight]"
 ---
 
 # Auto Sprint — End-to-End-Sprint-Orchestrator
@@ -14,8 +14,8 @@ Orchestrator-Kontext schlank bleibt. Die Implementierungsphase wird **von Ihnen
 Dies automatisiert, was zuvor sechs manuelle Befehle mit einem `/clear` dazwischen erforderte:
 
 ```
-/workflow:start N -> /project:decompose-tasks 00N -> /gate:validate-sprint 00N
--> /team:sprint "sprint-00N" -> /workflow:review N -> /workflow:retro N
+/workflow:start N -> /workflow:start N --tasks-only -> /gate:check sprint 00N
+-> /workflow:implement N -> /workflow:review N -> /workflow:retro N
 ```
 
 …und ergänzt dies um: Branch, Commit, Pull Request, CI-Überwachung und Merge.
@@ -25,6 +25,7 @@ Dies automatisiert, was zuvor sechs manuelle Befehle mit einem `/clear` dazwisch
 $ARGUMENTS
 
 - `<N>` : Sprint-Nummer (z.B. `5`). **Erforderlich.**
+- `--from-prd` : Vor Phase 1 wird `/workflow:plan --only=backlog` (Unter-Agent) ausgeführt, um das Backlog aus `project-management/prd.md` zu erzeugen; danach läuft die normale Pipeline weiter.
 - `--auto-merge` : Merge automatisch durchführen, sobald CI grün und DoD bestanden ist. **Standard: AUS** — der
   Befehl pausiert und wartet auf ein explizites menschliches GO vor dem Merge (berücksichtigt „review obligatoire",
   Regel 09, und das Karpathy-Prinzip „kein Auto-Merge ohne menschliche Review").
@@ -52,7 +53,7 @@ an jede Phase übergeben:
 | Phase | Erwartetes Format |
 |-------|-------------------|
 | `start`, `review`, `retro` | Reine Zahl `N` (z.B. `5`) |
-| `decompose-tasks` | Null-aufgefüllt `00N` (z.B. `005`) |
+| `start --tasks-only` | reines `N` (z.B. `5`) |
 | `team:sprint` (Implementierung) | Freier Sprint-Name, aus Ordner / Status-Datei aufgelöst |
 
 Den Sprint-Ordner durch Glob-Suche `project-management/sprints/sprint-{N}-*/` auflösen und
@@ -64,12 +65,16 @@ Den Sprint-Ordner durch Glob-Suche `project-management/sprints/sprint-{N}-*/` au
 
 1. `<N>` und Flags parsen. `N`, `00N`, Sprint-Slug und Sprint-Name ableiten.
 2. `project-management/sprints/sprint-{N}-*/` und `.bmad/sprint-status.yaml` auflösen.
-   **Abbruch**, falls weder das eine noch das andere existiert (nichts zu orchestrieren).
+   Existiert keines von beiden, ist der Sprint neu: Phase 1 legt beides an (kein Abbruch).
 3. Sicherstellen, dass der Working Tree sauber ist und `--base` aktuell ist. **Abbruch** bei schmutzigem Tree.
 4. Den Feature-Branch `feature/sprint-{N}-<slug>` von `--base` erstellen / auschecken
    (Regel 09: `main` immer deployfähig — nie direkt auf dem Basis-Branch arbeiten).
 5. Bei `--dry-run`: aufgelösten Kontext + die 9 geplanten Phasen ausgeben und **hier stoppen**.
 
+### Phase 0b — Backlog aus dem PRD (Unter-Agent, nur mit `--from-prd`)
+
+> „Lesen Sie `.claude/commands/workflow/plan.md` und führen Sie `/workflow:plan --only=backlog` aus (Eingabe: `project-management/prd.md`). Geben Sie eine knappe Zusammenfassung und die erstellten Dateien zurück.“
+
 ### Phase 1 — Start (Unter-Agent)
 
 Einen isolierten Unter-Agenten starten:
@@ -80,13 +85,13 @@ Einen isolierten Unter-Agenten starten:
 
 ### Phase 2 — Zerlegung (Unter-Agent)
 
-> „Lesen Sie `.claude/commands/project/decompose-tasks.md` und führen Sie es für Sprint **00N** aus.
-> Generieren Sie die Task-Dateien je US, `task-board.md` und den Abhängigkeitsgraphen.
+> „Lesen Sie `.claude/commands/workflow/start.md` (`/workflow:start {N} --tasks-only`) und führen Sie es für Sprint **N** aus.
+> Generieren Sie die `tasks/TASK-*.md`-Dateien, `board.md` und den Abhängigkeitsgraphen.
 > Geben Sie eine knappe Zusammenfassung und die erstellten Dateien zurück."
 
 ### Phase 3 — Gate-Validierung (Unter-Agent + Auto-Korrektur-Schleife)
 
-> „Lesen Sie `.claude/commands/gate/validate-sprint.md` und führen Sie es für Sprint **00N** aus.
+> „Lesen Sie `.claude/commands/gate/check.md` (gate `sprint`) und führen Sie es für Sprint **00N** aus.
 > Geben Sie PASS/FAIL, die Punktzahl und die Liste der fehlgeschlagenen Kriterien zurück."
 
 **Bei FAIL → Auto-Korrektur-Schleife** (bis zu `--max-fix-attempts`):
@@ -97,6 +102,8 @@ Einen isolierten Unter-Agenten starten:
 
 ### Phase 4 — Implementierung (Sie = Dirigent)
 
+> Entspricht `/workflow:implement --parallel N` (das an `/team:sprint` delegiert).
+
 Direkt die **`/team:sprint`-Dirigenten-Rolle übernehmen** (kein verschachteltes Agent Team starten):
 
 1. `.bmad/sprint-status.yaml` lesen; Stories mit Status `ready-for-dev` filtern.
@@ -196,3 +203,4 @@ Phase                  | Status  | Anmerkungen
 - **Auto-Merge ist opt-in** und absichtlich hinter einem Flag gesperrt.
 - **Docker ist obligatorisch** für Tests (Projekt-CLAUDE.md).
 - Die Isolation der Unter-Agenten ersetzt `/clear` — jeden Unter-Agenten-Bericht knapp halten.
+- Für die parallele Agent-Teams-Variante, die die Stories zusätzlich mit Cross-Review schreibt, `/team:delivery` verwenden.