/memory-dream

name: memory-dream
scope: common
role_scope: orchestrator-only
description: |
  Curate the workspace memory wiki as its appointed orchestrator. Trigger on a
  Cloud-scheduled Dream task or a user's direct curation request. Inspect candidates
  for orphan leaves, near-duplicates, stale pages, remote conflicts and oversized
  hubs; browse the graph, cluster leaves into INDEX/hub/leaf structure, maintain
  authored overview prose, split hubs, merge duplicates and verify/report changes.
  Use memory_curate and memory_browse; preserve machine-generated hub TOCs and
  graph-derived INDEX Contents. Orchestrator-only: write verbs reject other actors
  with 403. Follow the body for safe mutation and verification procedures.
applies_to: [hermes, claude-code, codex]
version: 4

Memory Dream — orchestrator-driven consolidation

> **Memory pages are PKF (`.pkf`).** When you fold or merge page bodies, the body syntax > (sections, typed links, frontmatter) comes from the **`pkf-writing`** skill — load it > when you author body content, and validate the result before persisting. This skill > only governs the graph: what to merge, where to attach, and how to keep INDEX/hub > ownership straight.

> **Candidate boundary.** Dream sees authoritative **Memory Pages**, not “all PKF.” A > message-inline PKF or Library `.pkf` Asset remains outside this loop. Runtime > automatically classifies durable claims from validated inline PKF; Asset handling > still uses the `memory` skill. Explicitly materialize authoritative inline bytes only > when the user requests exact preservation. Only a resulting Memory Page participates > in candidates, revisions, merges and hub TOCs.

You are (when appointed) the **workspace memory orchestrator**. Your job is the "Dream phase": periodically reorganize the memory wiki so it stays coherent as it grows — merge duplicate hubs, attach satellite pages under the right hub, supersede stale/contradicted pages, keep the top-level INDEX lean, maintain every hub's `#overview` plus the INDEX's authored semantic sections, and split hubs that have grown oversized.

There is one automatic trigger authority: the **Cloud SchedulerService** sweeps every six hours, applies the 24-hour cadence gate plus authoritative wiki-health signals (orphan ratio, oversized INDEX, frontier duplicate cluster, or page-growth burst), deduplicates in-flight work, and dispatches one hidden `memory-dream` task to the bound workspace orchestrator. The Cloud performs no Memory LLM reasoning. The appointed orchestrator executes this skill in its own Runtime and is the sole automatic write actor. A user can also ask that orchestrator to curate immediately; ordinary per-page queries do not trigger Dream. The retired daemon `FF_MEMORY_DREAM_ENABLED` scheduler is not an active trigger path.

> **Authority gate.** The curation write verbs only work for the **appointed workspace > orchestrator** (the workspace owner, or the agent set as `orchestratorAgentId`). > If you are not the orchestrator, every write verb returns `403 orchestrator_only` — > that is expected, not a bug. Do not retry; write-time placement discipline (the > **memory** skill's browse-first flow) is what every agent does, and it is enough.

**Owner vs orchestrator vs deputy (product209/16 MA-2):**

• The **owner** (human) and the **appointed orchestrator**

(`orchestratorAgentId`) are the only Dream write actors. The owner speaking through an agent does NOT grant it Dream rights — the agent itself must hold the orchestrator binding. Dream never back-derives authority from "the owner is talking to me".

• A **deputy** does NOT inherit Dream from its bound member — not even when

the bound member is the owner. A deputy runs Dream write verbs only if the deputy agent itself is the appointed `orchestratorAgentId`.

• `candidates` is the READ half and works for any agent in scope; the write

verbs (`promote_to_hub` / `supersede` / `rebuild_index` and the section-level `section_merge` / `section_supersede` / `rewire`) are the gated half.

• `403 orchestrator_only` and `202 approval deferred` are final per-request

verdicts — do not retry, and do not route around them through another agent.

The verbs

memory_curate(op="candidates")                        # READ what needs work (any agent)
memory_curate(op="candidates", kind="orphans")        # one surface; limit caps per kind
memory_browse(query="<topic>")                        # READ the structure: {index, hubs[+snippet], nearest}
memory_curate(op="promote_to_hub", pageId="<id>",
              childPaths=["<path>", …])               # leaf → hub AND attach children (orchestrator only)
memory_curate(op="supersede", pageId="<id>",
              reason="merged into <path>")            # archive + mark stale (orchestrator only)
memory_curate(op="rebuild_index")                     # regenerate hub TOCs; INDEX Contents stays graph-derived (orchestrator only)
memory_curate(op="section_merge", pageId="<winnerPageId>",
              targetSection="<winnerSlug>", sourcePageId="<loserPageId>",
              sourceSection="<loserSlug>",
              mergedContent="<merged body>")          # fold ONE near-duplicate section (memory211 W5)
memory_curate(op="section_supersede", pageId="<pageId>",
              section="<slug>")                       # retire ONE section in place (memory211 W5)
memory_curate(op="rewire", linkId="<linkId>",
              toPageId="<id>")                        # re-point a broken/wrong link (memory211 W5)

• `candidates` is the READ half: `{candidates:{orphans,duplicates,stale,conflicts,oversized}}`

— unplaced leaves (no outgoing `child-of`/`parent` edge to a live hub; an INDEX `index-anchor` only guarantees reachability and therefore still counts as flat), near-duplicate clusters (`duplicate_cluster:<peerIds>`), stale pages, remote-conflict pages, and oversized hub/INDEX advisories (`kind="oversized"` — size is recorded, never machine-enforced; splitti