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.