[Discussion] Dream CE architecture review: feedback wanted on the current design

[CaralHsi]

Dream CE is an early community edition module for offline memory consolidation in MemOS. We would like to invite architecture feedback before turning more ideas into implementation tasks.

Current architecture

Dream CE currently follows a staged pipeline:

Form Motives -> Recall Around Motives -> Consolidation Reasoning -> Diary Summary -> Persistence

Main components:

• MotiveFormation: groups pending memories into dream motives.
• DirectRecall: recalls related memories around each motive.
• ConsolidationReasoning: produces Dream actions and insights.
• StructuredDiarySummary: generates a human-readable diary artifact.
• DreamPersistence: persists Dream-produced memories and diary entries.
• DreamSignalStore: accumulates trigger signals.
• Trigger routers expose Dream execution APIs.

Design intent

The current implementation is intentionally modular. Community contributors should be able to replace or extend:

• signal sources,
• motive formation,
• recall strategy,
• reasoning strategy,
• diary generation,
• persistence policy,
• trigger policy.

Questions

• Does this pipeline structure make sense?
• Are the stage boundaries right?
• Should motive formation happen before recall, or should recall help form motives?
• Should diary generation be separate from memory persistence?
• Should Dream be implemented as a plugin, a scheduler task, or a core memory feature?
• What extension points are missing?
• What should be configurable?
• What should be stable API vs experimental internals?

Desired outcome

We want feedback on the architecture before expanding Dream CE further. Concrete proposals may be converted into follow-up help wanted issues.