dream

Do agents dream of electric sheep?
Nächtlicher Memory-Maintenance-Worker für OpenClaw.

Repo/Projektname: agentic-dreams
Skill-Name (intern): dream

Zweck

dream verarbeitet typischerweise jede Nacht genau ein älteres Daily Memory und leitet daraus drei mögliche Bewegungen ab:

1. das Daily selbst verdichten
2. stabile, aktive Langzeitinformation nach MEMORY.md übernehmen
3. sekundäre, verdrängte oder nicht mehr aktiv führende Information nach SUBCONSCIOUS.md ablegen

Grundprinzip

Nicht heroisch. Nicht kreativ-chaotisch. Konservativ.

dream arbeitet so:

• das LLM beurteilt und editiert direkt Daily, MEMORY.md und SUBCONSCIOUS.md im Agent-Workspace
• scripts/dream_state.py verwaltet nur dream-state.json, Hashes, Cursor und Idempotenz
• ein kompaktes Run-Log dokumentiert den Lauf für Menschen

Projekt vs. Runtime

Wichtig: Dieses Repo ist Skill-/Projektcode, nicht der operative Speicherort.

• Projekt/Skill enthält Doku, Skripte und Beispiele
• Runtime-Daten liegen im Agent-Workspace

Zur Laufzeit gehören also in den Ziel-Workspace des Agents:

• MEMORY.md
• SUBCONSCIOUS.md
• memory/*.md
• memory/dream-log/*.md
• memory/dream-state.json

scripts/dream_state.py arbeitet deshalb nicht relativ zum Skillordner, sondern gegen einen explizit übergebenen Workspace:

py scripts/dream_state.py --workspace <agent-workspace> show

Gedächtnismodell

• Daily Memory = episodisches Rohmaterial: Was ist passiert?
• MEMORY.md = aktives, kanonisches Langzeitgedächtnis: Was soll dauerhaft aktiv erinnert werden?
• SUBCONSCIOUS.md = latenter, verdrängter oder sekundärer Kontext: Was soll nicht aktiv vorne liegen, aber auch nicht ganz verloren gehen?

Wichtige Guardrails

• Nie MEMORY.md komplett umschreiben
• Nie heutige oder gestrige Daily-Datei verdichten
• memory_search als Evidenz nutzen, aber nicht als alleinige Entscheidungsinstanz behandeln
• Dauerhafte Dubletten zwischen MEMORY.md und SUBCONSCIOUS.md vermeiden
• Idempotent arbeiten: keine doppelten Übernahmen
• Jede Änderung mit einem einzigen nachvollziehbaren Run-Log dokumentieren

Struktur

Im Projekt / Skill

• skill/ – eigentlicher AgentSkill
• docs/ – Design, Regeln, Obsoleszenz-Heuristik, State-Schema
• scripts/dream_state.py – Interface zu dream-state.json im Ziel-Workspace
• examples/dream-state.example.json – Beispiel für den maschinenlesbaren State
• examples/dream-log/README.md – Beispielhinweis für menschenlesbare Run-Logs

Deployment

Einfach den ganzen Projektinhalt in den Ziel-Skill-Ordner kopieren, also auch docs/ und examples/.

Installationsempfehlung (kompakt):

• Distribution/Repo: agentic-dreams
• Zielskill im Workspace: skills/dream/
• Skill-Aufrufname bleibt: dream

Wichtig dabei:

• das Skript läuft aus dem Skill-Ordner
• die operativen Dateien liegen trotzdem nur im Agent-Workspace
• scripts/dream_state.py immer mit --workspace <agent-workspace> aufrufen

Zur Laufzeit im Agent-Workspace

• MEMORY.md
• SUBCONSCIOUS.md
• memory/YYYY-MM-DD.md
• memory/dream-log/YYYY-MM-DD.md
• memory/dream-state.json

Nightly Flow

1. relevantes State-/Cursor-Kontextfenster aus memory/dream-state.json im Agent-Workspace holen (show + pending)
2. genau ein älteres Daily im Agent-Workspace auswählen: standardmäßig die älteste offene Daily-Datei laut cursor.nextDailyCandidate
3. Daily semantisch beurteilen und direkt bearbeiten
4. SUBCONSCIOUS.md nur bei Bedarf öffnen (wenn pendingReview vorhanden ist oder neue Kandidaten entstehen)
5. Ableitungen nach MEMORY.md und SUBCONSCIOUS.md direkt eintragen
6. erst danach offene pendingReview-Fälle gegen die neuen Signale prüfen und gezielt aktualisieren (pending-update / pending-apply)
7. memory/dream-state.json aktualisieren (record, optional --pending-review-json bei vollständiger Ersetzung)
8. Run-Log append-basiert in memory/dream-log/YYYY-MM-DD.md schreiben

Wann direkt nach SUBCONSCIOUS?

Direkt vom Daily nach SUBCONSCIOUS.md dürfen nur Inhalte, die nicht aktiv-langzeitwürdig sind, aber als Hintergrundsignal erhalten bleiben sollen, zum Beispiel:

• verdrängte Zwischenstände
• verworfene, aber aufschlussreiche Hypothesen
• frühere Workarounds
• sehr spezifische Kontextreste mit möglichem späterem Erklärwert
• Dinge, die helfen könnten spätere Änderungen in MEMORY.md zu verstehen

Nicht dorthin gehören:

• banaler Tagesmüll
• triviale To-do-Reste
• Einmaligkeiten ohne späteren Wert

memory_search praktisch einsetzen

Nutze memory_search gezielt, bevor du Inhalte nach MEMORY.md oder SUBCONSCIOUS.md verschiebst:

• prüfe, ob dieselbe Entscheidung oder Präferenz bereits in MEMORY.md verankert ist
• prüfe, ob ein ähnlicher Kontext bereits in SUBCONSCIOUS.md liegt
• suche nach neueren Gegenbelegen, wenn ein Eintrag suppressionsverdächtig ist

Nicht nötig für jede triviale Daily-Kürzung; nötig für semantische Promotion-/Suppression-Entscheidungen.

Erster Start

Wenn memory/dream-state.json im Agent-Workspace noch nicht existiert, ist das kein Problem.

• scripts/dream_state.py arbeitet mit einem Default-State
• beim ersten Schreibvorgang wird die Datei angelegt
• sinnvoller Einstieg:

py scripts/dream_state.py --workspace <agent-workspace> refresh-cursor

show funktioniert auch ohne bestehende Datei; refresh-cursor schreibt den ersten sinnvollen State.

Wenn SUBCONSCIOUS.md im Agent-Workspace noch fehlt, darf sie bei Bedarf mit knapper Grundstruktur neu angelegt werden.

Geplante Cron-Nutzung

Typisch nachts, z. B. 03:30 Europe/Vienna.

Empfohlen zunächst:

1. genau ein Daily pro Nacht, aber nie das von gestern
2. cursor.nextDailyCandidate und processedDailies sauber pflegen
3. pending-suppression konservativ und kontextabhängig auflösen (Tempo je nach Evidenz/Schweregrad)
4. State klein und nützlich halten