red-proto 0.13.2 → 0.15.1

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Enrico Reinsdorf
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/bin/install.js

@@ -301,7 +301,7 @@ async function installFiles(claudeBase, isGlobal, noClobber) {
     copied++;
   }
 
-  // If local install: also set up project structure + design system
+  // If local install: also set up project structure + design system + docs
   if (!isGlobal) {
     const dirs = ['research', 'features', 'flows', 'bugs', 'docs', 'projekt',
                   'design-system/tokens', 'design-system/components',
@@ -311,6 +311,11 @@ async function installFiles(claudeBase, isGlobal, noClobber) {
     }
     const srcDS = join(PACKAGE_ROOT, 'design-system');
     await cp(srcDS, join(projectRoot, 'design-system'), { recursive: true, force: !noClobber, errorOnExist: false });
+
+    // Copy framework docs to .claude/red-proto/ (templates, SCAFFOLDING, CONVENTIONS)
+    const srcDocs = join(PACKAGE_ROOT, 'docs');
+    await mkdir(join(projectRoot, '.claude', 'red-proto'), { recursive: true });
+    await cp(srcDocs, join(projectRoot, '.claude', 'red-proto'), { recursive: true, force: !noClobber, errorOnExist: false });
   }
 
   console.log('');

package/commands/red:proto-architect.md

@@ -3,13 +3,51 @@ name: Solution Architect
 description: Übersetzt Feature Specs in technisches Design – Component-Struktur, Daten-Model, Security, Test-Setup
 ---
 
-> Lies `docs/CONVENTIONS.md` für die verbindlichen Draft/Approval/Resume-Regeln.
+> Lies `.claude/red-proto/CONVENTIONS.md` für die verbindlichen Draft/Approval/Resume-Regeln.
 
 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.
 
-## Phase 0: Feature-ID
+## Phase 0: Projektstatus lesen und Feature wählen
 
-Keine ID in der Anfrage → `ls features/` → nachfragen.
+```bash
+cat features/STATUS.md 2>/dev/null
+ls features/FEAT-*.md 2>/dev/null
+```
+
+Lies STATUS.md vollständig. Kategorisiere alle Features:
+
+- **Tech-bereit** (für diesen Skill relevant): UX ✓, Tech noch `–`
+- **In Bearbeitung**: Tech begonnen (status: draft), noch nicht approved
+- **Tech fertig**: Tech ✓ – überspringen
+- **UX fehlt noch**: UX `–` – überspringen, kurz erwähnen (erst /red:proto-ux nötig)
+- **Noch nicht ready**: Req fehlt – überspringen
+
+Zeige eine kurze Übersicht im Chat, z.B.:
+```
+Tech-bereit (2):  FEAT-01 Login, FEAT-03 Dashboard
+In Bearbeitung:   FEAT-02 Nutzerprofil (draft)
+Bereits fertig:   –
+UX fehlt noch:    FEAT-04 Benachrichtigungen, FEAT-05 Export (erst /red:proto-ux)
+```
+
+**Wenn genau eine Feature-ID in der Anfrage angegeben** → direkt mit dieser starten, kein Multi-Select nötig. `MODUS = einzeln`.
+
+**Wenn keine ID angegeben:** Multi-Select-Frage mit allen Tech-bereiten Features. Erste Option ist immer "Alle":
+
+```typescript
+AskUserQuestion({ questions: [{ question: "Welche Features sollen jetzt bearbeitet werden?", header: "Feature-Auswahl", options: [
+  { label: "Alle: FEAT-[ID], FEAT-[ID]", description: "Alle in einem Durchlauf – eine Freigabe am Ende" },
+  { label: "FEAT-[ID] [Name]", description: "" },
+  { label: "FEAT-[ID] [Name]", description: "" }
+], multiSelect: true }] })
+```
+
+*(Optionen dynamisch aus STATUS.md befüllen. "Alle"-Option konkrete IDs in label nennen.)*
+
+**MODUS bestimmen:**
+- "Alle" ausgewählt → `MODUS = alle`
+- Teilmenge ausgewählt → `MODUS = einzeln`
+- Bearbeitungsreihenfolge: ausgewählte Features in ID-Reihenfolge als `QUEUE` merken.
 
 ## Phase 1: Kontext lesen
 
@@ -68,94 +106,68 @@ AskUserQuestion({ questions: [{ question: "[Konkrete Frage]", header: "[Thema]",
 
 ## Phase 3: Tech-Design erstellen
 
-Ergänze `## 3. Technisches Design` in FEAT-X.md:
-
-```markdown
-## 3. Technisches Design
-*[Datum]*
-
-### Component-Struktur
-FeatureContainer
-├── FeatureHeader
-├── FeatureList
-│   └── FeatureItem
-└── FeatureEmpty
-
-Wiederverwendbar: [Komponente X] aus src/components/...
-
-### Daten-Model
-[Was wird gespeichert, wie strukturiert – kein SQL]
-Gespeichert in: [localStorage / DB-Tabelle / API-State]
-
-### API / Daten-Fluss
-- GET  /api/[resource]   → [Zweck]
-- POST /api/[resource]   → [Zweck]
-
-### Tech-Entscheidungen
-- **[Entscheidung]:** [Begründung]
-
-### Security-Anforderungen
-- Authentifizierung: [Wer darf?]
-- Autorisierung: [Rollen/Rechte]
-- Input-Validierung: [Wo was]
-- OWASP: [XSS/CSRF/SQL-Injection relevante Punkte]
-
-### Dependencies
-- `package-name` – Zweck
-
-### A11y-Architektur
-
-| Element | ARIA-Pattern | Entscheidung |
-|---------|-------------|--------------|
-| Haupt-Container | Landmark? | ... |
-| Listen/Grids | aria-label eindeutig? | ... |
-| Live-Regions | Trigger (niemals initialer Render!) | ... |
-| Fokus-Management | Nach Aktion X → Fokus auf Y | ... |
-| Dialoge/Modals | aria-modal, Fokus-Trap, Escape? | ... |
-
-### Test-Setup
-- Unit: [Was]
-- Integration: [Was]
-- E2E: [Was]
-
-### Test-Infrastruktur
-- Environment: [happy-dom/jsdom + Limitierungen]
-- Mocks: [localStorage → vi.stubGlobal, fetch → vi.fn()]
-- Setup/Teardown: [beforeEach/afterEach Patterns]
-- Fallstricke: [z.B. "localStorage in happy-dom braucht Stub"]
+```bash
+cat .claude/red-proto/templates/tech-design.md
 ```
 
-## Phase 4: Review und Handoff
+Ergänze `## 3. Technisches Design` in FEAT-[X].md nach diesem Template. Fülle alle Platzhalter aus dem Kontext.
+
+## Phase 3b: Draft auf Disk schreiben
+
+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.
+
+---
+
+## Phase 4: Review (nur MODUS = einzeln)
+
+*Wenn MODUS = `alle`: diesen Abschnitt überspringen. Weiter zum nächsten Feature in QUEUE (Phase 1). Wenn QUEUE leer: zu „Finale Freigabe (MODUS = alle)".*
 
 ```typescript
-AskUserQuestion({ questions: [{ question: "Passt das technische Design?", header: "Review", options: [
-  { label: "Approved – weiter zu /red:proto-dev", description: "Design klar und vollständig" },
+AskUserQuestion({ questions: [{ question: "Passt das technische Design für FEAT-[X] [Name]?", header: "Review", options: [
+  { label: "Passt – weiter mit nächstem Feature", description: "" },
+  { label: "Passt – das war das letzte, weiter zu /red:proto-dev", description: "" },
   { label: "Fragen / Änderungen", description: "Feedback im Chat" }
 ], multiSelect: false }] })
 ```
 
-Nach Approval: FEAT-[X].md um Abschnitt `## 3. Technisches Design` erweitern, YAML `status: draft` setzen. User per CONVENTIONS.md §Resume Pattern informieren.
-
-## Phase 4b: Finalisieren
+## Phase 4b: Finalisieren (nur MODUS = einzeln)
 
-Nach `weiter` oder Korrekturen: FEAT-[X].md einlesen, Korrekturen übernehmen, `status: approved` + `## Fortschritt → Status: Approved, Aktueller Schritt: Tech` setzen. STATUS.md (Tech-Spalte ✓).
+Korrekturen übernehmen (falls nötig), `status: approved` + `## Fortschritt → Status: Freigegeben, Aktueller Schritt: Tech` setzen. STATUS.md (Tech-Spalte ✓).
 
 ```bash
-echo "Ich committe jetzt:"
-echo "  → features/FEAT-[X]-[name].md – Tech Design finalisiert"
-echo "  → features/STATUS.md – Tech-Status aktualisiert"
 git add features/FEAT-[X]-*.md features/STATUS.md
 git commit -q -m "docs: FEAT-[X] tech design – [Feature Name]" && git push -q
 ```
 
-## Routing nach Approval
+Nächstes Feature in QUEUE → Phase 1. Wenn QUEUE leer: abschließen.
 
-Lies STATUS.md und biete an:
-- Features mit UX ✓ aber Tech noch `–` → "Weiter mit FEAT-[ID] (Tech fehlt noch)"
-- "Alle Features abgedeckt – weiter zu /red:proto-dev"
-- "Direkt zu /red:proto-dev für FEAT-[X]"
+---
+
+## Finale Freigabe (nur MODUS = alle)
+
+Alle Features in QUEUE wurden als Draft auf Disk geschrieben. Zeige eine Zusammenfassung:
+
+```
+Fertig als Draft:
+  ✓ FEAT-01 Login          → features/FEAT-01-login.md
+  ✓ FEAT-03 Dashboard      → features/FEAT-03-dashboard.md
+```
+
+```typescript
+AskUserQuestion({ questions: [{ question: "Alle Tech-Designs sehen gut aus?", header: "Finale Freigabe", options: [
+  { label: "Alles freigeben und committen", description: "Alle Features auf approved setzen, ein Commit" },
+  { label: "Änderungen nötig", description: "Welches Feature – Feedback im Chat" }
+], multiSelect: false }] })
+```
+
+Nach Freigabe: alle Draft-Dateien auf `status: approved` setzen, `## Fortschritt` aktualisieren, STATUS.md (Tech-Spalte ✓) für alle Features. Dann ein einziger Commit:
+
+```bash
+git add features/FEAT-*.md features/STATUS.md
+git commit -q -m "docs: tech design – FEAT-[ID], FEAT-[ID]" && git push -q
+```
 
-Bei "Weiter mit Feature X": direkt Phase 0 für nächstes Feature starten.
+Abschluss: "Alle Tech-Designs freigegeben. Weiter mit `/red:proto-dev`."
 
 ## Checklist vor Abschluss
 
@@ -169,4 +181,4 @@ Bei "Weiter mit Feature X": direkt Phase 0 für nächstes Feature starten.
 - [ ] State-Komplexität geprüft
 - [ ] Externe Daten: Validation-Strategie definiert
 - [ ] Dependencies aufgelistet
-- [ ] User approved
+- [ ] User hat freigegeben

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

@@ -138,7 +138,7 @@ AskUserQuestion({
 Falls "Erkläre mir mehr": Beantworte die Fragen in einfacher Sprache. Keine Annahme von Vorwissen.
 Falls "Andere Präferenz": Nimm den genannten Stack, passe Phase 4 entsprechend an.
 
-Danach noch fragen:
+Danach fragen (Verzeichnis + GitHub in einem Block):
 
 ```typescript
 AskUserQuestion({
@@ -153,16 +153,7 @@ AskUserQuestion({
         { label: "Anderer Name – ich nenne ihn im Chat", description: "Beliebiger Verzeichnisname" }
       ],
       multiSelect: false
-    }
-  ]
-})
-```
-
-Warte auf Antwort. Falls "Anderer Name": nachfragen im Chat.
-
-```typescript
-AskUserQuestion({
-  questions: [
+    },
     {
       question: "Soll ein GitHub-Repository angelegt werden?",
       header: "GitHub Repository",
@@ -177,7 +168,7 @@ AskUserQuestion({
 })
 ```
 
-Falls GitHub gewünscht:
+Falls "Anderer Name" bei Verzeichnis: nachfragen im Chat. Falls GitHub gewünscht:
 
 ```typescript
 AskUserQuestion({
@@ -190,30 +181,13 @@ AskUserQuestion({
         { label: "Anderer Name – ich nenne ihn im Chat", description: "Eigener Name, keine Leerzeichen, Bindestriche statt Unterstriche" }
       ],
       multiSelect: false
-    }
-  ]
-})
-```
-
-Warte auf Antwort. Falls "Anderer Name": nachfragen im Chat.
-
-Falls GitHub Ja:
-
-```typescript
-AskUserQuestion({
-  questions: [
+    },
     {
       question: "Was soll ins GitHub-Repository?",
       header: "Repository-Inhalt",
       options: [
-        {
-          label: "Nur der Programm-Code",
-          description: "Nur das Code-Verzeichnis – Projektdokumentation (features/, docs/, research/) bleibt lokal"
-        },
-        {
-          label: "Alles – Code + Projektdokumentation",
-          description: "PRD, Feature-Specs, Docs und Code in einem Repository"
-        }
+        { label: "Nur der Programm-Code", description: "Nur das Code-Verzeichnis – Projektdokumentation (features/, docs/, research/) bleibt lokal" },
+        { label: "Alles – Code + Projektdokumentation", description: "PRD, Feature-Specs, Docs und Code in einem Repository" }
       ],
       multiSelect: false
     }
@@ -221,182 +195,19 @@ AskUserQuestion({
 })
 ```
 
-## Phase 5: Projekt scaffolden
-
-`[codedir]` = bestätigtes Code-Verzeichnis (z.B. `projekt/`). Immer zuerst anlegen und dann mit `.` als Scaffold-Ziel arbeiten – so entsteht kein neuer Unterordner.
-
-```bash
-mkdir -p [codedir]
-cd [codedir]
-```
-
-> **Wichtig – interaktive Rückfragen im Terminal:**
-> - **"Initialize git repository?"** → immer **No** – Git richtet das Framework in Phase 6 ein
-> - **"Install dependencies?"** → **Yes**
-> - **"Project name?"** → den Repository-Namen eingeben (ist nur Metadaten, kein Ordner)
-> - Alle anderen Fragen: empfohlene Option wählen
-
-### JavaScript / TypeScript Web
-
-**Next.js (React):**
-```bash
-mkdir -p [codedir] && cd [codedir]
-npx create-next-app@latest . --typescript --tailwind --app --src-dir --no-git
-```
-
-**Nuxt:**
-```bash
-mkdir -p [codedir] && cd [codedir]
-# Falls "Initialize git?" erscheint: No wählen
-npx nuxi@latest init . --no-git
-```
-
-**Vue + Vite:**
-```bash
-mkdir -p [codedir] && cd [codedir]
-# Interaktiv: TypeScript Ja, Router Ja, Pinia Ja, Vitest Ja, Git Nein
-npm create vue@latest .
-```
-
-**React + Vite:**
-```bash
-mkdir -p [codedir] && cd [codedir]
-npm create vite@latest . -- --template react-ts
-```
-
-**SvelteKit:**
-```bash
-mkdir -p [codedir] && cd [codedir]
-# Interaktiv – bei Git-Frage: Nein
-npm create svelte@latest .
-```
-
-**Angular:**
-```bash
-mkdir -p [codedir] && cd [codedir]
-npx @angular/cli@latest new . --routing --style=scss --no-git
-```
+Falls "Anderer Name" bei Repo: nachfragen im Chat.
 
-**Remix:**
-```bash
-mkdir -p [codedir] && cd [codedir]
-npx create-remix@latest . --no-git
-```
-
-**Astro:**
-```bash
-mkdir -p [codedir] && cd [codedir]
-# Interaktiv – bei Git-Frage: Nein
-npm create astro@latest .
-```
-
-**NestJS (Backend):**
-```bash
-mkdir -p [codedir] && cd [codedir]
-npx @nestjs/cli@latest new . --package-manager npm --skip-git
-```
-
-**Express (Backend):**
-```bash
-mkdir -p [codedir] && cd [codedir]
-npm init -y
-npm install express
-npm install -D typescript @types/node @types/express ts-node nodemon
-```
-
-### Python
-
-**FastAPI:**
-```bash
-mkdir -p [codedir] && cd [codedir]
-python3 -m venv venv && source venv/bin/activate
-pip install fastapi uvicorn[standard] python-dotenv
-```
-
-**Django:**
-```bash
-mkdir -p [codedir] && cd [codedir]
-python3 -m venv venv && source venv/bin/activate
-pip install django python-dotenv
-# '.' als Ziel: legt manage.py direkt im Verzeichnis ab, kein Unterordner
-django-admin startproject config .
-```
-
-**Flask:**
-```bash
-mkdir -p [codedir] && cd [codedir]
-python3 -m venv venv && source venv/bin/activate
-pip install flask python-dotenv
-```
-
-### Java
-
-**Spring Boot** (via Spring Initializr CLI):
-```bash
-mkdir -p [codedir]
-# baseDir=. damit kein Unterordner entsteht
-curl https://start.spring.io/starter.zip \
-  -d type=maven-project \
-  -d language=java \
-  -d bootVersion=3.2.0 \
-  -d baseDir=. \
-  -d groupId=com.example \
-  -d artifactId=[repo-name] \
-  -d dependencies=web,data-jpa,postgresql \
-  -o scaffold.zip
-unzip scaffold.zip -d [codedir] && rm scaffold.zip
-```
-
-### C# / .NET
-
-**ASP.NET Core Web API:**
-```bash
-mkdir -p [codedir] && cd [codedir]
-# '--output .' damit kein Unterordner entsteht
-dotnet new webapi --output . --no-https false
-```
-
-**Blazor:**
-```bash
-mkdir -p [codedir] && cd [codedir]
-dotnet new blazor --output .
-```
-
-### Ruby
-
-**Rails:**
-```bash
-mkdir -p [codedir] && cd [codedir]
-# '.' als Ziel: kein Unterordner
-rails new . --database=postgresql --no-git
-```
-
-### Go
-
-```bash
-mkdir -p [codedir] && cd [codedir]
-go mod init [repo-name]
-# Gin:
-go get github.com/gin-gonic/gin
-```
+## Phase 5: Projekt scaffolden
 
-### Mobile
+`[codedir]` = bestätigtes Code-Verzeichnis (z.B. `projekt/`). Immer mit `.` als Scaffold-Ziel – kein Unterordner.
 
-**React Native (Expo):**
-```bash
-mkdir -p [codedir] && cd [codedir]
-npx create-expo-app@latest . --template blank-typescript
-```
+Wähle den passenden Abschnitt für den bestätigten Stack aus:
 
-**Flutter:**
 ```bash
-mkdir -p [codedir] && cd [codedir]
-flutter create .
+cat .claude/red-proto/SCAFFOLDING.md
 ```
 
-### Nicht gelisteter Stack
-
-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`.
+Führe die Befehle für `[gewähltes Framework]` aus. Danach zurück zu Phase 5b.
 
 ---
 

package/commands/red:proto-dev.md

@@ -166,26 +166,12 @@ git commit -q -m "feat: implement FEAT-[X] – [Feature Name]" && git push -q
 
 Schreibe `context/FEAT-[ID]-dev-handoff.md` (legt Kontext für `/red:proto-qa` in neuer Session):
 
-```markdown
-# Dev Handoff – FEAT-[ID]: [Feature Name]
-*[Datum]*
-
-## Was gebaut wurde
-- [Komponenten/Dateien mit kurzem Zweck]
-
-## Entscheidungen getroffen
-- [Wichtige Implementierungsentscheidungen und Begründungen]
-
-## DS-Abweichungen
-- [Tokens-Build oder Hypothesentest-Komponenten, falls vorhanden]
-
-## Offene Punkte
-- [Was nicht implementiert wurde und warum]
-
-## Für QA relevant
-- [Bekannte Edge Cases, Stolperstellen, was besonders getestet werden sollte]
+```bash
+cat .claude/red-proto/templates/dev-handoff.md
 ```
 
+Fülle alle Platzhalter mit konkreten Inhalten der Implementierung.
+
 ```bash
 mkdir -p context
 git add context/FEAT-[ID]-dev-handoff.md

package/commands/red:proto-flows.md

@@ -3,7 +3,7 @@ name: Flows
 description: Definiert übergreifende Nutzerreisen und exakte Screen Transitions – verbindliche Navigations-Referenz für alle Agents
 ---
 
-> Lies `docs/CONVENTIONS.md` für die verbindlichen Draft/Approval/Resume-Regeln.
+> Lies `.claude/red-proto/CONVENTIONS.md` für die verbindlichen Draft/Approval/Resume-Regeln.
 
 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.
 
@@ -215,7 +215,7 @@ AskUserQuestion({
       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: "Passt so – Flows sind vollständig", description: "Weiter zu /red:proto-ux für einzelne Features" },
         { label: "Änderungen nötig", description: "Feedback im Chat" }
       ],
       multiSelect: false
@@ -231,8 +231,6 @@ Nach Approval: `flows/product-flows.md` ist bereits als Draft gespeichert (Phase
 Nach `weiter` oder Korrekturen: `flows/product-flows.md` einlesen, Korrekturen übernehmen, `status: approved` setzen.
 
 ```bash
-echo "Ich committe jetzt:"
-echo "  → flows/product-flows.md – Screen-Inventar und Transitions finalisiert"
 git add flows/
 git commit -q -m "docs: product flows – screen inventory + transitions" && git push -q
 ```

package/commands/red:proto-qa.md

@@ -46,17 +46,8 @@ Agent("ux-reviewer", {
 
 Naming: `BUG-FEAT[X]-QA-[NNN].md` / `BUG-FEAT[X]-UX-[NNN].md`
 
-```markdown
-# BUG-FEAT[X]-[NNN]: [Kurztitel]
-- **Severity:** Critical | High | Medium | Low
-- **Bereich:** Functional | Security | A11y | Performance | UX
-- **Status:** Open
-
-## Steps to Reproduce
-1. ... 2. ... Expected: [...] Actual: [...]
-
-## Priority
-Fix now | Fix before release | Nice-to-have
+```bash
+cat .claude/red-proto/templates/bug-report.md
 ```
 
 Severity: Critical = Datenverlust/App unnutzbar, High = Kernfunktion kaputt, Medium = A11y/Flow-Bruch, Low = Optik/Edge-Case. Im Feature-File nur Bug-IDs referenzieren.