Dream / Reflexion

Dream-Vorschauarchitektur und expliziter Überprüfungs-Workflow

Dream ist eine separate, vom Benutzer überprüfte Preview-Funktion, die in der Memory Console unter https://xmemo.dev/me#dream verfügbar ist. Sie unterscheidet sich vom reflect-Wartungstool (das programmgesteuerte Konsolidierungsläufe bei Bedarf über MCP/API ausführt; siehe /docs/tools/reflect). Anstatt stille Hintergrundmutationen durchzuführen, stellt Dream das in den Vordergrund, was der Benutzer überprüft und speichert, und organisiert verstreuten Gesprächskontext in quellengeerdeten Kandidaten.

• Konsolen-Arbeitsbereich: In der Memory Console unter https://xmemo.dev/me#dream bietet Dream einen interaktiven Vorschau-Arbeitsbereich unter dem Untertitel: "Review recurring patterns before they become long-term memory."
• Benutzergesteuerte Überprüfung: Dream ändert persistenten Speicher niemals im Hintergrund; alle Kandidatenelemente erfordern eine explizite menschliche Überprüfung und Bestätigung, bevor Schreibvorgänge am Zielort stattfinden.
• Unterscheidung von reflect: Dream ist eine separate Vorschaufunktion, bei der Kandidaten zur menschlichen Überprüfung generiert werden und nichts ohne explizite Bestätigung gespeichert wird. Im Gegensatz dazu ist der reflect-Wartungslauf (/docs/tools/reflect) ein internes Tool, dessen summarize-Aktion aktive episodische Erinnerungen liest und quellengestützte Zusammenfassungen unter reflections/episodic ablegt. Für wiederkehrende Fakten bietet reflect eine promote-Aktion von episodisch zu semantisch, die eine durchschnittliche Wichtigkeit von mindestens 0.35 und ein durchschnittliches Vertrauen von mindestens 0.6 voraussetzt. Seine Lebenszyklusaktionen führen expire, decay und archive aus, wobei dry_run eine sichere Planung ohne Zielschreibvorgänge ermöglicht.
• Architektonische Grenze: Die Generierung von Dream-Kandidaten ist strikt ein Vorschaumechanismus und implementiert weder eine spekulative Light-, REM- oder Deep-Multipass-Architektur noch autonome Hintergrundmutationen.
• Sicheres Fehlerverhalten: Wenn ein Lauf stoppt oder auf ein Problem stößt, bleibt der vorhandene Speicher unberührt ("Dream stopped safely. Existing memory was not changed.").

Kontoverfügbarkeit, Plankatalog-Status und Vorschaugrenzen

Dream funktioniert ausschließlich, wenn Dream für Ihr Konto aktiviert ist. Alle Laufzeitsteuerungen sind in Produktionsumgebungen standardmäßig deaktiviert. Die öffentliche Dokumentation vermeidet es, interne Konfigurations-Flags preiszugeben.

• Kontoverfügbarkeit: Dream funktioniert ausschließlich, wenn Dream für Ihr Konto aktiviert ist. Wenn die Funktion für einen Arbeitsbereich nicht aktiv ist, zeigt die Konsole an: "Dream is not enabled for this workspace yet. Your memory remains unchanged."
• Katalogstatus: Im Produktplankatalog ist Dream nicht im Free-Tarif enthalten, während der Plus-Tarif Dream-Funktionen aufführt. Die Dokumentation erhebt jedoch keinen Anspruch darauf, dass Plus Dream heute in der Praxis freischaltet, da der persönliche Fallback-Provider den Zugriff verweigert, wenn die kommerzielle Durchsetzung inaktiv ist.
• Defektgrenze: Dream befindet sich derzeit in der Vorschau und generiert für Ihr Konto möglicherweise noch keine Kandidaten. Die modellbasierte Synthese kann nicht direkt in der ausgelieferten Worker-Umgebung ausgeführt werden, und die Kandidatenbestätigung hängt von der Kapazitätskonfiguration des Servers ab.
• Strikte menschliche Bestätigung: Das System erzwingt eine strikte menschliche Bestätigungsgrenze. Die Dokumentation weist alle Behauptungen über automatisches Speichern oder Anhängen im Hintergrund zurück; jedes vorgeschlagene Element erfordert die manuelle Zustimmung des Benutzers.

Lauflebenszyklus, Beleg-Eignung und Filter-Ursachencodes

Ein Dream-Lauf überprüft geeignete Speicherbelege über ein konfigurierbares Beobachtungsfenster (standardmäßig 30 Tage), um wiederkehrende Muster zu identifizieren, ohne Quelldatensätze zu verändern:

• Belegsammlung: Ein Vorschaulauf untersucht aktive, abrufbare episodische Erinnerungen, die innerhalb des Beobachtungsfensters erstellt wurden (anpassbar über --window-days auf bis zu 365 Tage).
• Fundierte Kandidaten: Geeignete Belege werden in wiederkehrende Themen gruppiert, wodurch Kandidatenelemente generiert werden, die mit Quellherkunft und einem Konfidenzwert ("Confidence Score") angezeigt werden.
• Warum Belege gefiltert wurden: In der Konsole berichtet die Laufzusammenfassung unter "Why evidence was filtered" mithilfe standardisierter Ursachen-Chips: score below threshold, insufficient occurrences, insufficient evidence days, insufficient query contexts, duplicate candidate, source not episodic, source inactive und contradiction detected.
• Inhaltsfreie Laufzusammenfassung: Abgeschlossene Läufe zeigen eine Überprüfungszusammenfassung an: "Dream reviewed {{considered}} signals, generated {{generated}} grounded candidates, and saved {{promoted}} confirmed memories.", begleitet von der Sicherheitsgarantie: "This report is review-only and never becomes Dream evidence."

Konsolen-Betriebsmodi und Zeitplan-Voreinstellungen

Die Dream-Einstellungen bieten eine granulare Kontrolle über Ausführungsmodi und Bewertungszeitpläne im Einstellungsbereich der Konsole:

• Betriebsmodi: Benutzer wählen zwischen zwei Verhaltensmodi: "Preview only" (wertet Belege aus und generiert überprüfbare Kandidaten ohne Schreibberechtigung) und "Allow explicit confirmation" (aktiviert die Bestätigungsoberfläche, sodass Benutzer einzelne Kandidaten überprüfen und selektiv festschreiben können).
• Zeitplan-Voreinstellungen: Die Ausführungshäufigkeit wird über drei Voreinstellungen konfiguriert: "Manual only" (wird nur auf Anforderung ausgeführt, wenn in der Konsole "Run Preview" ausgewählt oder ein CLI-Vorschaubefehl erteilt wird), "Daily around 03:00" (täglich geplanter Lauf, der um 03:00 Uhr in der lokalen Zeitzone des Benutzers ausgewertet wird) und "Weekly on Monday around 03:00" (wöchentlich montags um 03:00 Uhr in der lokalen Zeitzone des Benutzers ausgewertet).
• Einschränkung für geplante Läufe: Geplante Läufe arbeiten im Modus preview only; Hintergrundauswertungen führen niemals Schreibvorgänge im Speicher durch oder umgehen die menschliche Überprüfung.
• Zeitzonenverankerung: Geplante Läufe verwenden die lokale Zeitzone des Benutzerbrowsers.

Bestätigungs-Workflow, typisierte Ergebnisse und Ziel-Lebenszyklus

Das Festschreiben von Kandidaten erfolgt append-only und erfordert eine explizite Benutzeraktion. Die Konsole unterstützt Einzelposten-Bestätigung und optionale typisierte Ergebnisse:

• Kernbestätigung: Im Standard-Vorschaumodus erstellt das Klicken auf die Schaltfläche "Confirm and save" auf einer Kandidatenkarte einen NEUEN Speichereintrag unter dem Pfad dream/confirmed/... mit dem semantischen Schlüssel dream:confirmed:... . Quellerinnerungen werden niemals bearbeitet oder überschrieben.
• Konfiguration typisierter Ergebnisse: Wenn typisierte Ergebnisse verfügbar sind, stellt der Einstellungsbereich die Frage "What should Dream prepare?" mit dem Leitfaden "Choose what to generate. Turning a type off keeps existing drafts and saved content."
• Sechs Generierungsauswahlen: (1) Preferences: "Clarify your preferences"; (2) Knowledge: "Distill knowledge worth keeping"; (3) Skills: "Turn experience into reusable skills"; (4) Projects: "Organize project memory"; (5) Patterns: "Discover lasting patterns"; (6) Durable Memory: "Build reusable long-term memory".
• Generierungsschalter vs. Zustimmung zum Zielort: Das Aktivieren eines Generierungsschalters erteilt keine Zustimmung zu einem Zielort; alle vorbereiteten Ergebnisse erscheinen unter "Prepared for your review" und erfordern eine manuelle Überprüfung.
• Kandidaten-Überprüfungsaktionen: Prüfer können "Save edits" auswählen, um vorgeschlagene Titel und Inhalte zu ändern, "Review later", um aufzuschieben, "Reject", um zu verwerfen, oder in das Ziel übernehmen.
• Akzeptanz pro Zielort: Knowledge akzeptiert über "Add draft to knowledge base" in eine ausgewählte Wissensdatenbank als DRAFT (mit Suchindizierungszuständen: "Saved. Preparing for search.", "Search index is ready. Publication is a separate choice.", "Saved, but indexing needs another attempt."); Skill akzeptiert über "Add draft to Cloud Skills" als DRAFT; Project akzeptiert über "Confirm project organization" (die Projekt-Zuordnungsoption ist der einzige Pfad, der bestehende Erinnerungen einem Projektarbeitsbereich neu zuweist); Memory akzeptiert über "Save as memory".
• Entfernung: Bestätigte Ergebnisse werden zu Standarderinnerungen, Wissensentwürfen oder Skill-Entwürfen in ihren jeweiligen Speichern. Sie werden über Standard-Konsolen- oder API-Entfernungsaktionen gelöscht; es gibt keinen Dream-spezifischen Rollback- oder Undo-Mechanismus.

Arbeitsbereichsisolation, Teamgrenzen und CLI-Operationen

Arbeitsbereichsberechtigungen und CLI-Tools setzen strenge mandantenfähige Grenzen und Rollenfunktionen durch:

• Arbeitsbereichs-Scoping: Die Kopfzeile der Konsole identifiziert den aktiven Arbeitsbereich entweder als "Personal space" oder als "Team space".
• Teamberechtigungen: In Teamräumen können nur Team-Owner und Admins Dream-Einstellungen ändern, aktive Läufe abbrechen oder Kandidatenerinnerungen bestätigen ("Only Team owners and admins can change Dream settings.").
• Einschränkung für typisierte Ergebnisse in Teams: Typisierte Ergebnisse sind in Teamräumen nicht verfügbar. Team-Arbeitsbereiche arbeiten im Modus preview-only oder v1 memory confirmation.
• Verifizierte CLI-Befehle: Die xmemo CLI (fixierter Commit d412c7866b7a4c8eedb3a0cf40748c6aef8707ec, src/commands/dream.js) unterstützt drei verifizierte Befehle: xmemo dream preview [--window-days <n>] [--wait] [--json] (löst Vorschau aus; schlägt fehl, wenn die Vorschau deaktiviert ist, mit "Dream preview is disabled; CLI will not change Dream settings."), xmemo dream show <run-id> [--wait] [--json] (zeigt Kandidatenelemente an; unterstützt --receipt-out für Lesebestätigungen) und xmemo dream apply <run-id> --item <id> --from <view.json> --yes [--json] (bestätigt einen Kandidaten über den v1 confirm-Endpunkt).
• Operative Grenzen der CLI: Die CLI kann die Dream-Konfigurationseinstellungen nicht ändern (Einstellungen müssen in der Konsole verwaltet werden), und dream apply arbeitet ausschließlich mit v1 memory confirmation (führt keine typisierten Ergebnismutationen durch).

# Trigger a candidate preview across a 30-day window
xmemo dream preview --window-days 30 --wait --json

# Inspect candidate proposals and record a read receipt
xmemo dream show <run-id> --receipt-out receipt.json

# Confirm a candidate proposal into memory via v1 confirmation
xmemo dream apply <run-id> --item <item-id> --from view.json --yes