@the-bearded-bear/claude-craft 3.0.0

package/Dev/i18n/de/Python/agents/python-reviewer.md

@@ -0,0 +1,118 @@
+---
+name: python-reviewer
+description: Python code review specialist
+---
+
+# Python Reviewer Agent
+
+Sie sind ein erfahrener Python-Entwickler und Code-Review-Experte. Ihre Mission ist es, umfassende Code-Reviews durchzuführen, die Clean Architecture-Prinzipien, SOLID und Python-Best-Practices folgen.
+
+## Kontext
+
+Beziehen Sie sich auf die Projektregeln:
+- `rules/01-workflow-analysis.md` - Analyse-Workflow
+- `rules/02-architecture.md` - Clean Architecture
+- `rules/03-coding-standards.md` - Codierungsstandards
+- `rules/04-solid-principles.md` - SOLID-Prinzipien
+- `rules/05-kiss-dry-yagni.md` - KISS, DRY, YAGNI
+- `rules/06-tooling.md` - Tools und Konfiguration
+- `rules/07-testing.md` - Teststrategie
+
+## Review-Checkliste
+
+### Architektur
+- [ ] Clean Architecture eingehalten (Domain/Application/Infrastructure)
+- [ ] Abhängigkeiten zeigen nach innen
+- [ ] Domain-Layer unabhängig
+- [ ] Protocols/Interfaces für Abstraktionen
+- [ ] Repository-Pattern korrekt implementiert
+
+### SOLID-Prinzipien
+- [ ] Single Responsibility - eine Klasse = ein Grund zur Änderung
+- [ ] Open/Closed - offen für Erweiterung, geschlossen für Änderung
+- [ ] Liskov Substitution - Subtypen sind substituierbar
+- [ ] Interface Segregation - kleine, spezifische Schnittstellen
+- [ ] Dependency Inversion - hängt von Abstraktionen ab
+
+### Code-Qualität
+- [ ] PEP 8-konform
+- [ ] Type Hints auf allen öffentlichen Funktionen
+- [ ] Google-Stil Docstrings
+- [ ] Klare, beschreibende Namen
+- [ ] KISS: einfache Funktionen < 20 Zeilen
+- [ ] DRY: keine Code-Duplikation
+- [ ] YAGNI: kein spekulativer Code
+
+### Testing
+- [ ] Tests für neuen Code geschrieben
+- [ ] Coverage > 80%
+- [ ] Unit-Tests isoliert mit Mocks
+- [ ] Integrationstests für Infrastructure
+- [ ] Randfälle getestet
+
+### Sicherheit
+- [ ] Keine fest codierten Geheimnisse
+- [ ] Eingabevalidierung mit Pydantic
+- [ ] Keine SQL-Injection (parametrisierte Abfragen)
+- [ ] Exceptions ordnungsgemäß behandelt
+- [ ] Keine sensiblen Daten in Logs
+
+### Performance
+- [ ] Keine N+1-Abfragen
+- [ ] Paginierung für große Listen
+- [ ] Geeignete Indizes
+- [ ] Async/await wenn zutreffend
+
+## Review-Format
+
+```markdown
+## Zusammenfassung
+[Gesamtbewertung des Codes]
+
+## Stärken
+- [Was gut gemacht ist]
+- [Beobachtete gute Praktiken]
+
+## Probleme
+
+### Kritisch
+- [ ] [Muss vor Merge behoben werden]
+
+### Wichtig
+- [ ] [Sollte behoben werden]
+
+### Geringfügig
+- [ ] [Nice to have]
+
+## Detaillierte Kommentare
+
+### Datei: pfad/zur/datei.py
+
+**Zeile X-Y**: [Kommentar]
+
+```python
+# Aktueller Code
+def bad_code():
+    pass
+
+# Verbesserungsvorschlag
+def improved_code():
+    pass
+```
+
+**Begründung**: [Erklärung, warum Änderung nötig ist]
+
+## Bewertung
+
+- Architektur: X/10
+- Code-Qualität: X/10
+- Testing: X/10
+- Sicherheit: X/10
+
+**Gesamt**: X/10
+
+## Empfehlung
+- [ ] Genehmigen
+- [ ] Änderungen anfordern
+- [ ] Ablehnen
+```

package/Dev/i18n/de/Python/checklists/new-feature.md

@@ -0,0 +1,148 @@
+# Checkliste: Neues Feature
+
+## Phase 1: Analyse (OBLIGATORISCH)
+
+### Bedarf verstehen
+
+- [ ] **Ziel** klar definiert
+  - Welche Funktionalität genau?
+  - Welches Problem wird gelöst?
+  - Was sind die Akzeptanzkriterien?
+
+- [ ] **Geschäftskontext** verstanden
+  - Welche Geschäftsauswirkung?
+  - Welche Benutzer betroffen?
+  - Spezifische Geschäftsbeschränkungen?
+
+- [ ] **Technische Einschränkungen** identifiziert
+  - Erforderliche Performance?
+  - Skalierbarkeit?
+  - Sicherheit?
+  - Kompatibilität?
+
+### Bestehenden Code erkunden
+
+- [ ] **Ähnliche Muster** identifiziert
+  ```bash
+  rg "class.*Service" --type py
+  rg "class.*Repository" --type py
+  ```
+
+- [ ] **Architektur** analysiert
+  ```bash
+  tree src/ -L 3 -I "__pycache__|*.pyc"
+  ```
+
+- [ ] **Projektstandards** verstanden
+  - Namenskonventionen
+  - Fehlerbehandlungsmuster
+  - Teststruktur
+
+### Auswirkungen identifizieren
+
+- [ ] **Impact-Matrix** erstellt
+  - Welche Module betroffen?
+  - Welche DB-Migrationen notwendig?
+  - Welche API-Änderungen?
+
+- [ ] **Abhängigkeiten** identifiziert
+  - Module, die von zu änderndem Code abhängen
+  - Module, von denen neuer Code abhängt
+
+### Lösung entwerfen
+
+- [ ] **Architektur** definiert
+  - Welcher Layer (Domain/Application/Infrastructure)?
+  - Welche Klassen/Funktionen zu erstellen?
+  - Welche Interfaces notwendig?
+
+- [ ] **Datenfluss** dokumentiert
+  - Wie fließen Daten?
+  - Welche Transformationen?
+
+- [ ] **Technische Entscheidungen** begründet
+  - Warum dieser Ansatz?
+  - Welche Alternativen erwogen?
+
+### Implementierung planen
+
+- [ ] **Aufgaben** in atomare Schritte zerlegt
+- [ ] **Reihenfolge** der Implementierung definiert
+- [ ] **Schätzung** mit Puffer durchgeführt (20%)
+
+### Risiken identifizieren
+
+- [ ] **Risiken** identifiziert und bewertet
+- [ ] **Mitigationen** geplant
+- [ ] **Fallbacks** definiert wenn möglich
+
+### Tests definieren
+
+- [ ] **Teststrategie** definiert
+  - Unit-Tests
+  - Integrationstests
+  - E2E-Tests
+- [ ] **Ziel-Coverage** definiert
+
+Siehe `rules/01-workflow-analysis.md` für Details.
+
+## Phase 2: Implementierung
+
+### Domain-Layer (Falls zutreffend)
+
+- [ ] **Entities** erstellt
+  - [ ] Dataclass oder Python-Klasse
+  - [ ] Validierung in `__post_init__`
+  - [ ] Geschäftsmethoden
+  - [ ] Gleichheit basierend auf ID
+  - [ ] Vollständige Docstrings
+
+- [ ] **Value Objects** erstellt
+  - [ ] `frozen=True` (unveränderlich)
+  - [ ] Strenge Validierung
+  - [ ] Wertbasierte Gleichheit
+
+- [ ] **Domain-Services** erstellt (falls erforderlich)
+  - [ ] Multi-Entitäts-Geschäftslogik
+  - [ ] Injizierte Abhängigkeiten
+  - [ ] Keine Infrastructure-Abhängigkeit
+
+- [ ] **Repository-Interfaces** erstellt
+  - [ ] Protocol in domain/repositories/
+  - [ ] Dokumentierte Methoden
+
+- [ ] **Domain-Exceptions** erstellt
+  - [ ] Von DomainException erben
+  - [ ] Klare Meldungen
+
+[... Rest der Phasen folgen dem gleichen Muster ...]
+
+## Quick-Checkliste
+
+### Mindestens erforderlich
+
+- [ ] Vollständige Analyse durchgeführt
+- [ ] Clean Architecture (Clean + SOLID)
+- [ ] Tests geschrieben und bestanden (> 80% Coverage)
+- [ ] `make quality` läuft durch
+- [ ] Dokumentation aktualisiert
+- [ ] Vollständige PR-Beschreibung
+
+### Vor Merge
+
+- [ ] Genehmigte Review
+- [ ] CI läuft durch
+- [ ] Keine Konflikte
+- [ ] Commits squashen falls erforderlich
+
+### Warnsignale
+
+Wenn eines davon zutrifft, **NICHT MERGEN**:
+
+- ❌ Analyse nicht durchgeführt
+- ❌ Fehlende Tests
+- ❌ Coverage < 80%
+- ❌ Linting/Type-Fehler
+- ❌ Fest codierte Geheimnisse
+- ❌ Undokumentierte Breaking Changes
+- ❌ Ungetestete DB-Migration

package/Dev/i18n/de/Python/checklists/pre-commit.md

@@ -0,0 +1,358 @@
+# Pre-Commit-Checkliste
+
+## Vor jedem Commit
+
+### 1. Code-Qualität
+
+- [ ] **Linting** - Code folgt Standards
+  ```bash
+  make lint
+  # oder
+  ruff check src/ tests/
+  ```
+
+- [ ] **Formatierung** - Code ordnungsgemäß formatiert
+  ```bash
+  make format-check
+  # oder
+  black --check src/ tests/
+  isort --check src/ tests/
+  ```
+
+- [ ] **Typ-Checking** - Keine Typ-Fehler
+  ```bash
+  make type-check
+  # oder
+  mypy src/
+  ```
+
+- [ ] **Sicherheit** - Keine offensichtlichen Schwachstellen
+  ```bash
+  make security-check
+  # oder
+  bandit -r src/ -ll
+  ```
+
+### 2. Tests
+
+- [ ] **Alle Tests bestehen**
+  ```bash
+  make test
+  # oder
+  pytest tests/
+  ```
+
+- [ ] **Neue Tests geschrieben** für neuen Code
+  - [ ] Unit-Tests für neue Logik
+  - [ ] Integrationstests falls erforderlich
+  - [ ] E2E-Tests falls kritischer Ablauf
+
+- [ ] **Coverage beibehalten** (> 80%)
+  ```bash
+  make test-cov
+  # oder
+  pytest --cov=src --cov-report=term
+  ```
+
+- [ ] **Relevante Tests** für behobene Bugs
+  - [ ] Test reproduziert Bug (sollte vor Fix fehlschlagen)
+  - [ ] Test läuft nach Fix durch
+
+### 3. Code-Standards
+
+- [ ] **PEP 8** eingehalten
+  - [ ] Max. Zeile 88 Zeichen
+  - [ ] Imports organisiert (stdlib, third-party, lokal)
+  - [ ] Keine abschließenden Leerzeichen
+
+- [ ] **Type Hints** auf allen öffentlichen Funktionen
+  ```python
+  def my_function(param: str) -> int:
+      """Docstring."""
+      pass
+  ```
+
+- [ ] **Docstrings** Google-Stil
+  ```python
+  def function(arg1: str, arg2: int) -> bool:
+      """
+      Zusammenfassungszeile.
+
+      Args:
+          arg1: Beschreibung
+          arg2: Beschreibung
+
+      Returns:
+          Beschreibung
+
+      Raises:
+          ValueError: Wenn Bedingung
+      """
+      pass
+  ```
+
+- [ ] **Namenskonventionen**
+  - [ ] Klassen: PascalCase
+  - [ ] Funktionen/Variablen: snake_case
+  - [ ] Konstanten: UPPER_CASE
+  - [ ] Privat: _vorangestellt
+
+### 4. Architektur
+
+- [ ] **Clean Architecture** eingehalten
+  - [ ] Domain hängt von nichts ab
+  - [ ] Abhängigkeiten zeigen nach innen
+  - [ ] Protocols für Abstraktionen
+
+- [ ] **SOLID** angewendet
+  - [ ] Single Responsibility
+  - [ ] Open/Closed
+  - [ ] Liskov Substitution
+  - [ ] Interface Segregation
+  - [ ] Dependency Inversion
+
+- [ ] **KISS, DRY, YAGNI**
+  - [ ] Einfache Lösung
+  - [ ] Keine Duplikation
+  - [ ] Kein unnötiger Code
+
+### 5. Sicherheit
+
+- [ ] **Keine Geheimnisse** fest im Code codiert
+  - [ ] Keine Passwörter
+  - [ ] Keine API-Schlüssel
+  - [ ] Keine Token
+
+- [ ] **Umgebungsvariablen**
+  - [ ] Zu `.env.example` hinzugefügt falls neu
+  - [ ] In README dokumentiert falls erforderlich
+
+- [ ] **Eingabevalidierung**
+  - [ ] Alle Eingaben validiert (Pydantic)
+  - [ ] Keine SQL-Injection (parametrisierte Abfragen)
+  - [ ] Keine XSS-Injection
+
+- [ ] **Sensible Daten**
+  - [ ] Passwörter gehasht (bcrypt)
+  - [ ] PII geschützt
+  - [ ] Logs enthalten keine sensiblen Daten
+
+### 6. Datenbank
+
+- [ ] **Migration** erstellt falls Schema-Änderung
+  ```bash
+  make db-migrate msg="Beschreibung"
+  # oder
+  alembic revision --autogenerate -m "Beschreibung"
+  ```
+
+- [ ] **Migration getestet**
+  - [ ] Upgrade funktioniert
+  - [ ] Downgrade funktioniert
+  - [ ] Kein Datenverlust
+
+- [ ] **Indizes** hinzugefügt falls erforderlich
+  - [ ] Auf häufig durchsuchten Spalten
+  - [ ] Auf Fremdschlüsseln
+
+### 7. Performance
+
+- [ ] **N+1-Abfragen** vermieden
+  - [ ] Verwendung von joinedload/selectinload falls erforderlich
+  - [ ] Keine Abfragen in Schleifen
+
+- [ ] **Paginierung** für große Listen
+  - [ ] Limit/Offset implementiert
+  - [ ] Keine Tausende von Elementen laden
+
+- [ ] **Caching** falls angebracht
+  - [ ] Cache für häufig abgerufene Daten
+  - [ ] Cache-Invalidierung verwaltet
+
+### 8. Logging & Monitoring
+
+- [ ] **Angemessenes Logging**
+  - [ ] Korrektes Level (DEBUG, INFO, WARNING, ERROR)
+  - [ ] Klare und informative Meldungen
+  - [ ] Kontext hinzugefügt (user_id, request_id, etc.)
+
+- [ ] **Kein print()** - Logger verwenden
+  ```python
+  # ❌ Schlecht
+  print(f"Benutzer {user_id} erstellt")
+
+  # ✅ Gut
+  logger.info(f"Benutzer erstellt", extra={"user_id": user_id})
+  ```
+
+- [ ] **Exceptions protokolliert**
+  ```python
+  try:
+      risky_operation()
+  except Exception as e:
+      logger.error(f"Operation fehlgeschlagen: {e}", exc_info=True)
+      raise
+  ```
+
+### 9. Dokumentation
+
+- [ ] **Code-Kommentare** für komplexe Logik
+  - [ ] Keine offensichtlichen Kommentare
+  - [ ] Erklärung des "Warum", nicht "Was"
+
+- [ ] **README** aktualisiert falls erforderlich
+  - [ ] Neue Features dokumentiert
+  - [ ] Setup-Anweisungen aktuell
+  - [ ] Umgebungsvariablen dokumentiert
+
+- [ ] **API-Docs** aktuell
+  - [ ] Neue Endpoints dokumentiert
+  - [ ] Beispiele bereitgestellt
+  - [ ] Fehler dokumentiert
+
+### 10. Git
+
+- [ ] **Commit-Message** folgt Conventional Commits
+  ```
+  type(scope): subject
+
+  body
+
+  footer
+  ```
+  - Typen: feat, fix, docs, style, refactor, test, chore
+  - Subject: imperativ, Kleinbuchstaben, kein Punkt
+  - Body: optional, Änderungsdetails
+  - Footer: Breaking Changes, schließt Issues
+
+- [ ] **Atomarer Commit**
+  - [ ] Ein Commit = eine logische Änderung
+  - [ ] Keine riesigen Commits
+  - [ ] Keine "WIP"- oder "fix"-Commits
+
+- [ ] **Temporäre Dateien** nicht enthalten
+  - [ ] Keine .pyc, __pycache__
+  - [ ] Keine .env (nur .env.example)
+  - [ ] Keine IDE-Dateien
+
+### 11. Abhängigkeiten
+
+- [ ] **Neue Abhängigkeiten** begründet
+  - [ ] Wirklich notwendig?
+  - [ ] Keine Alternative in bestehenden Deps?
+  - [ ] Gewartete und sichere Bibliothek?
+
+- [ ] **Lock-Datei** aktualisiert
+  ```bash
+  poetry lock
+  # oder
+  uv lock
+  ```
+
+- [ ] **Version korrekt gepinnt**
+  - [ ] Nicht zu breite Versionen (`*`)
+  - [ ] Kompatibel mit anderen Deps
+
+### 12. Aufräumen
+
+- [ ] **Toter Code** entfernt
+  - [ ] Kein auskommentierter Code
+  - [ ] Keine ungenutzten Funktionen
+  - [ ] Keine ungenutzten Imports
+
+- [ ] **Debug-Code** entfernt
+  - [ ] Kein breakpoint()
+  - [ ] Keine Debug-Prints
+  - [ ] Keine TODO/FIXME (oder Issue erstellen)
+
+- [ ] **Konsolen-Logs** entfernt
+  - [ ] Keine Debug-print()
+  - [ ] Geeignete Logs verwendet
+
+## Quick-Check-Befehl
+
+```bash
+# Einzeiler zum Prüfen von allem
+make quality && make test-cov
+```
+
+## Pre-Commit-Hook
+
+Zur Automatisierung Pre-Commit-Hooks verwenden:
+
+```bash
+# .pre-commit-config.yaml bereits konfiguriert
+pre-commit install
+
+# Manuell ausführen
+pre-commit run --all-files
+```
+
+## Wenn etwas fehlschlägt
+
+### Linting-Fehler
+
+```bash
+# Auto-Fix für Behebbare
+make lint-fix
+# oder
+ruff check --fix src/ tests/
+```
+
+### Formatierungsfehler
+
+```bash
+# Auto-Format
+make format
+# oder
+black src/ tests/
+isort src/ tests/
+```
+
+### Fehlschlagende Tests
+
+```bash
+# Tests im Verbose-Modus zum Debuggen ausführen
+pytest -vv tests/
+
+# Spezifischen Test ausführen
+pytest tests/path/to/test.py::test_function -vv
+
+# stdout/stderr anzeigen
+pytest -s tests/
+```
+
+### Typ-Fehler
+
+```bash
+# Detaillierte Fehler anzeigen
+mypy src/ --show-error-codes
+
+# Temporär ignorieren (vermeiden!)
+# type: ignore[error-code]
+```
+
+## Ausnahmen
+
+### Dringender Hotfix
+
+Wenn dringender Produktions-Hotfix:
+- [ ] Mindest-Tests laufen durch
+- [ ] Fix manuell verifiziert
+- [ ] PR sofort danach erstellt
+- [ ] TODO erstellt zur Verbesserung der Tests
+
+### WIP-Commit
+
+Wenn wirklich notwendig (vermeiden):
+- [ ] Commit in separatem Branch
+- [ ] Mit `WIP:` vorangestellt
+- [ ] Vor Merge zu main squashen
+
+## Quick-Checkliste (Minimum)
+
+- [ ] `make lint` ✅
+- [ ] `make type-check` ✅
+- [ ] `make test` ✅
+- [ ] Gültige Commit-Message ✅
+- [ ] Keine Geheimnisse ✅

package/Dev/i18n/de/Python/commands/async-check.md

@@ -0,0 +1,84 @@
+---
+description: Python Async-Prüfung
+argument-hint: [arguments]
+---
+
+# Python Async-Prüfung
+
+## Argumente
+
+$ARGUMENTS (optional: Pfad zur Analyse)
+
+## MISSION
+
+Analysieren Sie die Verwendung von asynchronem Code im Python-Projekt und identifizieren Sie Probleme mit async/await-Mustern, blockierenden Aufrufen und Leistungsproblemen.
+
+### Schritt 1: Async-Funktionen identifizieren
+
+```bash
+# Alle async-Funktionen finden
+rg "async def" --type py
+
+# await-Verwendung finden
+rg "await " --type py
+```
+
+Prüfen Sie:
+- [ ] Async-Funktionen ordnungsgemäß deklariert
+- [ ] Await für async-Aufrufe verwendet
+- [ ] Kein blockierender Code in async-Funktionen
+- [ ] Ordnungsgemäße Exception-Behandlung in async
+
+### Schritt 2: Blockierende Aufrufe erkennen
+
+```python
+# Häufige blockierende Aufrufe, die in async vermieden werden sollten:
+- time.sleep()        # asyncio.sleep() verwenden
+- requests.get()      # httpx oder aiohttp verwenden
+- open()              # aiofiles verwenden
+- db.execute()        # Async-DB-Treiber verwenden
+```
+
+### Schritt 3: Async-Muster prüfen
+
+```python
+# Gute Muster
+async def fetch_data(url: str) -> dict:
+    async with httpx.AsyncClient() as client:
+        response = await client.get(url)
+        return response.json()
+
+# Prüfen Sie:
+- [ ] async with für Context Manager
+- [ ] await für async-Operationen
+- [ ] asyncio.gather() für gleichzeitige Aufgaben
+- [ ] Ordnungsgemäße Fehlerbehandlung mit try/except
+```
+
+### Schritt 4: Bericht generieren
+
+```
+ASYNC-CODE-ANALYSE
+=====================================
+
+ASYNC-FUNKTIONEN: XX
+AWAIT-ANWEISUNGEN: XX
+BLOCKIERENDE AUFRUFE GEFUNDEN: XX
+
+ERKANNTE PROBLEME:
+
+1. Blockierender Aufruf in async-Funktion
+   Datei: app/services/user.py:45
+   Problem: time.sleep() statt asyncio.sleep() verwendet
+   Behebung: Durch asyncio.sleep() ersetzen
+
+2. Fehlendes await
+   Datei: app/api/endpoints.py:78
+   Problem: Async-Funktion ohne await aufgerufen
+   Behebung: await-Schlüsselwort hinzufügen
+
+EMPFEHLUNGEN:
+- Blockierende Aufrufe durch async-Alternativen ersetzen
+- asyncio.gather() für gleichzeitige Operationen verwenden
+- Ordnungsgemäße Timeout-Behandlung hinzufügen
+```