rebreak-monorepo/CLAUDE.md

CLAUDE.md — rebreak-monorepo

Projekt-Stub. Bei Bedarf mit /init um eine vollständige Codebase-Übersicht erweitern.

graphify (Knowledge-Graph)

⚠️ HARTREGEL — automatisch, ohne dass der User es je erwähnen muss

1. Memory/Kontext = Graph-FIRST, immer. Bei JEDER Frage zu Code, Architektur, Modulen oder Traceability ZUERST graph.json abfragen (per CLI/Python-Script, kompakte Ausgabe) und daraus die relevanten Dateien/Symbole bestimmen — DANN gezielt nur diese 1–2 Dateien lesen. Nie blind grep-en oder breit lesen, wenn der Graph die Antwort eingrenzen kann. Der User sagt „nutze graphify" NIE explizit — es ist Default.
2. Wartung = Graph-Update, automatisch. Nach Code-Änderungen in einer Session proaktiv /graphify --update laufen lassen (Code-only = gratis) und graph.json + manifest.json mit-committen, wenn die übrigen Änderungen committet werden — ohne Aufforderung. Git-Hook aktiv: ein post-commit/post-checkout-Hook rebuildet den Graph nach JEDEM Commit/Branch-Wechsel im Hintergrund (AST, gratis) — auch aus VS Code o. ä. Folge: graph.json ist danach „modified" → beim nächsten Commit mitnehmen. Notbremse: GRAPHIFY_SKIP_HOOK=1 git commit …. ⚠️ Hook lebt in .git/hooks/ (nicht in Git) → pro Maschine/Clone; auf neuer Maschine einmalig graphify hook install.
3. Nie graph.json / GRAPH_REPORT.md ganz in den Kontext laden — immer Query/Script.

Ein persistenter graphify-Wissensgraph liegt unter graphify-out/graph.json (14.350 Knoten / ~19.340 Kanten inkl. 27 Traceability-Kanten, Stand 2026-06-10) und ist im Repo getrackt (Scratch/Cache via .gitignore ausgeschlossen).

Wann konsultieren: Bei Fragen zu Codebase-Struktur, Architektur, „was ruft X / wo ist Y", Cross-Modul-Bezügen oder DiGA-Traceability zuerst den Graphen nutzen, statt das Monorepo blind zu durchsuchen.

⚠️ Token-Disziplin (der eigentliche Zweck): graph.json ist ~13 MB. NIEMALS graph.json (oder GRAPH_REPORT.md) ganz in den Kontext lesen — das verbrennt mehr Tokens als es spart. Immer nur per CLI/Python-Script abfragen, sodass nur eine kompakte Antwort ins Kontext-Fenster kommt. Wird diese Regel verletzt, ist der Graph ein Token-Loch statt -Sparer.

Wie abfragen:

• Einfache „wo ist X / was ruft Y"-Fragen → graphify query "<frage>" (BFS, kompakte Ausgabe).
• Tiefe Architektur-/Traceability-Traces → kleines Python-Script das graph.json von der Platte liest und nur das Ergebnis printet (Adjazenz + shortest-path). Die Substring-BFS von graphify query verheddert sich an i18n-Locale-Keys; für präzise Pfade ist der gezielte Walk verlässlicher.
• Graph-FIRST für jede Codebase-Frage — das ist der Token-Spar-Mechanismus: Der Graph nennt dir kompakt die beteiligten Dateien/Symbole/Pfade, dann liest du gezielt nur die 1–2 relevanten Dateien statt das Repo zu grep-en oder breit zu lesen. Auch bei Logikfragen: erst Graph fragen (welche Dateien?), dann nur die lesen. So wird aus „10 Dateien lesen" → „Graph-Query + 1 Datei lesen".

Nach Code-Änderungen / neuen Features: /graphify --update. Nur-Code-Änderungen sind GRATIS (AST, kein LLM — die Skill erkennt das automatisch). Doc-/Bild-Änderungen kosten LLM-Tokens → nur ausführen wenn man die Doc-Inhalte wirklich im Graph braucht. Wenn das Ziel reine Token-Ersparnis ist: Updates code-only halten.

Aktueller Scope & Grenzen (ehrlich):

• Code-Struktur: vollständig (AST über backend/ + apps/rebreak-native/).
• Doc↔Code-Brücken: spärlich — nur der Lyra-/Krisen-Strang ist verdrahtet (12 traceability:true-Kanten, gespiegelt in docs/specs/diga/05d-traceability-matrix-v0.md). Andere DiGA-Stränge (Schutz/Blocker REQ-PROT, Mail REQ-MAIL, Anonymität) sind noch nicht Code-verknüpft → manuell verdrahten wie beim Lyra-Strang (05d §4).
• Bilder (184) + 1 Video bewusst übersprungen — stehen beim nächsten --update wieder als „neu" an.

graphify-eigene memory: graphify-out/memory/ hält gespeicherte Query-Antworten (z. B. den Lyra-Traceability-Trace) und fließt beim --update zurück in den Graphen.

Agent-Verhaltensregel: Keine eigenmächtigen Code-Änderungen

⚠️ HARTREGEL — vom User explizit verlangt

• Nie Code schreiben, ändern oder erstellen, nur weil etwas „offensichtlich" erscheint.
• Keine Implementierung ohne ausdrückliches „Go" des Users.
• Ausnahme: Der User gibt einen konkreten, knappen und verständlichen Implementierungstask.
• Vorher sind Fragen, Planen und Recherche erlaubt und gewollt — aber erst nach einem klaren „mach das" wird Code produziert.

Session-Kontext-Limit: Stop & Prompt

⚠️ HARTREGEL — vom User explizit verlangt

Wenn Anzeichen dafür bestehen, dass der Session-Kontext voll läuft oder alte Details verloren gehen (z. B. ich vergesse wiederholt Werte wie hardwareId, UDIDs oder bereits besprochene Fakten), dann:

1. Sofort stoppen — keine weiteren Code-Änderungen, keine langen Analysen.
2. Kurzen Status-Block notieren — was wurde besprochen, was steht noch aus, welche Dateien betroffen sind.
3. Dem User einen einfachen Copy-Paste-Prompt geben, mit dem er die nächste Session nahtlos fortsetzen kann.
4. Den User bitten, diese Session zu beenden und die neue mit dem Prompt zu starten.

Das verhindert, dass bereits erledigte Arbeit oder wichtige Kontextdetails erneut aufgebaut werden müssen.