Dreaming trails now write to dreams.md

davemorin

·Apr 5, 2026·#61537Memory: move dreaming trail to dreams.md

Dreaming output—those fleeting traces from light and REM phases—now lands in its own dedicated file instead of cluttering daily memory notes.

The memory system now keeps dreaming trails separate from canonical memory. When light or REM dreaming phases run, their output goes to a top-level dreams.md file rather than daily memory notes. This means users can inspect what the system was "thinking" during dream phases without wading through daily logs.

The change also makes dreams.md explicitly readable on demand, while deliberately excluding it from default memory indexing and search. It's available when needed, but stays out of the way during normal recall operations.

In the memory-core extension, the dreaming markdown writer was updated to resolve a dedicated path instead of dating content to specific days. The host SDK's memory path allowlist was extended to recognize dreams.md, and the flush plan was updated to treat it as a read-only reference file. Help text throughout now points users to the correct location.

View Original GitHub Description

Summary

Problem: light/REM dreaming trail content was being written into daily memory notes instead of a dedicated dreaming trail file.
Why it matters: dreaming output is useful as an audit/staging trail, but it should stay separate from canonical memory and daily notes.
What changed: dreaming now writes inline trail content to top-level dreams.md, /dreaming help text reflects that path, and explicit memory-file access allows reading dreams.md on demand.
What did NOT change (scope boundary): dreams.md is not included in default memory indexing, search guidance, watcher coverage, or evergreen-memory treatment.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes #
Related #
This PR fixes a bug or regression

Root Cause (if applicable)

Root cause: N/A
Missing detection / guardrail: N/A
Contributing context (if known): N/A

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: extensions/memory-core/src/dreaming-markdown.test.ts, src/memory-host-sdk/host/internal.test.ts, packages/memory-host-sdk/src/host/internal.test.ts
Scenario the test should lock in: dreaming writes trail content to top-level dreams.md while explicit file access still accepts dreams.md without pulling it into default memory recall.
Why this is the smallest reliable guardrail: the change is localized to the dreaming writer path and the memory-path allowlist.
Existing test that already covers this (if any): updated /dreaming command coverage in extensions/memory-core/src/dreaming-command.test.ts
If no new test is added, why not: N/A

User-visible / Behavior Changes

Light and REM dreaming now write their managed trail blocks to top-level dreams.md.
/dreaming help text now points to dreams.md.
dreams.md can be read explicitly as a memory file, but it is not part of normal memory recall/indexing.

Diagram (if applicable)

Before:
[dreaming phase] -> [daily note memory/YYYY-MM-DD.md]

After:
[dreaming phase] -> [dreams.md trail] -> [separate from durable/default memory recall]

Security Impact (required)

New permissions/capabilities? (No)
Secrets/tokens handling changed? (No)
New/changed network calls? (No)
Command/tool execution surface changed? (No)
Data access scope changed? (Yes)
If any Yes, explain risk + mitigation: dreams.md is now explicitly readable as a memory file, but it is intentionally kept out of default search/indexing to avoid broadening normal recall scope.

Repro + Verification

Environment

OS: macOS
Runtime/container: local workspace
Model/provider: N/A
Integration/channel (if any): N/A
Relevant config (redacted): default memory-core dreaming config

Steps

Enable dreaming and let a light or REM phase write trail output.
Inspect the workspace root.
Explicitly read dreams.md.

Expected

Dreaming trail output lands in top-level dreams.md.
dreams.md remains separate from default memory recall/indexing.

Actual

Matches expected in code path; local environment verification is partially blocked.

Evidence

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Human Verification (required)

Verified scenarios: reviewed the final diff, committed the scoped file set, and pushed the branch to the fork.
Edge cases checked: preserved explicit dreams.md read access while removing earlier indexing/search/watcher additions.
What you did not verify: full local Vitest execution. The normal runner hit a sandboxed pnpm cache permission issue, and direct Vitest config runs in this environment fail before collection in the repo's custom non-isolated runner.

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

Backward compatible? (Yes)
Config/env changes? (No)
Migration needed? (No)
If yes, exact upgrade steps:

Risks and Mitigations

Risk: downstream code may still assume dreaming trail content lives in daily notes.
- Mitigation: command/help text and targeted tests now reflect the dedicated dreams.md path.
Risk: explicit read access to dreams.md could accidentally be broadened later into normal recall.
- Mitigation: this PR deliberately removes indexing/search/watcher additions and adds narrow tests around explicit access only.