red-proto 0.13.3 → 0.15.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/bin/install.js CHANGED
@@ -301,7 +301,7 @@ async function installFiles(claudeBase, isGlobal, noClobber) {
301
301
  copied++;
302
302
  }
303
303
 
304
- // If local install: also set up project structure + design system
304
+ // If local install: also set up project structure + design system + docs
305
305
  if (!isGlobal) {
306
306
  const dirs = ['research', 'features', 'flows', 'bugs', 'docs', 'projekt',
307
307
  'design-system/tokens', 'design-system/components',
@@ -311,6 +311,11 @@ async function installFiles(claudeBase, isGlobal, noClobber) {
311
311
  }
312
312
  const srcDS = join(PACKAGE_ROOT, 'design-system');
313
313
  await cp(srcDS, join(projectRoot, 'design-system'), { recursive: true, force: !noClobber, errorOnExist: false });
314
+
315
+ // Copy framework docs to .claude/red-proto/ (templates, SCAFFOLDING, CONVENTIONS)
316
+ const srcDocs = join(PACKAGE_ROOT, 'docs');
317
+ await mkdir(join(projectRoot, '.claude', 'red-proto'), { recursive: true });
318
+ await cp(srcDocs, join(projectRoot, '.claude', 'red-proto'), { recursive: true, force: !noClobber, errorOnExist: false });
314
319
  }
315
320
 
316
321
  console.log('');
@@ -3,13 +3,51 @@ name: Solution Architect
3
3
  description: Übersetzt Feature Specs in technisches Design – Component-Struktur, Daten-Model, Security, Test-Setup
4
4
  ---
5
5
 
6
- > Lies `docs/CONVENTIONS.md` für die verbindlichen Draft/Approval/Resume-Regeln.
6
+ > Lies `.claude/red-proto/CONVENTIONS.md` für die verbindlichen Draft/Approval/Resume-Regeln.
7
7
 
8
8
  Du bist Solution Architect. Du übersetzt Feature Specs in ein klares technisches Design. Kein Code, kein SQL, keine TypeScript-Interfaces – nur **WAS** gebaut wird, nicht **WIE** im Detail.
9
9
 
10
- ## Phase 0: Feature-ID
10
+ ## Phase 0: Projektstatus lesen und Feature wählen
11
11
 
12
- Keine ID in der Anfrage → `ls features/` → nachfragen.
12
+ ```bash
13
+ cat features/STATUS.md 2>/dev/null
14
+ ls features/FEAT-*.md 2>/dev/null
15
+ ```
16
+
17
+ Lies STATUS.md vollständig. Kategorisiere alle Features:
18
+
19
+ - **Tech-bereit** (für diesen Skill relevant): UX ✓, Tech noch `–`
20
+ - **In Bearbeitung**: Tech begonnen (status: draft), noch nicht approved
21
+ - **Tech fertig**: Tech ✓ – überspringen
22
+ - **UX fehlt noch**: UX `–` – überspringen, kurz erwähnen (erst /red:proto-ux nötig)
23
+ - **Noch nicht ready**: Req fehlt – überspringen
24
+
25
+ Zeige eine kurze Übersicht im Chat, z.B.:
26
+ ```
27
+ Tech-bereit (2): FEAT-01 Login, FEAT-03 Dashboard
28
+ In Bearbeitung: FEAT-02 Nutzerprofil (draft)
29
+ Bereits fertig: –
30
+ UX fehlt noch: FEAT-04 Benachrichtigungen, FEAT-05 Export (erst /red:proto-ux)
31
+ ```
32
+
33
+ **Wenn genau eine Feature-ID in der Anfrage angegeben** → direkt mit dieser starten, kein Multi-Select nötig. `MODUS = einzeln`.
34
+
35
+ **Wenn keine ID angegeben:** Multi-Select-Frage mit allen Tech-bereiten Features. Erste Option ist immer "Alle":
36
+
37
+ ```typescript
38
+ AskUserQuestion({ questions: [{ question: "Welche Features sollen jetzt bearbeitet werden?", header: "Feature-Auswahl", options: [
39
+ { label: "Alle: FEAT-[ID], FEAT-[ID]", description: "Alle in einem Durchlauf – eine Freigabe am Ende" },
40
+ { label: "FEAT-[ID] [Name]", description: "" },
41
+ { label: "FEAT-[ID] [Name]", description: "" }
42
+ ], multiSelect: true }] })
43
+ ```
44
+
45
+ *(Optionen dynamisch aus STATUS.md befüllen. "Alle"-Option konkrete IDs in label nennen.)*
46
+
47
+ **MODUS bestimmen:**
48
+ - "Alle" ausgewählt → `MODUS = alle`
49
+ - Teilmenge ausgewählt → `MODUS = einzeln`
50
+ - Bearbeitungsreihenfolge: ausgewählte Features in ID-Reihenfolge als `QUEUE` merken.
13
51
 
14
52
  ## Phase 1: Kontext lesen
15
53
 
@@ -68,94 +106,68 @@ AskUserQuestion({ questions: [{ question: "[Konkrete Frage]", header: "[Thema]",
68
106
 
69
107
  ## Phase 3: Tech-Design erstellen
70
108
 
71
- Ergänze `## 3. Technisches Design` in FEAT-X.md:
72
-
73
- ```markdown
74
- ## 3. Technisches Design
75
- *[Datum]*
76
-
77
- ### Component-Struktur
78
- FeatureContainer
79
- ├── FeatureHeader
80
- ├── FeatureList
81
- │ └── FeatureItem
82
- └── FeatureEmpty
83
-
84
- Wiederverwendbar: [Komponente X] aus src/components/...
85
-
86
- ### Daten-Model
87
- [Was wird gespeichert, wie strukturiert – kein SQL]
88
- Gespeichert in: [localStorage / DB-Tabelle / API-State]
89
-
90
- ### API / Daten-Fluss
91
- - GET /api/[resource] → [Zweck]
92
- - POST /api/[resource] → [Zweck]
93
-
94
- ### Tech-Entscheidungen
95
- - **[Entscheidung]:** [Begründung]
96
-
97
- ### Security-Anforderungen
98
- - Authentifizierung: [Wer darf?]
99
- - Autorisierung: [Rollen/Rechte]
100
- - Input-Validierung: [Wo was]
101
- - OWASP: [XSS/CSRF/SQL-Injection relevante Punkte]
102
-
103
- ### Dependencies
104
- - `package-name` – Zweck
105
-
106
- ### A11y-Architektur
107
-
108
- | Element | ARIA-Pattern | Entscheidung |
109
- |---------|-------------|--------------|
110
- | Haupt-Container | Landmark? | ... |
111
- | Listen/Grids | aria-label eindeutig? | ... |
112
- | Live-Regions | Trigger (niemals initialer Render!) | ... |
113
- | Fokus-Management | Nach Aktion X → Fokus auf Y | ... |
114
- | Dialoge/Modals | aria-modal, Fokus-Trap, Escape? | ... |
115
-
116
- ### Test-Setup
117
- - Unit: [Was]
118
- - Integration: [Was]
119
- - E2E: [Was]
120
-
121
- ### Test-Infrastruktur
122
- - Environment: [happy-dom/jsdom + Limitierungen]
123
- - Mocks: [localStorage → vi.stubGlobal, fetch → vi.fn()]
124
- - Setup/Teardown: [beforeEach/afterEach Patterns]
125
- - Fallstricke: [z.B. "localStorage in happy-dom braucht Stub"]
109
+ ```bash
110
+ cat .claude/red-proto/templates/tech-design.md
126
111
  ```
127
112
 
128
- ## Phase 4: Review und Handoff
113
+ Ergänze `## 3. Technisches Design` in FEAT-[X].md nach diesem Template. Fülle alle Platzhalter aus dem Kontext.
114
+
115
+ ## Phase 3b: Draft auf Disk schreiben
116
+
117
+ Unabhängig vom MODUS: FEAT-[X].md jetzt mit `## 3. Technisches Design` ergänzen und `status: draft` setzen. Datei auf Disk schreiben – noch kein Commit.
118
+
119
+ ---
120
+
121
+ ## Phase 4: Review (nur MODUS = einzeln)
122
+
123
+ *Wenn MODUS = `alle`: diesen Abschnitt überspringen. Weiter zum nächsten Feature in QUEUE (Phase 1). Wenn QUEUE leer: zu „Finale Freigabe (MODUS = alle)".*
129
124
 
130
125
  ```typescript
131
- AskUserQuestion({ questions: [{ question: "Passt das technische Design?", header: "Review", options: [
132
- { label: "Approved – weiter zu /red:proto-dev", description: "Design klar und vollständig" },
126
+ AskUserQuestion({ questions: [{ question: "Passt das technische Design für FEAT-[X] [Name]?", header: "Review", options: [
127
+ { label: "Passt – weiter mit nächstem Feature", description: "" },
128
+ { label: "Passt – das war das letzte, weiter zu /red:proto-dev", description: "" },
133
129
  { label: "Fragen / Änderungen", description: "Feedback im Chat" }
134
130
  ], multiSelect: false }] })
135
131
  ```
136
132
 
137
- Nach Approval: FEAT-[X].md um Abschnitt `## 3. Technisches Design` erweitern, YAML `status: draft` setzen. User per CONVENTIONS.md §Resume Pattern informieren.
138
-
139
- ## Phase 4b: Finalisieren
133
+ ## Phase 4b: Finalisieren (nur MODUS = einzeln)
140
134
 
141
- Nach `weiter` oder Korrekturen: FEAT-[X].md einlesen, Korrekturen übernehmen, `status: approved` + `## Fortschritt → Status: Approved, Aktueller Schritt: Tech` setzen. STATUS.md (Tech-Spalte ✓).
135
+ Korrekturen übernehmen (falls nötig), `status: approved` + `## Fortschritt → Status: Freigegeben, Aktueller Schritt: Tech` setzen. STATUS.md (Tech-Spalte ✓).
142
136
 
143
137
  ```bash
144
- echo "Ich committe jetzt:"
145
- echo " → features/FEAT-[X]-[name].md – Tech Design finalisiert"
146
- echo " → features/STATUS.md – Tech-Status aktualisiert"
147
138
  git add features/FEAT-[X]-*.md features/STATUS.md
148
139
  git commit -q -m "docs: FEAT-[X] tech design – [Feature Name]" && git push -q
149
140
  ```
150
141
 
151
- ## Routing nach Approval
142
+ Nächstes Feature in QUEUE → Phase 1. Wenn QUEUE leer: abschließen.
152
143
 
153
- Lies STATUS.md und biete an:
154
- - Features mit UX ✓ aber Tech noch `–` → "Weiter mit FEAT-[ID] (Tech fehlt noch)"
155
- - "Alle Features abgedeckt weiter zu /red:proto-dev"
156
- - "Direkt zu /red:proto-dev für FEAT-[X]"
144
+ ---
145
+
146
+ ## Finale Freigabe (nur MODUS = alle)
147
+
148
+ Alle Features in QUEUE wurden als Draft auf Disk geschrieben. Zeige eine Zusammenfassung:
149
+
150
+ ```
151
+ Fertig als Draft:
152
+ ✓ FEAT-01 Login → features/FEAT-01-login.md
153
+ ✓ FEAT-03 Dashboard → features/FEAT-03-dashboard.md
154
+ ```
155
+
156
+ ```typescript
157
+ AskUserQuestion({ questions: [{ question: "Alle Tech-Designs sehen gut aus?", header: "Finale Freigabe", options: [
158
+ { label: "Alles freigeben und committen", description: "Alle Features auf approved setzen, ein Commit" },
159
+ { label: "Änderungen nötig", description: "Welches Feature – Feedback im Chat" }
160
+ ], multiSelect: false }] })
161
+ ```
162
+
163
+ Nach Freigabe: alle Draft-Dateien auf `status: approved` setzen, `## Fortschritt` aktualisieren, STATUS.md (Tech-Spalte ✓) für alle Features. Dann ein einziger Commit:
164
+
165
+ ```bash
166
+ git add features/FEAT-*.md features/STATUS.md
167
+ git commit -q -m "docs: tech design – FEAT-[ID], FEAT-[ID]" && git push -q
168
+ ```
157
169
 
158
- Bei "Weiter mit Feature X": direkt Phase 0 für nächstes Feature starten.
170
+ Abschluss: "Alle Tech-Designs freigegeben. Weiter mit `/red:proto-dev`."
159
171
 
160
172
  ## Checklist vor Abschluss
161
173
 
@@ -169,4 +181,4 @@ Bei "Weiter mit Feature X": direkt Phase 0 für nächstes Feature starten.
169
181
  - [ ] State-Komplexität geprüft
170
182
  - [ ] Externe Daten: Validation-Strategie definiert
171
183
  - [ ] Dependencies aufgelistet
172
- - [ ] User approved
184
+ - [ ] User hat freigegeben
@@ -138,7 +138,7 @@ AskUserQuestion({
138
138
  Falls "Erkläre mir mehr": Beantworte die Fragen in einfacher Sprache. Keine Annahme von Vorwissen.
139
139
  Falls "Andere Präferenz": Nimm den genannten Stack, passe Phase 4 entsprechend an.
140
140
 
141
- Danach noch fragen:
141
+ Danach fragen (Verzeichnis + GitHub in einem Block):
142
142
 
143
143
  ```typescript
144
144
  AskUserQuestion({
@@ -153,16 +153,7 @@ AskUserQuestion({
153
153
  { label: "Anderer Name – ich nenne ihn im Chat", description: "Beliebiger Verzeichnisname" }
154
154
  ],
155
155
  multiSelect: false
156
- }
157
- ]
158
- })
159
- ```
160
-
161
- Warte auf Antwort. Falls "Anderer Name": nachfragen im Chat.
162
-
163
- ```typescript
164
- AskUserQuestion({
165
- questions: [
156
+ },
166
157
  {
167
158
  question: "Soll ein GitHub-Repository angelegt werden?",
168
159
  header: "GitHub Repository",
@@ -177,7 +168,7 @@ AskUserQuestion({
177
168
  })
178
169
  ```
179
170
 
180
- Falls GitHub gewünscht:
171
+ Falls "Anderer Name" bei Verzeichnis: nachfragen im Chat. Falls GitHub gewünscht:
181
172
 
182
173
  ```typescript
183
174
  AskUserQuestion({
@@ -190,30 +181,13 @@ AskUserQuestion({
190
181
  { label: "Anderer Name – ich nenne ihn im Chat", description: "Eigener Name, keine Leerzeichen, Bindestriche statt Unterstriche" }
191
182
  ],
192
183
  multiSelect: false
193
- }
194
- ]
195
- })
196
- ```
197
-
198
- Warte auf Antwort. Falls "Anderer Name": nachfragen im Chat.
199
-
200
- Falls GitHub Ja:
201
-
202
- ```typescript
203
- AskUserQuestion({
204
- questions: [
184
+ },
205
185
  {
206
186
  question: "Was soll ins GitHub-Repository?",
207
187
  header: "Repository-Inhalt",
208
188
  options: [
209
- {
210
- label: "Nur der Programm-Code",
211
- description: "Nur das Code-Verzeichnis – Projektdokumentation (features/, docs/, research/) bleibt lokal"
212
- },
213
- {
214
- label: "Alles – Code + Projektdokumentation",
215
- description: "PRD, Feature-Specs, Docs und Code in einem Repository"
216
- }
189
+ { label: "Nur der Programm-Code", description: "Nur das Code-Verzeichnis – Projektdokumentation (features/, docs/, research/) bleibt lokal" },
190
+ { label: "Alles Code + Projektdokumentation", description: "PRD, Feature-Specs, Docs und Code in einem Repository" }
217
191
  ],
218
192
  multiSelect: false
219
193
  }
@@ -221,182 +195,19 @@ AskUserQuestion({
221
195
  })
222
196
  ```
223
197
 
224
- ## Phase 5: Projekt scaffolden
225
-
226
- `[codedir]` = bestätigtes Code-Verzeichnis (z.B. `projekt/`). Immer zuerst anlegen und dann mit `.` als Scaffold-Ziel arbeiten – so entsteht kein neuer Unterordner.
227
-
228
- ```bash
229
- mkdir -p [codedir]
230
- cd [codedir]
231
- ```
232
-
233
- > **Wichtig – interaktive Rückfragen im Terminal:**
234
- > - **"Initialize git repository?"** → immer **No** – Git richtet das Framework in Phase 6 ein
235
- > - **"Install dependencies?"** → **Yes**
236
- > - **"Project name?"** → den Repository-Namen eingeben (ist nur Metadaten, kein Ordner)
237
- > - Alle anderen Fragen: empfohlene Option wählen
238
-
239
- ### JavaScript / TypeScript Web
240
-
241
- **Next.js (React):**
242
- ```bash
243
- mkdir -p [codedir] && cd [codedir]
244
- npx create-next-app@latest . --typescript --tailwind --app --src-dir --no-git
245
- ```
246
-
247
- **Nuxt:**
248
- ```bash
249
- mkdir -p [codedir] && cd [codedir]
250
- # Falls "Initialize git?" erscheint: No wählen
251
- npx nuxi@latest init . --no-git
252
- ```
253
-
254
- **Vue + Vite:**
255
- ```bash
256
- mkdir -p [codedir] && cd [codedir]
257
- # Interaktiv: TypeScript Ja, Router Ja, Pinia Ja, Vitest Ja, Git Nein
258
- npm create vue@latest .
259
- ```
260
-
261
- **React + Vite:**
262
- ```bash
263
- mkdir -p [codedir] && cd [codedir]
264
- npm create vite@latest . -- --template react-ts
265
- ```
266
-
267
- **SvelteKit:**
268
- ```bash
269
- mkdir -p [codedir] && cd [codedir]
270
- # Interaktiv – bei Git-Frage: Nein
271
- npm create svelte@latest .
272
- ```
273
-
274
- **Angular:**
275
- ```bash
276
- mkdir -p [codedir] && cd [codedir]
277
- npx @angular/cli@latest new . --routing --style=scss --no-git
278
- ```
198
+ Falls "Anderer Name" bei Repo: nachfragen im Chat.
279
199
 
280
- **Remix:**
281
- ```bash
282
- mkdir -p [codedir] && cd [codedir]
283
- npx create-remix@latest . --no-git
284
- ```
285
-
286
- **Astro:**
287
- ```bash
288
- mkdir -p [codedir] && cd [codedir]
289
- # Interaktiv – bei Git-Frage: Nein
290
- npm create astro@latest .
291
- ```
292
-
293
- **NestJS (Backend):**
294
- ```bash
295
- mkdir -p [codedir] && cd [codedir]
296
- npx @nestjs/cli@latest new . --package-manager npm --skip-git
297
- ```
298
-
299
- **Express (Backend):**
300
- ```bash
301
- mkdir -p [codedir] && cd [codedir]
302
- npm init -y
303
- npm install express
304
- npm install -D typescript @types/node @types/express ts-node nodemon
305
- ```
306
-
307
- ### Python
308
-
309
- **FastAPI:**
310
- ```bash
311
- mkdir -p [codedir] && cd [codedir]
312
- python3 -m venv venv && source venv/bin/activate
313
- pip install fastapi uvicorn[standard] python-dotenv
314
- ```
315
-
316
- **Django:**
317
- ```bash
318
- mkdir -p [codedir] && cd [codedir]
319
- python3 -m venv venv && source venv/bin/activate
320
- pip install django python-dotenv
321
- # '.' als Ziel: legt manage.py direkt im Verzeichnis ab, kein Unterordner
322
- django-admin startproject config .
323
- ```
324
-
325
- **Flask:**
326
- ```bash
327
- mkdir -p [codedir] && cd [codedir]
328
- python3 -m venv venv && source venv/bin/activate
329
- pip install flask python-dotenv
330
- ```
331
-
332
- ### Java
333
-
334
- **Spring Boot** (via Spring Initializr CLI):
335
- ```bash
336
- mkdir -p [codedir]
337
- # baseDir=. damit kein Unterordner entsteht
338
- curl https://start.spring.io/starter.zip \
339
- -d type=maven-project \
340
- -d language=java \
341
- -d bootVersion=3.2.0 \
342
- -d baseDir=. \
343
- -d groupId=com.example \
344
- -d artifactId=[repo-name] \
345
- -d dependencies=web,data-jpa,postgresql \
346
- -o scaffold.zip
347
- unzip scaffold.zip -d [codedir] && rm scaffold.zip
348
- ```
349
-
350
- ### C# / .NET
351
-
352
- **ASP.NET Core Web API:**
353
- ```bash
354
- mkdir -p [codedir] && cd [codedir]
355
- # '--output .' damit kein Unterordner entsteht
356
- dotnet new webapi --output . --no-https false
357
- ```
358
-
359
- **Blazor:**
360
- ```bash
361
- mkdir -p [codedir] && cd [codedir]
362
- dotnet new blazor --output .
363
- ```
364
-
365
- ### Ruby
366
-
367
- **Rails:**
368
- ```bash
369
- mkdir -p [codedir] && cd [codedir]
370
- # '.' als Ziel: kein Unterordner
371
- rails new . --database=postgresql --no-git
372
- ```
373
-
374
- ### Go
375
-
376
- ```bash
377
- mkdir -p [codedir] && cd [codedir]
378
- go mod init [repo-name]
379
- # Gin:
380
- go get github.com/gin-gonic/gin
381
- ```
200
+ ## Phase 5: Projekt scaffolden
382
201
 
383
- ### Mobile
202
+ `[codedir]` = bestätigtes Code-Verzeichnis (z.B. `projekt/`). Immer mit `.` als Scaffold-Ziel – kein Unterordner.
384
203
 
385
- **React Native (Expo):**
386
- ```bash
387
- mkdir -p [codedir] && cd [codedir]
388
- npx create-expo-app@latest . --template blank-typescript
389
- ```
204
+ Wähle den passenden Abschnitt für den bestätigten Stack aus:
390
205
 
391
- **Flutter:**
392
206
  ```bash
393
- mkdir -p [codedir] && cd [codedir]
394
- flutter create .
207
+ cat .claude/red-proto/SCAFFOLDING.md
395
208
  ```
396
209
 
397
- ### Nicht gelisteter Stack
398
-
399
- Falls der gewählte Stack nicht in der Liste ist: Nutze die offizielle `create-*` CLI oder den Standard-Scaffolding-Weg des Frameworks. Dokumentiere den verwendeten Befehl in `project-config.md`.
210
+ Führe die Befehle für `[gewähltes Framework]` aus. Danach zurück zu Phase 5b.
400
211
 
401
212
  ---
402
213
 
@@ -166,26 +166,12 @@ git commit -q -m "feat: implement FEAT-[X] – [Feature Name]" && git push -q
166
166
 
167
167
  Schreibe `context/FEAT-[ID]-dev-handoff.md` (legt Kontext für `/red:proto-qa` in neuer Session):
168
168
 
169
- ```markdown
170
- # Dev Handoff – FEAT-[ID]: [Feature Name]
171
- *[Datum]*
172
-
173
- ## Was gebaut wurde
174
- - [Komponenten/Dateien mit kurzem Zweck]
175
-
176
- ## Entscheidungen getroffen
177
- - [Wichtige Implementierungsentscheidungen und Begründungen]
178
-
179
- ## DS-Abweichungen
180
- - [Tokens-Build oder Hypothesentest-Komponenten, falls vorhanden]
181
-
182
- ## Offene Punkte
183
- - [Was nicht implementiert wurde und warum]
184
-
185
- ## Für QA relevant
186
- - [Bekannte Edge Cases, Stolperstellen, was besonders getestet werden sollte]
169
+ ```bash
170
+ cat .claude/red-proto/templates/dev-handoff.md
187
171
  ```
188
172
 
173
+ Fülle alle Platzhalter mit konkreten Inhalten der Implementierung.
174
+
189
175
  ```bash
190
176
  mkdir -p context
191
177
  git add context/FEAT-[ID]-dev-handoff.md
@@ -3,7 +3,7 @@ name: Flows
3
3
  description: Definiert übergreifende Nutzerreisen und exakte Screen Transitions – verbindliche Navigations-Referenz für alle Agents
4
4
  ---
5
5
 
6
- > Lies `docs/CONVENTIONS.md` für die verbindlichen Draft/Approval/Resume-Regeln.
6
+ > Lies `.claude/red-proto/CONVENTIONS.md` für die verbindlichen Draft/Approval/Resume-Regeln.
7
7
 
8
8
  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.
9
9
 
@@ -215,7 +215,7 @@ AskUserQuestion({
215
215
  question: "Sind alle Screens und Transitions vollständig und korrekt?",
216
216
  header: "Flows Review",
217
217
  options: [
218
- { label: "Approved – Flows sind vollständig", description: "Weiter zu /red:proto-ux für einzelne Features" },
218
+ { label: "Passt so – Flows sind vollständig", description: "Weiter zu /red:proto-ux für einzelne Features" },
219
219
  { label: "Änderungen nötig", description: "Feedback im Chat" }
220
220
  ],
221
221
  multiSelect: false
@@ -231,8 +231,6 @@ Nach Approval: `flows/product-flows.md` ist bereits als Draft gespeichert (Phase
231
231
  Nach `weiter` oder Korrekturen: `flows/product-flows.md` einlesen, Korrekturen übernehmen, `status: approved` setzen.
232
232
 
233
233
  ```bash
234
- echo "Ich committe jetzt:"
235
- echo " → flows/product-flows.md – Screen-Inventar und Transitions finalisiert"
236
234
  git add flows/
237
235
  git commit -q -m "docs: product flows – screen inventory + transitions" && git push -q
238
236
  ```
@@ -46,17 +46,8 @@ Agent("ux-reviewer", {
46
46
 
47
47
  Naming: `BUG-FEAT[X]-QA-[NNN].md` / `BUG-FEAT[X]-UX-[NNN].md`
48
48
 
49
- ```markdown
50
- # BUG-FEAT[X]-[NNN]: [Kurztitel]
51
- - **Severity:** Critical | High | Medium | Low
52
- - **Bereich:** Functional | Security | A11y | Performance | UX
53
- - **Status:** Open
54
-
55
- ## Steps to Reproduce
56
- 1. ... 2. ... Expected: [...] Actual: [...]
57
-
58
- ## Priority
59
- Fix now | Fix before release | Nice-to-have
49
+ ```bash
50
+ cat .claude/red-proto/templates/bug-report.md
60
51
  ```
61
52
 
62
53
  Severity: Critical = Datenverlust/App unnutzbar, High = Kernfunktion kaputt, Medium = A11y/Flow-Bruch, Low = Optik/Edge-Case. Im Feature-File nur Bug-IDs referenzieren.