@the-bearded-bear/claude-craft 3.0.0

package/Dev/i18n/de/Common/commands/fix-bug-tdd.md

@@ -0,0 +1,383 @@
+---
+description: Bugfix im TDD/BDD-Modus
+argument-hint: [arguments]
+---
+
+# Bugfix im TDD/BDD-Modus
+
+Sie sind ein Senior-Entwickler mit Expertise in TDD (Test-Driven Development) und BDD (Behavior-Driven Development). Sie müssen einen Bug strikt nach der TDD/BDD-Methodologie beheben: Zuerst einen fehlschlagenden Test schreiben, der den Bug reproduziert, dann den Code beheben, damit der Test besteht.
+
+## Argumente
+$ARGUMENTS
+
+Argumente:
+- Bug-Beschreibung oder Ticket-Link
+- (Optional) Betroffene Datei oder Modul
+
+Beispiel: `/common:fix-bug-tdd "Benutzer kann sich nicht abmelden"` oder `/common:fix-bug-tdd #123`
+
+## MISSION
+
+### TDD/BDD-Philosophie
+
+```
+ROT → GRÜN → REFACTOR
+
+1. ROT    : Fehlschlagenden Test schreiben (Bug reproduzieren)
+2. GRÜN   : Minimalen Code schreiben, damit Test besteht
+3. REFACTOR : Code verbessern ohne Tests zu brechen
+```
+
+### Schritt 1: Bug verstehen
+
+#### Informationen sammeln
+- Präzise Beschreibung des aktuellen Verhaltens
+- Erwartetes Verhalten
+- Reproduktionsschritte
+- Betroffene Umgebung
+- Verfügbare Logs/Stack Traces
+
+#### Zu stellende Fragen
+1. Was ist das aktuelle Verhalten?
+2. Was sollte das korrekte Verhalten sein?
+3. Wann wurde der Bug eingeführt? (git bisect falls notwendig)
+4. Was sind die Edge Cases?
+5. Gibt es bestehende Tests, die diesen Bug hätten erkennen sollen?
+
+### Schritt 2: ROT - Fehlschlagenden Test schreiben
+
+#### BDD-Format (Gherkin-Stil)
+
+```gherkin
+Feature: [Betroffene Funktion]
+  Als [Benutzertyp]
+  Möchte ich [Aktion]
+  Um [Nutzen]
+
+  Szenario: [Bug-Fall-Beschreibung]
+    Gegeben sei [Kontext/Ausgangszustand]
+    Wenn [Aktion, die Bug auslöst]
+    Dann [erwartetes Verhalten, das aktuell nicht eintritt]
+```
+
+#### Unit Test
+
+```python
+# Python - pytest
+class TestBugFix:
+    """
+    Bug: [Kurzbeschreibung]
+    Ticket: #XXX
+
+    Aktuelles Verhalten: [was passiert]
+    Erwartetes Verhalten: [was passieren sollte]
+    """
+
+    def test_should_[erwartetes_verhalten]_when_[bedingung](self):
+        # Arrange - Kontext vorbereiten
+        # ...
+
+        # Act - Aktion ausführen, die Bug verursacht
+        # ...
+
+        # Assert - Erwartetes Verhalten überprüfen
+        # Dieser Test MUSS vor dem Fix fehlschlagen
+        assert result == expected_value
+```
+
+```typescript
+// TypeScript - Jest
+describe('Bug #XXX: [Beschreibung]', () => {
+  /**
+   * Aktuelles Verhalten: [was passiert]
+   * Erwartetes Verhalten: [was passieren sollte]
+   */
+  it('should [erwartetes verhalten] when [bedingung]', () => {
+    // Arrange
+    const input = prepareTestData();
+
+    // Act
+    const result = functionUnderTest(input);
+
+    // Assert - Dieser Test MUSS vor dem Fix fehlschlagen
+    expect(result).toBe(expectedValue);
+  });
+});
+```
+
+```php
+// PHP - PHPUnit
+/**
+ * @testdox Bug #XXX: [Bug-Beschreibung]
+ */
+class BugFixTest extends TestCase
+{
+    /**
+     * Aktuelles Verhalten: [was passiert]
+     * Erwartetes Verhalten: [was passieren sollte]
+     *
+     * @test
+     */
+    public function it_should_expected_behavior_when_condition(): void
+    {
+        // Arrange
+        $input = $this->prepareTestData();
+
+        // Act
+        $result = $this->service->methodUnderTest($input);
+
+        // Assert - Dieser Test MUSS vor dem Fix fehlschlagen
+        $this->assertEquals($expectedValue, $result);
+    }
+}
+```
+
+```dart
+// Dart - Flutter test
+group('Bug #XXX: [Beschreibung]', () {
+  /// Aktuelles Verhalten: [was passiert]
+  /// Erwartetes Verhalten: [was passieren sollte]
+  test('should [erwartetes verhalten] when [bedingung]', () {
+    // Arrange
+    final input = prepareTestData();
+
+    // Act
+    final result = functionUnderTest(input);
+
+    // Assert - Dieser Test MUSS vor dem Fix fehlschlagen
+    expect(result, equals(expectedValue));
+  });
+});
+```
+
+### Schritt 3: Test-Fehlschlag überprüfen
+
+```bash
+# Spezifischen Test ausführen
+# Python
+pytest tests/test_bug_xxx.py -v
+
+# JavaScript/TypeScript
+npm test -- --testPathPattern="bug-xxx"
+
+# PHP
+./vendor/bin/phpunit --filter "it_should_expected_behavior"
+
+# Flutter
+flutter test test/bug_xxx_test.dart
+```
+
+**WICHTIG**: Der Test MUSS in diesem Stadium fehlschlagen. Falls der Test besteht, bedeutet das:
+- Der Test reproduziert den Bug nicht korrekt
+- Der Bug wurde bereits behoben
+- Der Test ist schlecht geschrieben
+
+### Schritt 4: GRÜN - Bug beheben (Minimaler Code)
+
+#### Prinzipien
+1. MINIMALEN Code schreiben, damit Test besteht
+2. Keine anderen Fälle antizipieren
+3. Noch nicht refactorn
+4. Code einfach halten
+
+#### Prozess
+1. Grundursache identifizieren
+2. Minimalen Fix implementieren
+3. Test erneut ausführen
+4. Sicherstellen, dass Test besteht
+
+```bash
+# Test nach Fix erneut ausführen
+# Der Test MUSS jetzt bestehen
+```
+
+### Schritt 5: Nicht-Regression überprüfen
+
+```bash
+# ALLE bestehenden Tests ausführen
+# Python
+pytest
+
+# JavaScript/TypeScript
+npm test
+
+# PHP
+./vendor/bin/phpunit
+
+# Flutter
+flutter test
+
+# ALLE Tests müssen bestehen
+```
+
+### Schritt 6: REFACTOR - Code verbessern
+
+#### Refactoring-Checkliste
+- [ ] Ist der Code lesbar?
+- [ ] Gibt es Duplikation?
+- [ ] Sind Namen aussagekräftig?
+- [ ] Tut die Funktion nur eine Sache?
+- [ ] Respektiert der Code Projektkonventionen?
+
+#### Nach jeder Änderung
+```bash
+# Tests nach jedem Refactoring erneut ausführen
+# Tests müssen immer bestehen
+```
+
+### Schritt 7: Ergänzende Tests hinzufügen
+
+#### Abzudeckende Edge Cases
+```python
+class TestBugFixEdgeCases:
+    """Ergänzende Tests für Edge Cases."""
+
+    def test_with_empty_input(self):
+        """Verhalten mit leerer Eingabe überprüfen."""
+        pass
+
+    def test_with_null_input(self):
+        """Verhalten mit null überprüfen."""
+        pass
+
+    def test_with_maximum_values(self):
+        """Verhalten an Grenzen überprüfen."""
+        pass
+
+    def test_with_special_characters(self):
+        """Verhalten mit Sonderzeichen überprüfen."""
+        pass
+```
+
+### Schritt 8: Dokumentation
+
+#### Kommentar im Test
+```python
+def test_logout_clears_session_bug_123(self):
+    """
+    Regressionstest für Bug #123.
+
+    Problem: Benutzersession wurde beim Logout nicht gelöscht, was
+             Zugriff auf geschützte Ressourcen nach Logout ermöglichte.
+
+    Grundursache: Session.destroy() wurde im Logout-Handler nicht aufgerufen.
+
+    Fix: Session.destroy()-Aufruf vor Redirect hinzugefügt.
+
+    Datum: 2024-01-15
+    Autor: developer@example.com
+    """
+```
+
+#### Commit-Nachricht
+```
+fix(auth): session beim logout löschen (#123)
+
+- Regressionstest für Logout-Bug hinzufügen
+- Session.destroy() im Logout-Handler aufrufen
+- Überprüfen, dass Session vor Redirect gelöscht wird
+
+Fixes #123
+```
+
+### Abschlussbericht
+
+```
+══════════════════════════════════════════════════════════════
+🐛 BUGFIX-BERICHT - TDD/BDD
+══════════════════════════════════════════════════════════════
+
+Ticket: #XXX
+Beschreibung: [Bug-Beschreibung]
+
+──────────────────────────────────────────────────────────────
+📋 ANALYSE
+──────────────────────────────────────────────────────────────
+
+Aktuelles Verhalten:
+[Was passierte]
+
+Erwartetes Verhalten:
+[Was passieren sollte]
+
+Grundursache:
+[Warum der Bug auftrat]
+
+──────────────────────────────────────────────────────────────
+🔴 TEST GESCHRIEBEN (ROT)
+──────────────────────────────────────────────────────────────
+
+Datei: tests/test_xxx.py
+Test: test_should_xxx_when_yyy
+
+```python
+def test_should_xxx_when_yyy(self):
+    # ... Test-Code
+```
+
+Erstes Ergebnis: ❌ FAIL
+Nachricht: AssertionError: expected X but got Y
+
+──────────────────────────────────────────────────────────────
+🟢 FIX (GRÜN)
+──────────────────────────────────────────────────────────────
+
+Geänderte Datei: src/module/file.py
+Zeilen: 45-52
+
+```python
+# Vorher
+def problematic_function():
+    # fehlerhafter Code
+
+# Nachher
+def problematic_function():
+    # korrigierter Code
+```
+
+Ergebnis nach Fix: ✅ PASS
+
+──────────────────────────────────────────────────────────────
+♻️ REFACTORING
+──────────────────────────────────────────────────────────────
+
+- [x] Code vereinfacht
+- [x] Variable zur Klarheit umbenannt
+- [x] Duplikation entfernt
+
+──────────────────────────────────────────────────────────────
+✅ TESTS
+──────────────────────────────────────────────────────────────
+
+| Test | Status |
+|------|--------|
+| test_should_xxx_when_yyy (neu) | ✅ |
+| test_existing_1 | ✅ |
+| test_existing_2 | ✅ |
+| ... | ✅ |
+
+Gesamt: XX Tests, 0 Fehler
+
+──────────────────────────────────────────────────────────────
+📝 COMMIT
+──────────────────────────────────────────────────────────────
+
+```
+fix(module): kurze beschreibung (#XXX)
+
+- Regressionstest hinzufügen
+- Grundursache beheben
+- Edge-Case-Tests hinzufügen
+
+Fixes #XXX
+```
+
+──────────────────────────────────────────────────────────────
+🎯 POST-FIX-AKTIONEN
+──────────────────────────────────────────────────────────────
+
+- [ ] PR erstellt
+- [ ] Code Review angefordert
+- [ ] Dokumentation aktualisiert
+- [ ] Ticket geschlossen
+```

package/Dev/i18n/de/Common/commands/full-audit.md

@@ -0,0 +1,191 @@
+---
+description: Vollständiges Multi-Technologie-Audit
+argument-hint: [arguments]
+---
+
+# Vollständiges Multi-Technologie-Audit
+
+Sie sind ein Code-Audit-Experte. Sie müssen ein vollständiges Compliance-Audit des Projekts durchführen, indem Sie vorhandene Technologien automatisch erkennen und entsprechende Regeln anwenden.
+
+## Argumente
+$ARGUMENTS
+
+Falls keine Argumente angegeben, alle Technologien automatisch erkennen.
+
+## MISSION
+
+### Schritt 1: Technologie-Erkennung
+
+Projekt scannen, um vorhandene Technologien zu identifizieren:
+
+| Datei | Technologie |
+|---------|-------------|
+| `composer.json` + `symfony/*` | Symfony |
+| `pubspec.yaml` + `flutter:` | Flutter |
+| `pyproject.toml` oder `requirements.txt` | Python |
+| `package.json` + `react` (ohne `react-native`) | React |
+| `package.json` + `react-native` | React Native |
+
+Für jede erkannte Technologie:
+1. Regeln aus `.claude/rules/` laden
+2. Spezifisches Audit anwenden
+
+### Schritt 2: Audit nach Technologie
+
+Für JEDE erkannte Technologie überprüfen:
+
+#### Architektur (25 Punkte)
+- [ ] Getrennte Schichten (Domain/Application/Infrastructure)
+- [ ] Nach innen gerichtete Abhängigkeiten (zur Domain)
+- [ ] Ordnerstruktur entspricht Konventionen
+- [ ] Keine Framework-Kopplung in Domain
+- [ ] Architektur-Patterns eingehalten
+
+#### Code-Qualität (25 Punkte)
+- [ ] Namensstandards eingehalten
+- [ ] Linting/Analyze ohne kritische Fehler
+- [ ] Type Hints/Annotations vorhanden
+- [ ] Öffentliche Klassen dokumentiert
+- [ ] Zyklomatische Komplexität < 10
+
+#### Testing (25 Punkte)
+- [ ] Coverage ≥ 80%
+- [ ] Unit Tests für Domain
+- [ ] Integrationstests vorhanden
+- [ ] E2E/Widget Tests für UI
+- [ ] Test-Pyramide eingehalten
+
+#### Sicherheit (25 Punkte)
+- [ ] Keine Secrets im Quellcode
+- [ ] Input-Validierung bei allen Eingaben
+- [ ] OWASP-Schutz (XSS, CSRF, Injection)
+- [ ] Sensible Daten verschlüsselt
+- [ ] Dependencies ohne bekannte Schwachstellen
+
+### Schritt 3: Tools ausführen
+
+```bash
+# Symfony
+docker compose exec php php bin/console lint:container
+docker compose exec php vendor/bin/phpstan analyse
+docker compose exec php vendor/bin/phpunit --coverage-text
+
+# Flutter
+docker run --rm -v $(pwd):/app -w /app dart dart analyze
+docker run --rm -v $(pwd):/app -w /app dart flutter test --coverage
+
+# Python
+docker compose exec app ruff check .
+docker compose exec app mypy .
+docker compose exec app pytest --cov
+
+# React/React Native
+docker compose exec node npm run lint
+docker compose exec node npm run test -- --coverage
+```
+
+### Schritt 4: Scores berechnen
+
+Für jede Technologie berechnen:
+- Architektur-Score: X/25
+- Code-Qualität-Score: X/25
+- Testing-Score: X/25
+- Sicherheits-Score: X/25
+- **Gesamt-Score: X/100**
+
+### Schritt 5: Bericht generieren
+
+```
+══════════════════════════════════════════════════════════════
+📊 MULTI-TECHNOLOGIE-AUDIT - Gesamt-Score: XX/100
+══════════════════════════════════════════════════════════════
+
+Erkannte Technologien: [Liste]
+Datum: YYYY-MM-DD
+
+──────────────────────────────────────────────────────────────
+🔷 SYMFONY - Score: XX/100
+──────────────────────────────────────────────────────────────
+
+🏗️ Architektur (XX/25)
+  ✅ Clean Architecture eingehalten
+  ✅ CQRS korrekt implementiert
+  ⚠️ 2 Services greifen direkt auf Repository zu
+
+📝 Code-Qualität (XX/25)
+  ✅ PHPStan Level 8 - 0 Fehler
+  ✅ PSR-12 Konventionen eingehalten
+  ⚠️ 5 Methoden > 20 Zeilen
+
+🧪 Testing (XX/25)
+  ✅ Coverage: 85%
+  ✅ Domain Unit Tests
+  ⚠️ Keine Panther E2E Tests
+
+🔒 Sicherheit (XX/25)
+  ✅ Keine Secrets im Code
+  ✅ CSRF aktiviert
+  ⚠️ Dependency mit geringfügigem CVE
+
+──────────────────────────────────────────────────────────────
+🔷 FLUTTER - Score: XX/100
+──────────────────────────────────────────────────────────────
+
+[Gleiche Struktur]
+
+══════════════════════════════════════════════════════════════
+📋 GLOBALE ZUSAMMENFASSUNG
+══════════════════════════════════════════════════════════════
+
+| Technologie | Architektur | Code | Tests | Sicherheit | Gesamt |
+|-------------|--------------|------|-------|----------|-------|
+| Symfony     | XX/25        | XX/25| XX/25 | XX/25    | XX/100|
+| Flutter     | XX/25        | XX/25| XX/25 | XX/25    | XX/100|
+| DURCHSCHNITT| XX/25        | XX/25| XX/25 | XX/25    | XX/100|
+
+══════════════════════════════════════════════════════════════
+🎯 TOP 5 PRIORITÄTS-AKTIONEN
+══════════════════════════════════════════════════════════════
+
+1. [KRITISCH] Aktion 1 Beschreibung
+   → Auswirkung: +X Punkte | Aufwand: Niedrig/Mittel/Hoch
+
+2. [HOCH] Aktion 2 Beschreibung
+   → Auswirkung: +X Punkte | Aufwand: Niedrig/Mittel/Hoch
+
+3. [MITTEL] Aktion 3 Beschreibung
+   → Auswirkung: +X Punkte | Aufwand: Niedrig/Mittel/Hoch
+
+4. [MITTEL] Aktion 4 Beschreibung
+   → Auswirkung: +X Punkte | Aufwand: Niedrig/Mittel/Hoch
+
+5. [NIEDRIG] Aktion 5 Beschreibung
+   → Auswirkung: +X Punkte | Aufwand: Niedrig/Mittel/Hoch
+```
+
+## Bewertungsregeln
+
+### Abzüge nach Kategorie
+
+| Verstoß | Verlorene Punkte |
+|-----------|---------------|
+| Architektur-Pattern verletzt | -5 |
+| Framework/Domain-Kopplung | -3 |
+| Kritischer Linting-Fehler | -2 |
+| Linting-Warnung | -1 |
+| Methode > 30 Zeilen | -1 |
+| Coverage < 80% | -5 |
+| Keine Domain Unit Tests | -5 |
+| Secret im Code | -10 |
+| Kritische CVE-Schwachstelle | -10 |
+| Hohe CVE-Schwachstelle | -5 |
+
+### Qualitäts-Schwellenwerte
+
+| Score | Bewertung |
+|-------|------------|
+| 90-100 | Ausgezeichnet |
+| 75-89 | Gut |
+| 60-74 | Akzeptabel |
+| 40-59 | Verbesserungsbedarf |
+| < 40 | Kritisch |