chahine/rebreak-monorepo
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
rebreak-monorepo/CLAUDE.md
chahinebrini 802a7cb9a3 docs: CLAUDE.md mit graphify-Nutzungs- + Token-Disziplin-Regeln 
Knowledge-Graph (graphify-out/graph.json) fuer Codebase-/Architektur-/Traceability-
Fragen konsultieren; graph.json nie in Kontext laden; --update code-only halten.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-10 12:49:23 +02:00

2.6 KiB
Raw Blame History

CLAUDE.md — rebreak-monorepo

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

graphify (Knowledge-Graph)

Ein persistenter graphify-Wissensgraph liegt unter graphify-out/graph.json (14.350 Knoten / 19.326 Kanten, Stand 2026-06-10).

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.
  • Lohnt sich nur bei Navigations-/„welche Dateien sind beteiligt"-Fragen. Für tiefe Logik-/Verhaltensfragen müssen die echten Dateien gelesen werden — dann spart der Graph wenig. Nicht erzwingen.

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.