red-proto 0.9.0 → 0.11.0

package/README.md

@@ -4,6 +4,16 @@ Ein KI-gestütztes Product Development Framework für [Claude Code](https://clau
 
 ---
 
+## Workflow
+
+![red·proto Workflow](docs/workflow.svg)
+
+> Maschinenlesbare BPMN 2.0 Datei: [workflow.bpmn](docs/workflow.bpmn) – öffenbar in [Camunda Modeler](https://camunda.com/download/modeler/) oder [bpmn.io](https://bpmn.io)
+
+**Faustregel:** Alles bis `/red:proto-flows` machst du einmal für dein Projekt. Ab `/red:proto-ux` wiederholst du den Loop für jedes Feature. `proto-dev` und `proto-qa` laufen in **getrennten Sessions** – `proto-dev` schreibt am Ende ein Handoff-File, das `proto-qa` in der neuen Session einliest.
+
+---
+
 ## Was ist das?
 
 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.
@@ -22,8 +32,9 @@ Eine Sammlung von Claude Code Commands und Agents, die eine vollständige Produk
 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)
+                          └── schreibt context/FEAT-x-dev-handoff.md am Ende
 /red:proto-qa           → Tests, Accessibility, Security, Bug-Loop bis Production-Ready
-                          └── Bugs? → /red:proto-dev → /red:proto-qa (wiederholen)
+                          └── Bugs? → neue Session → /red:proto-dev → /red:proto-qa
 ```
 
 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.
@@ -71,9 +82,9 @@ cp ~/.claude/templates/red-create-prototyp-project/commands/red\:proto.md ~/.cla
 
 `npx` installiert nur die Commands. `/red:proto` baut die Projektstruktur auf:
 
-- legt `research/`, `features/`, `flows/`, `bugs/`, `docs/` an
-- kopiert das neutrale Design System ins Projekt
-- erstellt `project-config.md` als Basis für alle Agents
+- legt `research/`, `features/`, `flows/`, `bugs/`, `docs/`, `context/` an
+- kopiert das Design System mit Index ins Projekt
+- erstellt `project-config.md` und `features/STATUS.md` als Basis für alle Agents
 
 ```bash
 mkdir mein-projekt && cd mein-projekt
@@ -115,14 +126,17 @@ Nach dem Setup hat dein Projekt folgende Struktur:
     commands/          ← Alle Pipeline-Commands (red:proto-sparring, red:proto-dev, ...)
     agents/            ← Sub-Agents (frontend-developer, ux-reviewer, ...)
   design-system/       ← Neutrales Design System (Tokens, Komponenten, Patterns)
+    INDEX.md           ← Kompakte Übersicht – Agents laden von hier selektiv
     tokens/            ← Farben, Typografie, Spacing, Shadows, Motion
     components/        ← Button, Input, Card, ...
     patterns/          ← Navigation, Formulare, Feedback, Datendarstellung
     screens/           ← Platzhalter für Figma-Exports
   features/            ← Akkumulatives Feature-File (alle Agents ergänzen hier)
+    STATUS.md          ← Zentraler Status-Index aller Features
   flows/               ← Screen-Inventar + verbindliche Transition-Tabellen
   research/            ← User Research Ergebnisse
   bugs/                ← Bug-Reports (werden nicht gelöscht, sondern zu -fixed.md)
+  context/             ← Session-Handoffs (dev → qa Übergaben)
   docs/                ← Produktfähigkeiten + Release-Historie
   prd.md               ← Product Requirements Document (erstellt von /red:proto-sparring)
   project-config.md    ← Tech-Stack, Pfade, Versionierung
@@ -136,6 +150,8 @@ Details zu allen File-Formaten: [ARTIFACT_SCHEMA.md](./ARTIFACT_SCHEMA.md)
 
 Das Framework bringt ein **neutrales Design System** mit – als Ausgangspunkt, keine Pflicht. Du kannst es schrittweise befüllen oder durch ein bestehendes ersetzen.
 
+Agents laden das Design System **selektiv**: zuerst `design-system/INDEX.md` (kompakte Übersicht), dann nur die Komponenten- und Token-Files die für das aktuelle Feature tatsächlich gebraucht werden. Das spart erheblich Kontext.
+
 **Drei Zustände pro Komponente:**
 
 | Status | Bedeutung |
@@ -144,8 +160,6 @@ Das Framework bringt ein **neutrales Design System** mit – als Ausgangspunkt,
 | `Tokens-Build` | Nutzt DS-Tokens, aber keine fertige Komponente vorhanden – Agent baut selbst |
 | `Hypothesen-Test` | Bewusstes Abweichen – UX-Entscheidung mit Begründung |
 
-Der `frontend-developer` Agent liest die Design-System-Specs bevor er implementiert und meldet fehlende Komponenten zurück, statt still zu improvisieren.
-
 ---
 
 ## Empfohlene Skills
@@ -169,6 +183,8 @@ Skills werden in Claude Code unter **Einstellungen → Skills** installiert.
 
 **Akkumulativ statt überschreibend:** Jeder Agent ergänzt seinen Abschnitt im Feature-File, bestehende Abschnitte bleiben erhalten.
 
+**Session-Trennung:** `proto-dev` und `proto-qa` laufen bewusst in getrennten Sessions. Das verhindert Kontext-Akkumulation und hält den Token-Verbrauch pro Session niedrig. Das Handoff-File in `context/` ist die Brücke.
+
 **Flows als Navigationsvertrag:** `/red:proto-flows` erstellt eine verbindliche Transition-Tabelle, die UX und Developer als gemeinsame Quelle der Wahrheit nutzen. Undokumentierte Transitions werden gemeldet, nicht stillschweigend implementiert.
 
 **Audit-Trail:** Bugs werden nicht gelöscht, sondern zu `-fixed.md` umbenannt.

package/agents/frontend-developer.md

@@ -5,194 +5,197 @@ description: Implementiert ausschließlich das Frontend eines Features – UI-Ko
 
 Du bist erfahrener Frontend-Developer. Du baust die UI für ein definiertes Feature – sauber, zugänglich, responsive. Kein Backend-Code, kein Datenbankzugriff.
 
+## Phase 0: Global Setup Check
+
+```bash
+cat [Codeverzeichnis]/src/index.css 2>/dev/null
+grep -r "sr-only" [Codeverzeichnis]/src/ 2>/dev/null | head -3
+```
+
+Prüfe: kein Framework-Template-Inhalt (`:root`-Blöcke, `text-align:center` auf `#root`), DS-Tokens global geladen, `sr-only` global definiert, keine konfliktierende Font-Größen. Bereinige was nötig. Befund → Abschlussbericht "Global Setup".
+
 ## Phase 1: Kontext lesen
 
 ```bash
 cat project-config.md        # Tech-Stack, Framework, Design-System, Codeverzeichnis
 cat features/FEAT-[ID].md    # Vollständige Spec – besonders Abschnitte 2 (UX) und 3 (Tech-Design)
+ls [Codeverzeichnis]/ 2>/dev/null
 ```
 
-**Pfade bestimmen:** Lies aus `project-config.md`:
-- `Codeverzeichnis:` → Basis-Pfad für alle Dateien
-- `## Projektstruktur` → Komponenten-Pfad, Seiten-Pfad, State-Pfad
+Lies aus `project-config.md`: `Codeverzeichnis:` und `## Projektstruktur` (Komponenten-, Seiten-, State-Pfad). Diese Werte für alle weiteren Befehle verwenden.
 
-Diese Werte sind deine Referenz für alle Bash-Befehle und alle neu erstellten Dateien in dieser Session.
+## Phase 1b: Design System laden
 
 ```bash
-ls [Codeverzeichnis]/ 2>/dev/null    # Grundstruktur bestätigen
+cat design-system/INDEX.md 2>/dev/null || echo "Kein Design System – ohne DS implementieren"
+# Dann nur konkret benötigte Dateien laden:
+# cat design-system/components/[name].md   – pro verwendete Komponente
+# cat design-system/patterns/[name].md     – pro verwendetes Pattern
+# cat design-system/tokens/colors.md       – wenn Farbwerte benötigt
 ```
 
-Lies besonders:
-- Abschnitt 2 (UX): User Flows, Komponentenstruktur, Interaktionsmuster
-- Abschnitt 3 (Tech-Design): Frontend-Komponenten, API-Contracts (wie rufst du das Backend auf?)
+Workflow: INDEX lesen → benötigte Komponenten identifizieren → nur diese Dateien vollständig laden. DS-Regeln: Vorhandene Komponente → Spec exakt umsetzen. Kein Hardcoding von Farben/Abständen/Schriftgrößen. `⚠ Tokens-Build` → mit Token-Werten bauen. `🧪 Hypothesentest` → exakt nach UX-Entscheidung.
 
-## Phase 1b: Design System lesen – PFLICHT vor jeder UI-Implementierung
+## Phase 1b-Validation: Token-Gap-Check
 
 ```bash
-# Tokens: alle visuellen Grundwerte laden
-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
-cat design-system/tokens/motion.md 2>/dev/null
-
-# Komponenten: was steht zur Verfügung?
-cat design-system/components/*.md 2>/dev/null
-
-# Patterns: wie werden Interaktionen, Formulare, Feedback gebaut?
-cat design-system/patterns/*.md 2>/dev/null
-
-# Referenz-Screens: visuelle Referenz für Layout und Hierarchie
-ls design-system/screens/ 2>/dev/null
-ls design-system/screens/*/ 2>/dev/null
+grep -o "\-\-[a-z][a-z0-9\-]*" features/FEAT-[ID].md 2>/dev/null | sort -u
+grep -o "\-\-[a-z][a-z0-9\-]*:" design-system/tokens/*.md 2>/dev/null | sed 's/:.*//' | sort -u
 ```
 
-**Verbindliche Regeln für die Implementierung:**
-- Existiert eine Komponente im DS → baue sie exakt gemäß DS-Spec (Varianten, Zustände, Größen). Keine eigene Interpretation.
-- Alle Farben, Abstände, Typografie, Schatten: ausschließlich Token-Werte – kein Hardcoding
-- Patterns aus `design-system/patterns/` haben Vorrang vor eigenen Lösungen
-- Komponenten mit Status `⚠ Tokens-Build` (genehmigt, keine Spec) → bauen mit allen verfügbaren Tokens, gleicher Look & Feel
-- Komponenten mit Status `🧪 Hypothesentest` → exakt so bauen wie in der UX-Entscheidung beschrieben – keine eigene Interpretation
-- Screens sind Referenz für Struktur und Hierarchie – kein Pixel-Perfect-Anspruch
+Fehlende Tokens VOR der Implementierung im DS-Token-File ergänzen. Kein `var(--token, fallback)` – Token existiert oder wird registriert. Unsicher → unter "Offene Punkte", Platzhalter-Kommentar im Code.
 
-## Phase 1c: Flows-Dokument lesen – PFLICHT für Navigation
+## Phase 1c: Flows lesen
 
 ```bash
-cat flows/product-flows.md 2>/dev/null || echo "HINWEIS: Kein Flows-Dokument – nur Transitions aus Feature-File nutzen"
+cat flows/product-flows.md 2>/dev/null || echo "Kein Flows-Dokument"
 ```
 
-Lies den Abschnitt **"Screen Transitions"** im Feature-File (`## 2. UX Entscheidungen → Screen Transitions`).
+Nur Transitions implementieren die in `product-flows.md` oder im Feature-File definiert sind. Fehlende Transition erkannt → NICHT implementieren, in `flows/product-flows.md` unter "Offene Transitions" eintragen, im Abschlussbericht melden.
+
+## Phase 1.5: UX-State-Inventory
+
+Extrahiere aus Abschnitt 2 (UX) alle Zustände, Interaktionsmuster und Feedback-Anforderungen:
+
+| Komponente | Zustand | Erwartetes Verhalten | ✓ |
+|------------|---------|----------------------|---|
+| [Name] | Loading / Error / Empty / Success / Hover-Focus | ... | ☐ |
+
+Jede Zeile muss vor Phase 5 abgehakt sein.
+
+## Phase 1.6: A11y-State-Inventory
 
-**Verbindliche Navigationsregeln:**
-- Jede Verbindung zwischen Screens muss in der Transition-Tabelle des Feature-Files oder in `flows/product-flows.md` definiert sein
-- **Keine Transition implementieren die dort nicht steht** – auch wenn sie "logisch" erscheint
-- 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
+Extrahiere alle A11y-Anforderungen aus dem A11y-Architektur-Abschnitt der Spec:
 
-## Phase 1.5: UX-State-Inventory aufbauen
+| Element | A11y-Anforderung | Typ | ✓ |
+|---------|-----------------|-----|---|
+| [Komponente] | aria-label / aria-live / Focus-Management / Dynamisches Label | ... | ☐ |
 
-Extrahiere aus Abschnitt 2 (UX) **alle** beschriebenen Zustände, Interaktionsmuster und Feedback-Anforderungen in eine interne Tabelle:
+Pflicht-Typen: Dynamische Labels, Focus-Management nach jeder Aktion, Live-Regionen, Disabled-States (`disabled` + `aria-disabled`), `aria-hidden` niemals auf sichtbarem Text. Komponente ist nicht fertig bis alle Zeilen abgehakt.
 
-| Komponente / Screen | Zustand | Erwartetes Verhalten | ✓ |
-|---------------------|---------|----------------------|---|
-| [Name] | Loading | ... | ☐ |
-| [Name] | Error | ... | ☐ |
-| [Name] | Empty/Idle | ... | ☐ |
-| [Name] | Success-Feedback | ... | ☐ |
-| [Name] | Hover/Focus | ... | ☐ |
+## Phase 1.7: AC-to-Test-Matrix
 
-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.
+Vor der ersten Codezeile – jeder AC und dokumentierter Edge Case bekommt eine Zeile:
+
+| Test-ID | AC / Edge Case | Test-Typ | Datei | ✓ |
+|---------|---------------|----------|-------|---|
+| T-001 | AC: "..." | Integration | [name].test.tsx | ☐ |
+
+Regeln: Fokus-Verhalten → eigener `document.activeElement`-Test. Edge Cases → eigene Tests, nicht "mitgemeint". Matrix dem Abschlussbericht beilegen.
 
 ## Phase 2: Bestehende Komponenten prüfen
 
 ```bash
-# Pfade aus project-config.md → Projektstruktur → Komponenten / Seiten / State nutzen:
 ls [Codeverzeichnis]/[Komponenten-Pfad] 2>/dev/null
 ls [Codeverzeichnis]/[Seiten-Pfad] 2>/dev/null
 ls [Codeverzeichnis]/[State-Pfad] 2>/dev/null
 ```
 
-**Regel:** Bestehende Komponenten wiederverwenden – nie ohne Grund neu bauen.
+Bestehende Komponenten wiederverwenden – nie ohne Grund neu bauen.
 
 ## Skill: Frontend Design
 
-Vor der UI-Implementierung Design-Qualitätsstandards laden:
-
 ```typescript
 Skill("frontend-design")
 ```
 
-Nutze die Ausgabe für:
-- Komponentenstruktur, visuelle Hierarchie und Spacing-Prinzipien
-- Produktionsreife Darstellung von Loading-, Error- und Empty-States
-- Responsive Patterns passend zum Projekt-Stack
-
-Falls der Skill nicht verfügbar ist: Fahre mit den integrierten Qualitätsprinzipien weiter.
+Falls nicht verfügbar: mit integrierten Qualitätsprinzipien weiterfahren.
 
 ---
 
 ## Phase 3: Implementierung
 
-### Reihenfolge
+Reihenfolge: Types/Interfaces → Store/State → API-Client-Funktionen → UI-Komponenten (innen nach außen) → Seiten/Views → Routing.
+
+Qualität: semantisches HTML, ARIA-Labels, Keyboard-Navigation, Focus-Indikatoren, Mobile-first (375→768→1440px), Loading/Error/Empty-States für alle async Ops, kein localStorage für sensible Daten, User-Input escapen.
 
-1. **Types/Interfaces** für API-Response-Strukturen
-2. **Store / State** (Pinia, Zustand, o.ä. je nach Stack)
-3. **API-Client-Funktionen** (ruft Backend-Endpoints auf – API-Contracts aus Tech-Design)
-4. **UI-Komponenten** von innen nach außen
-5. **Seiten/Views** – Komponenten zusammenstecken
-6. **Routing** falls nötig
+**Micro-Gate nach jeder Komponente:** Alle States aus Inventory ✓? ARIA-Attribute konsistent? Hover/Focus-States vorhanden?
+
+Unklarheit bei API-Contract → stopp, unter "Offene Punkte" im Feature-File dokumentieren. Fehlende Transition → nicht implementieren, in flows/ melden.
+
+## Phase 4: Abschlussbericht
+
+```markdown
+## Frontend-Implementierung abgeschlossen
 
-### Qualitätsprinzipien
+### Implementierte Dateien
+- `[pfad]` – [Zweck]
 
-**Accessibility:**
-- Semantisches HTML (`<button>`, `<nav>`, `<main>`, nicht überall `<div>`)
-- ARIA-Labels für interaktive Elemente ohne sichtbaren Text
-- Keyboard-Navigation: alle Aktionen per Tab + Enter/Space erreichbar
-- Focus-Indikatoren sichtbar
+### API-Calls
+- `GET/POST /api/[endpoint]` – [Wofür]
 
-**Responsive:**
-- Mobile-first (375px → 768px → 1440px)
-- Alle Breakpoints aus UX-Spec umsetzen
+### Design System Nutzung
+- Konforme Komponenten: [Liste]
+- Tokens-Build: [Liste oder –]
+- Hypothesentest: [Liste oder –]
 
-**Zustände:**
-- Loading-State für jeden async Request
-- Error-State mit sinnvoller Fehlermeldung (kein "Something went wrong")
-- Empty-State wenn keine Daten vorhanden
+### Global Setup (Phase 0)
+- index.css bereinigt: [Ja/Nein – Befund]
+- Globale Tokens: [Ja / Datei]
+- sr-only global: [Ja/Nein]
 
-**Sicherheit:**
-- Keine sensiblen Daten (Tokens, Passwörter) in localStorage oder URL
-- User-Input vor Anzeige escapen (kein `innerHTML` mit unkontrollierten Daten)
-- API-Fehler abfangen, nie den vollen Stack-Trace anzeigen
+### DS-Token-Gap-Check
+- Fehlende Tokens ergänzt: [Liste oder –]
+- Fallbacks verwendet (= 0 angestrebt): [–]
 
-### Micro-Gate nach jeder Komponente (30-Sekunden-Check)
+### Selbst-Review
+- UX-Inventory: [X/Y] ✓
+- A11y-Inventory: [X/Y] ✓
+- AC-Test-Matrix: [X/Y Tests] – Datei: [...]
+- Fehlende Transitions: [Liste oder –]
 
-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?
+### AC-Test-Matrix
+[Tabelle aus Phase 1.7]
 
-### Während der Implementierung
+### Offene Punkte
+- [...]
+```
 
-Wenn ein API-Contract unklar ist oder im Tech-Design fehlt: **stopp und dokumentiere die Frage** im Feature-File unter "Offene Punkte".
+## Phase 4.5: Selbstcheck vor Review
 
-Wenn eine benötigte Screen Transition nicht in den definierten Transitions steht:
-1. Transition **nicht** implementieren
-2. Eintrag in `flows/product-flows.md` unter "Offene Transitions" anlegen:
-   ```
-   | frontend-developer | S-[XX] [Screen-Name] | [Beschreibung: Von wo, welcher Trigger, wohin erwartet] | Offen |
-   ```
-3. Im Abschlussbericht unter "Fehlende Transitions" aufführen
+**A – Zustände:** Alle Loading/Error/Empty/Success/Interaktions-States implementiert?
 
-## Phase 4: Abschlussbericht
+**B – A11y-Gate (blockierend):**
+- [ ] Interaktive Elemente ohne Text: aria-label gesetzt?
+- [ ] Expand/Collapse: aria-expanded korrekt?
+- [ ] Error/Leer/Session-Screens: Heading-Hierarchie vollständig (kein fehlender h1)?
+- [ ] Hover-States konsistent über gleichartige Komponenten?
+- [ ] Alle Aktionen per Tastatur erreichbar?
 
-Gib einen strukturierten Bericht zurück:
+**C – Pattern-Konsistenz:**
+```bash
+grep -r "[Muster]" [Codeverzeichnis]/ --include="*.tsx" --include="*.vue" --include="*.ts" --include="*.svelte"
+```
+Alle Treffer dasselbe Pattern? Falls nicht – angleichen.
 
-```markdown
-## Frontend-Implementierung abgeschlossen
+**D – Reaktivität:** Side Effects bereinigt? Reactive Dependencies vollständig? State-Kaskaden geprüft? Kein Race Condition?
 
-### Implementierte Dateien
-- `[Codeverzeichnis]/src/components/[Name].vue` – [Zweck]
-- `[Codeverzeichnis]/src/stores/[name].ts` – [Zweck]
-- `[Codeverzeichnis]/src/pages/[name].vue` – [Zweck]
+---
 
-### API-Calls implementiert
-- `GET /api/[endpoint]` – [Wofür]
-- `POST /api/[endpoint]` – [Wofür]
+## Phase 5: Review-Checkpoint
 
-### Design System Nutzung
-- Konforme Komponenten: [Liste]
-- Tokens-Build Komponenten (genehmigt): [Liste oder "–"]
-- Hypothesentest-Komponenten: [Liste oder "–"]
+```typescript
+AskUserQuestion({
+  questions: [{
+    question: "Implementierung prüfen",
+    header: "Code Review",
+    options: [
+      { label: "Sieht gut aus – weiter zu /red:proto-qa", description: "" },
+      { label: "Änderungen nötig", description: "Feedback im Chat" }
+    ],
+    multiSelect: false
+  }]
+})
+```
 
-### Fehlende Transitions (in flows/product-flows.md gemeldet)
-- [Screen + Situation] oder "–"
+## Phase 6: Feature-File + Commit
 
-### 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: ...]
+Nach Approval – Abschnitt `## 4. Implementierung` in FEAT-X.md ergänzen, Status auf "Dev" setzen, STATUS.md aktualisieren.
 
-### Offene Punkte
-- [Falls etwas nicht implementierbar war ohne Backend-Info oder fehlende Specs]
+```bash
+git add . features/STATUS.md
+git commit -m "feat: implement FEAT-[X] – [Feature Name]"
+git push
 ```
+
+Sage: "Implementierung abgeschlossen. Nächster Schritt: `/red:proto-qa`."

package/agents/qa-engineer.md

@@ -30,13 +30,39 @@ Gehe **jeden AC** durch. Teste ihn. Dokumentiere Ergebnis.
 - ✅ Passed
 - ❌ Failed → Bug-File anlegen
 
-### 2b. Edge Cases Tests
+### 2b. Edge-Case-Compliance-Pass – PFLICHT, systematisch
 
-Alle dokumentierten Edge Cases aus der Spec testen. Zusätzlich eigene aus QA-Perspektive:
+Dieser Pass ist nicht opportunistisch. Gehe **jeden** dokumentierten Edge Case aus der Spec einzeln durch und prüfe ob er im Code explizit implementiert und durch einen Test abgesichert ist.
+
+**Schritt 1: Edge Cases aus der Spec extrahieren**
+
+Lies Abschnitt 1 (Requirements/Edge Cases) und Abschnitt 3 (Tech-Design) des Feature-Files. Jeder Satz der "wenn … dann …"-Logik beschreibt einen Edge Case. Erstelle eine Liste:
+
+| # | Edge Case (aus Spec) | Im Code implementiert? | Test vorhanden? | Befund |
+|---|---------------------|----------------------|-----------------|--------|
+| 1 | [z.B. "Leere Eingabe → kein Todo, Fokus bleibt im Input"] | ✅ / ❌ | ✅ / ❌ | – / Bug |
+| 2 | [z.B. "Identischer Titel → eigene UUID"] | ✅ / ❌ | ✅ / ❌ | – / Bug |
+| 3 | [z.B. "Fokus nach Löschen → nächstes Item oder Input"] | ✅ / ❌ | ✅ / ❌ | – / Bug |
+
+**Schritt 2: Für jeden nicht abgesicherten Edge Case gilt:**
+- Code vorhanden, Test fehlt → Bug-File anlegen (Severity: Medium, Bereich: Test-Coverage)
+- Code fehlt → Bug-File anlegen (Severity: passend zum Edge Case)
+- Beides fehlt → Bug-File mit Severity High
+
+**Schritt 3: AC-Test-Matrix des Developer-Agents prüfen**
+
+Falls der Developer-Agent eine AC-Test-Matrix im Abschlussbericht geliefert hat:
+```bash
+# Test-Matrix aus dem Feature-File oder Developer-Bericht lesen
+```
+Vergleiche die Matrix mit den tatsächlich vorhandenen Tests. Jede Zeile der Matrix die keinen korrespondierenden Test im Testfile hat → Bug-File.
+
+**Zusätzliche eigene Edge Cases aus QA-Perspektive:**
 - Was passiert bei leerem Input?
-- Was passiert bei Maximal-Werten?
-- Was passiert bei gleichzeitigen Aktionen?
-- Was passiert bei Netzwerkfehlern?
+- Was passiert bei Maximal-Werten (z.B. sehr langer Text)?
+- Was passiert bei gleichzeitigen Aktionen (z.B. Edit + Delete gleichzeitig triggerbar)?
+- Was passiert bei identischen Timestamps oder IDs?
+- Was passiert wenn der Fokus-Management-Pfad nicht greift (z.B. ref ist null)?
 
 ### 2c. Security-Tests (immer)
 
@@ -98,7 +124,7 @@ Gib zurück:
 
 ### Getestete Bereiche
 - Acceptance Criteria: X/Y passed
-- Edge Cases: X getestet
+- Edge-Case-Compliance-Pass: X/Y Edge Cases implementiert + getestet (Details: Tabelle aus 2b)
 - Security: [kurzes Ergebnis]
 - Cross-Browser/Responsive: [kurzes Ergebnis]
 - Regression: [betroffene Bereiche geprüft]