--- name: bmad-pipeline description: > Orchestriert den kompletten BMAD-Entwicklungszyklus als automatische Pipeline: bmad-create-story → bmad-testarch-atdd → bmad-dev-story → bmad-testarch-test-review → bmad-code-review → bmad-security-review (Kassandra, conditional), jeweils in frischem Kontext. Führt git add nach dev-story aus. Der Code-Review-Skill fixt Minor Issues selbst ("fixe minor issues instantly"). Pausiert nur bei Major/Critical Issues (User-Entscheidung), am Epic-Ende zwingend mit Kassandra-Security-Review und danach für die Retrospektive (liest sprint-status.yaml). Trigger: "bmad pipeline", "bmad run", "bmad start", "story pipeline", "neues feature", "story durchlaufen", "pipeline starten", immer wenn der User den kompletten BMAD-Flow starten will ohne jeden Schritt einzeln aufzurufen. --- # BMAD Pipeline Skill Dieser Skill orchestriert den vollständigen BMAD-Entwicklungszyklus in einer einzigen Ausführung. Jeder Schritt läuft in einem eigenen, frischen Subagenten-Kontext. ## Ablauf-Übersicht ``` [1] bmad-create-story (Sonnet, frischer Kontext) ↓ [1b] Matrix-Gate (Oracle) (Sonnet, frischer Kontext) ← nur wenn Matrix-Feature Spec-Anforderungen, Fehlercodes, Testfälle → MATRIX_ORACLE_CONTEXT ↓ [2] bmad-testarch-atdd (Sonnet, frischer Kontext) ← TEA Gate 1 failing tests generieren + stagen (+ Oracle-Findings wenn Matrix) ↓ [3] bmad-dev-story (Sonnet, frischer Kontext) ↓ rtk git add . ↓ [4] bmad-testarch-test-review (Sonnet, frischer Kontext) ← TEA Gate 2 Test-Qualität prüfen, Findings ausgeben ↓ [5] bmad-code-review (Opus, frischer Kontext) "fixe minor issues instantly" → Minor Issues werden vom Skill selbst gefixt ↓ rtk git add . ↓ [5b] Security-Review-Gate (conditional) ← SEC Gate 1 Story-Frontmatter `security_review` prüfen (required/optional/not-needed) oder Heuristik über Dateipfade der Änderung. Falls required oder vom User bestätigt optional: → bmad-security-review (Kassandra) — staged diff → CRITICAL blockiert den Commit; HIGH konfigurierbar → Report nach _bmad-output/.../security-reports/ ↓ Major/Critical/HIGH Issues aus [5] oder [5b] gefunden? Ja → Pause, User entscheidet Nein → sprint-status.yaml aktualisieren (Story → done, last_updated, Kommentarzeile) ↓ rtk git add sprint-status.yaml ↓ rtk git commit ↓ [6] Epic-Check: sprint-status.yaml Epic fertig? → [6b] Kassandra am Epic-Ende ← SEC Gate 2 (zwingend, unabhängig von Story-Flags) mit Diff-Range-Override: rtk git diff ..HEAD → epic-{N}-security-review-{date}.md wird erzeugt → CRITICAL/HIGH = Pause, User entscheidet → Danach Pause für Retrospektive Sonst → ✅ Fertig, nächste Story bereit ``` --- ## Schritt-für-Schritt-Anleitung ### Vorbereitung Bestimme die BMAD-Skill-Pfade: ```bash rtk find . -name "SKILL.md" -type f ``` Erwartete Pfade: - `skills/bmad-create-story/SKILL.md` - `skills/bmad-testarch-atdd/SKILL.md` - `skills/bmad-dev-story/SKILL.md` - `skills/bmad-testarch-test-review/SKILL.md` - `skills/bmad-code-review/SKILL.md` - `skills/bmad-security-review/SKILL.md` (Kassandra) Halte den Story-Titel oder die Feature-Beschreibung vom User fest – sie wird an alle Subagenten weitergegeben. --- ### Schritt 1: bmad-create-story **Modell:** `claude-sonnet-4-6` | **Kontext:** frisch (Task-Tool) ``` Lies und befolge die Anweisungen aus .claude/skills/bmad-create-story/SKILL.md. Feature/Story: [FEATURE_BESCHREIBUNG_VOM_USER] Arbeite das vollständig durch und beende dann. ``` Warte auf Fertigstellung. Notiere den Namen der erstellten Story-Datei: ```bash rtk git status ``` Zeige: `✓ Schritt 1: Story erstellt → [story-datei.md]` --- ### Schritt 1b: Matrix-Gate — Oracle-Konsultation (conditional) **Modell:** `claude-sonnet-4-6` | **Kontext:** frisch (Task-Tool) **Erkennung:** Prüfe ob die Story ein Matrix-API-Feature beschreibt: ```bash rtk grep -i "_matrix/\|m\.room\.\|m\.login\|event_type\|txnId\|sync.*since\|matrix.*spec" [STORY_DATEI_AUS_SCHRITT_1] ``` Matrix-Bezug liegt vor wenn: Endpoint-Pfade wie `/_matrix/client/`, Event-Typen wie `m.room.*`, Matrix-Fehlercodes (`M_FORBIDDEN` etc.) oder Matrix-Konzepte (sync, txnId, power_levels) im Story-Text erwähnt werden. **Wenn kein Matrix-Bezug:** `⏭️ Schritt 1b: Matrix-Gate übersprungen — kein Matrix-Feature.` `MATRIX_ORACLE_CONTEXT = null` Fahre direkt mit Schritt 2 fort. **Wenn Matrix-Feature erkannt:** ``` Lies und befolge die Anweisungen aus skills/agent-oracle/SKILL.md. Du bist die Oracle — Matrix Client-Server API v1.18 Expertin. Die folgende Story beschreibt ein Matrix-Feature für den Nebu-Server. Story-Datei: [STORY_DATEI_AUS_SCHRITT_1] Führe für diese Story aus: 1. Spec Lookup (lade references/spec-lookup.md): Welche Matrix CS API v1.18 Endpoints, Event-Typen und Verhaltensregeln sind relevant? Liste alle MUST-Anforderungen für dieses Feature. 2. Test Guidance (lade references/test-guidance.md): Welche spec-definierten Fehlercodes, HTTP-Status-Codes und Edge Cases MÜSSEN als Tests abgedeckt sein? Gib das Ergebnis als kompaktes Markdown zurück (max. 40 Zeilen). Keine Prosa — nur Anforderungen und Testfälle als Listen. Beende dann. ``` Warte auf Fertigstellung. Speichere die Ausgabe als `MATRIX_ORACLE_CONTEXT`. Zeige: `✓ Schritt 1b: Oracle konsultiert — Matrix-Spec-Context erfasst.` --- ### Schritt 2: bmad-testarch-atdd (TEA Gate 1 — Failing Tests) **Modell:** `claude-sonnet-4-6` | **Kontext:** frisch (Task-Tool) | **Pflicht** **Ausnahme:** Reine Infrastruktur-Stories ohne beobachtbares Verhalten (z.B. nur Dockerfile, nur Migration ohne Logik) können übersprungen werden. Dann Ausgabe: `⏭️ Schritt 2: Infra-only Story — ATDD übersprungen.` Für alle anderen Stories: ``` Lies und befolge die Anweisungen aus .claude/skills/bmad-testarch-atdd/SKILL.md (oder den ATDD workflow.md falls SKILL.md nicht existiert). Story-Datei: [STORY_DATEI_AUS_SCHRITT_1] Generiere failing Acceptance Tests für alle Acceptance Criteria der Story. Die Tests müssen FAILING sein bevor Implementation-Code existiert. [NUR WENN MATRIX_ORACLE_CONTEXT VORHANDEN — sonst diesen Block weglassen:] Matrix Spec-Anforderungen (aus Oracle, v1.18): [MATRIX_ORACLE_CONTEXT] Stelle sicher, dass ALLE spec-definierten Fehlercodes, HTTP-Status-Codes und Edge Cases oben als eigene failing Tests abgedeckt sind. Die Matrix-Spezifikation definiert explizit welche Fehlerantworten auf welche Eingaben zu erfolgen haben — teste nicht nur den Happy-Path. Beende nach Generierung der Tests. ``` Warte auf Fertigstellung. Zeige: `✓ Schritt 2: Failing Acceptance Tests generiert.` --- ### Schritt 3: bmad-dev-story + git add **Modell:** `claude-sonnet-4-6` | **Kontext:** frisch (Task-Tool) ``` Lies und befolge die Anweisungen aus .claude/skills/bmad-dev-story/SKILL.md. Implementiere die zuletzt erstellte Story vollständig. Die failing Acceptance Tests aus Schritt 2 sind bereits vorhanden — implementiere gegen diese Tests bis sie grün sind. Beende nach Abschluss der Implementierung. ``` Warte auf Fertigstellung. Danach: ```bash [ -f /tmp/bmad-session-env.sh ] && source /tmp/bmad-session-env.sh rtk git add . rtk git status ``` Zeige: `✓ Schritt 3: Implementierung abgeschlossen, git add ausgeführt.` --- ### Schritt 4: bmad-testarch-test-review (TEA Gate 2 — Test-Qualität) **Modell:** `claude-sonnet-4-6` | **Kontext:** frisch (Task-Tool) | **Pflicht** ``` Lies und befolge die Anweisungen aus .claude/skills/bmad-testarch-test-review/SKILL.md (oder den test-review workflow.md falls SKILL.md nicht existiert). Reviewe alle gestagten Test-Dateien (git diff --staged). Prüfe insbesondere: - Hat jedes Acceptance Criterion der Story mindestens einen Test? - Gibt es Hard Waits, versteckte Assertions oder nicht-deterministische Tests? - Haben GenServer-State-Stories einen Crash/Restart-Test? - Wird Cookie-Forging oder DB-Seeding als Shortcut verwendet? Klassifiziere jeden Fund als MAJOR, MINOR oder INFO. MAJOR: fehlendes Test-Coverage für ein Acceptance Criterion. Gib das vollständige Ergebnis aus und beende dann. ``` Warte auf die vollständige Ausgabe. Speichere die Findings für Schritt 5. **Wenn MAJOR Findings im Test-Review:** ``` ⚠️ bmad-testarch-test-review hat MAJOR Test-Lücken gefunden (siehe oben). Empfehlung: Behebe fehlende Test-Coverage vor dem Code-Review. Tippe "weiter" um trotzdem mit dem Code-Review fortzufahren, oder behebe die Lücken und starte Schritt 4 neu. ``` Stoppe und warte. Bei "weiter": fahre mit Schritt 5 fort. **Wenn keine MAJOR Findings:** Zeige: `✓ Schritt 4: Test-Review bestanden. Findings werden an Code-Review übergeben.` --- ### Schritt 5: bmad-code-review (inkl. Minor-Issue-Fix) **Modell:** `claude-opus-4-7` | **Kontext:** frisch (Task-Tool) Übergib die Findings aus Schritt 4 an den Code-Review-Agent: ``` [OLLAMA-PRÄAMBEL wenn OLLAMA_MODE=true] Lies und befolge die Anweisungen aus .claude/skills/bmad-code-review/SKILL.md. fixe minor issues instantly Reviewe alle gestagten Änderungen (git diff --staged). Test-Review Findings (aus bmad-testarch-test-review): [FINDINGS_AUS_SCHRITT_4] [NUR WENN MATRIX_ORACLE_CONTEXT VORHANDEN — sonst diesen Block weglassen:] Matrix Spec-Anforderungen (aus Oracle, v1.18): [MATRIX_ORACLE_CONTEXT] Prüfe ob die Implementierung ALLEN oben genannten MUST-Anforderungen der Matrix Client-Server API v1.18 entspricht. Jede Abweichung ist ein Finding. Fehlende Fehlercodes (z.B. falsches errcode, falscher HTTP-Status) = MAJOR. Berücksichtige diese Test-Findings in deinem Review. Gib das vollständige Ergebnis aus. Klassifiziere jeden Fund explizit als MAJOR, MINOR oder INFO – damit die Pipeline die Schwere eindeutig erkennen kann. ``` Der Skill fixt Minor Issues selbst während des Reviews. Warte auf die vollständige Ausgabe. Danach in jedem Fall: ```bash [ -f /tmp/bmad-session-env.sh ] && source /tmp/bmad-session-env.sh rtk git add . rtk git status ``` --- ### Schritt 5b: Security-Review-Gate (SEC Gate 1 — pro Story, conditional) **Modell:** `claude-opus-4-7` | **Kontext:** frisch (Task-Tool) **Ziel:** Security-sensitive Stories bekommen ein zweites, fokussiertes Review. Nicht-sensitive Stories überspringen den Schritt. #### Entscheidung: braucht die Story ein Security-Review? 1. **Prüfe die Story-Datei auf Frontmatter-Flag** `security_review`: - `required` → SEC Gate 1 ausführen - `optional` → Nutzer einmalig fragen: "Story ist als optional markiert — Security-Review jetzt laufen lassen? [Y/n]" - `not-needed` → Gate überspringen, Zeile ausgeben: `⏭️ Schritt 5b: Security-Review übersprungen (Story flagged `not-needed`).` - **Flag fehlt:** Auto-Klassifikation (siehe unten). 2. **Auto-Klassifikation** (wenn Frontmatter-Flag fehlt). Lese die gestagten Dateinamen: ```bash rtk git diff --staged --name-only ``` Markiere als `required`, wenn **mindestens einer** zutrifft: - Datei liegt unter `gateway/internal/auth/`, `gateway/internal/middleware/`, `gateway/internal/admin/`, `gateway/internal/db/` - Neue HTTP-Route in `gateway/cmd/gateway/main.go` (`mux.Handle` oder `mux.HandleFunc` Zeilen hinzugefügt) - Datei liegt unter `core/apps/signature/` oder `core/apps/permissions/` - Elixir `.ex`-Datei `imports :crypto` oder nutzt `Plug.Conn` auf externem Input - Neue SQL-Migration unter `gateway/migrations/` - Sonst: `not-needed`. Gate überspringen mit kurzer Begründung. #### Security-Review durchführen Falls `required` oder vom User bestätigt: ``` Lies und befolge die Anweisungen aus .claude/skills/bmad-security-review/SKILL.md. Reviewe alle gestagten Änderungen (git diff --staged). Kassandra (die Skill-Persona) kennt den vollen Security-Scope: OWASP Top 10, ASVS L2, CWE Top 25, STRIDE, NIST SP 800-53 plus die Nebu-spezifischen Invarianten (Compliance RSP, Audit-Immutability, OIDC-Validierung, Matrix Power Levels, Crypto-Primitive, Secrets-Hygiene). Frameworks werden nach betroffener Komponente gewichtet — keine blinde Checkliste. Kassandra schreibt den Report als Markdown-Audit-Artefakt nach _bmad-output/implementation-artifacts/security-reports/{story-id-or-date}-security-review.md — auch bei null Findings (Audit-Trail). Gib am Ende zurück: - Classification: CRITICAL | HIGH | CLEAN - Pfad zum Report - Severity-Zähler ``` Warte auf Fertigstellung. **Wenn Classification = CRITICAL:** ``` 🔴 Kassandra hat CRITICAL Findings gefunden — Report: [pfad] Pipeline gestoppt. User-Entscheidung erforderlich: (a) fixen und neu starten (b) akzeptieren mit schriftlicher Begründung (c) als Follow-up-Story in nächstes Epic verschieben Tippe "weiter" um trotzdem zu commiten. ``` Stoppe und warte. Bei "weiter": fahre fort. **Wenn Classification = HIGH:** Kassandra respektiert `blocking_severity` aus `.claude/security-agent.yaml` (Default: `CRITICAL`). HIGH warnt, blockiert aber nur wenn `blocking_severity: HIGH` konfiguriert ist. Übernimm Kassandras Entscheidung 1:1 — wenn Kassandra sagt "Pipeline darf durchlaufen", zeige die Warnung und fahre fort. **Wenn Classification = CLEAN:** Zeige: `✓ Schritt 5b: Kassandra — clean.` ```bash [ -f /tmp/bmad-session-env.sh ] && source /tmp/bmad-session-env.sh rtk git add . ``` --- ### Schritt 6: Review-Auswertung Analysiere die Ausgaben aus Schritt 4 (Test-Review), Schritt 5 (Code-Review) **und Schritt 5b (Security-Review, falls ausgeführt)** auf **Major / Critical / High Issues**: - Schlüsselwörter: `MAJOR`, `Critical`, `CRITICAL`, `HIGH severity`, `🔴`, `blocking` - Abschnitte: `## Major Issues`, `## Critical Issues`, `### Blocking Problems`, `## CRITICAL`, `## HIGH` - Aussagen wie "must be fixed before merging" **Wenn blockierende Issues gefunden (aus einem der Reviews):** ``` ⚠️ Blockierende Issues gefunden (MAJOR/CRITICAL/HIGH — siehe oben). Pipeline gestoppt. Bitte behebe die Issues und starte neu – oder tippe "weiter" um trotzdem zu commiten. ``` Stoppe und warte. Bei "weiter": fahre mit dem Commit fort. **Wenn keine blockierenden Issues:** Zeige: `✓ Kein blockierendes Issue – commite automatisch.` **Vor jedem Commit: sprint-status.yaml aktualisieren** (gilt genauso im "weiter"-Fall aus dem Stop oben). ```bash rtk read _bmad-output/implementation-artifacts/sprint-status.yaml ``` 1. **Story-Status im `development_status:`-Block auf `done` setzen.** Der YAML-Key enthält den vollen Slug, z.B. `5-24-sso-redirect-scheme-allowlist: done`. Story-ID und Slug kommen aus der in Schritt 1 erstellten Story-Datei. 2. **`last_updated:` auf das heutige Datum setzen** — kommt zweimal in der Datei vor: - als Kommentar am Dateianfang (`# last_updated: YYYY-MM-DD`) - als YAML-Feld (`last_updated: YYYY-MM-DD`) 3. **Neue Kommentarzeile direkt unter dem `last_updated`-Kommentar einfügen**, im bestehenden Format: ``` # story {STORY_ID} done (pipeline: {KURZE_ZUSAMMENFASSUNG}): {YYYY-MM-DD} ``` Beispiele für `{KURZE_ZUSAMMENFASSUNG}` aus der Historie: - `ATDD+Dev+Code+Security CLEAN` - `CLEAN, Bootstrap replay entry points closed` - `2 MINOR fixed — handler alloc + base.html inline style` - `2 MAJOR + HIGH fixed, 2 rounds Kassandra` - `3 rounds — real sql.Tx via runInTx injection` 4. **Stagen:** ```bash rtk git add _bmad-output/implementation-artifacts/sprint-status.yaml ``` Zeige: `✓ sprint-status.yaml aktualisiert ({STORY_ID} → done).` **Dann commiten:** ```bash rtk git commit -m "$(cat <<'EOF' [KURZE_ZUSAMMENFASSUNG_AUS_STORY_ODER_REVIEW] EOF )" ``` Keine `Co-Authored-By`-Zeile anhängen. Zeige: `✓ Commit erstellt.` --- ### Schritt 7: Epic-Status prüfen ```bash rtk read _bmad-output/implementation-artifacts/sprint-status.yaml ``` Suche in der YAML nach dem Feld `epic-{N}-retrospective` (z.B. `epic-1-retrospective`). Die Epic-Nummer entnimmst du dem Namen der aktuellen Story oder der sprint-status.yaml selbst. **Retro ist fällig, wenn:** Der Eintrag, der in der Datei direkt **vor** `epic-{N}-retrospective` steht (also die letzte Story des Epics), soeben auf `done` gesetzt wurde – sprich: die Story, die wir gerade committed haben, ist genau diese letzte Story. **Epic abgeschlossen:** **Zuerst: Schritt 7b — Epic-Ende Security-Review (SEC Gate 2, zwingend)** Dies läuft unabhängig von Story-Flags — jedes Epic bekommt am Ende ein ganzheitliches Security-Review. 1. Bestimme die Base-Referenz für den Epic-Diff: ```bash rtk git log --grep="epic-{N-1}-retrospective\|retrospektive" --oneline ``` - Falls unklar: frage den User: "Epic-Diff-Basis? (commit-sha oder Tag)" 2. Führe Kassandra mit Epic-Diff-Range-Override aus: ``` Lies und befolge die Anweisungen aus .claude/skills/bmad-security-review/SKILL.md. **Caller-Overrides** (siehe Phase 1 in Kassandras workflow.md): - Diff-Range: statt `git diff --staged`, reviewe `git diff ..HEAD` - Report-Filename-Prefix: `epic-{N}-security-review-{YYYY-MM-DD}` Zusätzlicher Analyse-Fokus über Kassandras Standard-Scope hinaus: - ganzheitliche Angriffsflächen, die über einzelne Stories hinweg entstehen - Kombinationen neuer Endpoints, die zusammen Auth-Bypass ermöglichen - neue DB-Migrationen, die RLS / Policies brechen - neue gRPC-Handler, die Middleware umgehen - kumulative Secrets- oder Crypto-Verschiebungen Kassandra schreibt den Report nach _bmad-output/implementation-artifacts/security-reports/epic-{N}-security-review-{YYYY-MM-DD}.md (Audit-Artefakt, auch bei null Findings). Gib Classification (CRITICAL | HIGH | CLEAN) und Report-Pfad zurück. ``` 3. (Der Report wird von Kassandra selbst geschrieben — kein separater Pipeline-Schreibschritt.) 4. Auswertung: - **CRITICAL oder HIGH gefunden:** Stoppe mit ``` 🔴 Epic-Ende Security-Review hat CRITICAL/HIGH Findings. Epic kann nicht abgeschlossen werden ohne User-Entscheidung. Optionen: (a) Follow-up-Stories in Epic {N+1} anlegen (empfohlen) (b) Begründete Akzeptanz als Risiko dokumentieren Tippe "weiter" um die Retrospektive trotzdem zu starten. ``` - **Nur MEDIUM/LOW oder null Findings:** Weiter zur Retrospektive. **Dann: Retrospektive** ``` 🏁 Epic abgeschlossen! Security-Review-Artefakt: epic-{N}-security-review-{YYYY-MM-DD}.md Alle Stories sind erledigt. Zeit für die Retrospektive. Führe außerdem /bmad-testarch-trace aus, um die Traceability-Matrix für das Epic zu erstellen. Wenn du fertig bist, starte den nächsten Epic mit "bmad pipeline". ``` Stoppe hier und warte auf den User. **Epic läuft noch:** ``` ✅ Story abgeschlossen. Nächste Story starten? [Y/n] ``` - Bei `Y` oder Enter: Starte die Pipeline von vorne (Schritt 1: bmad-create-story). - Bei `n`: Beende die Pipeline. --- ## Fehlerbehandlung - **Subagent schlägt fehl:** Zeige die vollständige Fehlermeldung. Stoppe, User entscheidet. - **git add / git commit schlägt fehl:** Zeige den git-Fehler. Stoppe, warte auf User-Aktion. - **sprint-status.yaml nicht vorhanden:** `ℹ️ sprint-status.yaml nicht gefunden – Epic-Check übersprungen.` - **SKILL.md / workflow.md nicht gefunden:** Melde den fehlenden Pfad und stoppe. - **bmad-testarch-atdd nicht verfügbar:** `⚠️ ATDD-Skill nicht gefunden – TEA Gate 1 übersprungen. Stelle sicher, dass Acceptance Tests manuell vor der Implementierung existieren.` - **bmad-testarch-test-review nicht verfügbar:** `⚠️ Test-Review-Skill nicht gefunden – TEA Gate 2 übersprungen.` --- ## Modell-Übersicht | Schritt | Modell | |------------------------------|-------------------| | bmad-create-story | claude-sonnet-4-6 | | Matrix-Gate Oracle (Schritt 1b, nur bei Matrix-Stories) | claude-sonnet-4-6 | | bmad-testarch-atdd | claude-sonnet-4-6 | | bmad-dev-story | claude-sonnet-4-6 | | bmad-testarch-test-review | claude-sonnet-4-6 | | bmad-code-review | claude-opus-4-7 | | bmad-security-review (Kassandra, Gate 1 & 2) | per `.claude/security-agent.yaml` (Default: claude-opus-4-7) | --- ## Wichtige Hinweise - Gib dem User nach jedem Schritt ein kurzes Status-Update. - Die Feature-Beschreibung des Users muss an alle Subagenten weitergegeben werden. - Alle Schritte laufen **sequenziell** – kein paralleles Starten von Subagenten. - Die Findings aus dem Test-Review (Schritt 4) **müssen** an den Code-Review-Agent (Schritt 5) übergeben werden. - `rtk git add .` nach dem Code-Review ist immer auszuführen, unabhängig davon ob Minor Issues gefunden wurden oder nicht – es schadet nicht und stellt Vollständigkeit sicher. - **TEA Gate 1 (ATDD)** erzeugt failing Tests — der Dev-Agent implementiert gegen diese. Ohne failing Tests kein klares Definition of Done. - **TEA Gate 2 (Test-Review)** läuft vor dem Code-Review, damit Test-Lücken frühzeitig erkannt werden und der Code-Reviewer sich auf Logik konzentrieren kann. - **SEC Gate 1 (Story-Security-Review)** ist conditional und läuft nach dem Code-Review. Entscheidung per Story-Frontmatter-Flag `security_review` oder per Heuristik über die gestagten Dateipfade. Blockiert den Commit bei CRITICAL/HIGH. - **SEC Gate 2 (Epic-Ende-Security-Review)** ist zwingend, unabhängig von Story-Flags. Läuft vor der Retrospektive mit dem gesamten Epic-Diff. Erzeugt immer ein `epic-{N}-security-review-{date}.md` Audit-Artefakt.