Vault-Struktur und Debugging
Organisiere einen Markdown-Vault als durchsuchbaren Zweitspeicher. Behebe die vier Fehlermodi, wenn Claude etwas Unerwartetes tut.
STATE.md und MEMORY.md enthalten das, was jede Sitzung benötigt. Ein Markdown-Vault (Obsidian oder ein beliebiger Ordner) enthält alles andere: Strategienotizen, Besprechungsprotokolle, Projektjournale, Forschung, Wettbewerbsanalysen.
Der Vault entwickelt sich zu einem institutionellen Gedächtnis: Entscheidungen, die du vor sechs Monaten getroffen hast und warum, Referenzmaterialien, die die aktuelle Arbeit informieren, Muster, die Projekte umfassen. Verbinde ihn über einen Obsidian- oder Dateisystem-MCP, und Claude kann das Ganze bei Bedarf durchsuchen. Ohne den Vault existiert dieses Wissen nur in deinem Kopf oder ist in alten Dokumenten vergraben.
Warum Markdown besser ist als eine Datenbank: einfache Dateien sind greppable, versionierbar mit Git, in jedem Editor zu öffnen und überleben jeden Tool-Wechsel. Eine funktionierende Struktur:
~/notes/
├── STATE.md # Immer geladen
├── MEMORY.md # Index, immer geladen
├── STRATEGY-DIGEST.md # Zusammenfassungen von Strategiedokumenten
├── strategy/ # Vollständige Dokumente, bei Bedarf gelesen
├── projects/ # Datierte Projektnotizen
├── resources/
└── reference/Der Skalierungsschlüssel ist das Digest-Muster: Wenn du ein 1.000-Wörter-Strategiedokument schreibst, schreibe daneben eine 3-Satz-Zusammenfassung und indiziere die Zusammenfassung in MEMORY.md. Claude liest beim Sitzungsstart etwa 50 Tokens statt der ungefähr 1.500 des vollständigen Dokuments. Bei 25 Strategiedokumenten sind das 1.250 Tokens statt 37.500, und die Sitzungen bleiben schnell.
Wenn Claude etwas Unerwartetes tut, überprüfe der Reihe nach vier Fehlermodi, vom häufigsten zum seltensten:
Veralteter Speicher: STATE.md sagt etwas, die Realität etwas anderes. Claude hat deine Anweisungen perfekt befolgt; die Anweisungen waren falsch. Frage zuerst immer: „Zeige mir deine STATE.md“.
Fehlender Kontext: Die relevante Datei wurde nie geladen, also hat Claude eine vernünftige Vermutung angestellt. Lade die Datei explizit und frage erneut.
Tool nicht verfügbar: Ein MCP ist ausgefallen oder ein Hook hat einen Befehl blockiert, und Claude hat ihn schlecht umgangen. Überprüfe die Tool-Verfügbarkeit, bevor du die Argumentation bemängelst.
Halluzination: die seltenste Ursache. Zuerst überprüfen: nach der Funktion greppen, prüfen, ob der Endpunkt existiert. Die meisten „Halluzinationen“ erweisen sich als einer der ersten drei Punkte.
Eine Diagnosefrage pro Fehlermodus:
Veralteter Speicher: „Was sagt deine STATE.md über [Thema]?“ Inhalt von vor drei Sitzungen bedeutet veralteten Zustand.
Fehlender Kontext: „Welche Dateien hast du über [Thema] geladen?“ Keine relevanten Dateien bedeutet, die richtige zu laden.
Tool nicht verfügbar: „Welche Tools stehen dir gerade zur Verfügung?“
Halluzination: „Greppe nach [Funktion/Endpunkt] und zeige mir, was du findest.“
Die Reihenfolge dauert zwei Minuten und findet die Ursache fast jedes Mal. Direkt zu „Claude halluzinierte“ zu springen, verzögert normalerweise die eigentliche Lösung, indem Code neu geschrieben wird, der nicht neu geschrieben werden musste.
Prävention ist besser als Debugging. Die Gewohnheiten:
STATE.md-Update am Sitzungsende. Eliminiert 80 % der Probleme mit veraltetem Speicher.
Archiviere ausgelieferte Projekte in datierte project_*-Dateien.
Monatliches MEMORY.md-Audit: Bestätige, dass jeder Zeiger immer noch auf eine vorhandene Datei verweist.
Fasse jedes Dokument über 500 Wörter zusammen.
Schreibe Entscheidungen im Moment der Entscheidung auf, nicht am Ende der Woche. Eine nachträgliche Erfassung verliert die Begründung.
Bevor du Projektnachweise archivierst, extrahiere die dauerhaften Lektionen in feedback_*-Einträge. Das Projekt wird Geschichte; die Lektionen bleiben aktiv.
Ein Vault mit 10 gut gepflegten Dokumenten ist besser als einer mit 200 veralteten. Qualität und Aktualität sind wichtiger als Quantität.
Mit einem Obsidian- oder Dateisystem-MCP wird der Vault zu einer Live-Wissensdatenbank:
Entscheidungsarchäologie: „Durchsuche den Vault, warum wir Postgres statt MySQL gewählt haben.“ Eine 10-minütige manuelle Suche wird zu 15 Sekunden.
Mustererkennung: „Finde alle Erwähnungen von Ratenbegrenzungsproblemen oder 429-Fehlern über Projekte hinweg.“ Claude deckt eine gemeinsame Grundursache auf, die sich über fünf Projektdateien erstreckt.
Referenzsuche: „Finde die Kontaktinformationen in den Lieferantennotizen.“ Sofortiger Abruf aus nicht indizierten Dateien.
Die Suchqualität hängt von der Namenskonsistenz ab: project_[name]_[date].md und feedback_[rule].md sind besser als das, was sich gerade natürlich anfühlte. Namenskonventionen sind der Index, den du erstellst, bevor du ihn benötigst.
Alle vier Modi sind sauber, und die Ausgabe ist immer noch falsch? Zwei Ursachen sehen aus wie Halluzinationen, sind es aber nicht.
Kontextreihenfolge: Wenn geladene Dateien in Konflikt stehen, gewinnt tendenziell der später geladene Inhalt. Wenn alte Projekthinweise STATE.md widersprechen, weise die Autorität explizit zu: „STATE.md ist die aktuelle Grundwahrheit. Es ersetzt alles in den Projekthinweisen.“
Einschränkungskonflikte: CLAUDE.md sagt „alle SQL-Abfragen parametrisieren“, also schreibt Claude SQL während einer von dir als reinen Stil-Refaktor gedachten Aktion um. Kein Fehler; schränke es explizit ein: „Nur Stil, SQL-Muster nicht ändern.“
Die Diagnose für beides: „Welche Anweisungen befolgst du, die diese Entscheidung regeln? Liste die Regeln in der Reihenfolge ihrer Priorität auf.“ Du wirst eine veraltete Quelle, eine widersprüchliche Regel oder eine CLAUDE.md-Lücke finden. Alles behebbar.
Ein Markdown-Vault mit Digest-Dateien skaliert deinen Zweitspeicher; Digests halten Sitzungen schnell, vollständige Dokumente werden bei Bedarf geladen. Wenn Claude sich falsch verhält, überprüfe der Reihe nach: veralteter Speicher, fehlender Kontext, Tool nicht verfügbar, Halluzination, und beginne immer mit „Zeige mir deine STATE.md“. Füttere den Vault im Moment der Entscheidung, und sein Wert steigt jede Woche.