doctate/CLAUDE.md

Regeln

• Sprich im Chat deutsch mit mir.

• Gehe schritweise vor. Nummeriere die Schritte, damit ich mich darauf beziehen kann.

• Effizienz ist mir sehr wichtig. Wenn dir etwas auffällt, das die Performance negativ beeinflussen kann, dann weise mich darauf hin.

• CRITICAL: Im Code und den Kommentaren muss alles auf ENGLISCH sein.

• CRITICAL: Bevor du Code änderst, erkläre mir, warum du das machst und welche Konzepte du nutzt. Ich will was dazulernen. WARTE AUF MEINE FREIGABE, BEVOR DU CODE ÄNDERST.

• NOCHMAL: WARTE AUF MEIN OK, BEVOR DU CODE ÄNDERST ODER ERZEUGST! Führe alles schrittweise aus. Erkläre deine Schritte. Wenn es ein Problem gibt, dann FRAGE MICH. Beantworte deine Fragen nicht selber.

Rust

• Ich bevorzuge Rust, vor allem für Business-Logik. (Das heißt nicht, dass z.B. JS in HTML böse ist!)

• Halte dich and Best Practices und Rust-Style-Guidelines.

• Ich bin sehr erfahren mit Delphi und verstehe auch funktionale Sprachen. Rust ist neu für mich. Erkläre alles, was Rust von Delphi unterscheidet.

• Performance: Bevorzuge Rc<dyn Trait> + lokales downcast_ref gegenüber Deep Copies via Rc::new(obj.clone()).

• Vermeide lange Namespace-Ketten im Code (z.B. crate::ast::compiler::...). Nutze use Statements.

• Mach zu gegebener Zeit ein "cargo fmt"

• CRITICAL: "cargo clippy" hat immer Recht!

Bugs

• Bugs sind nur dann "Bugs", wenn es einen Integrations- oder Unit-Test gibt, der ihn bestätigt.
• Ein Bugfix macht den Test-Case grün.
• Tests sind immer direkte Unit-Tests, oder Integrationstests im tests-Ordner (KEIN SKRIPT IN EXAMPLES!)
• Ergo: JEDER BUGFIX BRAUCHT EINEN TEST-CASE.

Dokumentation

• Wir benutzen Markdown.
• Mermaid-Diagramme sind erlaubt, um Struktur zu dokumentieren. Z.B:

graph TD;
    A-->B;
    A-->C;
    B-->D;
    C-->D;