dreamcontext 0.8.3 → 0.8.6

package/dist/skill-packs/goal-skill/SKILL.md

@@ -64,7 +64,7 @@ flowchart TD
     P5 -->|cap reached| ESC2[ESCALATE to user — do NOT proceed]
     P5 -->|PASS| P6{Phase 6 — goal-validator runs the chosen method: PASS?}
     P6 -->|FAIL| P4
-    P6 -->|PASS| DONE[Goal reached — task to in_review, ask the user to complete]
+    P6 -->|PASS| DONE[Goal reached — validation passed, mark task completed + tell the user]
 ```
 
 ### Phase 0 — Scope & validation method (ask the user)
@@ -143,9 +143,11 @@ recorded in the task and returns `PASS | FAIL` with evidence (exact command + ou
 
 - **FAIL** → append the failure report to the task (`dreamcontext tasks log`), and route
   **back to Phase 4** (IMPLEMENT). Loop IMPLEMENT → REVIEW → VALIDATE until validation PASSES.
-- **PASS** → the goal is reached. `dreamcontext tasks status <slug> in_review "all criteria
-  met; validation passed via <method>"`, then **ask the user to confirm completion** —
-  `tasks complete` is a user action; you never auto-complete.
+- **PASS** → the goal is reached. The user-chosen validation method *is* the definition of
+  done, and it passed with evidence — so close it: `dreamcontext tasks status <slug> completed
+  "all criteria met; validation passed via <method>"`, then **tell the user it's done** (what
+  shipped + the evidence). Only leave it in `in_review` instead if the validation surfaced
+  something a human should still eyeball before closing.
 
 ## Convergence rules (how the loops end)
 
@@ -166,7 +168,7 @@ recorded in the task and returns `PASS | FAIL` with evidence (exact command + ou
 | "I'll let the implementer review its own work." | Self-review is not review. Use a clean-context `reviewer`. |
 | "I'll skip asking the user how to validate, tests are obviously the way." | Phase 0 is non-negotiable. Validation criteria are the user's call. |
 | "We've looped 4 times, but I think this next one fixes it." | Cap is 3. Escalate. The user decides whether to keep going. |
-| "I'll auto-complete the task, validation passed." | `complete` is user-only. Move to `in_review` and ask. |
+| "I'll mark it complete because I *think* it's done." | Done is defined by Phase 6 validation passing with evidence — not by your hunch. Complete only after PASS. |
 
 ## Rationalization table
 
@@ -182,7 +184,7 @@ recorded in the task and returns `PASS | FAIL` with evidence (exact command + ou
 - **Orchestrator never writes production code.** Dispatch sub-agents.
 - **Plan reviewers run in parallel**, in one message. Sequential dispatch defeats the design.
 - **Never skip Phase 0's validation-method question.**
-- **Never auto-`complete` the task** — that's the user's action; you stop at `in_review`.
+- **`complete` only after Phase 6 PASS** — validation passing with evidence is the definition of done; never complete on a hunch, and never before validation.
 - **Tell `reviewer` to run `git diff` itself**; don't paste diffs into prompts.
 - **Caps are hard** (3 per loop). At the cap, escalate — never declare done.
 - **Use the `dreamcontext` skill** throughout — the task doc is the source of truth.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dreamcontext",
-  "version": "0.8.3",
+  "version": "0.8.6",
   "description": "dreamcontext — the persistent brain for your AI agents. Remembers what you built, knows how your project works.",
   "type": "module",
   "bin": {

package/skill/SKILL.md

@@ -319,7 +319,7 @@ Sleep debt reminders are injected on every user message (via UserPromptSubmit ho
      - user hint mentions knowledge or a feature
    - When unsure, **over-fire** `sleep-product` — it no-ops cheaply.
    - **Conditional fire**: `sleep-migration` when `dreamcontext migrations pending` produces output (pending agent migration tasks exist). Contract: no-content changes only (structure/paths/frontmatter/fences); writes ledger via `dreamcontext migrations record` on completion.
-   - **Conditional fire**: `sleep-federation` when `state/.connections.json` has active (non-stale) links OR the federation inbox has pending entries (check `dreamcontext federation status`). Contract: **drain THEN distribute** — `dreamcontext federation drain` (ingest peer digests into first-class `knowledge/*--from-*.md` with `federated:true` provenance, surface conflict-notes as bookmarks, never auto-resolve) then `dreamcontext federation sync` (consent-gated, recall-filtered push into connected peers' inboxes, watermark advances). Owns ONLY `.connections.json` + `.federation-inbox/` + `knowledge/*--from-*.md`. Idempotent — over-fire cheaply.
+   - **Do NOT fire `sleep-federation`.** Federation is read-only (live reference); the copy-based drain/distribute path is disabled and parked on the roadmap. Sleep copies NOTHING across vault boundaries — peers are read live at recall time, not synced at sleep. (The `sleep-federation` specialist + `federation sync`/`drain` are retained but inert.)
    - Pass each specialist a small text brief in its prompt: epoch, session IDs, active task slugs, planning version, signals relevant to that specialist, optional user hint. Do **not** include transcript content — specialists call `dreamcontext transcript distill <id>` themselves.
    - **Consolidation discipline (remind both 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 or a needless sub-task; `sleep-product` keeps similar verticals/brands/topics in the fewest knowledge files, splitting only on a sharp topical boundary that sharpens tags. Duplicate tasks and fragmented near-duplicate knowledge are the top consolidation failure modes — but genuinely separate concerns/topics still get their own task/file.
 5. Wait for all specialist reports. Each returns a short structured report.
@@ -408,10 +408,10 @@ dreamcontext tasks insert <name> changelog "Implemented pagination for /api/task
 # Lifecycle
 dreamcontext tasks log <name> "what was done"                           # Quick changelog entry (MANDATORY)
 dreamcontext tasks status <name> in_review "Ready for review"           # Bump status (todo|in_progress|in_review|completed)
-dreamcontext tasks complete <name> "summary"                            # Mark complete (user only; sleep agent never auto-completes)
+dreamcontext tasks complete <name> "summary"                            # Convenience for marking complete
 ```
 
-**Status convention:** `todo` -> `in_progress` -> `in_review` -> `completed`. The sleep agent bumps tasks it touched to `in_review` (never `completed`) so the user can verify before declaring done. This prevents the "task rotting in todo" failure mode.
+**Status convention:** `todo` -> `in_progress` -> `in_review` -> `completed`. The sleep agent picks the status that matches reality — `completed` for work that's demonstrably done, low-risk, and already validated, and `in_review` only when a human genuinely must verify something (a behaviour change, a design decision, a risky/critical-path change). It does **not** reflexively park everything in `in_review`; finished work that needs no review is closed, so neither "task rotting in todo" nor "task rotting half-closed in in_review" happens.
 
 Task insert sections: `why`, `user_stories`, `acceptance_criteria`, `constraints`, `technical_details`, `notes`, `changelog`
 
@@ -491,29 +491,45 @@ dreamcontext memory status
 
 ## Cross-Project Federation (issue #25)
 
-Every `_dream_context/` is normally an island. Federation lets you reach across projects — recall what you worked out in *another* vault — using nothing but the local filesystem (no network, ever). Phase 1 is **read-only**: discovery + cross-vault recall + peer snapshots.
+Every `_dream_context/` is normally an island. Federation lets you reach across projects — recall what you worked out in *another* vault — using nothing but the local filesystem (no network, ever).
+
+**Ambient awareness — you start informed.** The session snapshot includes a `## Connected projects` section listing each readable peer with a one-line description and last activity. At session start you already know which sibling projects exist and roughly what's in them. For an up-to-date summary on demand:
 
 ```bash
-dreamcontext vaults discover [root] [--register]   # find every _dream_context/ under a tree (node_modules ignored, depth-bounded)
-dreamcontext memory recall <query...> --vault <name>   # also search a peer vault (repeatable)
-dreamcontext memory recall <query...> --all-vaults     # search current + every SHAREABLE registered vault
-dreamcontext memory recall <query...> --connected      # search current + out/both connections (degenerate=local until Phase 2)
-dreamcontext snapshot --vault <name>               # print a peer vault's context snapshot
-dreamcontext config shareable on|off               # opt this project IN/OUT of peer recall (default: off)
+dreamcontext federation peers          # compact summary: what each peer is, last activity, active task, top tags
 ```
 
-**Trust model — shareable gates READS, private by default.** A vault is invisible to peer recall until its owner runs `config shareable on`. New and migrated projects default to `shareable: false`. `shareable` is asymmetric: it controls whether OTHERS may pull *your* corpus — it never blocks *you* from reading a shareable peer, and the current vault is always searched regardless of its own flag. Non-shareable peers are silently excluded from `--all-vaults` (never an error). Cross-vault hits are namespaced `<vault>::<type>/<slug>` so the same slug in two vaults never collides.
+**PULL — recall already spans peers.** Plain `memory recall` automatically searches readable peer vaults alongside the current one. No flag needed. You get up to 10 hits, vault-tagged `<vault>::<type>/<slug>` so provenance is always visible:
 
-**When to reach across.** Use `--vault`/`--all-vaults` for "how did I solve this in project X?" / "did we already build Y somewhere?" before re-deriving knowledge that already exists in a sibling project.
+```bash
+dreamcontext memory recall "<query>"                   # current vault + all eligible readable peers (default)
+dreamcontext memory recall "<query>" --vault <name>    # current + one named peer (repeatable)
+dreamcontext memory recall "<query>" --connected       # current + out/both connections
+dreamcontext memory recall "<query>" --all-vaults      # current + every shareable vault
+```
 
-**Per-link connections (Phase 2).** `dreamcontext connect <vault> --direction out|in|both [--topics a,b]` builds an outgoing mesh in `state/.connections.json`; `connections list` / `disconnect <vault>` manage it. Direction is asymmetric: `out` = your digest may flow TO the peer, `in` = you accept the peer's digest, `both` = bidirectional. The dashboard Settings → Cross-Project Federation card edits all of this plus the shareable switch.
+Eligible = direction `out`/`both`, status not stale, AND the peer is `shareable: true`. If no eligible connections exist, recall is local-only (unchanged). A peer vault being `shareable` controls whether *others* may read it — it never blocks you from reading a shareable peer, and the current vault is always searched. Non-shareable peers are silently excluded (never an error). Cross-vault hits are namespaced `<vault>::<type>/<slug>` so the same slug in two vaults never collides.
 
-**Sleep-driven digest inbox (Phase 3).** Federated knowledge crosses a boundary as a *directory of one-file-per-entry JSON digests* under `state/.federation-inbox/` (consumed entries archive to `consumed/`). The `sleep-federation` specialist runs two idempotent steps, ALWAYS in this order:
+Use `--vault <name>` when you know where the answer likely lives; the default span is the cheapest path when you don't.
 
-1. **Drain** (`dreamcontext federation drain`) — ingest each pending inbox entry as **first-class** local `knowledge/<slug>.md` carrying `federated: true` + `origin{vault,entryId,sourceTimestamp}` provenance. A slug collision lands at `knowledge/<slug>--from-<vault>.md` (the local doc is never clobbered). A `conflict-note` entry is ingested AND surfaced as a bookmark for the user — never auto-resolved. Version-incompatible entries are quarantined in place.
-2. **Distribute** (`dreamcontext federation sync`) — for each `out`/`both` connection, the sender reads the RECEIVER's `.connections.json` and writes ONLY if the receiver declares `in`/`both` back (the **consent rule**); it computes a recall-filtered digest since `last_synced_at`, writes one file per entry into the peer's inbox, and advances the watermark. Draining first means freshly-ingested peer knowledge is in the corpus when the outbound digest is computed — and is then EXCLUDED from it, because `federated: true` docs are dropped from BOTH digest computation AND cross-vault recall serving (the transitive-leak guard: a third vault never sees what merely passed through this one). Filename dedup + watermark + that exclusion make an A↔B cycle echo-free.
+**Read-only — nothing is ever copied.** Federation is a *live reference*: a connected, shareable peer's CANONICAL docs are surfaced at recall time (PULL, above) and never written into your vault. Each vault stays the single source of truth for its own knowledge. There is no per-situation "when to read" rule — a connection is a standing "may read" agreement, resolved live by recall whenever it's relevant.
 
-The SessionStart snapshot stays on the hot path: it only ever does a single local `pendingInboxCount` readdir to nudge "N pending peer digests — drain them"; it NEVER resolves a peer or builds a peer corpus. Dashboard previews via `POST /api/federation/sync` are **dry-run by construction** (no write function reachable from any server route).
+```bash
+dreamcontext vaults discover [root] [--register]   # find every _dream_context/ under a tree
+dreamcontext connect <vault> --direction out [--topics a,b]   # create a read edge (out = read)
+dreamcontext connections list / disconnect <vault>                      # manage links
+dreamcontext snapshot --vault <name>               # print a peer vault's context snapshot
+dreamcontext config shareable on|off               # opt this project IN/OUT of peer recall (default: off)
+```
+
+**Copy-based sync is parked on the roadmap.** Earlier builds pushed a lossy, truncated *digest* of each vault into its peers at sleep (`federation sync`) and ingested it as `federated: true` copies (`federation drain`). That broke single-source-of-truth: copies were write-once, went stale the moment the source changed, and an edit produced duplicates + false conflict-notes. It is now **disabled** — `federation sync` / `federation drain` are inert no-ops, and the `sleep-federation` specialist is no longer dispatched. Re-introducing a copy/offline-mirror mode needs a proper design first (it's the one thing live read can't do: survive a peer going offline).
+
+**Cleaning up old copies.** If a vault still holds `federated: true` knowledge files from the old sync path, remove them deliberately:
+```bash
+dreamcontext federation status                     # shows connections + any leftover federated copies
+dreamcontext federation purge --all                # remove every federated:true copy in this vault
+dreamcontext federation purge --vault <name>       # remove only copies that came from one peer
+```
 
 ---
 
@@ -601,7 +617,7 @@ All commands prefixed with `dreamcontext`. For reading/searching, use native too
 | `tasks rice <name> [--reach N] [--impact N] [--confidence N] [--effort N] [--clear]` | Print or update RICE values; no flags prints current values |
 | `tasks insert <name> <section> <content>` | Insert into task section |
 | `tasks status <name> <todo\|in_progress\|in_review\|completed> [reason...]` | Change task status (logs to changelog) |
-| `tasks complete <name>` | Complete task (user only; sleep agent uses `tasks status ... in_review`) |
+| `tasks complete <name>` | Complete task (convenience for `tasks status <name> completed`) |
 | `tasks log <name> <content>` | Log task progress |
 | `bookmark add "<message>" [-s 1\|2\|3] [--task <slug>]` | Bookmark an important moment with optional task link |
 | `bookmark list` | Show current bookmarks |

package/skill-packs/goal-skill/SKILL.md

@@ -64,7 +64,7 @@ flowchart TD
     P5 -->|cap reached| ESC2[ESCALATE to user — do NOT proceed]
     P5 -->|PASS| P6{Phase 6 — goal-validator runs the chosen method: PASS?}
     P6 -->|FAIL| P4
-    P6 -->|PASS| DONE[Goal reached — task to in_review, ask the user to complete]
+    P6 -->|PASS| DONE[Goal reached — validation passed, mark task completed + tell the user]
 ```
 
 ### Phase 0 — Scope & validation method (ask the user)
@@ -143,9 +143,11 @@ recorded in the task and returns `PASS | FAIL` with evidence (exact command + ou
 
 - **FAIL** → append the failure report to the task (`dreamcontext tasks log`), and route
   **back to Phase 4** (IMPLEMENT). Loop IMPLEMENT → REVIEW → VALIDATE until validation PASSES.
-- **PASS** → the goal is reached. `dreamcontext tasks status <slug> in_review "all criteria
-  met; validation passed via <method>"`, then **ask the user to confirm completion** —
-  `tasks complete` is a user action; you never auto-complete.
+- **PASS** → the goal is reached. The user-chosen validation method *is* the definition of
+  done, and it passed with evidence — so close it: `dreamcontext tasks status <slug> completed
+  "all criteria met; validation passed via <method>"`, then **tell the user it's done** (what
+  shipped + the evidence). Only leave it in `in_review` instead if the validation surfaced
+  something a human should still eyeball before closing.
 
 ## Convergence rules (how the loops end)
 
@@ -166,7 +168,7 @@ recorded in the task and returns `PASS | FAIL` with evidence (exact command + ou
 | "I'll let the implementer review its own work." | Self-review is not review. Use a clean-context `reviewer`. |
 | "I'll skip asking the user how to validate, tests are obviously the way." | Phase 0 is non-negotiable. Validation criteria are the user's call. |
 | "We've looped 4 times, but I think this next one fixes it." | Cap is 3. Escalate. The user decides whether to keep going. |
-| "I'll auto-complete the task, validation passed." | `complete` is user-only. Move to `in_review` and ask. |
+| "I'll mark it complete because I *think* it's done." | Done is defined by Phase 6 validation passing with evidence — not by your hunch. Complete only after PASS. |
 
 ## Rationalization table
 
@@ -182,7 +184,7 @@ recorded in the task and returns `PASS | FAIL` with evidence (exact command + ou
 - **Orchestrator never writes production code.** Dispatch sub-agents.
 - **Plan reviewers run in parallel**, in one message. Sequential dispatch defeats the design.
 - **Never skip Phase 0's validation-method question.**
-- **Never auto-`complete` the task** — that's the user's action; you stop at `in_review`.
+- **`complete` only after Phase 6 PASS** — validation passing with evidence is the definition of done; never complete on a hunch, and never before validation.
 - **Tell `reviewer` to run `git diff` itself**; don't paste diffs into prompts.
 - **Caps are hard** (3 per loop). At the cap, escalate — never declare done.
 - **Use the `dreamcontext` skill** throughout — the task doc is the source of truth.

package/dist/dashboard/assets/channel-3OfE-PZ3.js

@@ -1 +0,0 @@
-import{aq as o,ar as n}from"./index-rIZLhbl7.js";const t=(r,a)=>o.lang.round(n.parse(r)[a]);export{t as c};

package/dist/dashboard/assets/classDiagram-6PBFFD2Q-Dpt9qwZI.js

@@ -1 +0,0 @@
-import{s as a,c as s,a as e,C as t}from"./chunk-4TB4RGXK--piiFXgS.js";import{_ as i}from"./index-rIZLhbl7.js";import"./chunk-FMBD7UC4-C1Le6hxh.js";import"./chunk-YZCP3GAM-BNc94uy1.js";import"./chunk-55IACEB6-C7uvmawY.js";import"./chunk-EDXVE4YY-BuWBKOPY.js";var u={parser:e,get db(){return new t},renderer:s,styles:a,init:i(r=>{r.class||(r.class={}),r.class.arrowMarkerAbsolute=r.arrowMarkerAbsolute},"init")};export{u as diagram};

package/dist/dashboard/assets/classDiagram-v2-HSJHXN6E-Dpt9qwZI.js

@@ -1 +0,0 @@
-import{s as a,c as s,a as e,C as t}from"./chunk-4TB4RGXK--piiFXgS.js";import{_ as i}from"./index-rIZLhbl7.js";import"./chunk-FMBD7UC4-C1Le6hxh.js";import"./chunk-YZCP3GAM-BNc94uy1.js";import"./chunk-55IACEB6-C7uvmawY.js";import"./chunk-EDXVE4YY-BuWBKOPY.js";var u={parser:e,get db(){return new t},renderer:s,styles:a,init:i(r=>{r.class||(r.class={}),r.class.arrowMarkerAbsolute=r.arrowMarkerAbsolute},"init")};export{u as diagram};

package/dist/dashboard/assets/clone-CZ-InUnR.js

@@ -1 +0,0 @@
-import{b as r}from"./graph-BMW3t-Jz.js";var e=4;function a(o){return r(o,e)}export{a as c};