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

package/Project/i18n/de/commands/migrate.md

@@ -0,0 +1,158 @@
+---
+description: "Einmalige Migration eines bestehenden Backlogs nach BMAD v6 (Analyse, Migration, Stories vervollständigen, Resynchronisation)"
+argument-hint: "[--analyze|--dry-run|--resync|--stories] [--force]"
+---
+
+# Backlog migrieren
+
+Einmalige Migration eines bestehenden Backlogs in das BMAD-v6-Layout, mit `.bmad/sprint-status.yaml` als einziger Quelle der Wahrheit für den Status von Stories und Tasks (Schema: `.claude/templates/project/sprint-status.md`). Ein einziger Befehl deckt vier Modi ab: Analyse, Migration, Ergänzung fehlender Story-Felder und Resynchronisation des Inhalts.
+
+## Verwendung
+
+| Aufruf | Was er tut | Ersetzt |
+|--------|------------|---------|
+| `/project:migrate --analyze` | Nur Bericht: Struktur, INVEST-Scores, BMAD-v6-Lücken. Schreibt nichts | `analyze-backlog` |
+| `/project:migrate` | Standard: migriert das Backlog und erstellt `.bmad/sprint-status.yaml` | `migrate-backlog` |
+| `/project:migrate --stories [story-id]` | Ergänzt fehlende Story-Felder (Tasks, AK, Verlauf, INVEST) | `update-stories` |
+| `/project:migrate --resync` | Gleicht Inhalt und IDs zwischen Markdown und YAML ab | `sync-backlog` |
+| `--dry-run` | Nur Vorschau, gilt für alle Modi | - |
+| `--force` | Überschreibt vorhandene BMAD-Dateien (Migrationsmodus) | - |
+
+## Argumente
+
+$ARGUMENTS (Format: [--analyze|--dry-run|--resync|--stories] [--force])
+- **--analyze**: Analysemodus (nur lesend)
+- **--stories**: optionale `story-id` (z. B. US-001); wenn weggelassen, werden alle Stories verarbeitet
+- **--resync**: Abgleichmodus
+- **--dry-run**: zeigt die geplanten Änderungen, schreibt nichts
+- **--force**: überschreibt eine vorhandene `sprint-status.yaml` und vorhandene BMAD-Dateien
+- Die Modi schließen sich gegenseitig aus; ohne einen davon läuft die Standardmigration.
+
+## Gemeinsame Regeln
+
+- **Backlog-Ort**, in dieser Reihenfolge gesucht: `project-management/backlog/` (Standard), `docs/backlog/`, `backlog/`, `.bmad/` (bereits migriert).
+- **Einzige Quelle der Wahrheit**: Der Status lebt ausschließlich in `.bmad/sprint-status.yaml`. Markdown enthält nur Inhalt (Titel, Beschreibung, AK, Punkte, übergeordnete Elemente).
+- **Alte Status**: Die Erstmigration ist der EINZIGE Zeitpunkt, an dem alte Markdown-Status/Emojis gelesen werden; sie werden in das YAML verschoben und anschließend aus dem Markdown entfernt. `--resync` und `--stories` kopieren nie einen Status aus dem Markdown.
+- **Plan Mode ist Pflicht** für die Standardmigration, `--stories` und `--resync` (außer mit `--dry-run`): Claude analysiert die Auswirkungen, schlägt einen Plan vor und wartet auf Ihre Freigabe, bevor etwas geändert wird.
+- **Empfohlene Reihenfolge**: zuerst `--analyze`, dann die Migration, dann `--stories`; `--resync` danach, wenn der Inhalt auseinanderläuft.
+
+## --analyze
+
+Nur Bericht, keine Datei wird geändert.
+
+1. **Erkennen** des Backlog-Orts (siehe gemeinsame Regeln).
+2. **Identifizieren** von Epics (`EPIC-*.md`, `epic*.md`), User Stories (`US-*.md`, `story*.md`), Tasks (`TASK-*.md` oder in Stories eingebettet) und Indexdateien (`index.md`, `backlog.md`, `README.md`).
+3. **Auswerten** pro Datei: ID, Titel, alter Status (🔴 To Do, 🟡 In Progress, 🟢 Done, ⏸️ Blocked), Sprint, Story Points, übergeordnete Elemente (US → EPIC, TASK → US), Anzahl AK, Anzahl Tasks und Fortschritt.
+4. **INVEST-Score** pro Story (0-6): Independent (keine blockierende Abhängigkeit), Negotiable (hat eine Beschreibung), Valuable (Nutzen genannt), Estimable (hat Punkte), Small (≤ 8 Punkte), Testable (hat AK).
+5. **BMAD-v6-Lücken**: Verfolgung der TDD-Phase, Task-Liste mit Fortschritt, Statusverlauf, Sprint-Zuordnung, Validierungsstatus der AK.
+6. **Bericht**: Zusammenfassung (Zähler), Struktur (Baum), INVEST-Tabelle, Tabelle der Migrationslücken (Feld / % betroffener Stories / Aktion), Empfehlungen.
+
+```
+📊 Backlog-Analysebericht
+Ort: project-management/backlog/ | Epics: {N} | Stories: {N} | Tasks: {N}
+
+| Story  | Titel | INVEST | Fehlt     |
+|--------|-------|--------|-----------|
+| US-001 | Login | 5/6    | Estimable |
+
+Migrationslücken: tdd_phase 100% | tasks.list 60% | history 100%
+Weiter: /project:migrate
+```
+
+## Standard: Migration
+
+1. **Prüfen**: `.bmad/` bei Bedarf anlegen; warnen, wenn `sprint-status.yaml` existiert und kein `--force` gesetzt ist; die Analyse sollte zuvor gelaufen sein.
+2. **Struktur anlegen**: `.bmad/sprint-status.yaml`, `batch-queue.yaml`, `gates/`, `hooks/`, `lib/`.
+3. **Jede Story auswerten**: Metadaten, AK (Gherkin), zugehörige Tasks, alter Status, Fortschritt.
+4. **Alte Status in das YAML überführen**:
+
+   | Ursprung | BMAD-v6-Status |
+   |----------|----------------|
+   | 🔴 To Do | backlog |
+   | 🟡 In Progress | in-progress |
+   | 🟢 Done | done |
+   | ⏸️ Blocked | blocked |
+   | Sprint-X zugewiesen | ready-for-dev |
+
+5. **Anfängliche TDD-Phase**: 0 % der Tasks erledigt → `red`; 1-99 % → `green`; 100 % → `refactor` oder `done`.
+6. **`sprint-status.yaml` erzeugen**, ein Eintrag pro Story:
+
+   ```yaml
+   stories:
+     US-001:
+       title: "User login"
+       status: "in-progress"
+       previous_status: "ready-for-dev"
+       tdd_phase: "red"
+       current_task: "TASK-001"
+       story_points: 5
+       epic_id: "EPIC-001"
+       tasks:
+         total: 4
+         completed: 2
+         list:
+           - { id: "TASK-001", title: "Backend auth endpoint", status: "in-progress", type: "BE" }
+       acceptance_criteria: { total: 3, validated: 1 }
+       history:
+         - { timestamp: "2026-01-29T10:00:00Z", from: "backlog", to: "in-progress", by: "migration", reason: "BMAD v6 migration" }
+   ```
+
+7. **Backup** (außer `--dry-run`): Backlog nach `.bmad/backup/` kopieren (mit Zeitstempel) und den Speicherort protokollieren.
+8. **Anwenden** (außer `--dry-run`): YAML schreiben, Status-Emojis/-Felder aus den Markdown-Dateien entfernen, `.bmad/migration-log.md` erstellen.
+
+Dry Run: listet die Dateien auf, die erstellt würden (z. B. `.bmad/sprint-status.yaml`), die Anzahl der Stories/Tasks/AK, die migriert würden, und endet mit „Run without --dry-run to apply changes.“.
+
+Rollback: `tar -xzf .bmad/backup/backlog-*.tar.gz -C project-management/ && rm .bmad/sprint-status.yaml`.
+
+Nächste Schritte: das YAML prüfen, `/workflow:status` ausführen, Sprint-Metadaten festlegen (Daten, Ziele), Quality Gates mit `/gate:check all` prüfen.
+
+## --stories
+
+Ergänzt fehlende BMAD-v6-Felder bestehender Stories (alle oder eine einzelne per `story-id`).
+
+1. **Laden** von `.bmad/sprint-status.yaml` und den Story-Dateien; beide vergleichen.
+2. **Fehlende Felder** und Standardwerte:
+
+   | Feld | Pflicht | Standard, wenn fehlend |
+   |------|---------|------------------------|
+   | tdd_phase | Ja | "red" bei in-progress, sonst "" |
+   | tasks.list / total / completed | Ja | Aus `## Tasks` extrahieren, zählen, erledigte zählen |
+   | current_task | Nein | Erste Task im Status in-progress |
+   | history | Ja | Anfangseintrag mit dem aktuellen Status (`by: "migrate"`) |
+   | acceptance_criteria.total / validated | Ja | Im AK-Abschnitt zählen / 0 |
+   | story_points | Ja | Benutzer fragen, wenn fehlend |
+   | epic_id | Nein | Aus der Datei extrahieren |
+
+3. **Tasks auswerten** aus der `## Tasks`-Tabelle der Story und **AK** aus den Gherkin-Blöcken `### ACn:`, um `tasks.list` und `acceptance_criteria.list` (IDs, Titel) zu füllen. Task- und AK-Status gelangen nur für noch nicht im YAML geführte Einträge dorthin; ein bereits vorhandener YAML-Status wird nie durch Markdown überschrieben.
+4. **INVEST**: `invest_score` hinzufügen (independent, negotiable, valuable, estimable, small, testable, total).
+5. **`sprint-status.yaml` aktualisieren** durch Zusammenführen der Felder; optional einen Metadaten-Kommentar in die Story-Dateien schreiben (`<!-- BMAD v6 Metadata … -->` mit `tdd_phase`, `invest_score`, `last_sync`).
+
+Ausgabe: Tabelle der aktualisierten Stories (ergänzte Felder, INVEST-Score), Zusammenfassung pro Feld (ergänzt / übersprungen), Warnungen (z. B. „US-003: Story Points fehlen“, „US-007: keine Akzeptanzkriterien“), geänderte Dateien. Danach die Warnungen beheben und `/project:migrate --resync` sowie `/gate:check backlog` ausführen.
+
+## --resync
+
+Gleicht Inhalt und IDs zwischen den Markdown-Dateien und dem YAML ab. Der Status wird nie synchronisiert: Das YAML gilt.
+
+1. **Laden** beider Quellen und Aufbau einer Vergleichstabelle nach Story-ID.
+2. **Abweichungen im Inhalt erkennen**: fehlende Stories, Titel, Story Points, Task-Listen, AK, Zuordnung.
+3. **Auflösen**: Das YAML ist maßgeblich für Status, TDD-Phase, Verlauf und Task-Zustand; Markdown ist maßgeblich für Titel, Beschreibungen, AK-Texte und Punkte. Den Benutzer fragen, wenn beide dasselbe Inhaltsfeld geändert haben.
+4. **Dateien → YAML**: nur in Dateien vorhandene Stories hinzufügen; Titel, Punkte, Task- und AK-Listen aktualisieren.
+5. **YAML → Dateien**: den Metadaten-Kommentar aktualisieren (TDD-Phase, Verlauf, INVEST-Score, Sync-Zeitstempel); nie einen Status ins Markdown schreiben.
+6. **Waisen**: im YAML, aber nicht in den Dateien → als `archived` markieren oder warnen; in den Dateien, aber nicht im YAML → zum YAML hinzufügen (Status `backlog`).
+7. **Zeitstempel**: `last_sync` im YAML und `<!-- last_sync: … -->` in den Story-Dateien.
+
+Ausgabe: Änderungen Dateien → YAML, Änderungen YAML → Dateien, aufgelöste Konflikte, Waisen (archiviert / hinzugefügt), Zeitpunkt der letzten Synchronisation. Danach `git diff` prüfen und `/workflow:status` ausführen.
+
+Automatisierung: Ein Pre-Commit-Hook kann `/project:migrate --resync` ausführen (`.bmad/hooks/pre-commit.sh`).
+
+## Beispiele
+
+```
+/project:migrate --analyze
+/project:migrate --dry-run
+/project:migrate
+/project:migrate --force
+/project:migrate --stories US-001
+/project:migrate --stories --dry-run
+/project:migrate --resync --dry-run
+```

package/Project/i18n/de/commands/move-task.md

@@ -1,204 +1,9 @@
 ---
-description: Eine Aufgabe verschieben
-argument-hint: [arguments]
+description: "Veraltet (Entfernung in 9.0): /project:backlog move task verwenden"
+deprecated: true
+replaced-by: /project:backlog
 ---
 
-# Eine Aufgabe verschieben
+> ⚠️ `/project:move-task` ist veraltet und wird in 9.0 entfernt. Verwenden Sie `/project:backlog move task`.
 
-Den Status einer Aufgabe gemäß dem strikten Workflow ändern.
-
-## Argumente
-
-$ARGUMENTS (Format: TASK-XXX Ziel)
-- **TASK-ID** (erforderlich): Aufgaben-ID (z.B. TASK-001)
-- **Ziel** (erforderlich):
-  - `in-progress`: Aufgabe starten
-  - `blocked`: Als blockiert markieren
-  - `done`: Als abgeschlossen markieren
-
-## Strikter Workflow
-
-```
-🔴 To Do ──→ 🟡 In Progress ──→ 🟢 Done
-     │              │
-     │              ↓
-     └────→ ⏸️ Blocked ←────┘
-                │
-                ↓
-           🟡 In Progress
-```
-
-### Erlaubte Übergänge
-
-| Von | Nach | Erlaubt |
-|--------|------|----------|
-| 🔴 To Do | 🟡 In Progress | ✅ |
-| 🔴 To Do | ⏸️ Blocked | ✅ |
-| 🔴 To Do | 🟢 Done | ❌ **Verboten** |
-| 🟡 In Progress | 🟢 Done | ✅ |
-| 🟡 In Progress | ⏸️ Blocked | ✅ |
-| 🟡 In Progress | 🔴 To Do | ✅ (Rollback) |
-| ⏸️ Blocked | 🟡 In Progress | ✅ |
-| 🟢 Done | 🟡 In Progress | ⚠️ (Wiedereröffnen) |
-
-## Prozess
-
-### Schritt 1: Aufgabe validieren
-
-1. Aufgabendatei finden
-2. Aktuellen Status lesen
-3. Zugehörige US und Sprint identifizieren
-
-### Schritt 2: Übergang validieren
-
-1. Prüfen, dass Übergang erlaubt ist
-2. Falls To Do → Done, blockieren und In Progress vorschlagen
-
-### Schritt 3: Falls Übergang zu Blocked
-
-Nach Blocker fragen:
-```
-Was ist der Blocker für TASK-XXX?
-> [Blocker-Beschreibung]
-```
-
-### Schritt 4: Falls Übergang zu Done
-
-Nach aufgewendeter Zeit fragen:
-```
-Zeit für TASK-XXX aufgewendet? (Schätzung: 4h)
-> [Tatsächliche Zeit, z.B. 3.5h]
-```
-
-### Schritt 5: Aufgabe aktualisieren
-
-1. Status in Metadaten ändern
-2. Blocker hinzufügen, falls Blocked
-3. Aufgewendete Zeit aktualisieren, falls Done
-4. Änderungsdatum aktualisieren
-
-### Schritt 6: Board aktualisieren
-
-1. Sprint-Board lesen
-2. Aufgabe in neue Spalte verschieben
-3. Metriken aktualisieren
-
-### Schritt 7: User Story aktualisieren
-
-1. Aufgabenliste aktualisieren
-2. Fortschritt neu berechnen
-3. Falls alle Aufgaben Done, Abschluss der US vorschlagen
-
-### Schritt 8: Index aktualisieren
-
-1. Globale Zähler aktualisieren
-
-## Ausgabeformat
-
-### Erfolgreicher Übergang
-
-```
-✅ Aufgabe verschoben!
-
-🔧 TASK-003: Login API Endpoint
-   Vorher: 🔴 To Do
-   Nachher: 🟡 In Progress
-
-📖 US-001: Benutzer-Login
-   Fortschritt: 2/6 → 3/6 (50%)
-
-Nächste Schritte:
-  /project:move-task TASK-003 done       # Bei Abschluss
-  /project:move-task TASK-003 blocked    # Falls blockiert
-```
-
-### Aufgabe abgeschlossen
-
-```
-✅ Aufgabe abgeschlossen!
-
-🔧 TASK-003: Login API Endpoint
-   Status: 🟡 In Progress → 🟢 Done
-   Schätzung: 4h
-   Tatsächliche Zeit: 3.5h ✓
-
-📖 US-001: Benutzer-Login
-   Fortschritt: 4/6 (67%) ████████░░░░
-
-Sprint 1:
-   Aufgaben erledigt: 12/25 (48%)
-   Stunden: 35h/77h abgeschlossen
-```
-
-### Alle Aufgaben Done
-
-```
-✅ Aufgabe abgeschlossen!
-
-🔧 TASK-006: AuthService Tests
-   Status: 🟢 Done
-
-🎉 Alle Aufgaben von US-001 abgeschlossen!
-
-📖 US-001: Benutzer-Login
-   Fortschritt: 6/6 (100%) ██████████
-
-Empfohlener nächster Schritt:
-  /sprint:transition US-001 done
-```
-
-### Workflow-Fehler
-
-```
-❌ Übergang nicht erlaubt!
-
-🔧 TASK-004: Auth Controller
-   Aktueller Status: 🔴 To Do
-   Angeforderter Übergang: → 🟢 Done
-
-Regel: Eine Aufgabe muss durch "In Progress" gehen, bevor sie "Done" sein kann
-
-Korrekte Aktion:
-  /project:move-task TASK-004 in-progress
-  # ... an Aufgabe arbeiten ...
-  /project:move-task TASK-004 done
-```
-
-### Blockierte Aufgabe
-
-```
-✅ Aufgabe als blockiert markiert
-
-🔧 TASK-005: Login Screen
-   Status: 🟡 In Progress → ⏸️ Blocked
-   Blocker: Warte auf Auth API (TASK-003)
-
-Zum Entblocken:
-  1. TASK-003 abschließen
-  2. /project:move-task TASK-005 in-progress
-```
-
-## Beispiele
-
-```
-# Aufgabe starten
-/project:move-task TASK-001 in-progress
-
-# Aufgabe abschließen
-/project:move-task TASK-001 done
-
-# Aufgabe blockieren
-/project:move-task TASK-001 blocked
-
-# Aufgabe entblocken
-/project:move-task TASK-001 in-progress
-```
-
-## Aktualisierte Metriken
-
-Bei jedem Verschieben:
-- Aufgabenzahl nach Status
-- Geschätzte vs. tatsächliche Stunden
-- US-Fortschritt
-- Sprint-Fortschritt
-- Kanban-Board
+Führen Sie `/project:backlog move task $ARGUMENTS` aus: Lesen Sie `.claude/commands/project/backlog.md` und folgen Sie der Datei mit diesen Argumenten.

package/Project/i18n/de/commands/report.md

@@ -0,0 +1,156 @@
+---
+description: "Analyseberichte zum Projekt: Sprint-Burndown, Metrik-Dashboard, Abhängigkeitsgraph der Stories und kritischer Pfad"
+argument-hint: "<burndown|metrics|deps> [--critical] [--sprint=Sprint-N] [--type=points|stories|tasks] [--format=...] [--velocity=N] [--output=path]"
+---
+
+# /project:report
+
+## Auftrag
+
+Zentraler Einstiegspunkt für lesende Projektanalysen. Jeder Unterbefehl wandelt Backlog- und Sprint-Daten in einen Bericht um: ein Burndown-Diagramm, ein Metrik-Dashboard oder einen Abhängigkeitsgraphen (optional mit kritischem Pfad).
+
+## Verwendung
+
+| Aufruf | Funktion | Ersetzt |
+|--------|----------|---------|
+| `/project:report burndown` | Mermaid-Burndown-Diagramm + Abweichung und Prognose | `/project:report burndown` |
+| `/project:report metrics` | Dashboard zu Velocity, Spec-Abdeckung, Gates, Sprint-Gesundheit, Regression | `/project:report metrics` |
+| `/project:report deps` | Abhängigkeitsgraph der Stories, Engpässe, parallele Gruppen | `/project:report deps` |
+| `/project:report deps --critical` | Kritischer Pfad, Puffer und paralleler Ausführungsplan | `/project:report deps --critical` |
+
+## Argumente
+
+`$ARGUMENTS` auswerten: Das erste Positionswort ist der Unterbefehl (`burndown`, `metrics` oder `deps`). Fehlt er oder ist er unbekannt, die obige Tabelle anzeigen und nachfragen, welcher ausgeführt werden soll.
+
+| Option | Gilt für | Beschreibung |
+|--------|---------|--------------|
+| `--sprint=Sprint-N` | alle | Zu analysierender Sprint (Standard: aktueller Sprint) |
+| `--type=points\|stories\|tasks` | burndown | Einheit des Diagramms (Standard `points`) |
+| `--format=dashboard\|json\|markdown` | metrics | Ausgabeformat (Standard `dashboard`) |
+| `--format=mermaid\|table\|json` | deps | Ausgabeformat (Standard `mermaid`) |
+| `--output=path` | deps | Ausgabepfad (Standard: stdout) |
+| `--critical` | deps | Wechselt zur Analyse des kritischen Pfads |
+| `--velocity=N` | deps --critical | Team-Velocity (Punkte pro Sprint) für die Zeitplanschätzung |
+
+## Gemeinsame Regeln
+
+- **Single Source of Truth:** Der STATUS von Stories und Tasks wird ausschließlich aus `.bmad/sprint-status.yaml` gelesen; Markdown-Dateien (`project-management/backlog/`, `tasks/TASK-*.md`) liefern den Inhalt (Titel, Punkte, `Depends on:`), niemals den Status. Die `history`-Einträge speisen das Burndown und die Velocity-Trends.
+- Standardpfade: `project-management/` (`prd.md`, `backlog/`, `sprints/sprint-{N}-{slug}/`); Templates in `.claude/templates/project/`.
+- Berichte lesen Projektdateien nur; geschrieben werden ausschließlich die Metrik-Snapshots in `.bmad/metrics/`.
+- **Der Plan-Modus ist verpflichtend:** Vor der Ausführung den Plan vorschlagen (gelesene Daten, geschriebene Dateien) und die Freigabe abwarten.
+- Jeden Bericht mit den wichtigsten Beobachtungen und Empfehlungen abschließen.
+
+## burndown
+
+Voraussetzungen: `.bmad/sprint-status.yaml` mit Sprint-Daten, Start-/Enddatum und geschätzten Story Points.
+
+1. **Laden**: den aktuellen Sprint in `.bmad/sprint-status.yaml` lesen (Daten, zugesagte Punkte, Status-`history` pro Tag) sowie frühere Daten aus `.bmad/metrics/`.
+2. **Berechnen**: Ideallinie (linear von der Summe auf 0), tatsächlicher Rest pro Tag, Abweichung (voraus/im Rückstand), prognostiziertes Ende anhand der aktuellen Velocity.
+3. **Diagramm** (Mermaid):
+
+```mermaid
+xychart-beta
+    title "Sprint-3 Burndown"
+    x-axis ["Day 1", "Day 2", "Day 3", "Day 4", "Day 5", "Day 6", "Day 7", "Day 8", "Day 9", "Day 10"]
+    y-axis "Story Points Remaining" 0 --> 25
+    line "Ideal" [21, 18.9, 16.8, 14.7, 12.6, 10.5, 8.4, 6.3, 4.2, 2.1, 0]
+    line "Actual" [21, 21, 18, 18, 15, 12, 12, 9, 6, 3]
+```
+
+4. **Analysebericht**:
+
+```
+SPRINT-BURNDOWN-BERICHT — Sprint-3 | Tag 9/10
+Zugesagt gesamt: 21 Pkt | Verbleibend: 3 | Erledigt: 18 (86%)
+Ideal-Rest: 2.1 | Ist: 3 | Abweichung: -0.9 Pkt (leicht im Rückstand)
+Durchschnittliche Velocity: 2.0 Pkt/Tag | Prognostiziertes Ende: Tag 10.5 (0.5 Tage Verzug)
+Trend: Tage 1-3: 3Pkt (langsamer Start) | Tage 4-6: 6Pkt | Tage 7-9: 9Pkt
+Risiko: 1 Story könnte überlaufen (US-015, 3Pkt, blockiert)
+```
+
+5. **Speichern**: die Tagesdaten an `.bmad/metrics/burndown-{sprint-id}.json` anhängen.
+
+## metrics
+
+Voraussetzungen: `.bmad/sprint-status.yaml`; `project-management/backlog/` mit Stories; optional die Historie `.bmad/metrics/` und `project-management/prd.md` für die Abdeckung.
+
+| Kategorie | Metriken (Quelle) |
+|-----------|-------------------|
+| Velocity | Erledigte Punkte pro Sprint, gleitender Durchschnitt (letzte 3), Commitment-Quote (erledigt / zugesagt, Ziel > 80%), Übertrag (`sprint-status.yaml`, Metrik-Historie) |
+| Spec-Abdeckung | % der FR-xxx durch Stories abgedeckt, % der Stories mit Code-Referenzen, % der AC mit Tests, % vollständiger Ketten FR→US→Code→Test (PRD, Stories, `/project:trace`) |
+| Quality Gates | PRD-Gate (>= 80%), Story-DoD, Erfolgsquote Sprint Ready, Erfolgsquote im ersten Durchlauf (Gate-Historie aus `/gate:check`) |
+| Sprint-Gesundheit | Erledigte Stories und Tasks / gesamt, blockierte Stories, TDD-Konformität (`sprint-status.yaml`) |
+| Regression | Gefundene / behobene Bugs pro Sprint, Regressionsrate, Escape-Rate (QA-Recette-Sitzungen, Regressionsregister) |
+
+Ablauf:
+1. **Sammeln**: `.bmad/sprint-status.yaml`, `.bmad/metrics/`, Traceability-Daten (`/project:trace`), Gate-Historie und QA-Recette-Sitzungen (falls vorhanden) lesen.
+2. **Berechnen**: alle fünf Kategorien sowie Trends gegenüber dem Vorsprint (steigend / fallend / gleich).
+3. **Dashboard** (eine Zeile pro Metrik mit Statussymbolen, Schwellenwerte wie oben):
+
+```
+PROJEKT-METRIK-DASHBOARD — Sprint-3 | 2026-02-19
+VELOCITY      Aktuell 18/21 Pkt (86%) | Durchschnitt 19 Pkt/Sprint | Commitment 86% OK | Übertrag 3 Pkt
+ABDECKUNG     Anforderungen 12/15 (80%) WARN | Stories mit Code 8/10 | AC mit Tests 24/28 (86%) OK | Vollständige Ketten 7/10 (70%) WARN
+QUALITY GATES PRD 1/1 | Story-DoD 6/8 (75%) WARN | Sprint Ready 1/1 | Erster Durchlauf 70% WARN
+SPRINT-HEALTH Stories 6/8 | Tasks 22/28 | Blockiert 1 (US-015) WARN | TDD-Konformität 100%
+REGRESSION    Bugs gefunden 4 | behoben 3 | Regressionen 0 | Escape-Rate 0%
+TRENDS        Velocity +2 Pkt | Abdeckung +10% | Erster Durchlauf -5% | Blockiert gleich
+```
+
+4. **Speichern** des Snapshots in `.bmad/metrics/sprint-{id}.json` mit den Schlüsseln `sprint_id`, `date`, `velocity` (`completed`, `committed`, `ratio`), `coverage` (`requirements`, `stories`, `tests`, `traceability`), `gates` (`prd_pass_rate`, `story_pass_rate`, `sprint_ready_rate`, `first_pass_rate`), `health` (`stories_done`, `stories_total`, `tasks_done`, `tasks_total`, `blocked`, `tdd_compliance`), `regression` (`bugs_found`, `bugs_fixed`, `regressions`, `escape_rate`).
+
+`--format=json` oder `markdown` gibt dieselben Daten in diesem Format aus.
+
+## deps
+
+Voraussetzungen: Stories in `project-management/backlog/` mit `Depends on:`-Feldern; optional `.bmad/sprint-status.yaml` (Statusfarben) und `project-management/prd.md` (Gruppierung nach Epic).
+
+1. **Laden**: `project-management/backlog/` durchsuchen, bei `--sprint` filtern, `Depends on:` aus der Traceability-Sektion jeder Story lesen und die Adjazenzliste aufbauen. Der Status stammt aus `.bmad/sprint-status.yaml`.
+2. **Validieren**: zirkuläre Abhängigkeiten (A -> B -> C -> A), Verweise auf nicht existierende Stories, Selbstreferenzen. Jedes Problem melden.
+3. **Graph** (Mermaid `graph TD`, Standard): ein `subgraph` pro Epic (`EPIC-001: Authentication`), Knoten `US-001[US-001: Login Page]`, Kanten `US-002 --> US-001` (hängt ab von) und `classDef`-Farben nach Status: `done` #90EE90, `inProgress` #FFD700, `blocked` #FF6B6B, `ready` #87CEEB. `--format=table|json` für andere Ausgaben.
+4. **Analysieren**: Engpass-Stories (blockieren 3 oder mehr andere), unabhängige Stories, längste Abhängigkeitskette, parallele Gruppen.
+5. **Bericht**:
+
+```
+STORY-ABHÄNGIGKEITSGRAPH — Sprint-3 | Stories: 8 | Abhängigkeiten: 5
+Engpässe: US-001 Login Page (blockiert 4 Stories)
+Unabhängig: US-006, US-007
+Längste Kette (3 Schritte): US-001 -> US-002 -> US-003
+Parallele Gruppen: [US-006, US-007] | [US-004, US-005] (nach US-001)
+Probleme: keine zirkulären Abhängigkeiten, keine fehlenden Verweise
+```
+
+### deps --critical
+
+Benötigt zusätzlich Story Points. Der kritische Pfad ist die längste Folge abhängiger Stories; er bestimmt die Mindestdauer unabhängig von der Teamgröße.
+
+1. **DAG aufbauen** aus dem obigen Graphen (bei einem Zyklus abbrechen).
+2. **Berechnen**: topologische Sortierung, frühester/spätester Start und Ende pro Story, Stories ohne Puffer = kritischer Pfad, Punktesumme entlang des Pfads.
+3. **Puffer**: Gesamtpuffer der nicht kritischen Stories, nahezu kritische Pfade (Puffer < 2 Pkt), Stories, die bei Verzögerung kritisch werden könnten.
+4. **Zeitplan** (mit `--velocity` die Phasen auf Sprints verteilen):
+
+```
+ANALYSE DES KRITISCHEN PFADS — Sprint-3 | Velocity: 21 Pkt/Sprint
+Kritischer Pfad (13 Pkt): US-001 (5) -> US-002 (3) -> US-005 (5)
+Nahezu kritisch: US-001 (5) -> US-004 (3) [Puffer: 2Pkt]
+Phase 1: US-001 + US-006 + US-007 (8Pkt) | Phase 2: US-002 + US-004 (6Pkt) | Phase 3: US-003 + US-005 (7Pkt)
+Puffer: US-003 5Pkt | US-004 2Pkt (beobachten) | US-006, US-007 8Pkt
+```
+
+5. **Empfehlungen**: optimale Ausführungsreihenfolge, Parallelisierung, Risiken bei kritischen Stories (z. B. den erfahrensten Entwickler US-001 zuweisen), Möglichkeiten zur Verkürzung des Pfads (Stories aufteilen).
+
+## Beispiel
+
+```
+User: /project:report deps --critical --sprint=Sprint-3 --velocity=21
+
+Claude: Kritischer Pfad: US-001 -> US-002 -> US-005 (13 Pkt), passt in 1 Sprint.
+Risiko: Ein Verzug von 2 oder mehr Tagen bei US-001 gefährdet den gesamten Sprint.
+```
+
+## Verwandte Befehle
+
+- `/project:trace` — Traceability-Matrix und Abdeckung
+- `/workflow:status` — Übersicht über den Sprint-Status
+- `/project:backlog next story` — Nächste Story (berücksichtigt Abhängigkeiten)
+- `/workflow:retro` — Sprint-Retrospektive (nutzt die Metriken)