Files
Brummel 2fa824aafe chore: move skills-plugin profile into CLAUDE.md project facts
The skills plugin dropped dev-cycle-profile.yml. Migrate this project's facts into CLAUDE.md under '## Skills plugin: project facts' and remove the profile file.
2026-06-13 16:30:11 +02:00

76 lines
3.5 KiB
Markdown
Executable File

# 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:
```mermaid
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`