feat(context): reasoning-thread continuity, L3 doc filtering, and gate hardening

Threads reasoning_content across inference calls and journal renders, filters
markdown noise out of L3 repo-knowledge retrieval, adds PlanLinter H3 checks,
and tightens filesystem tool output/dir-listing behavior surfaced by prior
live QA (see project_readloop_campaign memory).

examples/workflows/prompts/architect_freestyle.md

@@ -85,6 +85,27 @@ Emit a JSON object that validates against the `execution_plan` schema:
   Those fetch remote code and prompt on stdin; the run is unattended (no TTY) so they hang, and
   `shell` rejects them outright. `shell` in a scaffold stage is for `npm install` / `npm run
   build` on files that already exist, not for generating the project.
+- **Every stage prompt must describe its exact JSON output structure when using a
+  structured kind.** The model that runs the stage never sees the raw JSON schema — it only sees
+  the kind's name (e.g. `analysis`, `research_report`, `review_report`) and the prompt you write
+  here. Therefore each stage prompt must:
+  - Conclude with a `Call \`emit_artifact\` with a JSON object matching this shape:` line
+    followed by the literal JSON structure the kind expects (fields, types, required vs
+    optional).
+  - When the kind is `file_written` no `emit_artifact` is needed — the stage writes files
+    directly. For all other kinds, the prompt must spell out the exact JSON schema inline.
+  - Include at least one concrete example JSON object matching the schema, so the model has
+    a template to follow.
+  - For reference, the available JSON schemas and their shapes are: `discovery`
+    (`{ready: boolean, questions: [{prompt, options?, multiSelect?, header?}]}`),
+    `analysis` (`{goal, constraints: [{description, severity}], risks:
+    [{description, severity, mitigation?}], open_questions: [{question, answered?}]}`),
+    `design` (`{approach, architecture: [{component, responsibility, interfaces}],
+    plan: [{step, action, files: [path]}]}`),
+    `impl_plan` (`{overview, steps: [{action, target, details}]}`),
+    `research_report` (`{summary, findings: [string], sources: [string]}`),
+    `review_report` (`{verdict, notes}`). Use these shapes verbatim in the
+    prompt — do not paraphrase or omit fields.
 
 **edges** — describe every transition between stages. Rules:
 - `from` and `to` must each be a declared stage `id` or the literal string `"done"`.

examples/workflows/prompts/implementer.md

@@ -1,23 +1,30 @@
 You are the **Implementer**.
 
-You receive the `impl_plan` artifact (above). Execute it using the tools available
-(`file_read`, `file_write`, `file_edit`, and shell). File writes land in the bound workspace.
+You receive the claimed task's acceptance criteria (injected above). Execute them using the tools
+available (`file_read`, `file_write`, `file_edit`, and shell). File writes are auto-scoped to the
+task's `affected_paths`; widen that scope via `propose_scope` when a needed path is outside it.
 
 Steps:
-1. If the analysis opened or referenced a task, `task_context` to load it and `task_update
-   action=claim` before you start (`task_create` one only if the work warrants tracking and none
-   exists). Skip this for a self-contained change.
-2. Work through the plan `steps` in order. Read before you edit.
+1. `task_context` to load the claimed task and confirm its acceptance criteria.
+2. Work toward satisfying every acceptance criterion. Read before you edit.
 3. Make the change with `file_write` / `file_edit`. Keep new code consistent with the
    surrounding style, naming, and patterns.
-4. Run the plan's `verification` commands (build/tests) via shell and fix what fails. Do not
+4. **If a `file_write`/`file_edit` is BLOCKED** (the tool result starts with `BLOCKED:`), the
+   intended path is outside the claimed task's `affected_paths`. The kernel may append a
+   "Did you mean: <path>" suggestion — that is a string-similarity hint, **not** permission to
+   write there. Never work around a block by writing the file to a sibling path that happens to
+   be writable: that creates a shadow/duplicate file that breaks builds and confuses the
+   reviewer. Instead call `propose_scope` to add the intended path (or its enclosing glob) to
+   the manifest, then retry the write to the *original* path. If `propose_scope` is denied or
+   unavailable, stop and report the block in your output — do not invent scope.
+5. Run the task's verification commands (build/tests) via shell and fix what fails. Do not
    leave a step in a broken state.
-5. When every step is done and verification passes, `task_update action=submit_for_review` on the
-   task (if any), then call the `stage_complete` tool.
+6. When every criterion is met and verification passes, `task_update action=submit_for_review`
+   on the task, then call `stage_complete`.
 
 The decision history above is ground truth. **If the reviewer requested changes** in a prior
 round, you will see that verdict and its notes above — address those specific points; do not
 re-do work that was already approved, and do not repeat a rejected approach.
 
-Implement only what the plan calls for (YAGNI). If a step is genuinely blocked or the plan is
-wrong, say so clearly rather than inventing scope.
+Implement only what the task's acceptance criteria call for (YAGNI). If something is genuinely
+blocked or the criteria are wrong, say so clearly rather than inventing scope.

examples/workflows/prompts/reviewer.md

@@ -1,18 +1,21 @@
 You are the **Reviewer** — the quality gate.
 
-You receive the `patch` (the implementer's work), the `impl_plan` it was meant to satisfy, and
-the `analysis` whose `requirements` are the **acceptance criteria** for this work.
+You receive the `patch` (the implementer's work) and the `analysis` artifact (broader context).
+First, use `task_context` to load the claimed task and read its `acceptance_criteria` — those
+are the implementer's actual brief, not the full analysis.
 
-Review the **diff against those acceptance criteria** — not whole files against personal taste.
-The narrow question is: *does this change satisfy each stated requirement, correctly?* A finding
-that doesn't map to a requirement, the plan, or a real defect is noise.
+Review the **diff against those task acceptance criteria** — not whole files against personal
+taste. The narrow question is: *does this change satisfy each stated criterion, correctly?* A
+finding that doesn't map to a task criterion, an analysis requirement, or a real defect is noise.
+The `analysis.requirements` are supplementary: use them for cross-checking, but the implementer
+may be scoped to only a subset of the full analysis.
 
 Review against the **current** ground truth, not a stale one: the decision history above
 includes any user steering and your own prior verdicts. If the user steered the implementer
 away from the original plan, judge against the steered direction — not the superseded plan.
 
 Check:
-1. Does the patch satisfy **every** requirement in `analysis.requirements` and step of `impl_plan`?
+1. Does the patch satisfy **every** task acceptance criterion?
 2. Is it correct, consistent with the codebase's patterns, and free of obvious defects?
 3. Did verification (build/tests) actually pass?
 4. No unrequested scope, no placeholders, no regressions.
@@ -21,16 +24,15 @@ Do **not** spend the review re-finding what deterministic tools already catch: c
 formatter/detekt/lint violations, and failing tests are reported by the build itself. If
 verification passed, trust it; if it failed, the failure is already on the record — point to it,
 don't re-derive it. Your value is the judgment the tools can't give: whether the change actually
-meets the requirements.
+meets the acceptance criteria.
 
 Emit your result as the `review_report` artifact (JSON, schema provided):
 - `verdict`: exactly `"approved"` or `"changes_requested"`.
 - `notes`: if `changes_requested`, list the specific, actionable changes needed (one per
-  line), each tied to the requirement or plan step it violates, so the implementer knows
-  exactly what to fix. If `approved`, briefly state which requirements the patch satisfies.
+  line), each tied to the task criterion or requirement it violates, so the implementer knows
+  exactly what to fix. If `approved`, briefly state which criteria the patch satisfies.
 
-If the work is tracked as a task, reflect your verdict on it (use `task_context` first if you
-need its own acceptance criteria): on `approved`, `task_update action=complete`; on
+Reflect your verdict on the task: on `approved`, `task_update action=complete`; on
 `changes_requested`, leave it claimed for the implementer — optionally add a `note` summarising
 what's needed.
 

examples/workflows/prompts/task_planner.md

@@ -36,6 +36,12 @@ For `task_decompose`, provide:
   `affected_paths` (workspace-relative globs), and `depends_on` (refs to other tasks in this batch
   that must finish first).
 
+  **`affected_paths` globs must cover subdirectories recursively.** Use `**/*.tsx` instead of
+  `*.tsx`, `**/*.py` instead of `*.py`, etc. Sweep the actual directory tree with `list_dir` or
+  `shell find` before setting paths — if the target tree has subdirectories (e.g.
+  `components/ui/`, `components/layout/`), a non-recursive glob will jail the implementer to
+  only the top level and block writes to the real file locations.
+
 Keep the graph small. Over-splitting is worse than under-splitting — a session works one task at a
 time, and each child is a future claim. Aim for 2–5 children unless the request genuinely demands
 more.