Lernleitfaden: Teil 19. Agentenspeicher auf SQLite

Thema: Teil 19. Agenten-Speicher auf SQLite

Schwierigkeitsgrad: Mittelstufe

Geschätzte Lernzeit: 6-8 Stunden (Theorie 2 Stunden, Praxis 4-6 Stunden)

Voraussetzungen: Grundkenntnisse in SQL und SQLite (Erstellen von Tabellen, Indizes, einfache Abfragen)

Verständnis der Qwen Code-Architektur und des Hook-Systems (Teile 1-4 des Kurses)

Erfahrung mit der Kommandozeile und Python-Skripten

Vertrautheit mit dem Konzept des SDD (Specification-Driven Development)

Grundlegendes Verständnis der Funktionsweise von LLMs und Kontextfenstern

Lernziele: Eigenständig ein vollständiges Agenten-Speichersystem auf SQLite mit den Tabellen events und memories bereitstellen, einschließlich Schema, Hooks und Kontext-Injektionsmechanismus

Kritisch bewerten, welche Daten im Agenten-Speicher gespeichert werden sollten und welche auf keinen Fall, und Datenschutz- sowie Sicherheitsregeln praktisch anwenden

Hintergrund-Speicherzusammenfassung (Analog zu /dream) über Skripten wie dream_sqlite.py mit LLM-API-Aufruf implementieren und konfigurieren sowie deren Ausführung steuern

Die Grenze zwischen operativem Agenten-Speicher und dauerhaften Spezifikationen erkennen, stabile Regeln von memories in specs/, QWEN.md oder Fähigkeiten übertragen

Kontextanfragen optimieren, indem das Prinzip „weniger ist mehr“ angewendet wird: relevante Einträge nach Tags filtern, die Anzahl injizierter Blöcke begrenzen, „Kontextdegradierung“ verhindern

Überblick: Dieser Teil des Kurses widmet sich der Erstellung einer lokalen, transparenten und vollständig kontrollierbaren Speicherschicht für die Agentenentwicklung auf Basis von SQLite. Der integrierte Speicher von Qwen Code (QWEN.md, /remember, /forget, /dream) ist für die meisten Projekte ausreichend, aber bei Bedarf an Audit, Umgebungswechsel oder benutzerdefinierten Bereinigungsregeln kann der Entwickler ein eigenes System aufbauen. Kernidee: Ereignisse aus Agentensitzungen werden über Hooks in die Tabelle events protokolliert, dann werden sie durch Hintergrundzusammenfassung in kompakte Merkzettel der Tabelle memories verdichtet, die in den Kontext neuer Sitzungen injiziert werden. Wichtigste Einschränkung — der Speicher ergänzt, aber ersetzt nicht die Spezifikationen: dauerhafte Regeln müssen in specs/ oder QWEN.md übergehen. Der Kurs deckt das Datenbankschema, zwei Schlüssel-Hooks (log_event.py und inject_memory.py), die Integration in Qwen Code, Automatisierung der Zusammenfassung, Datenschutz sowie Prinzipien der Kontextsparsamkeit zur Verhinderung der „Kontextdegradierung“ ab.

Schlüsselkonzepte: Zweistufige Speicherarchitektur (events + memories): Rohe Ereignisse werden in der Tabelle events gespeichert — das ist das vollständige Protokoll der Agentenaktionen: Anfragen, Werkzeugaufrufe, Ergebnisse. Dauerhafte Erkenntnisse aus diesen Ereignissen werden in der Tabelle memories verdichtet — kompakte, strukturierte Notizen. Die Trennung ist kritisch wichtig: events ermöglichen Audit und Ausgangsmaterial für Zusammenfassung, memories — schnellen relevanten Kontext für neue Sitzungen. Ohne diese Trennung bläht sich der Kontext schnell mit unstrukturierten Daten auf.

Qwen Code-Hooks (log_event.py, inject_memory.py): Hooks sind ausführbare Skripte, die an Schlüsselpunkten des Sitzungslebenszyklus aufgerufen werden. log_event.py bindet sich an die Ereignisse UserPromptSubmit (Anfragesendung), PostToolUse (nach Werkzeugnutzung) und Stop (Sitzungsende) — es schreibt Metadaten in events. inject_memory.py bindet sich an SessionStart und UserPromptSubmit — es liest relevante Einträge aus memories und fügt sie dem Kontext der aktuellen Sitzung hinzu. Beide Skripte müssen ausführbar sein und korrekt in settings.json konfiguriert sein.

Hintergrundzusammenfassung (/dream für SQLite): Periodischer Prozess der Konsolidierung roher Ereignisse in dauerhafte Merkzettel. Im Unterschied zum integrierten /dream arbeitet die SQLite-Version offline: Das Skript dream_sqlite.py liest events über einen Zeitraum (z. B. --since 24h), ruft zur Zusammenfassung die LLM-API auf (DashScope/Bailian) und schreibt das Ergebnis in memories. Ausführung über cron, manuell oder nach Projektphasen. Schlüsselvorteil: vollständige Transparenz — der Mensch kann sowohl rohe Ereignisse als auch verdichtete Notizen einsehen.

Kontexthygiene und „Kontextdegradierung“: Phänomen, bei dem großer irrelevanter Kontext die Qualität der Modellantworten stärker verschlechtert als kurzer präziser Kontext. Studien zeigen: 300 relevante Token sind effektiver als 30 000 irrelevante. Praktische Schlussfolgerungen: nicht mehr als 3-5 Speicherblöcke injizieren, nach Tags/Kategorien filtern, Veraltetes löschen statt „präzisieren“, häufig benötigte Einträge als Regeln in QWEN.md übertragen.

Grenze Speicher vs. Spezifikation: Agenten-Speicher — operative Schicht für erkennbare Muster, Präferenzen und Fehler. Spezifikationen (specs/, QWEN.md, Fähigkeiten) — für das Produkt verbindliche Regeln. Wenn die Hintergrundzusammenfassung eine dauerhafte Regel findet (z. B. „CHANGELOG.md vor dem Merge immer aktualisieren“), muss sie aus memories in die entsprechende Spezifikation übergehen. Der Speicher hilft zu entdecken, Spezifikationen — die Verbindlichkeit zu verankern.

Datenschutz und Sicherheit des Speichers: Der Speicher wird leicht zu einem Lager sensibler Daten. Verbindliche Regeln: keine Umgebungsvariablen protokollieren, Werkzeugantworten kürzen, keine Geheimnisse und personenbezogenen Daten speichern, Kontext auf 3-5 Blöcke begrenzen, regelmäßig Veraltetes bereinigen, .db-Datei nicht committen (nur Schema und Skripte). Beispiel-.gitignore wird im Kurs bereitgestellt.

Volltextsuche (FTS) in SQLite: Die Tabelle memory_fts ermöglicht schnelle Suche im Inhalt der Merkzettel. Die Funktion snippet() wird zur Anzeige des Kontexts gefundener Übereinstimmungen verwendet. Ermöglicht das Auffinden relevanter Einträge nach Schlüsselwörtern bei Kontextinjektion oder manuellem Audit.

Praxisübungen: Titel: Bereitstellung des Basisschemas und erster Hook

Aufgabe: Erstellen Sie das Verzeichnis .qwen/memory, kopieren Sie schema.sql aus dem Lehrbuch, initialisieren Sie die SQLite-Datenbank agent-memory.db. Erstellen Sie dann .qwen/hooks, kopieren Sie log_event.py, machen Sie es ausführbar. Konfigurieren Sie settings.json zur Anbindung des Hooks an die Ereignisse UserPromptSubmit und PostToolUse. Führen Sie eine Test-Sitzung Qwen Code mit einer einfachen Anfrage durch (z. B. „erstelle hello.py“). Überprüfen Sie, ob die Ereignisse in die Datenbank geschrieben wurden.

Lösung: 1. mkdir -p .qwen/hooks .qwen/memory

1. cp "$TUTORIAL_DIR/examples/sqlite-memory/schema.sql" .qwen/memory/schema.sql
2. sqlite3 .qwen/memory/agent-memory.db < .qwen/memory/schema.sql
3. cp "$TUTORIAL_DIR/examples/sqlite-memory/hooks/log_event.py" .qwen/hooks/
4. chmod +x .qwen/hooks/log_event.py
5. Führen Sie die Konfiguration aus settings-hooks.example.json mit Ihrem settings.json zusammen (überschreiben Sie nicht Modell und Autorisierung)
6. Starten Sie Qwen Code, führen Sie die Anfrage aus
7. Überprüfen Sie: sqlite3 .qwen/memory/agent-memory.db "select event_name, tool_name, substr(prompt,1,80), timestamp from events order by id desc limit 5;"

Erwartetes Ergebnis: Einträge mit den Typen UserPromptSubmit und PostToolUse sind sichtbar.

Schwierigkeitsgrad: Anfänger

Titel: Injektion relevanter Erinnerungen in eine Sitzung

Aufgabe: Binden Sie inject_memory.py an die Ereignisse SessionStart und UserPromptSubmit an. Erstellen Sie manuell 2-3 Testeinträge in der Tabelle memories mit verschiedenen Kategorien (preferences, workflow, project). Starten Sie eine neue Qwen Code-Sitzung mit einer Anfrage, die für eine der Kategorien relevant ist. Überprüfen Sie über Logs oder Modifikation von inject_memory.py mit Ausgabe in stderr, dass die richtigen Einträge dem Kontext hinzugefügt wurden.

Lösung: 1. cp "$TUTORIAL_DIR/examples/sqlite-memory/hooks/inject_memory.py" .qwen/hooks/

1. chmod +x .qwen/hooks/inject_memory.py
2. Fügen Sie die Hooks in settings.json hinzu
3. Erstellen Sie Einträge manuell über SQL oder kopieren Sie manual-memory-example.sql
4. Modifizieren Sie inject_memory.py vorübergehend: fügen Sie print(f"[DEBUG] Injecting: {path}", file=sys.stderr) hinzu
5. Starten Sie eine Sitzung mit einer Anfrage zu Ihrer Kategorie
6. Überprüfen Sie die Ausgabe: Sie sollten [DEBUG] Injecting: mit den richtigen Pfaden sehen
7. Stellen Sie sicher, dass irrelevante Einträge nicht injiziert werden

Schwierigkeitsgrad: Mittelstufe

Titel: Hintergrundzusammenfassung mit Dry-Run

Aufgabe: Installieren Sie dream_sqlite_qwen_example.py als dream_sqlite.py. Stellen Sie sicher, dass die Variable BAILIAN_API_KEY konfiguriert ist. Führen Sie die Zusammenfassung für die letzten 24 Stunden im Dry-Run-Modus aus. Analysieren Sie die Ausgabe: welche Ereignisse wurden ausgewählt, welche Merkzettel vorgeschlagen. Führen Sie dann ohne Dry-Run aus und überprüfen Sie das Ergebnis in der Tabelle memories.

Lösung: 1. cp "$TUTORIAL_DIR/examples/sqlite-memory/dream_sqlite_qwen_example.py" .qwen/memory/dream_sqlite.py

1. export BAILIAN_API_KEY=ihr_schlüssel
2. python .qwen/memory/dream_sqlite.py --since 24h --dry-run
3. Prüfen Sie stdout: dort wird der Plan angezeigt — welche events ausgewählt, welche summaries generiert
4. Wenn das Ergebnis zufriedenstellend: python .qwen/memory/dream_sqlite.py --since 24h
5. Überprüfen Sie: sqlite3 .qwen/memory/agent-memory.db "select path, substr(content,1,100), updated_at from memories order by updated_at desc;"
6. Erwartetes Ergebnis: neue kompakte Einträge in memories, die Muster aus events widerspiegeln

Schwierigkeitsgrad: Mittelstufe

Titel: Migration einer Regel aus dem Speicher in die Spezifikation

Aufgabe: Nach mehreren Sitzungen fällt Ihnen auf, dass der Agent systematisch vergisst, CHANGELOG.md zu aktualisieren. Dieses Muster ist in memories als workflow/sdd-validation.md mit einer Notiz festgehalten. Ihre Aufgabe: bewerten Sie, ob es sich um eine dauerhafte Regel entwickelt hat, und übertragen Sie sie korrekt in die Projektspezifikation, löschen Sie sie aus memories oder markieren Sie sie als übertragen.

Lösung: 1. Finden Sie den Eintrag: sqlite3 .qwen/memory/agent-memory.db "select path, content from memories where path like '%validation%';"

1. Analysieren Sie die Häufigkeit: wie oft wiederholte sich der Fehler, bestätigte der Benutzer die Korrektur
2. Wenn die Regel dauerhaft ist (≥3 Bestätigungen, kritisch für das Produkt):

• Erstellen oder aktualisieren Sie specs/workflow/changelog.md oder fügen Sie einen Abschnitt in QWEN.md hinzu
• Formulieren Sie als verbindliche Regel: „Vor dem Merge eines Feature-Branches in main CHANGELOG.md mit Unreleased-Abschnitt aktualisieren“

1. Markieren Sie in memories: UPDATE memories SET content = content || '\n\n[TRANSFERRED TO specs/workflow/changelog.md 2024-XX-XX]' WHERE path = 'workflow/sdd-validation.md';

Oder löschen Sie bei sicherer Duplizierung

1. Überprüfen Sie in neuer Sitzung: der Agent sollte der Regel aus der Spezifikation folgen, ohne Speicher zu benötigen

Schwierigkeitsgrad: Fortgeschritten

Titel: Audit und Bereinigung sensibler Daten

Aufgabe: Bei der Datenbankprüfung stellen Sie fest, dass in events versehentlich Zeilen mit API-Schlüssel im Feld prompt enthalten sind (Benutzer hat ihn zur Testzwecken in die Anfrage eingefügt). Außerdem gibt es in memories einen Eintrag mit der privaten E-Mail eines Testers. Führen Sie ein Audit durch, finden Sie alle sensiblen Einträge, bereinigen Sie sie, und implementieren Sie Schutzmaßnahmen gegen Wiederholung.

Lösung: 1. Audit events: sqlite3 .qwen/memory/agent-memory.db "select id, substr(prompt,1,200) from events where prompt like '%sk-%' or prompt like '%Bearer%' or prompt like '%@%.%';"

1. Audit memories: analoge Abfrage mit Suche nach content
2. Löschen Sie gefundene Einträge: DELETE FROM events WHERE id IN (...); DELETE FROM memories WHERE path = '...';
3. Überprüfen Sie FTS: DELETE FROM memory_fts WHERE docid IN (SELECT id FROM memories WHERE ...);
4. Verstärken Sie log_event.py: fügen Sie Filterung hinzu — prüfen Sie prompt vor dem Schreiben auf Geheimnis-Muster mit regulären Ausdrücken, ersetzen Sie durch [REDACTED]
5. Fügen Sie in .gitignore hinzu: .qwen/memory/agent-memory.db und alle .db-journal, .db-wal
6. Dokumentieren Sie die Regel in der Projekt-README: „Nie Geheimnisse in Prompts einfügen“

Schwierigkeitsgrad: Fortgeschritten

Fallstudien: Titel: AgentClinic: Von operativen Notizen zur Produktspezifikation

Szenario: Ein Startup entwickelt den Dienst AgentClinic — eine öffentliche Plattform für satirische Bewertungen von KI-Agenten. Ein 4-Personen-Team nutzt Qwen Code mit kundenspezifischem SQLite-Speicher zur Koordination. Über 3 Monate wurden 15 000 Ereignisse und 200 Merkzettel in memories angesammelt.

Herausforderung: Problem 1: Der Kontext neuer Sitzungen blähte sich auf 8000 Token durch ungefilterte Injektion aller memories auf — das Modell „verlor sich“ und ignorierte Schlüsselanweisungen aus QWEN.md. Problem 2: Die Produkteinigung über den Ton („öffentlich und satirisch, keine privaten Ansprachen“) existierte nur in memories, und verschiedene Entwickler interpretierten sie unterschiedlich. Problem 3: Ein neuer Entwickler konnte nicht nachvollziehen, warum bestimmte Entscheidungen getroffen wurden — memories waren nicht versioniert und nicht committet.

Lösung: Das Team führte strenge Filterung in inject_memory.py ein: nur Einträge mit Tags, die für die aktuelle Aufgabe relevant sind (bestimmt durch Schlüsselwörter der Anfrage), maximal 4 Blöcke à 200 Token. Für Produkteinigungen schuf es den Prozess „Memory Triage“ — wöchentlich prüfte ein Senior-Entwickler neue memories und übertrug dauerhafte Regeln in specs/. Konkret migrierte die Ton-Einigung in specs/mission.md mit der Formulierung „Alle Einträge in AgentClinic sind standardmäßig öffentlich; satirischer Ton ist verbindlich, private Ansprachen verboten“. Schema und Skripte wurden in ein separates Repository mit Versionierung ausgelagert, .db-Datei in .gitignore aufgenommen — jeder Entwickler hielt eine lokale Kopie, synchronisierte bei Bedarf über Export/Import von memories als SQL-Dumps.

Ergebnis: Die durchschnittliche Sitzungskontextgröße sank von 8000 auf 1200 Token, während die Genauigkeit der Befolgung von Anweisungen (gemessen durch manuelle Bewertung von 50 Sitzungen) von 64% auf 91% stieg. Produkteinigungen wurden teamübergreifend einheitlich. Der neue Entwickler konnte die Regeln in 2 Stunden Lesen von specs/ erfassen statt in 2 Tagen Graben im Speicher. Die Zeit für „Memory Triage“ — 30 Minuten pro Woche — amortisierte sich durch reduzierte Interpretationsfehler.

Erkenntnisse: Ungefilterte Injektion aller memories ist schlimmer als fehlender Speicher — Kontextdegradierung ist real und messbar

Produktregeln müssen so schnell wie möglich in specs/ übergehen; memories sind nur Inkubator

Versionierung von Schema und Skripten ist kritisch, aber .db-Dateien dürfen nicht committet werden — das sind personenbezogene Daten und operative Schicht

Regelmäßiges manuelles Audit des Speichers (Memory Triage) ist notwendig, vollautomatische Zusammenfassung riskiert die Verfestigung fehlerhafter Muster

Verwandte Konzepte: Kontexthygiene und „Kontextdegradierung“

Grenze Speicher vs. Spezifikation

Datenschutz und Sicherheit des Speichers

Hintergrundzusammenfassung (/dream für SQLite)

Titel: Fintech-Startup: Datenschutz von Kundendaten im Agenten-Speicher

Szenario: Ein Fintech-Unternehmen mit 12 Entwicklern nutzte Qwen Code mit SQLite-Speicher zur Entwicklung eines Zahlungsverarbeitungssystems. Der Speicher half, komplexe Geschäftsregeln und häufige Fehler bei der Integration mit Bank-APIs zu verfolgen.

Herausforderung: Während eines Sicherheitsaudits stellte sich heraus, dass log_event.py vollständige Bank-API-Antworten in die Tabelle events schrieb, einschließlich maskierter Kartennummern, Transaktionsbeträge und interner Kunden-IDs. Außerdem hatten sich in memories Notizen mit E-Mails und Telefonnummern von Testern angesammelt, die zur Fehlersuche bei SMS-Benachrichtigungen verwendet wurden. Die Datenbank agent-memory.db geriet versehentlich bei einer hastischen Fehlerbehebung in einen Commit.

Lösung: Sofortmaßnahme: Commit zurückgezogen, Rotation aller potenziell kompromittierten Schlüssel, Regulator gemäß Verfahren informiert (Daten waren maskiert, aber der Leckage-Fakt selbst — ein Risiko). Strukturelle Änderungen: log_event.py neu geschrieben mit verbindlicher Filterung — reguläre Ausdrücke für PAN (auch maskierte), Beträge, E-Mails, Telefonnummern; API-Antworten auf Statuscode und message ohne Payload gekürzt. Pre-Commit-Hook implementiert, der Commits jeglicher .db-Dateien blockiert. memories durch SQL-Skript mit protokollierter Operationen für Audit bereinigt. Rolle „Privacy Reviewer“ im Memory Triage hinzugefügt.

Ergebnis: Vorfall begrenzt, keine Geldbußen dank schneller Reaktion und Maskierung der Ausgangsdaten. Das neue Filtersystem blockierte in 6 Monaten 340 potenzielle Leckagen (gemessen durch Auslösungen der regulären Ausdrücke). Entwicklerzeit für Filterkonfiguration — 4 Stunden — amortisierte sich in der ersten Woche. „Privacy by Design“-Kultur in den Speicherprozess eingebaut.

Erkenntnisse: „Maskierte“ Daten sind immer noch sensibel — Regulatoren und Ethik verlangen deren Ausschluss aus allen Logs

Technische Maßnahme (.gitignore) ist ohne Pre-Commit-Hook unzureichend — menschlicher Faktor in Hast ist unvermeidlich

Filterung muss in log_event.py erfolgen, verlassen Sie sich nicht darauf, dass „Entwickler vorsichtig sein werden“

Speicher-Audit muss so regelmäßig sein wie Code-Audit — Daten sammeln sich unbemerkt an

Verwandte Konzepte: Datenschutz und Sicherheit des Speichers

Zweistufige Speicherarchitektur (events + memories)

Qwen Code-Hooks (log_event.py, inject_memory.py)

Lerntipps: Beginnen Sie mit der manuellen Durchführung der gesamten Kette: erstellen Sie das Schema, starten Sie einen Hook, prüfen Sie die Datenbank manuell über sqlite3 CLI — so „spüren“ Sie den Datenfluss, bevor Sie automatisieren

Führen Sie ein „Laborjournal“ in einer separaten Datei: dokumentieren Sie, welche SQL-Abfragen Sie ausführten, was Sie erwarteten, was Sie erhielten — das entwickelt Intuition für die Fehlersuche in SQLite-Speicher

Üben Sie das Prinzip „zuerst Dry-Run, dann Realität“ mit dream_sqlite.py: die Gewohnheit, Zusammenfassung vor dem Schreiben zu prüfen, verhindert Verunreinigung von memories mit Müll

Erstellen Sie Ihre eigene „Reifegradskala“ für Regeln: 1 Mal — Notiz, 2 Mal — prüfen, 3 Mal — Kandidat für Spezifikation. Das erleichtert die Migrationsentscheidung

Nutzen Sie die Analogie zum menschlichen Gedächtnis: events — „alles, was Sie heute gesehen haben“, memories — „Einträge im Tagebuch“, specs/ — „unterschriebene Verträge“. Verträge haben Rechtskraft, Tagebuch — operative Hilfe

Für visuellen Stil: zeichnen Sie auf Papier ein Datenflussdiagramm vom Ereignis zur Injektion, markieren Sie, wo ein Leck oder eine Kontextaufblähung passieren kann — das aktiviert räumliches Denken

Lernen in Paaren: falls möglich, konfiguriert eine Person log_event.py, die andere inject_memory.py, dann tauschen sie Rollen und suchen nach Bugs in der Implementierung des anderen — der beste Weg, Edge Cases zu finden

Führen Sie während des Lernens regelmäßig /clear in Qwen Code aus — das trainiert bewussten Umgang mit Kontext statt Ansammlung von allem Möglichen

Zusätzliche Ressourcen: Originalbeispiele des Kurses (schema.sql, Hooks, dream sqlite): Repository sdd-qwen-code-ru/examples/sqlite-memory/ — Quelle aller Skripte, kopieren Sie von hier, schreiben Sie nicht von Grund auf neu

SQLite FTS5-Dokumentation: https://www.sqlite.org/fts5.html — für tiefes Verständnis der Volltextsuche in der Tabelle memory_fts

VentureBeat-Artikel über Agenten-Speicher von Anthropic: Im Kurs erwähnt; suchen Sie nach den Schlüsselwörtern 'Anthropic agent memory sessions patterns' — konzeptionelle Grundlage der Hintergrundzusammenfassung

Teil 14 des Kurses (Kontexthygiene): part-14-build-your-own-workflow.md — obligatorische Ergänzung zum Verständnis, warum /clear und Rollentrennung funktionieren

Teil 4 des Kurses (Konfiguration der API DashScope/Bailian): Für korrekte Einrichtung von BAILIAN_API_KEY in dream_sqlite_qwen_example.py

OWASP Cheat Sheet zur sicheren Protokollierung: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html — Erweiterung der Datenschutzregeln für Agenten-Speicher

Studie 'Lost in the Middle' (Stanford, 2023): Wissenschaftliche Schlüsselgrundlage des Phänomens der Kontextdegradierung; suchen Sie nach dem Titel zum Verständnis, warum die Position von Informationen im Kontext kritisch ist

Zusammenfassung: Agenten-Speicher auf SQLite ist eine lokale, transparente und vollständig kontrollierbare Schicht zur Ergänzung des integrierten Speichers von Qwen Code. Kernprinzipien: Trennung roher Ereignisse (events) und dauerhafter Merkzettel (memories), Hooks für Protokollierung und Injektion, Offline-Hintergrundzusammenfassung über dream_sqlite.py, strenge Grenze zwischen operativem Speicher und verbindlichen Spezifikationen. Hauptrisiken — Kontextdegradierung durch übermäßige Injektion und Leckage sensibler Daten. Lösungen: Relevanzfilterung, Begrenzung auf 3-5 Blöcke, regelmäßiges Audit, Geheimnisfilterung in Hooks, kein Commit von .db-Dateien. Erfolgreiche Implementierung erfordert Disziplin: der Speicher hilft, Regeln zu entdecken, aber Spezifikationen machen sie verbindlich.