karlsCORE KI-Gemeinschaft KI-Wissen Systemisch Denken Erstgespräch Anmelden
# Sauberer Code mit Claude Code: 16 Verträge mit 142 Regeln

Sauberer Code mit Claude Code:
14 Verträge mit 201 Regeln

Wie stellt man sicher, dass KI-generierter Code den eigenen Qualitätsstandards entspricht? Das Vertragssystem validiert jeden Code automatisch gegen 82 kritische Sicherheitsregeln und 119 weitere Qualitätsregeln. Problematischer Code wird blockiert, bevor er geschrieben wird.

Was ist das Vertragssystem?

Stell Dir vor, Du arbeitest mit einem brillanten Entwickler zusammen. Er schreibt Code schneller als jeder Mensch, kennt Dutzende Programmiersprachen und hat Zugriff auf das gesamte Wissen der Software-Entwicklung. Es gibt nur ein Problem: Manchmal schreibt er Code, der zwar funktioniert, aber gegen Eure internen Standards verstößt. Vielleicht eine Sicherheitslücke. Vielleicht ein Architektur-Pattern, das Ihr längst aufgegeben habt.

Das Vertragssystem löst dieses Problem. Es definiert Regeln, die jeder Code erfüllen muss, bevor er geschrieben wird. Nicht nachträglich. Nicht als Empfehlung. Sondern als harte Bedingung, die bei Verstoß den Schreibvorgang blockiert.

Die Grundidee ist einfach: Anstatt Code-Reviews durchzuführen und Fehler zu korrigieren, verhindern wir problematischen Code von vornherein. Das spart Zeit, reduziert Fehler und stellt sicher, dass niemand aus Versehen eine kritische Sicherheitslücke einführt.

Verträge und Regeln

Ein Vertrag ist eine thematische Sammlung von Regeln. Der PHP Security Contract enthält alle Regeln zur PHP-Sicherheit. Der SQL Security Contract alle Regeln zur Datenbank-Sicherheit. Der Code Quality Standards Contract Regeln zur allgemeinen Code-Qualität.

Jede Regel prüft ein spezifisches Pattern im Code:

  • Forbidden: Dieses Pattern darf nicht im Code vorkommen. Wird es gefunden, wird der Code blockiert.
  • Required: Dieses Pattern muss im Code vorkommen. Fehlt es, wird der Code blockiert.
  • Warning: Ein Hinweis ohne Blockierung. Der Code wird geschrieben, aber Claude erhält eine Warnung zur Kenntnisnahme.

Vier Schweregrade

Nicht jede Regelverletzung ist gleich kritisch. Deshalb gibt es vier Schweregrade:

  • Critical: Blockiert die Aktion. Der Code wird nicht geschrieben, bis das Problem behoben ist. Das sind typischerweise Sicherheitslücken.
  • Major: Warnung im System. Die Aktion wird ausgeführt, aber das Problem sollte beachtet werden. Das sind meist Architektur- oder Qualitätsprobleme.
  • Minor: Leichter Hinweis für Best Practices. Wird angezeigt, aber nicht hervorgehoben.
  • Info: Rein informativer Hinweis. Wird nur geloggt, keine Anzeige. Für optionale Empfehlungen wie "Tabellen könnten Suchfelder haben".

Warum funktioniert das?

Das System nutzt eine Eigenschaft von KI-Assistenten: Sie reagieren auf Feedback. Wenn Claude Code schreibt und dieser blockiert wird, erhält Claude eine detaillierte Fehlermeldung mit der betroffenen Zeile, der verletzten Regel und einem Vorschlag zur Behebung. Claude korrigiert den Code und versucht es erneut. Innerhalb einer Arbeitssitzung passt sich Claude an die Regeln an. Für sitzungsübergreifende Konsistenz werden die wichtigsten Regeln zusätzlich in der Projektkonfiguration hinterlegt, die Claude bei jedem Start liest.

Das Ergebnis: Sauberer Code von Anfang an, ohne manuelle Reviews.

Wichtiger Hinweis

Diese Seite zeigt echte Verträge und Regeln aus der Praxis. Sie dienen als Referenz und Inspiration. Für den Einsatz in eigenen Projekten müssen die Verträge und Regeln jedoch spezifisch angepasst werden: Andere Projekte haben andere Anforderungen, andere Architektur-Entscheidungen, andere Sicherheitsanforderungen. Was hier als kritisch eingestuft ist, kann in einem anderen Kontext irrelevant sein, und umgekehrt.

Wie funktioniert der Validierungsprozess?

Der Prozess ist dreistufig: Proaktive Guidance, reaktive Validierung und Nachverarbeitung. Alle Stufen laufen in wenigen Millisekunden ab, vollständig automatisch.

contract-system --three-stage-process 
┌─────────────────────────────────────────────────────────────────┐
│              DREISTUFIGER VALIDIERUNGSPROZESS                  │
└─────────────────────────────────────────────────────────────────┘

                         ┌─────────────┐
                         │    User     │
                         │   Prompt   │
                         └──────┬──────┘
                                │
                    "Erstelle eine SQL-Abfrage..."
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│           STUFE 1: PROAKTIVE GUIDANCE                          │
│           UserPromptSubmit + PreToolUse/Read Hooks              │
│                                                               │
│  A) Trigger-Keywords im Prompt:                              │
│     "SQL" → DB Security | "API" → API Contract | "CSS" → CSS │
│                                                               │
│  B) Beim Lesen von Code-Dateien:                             │
│     View/*.php    → VIEW-, FRB-, NAV- Rules                  │
│     Controller/*  → CQ-, ARCH- Rules                         │
│     Repository/*  → SQL-SEC-, DB- Rules                      │
│                                                               │
│  Zeigt häufig verletzte Rules aus Analytics (letzte 7 Tage)  │
└───────────────────────────────┬─────────────────────────────────┘
                                │
                    Claude schreibt Code...
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│           STUFE 2: REAKTIVE VALIDIERUNG                        │
│           PreToolUse Hook (Edit/Write)                         │
│                                                               │
│  Contract Validator:                                         │
│  • forbidden → Pattern darf NICHT vorkommen                 │
│  • required  → Pattern MUSS vorkommen                        │
│  • warning   → Hinweis ohne Blockierung                      │
│                                                               │
│  CRITICAL→BLOCK MAJOR→WARN MINOR→INFO INFO→LOG    │
└───────────────────────────────┬─────────────────────────────────┘
                                │
                ┌───────────────┴───────────────┐
                │                               │
                ▼                               ▼
          BLOCK                           PASS
          Code wird                        Code wird
          NICHT geschrieben                geschrieben
                │                               │
                │                               ▼
                │       ┌─────────────────────────────────────────────────────────────────┐
                │       │           STUFE 3: NACHVERARBEITUNG                        │
                │       │           PostToolUse Hook                                  │
                │       │                                                               │
                │       │  • code_analyzer      → Extrahiert Code-Entities          │
                │       │  • fix_permissions    → Setzt www-data Berechtigungen      │
                │       │  • quality_validator  → Nachträgliche Qualitätsprüfung     │
                │       │  • complexity_warning → Warnt bei hoher Komplexität        │
                │       │  • doku_reminder      → Erinnert an Doku-Updates           │
                │       └─────────────────────────────────────────────────────────────────┘
                │                               │
                └───────────────┬───────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                   FEEDBACK AN CLAUDE                           │
│  • Betroffene Zeile und Regel-ID                              │
│  • Beschreibung des Problems                                  │
│  • Vorschlag zur Behebung                                     │
│  • Hinweise aus Nachverarbeitung                              │
└─────────────────────────────────────────────────────────────────┘

Was passiert bei einem kritischen Verstoß?

Nehmen wir an, Claude generiert PHP-Code mit einem eval($userInput). Das ist eine bekannte Sicherheitslücke. Der Validator erkennt das Pattern, blockiert den Schreibvorgang und sendet eine Nachricht zurück:

contract-validator --violation 
BLOCKED by PHP-SEC-001 (critical)

Violation: eval() function detected
Line:      42
Pattern:   eval\s*\(
Fix:       Use json_decode() for data parsing,
           or a proper template engine for dynamic code.

The code was NOT written. Please fix and retry.

Claude erhält diese Information, korrigiert den Code automatisch und versucht es erneut. Innerhalb der Sitzung merkt sich Claude diese Korrekturen und vermeidet die gleichen Fehler.

Das Ergebnis

Sauberer, sicherer Code von Anfang an. Keine manuellen Reviews für bekannte Probleme. Die Regeln werden einmal definiert und dann bei jedem Schreibvorgang automatisch durchgesetzt.

Inhaltsverzeichnis

Grundlagen

Verträge und Regeln

Du kannst Dir die Aufzeichnung hier ansehen:

Als Mitglied der KI-Gemeinschaft kannst Du Dir die vollständige Aufzeichnung ansehen und auf alle 14 Verträge mit 201 Regeln zugreifen.

Zur KI-Gemeinschaft » oder Anmelden