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>
This commit is contained in:
@@ -0,0 +1,97 @@
|
||||
# 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.md](ARCHITECTURE.md) — **lies 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](ARCHITECTURE.md)
|
||||
|
||||
---
|
||||
|
||||
## Befehle
|
||||
|
||||
```bash
|
||||
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](src/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](src/utils.js). Dort sind isolierte Funktionen — wahrscheinlich gibt es schon eine.
|
||||
3. **Wenn es um das Datenmodell geht** → schau in [constants.js](src/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](src/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](src/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](ARCHITECTURE.md).
|
||||
- **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](package.json), [src-tauri/tauri.conf.json](src-tauri/tauri.conf.json), [src-tauri/Cargo.toml](src-tauri/Cargo.toml). `release.sh` prüft Cargo.toml **nicht** — du musst manuell.
|
||||
- Changelog-Entry in [App.jsx](src/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](ARCHITECTURE.md).
|
||||
|
||||
---
|
||||
|
||||
## 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](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.
|
||||
Reference in New Issue
Block a user