claude-vault/knowledge/preferences.md

PERSÖNLICHE PRÄFERENZEN

TECH-STACKS

Frontend

• Framework: React, Next.js
• Styling: Tailwind CSS
• Language: TypeScript
• State: React Context, Zustand (bei Bedarf)

Backend

• Framework: Django 5.2+, Django REST Framework
• Language: Python 3.12+
• Task Queue: Celery mit Redis
• Optimization: PuLP, FICO Xpress

Database

• Production: PostgreSQL
• Development: SQLite
• Cache/Broker: Redis

Infrastructure

• Container: Docker (Multi-Stage Builds)
• Orchestration: K3s
• Monitoring: Prometheus, Loki, Grafana
• CI/CD: GitLab CI

---

CODING STYLE

Python / Django

• Type Hints: Immer verwenden (str | None statt Optional[str])
• Docstrings: Google-Style für öffentliche APIs
• Imports: Absolute Imports bevorzugen, gruppiert (stdlib, third-party, local)
• Line Length: 88 Zeichen (Black-Standard)
• String Quotes: Double Quotes für Strings
• F-Strings: Bevorzugt gegenüber .format() oder %

Django-spezifisch

• Views: Fat Models, Thin Views
• Queries: Immer select_related/prefetch_related für Relations
• Naming: Models singular (Match), related_name plural (matches)
• Managers: Custom Manager für häufige Queries

TypeScript / React

• Components: Functional Components mit Hooks
• Naming: PascalCase für Components, camelCase für Funktionen
• Props: Destructuring im Funktions-Signatur
• CSS: Tailwind Utility Classes, keine Custom CSS wenn vermeidbar

Allgemein

• Comments: Englisch im Code
• No Magic Numbers: Konstanten mit sprechenden Namen
• Error Messages: Hilfreich und kontextbezogen
• DRY: Duplikation erst ab 3. Vorkommen abstrahieren

---

WORKFLOW

Dokumentation

• Format: Markdown
• Sprache: Deutsch für Nutzer-Dokumentation, Englisch für Code-Docs
• Tool: MkDocs mit Material Theme

Git

• Commits: Konventionelle Commit-Messages (feat, fix, refactor, docs, test)
• Branches: feature/, fix/, refactor/ Prefixes
• PRs: Klare Beschreibung, Test-Plan, Reviewer zuweisen

Testing

• Unit Tests: pytest / Django TestCase
• Coverage: Minimum 80% für kritische Pfade
• Mocking: unittest.mock oder pytest-mock

Code Review

• Fokus: Security > Correctness > Performance > Style
• Feedback: Konstruktiv, mit Alternativen
• Blocking: Nur bei Security/Correctness Issues

---

ABNEIGUNGEN (Was ich NICHT will)

• Over-Engineering ohne konkreten Nutzen
• Premature Optimization
• Magic Imports (implizite Abhängigkeiten)
• Riesige Commit-Messages ohne Substanz
• any Types in TypeScript
• Undokumentierte Public APIs
• Tests ohne Assertions

---

Letzte Aktualisierung: 2026-02-04