Files
karim c71feddf63 Doku & Aufräumen: CLAUDE.md/ARCHITECTURE.md, Tag-Schema, Legacy-Views weg
CLAUDE.md (Kurzform: was zu tun/lassen ist) und ARCHITECTURE.md
(vollständige Repo-Karte mit Verzeichnis, Datenfluss, View-Inventar,
Updater-Pipeline, Schwachstellen) als neue Onboarding-Dokumente.

Tag-Schema in Doku und Skript-Kommentar an die tatsächliche Konvention
angeglichen: Gitea-Tag ohne v-Prefix (latest.json-URL nutzt
/releases/download/<VERSION>/). Betrifft scripts/release.sh, README.md
und ARCHITECTURE.md §9+§10.

Legacy-Views Contacts.jsx und Clients.jsx entfernt — durch Persons.jsx
ersetzt, in NAV_ITEMS nicht mehr verlinkt, kein Import mehr im Code.
ARCHITECTURE.md §5/§12/§14 entsprechend aktualisiert.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-19 03:27:39 +02:00

5.4 KiB

Anweisungen für Claude

Dieses Dokument wird in jede Claude-Session automatisch geladen. Es ist die kürzeste Form: Was du wissen musst und was du tun/lassen sollst. Details stehen in ARCHITECTURE.mdlies sie, bevor du nicht-triviale Änderungen machst.


Was das Projekt ist

RAPPORT — Tauri 2.x Desktop-App für Architekturbüros. React 19 (kein TypeScript), minimaler Rust-Backend (System-Tray + Updater, keine Tauri-Commands). Solo-Dev: Karim. Daten leben in localStorage unter Key studio_data_v1. macOS Apple Silicon ist die primäre Plattform.

Architektur in einem Satz: App.jsx hält den gesamten State, übergibt ihn an lazy-geladene Views als Props, persistiert synchron in localStorage. Rust macht nur Tray + Update.

→ Vollständige Karte: ARCHITECTURE.md


Befehle

npm run dev          # Vite-Server auf http://localhost:3000
npx tauri dev        # Native App-Window mit HMR (für UI-Verifikation)
npm run lint         # ESLint
npm run build        # Frontend-Build (dist/)
npx tauri build      # Vollständiges App-Bundle
./scripts/release.sh # Release-Build mit Signatur — NUR auf explizite Anweisung

Es gibt keine Tests, keine CI, keinen Pre-Commit-Hook. Korrektheit ist Augenmaß.


Sprache

  • Antworte auf Deutsch. Karim arbeitet auf Deutsch.
  • UI-Strings im Code: Deutsch ("Zeiterfassung", "Buchhaltung", "Beenden").
  • Code-Identifier: Englisch (setView, currentUser, isQuitting).

Vor jeder Änderung — die drei Reflexe

  1. Wenn es um Daten/State geht → schau in App.jsx (Top-Level-State, Migrations, save(), update()). Kein Zustand existiert ausserhalb davon.
  2. Wenn es um Logik geht (Kalkulation, Format, Hash, QR-Bill) → schau in utils.js. Dort sind isolierte Funktionen — wahrscheinlich gibt es schon eine.
  3. Wenn es um das Datenmodell geht → schau in constants.js (defaultData ist die Shape-Referenz).

Tu — Konventionen die hier gelten

  • Inline-Styles (style={{}}) sind etabliert. Keine Tailwind-Vorschläge, keine CSS-Module einführen, ohne dass Karim das initiiert.
  • Globale Klassen (.btn, .card, .pill, .modal, .filter-bar) sind in App.jsx's <style>-Block definiert — nutze sie statt eigene zu erfinden.
  • CSS-Variablen für Theming (--bg, --text, --border, …). Dark Mode ist data-theme="dark" am Root. Niemals harte Farben einbauen, ohne CSS-Variable zu prüfen.
  • Lazy-Loaded Views — neue Top-Level-Screens in App.jsx mit React.lazy() einbinden, nicht direkt importieren.
  • Props-Pattern: Views bekommen { data, update, saveAll, modal, setModal, currentUser, … }. Kein Context, kein Redux. Wenn du State teilst, mach es über data oder hebe ihn in App.jsx.
  • update(key, value) für Top-Level-Field-Updates, saveAll(newData) für atomare Multi-Field-Updates.
  • Relative Imports (../utils.js), keine Pfad-Aliase.
  • Deutsch in UI-Strings, auch in neuen Features.

Lass — Stolperfallen

  • Kein TypeScript einführen ohne expliziten Auftrag — die Migration wäre eigenständig zu diskutieren.
  • Keine Test-Suite "nebenbei" aufsetzen — sinnvoll, aber separate Entscheidung.
  • Keine Context-/Redux-/Zustand-Provider hinzufügen — das Single-Root-State-Pattern ist bewusst.
  • Keine Tauri-Commands (#[tauri::command]) erfinden, ohne mit Karim zu klären. Die Architektur ist absichtlich Frontend-zentriert.
  • Keine neuen localStorage-Keys erfinden, ohne rapport_-Prefix und Eintragung in ARCHITECTURE.md §4.
  • Niemals Tests/Lint mit --no-verify umgehen — wenn ein Pre-Commit-Hook fehlt, fehlt er aus Absicht; wenn einer da ist, ist das Karims Entscheidung.
  • localStorage ist die Wahrheit — keine Versuche, parallele Persistierung (IndexedDB, Tauri AppData) hinzuzufügen.

Releases — heißes Eisen

Mach niemals einen Release auf eigene Faust. Auch nicht "halb" (kein Versions-Bump, kein release.sh, kein Tag, kein latest.json-Edit), es sei denn Karim sagt es explizit.

Wenn ein Release gewünscht ist, denke an:

  • Version in drei Dateien synchron: package.json, src-tauri/tauri.conf.json, src-tauri/Cargo.toml. release.sh prüft Cargo.toml nicht — du musst manuell.
  • Changelog-Entry in App.jsx's CHANGELOGS-Array + den rapport_changelog_seen-Vergleichswert.
  • release.sh braucht ~/.tauri/rapport_updater.key — wenn fehlt, abbrechen, nicht generieren.
  • Asset-Upload auf Gitea und latest.json-Commit sind manuelle Schritte.

Details: ARCHITECTURE.md §9 + §10.


UI-Verifikation

Wenn du Frontend-Änderungen machst, die optisch wirken, starte npx tauri dev und schau, ob es funktioniert. ESLint und Type-Checking gibt es hier nicht — also ist Augenschein die Verifikation. Wenn du es nicht selbst öffnen kannst, sag das explizit, anstatt "fertig" zu melden.


Wenn du etwas Neues findest

Wenn du beim Arbeiten merkst, dass ARCHITECTURE.md falsch oder veraltet ist (z.B. neue Views, neue Konventionen, Refactor): update sie im selben Commit. Sie ist die Karte — wenn sie verrottet, war die Mühe umsonst.

Wenn du eine wiederkehrende Anweisung von Karim bekommst, die hier fehlt: schlag vor, sie in CLAUDE.md zu ergänzen.