chahine/rebreak-monorepo
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
rebreak-monorepo/CLAUDE.md
chahinebrini c82c94e457 chore(graphify): Graph als Memory syncen, Scratch-/Cache-Muell untracken 
- 751 versehentlich getrackte Scratch-/Cache-Dateien (.chunk_*, .graphify_*, cache/ast/)
  aus Git entfernt; graphify-out/.* + graphify-out/cache/ in .gitignore
- Getrackt bleibt die echte Memory: graph.json (mit 27 Traceability-Kanten),
  GRAPH_REPORT.md, graph.html, manifest.json, memory/ (gespeicherte Query-Antworten)
- CLAUDE.md: graph-first Workflow geschaerft (Graph nennt Dateien -> gezielt 1-2 lesen
  statt grep) = der eigentliche Token-Spar-Mechanismus

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-10 13:16:52 +02:00

2.8 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.
  • 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.