Dreamer policy is hardcoded to software-development workflows — make per-project policy configurable (task prompts, memory categories, maintained docs)

[Ema-prowler]

Short description

Magic Context's memory machinery (historian, dreamer, injection) works well as a mechanism, but its policy layer is hardcoded to software development: the dreamer task prompts, the memory taxonomy, and the maintained docs list are compiled into the plugin and cannot be adapted to non-code projects (security, research, operations, writing, etc.). For a project that is not a code repository, the system still classifies memories with development-oriented categories and maintains ARCHITECTURE.md / STRUCTURE.md as if every project were a repo.

What problem does this solve?

The plugin manages each project's memory with a fixed policy designed for
software repositories. That policy shows up in three places:

1. The dreamer runs its tasks (curation, verification, user-memory review,
   documentation maintenance) with internal prompts written in development
   language. For a project that is not code, the agent classifies and
   organizes memory with the wrong perspective: it looks for "testing
   conventions", "releases" or "commits" where none exist.

2. Memory categories are locked to a development taxonomy (PROJECT_RULES,
   ARCHITECTURE, CONSTRAINTS, CONFIG_VALUES, NAMING). Memories from other
   domains get forced into categories that do not represent their real
   work, degrading curation usefulness.

3. Documentation maintenance is fixed to ARCHITECTURE.md and STRUCTURE.md,
   software architecture files. Projects that are not code repositories
   receive documentation that does not fit them, or cannot maintain the
   documentation that would actually serve them.

The result: the memory mechanism (historian, compaction, injection) works
for any project, but the policy layer limits it to development projects.
Users from other domains end up with less useful classification, irrelevant
documentation, and dreamer prompts that do not understand their work.

Proposed solution

Decouple the MECHANISM (historian, compaction, injection, storage — the core
of how the plugin stores, organizes and recalls memory) from the POLICY (how
the dreamer should think about THIS project). The core must remain intact;
the proposal is to open the policy layer to configuration so each project
can adapt it to its domain:

1. Project awareness for the dreamer.
   The dreamer runs tasks (curation, verification, user-memory review, doc
   maintenance, etc.), each with an internal system prompt. Today those
   prompts are fixed and speak in development language (codebase, repo,
   releases, testing). The proposal: let the user give the dreamer an
   orientation about what this project is and how it should treat its
   memories, without replacing the task mechanism — only adapting the
   perspective with which tasks are executed.

2. Configurable memory categories.
   The category taxonomy is fixed (PROJECT_RULES, ARCHITECTURE, CONSTRAINTS,
   CONFIG_VALUES, NAMING) and oriented to software repositories. The
   proposal: let the user define the categories their project uses, so
   curation classifies memories into the categories that actually exist in
   their work.

3. Configurable maintained docs.
   Documentation maintenance is fixed to ARCHITECTURE.md and STRUCTURE.md.
   The proposal: let the user choose which documentation files should be
   maintained (and with what content instructions for each), instead of a
   fixed list.

4. Non-code project mode (optional).
   A convenience mode that pre-configures the points above for projects
   that are not code repositories: disables development-oriented language
   and repo doc maintenance, keeps memory curation with user-defined
   categories, and focuses historian/review prompts on the project's real
   work type. It would solve the root problem for those who want it, but
   it is optional.

graph TD;
    A[TODAY - Policy welded to code] --> B[Dreamer task prompts fixed with dev-oriented language];
    A --> C[Memory categories fixed to dev taxonomy];
    A --> D[Maintained docs fixed to ARCHITECTURE.md and STRUCTURE.md];
    B --> E[Dreamer agent thinks in codebase / repo / releases];
    C --> E;
    D --> E;
    E --> F[Result: less useful curation and irrelevant docs for non-code projects];
    G[PROPOSAL - Configurable per-project policy] --> H[Project awareness - user tells the dreamer what this project is];
    G --> I[Memory categories defined by the user];
    G --> J[Maintained docs chosen by the user with content rules];
    G --> K[Non-code project mode - optional, pre-configures everything];
    H --> L[Dreamer agent understands your domain];
    I --> L;
    J --> L;
    L --> M[Result: useful curation and relevant docs for any project];
    E --> N{Transition};
    N -->|decouple mechanism from policy| H;

Loading

Alternatives considered

1. Fork the plugin and maintain it ourselves.
   Rejected: a fork forces perpetual sync with upstream for what is a
   configurability change.

2. Externalize dreamer prompts to files (templates/).
   Viable as an implementation, but less discoverable than the existing
   magic-context.jsonc configuration, which is the pattern the plugin
   already uses (schedules, models, thresholds).

3. Do nothing and use the plugin with defaults only.
   Rejected for non-dev projects: classifying into development categories
   and maintaining repo docs adds noise and tokens to projects that don't
   need them.

4. Hardcode a domain-specific category set as an additional option.
   Rejected: it would solve one specific case but reproduce the same
   problem for the next domain. The right fix is letting the user define
   their own categories.

Area

OpenCode plugin

Additional context

Real use case: a work project that is not a code repository — it contains
per-topic work folders, findings, operational data and methodology, with no
source code, commits or releases. Current behavior:

• Curation classifies memories into development categories that do not map
  to the project's real work (result: less useful curation, forced or
  skipped classification).
• Doc maintenance keeps ARCHITECTURE.md and STRUCTURE.md in sync even
  though those files describe software layers the project does not have.
• User memories accumulate slowly because the review prompt is tuned for
  recurring dev workflows, not for other types of work sessions.

Acceptance criteria:

• The dreamer receives configurable orientation about the project type
• Memory categories are user-configurable
• The maintained docs list and their content instructions are configurable
• Default behavior unchanged when no custom config is present
• Documented in the config schema and README

[Ema-prowler]

Efficiency impact
The development-oriented policy does not only produce less useful
classification — it also consumes resources unnecessarily:

1. Wasted tokens. The dreamer runs its tasks with long system prompts
   written for software development. For a non-code project, much of that
   context does not apply: the agent reads, analyzes and classifies
   memories looking for concepts that do not exist in the project
   (releases, commits, testing). Every run spends tokens on a frame that
   does not fit.

2. Fewer iterations. By aligning the dreamer prompt with the project's
   real domain, the agent classifies and decides correctly the first
   time: no back-and-forth to reinterpret memories that do not fit dev
   categories, and no corrective re-curation.

3. Less dreamer workload. By disabling what does not apply (repo doc
   maintenance, dev categories) and focusing tasks on what does, each run
   processes less volume with more accuracy.

4. More speed. Shorter, focused prompts = faster model responses on every
   dreamer task.

5. Dreamer at higher frequency. By reducing the per-run cost (tokens and
   time), running the dreamer more often becomes viable — for example on
   active projects where today it makes sense to space runs out because
   each one spends too much on context that does not apply.

The result: the same memory quality with less consumption, or more
maintenance frequency with the same token budget.

[magic-alfonso]

You've read the architecture correctly, and we're committing to fixing it the way you suggest: the compaction/memory/dreamer machinery is genuinely domain-neutral, and the software-development shape lives in a thin, enumerable policy layer (the memory taxonomy, the historian's fact-extraction fragment, the dreamer task set and its maintained-docs targets, commit detection). That layer will become configurable.

The shape we've settled on is versioned policy packs rather than per-field configuration:

• A pack bundles a memory taxonomy, the historian/classifier prompt fragments, the dreamer task set, and doc-maintenance targets as one coherent, versioned unit selected per project.
• The default pack reproduces today's behavior byte-for-byte, so existing projects see zero change.
• We will ship at least one non-software pack ourselves to prove the seam, and custom user-authored packs are part of the commitment — that's the real enabler for domains we'd never think to ship.
• Two hard constraints, stated early: pack selection can live in project config, but pack content (prompts especially) is user-level or shipped-with-the-plugin only — repository-supplied prompt text for the hidden agents is an injection surface we deliberately strip today, and that stays. And switching a project's pack is an explicit migration event (we have precedent machinery from an earlier taxonomy migration), never a silent config read, because a taxonomy drifting under a live memory pool corrupts classification and sharing quietly.

Why free-form categories lose to packs: category names look like display strings but actually key memory dedup, workspace sharing gates, cross-category merge protection, and classification calibration. An open set fragments memory pools and silently breaks sharing semantics; a closed per-pack set keeps every project internally coherent.

On timing, honestly: no date. This lands after an engine consolidation we're mid-way through — Magic Context's transform and background machinery is moving into a shared native engine (the Rust workspace in this repo), with the TypeScript plugin reducing to thin host hooks. Policy packs will be implemented once, in that engine, served identically to every harness — rather than twice in a layer that's being retired. When the pack format spec is written we'll link it here; design input on it is welcome, and a domain pack authored by someone who actually lives in that domain would be a first-class contribution.