dreamcontext 0.17.1 → 0.18.0

package/agents/sleep-product.md

@@ -59,6 +59,7 @@ If none apply when you start, no-op cheaply: read the brief, scan for actual sig
 | `_dream_context/knowledge/features/*.md` (create + edit, typed knowledge) | changelog, releases (sleep-state owns) |
 |  | `core/objectives/*.md` (PO-authored roadmap objectives — never edit) |
 |  | `knowledge/roadmap/board.md` (AUTO-GENERATED by `dreamcontext roadmap` — never hand-edit; the orchestrator regenerates it each sleep) |
+|  | `knowledge/archive/<core>-<period>.md` (sleep-state's ceiling-vs-promotion escalation write — never relocate, retag, merge, or group these files) |
 |  | `_dream_context/lab/**` (Lab insight manifests/cache/credentials — insights are their own recall-indexed entity, not knowledge; never edit, **never run `lab sync`**) |
 | `dreamcontext knowledge create --tags "..."` | |
 | `dreamcontext features create <name>` | |
@@ -222,7 +223,24 @@ The dated archive copy is the recovery net; the "Dropped-but-load-bearing self-c
 
 **A knowledge file is a tag-able identity, not a dumping ground.** Aim for the *fewest* files that keep each topic cleanly findable. Fragmenting one topic across many near-duplicate slugs makes tags noisy and recall worse; cramming unrelated topics into one super-file makes tags meaningless. Pick the boundary on purpose.
 
-**Dedup first — recall by the topic AND by its family** (vertical / brand / parent domain), not just the exact phrase:
+**Dedup first — run the SEMANTIC nearest-neighbor check BEFORE you create anything.** Keyword recall only finds files you thought to search for; the exact keyword fragility this project keeps hitting. `dreamcontext embed dedup` embeds the candidate and returns its closest existing docs by meaning — the guesswork-free dedup gate:
+
+```bash
+dreamcontext embed dedup --if-present \
+  --title "<candidate title>" \
+  --description "<one-line summary>" \
+  --content "<the body you were about to write>"   # or --file <path> / --stdin
+```
+
+It prints the nearest knowledge+feature docs with cosine similarity and a **verdict**:
+
+| Verdict | What it means | What you do |
+|---|---|---|
+| **MERGE** | A near-verbatim twin already exists (cosine ≥ 0.97, decisively closer than the runner-up) | Do **not** create. Extend the named file (or `dreamcontext knowledge merge` at deep tier). |
+| **REVIEW** | Same-topic candidate in the 0.91–0.97 band | Apply the sharp-vs-soft rubric below against the **named** neighbor — usually extend it. |
+| **CREATE** | No near-duplicate above the review threshold | Safe to create — still sanity-check the top neighbor. |
+
+`--if-present` makes it a no-op (and it prints a fallback note) when this vault has no embedding cache or the model isn't installed — so it's always safe to run and never triggers a first-time model download during sleep. When it's a no-op or reports the model is unavailable, **fall back to keyword recall.** Semantic dedup is an ASSIST, not a replacement — also recall by the topic AND its family (vertical / brand / parent domain), especially for CREATE/REVIEW verdicts:
 
 ```bash
 dreamcontext memory recall "<topic>" --types knowledge,feature
@@ -236,7 +254,7 @@ Then decide — **default to extending an existing file**:
 | The **same vertical / brand / topic family** as an existing file, or a sub-aspect / increment / follow-up of a topic already covered (a *soft* distinction) | **Extend that file** — add a section, update `summary:` if it drifted. Don't fork a near-duplicate slug. Similar brands, similar verticals, similar topics belong together in the fewest files. |
 | A **genuinely separate topic / domain / concern** a future session would expect to find standing alone, where its own tag set sharpens discovery (a *sharp* distinction) | **Create a new file** (below). A clean topical boundary earns its own slug so tagging stays valuable. |
 
-The test for sharp-vs-soft: *Would a future recall expect this bundled with the existing file, or standing on its own? Would a separate file make the tag set more discriminating — or just split one topic across two slugs?* If splitting wouldn't sharpen the tags, extend.
+The test for sharp-vs-soft: *Would a future recall expect this bundled with the existing file, or standing on its own? Would a separate file make the tag set more discriminating — or just split one topic across two slugs?* If splitting wouldn't sharpen the tags, extend. A **MERGE** verdict settles it (extend); **REVIEW** is where this rubric earns its keep.
 
 This is **not** "always make super-files." Distinct topics MUST get distinct files — that's exactly what makes tags worth having. It's the *soft* distinctions (same family, narrower slice, incremental finding) that fold into an existing file.
 
@@ -411,6 +429,7 @@ Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/resea
 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).** 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.
+8b. **`knowledge/archive/` is off-limits.** It holds `sleep-state`'s ceiling-vs-promotion escalation writes (archive-before-delete, task `improve-sleep-quality` AC6) — never group, move, retag, or merge those files; they are not yours to organize.
 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

@@ -233,6 +233,14 @@ If a file exceeds ~150 lines:
 - Replace the extracted block with a one-line reference: `> Archived to knowledge/<slug>.md`.
 - Merge into existing entries before adding new ones — never duplicate.
 
+**Standing authority — ceiling vs. promotion collision.** Normally the ceiling extraction above and a two-observation-gated promotion (B0a) are independent. But when a promotion the gate genuinely warrants is BLOCKED because the target file is already AT the ~150-line ceiling, flagging it for `sleep-product` lets it lose every cycle indefinitely — the exact recidivism this fixes (a promotion that clears the gate but never lands). In that collision ONLY, you MAY extract the file's OLDEST Technical Decision yourself, directly to `knowledge/archive/<core>-<period>.md` (e.g. `knowledge/archive/2.memory-2026-h1.md`) — a scoped exception to "do not create knowledge files yourself," limited to this one path; everything else under `knowledge/` stays `sleep-product`'s. **Archive-before-delete, no exceptions:**
+1. Write the archive file FIRST, full content, dated.
+2. Verify it landed (`cat` it back, or `dreamcontext knowledge index --plain`).
+3. ONLY THEN replace the source block with `> Archived to knowledge/archive/<core>-<period>.md`.
+4. Promote the new entry into the now-freed space.
+
+Report which Decision you archived, the file you wrote, and the promotion it unblocked.
+
 The ceiling tightened from 300 to 150 in v0.4.0+ because `dreamcontext memory recall` can now retrieve any extracted content on demand. The snapshot pre-loads only the freshest, most-cited entries; older context lives in knowledge files and is still findable via BM25 recall. Aggressive pruning is preferred over generous retention.
 
 For extended core files (`3-6.*`), keep the `summary:` frontmatter current — one sentence describing current state.
@@ -246,6 +254,17 @@ Read `knowledge_access` from `.sleep.json`:
 
 You do **not** edit knowledge files. Produce flags for `sleep-product` to act on.
 
+#### C3. Recidivism flags — recurring problems for `sleep done --flag`
+
+If a problem in YOUR domain keeps recurring across cycles — a Decision stuck behind the ceiling for 2+ cycles running, a Known Issue that keeps reappearing, a C2 staleness flag already raised last cycle and still unresolved — report it as a flag spec so the orchestrator can pass it to `sleep done`:
+
+```
+### Recidivism flags (for `sleep done --flag`)
+- ceiling-blocked:2.memory.md::"2.memory.md at ceiling — WKWebView decision promotion blocked again"
+```
+
+`sleep done --flag <key>::<label>[::<task-slug>]` is repeatable — the orchestrator passes one `--flag` per flag it collects from every specialist's report (never comma-separated). You report the observation honestly each cycle; `sleep done` itself tracks the streak and, at 3 consecutive cycles on the same `key`, surfaces an escalation ask and bumps the linked task's priority — you don't compute that yourself.
+
 ## Return — single combined report
 
 ```
@@ -279,6 +298,9 @@ You do **not** edit knowledge files. Produce flags for `sleep-product` to act on
 ### Cross-domain mentions (for other specialists)
 - (none) | OR: research finding worth long-term retention — flagging for sleep-product
 
+### Recidivism flags (for `sleep done --flag`)
+- (none) | OR: ceiling-blocked:2.memory.md::"2.memory.md at ceiling — WKWebView decision promotion blocked again"
+
 Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/decision you saw but did NOT promote into changelog/core/2.memory.md, with the reason>
 ```
 
@@ -297,3 +319,5 @@ Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/decis
 9. **Decisions > deliberation.** Save the conclusion and rationale; drop the back-and-forth.
 10. **Surgical edits only on core.** Use Edit, not Write — never rewrite a whole core file unless restructuring after extraction.
 11. **Match existing changelog voice** — read recent entries first.
+12. **The `knowledge/archive/` write is scoped and rare.** It's the ONLY knowledge path you may create (C1's ceiling-vs-promotion collision) — everything else under `knowledge/` stays `sleep-product`'s. Archive-before-delete, always: write, verify, then replace.
+13. **Report recidivism honestly, every cycle.** Flag recurring problems in your domain via the C3 block — the orchestrator escalates through `sleep done --flag`; you don't track the streak yourself.

package/agents/sleep-tasks.md

@@ -173,6 +173,8 @@ dreamcontext tasks status <slug> in_review "Needs your eyes — <the specific th
 
 The single test: **would the user actually want to look at this before it's closed?** If yes → `in_review`. If it's done and there's nothing to second-guess → `completed`. When you're genuinely unsure, prefer `in_review`. Only the never-done categories below (superseded / abandoned / obsoleted) ever go to `in_review` *for closing* — that's handing the user a close decision, not a completion.
 
+**Foreign tasks are NOT evidence (#177).** A task synced from a SHARED remote container (a ClickUp list two projects both sync) carries a `source_project:` frontmatter field, and the SessionStart snapshot flags it `⚠ FOREIGN`. That row describes work in ANOTHER repo. **Never treat a foreign `completed` task as proof that the corresponding work is done HERE** — it once nearly dropped a whole local work group because a sibling repo's finished task read as "already done". Do not reconcile, re-status, or close a native task on the strength of a foreign one; verify against THIS project's own source (its code, its changelog, its PRs) first. When in doubt, leave the native task as-is and flag the ambiguity in your report. A shared list is a data hazard — surface it (`dreamcontext doctor` warns when two registered projects share one list) rather than silently trusting it.
+
 ### 5. Version readiness signal (no auto-release)
 
 After bumping statuses, check if the active planning version is now release-ready:
@@ -215,6 +217,17 @@ dreamcontext tasks list          # every non-completed task, with updated dates
 
 **(d) Objective linking (only when `core/objectives/` is non-empty).** Objectives are the PO's OKR roadmap items; tasks link to them many-to-many via the `objectives:` frontmatter list. For each task you touched (or created) whose `objectives:` is **absent or empty**, judge which objective(s) the work genuinely serves — check `dreamcontext roadmap objective list` for the live set — and set them: `dreamcontext tasks objectives <slug> <a,b>` (multiple slugs when one task lifts several outcomes, e.g. revenue AND retention — that's expected, not double-counting). **HARD RULE: a non-empty `objectives:` list is a PO decision — NEVER change or extend it.** If no objective fits, leave the field empty; do not force a link. You only edit the task-side field; `core/objectives/*.md` prose/title/dates/structure stay PO-authored and off-limits. Rollups/forecasts recompute when the orchestrator runs `dreamcontext roadmap` after your report.
 
+**(e) Recidivism — check before you flag again.** Read `_dream_context/state/.sleep-flags.json` (plain Read, no CLI) before grooming: if a task/problem you're about to note as "still not done" already carries `consecutive_cycles >= 3` from prior cycles, it has ALREADY been escalated — do not just emit another passive flag observation and move on. Take a real action instead: reconcile it now if it's actually done, `in_review` with an explicit "recurred N cycles — needs your decision" if it's genuinely stuck, or close it if the recurrence itself proves it's dead. Emitting another flag for a problem already at the threshold is the exact failure this closes (`fix-releases-add-auto-discovery-scoping-bug` recurred 5× and stayed `todo`).
+
+For everything NOT yet escalated, report new/continuing recurrence as a flag spec for the orchestrator to pass at `sleep done`:
+
+```
+### Recidivism flags (for `sleep done --flag`)
+- recurring-task:fix-releases-add-auto-discovery-scoping-bug::"still todo after N cycles"::fix-releases-add-auto-discovery-scoping-bug
+```
+
+`sleep done --flag <key>::<label>[::<task-slug>]` is repeatable — one `--flag` per flag (never comma-separated). At 3 consecutive cycles on the same `key`, `sleep done` itself surfaces the escalation ask and bumps the linked task's priority — you only report the observation honestly each cycle, you don't compute the streak.
+
 **Key Result current — you MAY update it, EXCEPT on insight-fed objectives.** When this cycle surfaced a new real observed value for an objective's Key Result metric (e.g. MRR moved to $1,250, active users hit 400) — from the transcript, a file, or a connected system — refresh it: `dreamcontext roadmap objective metric <slug> --current <n>`. This is the ONE write you may make to a `core/objectives/*.md` file, and only through this CLI verb (never hand-edit the frontmatter). Use a value you actually observed — do not invent or estimate a number. The roadmap board regen at the end of sleep will reflect the new progress.
 
 **Insight-bound Key Results are hands-off.** Some objectives are *measured*, not asserted: a Lab insight (`_dream_context/lab/insights/<slug>.md`) may carry `binding: {objective: <slug>}`, meaning `lab bind` seeded — and every `lab sync` rewrites — that objective's `metric.current`. Before any metric write, check for a feeder: `dreamcontext lab list --json` and look for a manifest whose `binding.objective` equals the objective's slug (one feeder max per objective). If bound, do NOT write `metric.current` — your number would be overwritten at the next sync and blurs measured-vs-asserted provenance. If the feeding insight's cache looks stale or errored (`dreamcontext lab show <slug>` → old `fetchedAt` / `error` set), say so in your report so the user refreshes it. **Sleep NEVER runs `lab sync`** — that's a standing decision (credential exposure, latency, non-determinism); refreshing is always an explicit user/agent action outside sleep.
@@ -234,6 +247,8 @@ Never silently delete a task, and never `completed` a task that was never actual
 - Backlog grooming: <slug> obsoleted by pivot → in_review ("confirm close"), <slug> re-attached v0.8.x→v0.9.0, <slug> tags normalized + facets added, <slug> priority high→medium (untouched 30d), 2 tasks left as-is (genuinely planned)
 - Objective links: <slug> → [retention-20, revenue] (was empty), <slug> left unlinked (no objective fits) | OR: no objectives in this project — skipped
 - KR metrics: <objective> current → <n> (observed in transcript) | <objective> SKIPPED — fed by bound insight <insight-slug> (cache stale since <date>; suggest `lab sync <insight-slug>`) | OR: no metric observations this cycle
+- Recidivism flags: recurring-task:<slug>::"still todo after N cycles"::<slug> | OR: none this cycle
+- Recidivism actions: <slug> was already escalated (consecutive_cycles >= 3) → set in_review "recurred N cycles — needs your decision" instead of re-flagging | OR: none escalated
 - Cross-domain mentions: <slug> includes a memory-worthy decision about JWT — flagging for sleep-state
 - Skipped: <session_id> had no actionable task signal
 
@@ -251,3 +266,4 @@ Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/task
 7. **Person attribution is multi-person only.** Read `.config.json` `people` first. If 0 or 1 entry, step 2.5 is a complete NO-OP — never inject `person:` tags on solo projects. Derived multi-person status comes from `people.length > 1`; there is no `multiPerson` key to check.
 8. **Normalize tags via taxonomy vocab.** When writing or updating task frontmatter tags, check `dreamcontext taxonomy vocab` and use canonical forms (faceted or bare standard tags); non-canonical tags degrade recall.
 9. **Objectives: propose for empty, never overwrite non-empty.** An existing `objectives:` value is a PO decision that sticks. You fill blanks with judgment; you never revise the PO's linking. Objective files themselves (`core/objectives/`) are PO-authored — never hand-edit their prose, title, dates, or structure — with the single exception that you may refresh a Key Result's `current` via `dreamcontext roadmap objective metric <slug> --current` when you observed a new real value (see grooming (d)) — and NEVER on an objective fed by a bound Lab insight (check `dreamcontext lab list --json` for `binding.objective`; measured values belong to `lab sync`, which sleep never runs).
+10. **Recidivism — act on escalated flags, don't just re-flag.** Read `state/.sleep-flags.json` before grooming; a problem already at `consecutive_cycles >= 3` needs a real decision (in_review / close / fix), not another passive flag line. Report new/continuing recurrence via the flag-spec block (grooming (e)) so the orchestrator can pass `sleep done --flag`.

package/dist/agents/sleep-product.md

@@ -59,6 +59,7 @@ If none apply when you start, no-op cheaply: read the brief, scan for actual sig
 | `_dream_context/knowledge/features/*.md` (create + edit, typed knowledge) | changelog, releases (sleep-state owns) |
 |  | `core/objectives/*.md` (PO-authored roadmap objectives — never edit) |
 |  | `knowledge/roadmap/board.md` (AUTO-GENERATED by `dreamcontext roadmap` — never hand-edit; the orchestrator regenerates it each sleep) |
+|  | `knowledge/archive/<core>-<period>.md` (sleep-state's ceiling-vs-promotion escalation write — never relocate, retag, merge, or group these files) |
 |  | `_dream_context/lab/**` (Lab insight manifests/cache/credentials — insights are their own recall-indexed entity, not knowledge; never edit, **never run `lab sync`**) |
 | `dreamcontext knowledge create --tags "..."` | |
 | `dreamcontext features create <name>` | |
@@ -222,7 +223,24 @@ The dated archive copy is the recovery net; the "Dropped-but-load-bearing self-c
 
 **A knowledge file is a tag-able identity, not a dumping ground.** Aim for the *fewest* files that keep each topic cleanly findable. Fragmenting one topic across many near-duplicate slugs makes tags noisy and recall worse; cramming unrelated topics into one super-file makes tags meaningless. Pick the boundary on purpose.
 
-**Dedup first — recall by the topic AND by its family** (vertical / brand / parent domain), not just the exact phrase:
+**Dedup first — run the SEMANTIC nearest-neighbor check BEFORE you create anything.** Keyword recall only finds files you thought to search for; the exact keyword fragility this project keeps hitting. `dreamcontext embed dedup` embeds the candidate and returns its closest existing docs by meaning — the guesswork-free dedup gate:
+
+```bash
+dreamcontext embed dedup --if-present \
+  --title "<candidate title>" \
+  --description "<one-line summary>" \
+  --content "<the body you were about to write>"   # or --file <path> / --stdin
+```
+
+It prints the nearest knowledge+feature docs with cosine similarity and a **verdict**:
+
+| Verdict | What it means | What you do |
+|---|---|---|
+| **MERGE** | A near-verbatim twin already exists (cosine ≥ 0.97, decisively closer than the runner-up) | Do **not** create. Extend the named file (or `dreamcontext knowledge merge` at deep tier). |
+| **REVIEW** | Same-topic candidate in the 0.91–0.97 band | Apply the sharp-vs-soft rubric below against the **named** neighbor — usually extend it. |
+| **CREATE** | No near-duplicate above the review threshold | Safe to create — still sanity-check the top neighbor. |
+
+`--if-present` makes it a no-op (and it prints a fallback note) when this vault has no embedding cache or the model isn't installed — so it's always safe to run and never triggers a first-time model download during sleep. When it's a no-op or reports the model is unavailable, **fall back to keyword recall.** Semantic dedup is an ASSIST, not a replacement — also recall by the topic AND its family (vertical / brand / parent domain), especially for CREATE/REVIEW verdicts:
 
 ```bash
 dreamcontext memory recall "<topic>" --types knowledge,feature
@@ -236,7 +254,7 @@ Then decide — **default to extending an existing file**:
 | The **same vertical / brand / topic family** as an existing file, or a sub-aspect / increment / follow-up of a topic already covered (a *soft* distinction) | **Extend that file** — add a section, update `summary:` if it drifted. Don't fork a near-duplicate slug. Similar brands, similar verticals, similar topics belong together in the fewest files. |
 | A **genuinely separate topic / domain / concern** a future session would expect to find standing alone, where its own tag set sharpens discovery (a *sharp* distinction) | **Create a new file** (below). A clean topical boundary earns its own slug so tagging stays valuable. |
 
-The test for sharp-vs-soft: *Would a future recall expect this bundled with the existing file, or standing on its own? Would a separate file make the tag set more discriminating — or just split one topic across two slugs?* If splitting wouldn't sharpen the tags, extend.
+The test for sharp-vs-soft: *Would a future recall expect this bundled with the existing file, or standing on its own? Would a separate file make the tag set more discriminating — or just split one topic across two slugs?* If splitting wouldn't sharpen the tags, extend. A **MERGE** verdict settles it (extend); **REVIEW** is where this rubric earns its keep.
 
 This is **not** "always make super-files." Distinct topics MUST get distinct files — that's exactly what makes tags worth having. It's the *soft* distinctions (same family, narrower slice, incremental finding) that fold into an existing file.
 
@@ -411,6 +429,7 @@ Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/resea
 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).** 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.
+8b. **`knowledge/archive/` is off-limits.** It holds `sleep-state`'s ceiling-vs-promotion escalation writes (archive-before-delete, task `improve-sleep-quality` AC6) — never group, move, retag, or merge those files; they are not yours to organize.
 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

@@ -233,6 +233,14 @@ If a file exceeds ~150 lines:
 - Replace the extracted block with a one-line reference: `> Archived to knowledge/<slug>.md`.
 - Merge into existing entries before adding new ones — never duplicate.
 
+**Standing authority — ceiling vs. promotion collision.** Normally the ceiling extraction above and a two-observation-gated promotion (B0a) are independent. But when a promotion the gate genuinely warrants is BLOCKED because the target file is already AT the ~150-line ceiling, flagging it for `sleep-product` lets it lose every cycle indefinitely — the exact recidivism this fixes (a promotion that clears the gate but never lands). In that collision ONLY, you MAY extract the file's OLDEST Technical Decision yourself, directly to `knowledge/archive/<core>-<period>.md` (e.g. `knowledge/archive/2.memory-2026-h1.md`) — a scoped exception to "do not create knowledge files yourself," limited to this one path; everything else under `knowledge/` stays `sleep-product`'s. **Archive-before-delete, no exceptions:**
+1. Write the archive file FIRST, full content, dated.
+2. Verify it landed (`cat` it back, or `dreamcontext knowledge index --plain`).
+3. ONLY THEN replace the source block with `> Archived to knowledge/archive/<core>-<period>.md`.
+4. Promote the new entry into the now-freed space.
+
+Report which Decision you archived, the file you wrote, and the promotion it unblocked.
+
 The ceiling tightened from 300 to 150 in v0.4.0+ because `dreamcontext memory recall` can now retrieve any extracted content on demand. The snapshot pre-loads only the freshest, most-cited entries; older context lives in knowledge files and is still findable via BM25 recall. Aggressive pruning is preferred over generous retention.
 
 For extended core files (`3-6.*`), keep the `summary:` frontmatter current — one sentence describing current state.
@@ -246,6 +254,17 @@ Read `knowledge_access` from `.sleep.json`:
 
 You do **not** edit knowledge files. Produce flags for `sleep-product` to act on.
 
+#### C3. Recidivism flags — recurring problems for `sleep done --flag`
+
+If a problem in YOUR domain keeps recurring across cycles — a Decision stuck behind the ceiling for 2+ cycles running, a Known Issue that keeps reappearing, a C2 staleness flag already raised last cycle and still unresolved — report it as a flag spec so the orchestrator can pass it to `sleep done`:
+
+```
+### Recidivism flags (for `sleep done --flag`)
+- ceiling-blocked:2.memory.md::"2.memory.md at ceiling — WKWebView decision promotion blocked again"
+```
+
+`sleep done --flag <key>::<label>[::<task-slug>]` is repeatable — the orchestrator passes one `--flag` per flag it collects from every specialist's report (never comma-separated). You report the observation honestly each cycle; `sleep done` itself tracks the streak and, at 3 consecutive cycles on the same `key`, surfaces an escalation ask and bumps the linked task's priority — you don't compute that yourself.
+
 ## Return — single combined report
 
 ```
@@ -279,6 +298,9 @@ You do **not** edit knowledge files. Produce flags for `sleep-product` to act on
 ### Cross-domain mentions (for other specialists)
 - (none) | OR: research finding worth long-term retention — flagging for sleep-product
 
+### Recidivism flags (for `sleep done --flag`)
+- (none) | OR: ceiling-blocked:2.memory.md::"2.memory.md at ceiling — WKWebView decision promotion blocked again"
+
 Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/decision you saw but did NOT promote into changelog/core/2.memory.md, with the reason>
 ```
 
@@ -297,3 +319,5 @@ Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/decis
 9. **Decisions > deliberation.** Save the conclusion and rationale; drop the back-and-forth.
 10. **Surgical edits only on core.** Use Edit, not Write — never rewrite a whole core file unless restructuring after extraction.
 11. **Match existing changelog voice** — read recent entries first.
+12. **The `knowledge/archive/` write is scoped and rare.** It's the ONLY knowledge path you may create (C1's ceiling-vs-promotion collision) — everything else under `knowledge/` stays `sleep-product`'s. Archive-before-delete, always: write, verify, then replace.
+13. **Report recidivism honestly, every cycle.** Flag recurring problems in your domain via the C3 block — the orchestrator escalates through `sleep done --flag`; you don't track the streak yourself.

package/dist/agents/sleep-tasks.md

@@ -173,6 +173,8 @@ dreamcontext tasks status <slug> in_review "Needs your eyes — <the specific th
 
 The single test: **would the user actually want to look at this before it's closed?** If yes → `in_review`. If it's done and there's nothing to second-guess → `completed`. When you're genuinely unsure, prefer `in_review`. Only the never-done categories below (superseded / abandoned / obsoleted) ever go to `in_review` *for closing* — that's handing the user a close decision, not a completion.
 
+**Foreign tasks are NOT evidence (#177).** A task synced from a SHARED remote container (a ClickUp list two projects both sync) carries a `source_project:` frontmatter field, and the SessionStart snapshot flags it `⚠ FOREIGN`. That row describes work in ANOTHER repo. **Never treat a foreign `completed` task as proof that the corresponding work is done HERE** — it once nearly dropped a whole local work group because a sibling repo's finished task read as "already done". Do not reconcile, re-status, or close a native task on the strength of a foreign one; verify against THIS project's own source (its code, its changelog, its PRs) first. When in doubt, leave the native task as-is and flag the ambiguity in your report. A shared list is a data hazard — surface it (`dreamcontext doctor` warns when two registered projects share one list) rather than silently trusting it.
+
 ### 5. Version readiness signal (no auto-release)
 
 After bumping statuses, check if the active planning version is now release-ready:
@@ -215,6 +217,17 @@ dreamcontext tasks list          # every non-completed task, with updated dates
 
 **(d) Objective linking (only when `core/objectives/` is non-empty).** Objectives are the PO's OKR roadmap items; tasks link to them many-to-many via the `objectives:` frontmatter list. For each task you touched (or created) whose `objectives:` is **absent or empty**, judge which objective(s) the work genuinely serves — check `dreamcontext roadmap objective list` for the live set — and set them: `dreamcontext tasks objectives <slug> <a,b>` (multiple slugs when one task lifts several outcomes, e.g. revenue AND retention — that's expected, not double-counting). **HARD RULE: a non-empty `objectives:` list is a PO decision — NEVER change or extend it.** If no objective fits, leave the field empty; do not force a link. You only edit the task-side field; `core/objectives/*.md` prose/title/dates/structure stay PO-authored and off-limits. Rollups/forecasts recompute when the orchestrator runs `dreamcontext roadmap` after your report.
 
+**(e) Recidivism — check before you flag again.** Read `_dream_context/state/.sleep-flags.json` (plain Read, no CLI) before grooming: if a task/problem you're about to note as "still not done" already carries `consecutive_cycles >= 3` from prior cycles, it has ALREADY been escalated — do not just emit another passive flag observation and move on. Take a real action instead: reconcile it now if it's actually done, `in_review` with an explicit "recurred N cycles — needs your decision" if it's genuinely stuck, or close it if the recurrence itself proves it's dead. Emitting another flag for a problem already at the threshold is the exact failure this closes (`fix-releases-add-auto-discovery-scoping-bug` recurred 5× and stayed `todo`).
+
+For everything NOT yet escalated, report new/continuing recurrence as a flag spec for the orchestrator to pass at `sleep done`:
+
+```
+### Recidivism flags (for `sleep done --flag`)
+- recurring-task:fix-releases-add-auto-discovery-scoping-bug::"still todo after N cycles"::fix-releases-add-auto-discovery-scoping-bug
+```
+
+`sleep done --flag <key>::<label>[::<task-slug>]` is repeatable — one `--flag` per flag (never comma-separated). At 3 consecutive cycles on the same `key`, `sleep done` itself surfaces the escalation ask and bumps the linked task's priority — you only report the observation honestly each cycle, you don't compute the streak.
+
 **Key Result current — you MAY update it, EXCEPT on insight-fed objectives.** When this cycle surfaced a new real observed value for an objective's Key Result metric (e.g. MRR moved to $1,250, active users hit 400) — from the transcript, a file, or a connected system — refresh it: `dreamcontext roadmap objective metric <slug> --current <n>`. This is the ONE write you may make to a `core/objectives/*.md` file, and only through this CLI verb (never hand-edit the frontmatter). Use a value you actually observed — do not invent or estimate a number. The roadmap board regen at the end of sleep will reflect the new progress.
 
 **Insight-bound Key Results are hands-off.** Some objectives are *measured*, not asserted: a Lab insight (`_dream_context/lab/insights/<slug>.md`) may carry `binding: {objective: <slug>}`, meaning `lab bind` seeded — and every `lab sync` rewrites — that objective's `metric.current`. Before any metric write, check for a feeder: `dreamcontext lab list --json` and look for a manifest whose `binding.objective` equals the objective's slug (one feeder max per objective). If bound, do NOT write `metric.current` — your number would be overwritten at the next sync and blurs measured-vs-asserted provenance. If the feeding insight's cache looks stale or errored (`dreamcontext lab show <slug>` → old `fetchedAt` / `error` set), say so in your report so the user refreshes it. **Sleep NEVER runs `lab sync`** — that's a standing decision (credential exposure, latency, non-determinism); refreshing is always an explicit user/agent action outside sleep.
@@ -234,6 +247,8 @@ Never silently delete a task, and never `completed` a task that was never actual
 - Backlog grooming: <slug> obsoleted by pivot → in_review ("confirm close"), <slug> re-attached v0.8.x→v0.9.0, <slug> tags normalized + facets added, <slug> priority high→medium (untouched 30d), 2 tasks left as-is (genuinely planned)
 - Objective links: <slug> → [retention-20, revenue] (was empty), <slug> left unlinked (no objective fits) | OR: no objectives in this project — skipped
 - KR metrics: <objective> current → <n> (observed in transcript) | <objective> SKIPPED — fed by bound insight <insight-slug> (cache stale since <date>; suggest `lab sync <insight-slug>`) | OR: no metric observations this cycle
+- Recidivism flags: recurring-task:<slug>::"still todo after N cycles"::<slug> | OR: none this cycle
+- Recidivism actions: <slug> was already escalated (consecutive_cycles >= 3) → set in_review "recurred N cycles — needs your decision" instead of re-flagging | OR: none escalated
 - Cross-domain mentions: <slug> includes a memory-worthy decision about JWT — flagging for sleep-state
 - Skipped: <session_id> had no actionable task signal
 
@@ -251,3 +266,4 @@ Dropped-but-load-bearing self-check: <none | list any digest/auto-bookmark/task
 7. **Person attribution is multi-person only.** Read `.config.json` `people` first. If 0 or 1 entry, step 2.5 is a complete NO-OP — never inject `person:` tags on solo projects. Derived multi-person status comes from `people.length > 1`; there is no `multiPerson` key to check.
 8. **Normalize tags via taxonomy vocab.** When writing or updating task frontmatter tags, check `dreamcontext taxonomy vocab` and use canonical forms (faceted or bare standard tags); non-canonical tags degrade recall.
 9. **Objectives: propose for empty, never overwrite non-empty.** An existing `objectives:` value is a PO decision that sticks. You fill blanks with judgment; you never revise the PO's linking. Objective files themselves (`core/objectives/`) are PO-authored — never hand-edit their prose, title, dates, or structure — with the single exception that you may refresh a Key Result's `current` via `dreamcontext roadmap objective metric <slug> --current` when you observed a new real value (see grooming (d)) — and NEVER on an objective fed by a bound Lab insight (check `dreamcontext lab list --json` for `binding.objective`; measured values belong to `lab sync`, which sleep never runs).
+10. **Recidivism — act on escalated flags, don't just re-flag.** Read `state/.sleep-flags.json` before grooming; a problem already at `consecutive_cycles >= 3` needs a real decision (in_review / close / fix), not another passive flag line. Report new/continuing recurrence via the flag-spec block (grooming (e)) so the orchestrator can pass `sleep done --flag`.