red-proto 0.4.0 → 0.6.0

package/README.md

@@ -9,15 +9,21 @@ Ein KI-gestütztes Product Development Framework für [Claude Code](https://clau
 Eine Sammlung von Claude Code Commands und Agents, die eine vollständige Produktentwicklungs-Pipeline abbilden. Du arbeitest mit natürlicher Sprache – Claude führt die Pipeline aus, du triffst die Entscheidungen.
 
 ```
+/red:proto-workflow     → Nach jeder Pause: zeigt exakt wo du stehst und was als nächstes zu tun ist
+
 /red:proto-sparring     → Idee schärfen → PRD
 /red:proto-dev-setup    → Tech-Stack wählen, Projekt scaffolden, Git/GitHub einrichten
-/red:proto-research     → Problem Statement Map + Personas
-/red:proto-requirements → Feature Specs (User Stories, Acceptance Criteria, Edge Cases)
-/red:proto-flows        → Screen-Inventar + verbindliche Transition-Tabelle
-/red:proto-ux           → UX-Entscheidungen pro Feature – DS-konform, Transitions aus /flows
+/red:proto-research     → Problem Statement Map + Personas (optional)
+/red:proto-requirements → Feature Specs – einmal pro Feature, für ALLE Features
+                          ↓ wenn ALLE Features Specs haben:
+/red:proto-flows        → Screen-Inventar + verbindliche Transition-Tabelle (einmalig)
+/red:proto-ux           → UX-Entscheidungen – einmal pro Feature
+
+dann pro Feature (Build-Loop bis QA grün):
 /red:proto-architect    → Technisches Design + Security + Test-Setup
 /red:proto-dev          → Implementierung (Frontend + Backend, parallel falls nötig)
 /red:proto-qa           → Tests, Accessibility, Security, Bug-Loop bis Production-Ready
+                          └── Bugs? → /red:proto-dev → /red:proto-qa (wiederholen)
 ```
 
 Jeder Command ist eigenständig – du kannst an jedem Punkt einsteigen oder aufhören. Die Commands bauen aber aufeinander auf: jeder liest den Output des vorherigen und ergänzt die gemeinsamen Artefakte.
@@ -32,19 +38,25 @@ Jeder Command ist eigenständig – du kannst an jedem Punkt einsteigen oder auf
 
 ---
 
-## Installation
+## Installation – zwei Schritte, zwei verschiedene Dinge
+
+> **Wichtig:** Es gibt zwei Schritte, die unterschiedliche Zwecke haben. Beide sind nötig.
 
-### Option A – npx Installer (empfohlen)
+### Schritt 1 – `npx red-proto` installiert das Framework auf deinem Computer
 
-Einmalig ausführen. Der Installer fragt interaktiv ob global oder lokal:
+Macht die `/red:proto-*` Commands in Claude Code verfügbar. Einmalig pro Computer ausführen.
 
 ```bash
 npx red-proto@latest
 ```
 
-> **Update:** Einfach denselben Befehl erneut ausführen – der Installer erkennt bestehende Installationen und fragt was zu tun ist.
+Der Installer fragt interaktiv:
+- **Global** (`~/.claude/`) → Commands in allen Projekten verfügbar
+- **Lokal** (`./.claude/`) → nur im aktuellen Verzeichnis
 
-### Option B – Manuell via Git
+> **Update:** Denselben Befehl erneut ausführen – der Installer erkennt bestehende Installationen.
+
+**Option B – Manuell via Git (falls kein npx):**
 
 ```bash
 git clone https://github.com/eltuctuc/red-create-prototyp-project.git ~/.claude/templates/red-create-prototyp-project && \
@@ -53,9 +65,15 @@ cp ~/.claude/templates/red-create-prototyp-project/commands/red\:proto.md ~/.cla
 
 ---
 
-### Framework in ein Projekt einrichten
+### Schritt 2 – `/red:proto` richtet ein einzelnes Projekt ein
+
+> **Diesen Schritt musst du für jedes neue Projekt wiederholen.**
+
+`npx` installiert nur die Commands. `/red:proto` baut die Projektstruktur auf:
 
-Nach der Installation (Option A oder B) in Claude Code:
+- legt `research/`, `features/`, `flows/`, `bugs/`, `docs/` an
+- kopiert das neutrale Design System ins Projekt
+- erstellt `project-config.md` als Basis für alle Agents
 
 ```bash
 mkdir mein-projekt && cd mein-projekt
@@ -68,9 +86,7 @@ Dann in Claude Code:
 /red:proto
 ```
 
-Das kopiert alle Commands und Agents in `.claude/commands/` und `.claude/agents/` des Projekts, legt die Verzeichnisstruktur an und richtet das neutrale Design System ein.
-
-### Schritt 3 – Loslegen
+**Danach loslegen:**
 
 ```
 /red:proto-sparring
@@ -78,6 +94,17 @@ Das kopiert alle Commands und Agents in `.claude/commands/` und `.claude/agents/
 
 ---
 
+### Kurzübersicht: Was macht was?
+
+| Befehl | Wann | Was passiert |
+|--------|------|--------------|
+| `npx red-proto@latest` | Einmalig pro Computer | Installiert Commands in `~/.claude/` (global) oder `./.claude/` (lokal) |
+| `/red:proto` | Einmalig pro Projekt | Legt Projektstruktur an, kopiert Design System |
+| `/red:proto-sparring` | Start jedes Projekts | Erste Anlaufstelle – Idee zu PRD |
+| `/red:proto-workflow` | Nach jeder Session-Pause | Zeigt wo du stehst, was als nächstes kommt |
+
+---
+
 ## Was wird installiert?
 
 Nach dem Setup hat dein Projekt folgende Struktur:

package/agents/frontend-developer.md

@@ -9,7 +9,7 @@ Du bist erfahrener Frontend-Developer. Du baust die UI für ein definiertes Feat
 
 ```bash
 cat project-config.md        # Tech-Stack, Framework, Design-System, Codeverzeichnis
-cat features/FEAT-[ID].md    # Vollständige Spec – besonders Abschnitte 2 (IA/UX) und 3 (Tech-Design)
+cat features/FEAT-[ID].md    # Vollständige Spec – besonders Abschnitte 2 (UX) und 3 (Tech-Design)
 ```
 
 **Pfade bestimmen:** Lies aus `project-config.md`:
@@ -23,7 +23,7 @@ ls [Codeverzeichnis]/ 2>/dev/null    # Grundstruktur bestätigen
 ```
 
 Lies besonders:
-- Abschnitt 2 (IA/UX): User Flows, Komponentenstruktur, Interaktionsmuster
+- Abschnitt 2 (UX): User Flows, Komponentenstruktur, Interaktionsmuster
 - Abschnitt 3 (Tech-Design): Frontend-Komponenten, API-Contracts (wie rufst du das Backend auf?)
 
 ## Phase 1b: Design System lesen – PFLICHT vor jeder UI-Implementierung
@@ -61,7 +61,7 @@ ls design-system/screens/*/ 2>/dev/null
 cat flows/product-flows.md 2>/dev/null || echo "HINWEIS: Kein Flows-Dokument – nur Transitions aus Feature-File nutzen"
 ```
 
-Lies den Abschnitt **"Screen Transitions"** im Feature-File (`## 2. IA/UX Entscheidungen → Screen Transitions`).
+Lies den Abschnitt **"Screen Transitions"** im Feature-File (`## 2. UX Entscheidungen → Screen Transitions`).
 
 **Verbindliche Navigationsregeln:**
 - Jede Verbindung zwischen Screens muss in der Transition-Tabelle des Feature-Files oder in `flows/product-flows.md` definiert sein
@@ -69,6 +69,20 @@ Lies den Abschnitt **"Screen Transitions"** im Feature-File (`## 2. IA/UX Entsch
 - Wenn beim Implementieren eine fehlende Transition erkannt wird: **sofort stoppen**, in `flows/product-flows.md` unter "Offene Transitions" dokumentieren und im Abschlussbericht melden
 - Routing-Pfade (URLs/Routes) exakt so verwenden wie in den Screen Transitions definiert
 
+## Phase 1.5: UX-State-Inventory aufbauen
+
+Extrahiere aus Abschnitt 2 (UX) **alle** beschriebenen Zustände, Interaktionsmuster und Feedback-Anforderungen in eine interne Tabelle:
+
+| Komponente / Screen | Zustand | Erwartetes Verhalten | ✓ |
+|---------------------|---------|----------------------|---|
+| [Name] | Loading | ... | ☐ |
+| [Name] | Error | ... | ☐ |
+| [Name] | Empty/Idle | ... | ☐ |
+| [Name] | Success-Feedback | ... | ☐ |
+| [Name] | Hover/Focus | ... | ☐ |
+
+Diese Tabelle ist dein verbindliches AC-Set für Phase 3. Eine Komponente ist nicht fertig, solange nicht alle ihre Zustände abgehakt sind. Wer Zustände als "Qualitätsprinzip im Hinterkopf" trägt, implementiert sie teilweise – wer sie als Checkliste führt, implementiert sie vollständig.
+
 ## Phase 2: Bestehende Komponenten prüfen
 
 ```bash
@@ -118,7 +132,7 @@ Falls der Skill nicht verfügbar ist: Fahre mit den integrierten Qualitätsprinz
 
 **Responsive:**
 - Mobile-first (375px → 768px → 1440px)
-- Alle Breakpoints aus IA/UX-Spec umsetzen
+- Alle Breakpoints aus UX-Spec umsetzen
 
 **Zustände:**
 - Loading-State für jeden async Request
@@ -130,6 +144,13 @@ Falls der Skill nicht verfügbar ist: Fahre mit den integrierten Qualitätsprinz
 - User-Input vor Anzeige escapen (kein `innerHTML` mit unkontrollierten Daten)
 - API-Fehler abfangen, nie den vollen Stack-Trace anzeigen
 
+### Micro-Gate nach jeder Komponente (30-Sekunden-Check)
+
+Nach jeder fertiggestellten Komponente, bevor zur nächsten gegangen wird:
+- Hat sie alle Zustände aus dem State Inventory (Phase 1.5)?
+- Hat sie konsistente ARIA-Attribute verglichen mit gleichartigen Komponenten im Projekt?
+- Hat sie Hover/Focus-States wenn andere Komponenten dieser Art sie haben?
+
 ### Während der Implementierung
 
 Wenn ein API-Contract unklar ist oder im Tech-Design fehlt: **stopp und dokumentiere die Frage** im Feature-File unter "Offene Punkte".
@@ -166,6 +187,12 @@ Gib einen strukturierten Bericht zurück:
 ### Fehlende Transitions (in flows/product-flows.md gemeldet)
 - [Screen + Situation] oder "–"
 
+### Selbst-Review-Bestätigung
+- Zustands-Checkliste: [X/Y Punkte abgehakt – alle Komponenten vollständig]
+- A11y-Gate: [Bestanden / Ausnahmen mit Begründung]
+- Pattern-Konsistenz-Suche: [durchgeführt / Korrekturen vorgenommen: ...]
+- Reaktivitäts-Check: [durchgeführt für Stack: ...]
+
 ### Offene Punkte
 - [Falls etwas nicht implementierbar war ohne Backend-Info oder fehlende Specs]
 ```

package/agents/ux-reviewer.md

@@ -10,7 +10,7 @@ Du bist erfahrener UX Reviewer. Deine Sichtweise ist die des Nutzers: Ist das Fe
 ## Phase 1: Kontext lesen
 
 Lies vollständig:
-- `features/FEAT-X.md` – besonders Abschnitt 1 (Requirements/User Stories) und Abschnitt 2 (IA/UX)
+- `features/FEAT-X.md` – besonders Abschnitt 1 (Requirements/User Stories) und Abschnitt 2 (UX)
 - `research/personas.md` falls vorhanden – wer nutzt das Feature?
 - `research/problem-statement.md` falls vorhanden – welches Problem wird gelöst?
 
@@ -84,7 +84,7 @@ Gehe den dokumentierten User Flow (aus Abschnitt 2) Schritt für Schritt durch:
 
 ### 2f. Design System Compliance – PFLICHT
 
-Lies zuerst den Abschnitt **"DS-Status dieser Implementierung"** im Feature-File (`## 2. IA/UX Entscheidungen`). Dieser Abschnitt definiert welche Abweichungen genehmigt sind.
+Lies zuerst den Abschnitt **"DS-Status dieser Implementierung"** im Feature-File (`## 2. UX Entscheidungen`). Dieser Abschnitt definiert welche Abweichungen genehmigt sind.
 
 **Drei Kategorien – unterschiedliche Behandlung:**
 

package/commands/red:proto-architect.md

@@ -13,7 +13,7 @@ Falls keine FEAT-ID in der Anfrage: `ls features/` und nachfragen welches Featur
 
 ```bash
 cat project-config.md        # Tech-Stack, Dev-Setup, Codeverzeichnis
-cat features/FEAT-[ID].md    # Feature Spec + IA/UX-Entscheidungen
+cat features/FEAT-[ID].md    # Feature Spec + UX-Entscheidungen
 ```
 
 **Pfade bestimmen:** Lies aus `project-config.md`:
@@ -129,12 +129,14 @@ git commit -m "docs: FEAT-[X] tech design – [Feature Name]"
 git push
 ```
 
-Sage dem User: "Tech-Design dokumentiert. Nächster Schritt: `/red:proto-dev`."
+Sage dem User: "Tech-Design dokumentiert. Nächster Schritt: `/red:proto-dev`.
+
+Nach einer Pause: `/red:proto-workflow` zeigt dir exakt wo du stehst."
 
 ## Checklist vor Abschluss
 
 - [ ] Bestehende Architektur via Git geprüft
-- [ ] Feature Spec + IA/UX-Abschnitt vollständig gelesen
+- [ ] Feature Spec + UX-Abschnitt vollständig gelesen
 - [ ] Component-Struktur dokumentiert (kein Code)
 - [ ] Daten-Model beschrieben (kein SQL)
 - [ ] Security-Anforderungen explizit adressiert

package/commands/red:proto-dev-setup.md

@@ -529,7 +529,10 @@ Code:     [Codeverzeichnis]/
 Git:      Initialisiert ([Codeverzeichnis | Projekt-Root])
 GitHub:   [URL – oder: "Nur lokal"]
 
-Nächster Schritt: /red:proto-research – oder /red:proto-requirements wenn Research nicht nötig ist.
+Nächster Schritt: /red:proto-research (empfohlen)
+                  oder direkt /red:proto-requirements wenn Research nicht nötig ist.
+
+Nach einer Pause: /red:proto-workflow zeigt dir exakt wo du stehst.
 ```
 
 ## Checklist

package/commands/red:proto-dev.md

@@ -9,7 +9,7 @@ Du bist Orchestrator für die Implementierung. Du liest den Kontext, entscheides
 
 ```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)
+cat features/FEAT-[ID].md    # Vollständige Spec (Requirements + UX + Tech-Design)
 
 # Offene Bugs für dieses Feature?
 ls bugs/ 2>/dev/null | grep "FEAT-[ID]" || echo "Keine offenen Bugs"
@@ -46,6 +46,21 @@ cat design-system/patterns/*.md 2>/dev/null
 
 **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/`.
 
+## Phase 1.5: UX-Zustände als Implementierungs-Checkliste
+
+Lies Abschnitt `## 2. UX Entscheidungen` im Feature-File und extrahiere ALLE beschriebenen Zustände, Interaktionsmuster und Feedback-Anforderungen in eine interne Checkliste:
+
+| Komponente / Screen | Zustand | Erwartetes Verhalten | ✓ |
+|---------------------|---------|----------------------|---|
+| [Name] | Loading | ... | ☐ |
+| [Name] | Error | ... | ☐ |
+| [Name] | Empty/Idle | ... | ☐ |
+| [Name] | Success-Feedback | ... | ☐ |
+| [Name] | Hover/Focus | ... | ☐ |
+
+**Diese Liste ist dein verbindliches AC-Set – nicht Richtlinie, nicht Qualitätsprinzip.**
+Jede Zeile muss vor Phase 5 abgehakt sein. Wer A11y und States als "Frontend-Prinzipien" im Hinterkopf trägt, implementiert sie teilweise. Wer sie als Checkliste führt, implementiert sie vollständig.
+
 **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."
 
@@ -94,7 +109,7 @@ Du implementierst das Feature selbst. Alle Dateien kommen in das konfigurierte C
 
 **Frontend:**
 - Accessibility: semantisches HTML, ARIA-Labels wo nötig, Keyboard-Navigation
-- Responsive: Mobile-first, alle Breakpoints aus IA/UX-Spec
+- Responsive: Mobile-first, alle Breakpoints aus UX-Spec
 - Leere Zustände und Fehlerzustände immer implementieren
 - Loading-States für async Operationen
 
@@ -132,7 +147,7 @@ Starte beide Agents **gleichzeitig** mit dem Agent-Tool. Übergib das Codeverzei
 // 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: features/FEAT-[ID].md (Abschnitte UX + Tech-Design)
   Lies: project-config.md
   Lies: design-system/ vollständig (tokens/, components/, patterns/, screens/)
   Codeverzeichnis: [Wert aus project-config.md → Codeverzeichnis]
@@ -185,6 +200,16 @@ Für jeden offenen Bug:
 
 Wenn beim Fixen neue Fragen auftauchen: stopp und frag.
 
+**Ripple-Effekt-Check nach jedem Fix (PFLICHT):**
+
+Für jede geänderte Funktion, Hook oder Modul:
+```bash
+grep -r "[geänderter Funktionsname]" [Codeverzeichnis]/ --include="*.tsx" --include="*.vue" --include="*.ts" --include="*.svelte"
+```
+- Alle Importeure der geänderten Funktion identifiziert und geprüft?
+- Reaktive Abhängigkeiten die von geänderten Werten abhängen identifiziert?
+- Kein Fix der lokal korrekt ist, aber an anderer Stelle eine unbeabsichtigte Neuauslösung (Re-Trigger, Reconnect, Re-Fetch) erzeugt?
+
 Nach allen Fixes: committen und pushen:
 
 ```bash
@@ -193,6 +218,48 @@ git commit -m "fix: resolve QA bugs FEAT-[X] – [kurze Zusammenfassung]"
 git push
 ```
 
+## Phase 4.5: Entwickler-Selbstcheck – PFLICHT vor User-Review
+
+Dieser Check ersetzt nicht den QA-Agent – er schließt die Asymmetrie zwischen Implementierungs- und Prüftiefe. Kein Review-Checkpoint bevor alle Punkte abgehakt sind.
+
+### A – Zustands-Vollständigkeit (aus Phase 1.5 Checkliste)
+- [ ] Alle Loading-States implementiert?
+- [ ] Alle Error-States mit sinnvoller Fehlermeldung (kein "Something went wrong")?
+- [ ] Alle Empty/Idle-States implementiert?
+- [ ] Alle Success-Feedbacks nach User-Aktionen vorhanden?
+- [ ] Alle Interaktions-Zustände aus Abschnitt 2 (UX) abgedeckt?
+
+### B – A11y-Gate (blockierend – nicht überspringen)
+- [ ] Alle interaktiven Elemente ohne sichtbaren Text: aria-label gesetzt?
+- [ ] Alle Expand/Collapse-Pattern: aria-expanded korrekt, aria-controls nicht redundant mit hidden/display:none?
+- [ ] Alle Vollbild-Ersatzansichten (Error, Leer, Session abgelaufen): Heading-Hierarchie vollständig (kein fehlender h1)?
+- [ ] Hover-States: wenn eine Komponente Hover hat, haben alle gleichartigen Komponenten Hover?
+- [ ] Keyboard-Navigation: alle Aktionen per Tastatur erreichbar?
+
+### C – Pattern-Konsistenz-Suche
+Für jedes neu implementierte Pattern (Toggle, Error-Screen, Loading-State, ARIA-Attribut) einmal ausführen:
+```bash
+# Pattern an eigenen Code anpassen:
+grep -r "[charakteristisches Muster]" [Codeverzeichnis]/ --include="*.tsx" --include="*.vue" --include="*.ts" --include="*.svelte"
+```
+Prüfe: Haben alle Treffer dasselbe Pattern? Falls nicht – angleichen.
+
+### D – Reaktivitäts- und Side-Effect-Checks (stack-unabhängig)
+Lies den konfigurierten Stack aus `project-config.md` und wende diese universellen Prinzipien an – jedes moderne UI-Framework hat sie, die Syntax unterscheidet sich nur:
+
+- [ ] **Side Effects vollständig?** Jeder Side Effect (API-Call, Subscription, Timer, Event Listener) wird zum richtigen Zeitpunkt gestartet und bei Bedarf bereinigt.
+- [ ] **Reaktive Dependencies korrekt?** Das Reaktivitätssystem trackt alle Werte auf die der Effekt angewiesen ist – kein Unter-Tracking (stale values), kein Über-Tracking (unnötige Re-Runs).
+- [ ] **State-Update-Kaskaden geprüft?** Eine Zustandsänderung an Stelle A löst keine unbeabsichtigten Nebeneffekte an Stelle B aus.
+- [ ] **Timing-Reihenfolge deterministisch?** Mehrere State-Updates in Folge: keine Race Conditions?
+
+Wende diese Checks mit den Mustern und APIs an, die für den konfigurierten Stack gelten.
+
+### E – Bug-Fix Ripple (nur wenn Bugs gefixed wurden)
+Bereits abgedeckt in Phase 4 – Ripple-Effekt-Check. Hier bestätigen:
+- [ ] Ripple-Check für alle geänderten Module durchgeführt?
+
+---
+
 ## Phase 5: Review-Checkpoint
 
 ```typescript
@@ -238,4 +305,6 @@ git commit -m "feat: implement FEAT-[X] – [Feature Name]"
 git push
 ```
 
-Sage dem User: "Implementierung abgeschlossen. Nächster Schritt: `/red:proto-qa`."
+Sage dem User: "Implementierung abgeschlossen. Nächster Schritt: `/red:proto-qa`.
+
+Nach einer Pause: `/red:proto-workflow` zeigt dir exakt wo du stehst."

package/commands/red:proto-flows.md

@@ -21,13 +21,23 @@ 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:**
+**Guard – Feature Specs müssen existieren und vollständig sein:**
 ```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
+
+# Prüfe ob noch Features ohne Spec-Status vorhanden sind
+MISSING=$(grep -rL "Aktueller Schritt: Spec" features/*.md 2>/dev/null | grep -v "REJECTED\|ABANDONED")
+if [ -n "$MISSING" ]; then
+  echo "HINWEIS: Folgende Features haben noch keinen finalen Spec:"
+  echo "$MISSING"
+  echo ""
+  echo "Empfehlung: Zuerst alle Features mit /red:proto-requirements abschließen."
+  echo "Trotzdem fortfahren? (flows wird dann unvollständig sein)"
+fi
 ```
 
 ## Phase 2: Screens identifizieren
@@ -181,7 +191,9 @@ 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."
+Sage dem User: "Flows dokumentiert. Nächster Schritt: `/red:proto-ux` für jedes Feature (einmal pro Feature) – die Transitions aus `flows/product-flows.md` sind die verbindliche Referenz.
+
+Nach einer Pause: `/red:proto-workflow` zeigt dir exakt wo du stehst."
 
 ## Flows aktualisieren (Re-Run)
 

package/commands/red:proto-qa.md

@@ -47,7 +47,7 @@ Agent("qa-engineer", {
 
 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: features/FEAT-[ID].md (besonders Abschnitt 2: 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.)`
@@ -225,4 +225,7 @@ git push
 git push origin --tags
 ```
 
-Sage dem User: "v[X.Y.Z] getaggt und gepusht. Feature FEAT-[X] ist Production-Ready."
+Sage dem User: "v[X.Y.Z] getaggt und gepusht. Feature FEAT-[X] ist Production-Ready.
+
+Weiteres Feature? → `/red:proto-requirements` oder direkt in den Build-Loop für das nächste.
+Nach einer Pause: `/red:proto-workflow` zeigt dir exakt wo du stehst."

package/commands/red:proto-requirements.md

@@ -153,7 +153,7 @@ AskUserQuestion({
       question: "Ist die Feature Spec vollständig und korrekt?",
       header: "Review",
       options: [
-        { label: "Approved – weiter zu /red:proto-ux", description: "Spec ist ready" },
+        { label: "Approved – spec ist ready", description: "Nächstes Feature mit /red:proto-requirements oder alle Specs fertig → /red:proto-flows" },
         { label: "Änderungen nötig", description: "Feedback im Chat" }
       ],
       multiSelect: false
@@ -170,7 +170,27 @@ git commit -m "docs: FEAT-[X] spec – [Feature Name]"
 git push
 ```
 
-Sage dem User: "FEAT-X gespeichert. Nächster Schritt: `/red:proto-ux` für UI/UX-Entscheidungen."
+Prüfe wie viele Features noch den Status "Spec" brauchen:
+
+```bash
+ls features/ 2>/dev/null | grep "FEAT-"
+grep -l "Aktueller Schritt: Spec" features/*.md 2>/dev/null | wc -l
+```
+
+Sage dem User:
+
+```
+FEAT-[X] gespeichert.
+
+Weitere Features zu spezifizieren?
+→ /red:proto-requirements     für das nächste Feature
+
+Alle Features haben einen Spec?
+→ /red:proto-flows             Screen-Inventar + Transitions (einmalig, vor UX)
+  Danach: /red:proto-ux        pro Feature
+
+Nach einer Pause: /red:proto-workflow zeigt dir exakt wo du stehst.
+```
 
 ## Feature abbrechen
 

package/commands/red:proto-research.md

@@ -142,4 +142,6 @@ git commit -m "docs: add user research, personas and problem statement"
 git push
 ```
 
-Dann: "Research gespeichert. Nächster Schritt: `/red:proto-requirements` – ich empfehle, den Feature-Scope direkt mit dem PRD und den Research-Ergebnissen anzugehen."
+Dann: "Research gespeichert. Nächster Schritt: `/red:proto-requirements` – definiere alle Features (einen nach dem anderen). Erst wenn ALLE Features einen Spec haben, läuft `/red:proto-flows`.
+
+Nach einer Pause: `/red:proto-workflow` zeigt dir exakt wo du stehst."

package/commands/red:proto-sparring.md

@@ -111,7 +111,27 @@ else
 fi
 ```
 
-Sage dem User: "PRD gespeichert. Nächster Schritt: `/red:proto-dev-setup` – ich analysiere die Anforderungen und empfehle den passenden Tech-Stack."
+Sage dem User:
+
+```
+PRD gespeichert. Dein Weg von hier:
+
+  JETZT:
+  → /red:proto-dev-setup     Tech-Stack wählen, Projekt scaffolden, Git einrichten
+
+  DANACH (Reihenfolge wichtig):
+  → /red:proto-research      Personas + Problem Statement (optional, aber empfohlen)
+  → /red:proto-requirements  Feature Specs – einmal pro Feature, für ALLE Features
+                              ↓ wenn ALLE Features Specs haben:
+  → /red:proto-flows         Screen-Inventar + Transitions (einmalig, vor UX)
+  → /red:proto-ux            UX-Entscheidungen – einmal pro Feature
+
+  DANN PRO FEATURE (Build-Loop bis QA grün):
+  → /red:proto-architect → /red:proto-dev → /red:proto-qa
+     └── Bugs? → /red:proto-dev → /red:proto-qa (wiederholen)
+
+Nach einer Pause: /red:proto-workflow zeigt dir exakt wo du stehst.
+```
 
 ## Wichtig
 

package/commands/red:proto-ux.md

@@ -209,7 +209,7 @@ Falls nicht verfügbar: Weiter mit integrierten Qualitätsprinzipien.
 Ergänze das Feature-File `FEAT-[X].md`:
 
 ```markdown
-## 2. IA/UX Entscheidungen
+## 2. UX Entscheidungen
 *Ausgefüllt von: /red:proto-ux — [Datum]*
 
 ### Einbettung im Produkt
@@ -281,7 +281,7 @@ AskUserQuestion({
 })
 ```
 
-Nach Approval: Status in Feature-File auf "IA/UX" setzen.
+Nach Approval: Status in Feature-File auf "UX" setzen.
 
 ```bash
 git add features/FEAT-[X]-*.md flows/product-flows.md 2>/dev/null
@@ -289,4 +289,6 @@ git commit -m "docs: FEAT-[X] ux design + screen transitions – [Feature Name]"
 git push
 ```
 
-Sage dem User: "UX-Entscheidungen dokumentiert. Nächster Schritt: `/red:proto-architect` für das technische Design."
+Sage dem User: "UX-Entscheidungen dokumentiert. Nächster Schritt: `/red:proto-architect` für das technische Design.
+
+Nach einer Pause: `/red:proto-workflow` zeigt dir exakt wo du stehst."

package/commands/red:proto-workflow.md

@@ -1,82 +1,136 @@
 ---
 name: Workflow
-description: Zeigt den aktuellen Stand des Projekts und den nächsten Schritt im Product Development Framework
+description: Liest den echten Projektstatus und sagt dir exakt was als nächstes zu tun ist – starte hiermit nach jeder Pause
 ---
 
-Du bist der Workflow-Navigator für dieses Projekt. Deine Aufgabe: den aktuellen Stand prüfen und klar sagen, was als nächstes zu tun ist.
+Du bist der Workflow-Navigator. Deine einzige Aufgabe: den echten Stand lesen und dem User exakt sagen wo er steht und was als nächstes zu tun ist. Kein Raten, kein Schätzen – alles aus den Dateien.
 
-**Wichtig:** `/red:proto-workflow` ist der empfohlene Einstiegspunkt nach jeder Pause. Er liest den echten Dateistand – kein Kontext geht verloren, weil alle Entscheidungen in den Projekt-Dateien stehen.
+> **Nach jeder Session-Pause hier starten.** Dieser Command liest den vollständigen Projektstand aus den Dateien – kein Kontext geht verloren.
 
-## Was du tust
-
-**Schritt 1 – Prüfe den Projektstatus:**
+## Phase 1: Projektstand vollständig lesen
 
 ```bash
-# PRD vorhanden?
-cat prd.md 2>/dev/null || echo "FEHLT"
-
-# Projekt-Config vorhanden?
-cat project-config.md 2>/dev/null || echo "FEHLT"
+# Grundstruktur
+cat prd.md 2>/dev/null | head -5 || echo "FEHLT"
+cat project-config.md 2>/dev/null | grep -E "Projektname|Tech-Stack|Codeverzeichnis|Developer aufgeteilt" || echo "FEHLT"
 
-# Research vorhanden?
-ls research/ 2>/dev/null || echo "FEHLT"
+# Alle Features und ihr Status
+for f in features/*.md 2>/dev/null; do
+  echo "=== $f ==="
+  grep -E "^# |Aktueller Schritt:" "$f" 2>/dev/null
+done
 
-# Features vorhanden?
-ls features/ 2>/dev/null || echo "FEHLT"
+# Offene Bugs (nach Feature gruppiert)
+ls bugs/ 2>/dev/null | grep -v "\-fixed" || echo "Keine offenen Bugs"
 
-# Offene Bugs?
-ls bugs/ 2>/dev/null || echo "KEINE"
+# Flows vorhanden?
+cat flows/product-flows.md 2>/dev/null | head -3 || echo "FEHLT"
 
-# Releases?
-cat docs/releases.md 2>/dev/null || echo "FEHLT"
+# Letztes Release
+cat docs/releases.md 2>/dev/null | head -10 || echo "FEHLT"
 ```
 
-Lies die vorhandenen Dateien kurz, um den Inhalt zu verstehen – nicht nur ob sie existieren.
-
-**Schritt 2 – Erstelle eine Status-Übersicht:**
+## Phase 2: Status-Übersicht ausgeben
 
-Zeige dem User eine klare Zusammenfassung:
+Zeige eine präzise Übersicht – alles aus den echten Dateiinhalten:
 
 ```
-## Projektstatus
-
-### Pipeline
-[✅/⬜] 1. Sparring         → /red:proto-sparring
-[✅/⬜] 2. Dev Setup        → /red:proto-dev-setup
-[✅/⬜] 3. User Research    → /red:proto-research
-[✅/⬜] 4. Requirements     → /red:proto-requirements
-[✅/⬜] 5. Flows            → /red:proto-flows
-[✅/⬜] 6. UX Design        → /red:proto-ux
-[✅/⬜] 7. Solution Arch.   → /red:proto-architect
-[✅/⬜] 8. Developer        → /red:proto-dev
-[✅/⬜] 9. QA Engineer      → /red:proto-qa
-
-### Features im System
-- FEAT-1: [Name] – Status: [Schritt]
-- ...
-
-### Offene Bugs
-- BUG-FEAT[X]-[NNN]: [Kurztitel] (Severity) – oder: Keine offenen Bugs
-
-### Letztes Release
-- [Datum]: [Features / Bug Fixes] – oder: Noch kein Release
-
-### Nächster Schritt
-→ [Konkreter nächster Command + kurze Begründung]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  PROJEKTSTATUS: [Projektname aus prd.md]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+VORBEREITUNG
+  [✅/⬜] PRD               prd.md
+  [✅/⬜] Dev Setup          project-config.md
+  [✅/⬜] User Research      research/
+
+FEATURES
+  FEAT-1: [Name] ──── Status: [Spec|UX|Tech|Dev|QA|Done]
+  FEAT-2: [Name] ──── Status: [...]
+  ...
+
+OFFENE BUGS
+  [Liste oder: Keine offenen Bugs ✅]
+
+BUILD-LOOP STATUS
+  Flows definiert:   [✅ Ja / ⬜ Nein]
+  Features mit UX:   [X von Y]
+  Features im Loop:  [welche sind bei Architect/Dev/QA/Done]
+
+LETZTES RELEASE
+  [Version + Datum oder: Noch kein Release]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
-**Schritt 3 – Empfehle den nächsten Schritt:**
+## Phase 3: Nächsten Schritt exakt benennen
+
+Wende diese Entscheidungslogik an – in dieser Reihenfolge:
+
+**1. Noch kein PRD?**
+→ `Starte mit /red:proto-sparring`
+
+**2. PRD vorhanden, kein project-config.md?**
+→ `Führe /red:proto-dev-setup aus`
+
+**3. Dev-Setup vorhanden, offene Bugs aus früheren Features?**
+→ `Offene Bugs gefunden: [Liste]. Empfehlung: zuerst /red:proto-dev für FEAT-[X] um bekannte Regressions zu verhindern.`
+
+**4. Features fehlen oder nicht alle haben Status ≥ "Spec"?**
+→ `Definiere Features mit /red:proto-requirements`
+
+**5. Alle Features haben "Spec", aber kein Flows-Dokument?**
+→ `Alle Feature-Specs vorhanden – jetzt /red:proto-flows ausführen (einmalig, vor UX)`
+
+**6. Flows vorhanden, aber Features mit Status "Spec" (noch keine UX)?**
+→ `Führe /red:proto-ux für FEAT-[X] aus`
+
+**7. Features mit Status "UX", aber noch kein Tech-Design?**
+→ `Führe /red:proto-architect für FEAT-[X] aus`
 
-Basierend auf dem Status: Sag klar, was jetzt zu tun ist und welchen Command der User aufrufen soll. Wenn mehrere Features in verschiedenen Phasen sind: liste alle auf.
+**8. Features mit Status "Tech", aber noch keine Implementierung?**
+→ `Führe /red:proto-dev für FEAT-[X] aus`
 
-**Schritt 4 – Hilf bei Problemen:**
+**9. Features mit Status "Dev", aber noch kein QA?**
+→ `Führe /red:proto-qa für FEAT-[X] aus`
 
-Wenn der User fragt "was ist schiefgelaufen" oder "ich bin nicht sicher ob X korrekt ist": Lies die relevanten Dateien und gib eine ehrliche Einschätzung.
+**10. Features mit Status "QA" und offenen Bugs?**
+→ `FEAT-[X] hat [N] offene Bugs. Führe /red:proto-dev für FEAT-[X] aus, dann erneut /red:proto-qa`
 
-## Besondere Fälle
+**11. Alle Features "Done", keine offenen Bugs?**
+→ `Alle Features Production-Ready ✅. Nächste Schritte: neues Feature mit /red:proto-requirements oder Projekt abgeschlossen.`
 
-**Neues Projekt (noch gar nichts vorhanden):**
-Erkläre kurz den Framework-Workflow und sage: "Starte mit `/red:proto-sparring` – beschreib mir deine Idee."
+Gib immer **einen** konkreten nächsten Schritt – nicht mehrere gleichwertige Optionen. Wenn mehrere Features parallel in verschiedenen Phasen sind, priorisiere: offene Bugs zuerst, dann Build-Loop nach Feature-Nummer.
 
-**Fehler oder Inkonsistenz:**
-Wenn du siehst, dass ein Feature-File unvollständig ist oder ein Schritt übersprungen wurde, weise darauf hin – aber mach keine automatischen Korrekturen. Der User entscheidet.
+## Phase 4: Feature-Detail auf Wunsch
+
+Wenn der User nach einem spezifischen Feature fragt ("was ist offen in FEAT-2?"):
+
+```bash
+cat features/FEAT-[ID].md
+ls bugs/ 2>/dev/null | grep "FEAT-[ID]"
+```
+
+Zeige: Was wurde bereits entschieden, was fehlt noch, welche Bugs sind offen.
+
+## Sonderfall: Neues Projekt
+
+Wenn noch gar nichts vorhanden ist:
+
+```
+Noch kein Projekt gestartet.
+
+Die Pipeline im Überblick:
+  1. /red:proto-sparring      → Idee → PRD
+  2. /red:proto-dev-setup     → Tech-Stack + Scaffold + Git
+  3. /red:proto-research      → Personas (optional)
+  4. /red:proto-requirements  → Feature Specs (einmal pro Feature)
+                                ↓ wenn ALLE Features Specs haben:
+  5. /red:proto-flows         → Screen-Inventar + Transitions (einmalig)
+  6. /red:proto-ux            → UX-Entscheidungen (einmal pro Feature)
+
+  Dann pro Feature (Build-Loop):
+  7. /red:proto-architect → 8. /red:proto-dev → 9. /red:proto-qa
+     └── Bei Bugs: zurück zu /red:proto-dev → /red:proto-qa
+
+Starte mit: /red:proto-sparring
+```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "red-proto",
-  "version": "0.4.0",
+  "version": "0.6.0",
   "description": "AI-powered product development framework for Claude Code – from idea to tested prototype",
   "bin": {
     "red-proto": "./bin/install.js"