@runfusion/fusion 0.75.0-beta.0 → 0.75.0-beta.2

package/dist/plugins/fusion-plugin-reports/bundled.js

@@ -5787,6 +5787,7 @@ __export(project_exports, {
   tasks: () => tasks,
   todoItems: () => todoItems,
   todoLists: () => todoLists,
+  unplannedExecutionBlocks: () => unplannedExecutionBlocks,
   usageEvents: () => usageEvents,
   verificationCache: () => verificationCache,
   workflowPromptOverrides: () => workflowPromptOverrides,
@@ -5826,6 +5827,7 @@ var tasks = projectSchema.table("tasks", {
   worktree: text("worktree"),
   blockedBy: text("blocked_by"),
   overlapBlockedBy: text("overlap_blocked_by"),
+  queuedLogEpisodeSignature: text("queued_log_episode_signature"),
   paused: integer("paused").default(0),
   userPaused: integer("user_paused").default(0),
   pausedReason: text("paused_reason"),
@@ -6631,6 +6633,14 @@ var workflowWorkItems = projectSchema.table("workflow_work_items", {
   index("idx_workflow_work_items_task_run").on(t.taskId, t.runId),
   uniqueIndex("idx_workflow_work_items_one_active_task_continuation").on(t.projectId, t.taskId).where(sql`${t.kind} = 'task' AND ${t.state} IN ('runnable', 'running', 'held', 'retrying')`)
 ]);
+var unplannedExecutionBlocks = projectSchema.table("unplanned_execution_blocks", {
+  projectId: text("project_id").notNull().default(sql`current_setting('fusion.project_id', true)`),
+  taskId: text("task_id").notNull(),
+  episode: text("episode").notNull(),
+  createdAt: text("created_at").notNull()
+}, (t) => [
+  primaryKey({ columns: [t.projectId, t.taskId, t.episode] })
+]);
 var workflowRunBranches = projectSchema.table("workflow_run_branches", {
   projectId: text("project_id").notNull().default(sql`current_setting('fusion.project_id', true)`),
   taskId: text("task_id").notNull(),
@@ -12248,6 +12258,37 @@ var TRIAGE_POLICY_DEFAULTS = new Map(
   BUILTIN_TRIAGE_POLICY_SETTINGS.map((setting) => [setting.id, setting.default])
 );
 
+// ../core/src/agents/planning-review-policy.ts
+var PLANNING_COMPLETENESS_POLICY = `## Mandatory Planning Completeness Procedure
+
+Before writing the final PROMPT.md:
+
+1. Build an internal **planning ledger** from the Original Description, user comments, project instructions, cited issue/report, and any saved planning document. Preserve every requirement, settled decision, explicit non-goal, and acceptance outcome; do not silently replace the reporter's contract with a narrower reproduction.
+2. Research before structuring the plan. Trace the affected behavior through its real production entry points, callers, writers/readers, shared consumers, persistence boundaries, recovery paths, and existing tests. Resolve planning-time facts from the repository now; defer only details that genuinely require implementation-time discovery, and label those explicitly.
+3. For stateful, lifecycle, persistence, or concurrency work, enumerate the participant graph and both relevant orderings: stale-work cancellation/fencing, lock order and reentrancy, transaction boundaries, pool/transport limits, competing recovery paths, configuration/deployment identities, bypass/force paths, and failure cleanup. Every stated invariant must name the surfaces that preserve it.
+4. Map every ledger row to concrete File Scope entries, dependency-ordered implementation steps, and verification. Each feature-bearing step must name specific automated test scenarios with the input/state, action or ordering, and expected observable result; helper-only tests do not prove production reachability.
+5. Keep scope disciplined. Reuse current architecture and documented patterns unless the reporter contract requires a redesign. Put optional cleanup and adjacent ideas outside the active steps.
+6. Before persisting PROMPT.md, perform a fresh holistic completeness pass across the whole ledger. Try to disprove the plan by checking referenced paths and patterns, missing consumers, contradictory steps, uncovered failure orderings, and acceptance criteria without tests. Fix all gaps in one pass.
+
+On a revision, treat the cumulative revision ledger as durable decisions unless a later entry explicitly supersedes one: preserve resolved items, address every unresolved item surgically, and rerun the complete procedure instead of checking only the latest comment.`;
+var FAST_PLANNING_COMPLETENESS_POLICY = `## Fast Planning Completeness Check
+
+Before writing PROMPT.md, build a compact internal ledger from the Original Description, user comments, project rules, and acceptance outcomes. Inspect the real production callers/consumers, persistence or recovery paths, and nearby tests before choosing File Scope. For stateful or concurrent work, enumerate every participant plus both relevant orderings and failure cleanup. Map each requirement to a concrete step, file, and automated test scenario, then reread the whole plan once for missing surfaces, contradictions, and unproved outcomes. On revision, preserve prior decisions and address the complete cumulative ledger, not only the latest note.`;
+var PLAN_REVIEW_COMPLETENESS_POLICY = `## Mandatory Plan Review Procedure
+
+Apply this procedure to plan/spec reviews only. Code reviews use their dedicated procedure.
+
+Before choosing a verdict:
+
+1. Build one **review ledger** for the entire PROMPT.md: Original Description and user comments; Mission and Completion Criteria; Surface Enumeration and Symptom Verification when required; every implementation step, File Scope entry, dependency, risk, and test/verification promise.
+2. Complete the full review before reporting. Check coherence and requirement traceability, feasibility against the current repository, scope discipline, execution ordering, and verification quality. When relevant, also inspect security/data integrity, state transitions, concurrency orderings, deployment/configuration boundaries, recovery competitors, and force/bypass paths.
+3. Review at specification altitude. Block when a required behavior, surface, ordering, safety constraint, or proof is missing or the stated approach cannot work. Keep optional implementation detail, wording polish, and nonessential improvements advisory.
+4. If REVISE is necessary, batch **all independently discoverable blocking findings** into this one verdict; do not stop after the first defect. Give each blocker a stable ID, cite the affected section or repository evidence, and state the concrete PROMPT.md correction. Put advisory observations in a separate list.
+5. On re-review, use the supplied prior-review ledger as a decision primer. Verify every prior blocker, do not re-raise resolved or rejected semantic duplicates, and preserve accepted decisions. A newly blocking finding must say whether the revision introduced it, which prior blocker genuinely masked it, or why it is independently delivery-blocking for correctness, security, data safety, or executability. Record an earlier reviewer miss explicitly; never demote a critical defect merely because it was missed before.
+6. After any same-session PROMPT.md edit, distrust the edit: reread the complete artifact, rebuild the ledger, and perform a fresh holistic pass before APPROVE.
+
+APPROVE when the plan is executable and verifiable, not when it is cosmetically perfect. If returning REVISE, the verdict notes must contain the complete blocking checklist because those notes are the durable input to the next planning round.`;
+
 // ../core/src/agents/agent-prompts.ts
 var FUSION_RUNTIME_SELF_AWARENESS = `## Runtime Self-Awareness
 
@@ -12454,6 +12495,8 @@ The tool prevents your session from being killed by the inactivity watchdog duri
 - If a verification command times out, do NOT blindly retry \u2014 investigate. Check for hung subprocesses, infinite test loops, or tests waiting on missing dependencies. Use \`node_modules/.modules.yaml\` presence to confirm bootstrap.`;
 var FAST_TRIAGE_PROMPT_TEXT = `You are a task specification agent for "fn". This task is running in **fast mode**.
 
+${FAST_PLANNING_COMPLETENESS_POLICY}
+
 Write a lean, executable PROMPT.md quickly. Preserve safety gates, but skip heavyweight ceremony, review scoring, and proactive subtask analysis.
 
 ## Fast-mode priorities
@@ -12462,7 +12505,7 @@ Write a lean, executable PROMPT.md quickly. Preserve safety gates, but skip heav
 - Preserve required safety sections for bugs, workflow routing, forensic tasks, and decision-only work.
 
 ## Duplicate check
-Before writing a spec, call \`fn_task_list\` for active work, then call \`fn_task_search\` with 2-4 targeted keyword phrases from the title/description, such as file paths, symptoms, and symbols. For any likely match in \`done\` or \`archived\`, call \`fn_task_show\` and inspect it before deciding. If an existing task covers the same work, do not write a spec \u2014 but still write PROMPT.md, with its entire contents being the single line \`DUPLICATE: {existing-task-id}\` and nothing else. That file is how the duplicate is recorded; announcing it only in your reply leaves no plan behind and re-plans the task in a loop.
+Before writing a spec, call \`fn_task_list\` for active work, then call \`fn_task_search\` with \`includeDone: false\` and \`includeArchived: false\` for 2-4 targeted keyword phrases from the title/description, such as file paths, symptoms, and symbols. Do not search completed or archived work for duplicate candidates. When an active match is a duplicate, do not write a spec \u2014 but still write PROMPT.md, with its entire contents being the single line \`DUPLICATE: {existing-task-id}\` and nothing else. That file is how the duplicate is recorded; announcing it only in your reply leaves no plan behind and re-plans the task in a loop.
 
 ## Required PROMPT.md shape
 Write PROMPT.md with Original Description, Before \u2192 After Transformation, Mission, Dependencies, Context to Read First, File Scope, Steps, Documentation Requirements, Completion Criteria, Git Commit Convention, and Do NOT. Put \`## Original Description\` immediately after the title/\`Created\`/\`Size\` metadata with the operator's original task description copied **verbatim** (do not paraphrase). Put \`## Before \u2192 After Transformation\` next, before \`## Mission\`, with concise Before/After bullets: current state, target state, why it satisfies the user's request at a glance. In \`## Steps\`, every executable heading MUST use \`### Step N: <name>\` (e.g. \`### Step 1: Preflight\`). Do not write bare \`### Preflight\` / \`### Implementation\` headings, and do not add review-level, triage subtask, or proactive subtask headings.
@@ -12504,6 +12547,8 @@ If the requested outcome is only to decide, route, or coordinate work, include \
 Write PROMPT.md directly and stop. Do not call \`fn_review_spec()\`; workflow Plan Review is the single optional plan review gate before execution.`;
 var TRIAGE_PROMPT_TEXT = `You are a task specification agent for "fn", an AI-orchestrated task board.
 
+${PLANNING_COMPLETENESS_POLICY}
+
 ## Your Role
 You are the specification quality gate for implementation success.
 Your job: take a rough task description and produce a fully specified PROMPT.md that another AI agent can execute autonomously in a fresh context with zero memory of this conversation.
@@ -12728,9 +12773,9 @@ Verified facts about this codebase's storage \u2014 cite these correctly so Plan
 - New Postgres migrations must be **registered explicitly** in \`packages/core/src/postgres/schema-applier.ts\` (version constant + bookkeeping check); a \`.sql\` file dropped in the migrations dir that is not wired there silently never runs.
 
 ## Duplicate check
-Before writing a spec, first call \`fn_task_list\` to see active tasks, then call \`fn_task_search\` with 2-4 distinct keyword phrases from the task title and description (for example file paths, error symptoms, and symbol names).
-For any likely match in \`done\` or \`archived\`, call \`fn_task_show\` to inspect details before deciding.
-If a task already covers the same work (even if worded differently), do not write a spec.
+Before writing a spec, first call \`fn_task_list\` to see active tasks, then call \`fn_task_search\` with \`includeDone: false\` and \`includeArchived: false\` for 2-4 distinct keyword phrases from the task title and description (for example file paths, error symptoms, and symbol names).
+Do not search completed or archived work for duplicate candidates.
+If an actionable task already covers the same work (even if worded differently), do not write a spec.
 Instead you MUST still write PROMPT.md, with its ENTIRE contents being this one line and nothing else:
 \`DUPLICATE: {existing-task-id}\`
 Writing that file IS how you report the duplicate. Reporting it only in your reply is not recorded:
@@ -12761,7 +12806,7 @@ Workflow policy can disable proactive oversized-task splitting for operators who
 ## Triage tools
 You have these extra tools during triage:
 - \`fn_task_list\` \u2014 list existing active tasks
-- \`fn_task_search\` \u2014 keyword search across tasks, including done and archived tasks
+- \`fn_task_search\` \u2014 keyword search across active tasks by default; history is opt-in for non-duplicate research
 - \`fn_task_show\` \u2014 inspect a task and its PROMPT.md
 - \`fn_task_create\` \u2014 create a child/follow-up task while triaging
 - \`fn_task_document_write\` \u2014 save a planning document (e.g., key="plan")
@@ -12988,20 +13033,6 @@ Concrete examples:
 - [Optional improvements, not blocking]
 \`\`\`
 
-## Spec / Plan Review Convergence
-
-Specs and pre-execution Plan Review share this gate. Prefer **APPROVE** / **APPROVE_WITH_NOTES** when the plan is executable enough for an agent to implement. Put optional polish only under **Suggestions**.
-
-When you must **REVISE**:
-- List each blocking issue as a concrete PROMPT.md edit (which section, what to add/change/remove).
-- Do not demand a full rewrite unless the approach is fundamentally wrong (**RETHINK**).
-- Prefer fixing local PROMPT.md defects in-session when you have write tools, then **APPROVE**, instead of bouncing the task through another full replan cycle.
-
-**Converging on re-review (when the request includes your prior feedback + a Plan Review attempt number):**
-- This is a spec you already reviewed. VERIFY each issue you previously raised was addressed. REVISE only for (a) a PRIOR blocking issue still unresolved, or (b) a genuinely NEW problem THIS revision introduced.
-- Do NOT introduce a new blocking issue that ALSO applied to the version you previously reviewed \u2014 that is your own earlier miss. Record it under **Suggestions**, not REVISE.
-- **Severity ratchet at attempt 3+:** gate ONLY on \`critical\` (delivery-blocking) issues. Downgrade lone \`important\`/\`minor\` spec-wording nits to **Suggestions** and APPROVE. Rationale: the executor and downstream code review are later gates \u2014 a spec need not be perfect to be executable, only executable.
-
 ## Spec Review \u2014 Undersplit Task Detection
 
 When reviewing specs, assess whether the task should have been broken into subtasks. The bar for splitting is high \u2014 most tasks should remain whole. Coordination overhead (worktrees, dependency wiring, merge sequencing) is real, so splitting must clearly pay for itself.
@@ -13649,6 +13680,22 @@ function browserVerificationOptionalGroupNode(column, options = {}) {
   };
 }
 
+// ../core/src/agents/code-review-policy.ts
+var CODE_REVIEW_COMPLETENESS_POLICY = `## Mandatory Code Review Procedure
+
+Apply this procedure to code reviews only. Plan/spec reviews use their dedicated criteria below.
+
+Before choosing a verdict:
+
+1. Build a **requirements ledger** from PROMPT.md. For every Mission outcome, Completion Criterion, relevant \`## Surface Enumeration\` item, and \`## Symptom Verification\` assertion, identify both implementation evidence and test evidence. A missing or partial required row is REVISE.
+2. Trace each changed behavior from its **real production entry point** and selector through the changed helper to its consumers. A helper-only unit test does not prove that production can reach the new branch.
+3. For bug fixes, locate an automated test that reproduces the exact reported failure and asserts it is gone across the enumerated surfaces. Green builds, nearby unit tests, and synthetic state injection alone are insufficient.
+4. For persistence, lifecycle, and concurrency changes, verify that evidence belongs to the **current state, version, or planning episode**; every read-check-write path is atomic, locked, or CAS-protected; all mutation surfaces preserve the invariant; waits and locks are bounded and cleanup-safe; and a production-shaped integration test covers both relevant orderings.
+5. For route or state changes, inspect all affected UI, API, CLI, and agent consumers plus paired success/failure or approve/reject paths for contract parity.
+6. Before APPROVE, perform a fresh adversarial validation pass: try to disprove each completed ledger row by reading the real caller, guard, consumer, and test. Cite \`file:line\` for every blocker and name the exact missing proof.
+
+APPROVE only when every required ledger row has implementation and test evidence.`;
+
 // ../core/src/workflows/builtin-code-review-group.ts
 var CODE_REVIEW_GROUP_ID = "code-review";
 var CODE_REVIEW_STEP_NODE_ID = "code-review-step";
@@ -13668,6 +13715,8 @@ var CODE_REVIEW_PROMPT = `You are a senior code reviewer. Review the task's diff
 5. **Error handling** \u2014 swallowed errors, unhandled rejections/exceptions, missing validation at trust boundaries, misleading error messages.
 6. **Contract / signature changes** \u2014 changed function/exported-type signatures, API request/response shapes, or serialization that breaks existing callers.
 
+${CODE_REVIEW_COMPLETENESS_POLICY}
+
 Be specific: cite \`file:line\` for every finding and explain the concrete failure it causes.
 
 ## Output Requirements
@@ -13787,12 +13836,14 @@ var PLAN_REVIEW_PROMPT = `You are a senior plan reviewer. Review the task's PROM
 4. **Verification quality** \u2014 absent or weak tests/checks for the behavior being changed.
 5. **Risk callouts** \u2014 migrations, data-loss paths, external integrations, secrets, or plugin/runtime dependencies that need explicit handling.
 
+${PLAN_REVIEW_COMPLETENESS_POLICY}
+
 Be specific: cite the plan section or file path for every finding and explain the concrete correction.
 
 ## Output Requirements
 - APPROVE: the plan is ready for execution.
 - APPROVE_WITH_NOTES: execution may proceed, but include non-blocking advisory notes.
-- REVISE: the plan should be corrected before execution; include the missing or wrong requirement and the needed change.
+- REVISE: the plan should be corrected before execution; include every blocking finding and needed change in the JSON notes, not only in preceding prose.
 - Final output: output exactly one trailing JSON object on the final line (no markdown fences, no surrounding prose):
 {"verdict":"APPROVE|APPROVE_WITH_NOTES|REVISE","notes":"..."}`;
 function planReviewOptionalGroupNode(column, options = {}) {

package/dist/plugins/fusion-plugin-reports/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fusion-plugin-examples/reports",
-  "version": "0.1.52-beta.0",
+  "version": "0.1.52-beta.2",
   "type": "module",
   "exports": {
     ".": {

package/dist/plugins/fusion-plugin-roadmap/bundled.js

@@ -5759,6 +5759,7 @@ __export(project_exports, {
   tasks: () => tasks,
   todoItems: () => todoItems,
   todoLists: () => todoLists,
+  unplannedExecutionBlocks: () => unplannedExecutionBlocks,
   usageEvents: () => usageEvents,
   verificationCache: () => verificationCache,
   workflowPromptOverrides: () => workflowPromptOverrides,
@@ -5798,6 +5799,7 @@ var tasks = projectSchema.table("tasks", {
   worktree: text("worktree"),
   blockedBy: text("blocked_by"),
   overlapBlockedBy: text("overlap_blocked_by"),
+  queuedLogEpisodeSignature: text("queued_log_episode_signature"),
   paused: integer("paused").default(0),
   userPaused: integer("user_paused").default(0),
   pausedReason: text("paused_reason"),
@@ -6603,6 +6605,14 @@ var workflowWorkItems = projectSchema.table("workflow_work_items", {
   index("idx_workflow_work_items_task_run").on(t.taskId, t.runId),
   uniqueIndex("idx_workflow_work_items_one_active_task_continuation").on(t.projectId, t.taskId).where(sql`${t.kind} = 'task' AND ${t.state} IN ('runnable', 'running', 'held', 'retrying')`)
 ]);
+var unplannedExecutionBlocks = projectSchema.table("unplanned_execution_blocks", {
+  projectId: text("project_id").notNull().default(sql`current_setting('fusion.project_id', true)`),
+  taskId: text("task_id").notNull(),
+  episode: text("episode").notNull(),
+  createdAt: text("created_at").notNull()
+}, (t) => [
+  primaryKey({ columns: [t.projectId, t.taskId, t.episode] })
+]);
 var workflowRunBranches = projectSchema.table("workflow_run_branches", {
   projectId: text("project_id").notNull().default(sql`current_setting('fusion.project_id', true)`),
   taskId: text("task_id").notNull(),
@@ -12128,6 +12138,37 @@ var TRIAGE_POLICY_DEFAULTS = new Map(
   BUILTIN_TRIAGE_POLICY_SETTINGS.map((setting) => [setting.id, setting.default])
 );
 
+// ../core/src/agents/planning-review-policy.ts
+var PLANNING_COMPLETENESS_POLICY = `## Mandatory Planning Completeness Procedure
+
+Before writing the final PROMPT.md:
+
+1. Build an internal **planning ledger** from the Original Description, user comments, project instructions, cited issue/report, and any saved planning document. Preserve every requirement, settled decision, explicit non-goal, and acceptance outcome; do not silently replace the reporter's contract with a narrower reproduction.
+2. Research before structuring the plan. Trace the affected behavior through its real production entry points, callers, writers/readers, shared consumers, persistence boundaries, recovery paths, and existing tests. Resolve planning-time facts from the repository now; defer only details that genuinely require implementation-time discovery, and label those explicitly.
+3. For stateful, lifecycle, persistence, or concurrency work, enumerate the participant graph and both relevant orderings: stale-work cancellation/fencing, lock order and reentrancy, transaction boundaries, pool/transport limits, competing recovery paths, configuration/deployment identities, bypass/force paths, and failure cleanup. Every stated invariant must name the surfaces that preserve it.
+4. Map every ledger row to concrete File Scope entries, dependency-ordered implementation steps, and verification. Each feature-bearing step must name specific automated test scenarios with the input/state, action or ordering, and expected observable result; helper-only tests do not prove production reachability.
+5. Keep scope disciplined. Reuse current architecture and documented patterns unless the reporter contract requires a redesign. Put optional cleanup and adjacent ideas outside the active steps.
+6. Before persisting PROMPT.md, perform a fresh holistic completeness pass across the whole ledger. Try to disprove the plan by checking referenced paths and patterns, missing consumers, contradictory steps, uncovered failure orderings, and acceptance criteria without tests. Fix all gaps in one pass.
+
+On a revision, treat the cumulative revision ledger as durable decisions unless a later entry explicitly supersedes one: preserve resolved items, address every unresolved item surgically, and rerun the complete procedure instead of checking only the latest comment.`;
+var FAST_PLANNING_COMPLETENESS_POLICY = `## Fast Planning Completeness Check
+
+Before writing PROMPT.md, build a compact internal ledger from the Original Description, user comments, project rules, and acceptance outcomes. Inspect the real production callers/consumers, persistence or recovery paths, and nearby tests before choosing File Scope. For stateful or concurrent work, enumerate every participant plus both relevant orderings and failure cleanup. Map each requirement to a concrete step, file, and automated test scenario, then reread the whole plan once for missing surfaces, contradictions, and unproved outcomes. On revision, preserve prior decisions and address the complete cumulative ledger, not only the latest note.`;
+var PLAN_REVIEW_COMPLETENESS_POLICY = `## Mandatory Plan Review Procedure
+
+Apply this procedure to plan/spec reviews only. Code reviews use their dedicated procedure.
+
+Before choosing a verdict:
+
+1. Build one **review ledger** for the entire PROMPT.md: Original Description and user comments; Mission and Completion Criteria; Surface Enumeration and Symptom Verification when required; every implementation step, File Scope entry, dependency, risk, and test/verification promise.
+2. Complete the full review before reporting. Check coherence and requirement traceability, feasibility against the current repository, scope discipline, execution ordering, and verification quality. When relevant, also inspect security/data integrity, state transitions, concurrency orderings, deployment/configuration boundaries, recovery competitors, and force/bypass paths.
+3. Review at specification altitude. Block when a required behavior, surface, ordering, safety constraint, or proof is missing or the stated approach cannot work. Keep optional implementation detail, wording polish, and nonessential improvements advisory.
+4. If REVISE is necessary, batch **all independently discoverable blocking findings** into this one verdict; do not stop after the first defect. Give each blocker a stable ID, cite the affected section or repository evidence, and state the concrete PROMPT.md correction. Put advisory observations in a separate list.
+5. On re-review, use the supplied prior-review ledger as a decision primer. Verify every prior blocker, do not re-raise resolved or rejected semantic duplicates, and preserve accepted decisions. A newly blocking finding must say whether the revision introduced it, which prior blocker genuinely masked it, or why it is independently delivery-blocking for correctness, security, data safety, or executability. Record an earlier reviewer miss explicitly; never demote a critical defect merely because it was missed before.
+6. After any same-session PROMPT.md edit, distrust the edit: reread the complete artifact, rebuild the ledger, and perform a fresh holistic pass before APPROVE.
+
+APPROVE when the plan is executable and verifiable, not when it is cosmetically perfect. If returning REVISE, the verdict notes must contain the complete blocking checklist because those notes are the durable input to the next planning round.`;
+
 // ../core/src/agents/agent-prompts.ts
 var FUSION_RUNTIME_SELF_AWARENESS = `## Runtime Self-Awareness
 
@@ -12334,6 +12375,8 @@ The tool prevents your session from being killed by the inactivity watchdog duri
 - If a verification command times out, do NOT blindly retry \u2014 investigate. Check for hung subprocesses, infinite test loops, or tests waiting on missing dependencies. Use \`node_modules/.modules.yaml\` presence to confirm bootstrap.`;
 var FAST_TRIAGE_PROMPT_TEXT = `You are a task specification agent for "fn". This task is running in **fast mode**.
 
+${FAST_PLANNING_COMPLETENESS_POLICY}
+
 Write a lean, executable PROMPT.md quickly. Preserve safety gates, but skip heavyweight ceremony, review scoring, and proactive subtask analysis.
 
 ## Fast-mode priorities
@@ -12342,7 +12385,7 @@ Write a lean, executable PROMPT.md quickly. Preserve safety gates, but skip heav
 - Preserve required safety sections for bugs, workflow routing, forensic tasks, and decision-only work.
 
 ## Duplicate check
-Before writing a spec, call \`fn_task_list\` for active work, then call \`fn_task_search\` with 2-4 targeted keyword phrases from the title/description, such as file paths, symptoms, and symbols. For any likely match in \`done\` or \`archived\`, call \`fn_task_show\` and inspect it before deciding. If an existing task covers the same work, do not write a spec \u2014 but still write PROMPT.md, with its entire contents being the single line \`DUPLICATE: {existing-task-id}\` and nothing else. That file is how the duplicate is recorded; announcing it only in your reply leaves no plan behind and re-plans the task in a loop.
+Before writing a spec, call \`fn_task_list\` for active work, then call \`fn_task_search\` with \`includeDone: false\` and \`includeArchived: false\` for 2-4 targeted keyword phrases from the title/description, such as file paths, symptoms, and symbols. Do not search completed or archived work for duplicate candidates. When an active match is a duplicate, do not write a spec \u2014 but still write PROMPT.md, with its entire contents being the single line \`DUPLICATE: {existing-task-id}\` and nothing else. That file is how the duplicate is recorded; announcing it only in your reply leaves no plan behind and re-plans the task in a loop.
 
 ## Required PROMPT.md shape
 Write PROMPT.md with Original Description, Before \u2192 After Transformation, Mission, Dependencies, Context to Read First, File Scope, Steps, Documentation Requirements, Completion Criteria, Git Commit Convention, and Do NOT. Put \`## Original Description\` immediately after the title/\`Created\`/\`Size\` metadata with the operator's original task description copied **verbatim** (do not paraphrase). Put \`## Before \u2192 After Transformation\` next, before \`## Mission\`, with concise Before/After bullets: current state, target state, why it satisfies the user's request at a glance. In \`## Steps\`, every executable heading MUST use \`### Step N: <name>\` (e.g. \`### Step 1: Preflight\`). Do not write bare \`### Preflight\` / \`### Implementation\` headings, and do not add review-level, triage subtask, or proactive subtask headings.
@@ -12384,6 +12427,8 @@ If the requested outcome is only to decide, route, or coordinate work, include \
 Write PROMPT.md directly and stop. Do not call \`fn_review_spec()\`; workflow Plan Review is the single optional plan review gate before execution.`;
 var TRIAGE_PROMPT_TEXT = `You are a task specification agent for "fn", an AI-orchestrated task board.
 
+${PLANNING_COMPLETENESS_POLICY}
+
 ## Your Role
 You are the specification quality gate for implementation success.
 Your job: take a rough task description and produce a fully specified PROMPT.md that another AI agent can execute autonomously in a fresh context with zero memory of this conversation.
@@ -12608,9 +12653,9 @@ Verified facts about this codebase's storage \u2014 cite these correctly so Plan
 - New Postgres migrations must be **registered explicitly** in \`packages/core/src/postgres/schema-applier.ts\` (version constant + bookkeeping check); a \`.sql\` file dropped in the migrations dir that is not wired there silently never runs.
 
 ## Duplicate check
-Before writing a spec, first call \`fn_task_list\` to see active tasks, then call \`fn_task_search\` with 2-4 distinct keyword phrases from the task title and description (for example file paths, error symptoms, and symbol names).
-For any likely match in \`done\` or \`archived\`, call \`fn_task_show\` to inspect details before deciding.
-If a task already covers the same work (even if worded differently), do not write a spec.
+Before writing a spec, first call \`fn_task_list\` to see active tasks, then call \`fn_task_search\` with \`includeDone: false\` and \`includeArchived: false\` for 2-4 distinct keyword phrases from the task title and description (for example file paths, error symptoms, and symbol names).
+Do not search completed or archived work for duplicate candidates.
+If an actionable task already covers the same work (even if worded differently), do not write a spec.
 Instead you MUST still write PROMPT.md, with its ENTIRE contents being this one line and nothing else:
 \`DUPLICATE: {existing-task-id}\`
 Writing that file IS how you report the duplicate. Reporting it only in your reply is not recorded:
@@ -12641,7 +12686,7 @@ Workflow policy can disable proactive oversized-task splitting for operators who
 ## Triage tools
 You have these extra tools during triage:
 - \`fn_task_list\` \u2014 list existing active tasks
-- \`fn_task_search\` \u2014 keyword search across tasks, including done and archived tasks
+- \`fn_task_search\` \u2014 keyword search across active tasks by default; history is opt-in for non-duplicate research
 - \`fn_task_show\` \u2014 inspect a task and its PROMPT.md
 - \`fn_task_create\` \u2014 create a child/follow-up task while triaging
 - \`fn_task_document_write\` \u2014 save a planning document (e.g., key="plan")
@@ -12868,20 +12913,6 @@ Concrete examples:
 - [Optional improvements, not blocking]
 \`\`\`
 
-## Spec / Plan Review Convergence
-
-Specs and pre-execution Plan Review share this gate. Prefer **APPROVE** / **APPROVE_WITH_NOTES** when the plan is executable enough for an agent to implement. Put optional polish only under **Suggestions**.
-
-When you must **REVISE**:
-- List each blocking issue as a concrete PROMPT.md edit (which section, what to add/change/remove).
-- Do not demand a full rewrite unless the approach is fundamentally wrong (**RETHINK**).
-- Prefer fixing local PROMPT.md defects in-session when you have write tools, then **APPROVE**, instead of bouncing the task through another full replan cycle.
-
-**Converging on re-review (when the request includes your prior feedback + a Plan Review attempt number):**
-- This is a spec you already reviewed. VERIFY each issue you previously raised was addressed. REVISE only for (a) a PRIOR blocking issue still unresolved, or (b) a genuinely NEW problem THIS revision introduced.
-- Do NOT introduce a new blocking issue that ALSO applied to the version you previously reviewed \u2014 that is your own earlier miss. Record it under **Suggestions**, not REVISE.
-- **Severity ratchet at attempt 3+:** gate ONLY on \`critical\` (delivery-blocking) issues. Downgrade lone \`important\`/\`minor\` spec-wording nits to **Suggestions** and APPROVE. Rationale: the executor and downstream code review are later gates \u2014 a spec need not be perfect to be executable, only executable.
-
 ## Spec Review \u2014 Undersplit Task Detection
 
 When reviewing specs, assess whether the task should have been broken into subtasks. The bar for splitting is high \u2014 most tasks should remain whole. Coordination overhead (worktrees, dependency wiring, merge sequencing) is real, so splitting must clearly pay for itself.
@@ -13529,6 +13560,22 @@ function browserVerificationOptionalGroupNode(column, options = {}) {
   };
 }
 
+// ../core/src/agents/code-review-policy.ts
+var CODE_REVIEW_COMPLETENESS_POLICY = `## Mandatory Code Review Procedure
+
+Apply this procedure to code reviews only. Plan/spec reviews use their dedicated criteria below.
+
+Before choosing a verdict:
+
+1. Build a **requirements ledger** from PROMPT.md. For every Mission outcome, Completion Criterion, relevant \`## Surface Enumeration\` item, and \`## Symptom Verification\` assertion, identify both implementation evidence and test evidence. A missing or partial required row is REVISE.
+2. Trace each changed behavior from its **real production entry point** and selector through the changed helper to its consumers. A helper-only unit test does not prove that production can reach the new branch.
+3. For bug fixes, locate an automated test that reproduces the exact reported failure and asserts it is gone across the enumerated surfaces. Green builds, nearby unit tests, and synthetic state injection alone are insufficient.
+4. For persistence, lifecycle, and concurrency changes, verify that evidence belongs to the **current state, version, or planning episode**; every read-check-write path is atomic, locked, or CAS-protected; all mutation surfaces preserve the invariant; waits and locks are bounded and cleanup-safe; and a production-shaped integration test covers both relevant orderings.
+5. For route or state changes, inspect all affected UI, API, CLI, and agent consumers plus paired success/failure or approve/reject paths for contract parity.
+6. Before APPROVE, perform a fresh adversarial validation pass: try to disprove each completed ledger row by reading the real caller, guard, consumer, and test. Cite \`file:line\` for every blocker and name the exact missing proof.
+
+APPROVE only when every required ledger row has implementation and test evidence.`;
+
 // ../core/src/workflows/builtin-code-review-group.ts
 var CODE_REVIEW_GROUP_ID = "code-review";
 var CODE_REVIEW_STEP_NODE_ID = "code-review-step";
@@ -13548,6 +13595,8 @@ var CODE_REVIEW_PROMPT = `You are a senior code reviewer. Review the task's diff
 5. **Error handling** \u2014 swallowed errors, unhandled rejections/exceptions, missing validation at trust boundaries, misleading error messages.
 6. **Contract / signature changes** \u2014 changed function/exported-type signatures, API request/response shapes, or serialization that breaks existing callers.
 
+${CODE_REVIEW_COMPLETENESS_POLICY}
+
 Be specific: cite \`file:line\` for every finding and explain the concrete failure it causes.
 
 ## Output Requirements
@@ -13667,12 +13716,14 @@ var PLAN_REVIEW_PROMPT = `You are a senior plan reviewer. Review the task's PROM
 4. **Verification quality** \u2014 absent or weak tests/checks for the behavior being changed.
 5. **Risk callouts** \u2014 migrations, data-loss paths, external integrations, secrets, or plugin/runtime dependencies that need explicit handling.
 
+${PLAN_REVIEW_COMPLETENESS_POLICY}
+
 Be specific: cite the plan section or file path for every finding and explain the concrete correction.
 
 ## Output Requirements
 - APPROVE: the plan is ready for execution.
 - APPROVE_WITH_NOTES: execution may proceed, but include non-blocking advisory notes.
-- REVISE: the plan should be corrected before execution; include the missing or wrong requirement and the needed change.
+- REVISE: the plan should be corrected before execution; include every blocking finding and needed change in the JSON notes, not only in preceding prose.
 - Final output: output exactly one trailing JSON object on the final line (no markdown fences, no surrounding prose):
 {"verdict":"APPROVE|APPROVE_WITH_NOTES|REVISE","notes":"..."}`;
 function planReviewOptionalGroupNode(column, options = {}) {

package/dist/plugins/fusion-plugin-roadmap/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fusion-plugin-examples/roadmap",
-  "version": "0.1.52-beta.0",
+  "version": "0.1.52-beta.2",
   "type": "module",
   "exports": {
     ".": {

package/dist/plugins/fusion-plugin-todos/bundled.js

@@ -5759,6 +5759,7 @@ __export(project_exports, {
   tasks: () => tasks,
   todoItems: () => todoItems,
   todoLists: () => todoLists,
+  unplannedExecutionBlocks: () => unplannedExecutionBlocks,
   usageEvents: () => usageEvents,
   verificationCache: () => verificationCache,
   workflowPromptOverrides: () => workflowPromptOverrides,
@@ -5798,6 +5799,7 @@ var tasks = projectSchema.table("tasks", {
   worktree: text("worktree"),
   blockedBy: text("blocked_by"),
   overlapBlockedBy: text("overlap_blocked_by"),
+  queuedLogEpisodeSignature: text("queued_log_episode_signature"),
   paused: integer("paused").default(0),
   userPaused: integer("user_paused").default(0),
   pausedReason: text("paused_reason"),
@@ -6603,6 +6605,14 @@ var workflowWorkItems = projectSchema.table("workflow_work_items", {
   index("idx_workflow_work_items_task_run").on(t.taskId, t.runId),
   uniqueIndex("idx_workflow_work_items_one_active_task_continuation").on(t.projectId, t.taskId).where(sql`${t.kind} = 'task' AND ${t.state} IN ('runnable', 'running', 'held', 'retrying')`)
 ]);
+var unplannedExecutionBlocks = projectSchema.table("unplanned_execution_blocks", {
+  projectId: text("project_id").notNull().default(sql`current_setting('fusion.project_id', true)`),
+  taskId: text("task_id").notNull(),
+  episode: text("episode").notNull(),
+  createdAt: text("created_at").notNull()
+}, (t) => [
+  primaryKey({ columns: [t.projectId, t.taskId, t.episode] })
+]);
 var workflowRunBranches = projectSchema.table("workflow_run_branches", {
   projectId: text("project_id").notNull().default(sql`current_setting('fusion.project_id', true)`),
   taskId: text("task_id").notNull(),
@@ -12128,6 +12138,37 @@ var TRIAGE_POLICY_DEFAULTS = new Map(
   BUILTIN_TRIAGE_POLICY_SETTINGS.map((setting) => [setting.id, setting.default])
 );
 
+// ../core/src/agents/planning-review-policy.ts
+var PLANNING_COMPLETENESS_POLICY = `## Mandatory Planning Completeness Procedure
+
+Before writing the final PROMPT.md:
+
+1. Build an internal **planning ledger** from the Original Description, user comments, project instructions, cited issue/report, and any saved planning document. Preserve every requirement, settled decision, explicit non-goal, and acceptance outcome; do not silently replace the reporter's contract with a narrower reproduction.
+2. Research before structuring the plan. Trace the affected behavior through its real production entry points, callers, writers/readers, shared consumers, persistence boundaries, recovery paths, and existing tests. Resolve planning-time facts from the repository now; defer only details that genuinely require implementation-time discovery, and label those explicitly.
+3. For stateful, lifecycle, persistence, or concurrency work, enumerate the participant graph and both relevant orderings: stale-work cancellation/fencing, lock order and reentrancy, transaction boundaries, pool/transport limits, competing recovery paths, configuration/deployment identities, bypass/force paths, and failure cleanup. Every stated invariant must name the surfaces that preserve it.
+4. Map every ledger row to concrete File Scope entries, dependency-ordered implementation steps, and verification. Each feature-bearing step must name specific automated test scenarios with the input/state, action or ordering, and expected observable result; helper-only tests do not prove production reachability.
+5. Keep scope disciplined. Reuse current architecture and documented patterns unless the reporter contract requires a redesign. Put optional cleanup and adjacent ideas outside the active steps.
+6. Before persisting PROMPT.md, perform a fresh holistic completeness pass across the whole ledger. Try to disprove the plan by checking referenced paths and patterns, missing consumers, contradictory steps, uncovered failure orderings, and acceptance criteria without tests. Fix all gaps in one pass.
+
+On a revision, treat the cumulative revision ledger as durable decisions unless a later entry explicitly supersedes one: preserve resolved items, address every unresolved item surgically, and rerun the complete procedure instead of checking only the latest comment.`;
+var FAST_PLANNING_COMPLETENESS_POLICY = `## Fast Planning Completeness Check
+
+Before writing PROMPT.md, build a compact internal ledger from the Original Description, user comments, project rules, and acceptance outcomes. Inspect the real production callers/consumers, persistence or recovery paths, and nearby tests before choosing File Scope. For stateful or concurrent work, enumerate every participant plus both relevant orderings and failure cleanup. Map each requirement to a concrete step, file, and automated test scenario, then reread the whole plan once for missing surfaces, contradictions, and unproved outcomes. On revision, preserve prior decisions and address the complete cumulative ledger, not only the latest note.`;
+var PLAN_REVIEW_COMPLETENESS_POLICY = `## Mandatory Plan Review Procedure
+
+Apply this procedure to plan/spec reviews only. Code reviews use their dedicated procedure.
+
+Before choosing a verdict:
+
+1. Build one **review ledger** for the entire PROMPT.md: Original Description and user comments; Mission and Completion Criteria; Surface Enumeration and Symptom Verification when required; every implementation step, File Scope entry, dependency, risk, and test/verification promise.
+2. Complete the full review before reporting. Check coherence and requirement traceability, feasibility against the current repository, scope discipline, execution ordering, and verification quality. When relevant, also inspect security/data integrity, state transitions, concurrency orderings, deployment/configuration boundaries, recovery competitors, and force/bypass paths.
+3. Review at specification altitude. Block when a required behavior, surface, ordering, safety constraint, or proof is missing or the stated approach cannot work. Keep optional implementation detail, wording polish, and nonessential improvements advisory.
+4. If REVISE is necessary, batch **all independently discoverable blocking findings** into this one verdict; do not stop after the first defect. Give each blocker a stable ID, cite the affected section or repository evidence, and state the concrete PROMPT.md correction. Put advisory observations in a separate list.
+5. On re-review, use the supplied prior-review ledger as a decision primer. Verify every prior blocker, do not re-raise resolved or rejected semantic duplicates, and preserve accepted decisions. A newly blocking finding must say whether the revision introduced it, which prior blocker genuinely masked it, or why it is independently delivery-blocking for correctness, security, data safety, or executability. Record an earlier reviewer miss explicitly; never demote a critical defect merely because it was missed before.
+6. After any same-session PROMPT.md edit, distrust the edit: reread the complete artifact, rebuild the ledger, and perform a fresh holistic pass before APPROVE.
+
+APPROVE when the plan is executable and verifiable, not when it is cosmetically perfect. If returning REVISE, the verdict notes must contain the complete blocking checklist because those notes are the durable input to the next planning round.`;
+
 // ../core/src/agents/agent-prompts.ts
 var FUSION_RUNTIME_SELF_AWARENESS = `## Runtime Self-Awareness
 
@@ -12334,6 +12375,8 @@ The tool prevents your session from being killed by the inactivity watchdog duri
 - If a verification command times out, do NOT blindly retry \u2014 investigate. Check for hung subprocesses, infinite test loops, or tests waiting on missing dependencies. Use \`node_modules/.modules.yaml\` presence to confirm bootstrap.`;
 var FAST_TRIAGE_PROMPT_TEXT = `You are a task specification agent for "fn". This task is running in **fast mode**.
 
+${FAST_PLANNING_COMPLETENESS_POLICY}
+
 Write a lean, executable PROMPT.md quickly. Preserve safety gates, but skip heavyweight ceremony, review scoring, and proactive subtask analysis.
 
 ## Fast-mode priorities
@@ -12342,7 +12385,7 @@ Write a lean, executable PROMPT.md quickly. Preserve safety gates, but skip heav
 - Preserve required safety sections for bugs, workflow routing, forensic tasks, and decision-only work.
 
 ## Duplicate check
-Before writing a spec, call \`fn_task_list\` for active work, then call \`fn_task_search\` with 2-4 targeted keyword phrases from the title/description, such as file paths, symptoms, and symbols. For any likely match in \`done\` or \`archived\`, call \`fn_task_show\` and inspect it before deciding. If an existing task covers the same work, do not write a spec \u2014 but still write PROMPT.md, with its entire contents being the single line \`DUPLICATE: {existing-task-id}\` and nothing else. That file is how the duplicate is recorded; announcing it only in your reply leaves no plan behind and re-plans the task in a loop.
+Before writing a spec, call \`fn_task_list\` for active work, then call \`fn_task_search\` with \`includeDone: false\` and \`includeArchived: false\` for 2-4 targeted keyword phrases from the title/description, such as file paths, symptoms, and symbols. Do not search completed or archived work for duplicate candidates. When an active match is a duplicate, do not write a spec \u2014 but still write PROMPT.md, with its entire contents being the single line \`DUPLICATE: {existing-task-id}\` and nothing else. That file is how the duplicate is recorded; announcing it only in your reply leaves no plan behind and re-plans the task in a loop.
 
 ## Required PROMPT.md shape
 Write PROMPT.md with Original Description, Before \u2192 After Transformation, Mission, Dependencies, Context to Read First, File Scope, Steps, Documentation Requirements, Completion Criteria, Git Commit Convention, and Do NOT. Put \`## Original Description\` immediately after the title/\`Created\`/\`Size\` metadata with the operator's original task description copied **verbatim** (do not paraphrase). Put \`## Before \u2192 After Transformation\` next, before \`## Mission\`, with concise Before/After bullets: current state, target state, why it satisfies the user's request at a glance. In \`## Steps\`, every executable heading MUST use \`### Step N: <name>\` (e.g. \`### Step 1: Preflight\`). Do not write bare \`### Preflight\` / \`### Implementation\` headings, and do not add review-level, triage subtask, or proactive subtask headings.
@@ -12384,6 +12427,8 @@ If the requested outcome is only to decide, route, or coordinate work, include \
 Write PROMPT.md directly and stop. Do not call \`fn_review_spec()\`; workflow Plan Review is the single optional plan review gate before execution.`;
 var TRIAGE_PROMPT_TEXT = `You are a task specification agent for "fn", an AI-orchestrated task board.
 
+${PLANNING_COMPLETENESS_POLICY}
+
 ## Your Role
 You are the specification quality gate for implementation success.
 Your job: take a rough task description and produce a fully specified PROMPT.md that another AI agent can execute autonomously in a fresh context with zero memory of this conversation.
@@ -12608,9 +12653,9 @@ Verified facts about this codebase's storage \u2014 cite these correctly so Plan
 - New Postgres migrations must be **registered explicitly** in \`packages/core/src/postgres/schema-applier.ts\` (version constant + bookkeeping check); a \`.sql\` file dropped in the migrations dir that is not wired there silently never runs.
 
 ## Duplicate check
-Before writing a spec, first call \`fn_task_list\` to see active tasks, then call \`fn_task_search\` with 2-4 distinct keyword phrases from the task title and description (for example file paths, error symptoms, and symbol names).
-For any likely match in \`done\` or \`archived\`, call \`fn_task_show\` to inspect details before deciding.
-If a task already covers the same work (even if worded differently), do not write a spec.
+Before writing a spec, first call \`fn_task_list\` to see active tasks, then call \`fn_task_search\` with \`includeDone: false\` and \`includeArchived: false\` for 2-4 distinct keyword phrases from the task title and description (for example file paths, error symptoms, and symbol names).
+Do not search completed or archived work for duplicate candidates.
+If an actionable task already covers the same work (even if worded differently), do not write a spec.
 Instead you MUST still write PROMPT.md, with its ENTIRE contents being this one line and nothing else:
 \`DUPLICATE: {existing-task-id}\`
 Writing that file IS how you report the duplicate. Reporting it only in your reply is not recorded:
@@ -12641,7 +12686,7 @@ Workflow policy can disable proactive oversized-task splitting for operators who
 ## Triage tools
 You have these extra tools during triage:
 - \`fn_task_list\` \u2014 list existing active tasks
-- \`fn_task_search\` \u2014 keyword search across tasks, including done and archived tasks
+- \`fn_task_search\` \u2014 keyword search across active tasks by default; history is opt-in for non-duplicate research
 - \`fn_task_show\` \u2014 inspect a task and its PROMPT.md
 - \`fn_task_create\` \u2014 create a child/follow-up task while triaging
 - \`fn_task_document_write\` \u2014 save a planning document (e.g., key="plan")
@@ -12868,20 +12913,6 @@ Concrete examples:
 - [Optional improvements, not blocking]
 \`\`\`
 
-## Spec / Plan Review Convergence
-
-Specs and pre-execution Plan Review share this gate. Prefer **APPROVE** / **APPROVE_WITH_NOTES** when the plan is executable enough for an agent to implement. Put optional polish only under **Suggestions**.
-
-When you must **REVISE**:
-- List each blocking issue as a concrete PROMPT.md edit (which section, what to add/change/remove).
-- Do not demand a full rewrite unless the approach is fundamentally wrong (**RETHINK**).
-- Prefer fixing local PROMPT.md defects in-session when you have write tools, then **APPROVE**, instead of bouncing the task through another full replan cycle.
-
-**Converging on re-review (when the request includes your prior feedback + a Plan Review attempt number):**
-- This is a spec you already reviewed. VERIFY each issue you previously raised was addressed. REVISE only for (a) a PRIOR blocking issue still unresolved, or (b) a genuinely NEW problem THIS revision introduced.
-- Do NOT introduce a new blocking issue that ALSO applied to the version you previously reviewed \u2014 that is your own earlier miss. Record it under **Suggestions**, not REVISE.
-- **Severity ratchet at attempt 3+:** gate ONLY on \`critical\` (delivery-blocking) issues. Downgrade lone \`important\`/\`minor\` spec-wording nits to **Suggestions** and APPROVE. Rationale: the executor and downstream code review are later gates \u2014 a spec need not be perfect to be executable, only executable.
-
 ## Spec Review \u2014 Undersplit Task Detection
 
 When reviewing specs, assess whether the task should have been broken into subtasks. The bar for splitting is high \u2014 most tasks should remain whole. Coordination overhead (worktrees, dependency wiring, merge sequencing) is real, so splitting must clearly pay for itself.
@@ -13529,6 +13560,22 @@ function browserVerificationOptionalGroupNode(column, options = {}) {
   };
 }
 
+// ../core/src/agents/code-review-policy.ts
+var CODE_REVIEW_COMPLETENESS_POLICY = `## Mandatory Code Review Procedure
+
+Apply this procedure to code reviews only. Plan/spec reviews use their dedicated criteria below.
+
+Before choosing a verdict:
+
+1. Build a **requirements ledger** from PROMPT.md. For every Mission outcome, Completion Criterion, relevant \`## Surface Enumeration\` item, and \`## Symptom Verification\` assertion, identify both implementation evidence and test evidence. A missing or partial required row is REVISE.
+2. Trace each changed behavior from its **real production entry point** and selector through the changed helper to its consumers. A helper-only unit test does not prove that production can reach the new branch.
+3. For bug fixes, locate an automated test that reproduces the exact reported failure and asserts it is gone across the enumerated surfaces. Green builds, nearby unit tests, and synthetic state injection alone are insufficient.
+4. For persistence, lifecycle, and concurrency changes, verify that evidence belongs to the **current state, version, or planning episode**; every read-check-write path is atomic, locked, or CAS-protected; all mutation surfaces preserve the invariant; waits and locks are bounded and cleanup-safe; and a production-shaped integration test covers both relevant orderings.
+5. For route or state changes, inspect all affected UI, API, CLI, and agent consumers plus paired success/failure or approve/reject paths for contract parity.
+6. Before APPROVE, perform a fresh adversarial validation pass: try to disprove each completed ledger row by reading the real caller, guard, consumer, and test. Cite \`file:line\` for every blocker and name the exact missing proof.
+
+APPROVE only when every required ledger row has implementation and test evidence.`;
+
 // ../core/src/workflows/builtin-code-review-group.ts
 var CODE_REVIEW_GROUP_ID = "code-review";
 var CODE_REVIEW_STEP_NODE_ID = "code-review-step";
@@ -13548,6 +13595,8 @@ var CODE_REVIEW_PROMPT = `You are a senior code reviewer. Review the task's diff
 5. **Error handling** \u2014 swallowed errors, unhandled rejections/exceptions, missing validation at trust boundaries, misleading error messages.
 6. **Contract / signature changes** \u2014 changed function/exported-type signatures, API request/response shapes, or serialization that breaks existing callers.
 
+${CODE_REVIEW_COMPLETENESS_POLICY}
+
 Be specific: cite \`file:line\` for every finding and explain the concrete failure it causes.
 
 ## Output Requirements
@@ -13667,12 +13716,14 @@ var PLAN_REVIEW_PROMPT = `You are a senior plan reviewer. Review the task's PROM
 4. **Verification quality** \u2014 absent or weak tests/checks for the behavior being changed.
 5. **Risk callouts** \u2014 migrations, data-loss paths, external integrations, secrets, or plugin/runtime dependencies that need explicit handling.
 
+${PLAN_REVIEW_COMPLETENESS_POLICY}
+
 Be specific: cite the plan section or file path for every finding and explain the concrete correction.
 
 ## Output Requirements
 - APPROVE: the plan is ready for execution.
 - APPROVE_WITH_NOTES: execution may proceed, but include non-blocking advisory notes.
-- REVISE: the plan should be corrected before execution; include the missing or wrong requirement and the needed change.
+- REVISE: the plan should be corrected before execution; include every blocking finding and needed change in the JSON notes, not only in preceding prose.
 - Final output: output exactly one trailing JSON object on the final line (no markdown fences, no surrounding prose):
 {"verdict":"APPROVE|APPROVE_WITH_NOTES|REVISE","notes":"..."}`;
 function planReviewOptionalGroupNode(column, options = {}) {

package/dist/plugins/fusion-plugin-todos/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fusion-plugin-examples/todos",
-  "version": "0.1.1-beta.0",
+  "version": "0.1.1-beta.2",
   "type": "module",
   "exports": {
     ".": {