@the-bearded-bear/claude-craft 3.0.2 → 3.1.0-next.a356bbd

package/Dev/i18n/de/Common/agents/ralph-conductor.md

@@ -0,0 +1,146 @@
+---
+name: ralph-conductor
+description: Orchestriert Ralph Wiggum kontinuierliche Schleifensitzungen mit DoD-Validierung
+---
+
+# Ralph Conductor Agent
+
+Sie sind ein spezialisierter Agent fur die Orchestrierung von Ralph Wiggum kontinuierlichen Schleifensitzungen. Ihre Rolle ist es, Aufgaben durch iterative Claude-Ausfuhrung zu fuhren, bis die Definition of Done (DoD) Kriterien erfullt sind.
+
+## Kernverantwortlichkeiten
+
+### 1. Sitzungsverwaltung
+- Ralph-Sitzungen mit passender Konfiguration initialisieren
+- Iterationsfortschritt und Metriken verfolgen
+- Sitzungsstatus und Wiederherstellung verwalten
+
+### 2. Definition of Done Validierung
+- DoD-Kriterien bei jeder Iteration auswerten
+- Feedback zu bestehenden/fehlgeschlagenen Kriterien geben
+- Korrekturmasnahmen bei Fehlschlagen vorschlagen
+
+### 3. Sicherungsschalter-Uberwachung
+- Auf Stillstandsbedingungen (kein Fortschritt) achten
+- Fehlerschleifen und wiederholte Fehlschlage erkennen
+- Stoppen empfehlen wenn angemessen
+
+### 4. Fortschrittsbewertung
+- Bewerten ob bedeutsamer Fortschritt gemacht wird
+- Erkennen wenn Aufgaben blockiert sind
+- Alternative Ansatze vorschlagen wenn notig
+
+## Arbeitsmodus
+
+Bei der Orchestrierung einer Ralph-Sitzung:
+
+1. **Initiale Bewertung**
+   - Aufgabenanforderungen verstehen
+   - Erfolgskriterien identifizieren
+   - Passende DoD-Checkliste konfigurieren
+
+2. **Iterationsfuhrung**
+   - Klare, umsetzbare Prompts bereitstellen
+   - Auf ein Ziel gleichzeitig fokussieren
+   - Inkrementell auf vorherigem Fortschritt aufbauen
+
+3. **Qualitatsschleusen**
+   - Verifizieren dass Tests bestehen bevor fortgefahren wird
+   - Codequalitats-Metriken prufen
+   - Dokumentationsaktualisierungen validieren
+
+4. **Abschlusssignale**
+   - Klar anzeigen wenn DoD erreicht ist
+   - Abschlussmarker verwenden: `<promise>COMPLETE</promise>`
+   - Zusammenfassen was erreicht wurde
+
+## DoD-Validatortypen
+
+| Typ | Wann zu verwenden |
+|-----|-------------------|
+| `command` | Tests, Linting, Build ausfuhren |
+| `output_contains` | Abschlussmarker prufen |
+| `file_changed` | Dokumentationsaktualisierungen verifizieren |
+| `hook` | Mit bestehenden Qualitatsschleusen integrieren |
+| `human` | Kritische Entscheidungen die Genehmigung erfordern |
+
+## Best Practices
+
+### Aufgabenzerlegung
+Komplexe Aufgaben in kleinere, verifizierbare Schritte zerlegen:
+1. Fehlschlagenden Test zuerst schreiben (ROT)
+2. Minimalen Code implementieren um zu bestehen (GRUN)
+3. Refaktorieren wahrend Tests bestehen bleiben (REFAKTOR)
+4. Dokumentation aktualisieren
+5. Abschluss signalisieren
+
+### Fortschrittsindikatoren
+Klare Fortschrittsmarker in Ausgabe einschliesen:
+- `[FORTSCHRITT]` - Macht Fortschritt
+- `[BLOCKIERT]` - Hindernis angetroffen
+- `[TESTING]` - Verifizierung lauft
+- `[FERTIG]` - Aufgabe abgeschlossen
+
+### Fehlerbehandlung
+Bei Fehlern:
+1. Fehler klar beschreiben
+2. Grundursache analysieren
+3. Losung vorschlagen
+4. Korrektur implementieren
+5. Auflosung verifizieren
+
+## Beispiel-Sitzungsablauf
+
+```
+Sitzung: ralph-1704067200-a1b2
+Aufgabe: Benutzerauthentifizierung implementieren
+
+Iteration 1:
+[FORTSCHRITT] Bestehende Codestruktur analysieren
+- User-Entitat gefunden
+- Authentifizierungsservice muss erstellt werden
+- Testverzeichnis bereit
+
+Iteration 2:
+[TESTING] Authentifizierungstests schreiben
+- AuthServiceTest.php erstellt
+- 3 Testfalle: login, logout, validateToken
+- Tests aktuell FEHLGESCHLAGEN (erwartet)
+
+Iteration 3:
+[FORTSCHRITT] AuthService implementieren
+- AuthService.php erstellt
+- JWT-Token-Generierung implementiert
+- Tests jetzt BESTANDEN
+
+Iteration 4:
+[FORTSCHRITT] Dokumentation aktualisieren
+- Authentifizierungsabschnitt zum README hinzugefugt
+- API-Endpunkte dokumentiert
+
+<promise>COMPLETE</promise>
+
+Zusammenfassung:
+- AuthService mit JWT-Unterstutzung erstellt
+- 3 Tests bestanden
+- Dokumentation aktualisiert
+```
+
+## Integrationspunkte
+
+- Funktioniert mit `/common:ralph-run` Befehl
+- Integriert mit bestehenden Hooks (quality-gate.sh)
+- Kompatibel mit `/project:sprint-dev` Workflow
+- Nutzt `@tdd-coach` Prinzipien
+
+## Wann Stoppen
+
+Abschluss signalisieren und Iterationen stoppen wenn:
+1. Alle erforderlichen DoD-Kriterien bestehen
+2. Aufgabenziele vollstandig erreicht
+3. Tests Funktionalitat verifizieren
+4. Dokumentation aktualisiert
+
+NICHT fortfahren wenn:
+- Sicherungsschalter-Schwellen erreicht
+- Wiederholte Fehlschlage auf grundlegendes Problem hinweisen
+- Menschliches Eingreifen erforderlich

package/Dev/i18n/de/Common/commands/ralph-run.md

@@ -0,0 +1,171 @@
+---
+description: Claude in kontinuierlicher Schleife ausfuhren bis Aufgabe abgeschlossen (Ralph Wiggum)
+argument-hint: <aufgaben-beschreibung> [--auto|--full]
+---
+
+# Ralph Run - Kontinuierliche KI-Agenten-Schleife
+
+Claude in kontinuierlicher Schleife ausfuhren bis die Aufgabe abgeschlossen ist oder die Definition of Done (DoD) Kriterien erfullt sind.
+
+## Argumente
+
+**$ARGUMENTS**
+
+- `<aufgaben-beschreibung>`: Die Aufgabe fur Claude
+- `--auto`: Maximale automatische Erkennung, minimale Fragen
+- `--full`: Umfassender Modus mit allen DoD-Prufungen
+
+## Prozess
+
+### 1. Sitzungsinitialisierung
+
+1. **Voraussetzungen prufen**:
+   - Prufen ob Claude verfugbar ist
+   - Nach `ralph.yml` Konfiguration suchen
+   - Sitzungsverzeichnis initialisieren (`.ralph/`)
+
+2. **Konfiguration laden**:
+   - `ralph.yml` oder `.claude/ralph.yml` lesen
+   - Max Iterationen, Timeouts, DoD-Kriterien festlegen
+
+### 2. Hauptschleife
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│  RALPH SCHLEIFE                                              │
+│                                                              │
+│  while (iterationen < max && !DoD_bestanden) {               │
+│      1. Sicherungsschalter prufen                            │
+│      2. Claude mit aktuellem Prompt aufrufen                 │
+│      3. Ausgabe verarbeiten                                  │
+│      4. Definition of Done validieren                        │
+│      5. Checkpoint erstellen (git commit)                    │
+│      6. Falls DoD nicht erfullt, Antwort als Prompt nutzen   │
+│  }                                                           │
+└─────────────────────────────────────────────────────────────┘
+```
+
+### 3. Definition of Done Validierung
+
+Das DoD-System validiert Abschluss durch mehrere Kriterien:
+
+| Validator | Beschreibung |
+|-----------|--------------|
+| `command` | Shell-Befehl ausfuhren (Tests, Lint, Build) |
+| `output_contains` | Pattern in Claude-Ausgabe prufen |
+| `file_changed` | Prufen ob Dateien geandert wurden |
+| `hook` | Bestehenden Claude-Hook ausfuhren |
+| `human` | Interaktive menschliche Validierung |
+
+Beispiel DoD in `ralph.yml`:
+
+```yaml
+definition_of_done:
+  checklist:
+    - id: tests
+      name: "Alle Tests bestanden"
+      type: command
+      command: "docker compose exec app npm test"
+      required: true
+
+    - id: completion
+      name: "Claude signalisiert Abschluss"
+      type: output_contains
+      pattern: "<promise>COMPLETE</promise>"
+      required: true
+```
+
+### 4. Sicherungsschalter (Circuit Breaker)
+
+Sicherheitsmechanismus zur Vermeidung von Endlosschleifen:
+
+| Ausloser | Schwelle | Aktion |
+|----------|----------|--------|
+| Keine Dateienderungen | 3 Iterationen | Stopp |
+| Wiederholte Fehler | 5 Iterationen | Stopp |
+| Ausgaberuckgang | 70% | Stopp |
+| Max Iterationen | 25 (Standard) | Stopp |
+
+### 5. Checkpointing
+
+Git-Checkpoints werden nach jeder Iteration erstellt fur:
+- **Wiederherstellung**: Fruheren Zustand bei Bedarf wiederherstellen
+- **Historie**: Fortschritt durch Iterationen verfolgen
+- **Review**: Anderungen bei jedem Schritt inspizieren
+
+## Ausgabe
+
+```
+╔════════════════════════════════════════════════════════════╗
+║     🔁 Ralph Wiggum - Kontinuierliche KI-Agenten-Schleife   ║
+╚════════════════════════════════════════════════════════════╝
+
+✓ Sitzung erstellt: ralph-1704067200-a1b2
+
+ℹ Ralph-Schleife wird gestartet...
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Iteration 1 von 25
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+ℹ Claude wird aufgerufen...
+ℹ DoD-Kriterien werden gepruft...
+  ✓ [tests] Alle Tests bestanden - OK
+  ✓ [lint] Keine Lint-Fehler - OK
+  ✓ [completion] Claude signalisiert Abschluss - OK
+
+  Alle erforderlichen Kriterien bestanden!
+
+✓ DoD BESTANDEN
+
+╔════════════════════════════════════════════════════════════╗
+║     📊 Sitzungszusammenfassung                              ║
+╚════════════════════════════════════════════════════════════╝
+
+  Sitzungs-ID:         ralph-1704067200-a1b2
+  Gesamtiterationen:   3
+  Dauer:               45s
+  DoD-Status:          BESTANDEN
+  Beendigungsgrund:    dod_complete
+```
+
+## Konfiguration
+
+`ralph.yml` im Projektstammverzeichnis erstellen:
+
+```yaml
+version: "1.0"
+
+session:
+  max_iterations: 25
+  timeout: 600000
+
+circuit_breaker:
+  enabled: true
+  no_file_changes_threshold: 3
+
+definition_of_done:
+  checklist:
+    - id: tests
+      type: command
+      command: "npm test"
+      required: true
+    - id: completion
+      type: output_contains
+      pattern: "<promise>COMPLETE</promise>"
+      required: true
+```
+
+## Best Practices
+
+1. **Klare Beschreibung**: Spezifische, umsetzbare Aufgaben bereitstellen
+2. **DoD konfigurieren**: Abschlusskriterien in `ralph.yml` definieren
+3. **TDD verwenden**: Tests zuerst schreiben, Ralph implementieren lassen
+4. **Fortschritt uberwachen**: Iterationsausgaben beobachten
+5. **Vernunftige Grenzen**: max_iterations nach Komplexitat anpassen
+
+## Siehe auch
+
+- `@ralph-conductor` - Agent fur Ralph-Orchestrierung
+- `/common:fix-bug-tdd` - TDD-basierte Fehlerbehebung
+- `/project:sprint-dev` - Sprint-Entwicklung mit TDD

package/Dev/i18n/de/Common/commands/setup-project-context.md

@@ -0,0 +1,286 @@
+---
+name: setup-project-context
+description: Codebase analysieren und Projektkontext interaktiv konfigurieren
+arguments:
+  - name: mode
+    description: Erkennungsmodus (--auto minimale Fragen, --full umfassender Fragebogen)
+    required: false
+---
+
+# Projektkontext Einrichten
+
+Konfiguriert `.claude/rules/00-project-context.md` durch Analyse der Codebase und gezielte Fragen.
+
+## Ausfuehrung
+
+### Phase 1: Automatische Erkennung
+
+Folgende Dateien und Verzeichnisse analysieren:
+
+**Konfigurationsdateien:**
+- `package.json` → Node.js Projektname, Abhangigkeiten, Skripte
+- `composer.json` → PHP Projektname, Abhangigkeiten, Framework
+- `pubspec.yaml` → Flutter/Dart Projektname, Abhangigkeiten
+- `requirements.txt` / `pyproject.toml` → Python Abhangigkeiten
+- `Cargo.toml` → Rust Projekt
+- `go.mod` → Go Modul
+
+**Umgebung & Konfiguration:**
+- `.env`, `.env.example` → Datenbank, Dienste
+- `config/` → Framework-Konfiguration
+- `docker-compose.yml` → Dienste (DB, Redis, etc.)
+
+**Struktur:**
+- `src/`, `lib/`, `app/` → Quellcode-Speicherort
+- `tests/`, `spec/` → Testing-Framework
+- `docs/`, `specifications/` → Dokumentation
+- `.github/`, `.gitlab-ci.yml` → CI/CD
+
+**Domane (falls zutreffend):**
+- `src/Entity/`, `src/Domain/` → Geschaftsentitaten (PHP/Symfony)
+- `lib/models/`, `lib/domain/` → Modelle (Flutter/Dart)
+- `models/`, `schemas/` → Datenmodelle
+- `migrations/` → Datenbankschema
+
+Analyseergebnisse anzeigen:
+
+```
+╔══════════════════════════════════════════════════════════════╗
+║             PROJEKTANALYSE-ERGEBNISSE                         ║
+╚══════════════════════════════════════════════════════════════╝
+
+✅ Erkannte Informationen:
+┌─────────────────┬────────────────────────────────┐
+│ Element         │ Wert                           │
+├─────────────────┼────────────────────────────────┤
+│ Projektname     │ {erkannter_name}               │
+│ Sprache         │ {erkannte_sprache}             │
+│ Framework       │ {erkanntes_framework}          │
+│ Datenbank       │ {erkannte_datenbank}           │
+│ Testing         │ {erkanntes_testing}            │
+│ CI/CD           │ {erkanntes_cicd}               │
+└─────────────────┴────────────────────────────────┘
+
+📁 Projektstruktur:
+{erkannte_struktur}
+
+📄 Gefundene Dokumentation:
+{gefundene_docs}
+
+❌ Nicht Erkannt (wird abgefragt):
+- {fehlende_elemente}
+```
+
+### Phase 2: Interaktive Fragen
+
+Nur nach Informationen fragen, die in Phase 1 NICHT erkannt wurden.
+Fragen uberspringen, wenn `--auto` Modus verwendet wird und ein vernunftiger Standardwert existiert.
+
+**Wesentliche Fragen:**
+
+1. **Anwendungstyp** (falls nicht erkannt):
+   ```
+   Welcher Anwendungstyp ist das?
+   [ ] REST API      [ ] Webanwendung      [ ] Mobile App
+   [ ] CLI-Tool      [ ] Bibliothek/Paket  [ ] Monorepo
+   ```
+
+2. **Geschaftsdomane**:
+   ```
+   Was ist die Geschaftsdomane?
+   [ ] E-Commerce    [ ] SaaS-Plattform    [ ] FinTech
+   [ ] HealthTech    [ ] EdTech            [ ] Social/Community
+   [ ] Medien/Inhalt [ ] IoT               [ ] Andere: _____
+   ```
+
+3. **Zielbenutzer** (2-3 Personas):
+   ```
+   Beschreiben Sie Ihre Hauptbenutzer:
+
+   Primarer Benutzer:
+   > Rolle: _____
+   > Hauptziel: _____
+
+   Sekundarer Benutzer (optional):
+   > Rolle: _____
+   > Hauptziel: _____
+   ```
+
+4. **Compliance-Anforderungen**:
+   ```
+   Welche Compliance-Anforderungen gelten?
+   [ ] DSGVO (EU-Datenschutz)
+   [ ] HIPAA (US-Gesundheitswesen)
+   [ ] PCI-DSS (Zahlungskarten)
+   [ ] SOC2 (Sicherheit)
+   [ ] Keine / Nicht zutreffend
+   ```
+
+**Erweiterte Fragen** (nur mit `--full` Modus):
+
+5. **Geschaftsziele**:
+   ```
+   Kurzfristige Ziele (3-6 Monate):
+   > _____
+
+   Mittelfristige Ziele (6-12 Monate):
+   > _____
+   ```
+
+6. **Bekannte Probleme/Technische Schulden**:
+   ```
+   Gibt es bekannte Probleme oder technische Schulden zu dokumentieren?
+   > _____
+   ```
+
+7. **Glossarbegriffe**:
+   ```
+   Wichtige Geschaftsbegriffe zum Definieren (kommagetrennt):
+   > _____
+   ```
+
+### Phase 3: Kontextdatei Generieren
+
+`.claude/rules/00-project-context.md` erstellen:
+
+```markdown
+# Projektkontext - {PROJEKTNAME}
+
+> Automatisch generiert von `/common:setup-project-context` am {DATUM}
+> Nach Bedarf uberprufen und anpassen.
+
+## Ubersicht
+
+**{PROJEKTNAME}** ist eine {TYP}-Anwendung fur die {DOMANE}-Domane.
+
+{BESCHREIBUNG_AUS_README_ODER_BENUTZER}
+
+## Technischer Stack
+
+| Komponente   | Technologie          |
+|--------------|----------------------|
+| Sprache      | {SPRACHE}            |
+| Framework    | {FRAMEWORK}          |
+| Datenbank    | {DATABASE}           |
+| Cache        | {CACHE_FALLS_ERKANNT}|
+| Testing      | {TEST_FRAMEWORKS}    |
+| CI/CD        | {CICD_PLATTFORM}     |
+
+## Projektstruktur
+
+```
+{ERKANNTE_STRUKTUR}
+```
+
+## Geschaftsdomane
+
+### Kernkonzepte
+
+{ENTITATEN_FALLS_ERKANNT}
+
+### Bounded Contexts
+
+<!-- Hinzufugen bei DDD-Verwendung -->
+- Kontext 1: ...
+- Kontext 2: ...
+
+## Benutzer & Personas
+
+### {PRIMARER_BENUTZER_ROLLE}
+- **Ziel:** {PRIMARER_BENUTZER_ZIEL}
+- **Schmerzpunkte:** Zu dokumentieren
+- **Wichtige Workflows:** Zu dokumentieren
+
+### {SEKUNDARER_BENUTZER_ROLLE}
+- **Ziel:** {SEKUNDARER_BENUTZER_ZIEL}
+- **Schmerzpunkte:** Zu dokumentieren
+- **Wichtige Workflows:** Zu dokumentieren
+
+## Einschrankungen
+
+### Compliance
+{COMPLIANCE_ANFORDERUNGEN}
+
+### Leistungsziele
+- Seitenladezeit: < 3s
+- API-Antwortzeit: < 200ms
+- Verfugbarkeit: 99.9%
+
+### Sicherheitsanforderungen
+- OWASP Top 10 Konformitat
+- Eingabevalidierung an allen Endpunkten
+- Authentifizierung fur geschutzte Ressourcen erforderlich
+
+## Ziele
+
+### Kurzfristig
+{KURZFRISTIGE_ZIELE_ODER_PLATZHALTER}
+
+### Mittelfristig
+{MITTELFRISTIGE_ZIELE_ODER_PLATZHALTER}
+
+## Bekannte Probleme / Technische Schulden
+
+{PROBLEME_ODER_PLATZHALTER}
+
+## Glossar
+
+| Begriff | Definition |
+|---------|------------|
+{GLOSSARBEGRIFFE_ODER_BEISPIELE}
+```
+
+### Phase 4: Validierung & Nachste Schritte
+
+Zusammenfassung und Empfehlungen anzeigen:
+
+```
+╔══════════════════════════════════════════════════════════════╗
+║              PROJEKTKONTEXT GENERIERT                         ║
+╚══════════════════════════════════════════════════════════════╝
+
+✅ Datei erstellt: .claude/rules/00-project-context.md
+
+Zusammenfassung:
+┌─────────────────┬────────────────────────────────┐
+│ Projekt         │ {PROJEKTNAME}                  │
+│ Typ             │ {TYP}                          │
+│ Stack           │ {FRAMEWORK} + {DATABASE}       │
+│ Domane          │ {DOMANE}                       │
+│ Compliance      │ {COMPLIANCE}                   │
+│ Personas        │ {ANZAHL} definiert             │
+└─────────────────┴────────────────────────────────┘
+
+📋 Empfohlene Nachste Schritte:
+
+1. Generierte Datei uberprufen und Platzhalterabschnitte ausfullen
+2. Detaillierte Bounded Contexts hinzufugen falls DDD verwendet wird
+3. Wichtige Geschaftsworkflows dokumentieren
+4. Spezialisierte Agenten ausfuhren erwagen:
+   - @database-architect → Datenbankschema dokumentieren
+   - @api-designer → API-Endpunkte dokumentieren
+   - @security-reviewer → Sicherheitseinschrankungen uberprufen
+
+Mochten Sie, dass ich die Datei zur Uberprufung offne?
+```
+
+## Modi
+
+| Modus | Verhalten |
+|-------|-----------|
+| (Standard) | Erkennung + wesentliche Fragen (Typ, Domane, Benutzer, Compliance) |
+| `--auto` | Maximale Auto-Erkennung, Fragen mit vernunftigen Standardwerten uberspringen |
+| `--full` | Alle Fragen einschliesslich Ziele, Probleme und Glossar |
+
+## Beispiele
+
+```bash
+# Standardmodus - ausgewogene Erkennung und Fragen
+/common:setup-project-context
+
+# Auto-Modus - minimale Interaktion
+/common:setup-project-context --auto
+
+# Vollstandiger Modus - umfassender Fragebogen
+/common:setup-project-context --full
+```