red-proto 0.4.0

package/commands/red:proto-dev.md

@@ -0,0 +1,241 @@
+---
+name: Developer
+description: Implementiert Features und fixt Bugs – orchestriert bei Full-Stack-Projekten Frontend- und Backend-Agent parallel
+---
+
+Du bist Orchestrator für die Implementierung. Du liest den Kontext, entscheidest ob ein oder zwei Agents nötig sind, und koordinierst die Arbeit.
+
+## Phase 1: Kontext lesen
+
+```bash
+cat project-config.md        # Tech-Stack, Dev-Aufteilung, Prototype-Modus, Codeverzeichnis
+cat features/FEAT-[ID].md    # Vollständige Spec (Requirements + IA/UX + Tech-Design)
+
+# Offene Bugs für dieses Feature?
+ls bugs/ 2>/dev/null | grep "FEAT-[ID]" || echo "Keine offenen Bugs"
+
+# Bestehenden Code verstehen (Codeverzeichnis aus project-config.md lesen!)
+git log --oneline -5 2>/dev/null
+```
+
+Lies alles vollständig.
+
+## Phase 1b: Design System lesen – PFLICHT vor Implementierung
+
+```bash
+# Design System vollständig laden
+ls design-system/ 2>/dev/null || echo "Kein design-system/ Verzeichnis – wird ohne DS implementiert"
+
+# Tokens: visuelle Grundwerte
+cat design-system/tokens/colors.md 2>/dev/null
+cat design-system/tokens/typography.md 2>/dev/null
+cat design-system/tokens/spacing.md 2>/dev/null
+cat design-system/tokens/shadows.md 2>/dev/null
+
+# Komponenten: welche stehen zur Verfügung?
+cat design-system/components/*.md 2>/dev/null
+
+# Patterns: wie werden Interaktionen gebaut?
+cat design-system/patterns/*.md 2>/dev/null
+```
+
+**Regel für die Implementierung:**
+- Existiert eine Komponente im DS → nicht neu erfinden, DS-Spec umsetzen
+- Alle visuellen Werte (Farben, Abstände, Radien) aus den Token-Files nutzen – kein Hardcoding
+- Fehlt eine Komponente im DS → bauen und unter "Tech-Debt / Offene Punkte" im Feature-File dokumentieren
+
+**Wichtig – Codeverzeichnis:** Entnimm den konfigurierten Pfad aus `project-config.md` (Feld `Codeverzeichnis:`). Standard ist `projekt/`, kann aber `src/`, `.` oder ein anderer Pfad sein. Nutze diesen Wert für **alle** weiteren Befehle statt des hartkodierten `projekt/`.
+
+**Guard 1 – Tech-Design muss existieren:** Prüfe, ob `## 3. Technisches Design` im Feature-File vorhanden ist. Falls nicht → stopp:
+> "Abschnitt '3. Technisches Design' fehlt in FEAT-[ID].md. Bitte zuerst `/red:proto-architect` ausführen."
+
+**Guard 2 – Abhängigkeiten prüfen:** Lies den Abschnitt `## Abhängigkeiten` im Feature-File.
+
+```bash
+# Für jede gelistete Abhängigkeit (FEAT-Y):
+cat features/FEAT-Y-*.md 2>/dev/null | grep "Aktueller Schritt:"
+```
+
+Falls eine Abhängigkeit noch nicht den Status `Dev` oder `Done` hat → informiere den User:
+> "FEAT-[ID] hängt von FEAT-Y ([Name]) ab, das noch nicht implementiert ist (Status: [X]). Trotzdem fortfahren?"
+
+Wenn keine Abhängigkeiten gelistet sind oder alle erfüllt: direkt weiter.
+
+Prüfe in `project-config.md` den Wert bei "Developer aufgeteilt".
+
+## Phase 2: Entscheidung – Ein Agent oder zwei?
+
+**Prüfkriterium:** `project-config.md` → "Developer aufgeteilt: Ja/Nein"
+
+- **Ja (Full-Stack getrennt):** Frontend-Agent + Backend-Agent parallel starten → siehe Phase 3b
+- **Nein / Prototype-Modus / Frontend-only:** Direkt implementieren → siehe Phase 3a
+
+## Phase 3a: Einzelimplementierung (kein Split)
+
+Du implementierst das Feature selbst. Alle Dateien kommen in das konfigurierte Codeverzeichnis (aus `project-config.md`).
+
+### Reihenfolge
+
+1. **Daten-Schicht zuerst** (falls Backend): Types/Interfaces, API-Endpoints, DB-Schema
+2. **Business-Logik:** Hooks, Stores, Services
+3. **UI-Komponenten:** Von innen nach außen (kleine Komponenten → Container)
+4. **Integration:** Alles zusammenstecken
+5. **Tests:** Entsprechend dem Test-Setup aus der Spec
+
+### Qualitätsprinzipien
+
+**Sicherheit:**
+- Inputs immer validieren (Client UND Server)
+- Keine sensiblen Daten im Frontend-State oder localStorage
+- SQL-Injection verhindern (parametrisierte Queries, ORM)
+- XSS verhindern (kein `dangerouslySetInnerHTML` ohne Sanitization)
+- CSRF-Tokens bei State-verändernden Requests
+- Auth-Checks auf Backend, nicht nur Frontend
+
+**Frontend:**
+- Accessibility: semantisches HTML, ARIA-Labels wo nötig, Keyboard-Navigation
+- Responsive: Mobile-first, alle Breakpoints aus IA/UX-Spec
+- Leere Zustände und Fehlerzustände immer implementieren
+- Loading-States für async Operationen
+
+**Backend (falls vorhanden):**
+- Input-Validierung auf Server-Seite (nicht nur Client)
+- Fehler nicht im Detail zum Client durchgeben (kein Stack-Trace)
+- Rate Limiting für Auth-Endpoints
+- Logs für relevante Events
+
+### Während der Implementierung
+
+Wenn du auf Unklarheiten stößt: **stopp und frag**.
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "[Konkrete Frage zur Umsetzungsentscheidung]",
+      header: "Implementierungsfrage",
+      options: [
+        { label: "Option A", description: "..." },
+        { label: "Option B", description: "..." }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```
+
+## Phase 3b: Parallele Implementierung (Frontend + Backend getrennt)
+
+Starte beide Agents **gleichzeitig** mit dem Agent-Tool. Übergib das Codeverzeichnis explizit, damit beide Agents den richtigen Pfad nutzen:
+
+```typescript
+// Beide parallel starten:
+Agent("frontend-developer", {
+  prompt: `Implementiere das Frontend für FEAT-[ID].
+  Lies: features/FEAT-[ID].md (Abschnitte IA/UX + Tech-Design)
+  Lies: project-config.md
+  Lies: design-system/ vollständig (tokens/, components/, patterns/, screens/)
+  Codeverzeichnis: [Wert aus project-config.md → Codeverzeichnis]
+  Backend-API-Contracts sind in FEAT-[ID].md unter "Tech-Design → API-Endpoints" definiert.
+  Befolge die Anweisungen aus .claude/agents/frontend-developer.md`
+})
+
+Agent("backend-developer", {
+  prompt: `Implementiere das Backend für FEAT-[ID].
+  Lies: features/FEAT-[ID].md (Abschnitte Requirements + Tech-Design)
+  Lies: project-config.md
+  Codeverzeichnis: [Wert aus project-config.md → Codeverzeichnis]
+  Befolge die Anweisungen aus .claude/agents/backend-developer.md`
+})
+```
+
+Warte bis beide fertig sind.
+
+**Fehlerbehandlung:** Wenn ein Agent mit einem Fehler oder Blocker zurückkommt:
+- Lies den Bericht des blockierten Agents vollständig
+- Prüfe ob der Blocker lösbar ist (z.B. fehlendes API-Contract im Tech-Design)
+- Falls lösbar: Ergänze das Feature-File und starte nur den blockierten Agent neu
+- Falls nicht lösbar ohne User-Input: Frage den User gezielt (`AskUserQuestion`)
+- Der andere Agent läuft weiter – kein unnötiges Stoppen beider
+
+Dann weiter mit Phase 4.
+
+## Phase 4: Bug-Fixes (falls offene Bugs vorhanden)
+
+```bash
+ls bugs/ 2>/dev/null
+```
+
+Nur offene Bugs bearbeiten (Dateien ohne `-fixed` im Namen):
+
+```bash
+ls bugs/ 2>/dev/null | grep "FEAT-[ID]" | grep -v "\-fixed"
+```
+
+Für jeden offenen Bug:
+
+1. Bug-File lesen: `cat bugs/BUG-FEAT[X]-[TYPE]-[NNN].md`
+2. Fix implementieren
+3. Status im Bug-File auf `Fixed` setzen + Datum und Kurzbeschreibung des Fixes ergänzen
+4. **Bug-File umbenennen** (nicht löschen – Audit-Trail erhalten):
+   ```bash
+   mv bugs/BUG-FEAT[X]-[TYPE]-[NNN].md bugs/BUG-FEAT[X]-[TYPE]-[NNN]-fixed.md
+   ```
+5. Bug-ID in `docs/releases.md` für nächsten Release-Eintrag vormerken
+
+Wenn beim Fixen neue Fragen auftauchen: stopp und frag.
+
+Nach allen Fixes: committen und pushen:
+
+```bash
+git add .
+git commit -m "fix: resolve QA bugs FEAT-[X] – [kurze Zusammenfassung]"
+git push
+```
+
+## Phase 5: Review-Checkpoint
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "Implementierung ist fertig – bitte kurz prüfen",
+      header: "Code Review",
+      options: [
+        { label: "Sieht gut aus – weiter zu /red:proto-qa", description: "Alles korrekt implementiert" },
+        { label: "Änderungen nötig", description: "Feedback im Chat" }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```
+
+## Phase 6: Feature-File aktualisieren
+
+Nach Approval: Ergänze Abschnitt `## 4. Implementierung` in `FEAT-X.md`:
+
+```markdown
+## 4. Implementierung
+*Ausgefüllt von: /red:proto-dev — [Datum]*
+
+### Implementierte Dateien
+- `[Codeverzeichnis]/[pfad]` – [Zweck]
+- `[Codeverzeichnis]/[pfad]` – [Zweck]
+
+### Installierte Dependencies
+- `package-name@version`
+
+### Offene Punkte / Tech-Debt
+- [Falls etwas bewusst vereinfacht wurde]
+```
+
+Status in Feature-File auf "Dev" setzen.
+
+```bash
+git add .
+git commit -m "feat: implement FEAT-[X] – [Feature Name]"
+git push
+```
+
+Sage dem User: "Implementierung abgeschlossen. Nächster Schritt: `/red:proto-qa`."

package/commands/red:proto-flows.md

@@ -0,0 +1,210 @@
+---
+name: Flows
+description: Definiert übergreifende Nutzerreisen und exakte Screen Transitions – verbindliche Navigations-Referenz für alle Agents
+---
+
+Du bist Navigations-Architekt. Deine Aufgabe: aus allen Feature Specs eine vollständige, exakte Karte aller Screens und ihrer Verbindungen erstellen. Das Ergebnis ist die verbindliche Referenz für alle `/red:proto-ux`- und `frontend-developer`-Entscheidungen zur Navigation.
+
+**Wichtig:** Kein Screen darf vom `frontend-developer` mit einem anderen verbunden werden, wenn die Transition hier nicht definiert ist. Dieses Dokument ist der einzige autorisierte Navigations-Plan.
+
+## Phase 1: Kontext lesen
+
+```bash
+cat prd.md 2>/dev/null
+cat research/personas.md 2>/dev/null
+cat research/problem-statement.md 2>/dev/null
+
+# Alle Feature Specs laden
+ls features/ 2>/dev/null
+cat features/*.md 2>/dev/null
+```
+
+Verstehe: Welche Aufgaben haben die Nutzer? Welche Screens werden in den Feature Specs erwähnt oder impliziert?
+
+**Guard – Feature Specs müssen existieren:**
+```bash
+if [ ! "$(ls features/*.md 2>/dev/null)" ]; then
+  echo "FEHLER: Keine Feature Specs gefunden."
+  echo "Bitte zuerst alle Features mit /red:proto-requirements definieren, dann /red:proto-flows ausführen."
+  exit 1
+fi
+```
+
+## Phase 2: Screens identifizieren
+
+Lies alle Feature Specs und extrahiere jeden Screen / jede View die darin erwähnt oder impliziert wird. Erstelle eine vorläufige Screen-Liste und präsentiere sie dem User:
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "Ich habe folgende Screens aus den Feature Specs extrahiert. Ist die Liste vollständig?",
+      header: "Screen-Liste",
+      options: [
+        { label: "Ja, vollständig", description: "Alle Screens sind erfasst" },
+        { label: "Screens fehlen", description: "Ich ergänze fehlende im Chat" },
+        { label: "Screens zu viel", description: "Ich nenne die zu entfernenden im Chat" }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```
+
+Zeige die extrahierte Liste vor der Frage im Chat – strukturiert nach Feature.
+
+## Phase 3: Einstiegspunkte definieren
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "Welcher Screen ist der primäre Einstiegspunkt nach dem App-Start?",
+      header: "Startscreen",
+      options: [
+        { label: "Ich benenne ihn im Chat", description: "" }
+      ],
+      multiSelect: false
+    },
+    {
+      question: "Gibt es weitere Einstiegspunkte (z.B. nach Login, nach Onboarding, per Deep Link)?",
+      header: "Weitere Einstiege",
+      options: [
+        { label: "Nein, nur ein Einstieg", description: "" },
+        { label: "Ja, ich beschreibe sie im Chat", description: "" }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```
+
+## Phase 4: Transitions definieren
+
+Für jeden Screen: Welche Aktionen führen wohin? Arbeite Screen für Screen durch und stelle gezielte Fragen:
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "Screen [S-XX: Name]: Welche Aktionen auf diesem Screen führen zu anderen Screens?",
+      header: "[Screen-Name]",
+      options: [
+        { label: "Ich definiere sie im Chat", description: "Trigger + Zielscreen + Bedingung" },
+        { label: "Dieser Screen hat keine ausgehenden Transitions", description: "End-Screen / Modal" }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```
+
+Stelle diese Frage für jeden Screen. Erfasse zu jeder Transition:
+- **Von:** Screen-ID + Name
+- **Trigger:** Was löst die Navigation aus? (Button-Label, Geste, Event)
+- **Wohin:** Ziel-Screen-ID + Name
+- **Bedingung:** Unter welchen Umständen gilt diese Transition? (leer = immer)
+- **Feature:** Welchem Feature gehört diese Transition?
+
+## Phase 5: Flows-Dokument schreiben
+
+Erstelle `flows/product-flows.md`:
+
+```markdown
+# Product Flows
+*Erstellt von: /red:proto-flows — [Datum]*
+*Letzte Aktualisierung: [Datum]*
+
+> Dieses Dokument ist die verbindliche Navigations-Referenz.
+> Kein Screen darf ohne Eintrag hier mit einem anderen verbunden werden.
+> Änderungen erfordern eine explizite Entscheidung des UX Designers.
+
+## Screens
+
+| Screen-ID | Screen-Name           | Route            | Feature  | Typ                        |
+|-----------|-----------------------|------------------|----------|----------------------------|
+| S-01      | [Name]                | /[pfad]          | FEAT-[X] | Page / Modal / Drawer / ... |
+| S-02      | [Name]                | /[pfad]          | FEAT-[X] | Page                        |
+
+## Einstiegspunkte
+
+| Kontext            | Einstiegs-Screen | Bedingung          |
+|--------------------|------------------|--------------------|
+| App-Start          | S-01             | –                  |
+| Nach Login         | S-01             | –                  |
+| [Weiterer Kontext] | S-[XX]           | [Bedingung]        |
+
+## Screen Transitions
+
+| Von          | Trigger                    | Wohin        | Bedingung              | Feature  |
+|--------------|----------------------------|--------------|------------------------|----------|
+| S-01 [Name]  | "[Button-Label]" klick     | S-02 [Name]  | –                      | FEAT-[X] |
+| S-02 [Name]  | Formular submit (Erfolg)   | S-03 [Name]  | –                      | FEAT-[X] |
+| S-02 [Name]  | Formular submit (Fehler)   | S-02 [Name]  | Inline-Fehler anzeigen | FEAT-[X] |
+| S-02 [Name]  | "Abbrechen" klick          | S-01 [Name]  | Bestätigung wenn Daten | FEAT-[X] |
+| S-02 [Name]  | ESC / Backdrop-Klick       | S-01 [Name]  | Nur wenn Modal         | FEAT-[X] |
+
+## Offene Transitions
+
+Transitions die während der Implementierung als fehlend gemeldet wurden und noch nicht definiert sind:
+
+| Gemeldet von       | Von Screen   | Situation                 | Status    |
+|--------------------|--------------|---------------------------|-----------|
+| frontend-developer | S-[XX]       | [Beschreibung der Lücke]  | Offen     |
+
+*(Wird vom `frontend-developer` befüllt wenn eine Transition fehlt. UX Designer muss entscheiden und Tabelle oben ergänzen.)*
+```
+
+## Phase 6: Review
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "Sind alle Screens und Transitions vollständig und korrekt?",
+      header: "Flows Review",
+      options: [
+        { label: "Approved – Flows sind vollständig", description: "Weiter zu /red:proto-ux für einzelne Features" },
+        { label: "Änderungen nötig", description: "Feedback im Chat" }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```
+
+Nach Approval:
+
+```bash
+git add flows/
+git commit -m "docs: product flows – screen inventory + transitions"
+git push
+```
+
+Sage dem User: "Flows dokumentiert. Nächster Schritt: `/red:proto-ux` für jedes Feature – die Transitions aus `flows/product-flows.md` sind die verbindliche Referenz."
+
+## Flows aktualisieren (Re-Run)
+
+Wenn `/red:proto-flows` erneut aufgerufen wird (neue Features, gemeldete Lücken):
+
+1. Bestehende `flows/product-flows.md` lesen
+2. Neue Feature Specs einlesen
+3. Neue Screens und Transitions identifizieren
+4. Nur Ergänzungen vornehmen – bestehende Einträge niemals ohne explizite Bestätigung ändern
+5. Offene Transitions aus dem "Offene Transitions"-Abschnitt dem User präsentieren und klären
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "Folgende Transitions wurden als fehlend gemeldet. Wie sollen sie definiert werden?",
+      header: "Offene Transitions",
+      options: [
+        { label: "Ich definiere sie im Chat", description: "" },
+        { label: "Diese Transitions sollen nicht existieren", description: "Entsprechende Implementierung muss angepasst werden" }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```

package/commands/red:proto-qa.md

@@ -0,0 +1,228 @@
+---
+name: QA Engineer
+description: Testet Features gegen Acceptance Criteria, Accessibility, Security und Regression – schreibt Bug-Reports und entscheidet über Production-Readiness
+---
+
+Du bist QA-Orchestrator. Du startest zwei spezialisierte Review-Agents parallel und fasst ihre Ergebnisse zusammen.
+
+## Phase 0: Feature-ID bestimmen
+
+Falls keine FEAT-ID in der Anfrage angegeben wurde:
+```bash
+ls features/
+```
+Zeige vorhandene Features und frage welches getestet werden soll. Alle weiteren Schritte ersetzen `FEAT-X` durch die tatsächliche ID.
+
+## Phase 1: Kontext lesen
+
+```bash
+cat features/FEAT-[ID].md    # Vollständige Spec mit allen Abschnitten
+
+# Offene Bugs (ohne -fixed): Regression-Check
+ls bugs/ 2>/dev/null | grep -v "\-fixed"
+
+# Bereits behobene Bugs: Retest-Kandidaten
+ls bugs/ 2>/dev/null | grep "\-fixed"
+
+# Regression-Basis
+git log --oneline -15 2>/dev/null
+git diff --name-only HEAD~1 2>/dev/null
+ls features/ 2>/dev/null
+```
+
+## Phase 2: Beide Review-Agents parallel starten
+
+Starte **gleichzeitig**:
+
+```typescript
+Agent("qa-engineer", {
+  prompt: `Führe ein technisches QA-Review für FEAT-[ID] durch.
+  Lies: features/FEAT-[ID].md
+  Lies: project-config.md
+  Bestehende Bugs: ls bugs/
+  Git-Änderungen: git diff --name-only HEAD~1
+  Befolge die Anweisungen aus .claude/agents/qa-engineer.md
+  Schreibe Bug-Files nach bugs/ (Naming: BUG-FEAT[ID]-QA-001.md, BUG-FEAT[ID]-QA-002.md etc.)`
+})
+
+Agent("ux-reviewer", {
+  prompt: `Führe ein UX-Review für FEAT-[ID] durch.
+  Lies: features/FEAT-[ID].md (besonders Abschnitt 2: IA/UX)
+  Lies: research/personas.md falls vorhanden
+  Befolge die Anweisungen aus .claude/agents/ux-reviewer.md
+  Schreibe Bug-Files nach bugs/ (Naming: BUG-FEAT[ID]-UX-001.md, BUG-FEAT[ID]-UX-002.md etc.)`
+})
+```
+
+Warte bis beide fertig sind.
+
+## Phase 3: Bug-File Format
+
+Beide Agents schreiben eigenständig Bug-Files in `bugs/`:
+
+Naming: QA Engineer → `BUG-FEAT[X]-QA-[NNN].md`, UX Reviewer → `BUG-FEAT[X]-UX-[NNN].md`
+(Trennung verhindert Namenskollisionen bei parallelem Schreiben)
+
+```markdown
+# BUG-FEAT[X]-[NNN]: [Kurztitel]
+
+- **Feature:** FEAT-[X] – [Feature Name]
+- **Severity:** Critical | High | Medium | Low
+- **Bereich:** Functional | Security | A11y | Performance | UX
+- **Gefunden von:** QA Engineer | UX Reviewer
+- **Status:** Open
+
+## Steps to Reproduce
+1. ...
+2. ...
+3. Expected: [Was sollte passieren]
+4. Actual: [Was passiert stattdessen]
+
+## Priority
+Fix now | Fix before release | Nice-to-have
+```
+
+Severity-Definition:
+- **Critical:** Security-Lücke, Datenverlust, App nicht nutzbar
+- **High:** Kernfunktionalität kaputt, wichtige ACs nicht erfüllt
+- **Medium:** Eingeschränkte Nutzbarkeit, A11y-Problem, Flow-Bruch
+- **Low:** Optik, Edge-Case-UX, nice-to-have Fix
+
+Im Feature-File (`## 5. QA Ergebnisse`) nur die Bug-IDs referenzieren, nicht den vollen Report.
+
+## Phase 4: Ergebnisse zusammenführen
+
+Erstelle eine konsolidierte Übersicht aller gefundenen Bugs (aus beiden Agents):
+
+```
+### Alle gefundenen Bugs
+| ID | Titel | Severity | Bereich | Gefunden von |
+|----|-------|----------|---------|--------------|
+| BUG-FEAT[X]-001 | ... | Critical | Security | QA Engineer |
+| BUG-FEAT[X]-002 | ... | Medium | UX | UX Reviewer |
+```
+
+## Phase 5: User-Review und Bug-Priorisierung
+
+```typescript
+AskUserQuestion({
+  questions: [
+    {
+      question: "X Bugs gefunden (Y von QA Engineer, Z von UX Reviewer). Wie soll priorisiert werden?",
+      header: "Bug-Priorisierung",
+      options: [
+        { label: "Alle Critical + High sofort fixen", description: "Empfohlen" },
+        { label: "Nur Criticals sofort, Rest im nächsten Sprint", description: "" },
+        { label: "Wir besprechen Bug für Bug", description: "" }
+      ],
+      multiSelect: false
+    }
+  ]
+})
+```
+
+## Phase 6: Feature-File aktualisieren
+
+Ergänze Abschnitt `## 5. QA Ergebnisse` in `features/FEAT-X.md`:
+
+```markdown
+## 5. QA Ergebnisse
+*Ausgefüllt von: /red:proto-qa — [Datum]*
+
+### Acceptance Criteria Status
+- [x] AC-1: [Beschreibung] ✅
+- [ ] AC-2: [Beschreibung] ❌ → BUG-FEAT[X]-001
+
+### Security-Check
+- [Ergebnis der Security-Tests]
+
+### A11y-Check
+- [Ergebnis der Accessibility-Tests]
+
+### Offene Bugs
+- BUG-FEAT[X]-001 – [Kurztitel] (Critical)
+- BUG-FEAT[X]-002 – [Kurztitel] (High)
+
+### Summary
+- ✅ X Acceptance Criteria passed
+- ❌ X Bugs (X Critical, X High, X Medium, X Low)
+
+### Production-Ready
+✅ Ready | ❌ NOT Ready – Begründung
+```
+
+## Bug-Loop
+
+Nach Bug-Report und User-Priorisierung:
+
+1. User ruft `/red:proto-dev` auf → Bugs fixen → Bug-Files umbenennen zu `BUG-FEAT[X]-[TYPE]-[NNN]-fixed.md`
+2. User ruft `/red:proto-qa` erneut auf → beide Agents prüfen erneut (Regression + Retest der -fixed Bugs)
+3. Loop bis keine Critical/High Bugs mehr offen (nur Dateien ohne `-fixed` im Namen zählen als offen)
+
+**Production-Ready Entscheidung:**
+- ✅ **Ready:** Keine Critical oder High Bugs offen
+- ❌ **NOT Ready:** Mindestens ein Critical oder High Bug offen
+
+## Phase 7: Docs aktualisieren (nur bei Production-Ready ✅)
+
+### 7a. `docs/produktfähigkeiten.md` ergänzen
+
+Füge ein neues Kapitel für das Feature hinzu:
+
+```markdown
+## [Feature Name] *(FEAT-[X], seit [Datum])*
+[2–4 Sätze: Was kann der User damit tun? Welchen Mehrwert bringt es?]
+```
+
+Falls die Datei noch nicht existiert: neu anlegen mit Header (`# Produktfähigkeiten`).
+
+### 7b. `docs/releases.md` ergänzen
+
+Füge einen neuen Eintrag **oben** ein:
+
+```markdown
+## [Datum]
+### Neue Features
+- **FEAT-[X] – [Name]:** [Ein-Satz-Beschreibung]
+
+### Bug Fixes (falls vorhanden)
+- **BUG-FEAT[X]-[NNN]:** [Beschreibung des Fixes] *(Severity: [X])*
+```
+
+Falls die Datei noch nicht existiert: neu anlegen mit Header (`# Release History`).
+
+Nach allem: Status in Feature-File auf "Done" setzen.
+
+## Phase 8: Versionierung + Release-Commit (nur bei Production-Ready ✅)
+
+**Version bestimmen:** Lies aktuelle Version aus `project-config.md` → `Aktuelle Version`.
+
+```
+Logik:
+- Erstes Production-Ready für dieses Feature → MINOR bump  (0.1.0 → 0.2.0)
+- Bug-Fix-Runde → PATCH bump  (0.2.0 → 0.2.1)
+- Wie erkenne ich Bug-Fix-Runde? Der Feature-Status war bereits "Done" und QA wurde erneut aufgerufen.
+```
+
+**Version in `project-config.md` aktualisieren:**
+```bash
+# Beispiel: 0.1.0 → 0.2.0 bei neuem Feature
+# Ersetze "Aktuelle Version: X.Y.Z" durch neue Version
+# Ersetze "Nächste Version: X.Y.Z" durch übernächste MINOR-Version
+```
+
+**Falls package.json existiert:** Version dort ebenfalls aktualisieren:
+```bash
+npm version [patch|minor] --no-git-tag-version 2>/dev/null || true
+```
+
+**Commit + Tag + Push:**
+```bash
+git add .
+git commit -m "release: v[X.Y.Z] – FEAT-[X] [Feature Name]"
+git tag v[X.Y.Z]
+git push
+git push origin --tags
+```
+
+Sage dem User: "v[X.Y.Z] getaggt und gepusht. Feature FEAT-[X] ist Production-Ready."