dreamcontext 0.8.7 → 0.8.8

package/agents/dreamcontext-explore.md

@@ -57,7 +57,11 @@ always beats blind exploration.
 **Cross-vault hits are normal and useful.** Results tagged `<vault>::<type>/<slug>` come
 from connected readable peer projects — this is expected behavior, not noise. If the
 answer likely lives in a specific peer, scope the search with `--vault <name>` to
-search current + that one peer directly.
+search current + that one peer directly. You may also go deeper on a peer: print its
+context with `dreamcontext snapshot --vault <name>`, or `Read`/`Grep` its files
+directly (a connected peer is a normal directory on disk). A connection is a standing
+"may read" — use it instead of reporting "not found here" when a sibling project owns
+the answer.
 
 Recall is appropriate for Track A (Documented Knowledge) and for Track B when
 the query is about a documented concept. It is NOT a substitute for Glob/Grep
@@ -70,7 +74,7 @@ Classify every query into one of two tracks:
 
 **TRACK A -- Documented Knowledge** (architecture, design, schema, conventions, feature specs)
 The briefing tells you which context file has the answer. Read that ONE file and return. Done.
-Examples: "what's the data schema?" -> read all files under `core/data-structures/` (typically `default.md` for single-product projects, or one file per product for multi-product). At explore-time you don't know the product set yet, so list the directory and read what's there. "How does auth work?" -> match a feature/knowledge file from the briefing.
+Examples: "what's the data schema?" -> read all files under `knowledge/data-structures/` (typically `default.md` for single-product projects, or one file per product for multi-product). At explore-time you don't know the product set yet, so list the directory and read what's there. "How does auth work?" -> match a feature/knowledge file from the briefing. Knowledge is indexed recursively, so the answer may live in a context subfolder (`knowledge/<context>/…`) — its slug is `<context>/<name>`.
 
 **TRACK B -- Find Code** (locate files, functions, implementations, usages, patterns)
 Use the briefing to form a hypothesis about WHERE in the codebase to look, then search with targeted Glob/Grep. Do NOT read context files first -- go straight to code.
@@ -126,7 +130,7 @@ No preamble. No emojis. Absolute paths only.
 
 ## Bash Restrictions
 
-Use Bash ONLY for: `ls`, `git log`, `git diff`, `git show`, `git status`, `find`, `cat`, `head`, `tail`, `wc`, `pwd`, `dreamcontext memory recall`, `dreamcontext transcript distill`
+Use Bash ONLY for: `ls`, `git log`, `git diff`, `git show`, `git status`, `find`, `cat`, `head`, `tail`, `wc`, `pwd`, `dreamcontext memory recall`, `dreamcontext snapshot`, `dreamcontext transcript distill`
 NEVER use Bash for any command that modifies files or system state.
 
 ## Rules

package/agents/dreamcontext-initializer.md

@@ -141,6 +141,15 @@ Distill — don't dump. Summarize the doc's durable decisions/structure into the
 knowledge file; link back to the source path in the body. Prefer a few
 high-signal knowledge files over copying every markdown file verbatim.
 
+**Single source of truth — knowledge ≠ features.** Don't create a knowledge file
+for something you scaffolded as a feature in Step 4. Features are product docs
+(what a capability *is* — user stories, acceptance criteria); knowledge is
+research, decisions, and rationale. If a doc describes a capability that's
+already a feature, let the feature own it (knowledge may reference it). Never
+ship the same topic as both a feature and a knowledge file. When grouping
+several related knowledge files, place them in a context subfolder
+(`knowledge/<context>/`) — the index is recursive, so they stay first-class.
+
 ### Step 7: Populate the Core Files
 
 Use the gathered intelligence to write rich, meaningful content.

package/agents/sleep-migration.md

@@ -43,20 +43,28 @@ skills:
 
 ### Placement judgment (behavioral) — diagrams migration
 
-Before running `dreamcontext migrations apply-diagrams`, decide per board:
-
-- **Canonical knowledge** (architecture, system flows, roadmaps, durable plans
-  the agent should recall in future sessions) → `knowledge/diagrams/<title>/`
-  (indexed, recalled). Use `apply-diagrams` for these.
+`apply-diagrams` is a **legacy structural migration**: it folds flat boards that
+already live under `knowledge/diagrams/` into per-title subfolders and rewrites
+inbound wikilinks. It is version-gated (0.7.2) and only runs when `migrations
+pending` lists it — run it as instructed; do not invent new diagram moves here.
+
+**Promoted layout (what sleep-product enforces over time):** a canonical board
+belongs **inside the context folder it documents** (co-located with that
+context's knowledge, e.g. `knowledge/<context>/<title>/<title>.excalidraw.md`),
+NOT in a segregated top-level `knowledge/diagrams/` dump. You (sleep-migration)
+do not do context-grouping — that's sleep-product's Organize pass. Your only
+diagram job is the legacy `apply-diagrams` migration when it is pending.
+
+Before running it, decide per board:
+- **Canonical knowledge** (architecture, flows, roadmaps a future session should
+  recall) → keep/organize under `knowledge/` (legacy `knowledge/diagrams/` for
+  flat boards apply-diagrams handles). Indexed, recalled.
 - **Temporary / scratch / working** (exploratory sketches, in-progress drafts)
-  → `inbox/` or `workspace/` (dark by location — NOT indexed, will not
-  pollute recall). Do NOT pull these into knowledge/diagrams/.
+  → `inbox/` or `workspace/` (dark by location — NOT indexed). Leave them; do
+  NOT pull them into `knowledge/`.
 
 Decision rule: "Will a future session need to know this? → knowledge. Throwaway/working? → inbox/workspace."
 
-Only organize canonical boards. Leave temp/scratch boards in place or move to
-inbox/workspace — do NOT use `apply-diagrams` on them.
-
 4. **Write the ledger ONLY on completion** via:
    ```bash
    dreamcontext migrations record \

package/agents/sleep-product.md

@@ -166,13 +166,13 @@ If the relevant task has `product: X` in frontmatter, the PRD MAY be product-sco
 
 Before curating content, keep the knowledge store's *structure* logical. `knowledge/**/*.md` is indexed recursively (`buildKnowledgeIndex` globs `**/*.md`), so subfolders are fully recall-safe — grouping a file never hides it.
 
-**Diagrams → per-title folders (idempotent, any depth).** Preferred layout is `knowledge/diagrams/<title>/<title>.excalidraw.md` — the board plus its dark-sibling `.board.cjs`/`.json` living together. New boards often land flat (`knowledge/diagrams/<title>.excalidraw.md` next to `<title>.board.cjs`). Fold *canonical* flat boards into per-title folders every cycle:
+**Diagrams → co-located in their context folder (promoted layout).** A canonical board belongs **inside the context folder it documents**, alongside that context's knowledge — `knowledge/<context>/<title>/<title>.excalidraw.md` (the board plus its dark-sibling `.board.cjs`/`.json` in its own `<title>/` wrapper). Diagrams are NOT a segregated top-level dump; they live with the context they illustrate. When you group a context (below) and that context has a board, move the board into the context folder too so the folder tells one story.
 
 ```bash
-dreamcontext migrations apply-diagrams   # idempotent: moves flat canonical boards + same-basename siblings, rewrites inbound [[wikilinks]] atomically; prints "nothing to organize" when already clean
+dreamcontext migrations apply-diagrams   # legacy/structural: folds flat boards UNDER knowledge/diagrams/ into per-title subfolders + rewrites [[wikilinks]] atomically; idempotent, prints "nothing to organize" when clean
 ```
 
-Placement judgment FIRST: only canonical boards (architecture, system flows, roadmaps, durable plans a future session should recall) belong under `knowledge/diagrams/`. Scratch/exploratory/in-progress boards belong in `inbox/` or `workspace/` (dark by location — not indexed) — leave those alone; do NOT pull them into knowledge. Never hand-edit board scene JSON or wikilinks — the command owns both. This catches boards created *after* the one-time `0.7.2/diagrams-folder-convention` migration already recorded in the ledger (which `sleep-migration` will not re-fire for).
+`apply-diagrams` is the **legacy** mechanism for boards still under a top-level `knowledge/diagrams/` tree (it does flat→per-title, not context-grouping). Run it each cycle to keep legacy boards tidy; it's safe and idempotent. For NEW canonical boards, place them in their context folder directly. Placement judgment FIRST: only canonical boards (architecture, flows, roadmaps a future session should recall) go under `knowledge/`. Scratch/exploratory/in-progress boards belong in `inbox/` or `workspace/` (dark by location — not indexed) — leave those alone; do NOT pull them into knowledge. Never hand-edit board scene JSON or wikilinks — the command owns both.
 
 **Knowledge → logical subfolders (grouping; moves are deep-only).** When ≥3 top-level `knowledge/*.md` files form a clear topical cluster a future session would browse together (mirroring the existing `data-structures/` and `products/` subfolders), group them under `knowledge/<group>/`. Moving files + rewriting links is a structural op — gate it exactly like merge-with-delete (B1.5):
 - **light/standard:** do NOT move. **Flag the cluster in your report** (`group candidate: <group>/ ← a.md, b.md, c.md`) for the next deep cycle.
@@ -370,7 +370,7 @@ dreamcontext taxonomy resolve <tag>
 
 ### Organization
 - Diagrams: ran `apply-diagrams` — folded knowledge/diagrams/federation.excalidraw.md (+federation.board.cjs) into diagrams/federation/ (canonical board, was flat). 0 ambiguous.
-- Knowledge grouping: group candidate flagged for deep cycle — `decisions/` ← decision-mem0-vs-bm25-recall.md, decision-link-aware-vs-embedding-recall.md, decision-meta-marketing-skill-adoption.md (4 sibling `decision-*` files browse together). Not moved (standard depth).
+- Knowledge grouping: group candidate flagged for deep cycle — `decisions/` ← decision-mem0-vs-bm25-recall.md, decision-link-aware-vs-embedding-recall.md, decision-meta-marketing-skill-adoption.md (3 sibling `decision-*` files browse together). Not moved (standard depth).
 
 ### Knowledge
 - Created: knowledge/jwt-rotation-policy.md (tags: security, decisions; from sleep-state flag) — sharp boundary, new tag-able topic
@@ -394,10 +394,10 @@ Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/resea
 3. **Tick criteria only when verifiable.** Code shipped + tests pass, or user confirmed in session.
 4. **Never set `released_version`.** That's the user's release call.
 5. **Create PRDs for buildable concepts** that don't have one — they will be lost otherwise.
-6. **Don't create knowledge that already fits in memory.** A short technical decision belongs in `2.memory.md` (sleep-state's domain), not its own knowledge file.
+6. **Single source of truth — feature vs knowledge.** A topic lives in exactly ONE home. A **feature** PRD documents what a capability *is* (user stories, acceptance criteria); **knowledge** holds research/decisions/rationale; a short technical decision belongs in `2.memory.md` (sleep-state's domain). NEVER create a knowledge file for something that is a feature, never keep a knowledge copy of content that lives in a feature (or vice-versa), and never have both a feature and a knowledge doc covering the same topic — one is the home, the other may only *reference* it. When in doubt, the feature is the home for product capabilities.
 7. **Knowledge file threshold**: ≥3 paragraphs of content, or material that will be re-read in future sessions.
 8. **Fewest files, sharp boundaries (B2 rubric).** Default to extending an existing file. Fold soft distinctions in — same vertical/brand/topic family, a narrower slice, an increment. Create a new file only for a genuinely separate topic whose own tags sharpen discovery. Not super-files, not fragmentation.
-8a. **Keep the store organized (B0).** Every cycle, fold canonical flat diagram boards into per-title folders (`apply-diagrams`, idempotent, any depth). Group clustered top-level knowledge into logical subfolders only at `deep` depth (flag candidates at light/standard). Subfolders are recall-safe — the index globs `**/*.md`. Folder and tags must tell the same story.
+8a. **Keep the store organized (B0).** NEW boards belong in their context folder (`knowledge/<context>/<title>/`); `apply-diagrams` is reserved for folding legacy flat `knowledge/diagrams/` boards into per-title folders (idempotent, any depth). Group clustered top-level knowledge into logical subfolders only at `deep` depth (flag candidates at light/standard). Subfolders are recall-safe — the index globs `**/*.md`. Folder and tags must tell the same story.
 9. **Use standard tags only (prefer taxonomy vocab).** New tags fragment discovery; always check `dreamcontext taxonomy vocab` before tagging. Add new vocabulary via `taxonomy add` or `taxonomy alias` — never hand-edit `core/taxonomy.json` directly.
 10. **Process all flags from sleep-state** in your report — don't silently drop them.
 11. **No-op cheaply** when signals don't actually warrant work.

package/agents/sleep-state.md

@@ -34,7 +34,7 @@ Identity is sacred — a fresh session must immediately understand who the agent
 |---|---|
 | `core/0-4.*`, `core/6.*` files (Edit, surgical) | task files (sleep-tasks owns) |
 | `dreamcontext core changelog add` | knowledge files incl. `knowledge/data-structures/<product>.md` (sleep-product owns + writes; you only flag staleness) |
-| `dreamcontext core releases {add,update,active,list,show}` | feature PRDs (sleep-product owns) |
+| `dreamcontext core releases {add,active,list,show}` | feature PRDs (sleep-product owns) |
 | `dreamcontext trigger add` (context-dependent reminders) | |
 
 ## Inputs
@@ -114,7 +114,7 @@ dreamcontext tasks list --status completed
 
 If every task linked to the active planning version is `completed` (or only `in_review` remains and the user has been verifying), surface release readiness in your report.
 
-**Never run `dreamcontext core releases update --status released`** unless the user's hint explicitly asks for it. Releasing is the user's decision.
+**Never run `dreamcontext core releases add --status released`** unless the user's hint explicitly asks for it. Releasing is the user's decision.
 
 If no active planning version exists, create one before adding entries (otherwise entries float unattached):
 
@@ -250,7 +250,7 @@ You do **not** edit knowledge files. Produce flags for `sleep-product` to act on
 - Entries added: 4
   - feat(council) — "Add multi-persona debate system…"
   - fix(snapshot) — "Cap pinned-preview at 730 lines…"
-  - refactor(rem-sleep) — "Split monolithic protocol into orchestrator + 5 specialists…"
+  - refactor(sleep) — "Split monolithic sleep protocol into main-agent flow + specialists…"
   - docs(readme) — "Update sleep section…"
 - Active version: v0.3.0 (planning) — 2 of 4 tasks in_review, 1 in_progress, 1 todo. Not release-ready yet.
 - Skipped: 3 commits in this range were sleep-state churn (`.sleep.json` updates) — not user-facing.

package/agents/sleep-tasks.md

@@ -1,9 +1,10 @@
 ---
 name: sleep-tasks
 description: >
-  Sleep-cycle specialist that owns task files. Dispatched by dreamcontext-rem-sleep in
-  parallel with other specialists. Reconciles task bodies to current truth, bumps statuses,
-  creates new tasks for untracked work, attaches everything to the active planning version.
+  Sleep-cycle specialist that owns task files. Dispatched by the main agent during the
+  sleep flow, in parallel with other specialists. Reconciles task bodies to current truth,
+  bumps statuses, creates new tasks for untracked work, attaches everything to the active
+  planning version.
 tools: Read, Write, Edit, Bash, Glob, Grep
 model: sonnet
 skills:

package/dist/agents/dreamcontext-explore.md

@@ -57,7 +57,11 @@ always beats blind exploration.
 **Cross-vault hits are normal and useful.** Results tagged `<vault>::<type>/<slug>` come
 from connected readable peer projects — this is expected behavior, not noise. If the
 answer likely lives in a specific peer, scope the search with `--vault <name>` to
-search current + that one peer directly.
+search current + that one peer directly. You may also go deeper on a peer: print its
+context with `dreamcontext snapshot --vault <name>`, or `Read`/`Grep` its files
+directly (a connected peer is a normal directory on disk). A connection is a standing
+"may read" — use it instead of reporting "not found here" when a sibling project owns
+the answer.
 
 Recall is appropriate for Track A (Documented Knowledge) and for Track B when
 the query is about a documented concept. It is NOT a substitute for Glob/Grep
@@ -70,7 +74,7 @@ Classify every query into one of two tracks:
 
 **TRACK A -- Documented Knowledge** (architecture, design, schema, conventions, feature specs)
 The briefing tells you which context file has the answer. Read that ONE file and return. Done.
-Examples: "what's the data schema?" -> read all files under `core/data-structures/` (typically `default.md` for single-product projects, or one file per product for multi-product). At explore-time you don't know the product set yet, so list the directory and read what's there. "How does auth work?" -> match a feature/knowledge file from the briefing.
+Examples: "what's the data schema?" -> read all files under `knowledge/data-structures/` (typically `default.md` for single-product projects, or one file per product for multi-product). At explore-time you don't know the product set yet, so list the directory and read what's there. "How does auth work?" -> match a feature/knowledge file from the briefing. Knowledge is indexed recursively, so the answer may live in a context subfolder (`knowledge/<context>/…`) — its slug is `<context>/<name>`.
 
 **TRACK B -- Find Code** (locate files, functions, implementations, usages, patterns)
 Use the briefing to form a hypothesis about WHERE in the codebase to look, then search with targeted Glob/Grep. Do NOT read context files first -- go straight to code.
@@ -126,7 +130,7 @@ No preamble. No emojis. Absolute paths only.
 
 ## Bash Restrictions
 
-Use Bash ONLY for: `ls`, `git log`, `git diff`, `git show`, `git status`, `find`, `cat`, `head`, `tail`, `wc`, `pwd`, `dreamcontext memory recall`, `dreamcontext transcript distill`
+Use Bash ONLY for: `ls`, `git log`, `git diff`, `git show`, `git status`, `find`, `cat`, `head`, `tail`, `wc`, `pwd`, `dreamcontext memory recall`, `dreamcontext snapshot`, `dreamcontext transcript distill`
 NEVER use Bash for any command that modifies files or system state.
 
 ## Rules

package/dist/agents/dreamcontext-initializer.md

@@ -141,6 +141,15 @@ Distill — don't dump. Summarize the doc's durable decisions/structure into the
 knowledge file; link back to the source path in the body. Prefer a few
 high-signal knowledge files over copying every markdown file verbatim.
 
+**Single source of truth — knowledge ≠ features.** Don't create a knowledge file
+for something you scaffolded as a feature in Step 4. Features are product docs
+(what a capability *is* — user stories, acceptance criteria); knowledge is
+research, decisions, and rationale. If a doc describes a capability that's
+already a feature, let the feature own it (knowledge may reference it). Never
+ship the same topic as both a feature and a knowledge file. When grouping
+several related knowledge files, place them in a context subfolder
+(`knowledge/<context>/`) — the index is recursive, so they stay first-class.
+
 ### Step 7: Populate the Core Files
 
 Use the gathered intelligence to write rich, meaningful content.

package/dist/agents/sleep-migration.md

@@ -43,20 +43,28 @@ skills:
 
 ### Placement judgment (behavioral) — diagrams migration
 
-Before running `dreamcontext migrations apply-diagrams`, decide per board:
-
-- **Canonical knowledge** (architecture, system flows, roadmaps, durable plans
-  the agent should recall in future sessions) → `knowledge/diagrams/<title>/`
-  (indexed, recalled). Use `apply-diagrams` for these.
+`apply-diagrams` is a **legacy structural migration**: it folds flat boards that
+already live under `knowledge/diagrams/` into per-title subfolders and rewrites
+inbound wikilinks. It is version-gated (0.7.2) and only runs when `migrations
+pending` lists it — run it as instructed; do not invent new diagram moves here.
+
+**Promoted layout (what sleep-product enforces over time):** a canonical board
+belongs **inside the context folder it documents** (co-located with that
+context's knowledge, e.g. `knowledge/<context>/<title>/<title>.excalidraw.md`),
+NOT in a segregated top-level `knowledge/diagrams/` dump. You (sleep-migration)
+do not do context-grouping — that's sleep-product's Organize pass. Your only
+diagram job is the legacy `apply-diagrams` migration when it is pending.
+
+Before running it, decide per board:
+- **Canonical knowledge** (architecture, flows, roadmaps a future session should
+  recall) → keep/organize under `knowledge/` (legacy `knowledge/diagrams/` for
+  flat boards apply-diagrams handles). Indexed, recalled.
 - **Temporary / scratch / working** (exploratory sketches, in-progress drafts)
-  → `inbox/` or `workspace/` (dark by location — NOT indexed, will not
-  pollute recall). Do NOT pull these into knowledge/diagrams/.
+  → `inbox/` or `workspace/` (dark by location — NOT indexed). Leave them; do
+  NOT pull them into `knowledge/`.
 
 Decision rule: "Will a future session need to know this? → knowledge. Throwaway/working? → inbox/workspace."
 
-Only organize canonical boards. Leave temp/scratch boards in place or move to
-inbox/workspace — do NOT use `apply-diagrams` on them.
-
 4. **Write the ledger ONLY on completion** via:
    ```bash
    dreamcontext migrations record \

package/dist/agents/sleep-product.md

@@ -166,13 +166,13 @@ If the relevant task has `product: X` in frontmatter, the PRD MAY be product-sco
 
 Before curating content, keep the knowledge store's *structure* logical. `knowledge/**/*.md` is indexed recursively (`buildKnowledgeIndex` globs `**/*.md`), so subfolders are fully recall-safe — grouping a file never hides it.
 
-**Diagrams → per-title folders (idempotent, any depth).** Preferred layout is `knowledge/diagrams/<title>/<title>.excalidraw.md` — the board plus its dark-sibling `.board.cjs`/`.json` living together. New boards often land flat (`knowledge/diagrams/<title>.excalidraw.md` next to `<title>.board.cjs`). Fold *canonical* flat boards into per-title folders every cycle:
+**Diagrams → co-located in their context folder (promoted layout).** A canonical board belongs **inside the context folder it documents**, alongside that context's knowledge — `knowledge/<context>/<title>/<title>.excalidraw.md` (the board plus its dark-sibling `.board.cjs`/`.json` in its own `<title>/` wrapper). Diagrams are NOT a segregated top-level dump; they live with the context they illustrate. When you group a context (below) and that context has a board, move the board into the context folder too so the folder tells one story.
 
 ```bash
-dreamcontext migrations apply-diagrams   # idempotent: moves flat canonical boards + same-basename siblings, rewrites inbound [[wikilinks]] atomically; prints "nothing to organize" when already clean
+dreamcontext migrations apply-diagrams   # legacy/structural: folds flat boards UNDER knowledge/diagrams/ into per-title subfolders + rewrites [[wikilinks]] atomically; idempotent, prints "nothing to organize" when clean
 ```
 
-Placement judgment FIRST: only canonical boards (architecture, system flows, roadmaps, durable plans a future session should recall) belong under `knowledge/diagrams/`. Scratch/exploratory/in-progress boards belong in `inbox/` or `workspace/` (dark by location — not indexed) — leave those alone; do NOT pull them into knowledge. Never hand-edit board scene JSON or wikilinks — the command owns both. This catches boards created *after* the one-time `0.7.2/diagrams-folder-convention` migration already recorded in the ledger (which `sleep-migration` will not re-fire for).
+`apply-diagrams` is the **legacy** mechanism for boards still under a top-level `knowledge/diagrams/` tree (it does flat→per-title, not context-grouping). Run it each cycle to keep legacy boards tidy; it's safe and idempotent. For NEW canonical boards, place them in their context folder directly. Placement judgment FIRST: only canonical boards (architecture, flows, roadmaps a future session should recall) go under `knowledge/`. Scratch/exploratory/in-progress boards belong in `inbox/` or `workspace/` (dark by location — not indexed) — leave those alone; do NOT pull them into knowledge. Never hand-edit board scene JSON or wikilinks — the command owns both.
 
 **Knowledge → logical subfolders (grouping; moves are deep-only).** When ≥3 top-level `knowledge/*.md` files form a clear topical cluster a future session would browse together (mirroring the existing `data-structures/` and `products/` subfolders), group them under `knowledge/<group>/`. Moving files + rewriting links is a structural op — gate it exactly like merge-with-delete (B1.5):
 - **light/standard:** do NOT move. **Flag the cluster in your report** (`group candidate: <group>/ ← a.md, b.md, c.md`) for the next deep cycle.
@@ -370,7 +370,7 @@ dreamcontext taxonomy resolve <tag>
 
 ### Organization
 - Diagrams: ran `apply-diagrams` — folded knowledge/diagrams/federation.excalidraw.md (+federation.board.cjs) into diagrams/federation/ (canonical board, was flat). 0 ambiguous.
-- Knowledge grouping: group candidate flagged for deep cycle — `decisions/` ← decision-mem0-vs-bm25-recall.md, decision-link-aware-vs-embedding-recall.md, decision-meta-marketing-skill-adoption.md (4 sibling `decision-*` files browse together). Not moved (standard depth).
+- Knowledge grouping: group candidate flagged for deep cycle — `decisions/` ← decision-mem0-vs-bm25-recall.md, decision-link-aware-vs-embedding-recall.md, decision-meta-marketing-skill-adoption.md (3 sibling `decision-*` files browse together). Not moved (standard depth).
 
 ### Knowledge
 - Created: knowledge/jwt-rotation-policy.md (tags: security, decisions; from sleep-state flag) — sharp boundary, new tag-able topic
@@ -394,10 +394,10 @@ Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/resea
 3. **Tick criteria only when verifiable.** Code shipped + tests pass, or user confirmed in session.
 4. **Never set `released_version`.** That's the user's release call.
 5. **Create PRDs for buildable concepts** that don't have one — they will be lost otherwise.
-6. **Don't create knowledge that already fits in memory.** A short technical decision belongs in `2.memory.md` (sleep-state's domain), not its own knowledge file.
+6. **Single source of truth — feature vs knowledge.** A topic lives in exactly ONE home. A **feature** PRD documents what a capability *is* (user stories, acceptance criteria); **knowledge** holds research/decisions/rationale; a short technical decision belongs in `2.memory.md` (sleep-state's domain). NEVER create a knowledge file for something that is a feature, never keep a knowledge copy of content that lives in a feature (or vice-versa), and never have both a feature and a knowledge doc covering the same topic — one is the home, the other may only *reference* it. When in doubt, the feature is the home for product capabilities.
 7. **Knowledge file threshold**: ≥3 paragraphs of content, or material that will be re-read in future sessions.
 8. **Fewest files, sharp boundaries (B2 rubric).** Default to extending an existing file. Fold soft distinctions in — same vertical/brand/topic family, a narrower slice, an increment. Create a new file only for a genuinely separate topic whose own tags sharpen discovery. Not super-files, not fragmentation.
-8a. **Keep the store organized (B0).** Every cycle, fold canonical flat diagram boards into per-title folders (`apply-diagrams`, idempotent, any depth). Group clustered top-level knowledge into logical subfolders only at `deep` depth (flag candidates at light/standard). Subfolders are recall-safe — the index globs `**/*.md`. Folder and tags must tell the same story.
+8a. **Keep the store organized (B0).** NEW boards belong in their context folder (`knowledge/<context>/<title>/`); `apply-diagrams` is reserved for folding legacy flat `knowledge/diagrams/` boards into per-title folders (idempotent, any depth). Group clustered top-level knowledge into logical subfolders only at `deep` depth (flag candidates at light/standard). Subfolders are recall-safe — the index globs `**/*.md`. Folder and tags must tell the same story.
 9. **Use standard tags only (prefer taxonomy vocab).** New tags fragment discovery; always check `dreamcontext taxonomy vocab` before tagging. Add new vocabulary via `taxonomy add` or `taxonomy alias` — never hand-edit `core/taxonomy.json` directly.
 10. **Process all flags from sleep-state** in your report — don't silently drop them.
 11. **No-op cheaply** when signals don't actually warrant work.

package/dist/agents/sleep-state.md

@@ -34,7 +34,7 @@ Identity is sacred — a fresh session must immediately understand who the agent
 |---|---|
 | `core/0-4.*`, `core/6.*` files (Edit, surgical) | task files (sleep-tasks owns) |
 | `dreamcontext core changelog add` | knowledge files incl. `knowledge/data-structures/<product>.md` (sleep-product owns + writes; you only flag staleness) |
-| `dreamcontext core releases {add,update,active,list,show}` | feature PRDs (sleep-product owns) |
+| `dreamcontext core releases {add,active,list,show}` | feature PRDs (sleep-product owns) |
 | `dreamcontext trigger add` (context-dependent reminders) | |
 
 ## Inputs
@@ -114,7 +114,7 @@ dreamcontext tasks list --status completed
 
 If every task linked to the active planning version is `completed` (or only `in_review` remains and the user has been verifying), surface release readiness in your report.
 
-**Never run `dreamcontext core releases update --status released`** unless the user's hint explicitly asks for it. Releasing is the user's decision.
+**Never run `dreamcontext core releases add --status released`** unless the user's hint explicitly asks for it. Releasing is the user's decision.
 
 If no active planning version exists, create one before adding entries (otherwise entries float unattached):
 
@@ -250,7 +250,7 @@ You do **not** edit knowledge files. Produce flags for `sleep-product` to act on
 - Entries added: 4
   - feat(council) — "Add multi-persona debate system…"
   - fix(snapshot) — "Cap pinned-preview at 730 lines…"
-  - refactor(rem-sleep) — "Split monolithic protocol into orchestrator + 5 specialists…"
+  - refactor(sleep) — "Split monolithic sleep protocol into main-agent flow + specialists…"
   - docs(readme) — "Update sleep section…"
 - Active version: v0.3.0 (planning) — 2 of 4 tasks in_review, 1 in_progress, 1 todo. Not release-ready yet.
 - Skipped: 3 commits in this range were sleep-state churn (`.sleep.json` updates) — not user-facing.

package/dist/agents/sleep-tasks.md

@@ -1,9 +1,10 @@
 ---
 name: sleep-tasks
 description: >
-  Sleep-cycle specialist that owns task files. Dispatched by dreamcontext-rem-sleep in
-  parallel with other specialists. Reconciles task bodies to current truth, bumps statuses,
-  creates new tasks for untracked work, attaches everything to the active planning version.
+  Sleep-cycle specialist that owns task files. Dispatched by the main agent during the
+  sleep flow, in parallel with other specialists. Reconciles task bodies to current truth,
+  bumps statuses, creates new tasks for untracked work, attaches everything to the active
+  planning version.
 tools: Read, Write, Edit, Bash, Glob, Grep
 model: sonnet
 skills: