@the-bearded-bear/claude-craft 7.10.2 → 7.11.0-next.535f614

package/Dev/i18n/de/Team/commands/audit.md

@@ -14,6 +14,7 @@ $ARGUMENTS
 - `--techs=auto`: Technologien automatisch erkennen (Standard). Oder kommagetrennt angeben: `--techs=symfony,react`
 - `--max-workers=4`: Maximale parallele Auditor-Worker (Standard: 4, max: 4)
 - `--output-dir=<path>`: Benutzerdefiniertes Ausgabeverzeichnis für Audit-Ergebnisse
+- `--max-cost=<dollars>`: Maximales Budget in Dollar. Wenn die geschaetzten Parallelkosten diesen Schwellenwert ueberschreiten, wird die Ausfuehrung mit einer OVER BUDGET Meldung blockiert
 - `--dry-run`: Team-Zusammensetzung und geschätzte Kosten anzeigen, ohne auszuführen
 - `--skip-aggregation`: Ergebnisse pro Stack ohne Zusammenführung ausgeben
 - `--sequential`: Audits sequenziell statt parallel ausführen (kein Agent-Teams-Overhead). Nützlich für Einzeltechnologie-Projekte oder wenn Agent Teams nicht verfügbar ist.
@@ -27,6 +28,28 @@ $ARGUMENTS
 - `Tools/AgentTeams/lib/result-aggregator.sh` verfügbar
 - `Tools/AgentTeams/lib/cost-estimator.sh` verfügbar
 
+## Garde-Fou Fast Mode (Confirmation Bloquante)
+
+**OBLIGATOIRE** : Vor dem Start des Teams MUSS der Audit-Leader:
+
+1. Erkennen, ob der Fast Mode aktiv ist (Lightning-Bolt-Indikator im Terminal)
+2. Wenn Fast Mode aktiv:
+   - Vergleichs-Dashboard Standard vs. Fast via `cost-estimator.sh --fast-mode` anzeigen
+   - **Blockierende Warnung** mit verglichenen Kosten anzeigen:
+     ```
+     ⚠️  FAST MODE ERKANNT — Opus-Kosten 6x hoeher!
+
+     | Modus     | Input ($/M) | Output ($/M) | Geschaetzte Kosten dieses Audits |
+     |-----------|-------------|--------------|----------------------------------|
+     | Standard  | $5.00       | $25.00       | ~$X.XX                           |
+     | Fast      | $30.00      | $150.00      | ~$Y.YY                           |
+
+     Moechten Sie im Fast Mode fortfahren? (ja/nein)
+     Empfehlung: Tippen Sie /fast, um vor dem Fortfahren zu deaktivieren.
+     ```
+   - **Warten auf explizite Bestaetigung** des Benutzers vor dem Fortfahren
+   - Wenn der Benutzer ablehnt, abbrechen mit Nachricht, die `/fast` zum Deaktivieren vorschlaegt
+
 ## Wann verwenden (vs. sequenzielles Audit)
 
 | Bedingung | Team-Audit verwenden | `--sequential`-Flag verwenden |
@@ -92,6 +115,11 @@ Tools/AgentTeams/lib/cost-estimator.sh \
 
 Geschätzte Kosten dem Benutzer anzeigen. Im `--dry-run`-Modus hier stoppen.
 
+**Budgetgarantie**: Wenn `--max-cost` angegeben ist, pruefen dass `PAR_COST <= max_cost`. Wenn die geschaetzten Kosten das Budget ueberschreiten:
+- `OVER BUDGET: geschaetzte Kosten $X.XX > Budget $Y.YY` anzeigen
+- Ausfuehrung abbrechen (Worker NICHT starten)
+- Vorschlagen, die Anzahl der Stacks zu reduzieren oder `--sequential` zu verwenden
+
 ### Schritt 4: Team starten (Fan-Out)
 
 ```
@@ -115,6 +143,33 @@ Audit-Leader (opus) — koordiniert über TaskCreate/SendMessage
 3. Worker beanspruchen Aufgaben via `TaskUpdate` (Status: in_progress)
 4. Worker schreiben Ergebnisse nur in ihr isoliertes Verzeichnis
 
+**Lean Context pro Worker (A4)**: Jeder Worker erhaelt nur die technologische Referenz seines Stacks. Laden Sie NICHT den Kontext aller Technologien.
+- Symfony Worker → nur `@.claude/references/symfony/CLAUDE.md`
+- React Worker → nur `@.claude/references/react/`
+- Python Worker → nur `@.claude/references/python/`
+- etc.
+
+**Strukturiertes Spawn-Template (TaskCreate)**: Der Leader MUSS in jedem `TaskCreate` einfuegen:
+
+```
+Subject: "Audit <TechName> stack"
+Description:
+  Projekt: <projektname>
+  Technologie: <tech-name>
+  Docker-Service: <docker-service-name>
+  Root-Verzeichnis: <tech-root-directory>
+  Referenz: @.claude/references/<tech>/CLAUDE.md
+  Checks: [architecture, code-quality, testing, security]
+  Ausgabeformat: result.json in <output-dir>/<tech>/
+  Output-Schema:
+    { "tech": "<tech>", "score": <0-100>,
+      "architecture": { "score": <0-25>, "findings": [...] },
+      "code_quality": { "score": <0-25>, "findings": [...] },
+      "testing": { "score": <0-25>, "findings": [...] },
+      "security": { "score": <0-25>, "findings": [...] } }
+activeForm: "Audit <TechName>"
+```
+
 **Worker-Anweisungen** (pro Stack):
 
 Jeder Worker führt die 4 Audit-Kategorien sequenziell innerhalb seines Stacks aus:
@@ -164,9 +219,17 @@ Jeder Worker schreibt `result.json` in sein isoliertes Ausgabeverzeichnis:
 }
 ```
 
+**Completion-Nachrichten-Verbositaet (B4)**: Worker MUESSEN ihre Completion-Nachrichten auf < 50 Token begrenzen. Details in `result.json` schreiben, nicht in die Nachricht. Format: `DONE: <tech> <score>/100 | <findings_count> findings`
+
 ### Schritt 5: Synchronisationsbarriere
 
-Leader wartet, bis alle Worker-Aufgaben den Status `completed` erreicht haben (Abfrage via `TaskList`). Wenn ein Worker sein Timeout (5 Minuten pro Stack) überschreitet, markiert der Leader ihn als fehlgeschlagen und fährt mit Teilergebnissen fort.
+Leader wartet, bis alle Worker-Aufgaben den Status `completed` erreicht haben via `TaskList`-Polling.
+
+**Polling-Kadenz (B5)**: `TaskList` alle 30 Sekunden. Nach 3 aufeinanderfolgenden Polls ohne Statusaenderung, auf 60 Sekunden reduzieren. Verwenden Sie `TeammateIdle`/`TaskCompleted` Hooks (v2.1.33+) fuer reaktivere Benachrichtigung, falls verfuegbar.
+
+Wenn ein Worker sein Timeout (5 Minuten pro Stack) ueberschreitet, markiert der Leader ihn als fehlgeschlagen und faehrt mit Teilergebnissen fort.
+
+**Leader-Kontextwiederherstellung (A6)**: Um den Context-Compaction-Bug (#23620) abzumildern, MUSS der Leader `TaskList` alle 5 Worker-Completions neu lesen, um sein Bewusstsein fuer den Team-Status aufzufrischen. Wenn eine laengere Ruhephase (>3 Min ohne Update) erkannt wird, ein vollstaendiges Re-Read von `TaskList` erzwingen.
 
 ### Schritt 6: Ergebnis-Aggregation
 

package/Dev/i18n/de/Team/commands/delivery.md

@@ -21,6 +21,7 @@ $ARGUMENTS
 - `--dry-run`: Team-Zusammensetzung, Kostenschätzung und Story-Zuweisungen anzeigen, ohne auszuführen
 - `--quality-threshold=6`: Minimaler INVEST-Score für Phase 1 (Standard: 6/6)
 - `--max-rewrites=2`: Maximale Überarbeitungsschleifen pro Artefakt in Phase 1 (Standard: 2)
+- `--max-cost=<dollars>`: Maximales Budget in Dollar. Wenn die geschaetzten Parallelkosten diesen Schwellenwert ueberschreiten, wird die Ausfuehrung mit einer OVER BUDGET Meldung blockiert
 
 ## Voraussetzungen
 
@@ -32,6 +33,28 @@ $ARGUMENTS
 - `Tools/AgentTeams/lib/cost-estimator.sh` verfügbar
 - `Tools/AgentTeams/lib/result-aggregator.sh` verfügbar
 
+## Garde-Fou Fast Mode (Blockierende Bestaetigung)
+
+**OBLIGATORISCH**: Vor dem Start des Teams MUSS der Delivery Lead:
+
+1. Erkennen, ob der Fast Mode aktiv ist (Lightning-Bolt-Indikator im Terminal)
+2. Wenn Fast Mode aktiv:
+   - Vergleichs-Dashboard Standard vs. Fast via `cost-estimator.sh --fast-mode` anzeigen
+   - **Blockierende Warnung** mit verglichenen Kosten anzeigen:
+     ```
+     ⚠️  FAST MODE ERKANNT — Opus-Kosten 6x hoeher!
+
+     | Modus     | Input ($/M) | Output ($/M) | Geschaetzte Kosten dieser Lieferung |
+     |-----------|-------------|--------------|-------------------------------------|
+     | Standard  | $5.00       | $25.00       | ~$X.XX                              |
+     | Fast      | $30.00      | $150.00      | ~$Y.YY                              |
+
+     Moechten Sie im Fast Mode fortfahren? (ja/nein)
+     Empfehlung: Tippen Sie /fast, um vor dem Fortfahren zu deaktivieren.
+     ```
+   - **Warten auf explizite Bestaetigung** des Benutzers vor dem Fortfahren
+   - Wenn der Benutzer ablehnt, abbrechen mit Nachricht, die `/fast` zum Deaktivieren vorschlaegt
+
 ## Wann verwenden (vs. sequenziell oder andere Teams)
 
 | Bedingung | Team-Delivery verwenden | Alternative |
@@ -57,7 +80,7 @@ $ARGUMENTS
 Delivery-Lead (opus) — Orchestrierung, Validierung, gemeinsamer Kontext
   |
   +-- Writer (sonnet)    : Erstellt EPICs, US (INVEST+3C+Gherkin), Aufgaben
-  +-- Reviewer (sonnet)  : Validiert Qualität (INVEST 6/6, AC-Abdeckung, Testbarkeit, Slicing)
+  +-- Reviewer (haiku)   : Validiert Qualität (INVEST 6/6, AC-Abdeckung, Testbarkeit, Slicing)
   +-- Architect (sonnet) : Validiert technische Machbarkeit + Dateidomänen-Zuordnung
 ```
 
@@ -68,16 +91,34 @@ Der Delivery-Lead validiert die Eingabe:
 1. PRD oder Tech Spec vom angegebenen Pfad lesen
 2. PRD-Gate validieren (>=80%) -- bei Score unter Schwellenwert mit klarer Meldung abbrechen
 3. Features, Anforderungen und Abnahmekriterien-Umfang extrahieren
-4. Team via `TeamCreate` erstellen
+4. Kosten schaetzen via `cost-estimator.sh --task-type delivery --techs <worker_count>`
+5. **Budgetgarantie**: Wenn `--max-cost` angegeben ist, pruefen dass geschaetzte Kosten <= max_cost. Bei Ueberschreitung: `OVER BUDGET` anzeigen, abbrechen
+6. Team via `TeamCreate` erstellen
 
 #### Schritt 1.2: Team starten (Phase 1)
 
 Der Lead startet 3 Phase-1-Worker via `Task`-Tool:
 
 1. **Writer** (sonnet): Angewiesen, EPICs und User Stories im INVEST+3C+Gherkin-Format zu erstellen
-2. **Reviewer** (sonnet): Angewiesen, Qualität gemäß der untenstehenden Prüftabelle zu validieren
+2. **Reviewer** (haiku): Angewiesen, Qualität gemäß der untenstehenden Prüftabelle zu validieren — haiku reicht fuer diese Klassifikationsaufgabe (12x billiger als sonnet im Output)
 3. **Architect** (sonnet): Angewiesen, technische Machbarkeit zu validieren und Dateidomänen-Zuordnungen zu erstellen
 
+**Lean Context pro Phase-1-Worker**: Jeder Worker erhaelt nur das PRD/Tech Spec und die technologische Referenz des Projekts. Laden Sie NICHT die Referenzen aller Technologien.
+
+**Strukturiertes Spawn-Template Phase 1 (TaskCreate)**: Der Lead MUSS in jede Aufgabe einfuegen:
+```
+Subject: "Write <artefact-type>: <titel>"
+Description:
+  Projekt: <projektname>
+  Technologie: <projekt-tech>
+  PRD/Spec: <Inhalt oder Referenz>
+  Erwartetes Artefakt: <EPIC|US|Task>
+  Format: INVEST+3C+Gherkin fuer US
+  Erfolgskriterien: INVEST 6/6, nominale ACs >= 1, alternative >= 2, Fehler >= 2
+  Referenz: @.claude/references/<tech>/CLAUDE.md
+activeForm: "Writing <artefact-type>"
+```
+
 #### Schritt 1.3: Artefakt-Pipeline
 
 Die Pipeline ist sequenziell pro Artefakt, aber **Pipeline-artig** über Artefakte hinweg (mehrere Artefakte gleichzeitig in verschiedenen Phasen):
@@ -109,6 +150,8 @@ Der Lead koordiniert via `SendMessage`:
 | Story Points | 1-8 | INVEST-Kriterium "Small" |
 | Expliziter Nutzen | Ja | INVEST-Kriterium "Valuable" |
 
+**Gemeinsame Dateien-Erkennung (B2)**: Der Architect MUSS explizit gemeinsame Verzeichnisse (`**/Shared/**`, `**/Common/**`, `**/Utils/**`, `**/Helpers/**`) erkennen. Stories, die Dateien in diesen Verzeichnissen beruehren, erhalten automatisch einen `overlaps_with`-Marker und werden in derselben Welle sequenziert.
+
 #### Architect-Dateidomänen-Zuordnung
 
 Der Architect erstellt eine Dateidomänen-Zuordnung für jede User Story:
@@ -192,13 +235,62 @@ QUALITY METRICS
 
 ### Phasenübergang
 
-Bei `--phase=all` führt der Lead einen Teamübergang durch:
+Bei `--phase=all` führt der Lead einen sicheren Teamübergang durch:
+
+#### Schritt T.1: Handoff-Vertrag schreiben
+
+Der Lead schreibt eine `phase-handoff.yaml`-Datei im Sitzungsverzeichnis, bevor Phase 1 beendet wird:
+
+```yaml
+# .bmad/phase-handoff.yaml — Interphasen-Vertrag
+handoff_version: "1.0"
+timestamp: "2026-02-13T10:30:00Z"
+sprint: "<sprint-name>"
+phase1_status: "completed"
+
+stories_accepted:
+  - id: US-001
+    invest_score: 6
+    file_domains: [src/Domain/User/, src/App/User/, tests/Unit/User/]
+  - id: US-002
+    invest_score: 6
+    file_domains: [src/Domain/Order/, src/App/Order/, tests/Unit/Order/]
+
+stories_needs_review:
+  - id: US-004
+    reason: "INVEST 4/6 nach 2 Überarbeitungen"
+
+parallelization_waves:
+  - wave: 1
+    stories: [US-001, US-002]
+    reason: "0 Dateidomänen-Überlappung"
+  - wave: 2
+    stories: [US-003]
+    reason: "hängt von Dateien aus US-001 ab"
+
+phase1_metrics:
+  artifacts_created: 4
+  rewrites_total: 3
+  avg_invest_score: 5.5
+  duration_minutes: 20
+```
+
+#### Schritt T.2: Phase 1 herunterfahren und Phase 2 starten
 
 1. `shutdown_request` an Writer, Reviewer, Architect senden
 2. Warten, bis alle Worker heruntergefahren sind (~30s)
-3. Lead behält vollständigen Kontext aus Phase 1 (Stories, Domänenzuordnung, Wellen)
+3. Lead behält vollständigen Kontext aus Phase 1 via `phase-handoff.yaml`
+3.5. **Kontextwiederherstellung (A6)**: `phase-handoff.yaml` neu lesen, um den Status vor Start von Phase 2 aufzufrischen. Wenn der Kontext kompaktiert wurde (Bug #23620), garantiert dieser Re-Read vollstaendiges Bewusstsein fuer Phase-1-Artefakte.
 4. Mit Phase-2-Start fortfahren
 
+#### Wiederherstellung nach Absturz
+
+Wenn der Lead zwischen den beiden Phasen neu startet:
+1. Existenz von `.bmad/phase-handoff.yaml` prüfen
+2. Wenn vorhanden mit `phase1_status: completed`, direkt in Phase 2 fortfahren
+3. `parallelization_waves` und `file_domains` aus dem Handoff für die Zuweisung verwenden
+4. Wenn nicht vorhanden oder `phase1_status != completed`, Phase 1 neu starten
+
 ### Phase 2: Implementierung (Geschwindigkeit + Delegation)
 
 #### Phase-2-Team-Zusammensetzung
@@ -230,11 +322,25 @@ Der Lead startet Entwickler-Worker (bis zu `--max-workers`) und weist Stories na
 2. Wenn Wave 1 abgeschlossen ist, werden Wave-2-Stories zugewiesen
 3. Von abgeschlossenen Stories freigewordene Worker übernehmen die nächste verfügbare Story
 
+**Lean Context pro Phase-2-Worker**: Jeder Worker erhaelt nur die zugewiesene Story und die technologische Referenz des Projekts. Laden Sie NICHT andere Stories oder das vollstaendige PRD.
+
 Der Lead erstellt einen `TaskCreate` pro Story:
 
-- **Betreff**: `Implement US-XXX: <story title>`
-- **Beschreibung**: Vollständiger Story-Inhalt, Abnahmekriterien, Tech-Spec-Referenzen, TDD-Anforderungen, Dateidomänen-Umfang
-- **activeForm**: `Implementing US-XXX`
+**Strukturiertes Spawn-Template Phase 2 (TaskCreate)**:
+```
+Subject: "Implement US-XXX: <story title>"
+Description:
+  Projekt: <projektname>
+  Technologie: <projekt-tech>
+  Story: <vollstaendiger Story-Inhalt>
+  Abnahmekriterien: <vollstaendige ACs mit Gherkin>
+  Dateidomaene: <Verzeichnisse aus phase-handoff.yaml>
+  Ausserhalb Grenzen: <Verzeichnisse von ANDEREN in Bearbeitung befindlichen Stories>
+  TDD-Befehle: <tech-spezifische Docker-Befehle>
+  Erfolgskriterien: Alle AC-Tests bestanden, Lint sauber, Abdeckung nicht reduziert
+  Referenz: @.claude/references/<tech>/CLAUDE.md
+activeForm: "Implementing US-XXX"
+```
 
 #### Schritt 2.2: Worker-Ausführung (pro Story)
 
@@ -300,6 +406,12 @@ Der Lead klassifiziert Fehler gemäß der Ralph-Recovery-Engine:
 | 2 | Eingeschränkt | Mit Warnung fortfahren | Docs, optionale Gates, Abdeckungsrückgang |
 | 3 | Blockiert | An Menschen eskalieren | Sicherheit, Architektur, Auth |
 
+**Polling-Kadenz (B5)**: Der Lead pollt `TaskList` alle 30 Sekunden. Nach 3 aufeinanderfolgenden Polls ohne Aenderung, auf 60 Sekunden reduzieren. Verwenden Sie `TeammateIdle`/`TaskCompleted` Hooks (v2.1.33+), falls verfuegbar.
+
+**Nachrichten-Verbositaet (B4)**: Worker MUESSEN ihre Completion-Nachrichten auf < 50 Token begrenzen. Format: `DONE: US-XXX tests pass, +X files`. Details in die Aufgabenzusammenfassung schreiben.
+
+**Lead-Kontextwiederherstellung (A6)**: Um den Context-Compaction-Bug (#23620) abzumildern, MUSS der Lead `TaskList` alle 5 Worker-Completions neu lesen. Zu Beginn von Phase 2 systematisch `phase-handoff.yaml` neu lesen, um vollstaendiges Bewusstsein fuer Phase-1-Artefakte zu garantieren.
+
 **Worker-Blockade-Erkennung**: Wenn ein Worker seine Aufgabe seit 10 Minuten nicht aktualisiert hat, sendet der Lead eine Statusprüfungsnachricht. Wenn innerhalb von 2 Minuten keine Antwort erfolgt, markiert der Lead die Story als blockiert und weist sie einem anderen Worker zu oder reiht sie für menschliche Überprüfung ein.
 
 **Dateidomänen-Konflikt zur Laufzeit erkannt**: Wenn ein Worker einen Dateikonflikt mit dem Bereich eines anderen Workers meldet, stoppt der Lead den konfligierenden Worker, wartet auf den Abschluss des ersten und weist dann sequenziell zu.

package/Dev/i18n/de/Team/commands/security.md

@@ -17,6 +17,7 @@ $ARGUMENTS
 - `--output-dir=<path>`: Benutzerdefiniertes Ausgabeverzeichnis für Sicherheitsergebnisse
 - `--dry-run`: Team-Zusammensetzung und Scan-Plan anzeigen, ohne auszuführen
 - `--sarif`: Ergebnisse im SARIF-Format ausgeben (für CI/CD-Integration)
+- `--max-cost=<dollars>`: Maximales Budget in Dollar. Wenn die geschaetzten Parallelkosten diesen Schwellenwert ueberschreiten, wird die Ausfuehrung mit einer OVER BUDGET Meldung blockiert
 
 ## Voraussetzungen
 
@@ -27,6 +28,28 @@ $ARGUMENTS
 - `Tools/AgentTeams/lib/result-aggregator.sh` verfügbar
 - `Tools/AgentTeams/lib/cost-estimator.sh` verfügbar
 
+## Garde-Fou Fast Mode (Blockierende Bestaetigung)
+
+**OBLIGATORISCH**: Vor dem Start des Teams MUSS der Security Lead:
+
+1. Erkennen, ob der Fast Mode aktiv ist (Lightning-Bolt-Indikator im Terminal)
+2. Wenn Fast Mode aktiv:
+   - Vergleichs-Dashboard Standard vs. Fast via `cost-estimator.sh --fast-mode` anzeigen
+   - **Blockierende Warnung** mit verglichenen Kosten anzeigen:
+     ```
+     ⚠️  FAST MODE ERKANNT — Opus-Kosten 6x hoeher!
+
+     | Modus     | Input ($/M) | Output ($/M) | Geschaetzte Kosten dieser Review |
+     |-----------|-------------|--------------|----------------------------------|
+     | Standard  | $5.00       | $25.00       | ~$X.XX                           |
+     | Fast      | $30.00      | $150.00      | ~$Y.YY                           |
+
+     Moechten Sie im Fast Mode fortfahren? (ja/nein)
+     Empfehlung: Tippen Sie /fast, um vor dem Fortfahren zu deaktivieren.
+     ```
+   - **Warten auf explizite Bestaetigung** des Benutzers vor dem Fortfahren
+   - Wenn der Benutzer ablehnt, abbrechen mit Nachricht, die `/fast` zum Deaktivieren vorschlaegt
+
 ## Team-Zusammensetzung
 
 | Rolle | Modell | Agent | Verantwortlichkeit |
@@ -65,6 +88,15 @@ Tools/AgentTeams/lib/compatibility-check.sh \
 
 ### Schritt 3: Team starten (Fan-Out)
 
+**Kostenschaetzung**: Der Security Lead schaetzt die Kosten via `cost-estimator.sh --task-type security --techs <worker_count>`.
+
+**Budgetgarantie**: Wenn `--max-cost` angegeben ist, pruefen dass geschaetzte Kosten <= max_cost. Bei Ueberschreitung: `OVER BUDGET` anzeigen, abbrechen.
+
+**Lean Context pro Worker**: Jeder Reviewer erhaelt nur den fuer seine Dimension notwendigen Kontext:
+- Code Reviewer → `@.claude/references/<tech>/CLAUDE.md` + Liste der Quelldateien
+- Dependency-Auditor → Liste der Lockfiles (composer.lock, package-lock.json, etc.)
+- Infra-Reviewer → Dockerfiles, docker-compose.yml, CI/CD-Configs
+
 ```
 Sicherheits-Lead (opus) — orchestriert über TaskCreate/SendMessage
   |
@@ -81,6 +113,18 @@ Sicherheits-Lead (opus) — orchestriert über TaskCreate/SendMessage
 
 Der Lead erstellt 3 Aufgaben via `TaskCreate`:
 
+**Strukturiertes Spawn-Template (TaskCreate)**: Der Lead MUSS in jede Aufgabe einfuegen:
+```
+Subject: "Security Review <dimension>"
+Description:
+  Projekt: <projektname>
+  Dimension: <code|deps|infra>
+  Scope: <zu analysierende Dateien/Verzeichnisse>
+  Tools: <zu verwendende Docker-Befehle>
+  Ausgabeformat: Findings im Format { severity, category, file, description }
+activeForm: "Security Review <dimension>"
+```
+
 #### Aufgabe A: Quellcode-Sicherheitsreview
 
 **Umfang**: Analyse von Schwachstellen im Anwendungsquellcode
@@ -187,7 +231,15 @@ docker compose config --quiet  # Compose-Syntax validieren
 
 ### Schritt 4: Synchronisationsbarriere
 
-Sicherheits-Lead wartet, bis alle 3 Reviewer-Aufgaben abgeschlossen sind. Timeout: 8 Minuten pro Reviewer. Wenn ein Reviewer das Timeout überschreitet, fährt der Lead mit den verfügbaren Ergebnissen fort und vermerkt die Lücke.
+Sicherheits-Lead wartet, bis alle 3 Reviewer-Aufgaben abgeschlossen sind.
+
+**Polling-Kadenz (B5)**: `TaskList` alle 30 Sekunden. Nach 3 aufeinanderfolgenden Polls ohne Aenderung, auf 60 Sekunden reduzieren. Verwenden Sie `TeammateIdle`/`TaskCompleted` Hooks (v2.1.33+), falls verfuegbar.
+
+**Nachrichten-Verbositaet (B4)**: Reviewer MUESSEN ihre Completion-Nachrichten auf < 50 Token begrenzen. Format: `DONE: <dimension> <findings_count> findings (<critical>C/<high>H/<medium>M)`. Details in die Ergebnisdatei schreiben.
+
+**Lead-Kontextwiederherstellung (A6)**: Um den Context-Compaction-Bug (#23620) abzumildern, MUSS der Lead `TaskList` nach jeder Reviewer-Completion neu lesen, um sein Bewusstsein fuer den Team-Status aufzufrischen.
+
+Timeout: 8 Minuten pro Reviewer. Wenn ein Reviewer das Timeout überschreitet, fährt der Lead mit den verfügbaren Ergebnissen fort und vermerkt die Lücke.
 
 ### Schritt 5: Korrelation und Priorisierung
 

package/Dev/i18n/de/Team/commands/sprint.md

@@ -18,6 +18,7 @@ $ARGUMENTS
 - `--max-stories=10`: Maximale Anzahl zu bearbeitender Stories (Standard: 10)
 - `--timeout=12`: Maximale Laufzeit in Stunden (Standard: 12)
 - `--dry-run`: Team-Zusammensetzung und Story-Zuweisungen anzeigen, ohne auszuführen
+- `--max-cost=<dollars>`: Maximales Budget in Dollar. Wenn die geschaetzten Parallelkosten diesen Schwellenwert ueberschreiten, wird die Ausfuehrung mit einer OVER BUDGET Meldung blockiert
 - `--ralph-mode`: Ralph-Recovery-Engine aktivieren (Fehlerklassifizierung, Auto-Retry, Eskalationsdienst) zusammen mit Agent-Teams-Parallelisierung.
 
 ## Voraussetzungen
@@ -31,6 +32,28 @@ $ARGUMENTS
 - `Tools/AgentTeams/lib/compatibility-check.sh` verfügbar
 - `Tools/AgentTeams/lib/cost-estimator.sh` verfügbar
 
+## Garde-Fou Fast Mode (Blockierende Bestaetigung)
+
+**OBLIGATORISCH**: Vor dem Start des Teams MUSS der Sprint-Conductor:
+
+1. Erkennen, ob der Fast Mode aktiv ist (Lightning-Bolt-Indikator im Terminal)
+2. Wenn Fast Mode aktiv:
+   - Vergleichs-Dashboard Standard vs. Fast via `cost-estimator.sh --fast-mode` anzeigen
+   - **Blockierende Warnung** mit verglichenen Kosten anzeigen:
+     ```
+     ⚠️  FAST MODE ERKANNT — Opus-Kosten 6x hoeher!
+
+     | Modus     | Input ($/M) | Output ($/M) | Geschaetzte Kosten dieses Sprints |
+     |-----------|-------------|--------------|-----------------------------------|
+     | Standard  | $5.00       | $25.00       | ~$X.XX                            |
+     | Fast      | $30.00      | $150.00      | ~$Y.YY                            |
+
+     Moechten Sie im Fast Mode fortfahren? (ja/nein)
+     Empfehlung: Tippen Sie /fast, um vor dem Fortfahren zu deaktivieren.
+     ```
+   - **Warten auf explizite Bestaetigung** des Benutzers vor dem Fortfahren
+   - Wenn der Benutzer ablehnt, abbrechen mit Nachricht, die `/fast` zum Deaktivieren vorschlaegt
+
 ## Wann verwenden (vs. sequenzieller Sprint)
 
 | Bedingung | Team-Sprint verwenden (parallel) | `--sequential` oder Einzelstory verwenden |
@@ -53,9 +76,13 @@ Der Sprint-Dirigent lädt den Sprint-Status:
 2. Stories mit Status `ready-for-dev` filtern
 3. Story-Unabhängigkeit analysieren (auf Dateidomänen-Überlappung prüfen)
 4. Stories in parallelisierbare Gruppen aufteilen
+5. Kosten schaetzen via `cost-estimator.sh --task-type sprint --techs <worker_count>`
+6. **Budgetgarantie**: Wenn `--max-cost` angegeben ist, pruefen dass geschaetzte Kosten <= max_cost. Bei Ueberschreitung: `OVER BUDGET` anzeigen, abbrechen, vorschlagen die Anzahl der Stories zu reduzieren oder `--sequential` zu verwenden
 
 **Unabhängigkeitsprüfung**: Zwei Stories sind unabhängig, wenn ihre Abnahmekriterien und ihr Implementierungsumfang nicht auf dieselben Quelldateien verweisen. Der Dirigent überprüft die Beschreibung und Tech-Spec-Referenzen jeder Story, um dies festzustellen.
 
+**Gemeinsame Dateien-Erkennung (B2)**: Bei der Unabhaengigkeitsanalyse explizit gemeinsame Verzeichnisse (`**/Shared/**`, `**/Common/**`, `**/Utils/**`, `**/Helpers/**`) erkennen. Stories, die Dateien in diesen Verzeichnissen beruehren, erhalten automatisch einen `overlaps_with`-Marker und werden im gleichen Worker sequenziert.
+
 ### Schritt 2: Story-Zuweisung
 
 ```
@@ -74,11 +101,25 @@ Sprint-Dirigent (opus) — koordiniert über TaskCreate/SendMessage
   +------------------------------------------+
 ```
 
+**Lean Context pro Worker**: Jeder Worker erhaelt nur die technologische Referenz des Projekts (nicht alle Technologien). Der Conductor uebergibt nur `@.claude/references/<projekt-tech>/CLAUDE.md` im Kontext.
+
 Der Dirigent erstellt einen `TaskCreate` pro Story:
 
-- **Betreff**: `Implement US-XXX: <story title>`
-- **Beschreibung**: Vollständiger Story-Inhalt, Abnahmekriterien, Tech-Spec-Referenzen, TDD-Anforderungen
-- **activeForm**: `Implementing US-XXX`
+**Strukturiertes Spawn-Template (TaskCreate)**:
+```
+Subject: "Implement US-XXX: <story title>"
+Description:
+  Projekt: <projektname>
+  Technologie: <projekt-tech>
+  Story: <vollstaendiger Story-Inhalt>
+  Abnahmekriterien: <vollstaendige ACs mit Gherkin>
+  Dateidomaene: <erwartete Quellverzeichnisse>
+  Ausserhalb Grenzen: <NICHT zu aendernde Verzeichnisse>
+  TDD-Befehle: <tech-spezifische Docker-Befehle>
+  Erfolgskriterien: Alle AC-Tests bestanden, Lint sauber, Abdeckung nicht reduziert
+  Referenz: @.claude/references/<tech>/CLAUDE.md
+activeForm: "Implementing US-XXX"
+```
 
 ### Schritt 3: Worker-Ausführung (pro Story)
 
@@ -144,6 +185,12 @@ Der Dirigent klassifiziert Fehler gemäß der Ralph-Recovery-Engine:
 | 2 | Eingeschränkt | Mit Warnung fortfahren | Docs, optionale Gates, Abdeckungsrückgang |
 | 3 | Blockiert | An Menschen eskalieren | Sicherheit, Architektur, Auth |
 
+**Polling-Kadenz (B5)**: Der Conductor pollt `TaskList` alle 30 Sekunden. Nach 3 aufeinanderfolgenden Polls ohne Aenderung, auf 60 Sekunden reduzieren. Verwenden Sie `TeammateIdle`/`TaskCompleted` Hooks (v2.1.33+), falls verfuegbar.
+
+**Nachrichten-Verbositaet (B4)**: Worker MUESSEN ihre Completion-Nachrichten auf < 50 Token begrenzen. Format: `DONE: US-XXX tests pass, +X files`. Details in die Aufgabenzusammenfassung schreiben, nicht in die Nachricht.
+
+**Conductor-Kontextwiederherstellung (A6)**: Um den Context-Compaction-Bug (#23620) abzumildern, MUSS der Conductor `TaskList` alle 5 Worker-Completions neu lesen, um sein Bewusstsein fuer den Team-Status aufzufrischen.
+
 **Worker-Blockade-Erkennung**: Wenn ein Worker seine Aufgabe seit 10 Minuten nicht aktualisiert hat, sendet der Dirigent eine Statusprüfungsnachricht. Wenn innerhalb von 2 Minuten keine Antwort erfolgt, markiert der Dirigent die Story als blockiert und weist sie einem anderen Worker zu oder reiht sie für menschliche Überprüfung ein.
 
 ### Schritt 6: Sprint-Abschluss

package/Dev/i18n/en/Team/commands/audit.md

@@ -1,6 +1,6 @@
 ---
 description: Full Audit Team - Parallel multi-technology audit using Agent Teams
-argument-hint: [--techs=auto|tech1,tech2] [--max-workers=4]
+argument-hint: "[--techs=auto|tech1,tech2] [--max-workers=4]"
 ---
 
 # Full Audit Team - Parallel Multi-Technology Audit
@@ -14,6 +14,7 @@ $ARGUMENTS
 - `--techs=auto`: Auto-detect technologies (default). Or specify comma-separated: `--techs=symfony,react`
 - `--max-workers=4`: Maximum parallel auditor workers (default: 4, max: 4)
 - `--output-dir=<path>`: Custom output directory for audit results
+- `--max-cost=<dollars>`: Maximum budget in dollars. If the estimated parallel cost exceeds this threshold, execution is blocked with an OVER BUDGET message
 - `--dry-run`: Show team composition and estimated cost without executing
 - `--skip-aggregation`: Output per-stack results without merging
 - `--sequential`: Run audits sequentially instead of in parallel (no Agent Teams overhead). Useful for single-technology projects or when Agent Teams is not available.
@@ -27,6 +28,28 @@ $ARGUMENTS
 - `Tools/AgentTeams/lib/result-aggregator.sh` available
 - `Tools/AgentTeams/lib/cost-estimator.sh` available
 
+## Fast Mode Guard (Blocking Confirmation)
+
+**MANDATORY**: Before launching the team, the leader MUST:
+
+1. Detect if Fast Mode is active (lightning bolt indicator in terminal)
+2. If Fast Mode is active:
+   - Display the comparative dashboard standard vs fast via `cost-estimator.sh --fast-mode`
+   - **Display a blocking warning** with cost comparison:
+     ```
+     ⚠️  FAST MODE DETECTED — Opus costs 6x higher!
+
+     | Mode     | Input ($/M) | Output ($/M) | Estimated cost this audit |
+     |----------|-------------|--------------|--------------------------|
+     | Standard | $5.00       | $25.00       | ~$X.XX                   |
+     | Fast     | $30.00      | $150.00      | ~$Y.YY                   |
+
+     Do you want to continue in Fast Mode? (yes/no)
+     Recommendation: type /fast to disable before continuing.
+     ```
+   - **Wait for explicit user confirmation** before proceeding
+   - If the user refuses, abort with a message suggesting `/fast` to disable
+
 ## When to Use (vs. Sequential Audit)
 
 | Condition | Use Team Audit | Use `--sequential` flag |
@@ -92,6 +115,11 @@ Tools/AgentTeams/lib/cost-estimator.sh \
 
 Display estimated cost to user. In `--dry-run` mode, stop here.
 
+**Budget guard**: If `--max-cost` is specified, check that `PAR_COST <= max_cost`. If the estimated cost exceeds the budget:
+- Display `OVER BUDGET: estimated cost $X.XX > budget $Y.YY`
+- Abort execution (do NOT launch workers)
+- Suggest reducing the number of stacks or using `--sequential`
+
 ### Step 4: Team Spawn (Fan-Out)
 
 ```
@@ -115,6 +143,33 @@ Audit Leader (opus) — coordinates via TaskCreate/SendMessage
 3. Workers claim tasks via `TaskUpdate` (status: in_progress)
 4. Workers write results to their isolated directory only
 
+**Lean context per worker (A4)**: Each worker only receives its stack's technology reference. Do NOT load context for all technologies.
+- Symfony worker → `@.claude/references/symfony/CLAUDE.md` only
+- React worker → `@.claude/references/react/` only
+- Python worker → `@.claude/references/python/` only
+- etc.
+
+**Structured spawn template (TaskCreate)**: The leader MUST include in each `TaskCreate`:
+
+```
+Subject: "Audit <TechName> stack"
+Description:
+  Project: <project-name>
+  Technology: <tech-name>
+  Docker service: <docker-service-name>
+  Root directory: <tech-root-directory>
+  Reference: @.claude/references/<tech>/CLAUDE.md
+  Checks: [architecture, code-quality, testing, security]
+  Output format: result.json in <output-dir>/<tech>/
+  Output schema:
+    { "tech": "<tech>", "score": <0-100>,
+      "architecture": { "score": <0-25>, "findings": [...] },
+      "code_quality": { "score": <0-25>, "findings": [...] },
+      "testing": { "score": <0-25>, "findings": [...] },
+      "security": { "score": <0-25>, "findings": [...] } }
+activeForm: "Auditing <TechName>"
+```
+
 **Worker instructions** (per stack):
 
 Each worker executes the 4 audit categories sequentially within its stack:
@@ -164,9 +219,17 @@ Each worker writes `result.json` to its isolated output directory:
 }
 ```
 
+**Completion message verbosity (B4)**: Workers MUST limit their completion messages to < 50 tokens. Write details to the `result.json` file, not in the message. Format: `DONE: <tech> <score>/100 | <findings_count> findings`
+
 ### Step 5: Sync Barrier
 
-Leader waits for all worker tasks to reach `completed` status via `TaskList` polling. If a worker exceeds its timeout (5 minutes per stack), leader marks it as failed and proceeds with partial results.
+Leader waits for all worker tasks to reach `completed` status via `TaskList` polling.
+
+**Polling cadence (B5)**: `TaskList` every 30 seconds. After 3 consecutive polls without status change, reduce to 60 seconds. Use `TeammateIdle`/`TaskCompleted` hooks (v2.1.33+) for more reactive notification if available.
+
+If a worker exceeds its timeout (5 minutes per stack), leader marks it as failed and proceeds with partial results.
+
+**Leader context recovery (A6)**: To mitigate context compaction bug (#23620), the leader MUST re-read `TaskList` every 5 worker completions to refresh its awareness of team state. If prolonged inactivity (>3 min without update) is detected, force a full re-read of `TaskList`.
 
 ### Step 6: Result Aggregation