dreamcontext 0.10.6 → 0.12.0

package/dist/templates/AGENTS.md

@@ -22,7 +22,7 @@ You are this project's engineering partner. Direct, concise, context-aware. One
 This project uses **dreamcontext** — persistent memory for AI agents.
 
 - `_dream_context/` is your brain. Soul/user/memory auto-load every session via SessionStart hook. Trust the snapshot — do not re-read what is already injected.
-- Use the `dreamcontext` CLI for structured ops: `tasks create/log/complete`, `features create`, `knowledge create/touch`, `bookmark add`, `core changelog add`, `memory recall/remember`. Never hand-edit task/feature files.
+- Use the `dreamcontext` CLI for structured ops: `tasks create/log/complete`, `features create` (deprecated alias — writes typed knowledge under `knowledge/features/`), `knowledge create/touch`, `bookmark add`, `core changelog add`, `memory recall/remember`. Never hand-edit task/feature files.
 - Memory recall is auto-injected on prompts (UserPromptSubmit hook, top-3 hits over knowledge + features + tasks + memory + CHANGELOG). Opt-out: `DREAMCONTEXT_MEMORY_HOOK=0`. `memory remember "<note>"` appends a `type=note` CHANGELOG entry — not a LIFO section.
 - Sleep debt is auto-tracked. When prompted, run the sleep flow per the `dreamcontext` skill (parallel fan-out: dispatch `sleep-tasks`, `sleep-state`, and conditionally `sleep-product`). Do not ignore consolidation prompts.
 - Use `dreamcontext-explore` for codebase exploration.

package/dist/templates/CLAUDE.md

@@ -22,7 +22,7 @@ You are this project's engineering partner. Direct, concise, context-aware. One
 This project uses **dreamcontext** — persistent memory for AI agents.
 
 - `_dream_context/` is your brain. Soul/user/memory auto-load every session via SessionStart hook. Trust the snapshot — do not re-read what is already injected.
-- Use the `dreamcontext` CLI for structured ops: `tasks create/log/complete`, `features create`, `knowledge create/touch`, `bookmark add`, `core changelog add`, `memory recall/remember`. Never hand-edit task/feature files.
+- Use the `dreamcontext` CLI for structured ops: `tasks create/log/complete`, `features create` (deprecated alias — writes typed knowledge under `knowledge/features/`), `knowledge create/touch`, `bookmark add`, `core changelog add`, `memory recall/remember`. Never hand-edit task/feature files.
 - Memory recall is auto-injected on prompts (UserPromptSubmit hook, top-3 hits over knowledge + features + tasks + memory + CHANGELOG). Opt-out: `DREAMCONTEXT_MEMORY_HOOK=0`. `memory remember "<note>"` appends a `type=note` CHANGELOG entry — not a LIFO section.
 - Sleep debt is auto-tracked. When prompted, run the sleep flow per the `dreamcontext` skill (parallel fan-out: dispatch `sleep-tasks`, `sleep-state`, and conditionally `sleep-product`). Do not ignore consolidation prompts.
 - Use `dreamcontext-explore` for codebase exploration (default Explorer is blocked).

package/dist/templates/feature.md

@@ -1,5 +1,10 @@
 ---
 id: "{{ID}}"
+type: "feature"
+name: "{{NAME}}"
+description: "{{DESCRIPTION}}"
+pinned: false
+date: "{{DATE}}"
 status: "planning"
 created: "{{DATE}}"
 updated: "{{DATE}}"

package/dist/templates/obsidian/graph.json

@@ -8,7 +8,7 @@
   "collapse-color-groups": false,
   "colorGroups": [
     {
-      "query": "path:core/features",
+      "query": "path:knowledge/features",
       "color": {
         "a": 1,
         "rgb": 1096577

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dreamcontext",
-  "version": "0.10.6",
+  "version": "0.12.0",
   "description": "dreamcontext — the persistent brain for your AI agents. Remembers what you built, knows how your project works.",
   "type": "module",
   "bin": {
@@ -12,6 +12,7 @@
     "skill-initializer",
     "skill-curator",
     "skill-deep-research",
+    "skill-sync",
     "skill-packs",
     "agents",
     "README.md",

package/skill/SKILL.md

@@ -88,6 +88,7 @@ dreamcontext is **more than memory files**. Every capability below is real and s
 | **Web dashboard** | Local React UI: Kanban, Eisenhower matrix, brain graph, sleep tracker, council hall | [integrations.md](references/integrations.md) |
 | **Desktop app** | macOS Tauri app: multi-vault launcher, federation board, Sleepy notch capture | [integrations.md](references/integrations.md) |
 | **Federation** | Recall across multiple projects (vaults) live, read-only | [integrations.md](references/integrations.md) |
+| **✅ Team brain sync (shared repo)** | **Yes — a team can share ONE brain.** The whole `_dream_context/` becomes its own git repo (separate from the code repo); `sleep done` auto fetch→merge→commit→pushes it, and the `/dream-sync` skill resolves prose conflicts. Different from federation (read-only cross-project recall) and cloud task sync (tasks only). CLI shipped; one-click desktop flow is M2/pending. | [integrations.md](references/integrations.md) |
 | **Council** | Structured multi-persona debates with a synthesized verdict | [integrations.md](references/integrations.md) |
 | **Marketing (`mk`)** | Meta marketing skill: cohorts, campaigns, competitor ingest | [integrations.md](references/integrations.md) |
 | **Versions / releases** | Planning versions and releases unify in RELEASES.json | [tasks-and-features.md](references/tasks-and-features.md) |
@@ -131,7 +132,7 @@ The SessionStart hook injects this automatically every session — answer from i
 
 | File | Load When |
 |------|-----------|
-| `core/features/<name>.md` | Feature scoping, sprint work, planning, "what's next" |
+| `knowledge/features/<name>.md` | Feature scoping, sprint work, planning, "what's next" |
 | `core/3.style_guide_and_branding.md` | UI/UX, frontend, branding, copy, design |
 | `core/4.tech_stack.md` | Architecture, integrations, dependencies, infra |
 | `knowledge/data-structures/<product>.md` (or `default.md`) | Database, API design, schema, data modeling |
@@ -182,7 +183,7 @@ When in doubt about a command or flag, open [cli-reference.md](references/cli-re
 3. **Recall before grep.** Before grepping `_dream_context/` for prior decisions or "did we already do X?", run `dreamcontext memory recall "<query>"`. It ranks across knowledge, features, tasks, memory, and changelog in one shot — cheaper and more on-target than blind Grep.
 
 4. **Single source of truth — check before creating, update over duplicate.** Every fact lives in exactly ONE place. Before creating any task/feature/knowledge, `dreamcontext memory recall` for it; if it exists, UPDATE it instead of forking a copy.
-   - **Know feature vs knowledge.** A **feature** (`core/features/<name>.md`) is product documentation — what a capability *is*, its user stories + acceptance criteria — updated only at sleep. **Knowledge** (`knowledge/…`) is other durable material: research, decisions, rationale, domain/technical context. In-progress work lives in a **task**, never in a feature or knowledge file.
+   - **Know feature vs knowledge.** A **feature** (`knowledge/features/<name>.md` — typed knowledge, `type: feature`; the `dreamcontext features` CLI is a deprecated compat alias) is product documentation — what a capability *is*, its user stories + acceptance criteria — updated only at sleep. **Knowledge** (`knowledge/…`) is other durable material: research, decisions, rationale, domain/technical context. In-progress work lives in a **task**, never in a feature or knowledge file.
    - **Never create a knowledge file for something that is a feature**, and never keep a knowledge copy of content that already lives in a feature (or vice-versa). If a topic is a feature, the feature is its home — knowledge may *reference* it, not duplicate it. Don't have both a feature and a knowledge doc covering the same thing.
    - **Never duplicate knowledge.** If two docs overlap, merge into one and point the other at it. Fragmented near-duplicate knowledge and duplicate tasks are the top failure modes — `sleep-product` dedupes, but don't create the mess.
 
@@ -326,6 +327,7 @@ All sub-agents get a lightweight context briefing via the SubagentStart hook. Wh
 - `dreamcontext upgrade` — upgrade the CLI, then (one command) update the desktop app if installed and offer to refresh **every registered project** to match (`--yes` does it all non-interactively). **Keeping projects + app updated is the CLI's job — you should not run per-project updates by hand or ask the user to.**
 - `dreamcontext doctor` — validate `_dream_context/` structure.
 - `dreamcontext dashboard` — open the web UI. `dreamcontext app install|update|status` — the desktop app.
+- **Team collaboration / shared brain** — when the user wants to **use one brain with other people** ("share the brain", "collaborate on tasks/knowledge together", "put the brain in its own repo"), that's the **shared brain repo**: `dreamcontext brain init` (create) / `brain attach <url>` (join) / `brain status`, auto-synced at `sleep done`, prose conflicts resolved by the **`/dream-sync`** skill. **Guide them into it — don't say "unsupported".** Setup is CLI-only today (the one-click desktop login/attach is M2/pending). Full surface → [integrations.md](references/integrations.md).
 
 ---
 
@@ -340,7 +342,6 @@ When dreamcontext gets in your way — a recall gap, a missing command, a confus
 ```
 _dream_context/
 ├── core/
-│   ├── features/<feature>.md         ← Feature PRDs (may include product:)
 │   ├── 0.soul.md  1.user.md  2.memory.md
 │   ├── 3.style_guide_and_branding.md  4.tech_stack.md  6.system_flow.md
 │   ├── CHANGELOG.json  RELEASES.json  taxonomy.json
@@ -349,6 +350,7 @@ _dream_context/
 │   ├── <context>/                    ←   PROMOTED: group related docs into a context folder
 │   │   ├── <doc>.md                  ←     the context's knowledge
 │   │   └── <title>/<title>.excalidraw.md  ← diagrams live INSIDE their context folder
+│   ├── features/<feature>.md         ← Feature PRDs, typed knowledge (type: feature; may include product:)
 │   ├── data-structures/{default,<product>}.md   ← schemas (recall-indexed; ```sql body)
 │   └── products/<product>.md         ← per-product knowledge (multi-product)
 ├── overrides/
@@ -370,5 +372,5 @@ Open these with `Read` when the task needs depth:
 - **[tasks-and-features.md](references/tasks-and-features.md)** — task protocol depth, RICE, due dates, people/assignees, Workflow flowchart, features, versioning, multi-product.
 - **[knowledge-and-recall.md](references/knowledge-and-recall.md)** — knowledge files, pinning, recall modes, taxonomy, Excalidraw/diagrams.
 - **[sleep.md](references/sleep.md)** — full consolidation flow, specialist contracts, deep sleep, epoch safety, reflect, marketing/council passes.
-- **[integrations.md](references/integrations.md)** — ClickUp/GitHub task sync (one cloud backend at a time), dashboard, desktop app, federation/vaults, council, marketing.
+- **[integrations.md](references/integrations.md)** — ClickUp/GitHub task sync (one cloud backend at a time), **team brain sync (shared brain repo — `brain init`/`attach`/`sync`, `/dream-sync` conflict resolution)**, dashboard, desktop app, federation/vaults, council, marketing.
 - **[improving-dreamcontext.md](references/improving-dreamcontext.md)** — the feedback loop, when and how to file.

package/skill/references/cli-reference.md

@@ -63,7 +63,7 @@ Sections for `tasks insert`: `why`, `user_stories`, `acceptance_criteria`, `cons
 
 | Command | Description |
 |---|---|
-| `roadmap` | Render the objective board (rollups, target vs forecast, slip flags) and regenerate `knowledge/roadmap/board.md`. `--json` emits the typed RoadmapModel instead (no writes). |
+| `roadmap` | Render the objective board (rollups, target vs forecast, slip flags) and regenerate `knowledge/roadmap/board.md`. `--json` emits the typed RoadmapModel instead (no writes). A slipping objective reports the numeric days late (`slip_days`) and the auto-derived cause (`slip_upstream`: the direct dependency slug(s) whose forecast runs past this target, else own member tasks). The SessionStart snapshot renders these (`Nd late (upstream: …)` or `(own tasks)`) plus each objective's impact/effort and a one-line description, and orders active objectives by time-box relevance (this month → this quarter → later). |
 | `roadmap objective create <slug>` | Create `core/objectives/<slug>.md`. `--title <str>` (required), `--target YYYY-MM-DD`, `--depends-on <csv>`, `--feature <prd-slug>`, `--why <text>`. |
 | `roadmap objective list` | All objectives with progress %, status, forecast. `--json`. |
 | `roadmap objective show <slug>` | One objective: member tasks, direct dependents, and the transitive "if this slips, so do" set. `--json`. |
@@ -71,6 +71,7 @@ Sections for `tasks insert`: `why`, `user_stories`, `acceptance_criteria`, `cons
 | `roadmap objective delete <slug>` | Delete; other objectives' `depends_on` are healed automatically. `--yes`. |
 | `roadmap objective depend <A> <B>` | A depends on B — **rejected at write time** if it would create a circular dependency. |
 | `roadmap objective undepend <A> <B>` | Remove the dependency edge. |
+| `roadmap objective metric <slug>` | Set/update the objective's Key Result metric (outcome-based progress instead of task rollup). `--current <n>` (the common nudge — latest observed value), `--target <n>`, `--baseline <n>`, `--label <text>`, `--unit <text>`, `--clear` (remove the metric, back to task-based progress). Sleep may update `--current` when it observes a new real value; all other objective fields stay PO-owned. |
 
 Task-side linkage: `tasks create --objectives a,b` · `tasks objectives <task> a,b|clear` · `tasks list --objective <slug>`. Objectives are recallable: `memory recall "<query>" --types objective`.
 
@@ -186,6 +187,24 @@ Never hand-edit `core/taxonomy.json` — mutate via these commands.
 
 ---
 
+## Brain — team collaboration / shared brain repo (see [integrations.md](integrations.md))
+
+Sync the WHOLE brain (`_dream_context/`) — tasks, knowledge, features, sleep state — to its own git remote so a **team collaborates on the same brain** the way they collaborate on code. Distinct from federation (which is read-only cross-*project* recall) and from cloud task sync (which mirrors only *tasks* to ClickUp/GitHub Issues). Brain repos default **private**; attaching one is a **trust decision** (a brain repo loads into every future session). Local indexes/caches are per-machine and never pushed. **M1 CLI is shipped; the one-click desktop/Launcher flow (device-flow GitHub login, repo picker, UI attach) is M2 — pending.**
+
+| Command | Description |
+|---|---|
+| `brain status` | Show brain-repo mode (`separate`/`in-tree`), remote, sync state, and whether cloud sync is ON. Reports `mergeInProgress` / `pendingAgentMerge` (the `/dream-sync` handoff signals). |
+| `brain init` | Create a NEW brain repo on GitHub (**private by default**) and push a scrubbed first commit. `--public` (requires interactive confirm), `--code-repo <url>` (store a pointer to the paired code repo). |
+| `brain attach <url>` | Attach an EXISTING team brain repo — a **TRUST decision** (S6): prints a trust warning + incoming-diff preview and refuses without confirmation. `-y/--yes` to skip the prompt. |
+| `brain discover` | List `dreamcontext-brain`-topic repos you can access on GitHub. |
+| `brain sync` | Fetch → semantic-merge-on-conflict → commit → push (or, in `in-tree` mode, commit-only — never auto-pushes). `--pull-only` (take team content in, never push), `--push-only`, `--strict` (WARN scrub hits block too), `--resume` / `--continue` (the attended `/dream-sync` handoff — see below). |
+| `brain enable` / `brain disable` | Explicit master switch for cloud sync on this project (v3.3). |
+| `brain scrub` | Dry-run the secrets/absolute-path scrub gate against the current staged tree. |
+
+**Automatic sync:** every `dreamcontext sleep done` runs a brain sync (fetch/merge/commit/push); failure never fails sleep. Session-start does a non-blocking background pull. **On an agent-class merge conflict** (two people edited the same prose section) the CLI stops at `already-awaiting-agent` and defers to the **`/dream-sync` skill** — the agent half that reads base/ours/theirs and writes the semantic merge, then `brain sync --continue`. Never drive `--resume`/`--continue` unattended.
+
+---
+
 ## Council (see [integrations.md](integrations.md))
 
 `council create`, `council agent create`, `council round start\|end`, `council synthesize`, `council complete`, `council promote`, `council list`, `council show`. Plus sub-agent helpers (`round-context`, `report append`, `summaries`, `research add\|list`).

package/skill/references/integrations.md

@@ -1,6 +1,8 @@
 # Integrations — ClickUp / GitHub, Dashboard, Desktop App, Federation, Council, Marketing
 
-This reference covers everything beyond the local markdown brain. **If a user asks whether dreamcontext integrates with ClickUp or GitHub Issues, runs a dashboard, syncs across projects, or runs debates — the answer is yes.** Details below.
+This reference covers everything beyond the local markdown brain. **If a user asks whether dreamcontext integrates with ClickUp or GitHub Issues, runs a dashboard, syncs across projects, lets a *team share one brain*, or runs debates — the answer is yes.** Details below.
+
+> **"I want to use dreamcontext WITH my team / with other people."** That is the **shared brain repo** — see [Team brain sync](#-team-brain-sync-shared-brain-repo-collaborate-on-one-brain) below. Don't confuse it with the three neighbors: **cloud task sync** (ClickUp/GitHub Issues) mirrors only *tasks*; **federation** is read-only cross-*project* recall (no copying); the shared **brain repo** git-syncs the *whole* `_dream_context/` so several people push/pull/merge the same tasks + knowledge + features.
 
 ---
 
@@ -212,6 +214,48 @@ dreamcontext federation purge --dry-run            # preview
 
 ---
 
+## ✅ Team brain sync (shared brain repo) — collaborate on ONE brain
+
+**Yes, a team can share a single dreamcontext brain.** The whole `_dream_context/` (tasks, knowledge, features, sleep state) becomes **its own git repo** with its own remote — separate from the code repo — and the CLI/desktop app push/pull/merge it the way a team collaborates on code. The brain stays plain markdown/JSON on disk (local-first); git is just the sync transport, not a new database.
+
+**Guide the user here** the moment they say *"I want to use this with my team / with other people," "share the brain," "collaborate on tasks/knowledge together,"* or *"put the brain in its own repo."* Do NOT answer "we don't support that" — this is the feature.
+
+**How it differs from its neighbors** (say this if the user conflates them):
+- **Cloud task sync** (ClickUp/GitHub Issues) — mirrors only *tasks* to a task manager, one backend at a time.
+- **Federation** — read-only recall across your OWN separate projects; nothing is ever copied.
+- **Shared brain repo (this)** — the *whole* brain is one git-synced artifact several people edit together.
+
+### Onboarding a team (M1 — CLI, shipped today)
+
+```bash
+# Person A — create a brand-new shared brain repo (PRIVATE by default) and push a scrubbed first commit
+dreamcontext brain init --code-repo https://github.com/acme/app     # pointer back to the paired code repo
+
+# Person B (and every teammate) — attach the existing brain repo (a TRUST decision: it loads every session)
+dreamcontext brain discover           # list dreamcontext-brain-topic repos you can access
+dreamcontext brain attach https://github.com/acme/app-brain         # trust warning + diff preview, then confirm
+
+dreamcontext brain status             # mode (separate/in-tree), remote, sync state, cloud-sync switch
+```
+
+### Day-to-day (mostly automatic)
+
+- **Every `sleep done`** fetches → semantic-merges on conflict → commits → pushes the brain (sync failure never fails sleep). **Session start** does a non-blocking background pull. So teammates' consolidated context reaches everyone without a manual step.
+- **Manual sync any time:** `dreamcontext brain sync` (or `--pull-only` to just take team content in).
+- **On a prose merge conflict** (two people edited the same `##` section of a knowledge/feature doc), the CLI resolves every deterministic file itself and stops at `already-awaiting-agent`, deferring the rest to the **`/dream-sync` skill** — the agent reads base/ours/theirs snapshots, writes the real semantic merge, and hands back with `brain sync --continue`. (`--resume`/`--continue` are attended-only; never drive them unattended.)
+
+### Editing / reconfiguring
+
+- **Turn cloud sync on/off:** `dreamcontext brain enable` / `brain disable`.
+- **Modes:** `separate` (own remote, full auto-sync) vs `in-tree` (brain nested in the code repo — commit-only, **never** auto-pushes; the safe default). Both always run the scrub gate.
+- **Safety rails (always on):** brain repos default **private** (`--public` needs an explicit confirm); a **scrub gate** blocks secrets / absolute local paths before every commit and push; tokens are supplied via `GIT_ASKPASS` (never embedded in the remote URL); per-machine indexes/caches are gitignored and never pushed.
+
+### From the desktop app? — M2, PENDING (not yet shipped)
+
+The one-click UX — **GitHub device-flow login from the Launcher, a repo picker over your `dreamcontext-brain`-topic repos, UI "create"/"attach" with the trust preview, and a team-updates badge** — is **M2, still pending**. Today the shared-brain setup is **CLI-only** (a technical user runs `brain init` / `brain attach`). Be honest about this: a non-technical teammate can't yet do the *setup* from the app; once attached, the normal dashboard/app reads the shared brain like any other. (Full status: `knowledge/features/brain-repo-sync.md`; merge internals: `skill-sync/references/merge-rules.md`.)
+
+---
+
 ## Council (multi-persona debates)
 
 Structured debates for load-bearing decisions (architecture, migrations, hiring, brand critiques). N personas × N rounds, each persona its own sub-agent with a scoped prompt, model, and aspects; a synthesizer writes the verdict. Also available as the `council` skill pack + `/council` skill.

package/skill/references/knowledge-and-recall.md

@@ -43,7 +43,7 @@ It moves the file **and** rewrites every inbound `[[wikilink]]` in one atomic st
 
 ## Memory functions — what they are and how to use them
 
-The `memory` command group is your interface to the curated corpus: `knowledge/*`, `core/features/*`, `state/*.md`, `core/2.memory.md` (Technical Decisions + Known Issues), and every `core/CHANGELOG.json` entry. No setup, no index file, no external service — rebuilt in memory each call (<100ms on ~130 docs).
+The `memory` command group is your interface to the curated corpus: `knowledge/*` (`knowledge/features/*` loads as its own `feature` channel — `--types feature` vs `--types knowledge` — never double-counted), `state/*.md`, `core/2.memory.md` (Technical Decisions + Known Issues), and every `core/CHANGELOG.json` entry. No setup, no index file, no external service — rebuilt in memory each call (<100ms on ~130 docs).
 
 | Function | Use it to… | Command |
 |---|---|---|

package/skill/references/sleep.md

@@ -43,7 +43,7 @@ For non-file-change work (architecture discussion, a decision with no edits): `d
      - a `knowledge_access` entry is 30+ days untouched
      - a research bookmark exists
      - a task slug matches an existing feature PRD filename
-     - `git status` shows changes under `_dream_context/core/features/`
+     - `git status` shows changes under `_dream_context/knowledge/features/`
      - a session advanced ≥1 acceptance criterion, OR introduced a feature concept with ≥2 criteria, OR the user named something "a feature" / "we should add X", OR a task has `feature:` frontmatter pointing to a non-existent PRD
      - the user hint mentions knowledge or a feature
      - When unsure, **over-fire** `sleep-product` — it no-ops cheaply.
@@ -66,7 +66,7 @@ For non-file-change work (architecture discussion, a decision with no edits): `d
 |---|---|---|
 | `sleep-tasks` | Task files (`state/*.md`) | Reconciles task bodies to truth, bumps statuses, creates tasks for untracked work, attaches to the planning version, sets the start/due range, and keeps declared custom fields current (never fabricating `ask` fields in the no-user sleep context). When objectives exist, proposes `objectives:` links for tasks with an EMPTY/absent list (multiple slugs when a task serves several outcomes) — **never overwrites a non-empty list** (that's a PO decision). |
 | `sleep-state` | Core identity (soul, user, memory, core 3–6), CHANGELOG, RELEASES | Records patterns/decisions/preferences, writes a changelog entry per meaningful change since the epoch, surfaces release readiness, enforces anti-bloat ceilings, flags stale knowledge for `sleep-product`. |
-| `sleep-product` | Knowledge files + feature PRDs | Creates/reconciles `knowledge/*.md` and `core/features/*.md`, processes staleness flags, maintains the knowledge index + taxonomy. |
+| `sleep-product` | Knowledge files + feature PRDs | Creates/reconciles `knowledge/*.md` and `knowledge/features/*.md` (typed knowledge, `type: feature`), processes staleness flags, maintains the knowledge index + taxonomy. |
 | `sleep-migration` | Structure only | Moves/renames folders, normalizes frontmatter, wraps fences. Never alters body prose. |
 
 **Consolidation discipline (remind specialists in the brief):** prefer *updating/extending* an existing entity over creating a new one. `sleep-tasks` folds a smaller slice into the task that already covers it (broaden its title + insert sub-items) rather than forking a duplicate. `sleep-product` keeps similar verticals/topics in the fewest knowledge files, splitting only on a sharp topical boundary. Duplicate tasks and fragmented near-duplicate knowledge are the top failure modes — but genuinely separate concerns still get their own task/file.

package/skill/references/tasks-and-features.md

@@ -114,6 +114,7 @@ dreamcontext roadmap objective list|show <slug>       # show = members + depende
 dreamcontext roadmap objective edit <slug> [--title] [--target <date>|clear] [--status not_started|active|review|done|clear] [--feature <slug>|clear]
 dreamcontext roadmap objective depend <A> <B>         # A depends on B — REJECTED at write time if it would create a cycle
 dreamcontext roadmap objective undepend <A> <B>
+dreamcontext roadmap objective metric <slug> [--current <n>] [--target <n>] [--baseline <n>] [--label ..] [--unit ..] [--clear]   # Key Result: --current is the common nudge
 dreamcontext roadmap objective delete <slug> --yes    # also heals other objectives' depends_on
 dreamcontext tasks create <name> --objectives a,b     # link at creation (slugs must exist)
 dreamcontext tasks objectives <task> a,b|clear        # set/clear on an existing task
@@ -124,8 +125,9 @@ dreamcontext tasks list --objective <slug>            # all tasks serving an obj
 - **Progress** = completed ÷ total member tasks (each objective counts over its OWN member set — a shared task contributes to each independently).
 - **Rollup status** (real enum): all `completed`→`done` 🟢 · any `in_progress`→`active` 🔵 · any `in_review`→`review` 🟡 · else `not_started` ⚪. A manual `--status` override wins (`status_source: override`).
 - **Forecast cascade — full transitive DAG:** `forecast_start = max(earliest member start, max(forecast_end of dependencies))`; `forecast_end = max(latest member due, forecast_start)`. A slip anywhere propagates to ALL transitive dependents (diamond shapes included).
-- **Null rule:** no dated member tasks → `forecast = null` ("unforecastable") and it imposes NO constraint on dependents.
-- **Slipping** 🔴 = `forecast_end > target_date` (the PO's committed date). This is the live on-track signal — surfaced in the snapshot and the board.
+- **Milestone forecast:** an objective with NO dated tasks of its own but WITH dependencies inherits its forecast from its latest dependency (finish-to-start) — so a pure milestone ("launch", which only depends on others) slips when an upstream slips. Only an objective with neither dated tasks nor a forecastable dependency stays `null` ("unforecastable") — and a null-forecast objective still never drags its dependents to "now".
+- **Slipping** 🔴 = `forecast_end > target_date` (the PO's committed date). The model also exposes `slip_days` (how many days late) and `slip_upstream` (the auto-derived cause — the dependency slug(s) responsible, else empty = the objective's own tasks overrun). Surfaced in the snapshot and the board.
+- **Prioritization + description:** each objective also carries `impact` (1–5), `effort` (weeks) and a one-line `description` (first body line) — rendered in the snapshot, which now surfaces current-month/quarter targets first.
 
 **Rules for agents:**
 1. **Propose, never overwrite.** Suggest `objectives:` for tasks you create or find unlabeled; an existing non-empty list is a PO decision — never change it unless the user asks.
@@ -134,6 +136,19 @@ dreamcontext tasks list --objective <slug>            # all tasks serving an obj
 4. **`knowledge/roadmap/board.md` is auto-generated** — regenerate with `dreamcontext roadmap`, never hand-edit it. Objective files themselves are PO-authored prose — edit `## Why`/`## Notes` freely, but rollups/members are computed and don't belong in them.
 5. A feature PRD *may* back an objective via the objective's `feature:` field — a convenience link, not a requirement.
 
+### Proactive objective capture (in-session — ASK, never auto-create)
+
+Objectives are PO-authored, so this is an **offer-and-confirm** flow, never a silent write. When, during a session, the user **states or clearly implies an outcome/goal** — an explicit target ("hedefimiz $2000 MRR", "we want to launch mobile by Q4") OR an inferred one from how they talk about direction ("we really need to grow this", "the whole point is to make it a business") — do this:
+
+1. **Dedup first.** Run `dreamcontext roadmap objective list` and `dreamcontext memory recall "<the outcome>" --types objective`. If an objective already covers it, DON'T propose a new one — offer to update the existing one instead (or just link the current work to it).
+2. **Offer it.** If it's genuinely new, ask: *"This sounds like a roadmap objective — want me to add it?"* Never create without a yes.
+3. **Ask the dates.** On yes, ask for the committed window — start and target date (`--target`, and set start via `objective edit`/dashboard). Don't invent dates.
+4. **Offer a Key Result.** Ask whether to track it by a number rather than member tasks: *"Track this by a metric (e.g. MRR 0→2000) or by its tasks?"* If a metric, capture `label` + `baseline`/`target` (`--metric*` flags on create, or `objective metric` after).
+5. **Detect + propose dependencies.** From the existing objective list, infer likely `depends_on` edges ("make-it-a-business can't happen before simplified-ux and team-ready ship") and **propose them for confirmation**; on yes, apply with `objective depend <A> <B>` (the write-time cycle guard protects you). Never write a dependency edge silently.
+6. **Keep the Key Result current.** When the session later surfaces a real observed value for a tracked objective ("MRR just hit $1,250", "we're at 400 active users"), offer to update it: `dreamcontext roadmap objective metric <slug> --current <n>`. Use a value you actually observed — never estimate. (Sleep may also refresh `--current` autonomously from observed values.)
+
+The through-line: **you detect and propose; the PO confirms.** Every create, date, dependency, and metric write waits for a yes — matching the "objectives are PO-authored" invariant and the board-first ritual (`knowledge/visual-first-board-ritual.md`).
+
 ---
 
 ## The Workflow flowchart (keep it in sync)
@@ -221,16 +236,22 @@ When an override is active its briefing (the field list, each field's `required`
 
 ## Features (PRDs)
 
-Retrospective product documentation, **created and updated exclusively by the sleep agent**. During active work, everything goes in the task; sleep consolidates task content into the matching feature.
+Features are **typed knowledge** — a feature PRD is a `knowledge/features/<name>.md` file with
+frontmatter `type: feature` (plus `name`/`description`/`pinned:false`/`date` for knowledge-index
+display). Retrospective product documentation, **created and updated exclusively by the sleep
+agent**. During active work, everything goes in the task; sleep consolidates task content into
+the matching feature. `dreamcontext features …` is a **deprecated compat alias** (prints a
+deprecation notice on every call) that reads/writes `knowledge/features/` — it is not a separate
+entity from knowledge.
 
 ```bash
-dreamcontext features create <name> -w "Why" -t backend,api -s planning --related-tasks a,b
+dreamcontext features create <name> -w "Why" -d "One-line description" -t backend,api -s planning --related-tasks a,b
 dreamcontext features set <name> status active
 dreamcontext features set <name> tags backend,api,topic:recall
 dreamcontext features insert <name> acceptance_criteria "..."   # auto-formats as - [ ]
 dreamcontext features doctor                                    # staleness / orphans / dangling refs
 ```
-Status values: `planning | in_progress | in_review | active | shipped | deprecated`. Sections: `changelog`, `notes`, `technical_details`, `constraints`, `user_stories`, `acceptance_criteria`, `why`. PRDs live in `core/features/<name>.md` (flat directory; may carry `product:`).
+Status values: `planning | in_progress | in_review | active | shipped | deprecated`. Sections: `changelog`, `notes`, `technical_details`, `constraints`, `user_stories`, `acceptance_criteria`, `why`. PRDs live in `knowledge/features/<name>.md` (flat directory under `knowledge/`; may carry `product:`); the generic knowledge index/recall channel excludes `knowledge/features/**` to avoid double-listing — features stay a distinct surface (snapshot Features section, dashboard Features tab, `--types feature` recall).
 
 ---
 
@@ -257,7 +278,7 @@ New tasks without `--version` auto-attach to the active planning version, so wor
 - **Per-product data structures**: `knowledge/data-structures/<product>.md` (single-product → `default.md`). Body format is a single ` ```sql ` fenced block with `-- ...` comments (the dashboard highlights it). Recall-indexed, owned by `sleep-product`.
 - **Per-product knowledge**: `knowledge/products/<product>.md`. Cross-cutting knowledge stays at top-level `knowledge/`.
 - **Tasks** may carry `product: <name>` in frontmatter; CLI/dashboard surface a product filter.
-- **Feature PRDs** may carry `product: <name>` (still in the flat `core/features/` directory).
+- **Feature PRDs** may carry `product: <name>` (still in the flat `knowledge/features/` directory).
 - **Auto-injection**: the SessionStart hook resolves the active task (override `state/.active-task`, else most-recently-modified `in_progress` task). If its `product:` is in `multiProduct`, the hook injects `knowledge/products/<name>.md` into the snapshot under `## Active Product Knowledge: <name>` (capped ~200 lines). You don't load it manually — it's already in context.
 
 If `multiProduct` is `false`/absent, treat the project as single-product and use `data-structures/default.md`.

package/skill-curator/SKILL.md

@@ -10,7 +10,7 @@ description: >
   stale task statuses, off-vocabulary tags, a flat knowledge dump that should be foldered).
   This is the interactive, sub-agent-driven brain REFACTOR — the pass that sleep won't do. It is
   allowed to MOVE, MERGE, SPLIT, RENAME, RE-TYPE, and RETIRE content to reach the right
-  knowledge / feature / task / version shape.
+  knowledge / feature / task / version / objective shape.
 user-invocable: true
 alwaysApply: false
 tags: [curator, refactor, reorganize, cleanup, dedup, single-source-of-truth, orchestration, sub-agents, dreamcontext]
@@ -87,7 +87,7 @@ flowchart TD
 2. **Read the current conventions** so the whole run targets *today's* shape: the installed
    `dreamcontext` skill + references, `dreamcontext taxonomy vocab`, `core/0.soul.md`, `1.user.md`.
 3. **Announce** (per the ritual) and ask **only what you can't determine** (keep it short):
-   - **Scope**: the whole brain, or one domain (knowledge / features / tasks / versions)?
+   - **Scope**: the whole brain, or one domain (knowledge / features / tasks / versions / objectives)?
    - **Anything off-limits** — files/areas you should not touch this pass?
    - Confirm they want a **real run** (it mutates the corpus) — the plan is shown before execution.
    On a clean git tree, note it; if there are uncommitted changes, recommend committing first so the
@@ -106,6 +106,7 @@ findings:
 | `features` | reconcile status to reality, rename to current vocabulary, dedup vs knowledge, flag stale |
 | `tasks` | finished tasks still open (STATUS-BUMP), duplicate/stale tasks (MERGE/RETIRE), orphans → attach to a planning version |
 | `versions` | reconcile release/version statuses so they're tidy and consistent |
+| `objectives` | PO-authored roadmap objectives (`core/objectives/*.md`): dangling `depends_on`/task links, stale status overrides, malformed dates/metrics, target dates long past with no progress — flag; never rewrite PO prose (STATUS-BUMP/RETAG only, PO owns the file) |
 
 Give each auditor its domain + the conventions you read in Phase 0. Each returns a **source → action
 → target** findings table. A finding that says "clean up knowledge" without naming each file and the

package/skill-deep-research/SKILL.md

@@ -9,7 +9,7 @@ description: >
   cite it", "cross-project / cross-corpus question", or any "tons of data, federated/tagged
   vault" question where one explore agent and one answer under-serves. This is the heavy,
   iterative, sub-agent-driven counterpart to `dreamcontext-explore`: it fans out searchers over
-  the whole curated corpus (knowledge + features + tasks + memory + CHANGELOG) AND connected
+  the whole curated corpus (knowledge + features + tasks + memory + CHANGELOG + objectives) AND connected
   peer vaults, adversarially verifies the load-bearing claims, and returns a SYNTHESIZED, CITED
   report — not raw hits.
 user-invocable: true
@@ -91,7 +91,7 @@ the planner and the synthesizer.
   - everything readable → `--connected` (out/both peers) or `--all-vaults`.
 - **Seed with recall, in JSON, scoped by type:**
   ```bash
-  dreamcontext memory recall "<facet>" --json --top 15 --types knowledge,feature,task,memory,changelog --connected
+  dreamcontext memory recall "<facet>" --json --top 15 --types knowledge,feature,task,memory,changelog,objective --connected
   ```
   Run it for **2–4 different phrasings/facets** of the question — recall is cheap (<100ms, zero
   token overhead) and different keywords surface different docs. Collect the union of hits.

package/skill-initializer/SKILL.md

@@ -80,7 +80,7 @@ flowchart TD
 ### Phase 0 — RECOGNIZE & OFFER (interactive — ask, then wait)
 
 1. Confirm the brain is missing/sparse (`ls _dream_context/`; if present, check for empty
-   `knowledge/`, zero `core/features/`, untouched template stubs).
+   `knowledge/`, zero `knowledge/features/`, untouched template stubs).
 2. Make the **offer** above. Then ask **only what you can't detect** (3–6 questions max):
    - **Where is your material?** Absolute paths to folders/files to ingest (docs, exports,
      wiki, ADRs, specs, notes). "None — codebase only" is a valid answer.
@@ -116,7 +116,7 @@ mapped to a target:
 |---|---|
 | `knowledge/<context>/<slug>.md` | research, decisions, rationale, domain/technical deep context |
 | `knowledge/data-structures/<product>.md` | real schemas (Prisma/SQL/ORM) — actual tables/fields |
-| `core/features/<name>.md` | product capabilities (what a feature *is*) — candidate PRDs |
+| `knowledge/features/<name>.md` | product capabilities (what a feature *is*, typed knowledge `type: feature`) — candidate PRDs |
 | `state/<task>.md` | open/in-flight work, TODOs, roadmap items |
 | people roster | distinct git authors (`git shortlog -sne`) |
 | taxonomy `domain:<x>` | recurring project nouns |

package/skill-sync/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: dream-sync
+description: >
+  Load when the user asks to sync/reconcile the dreamcontext brain repo with a team (a shared
+  `_dream_context/` git remote), or when `dreamcontext brain sync` (or the SessionStart snapshot)
+  reports a team merge awaiting resolution. Triggers: "/dream-sync", "sync the brain", "reconcile
+  with the team", "resolve the brain merge conflict", "already-awaiting-agent", "awaiting-agent",
+  "pending team-merge handoff". This is the agent half of the semantic-merge contract: the CLI
+  resolves every deterministic file (JSON changelog/releases/config/taxonomy, task status +
+  changelog) automatically and only ever defers PROSE files (knowledge/features) where two people
+  edited the same section — you read base/ours/theirs snapshots and write the actual semantic
+  merge, then hand back to the CLI to commit + push.
+user-invocable: true
+alwaysApply: false
+tags: [sync, brain-repo, git, merge, collaboration, dreamcontext]
+---
+
+# /dream-sync — the agent half of the brain-repo merge contract
+
+You are the **semantic merge resolver**. The CLI (`dreamcontext brain sync`) already did
+everything it safely can on its own: every JSON class (changelog, releases, config, taxonomy) and
+every task markdown file were merged and committed automatically — set-unions and furthest-status
+logic never lose data and never need judgment. The ONLY thing left for you is **prose that two
+people edited in the same `##` section** of a knowledge file or feature doc — a case the CLI
+correctly refuses to resolve on its own (see `references/merge-rules.md` — the "C1 discard
+contract"), because a naive textual merge mangles Markdown and a "remote wins" default would
+silently throw away one author's words.
+
+**Read `references/merge-rules.md` before touching anything** — it is the single source of truth
+for the deterministic rules, the CLI-vs-agent split, and the full pull-only → resume → resolve →
+continue state machine you are stepping into.
+
+## Step 1 — determine the handoff state
+
+Run `dreamcontext brain status`. It reports two independent booleans:
+
+- `mergeInProgress` (a real git `MERGE_HEAD` exists) — the **classic** path: `brain sync` (auto
+  mode) hit an agent-class conflict directly and left the merge open.
+- `pendingAgentMerge` (no `MERGE_HEAD`, but a report was deferred) — the **pull-only** path: a
+  headless background pull (session-start) hit the same conflict, but pull-only NEVER leaves the
+  tree mid-merge — it aborted back to a clean commit and recorded the defer for you to redo
+  attended.
+
+Branch on exactly these two signals (equivalently: a plain `dreamcontext brain sync` returning
+`already-awaiting-agent` tells you one of the two is true, without telling you which):
+
+| State | What to do |
+|---|---|
+| `mergeInProgress: true` | Go straight to **Step 2** (report already exists, real `MERGE_HEAD`). |
+| `pendingAgentMerge: true`, `mergeInProgress: false` | Run `dreamcontext brain sync --resume` FIRST. If it returns `pushed` or `pulled`, the handoff is DONE — the remote moved on and nothing needed your judgment. If it returns `awaiting-agent`, a FRESH report + a real `MERGE_HEAD` now exist — go to **Step 2**. |
+| Neither | Just run `dreamcontext brain sync` (normal on-demand sync) — nothing to resolve. |
+
+**You never call `--resume` when a `MERGE_HEAD` is already there, and you never skip `--resume`
+for a `pendingAgentMerge`-only state** — the CLI enforces this with `invalid-flag`, but don't rely
+on that as your only guardrail; read the state first.
+
+## Step 2 — read the report and resolve each deferred file
+
+Read `_dream_context/state/.brain-merge/report.json`. For each entry in `deferred`:
+
+1. Read the three snapshots it names: `basePath` (common ancestor), `oursPath` (this machine's
+   version), `theirsPath` (the remote/teammate's version) — all under `state/.brain-merge/`.
+2. Write the semantically-merged content directly into the REAL file at `path` (repo-relative,
+   possibly under an `_dream_context/` prefix in in-tree mode — strip it to find the file on disk).
+   Preserve both authors' intent: don't just pick one side. For a knowledge/feature doc, merge
+   section-by-section — sections only one side touched keep that side's version; sections BOTH
+   touched are the ones you're here for — read them and write prose that keeps both people's point,
+   reconciling wording, not concatenating raw diffs.
+3. Stage it — run `git add <path>` inside the brain repo (in `separate` mode, the brain repo root
+   IS `_dream_context/`; in `in-tree` mode, it's the code repo root and `path` already carries the
+   `_dream_context/` prefix).
+
+Do this for every entry in `deferred` before moving on — `--continue` commits everything staged in
+one shot.
+
+## Step 3 — hand back to the CLI
+
+Run `dreamcontext brain sync --continue`. It re-scrubs (a secret can be reintroduced by a merge —
+never skip this), commits, and pushes (retrying once on a non-fast-forward race). On success the
+report and its snapshot files are gone, `pendingAgentMerge` flips back to `false`, and a normal
+`brain sync` runs cleanly from here on. If it instead reports `blocked-scrub`, something you wrote
+looks like a secret or a local path — fix it and re-run `--continue`.
+
+## What you must NEVER do
+
+- **Never call `--resume` or `--continue` unattended / speculatively** — they are the explicit
+  ATTENDED gates for exactly this handoff. `sleep done`'s autoSync, the session-start background
+  pull, and the dashboard all stop at `already-awaiting-agent` and print the instruction to run
+  `/dream-sync` — they never drive these flags themselves.
+- **Never write the CLI's discarded remote-wins output** for a deferred knowledge/feature file —
+  if you see `report.json`'s `deferred` entry for a path, that means the CLI's own attempt was
+  thrown away specifically because it would have clobbered one side; only your snapshot-based
+  merge is authoritative for that file.
+- **Never hand-edit `.brain-merge/report.json`** or its snapshots — they are inputs, not outputs.