openclaw - 💡(How to fix) Fix Dreaming deep promotion should support a review queue before writing to MEMORY.md [1 participants]

Summary

memory-core Dreaming currently writes deep-phase promoted candidates directly into MEMORY.md as ## Promoted From Short-Term Memory (...) blocks. I would like maintainers' guidance on whether this final write path should be configurable so promoted output can land in a separate review queue first, instead of mutating MEMORY.md automatically.

This is related to, but distinct from, the existing pollution/raw-snippet reports:

• #67363: deep promotion writes raw verbatim daily-log snippets into MEMORY.md
• #67442: transport/session metadata can survive into promoted long-term memory
• #66412: dreaming.storage.mode: "separate" prevents phase blocks from polluting daily memory files, but does not separate the final promoted-memory write

Current behavior

The existing dreaming.storage.mode: "separate" setting separates Dreaming phase/report artifacts, but deep promotion still appends the final promoted entries directly to MEMORY.md.

That means MEMORY.md is both:

1. the curated long-term memory file described by the docs as durable facts/preferences/decisions, and
2. the automatic write target for scored short-term candidates.

In practice, those two roles can conflict. Even when candidate scoring is working as intended, automatic append-only promoted blocks can accumulate raw snippets, routine daily-log fragments, cron/task details, or other material that still needs human/agent distillation before it belongs in canonical long-term memory.

Why this matters

MEMORY.md is a high-impact bootstrap file. If it grows with unreviewed promoted blocks, it can:

• degrade the signal quality of long-term memory,
• push curated content toward bootstrapMaxChars truncation,
• make operators treat auto-generated candidates as canonical memory,
• require manual cleanup after the fact rather than review before commit.

This becomes especially noticeable for personal-assistant workspaces where MEMORY.md is expected to remain a compact constitution of durable preferences and decisions, while daily notes and Dreaming artifacts are allowed to be noisier and more exploratory.

Proposal

Add a configuration option for deep promotion output, for example:

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "phases": {
              "deep": {
                "promotionWriteMode": "review" // "memory" | "review" | "both" | "off"
              }
            }
          }
        }
      }
    }
  }
}

Possible modes:

• memory current behavior: append directly to MEMORY.md.
• review: write promoted candidates to a separate review surface only, such as memory/dreaming/promotions/YYYY-MM-DD.md, memory/dreaming/deep/YYYY-MM-DD.md, or DREAMS.md metadata.
• both: keep current append while also writing a structured review artifact.
• off: rank/report candidates but do not persist promoted entries.

The review artifact could preserve the current marker, score, source, and snippet metadata. A later command or UI action could approve/distill selected candidates into MEMORY.md.

Expected result

Operators can keep Dreaming enabled and continue benefiting from ranking/recovery, while preserving MEMORY.md as a curated long-term memory file.

A workflow would become:

1. Dreaming ranks and stages durable candidates.
2. Deep phase writes candidates to a review queue.
3. Human or agent reviews/distills them.
4. Only approved/distilled facts/preferences/decisions are written into MEMORY.md.

Questions

• Is direct append to MEMORY.md considered the intended final design, or mainly the first shipped write path?
• Would maintainers prefer a config flag, a separate CLI flow, or an always-on review artifact plus optional direct append?
• Should dreaming.storage.mode: "separate" eventually cover final promotion output too, or should promotion write mode be a separate setting?