doctate/CLAUDE.md

Regeln

• 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.

• 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!

Java

• Java Home ist in /opt/android-studio/jbr

HTML

• Innerhalb von HTML-Seiten sind JS-Einbettungen ausdrücklich erlaubt und gewünscht, wenn sie für den modernen Look-And-Feel der Webseite erforderlich sind.
• Wäge beim Website-Design immer ab, ob sich JS lohnt und schlage es ggfs. als Alternative zu purem HTML vor.

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;

Skills plugin: project facts

The few facts the skills plugin needs that genuinely vary per project. Everything else is a fixed convention (see ~/dev/skills/docs/conventions.md).

• Code roots — server, common, clients/desktop. experiments/ is a deliberate sandbox: it is iterated autonomously and stays outside the review scope (architect / quality reviewer do not walk it).
• Build — cargo build --manifest-path server/Cargo.toml.
• Test — cargo test --manifest-path server/Cargo.toml -j 4. The inner loop stays server-focused; common/ comes along via path-dep. The full multi-world + Gradle sweep runs at cycle close via the regression script.
• Lint — cargo clippy.
• Regression scripts — scripts/check.sh (fmt + clippy + build + test across all four Cargo worlds plus the Wear OS Gradle build; exit code = number of FAIL stages). scripts/regress_whisper.sh is deliberately NOT here: it needs a live Whisper service (network) and runs on demand, not as a hermetic audit gate.
• Standing reading — docs/projektplan.md is deliberately NOT standing reading (~150 KB, too heavy for every dispatch); read it explicitly when a task needs it.
• Issue tracker — Gitea, repo Brummel/doctate.
  • browsable URL: http://192.168.178.103:3000/Brummel/doctate
  • list open issues: tea issues ls --repo Brummel/doctate --state open