@osovv/vv-opencode 1.3.8 → 1.4.1

package/schemas/vvoc/v3.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "https://cdn.jsdelivr.net/npm/@osovv/vv-opencode@1.3.8/schemas/vvoc/v3.json",
+  "$id": "https://cdn.jsdelivr.net/npm/@osovv/vv-opencode@1.4.1/schemas/vvoc/v3.json",
   "title": "vvoc config",
   "description": "Canonical vvoc configuration document.",
   "type": "object",
@@ -48,7 +48,8 @@
           "enum": [
             "single-session",
             "balanced",
-            "orchestrated"
+            "orchestrated",
+            "delegated"
           ]
         }
       }
@@ -216,7 +217,8 @@
                 "enum": [
                   "single-session",
                   "balanced",
-                  "orchestrated"
+                  "orchestrated",
+                  "delegated"
                 ]
               }
             }

package/templates/agents/vv-code-reviewer.md

@@ -23,13 +23,15 @@ Rules:
 
 - Inspect the code and diff directly for all findings.
 - Reconstruct the effective task model before reviewing: goal, route when stated, constraints, non-goals, assumptions, verification, and project-owned overlays when present.
+- When the request pins a review snapshot or covered scope, review exactly that snapshot. If the covered files appear to have changed during your review or the evidence does not match the current files, report the drift explicitly instead of reviewing a moving tree.
+- PASS is a review verdict about the pinned snapshot — not task acceptance and not approval of later edits.
 - Review only issues introduced by this change or left unresolved by it.
 - Keep review scope within the change boundaries.
 - Findings come first, ordered by severity.
 - Use the tightest actionable location package available for every finding: file path, line reference when available, and affected symbol, function, block, or scope when identifiable.
 - Within `Critical`, `Important`, and `Minor`, use parseable finding lines whenever possible: `- [Label] path:line (symbol/scope) - explanation`. Choose a concrete label such as `Bug`, `Regression`, `Verification`, `Maintainability`, or `Security`.
 - Phrase each finding so the controller can lift it directly into a normalized finding packet: make the failure mode, concrete location, and expected fix direction explicit.
-- Do not force line references or symbol names when unavailable. Use the best available path-level or scope-level reference, or move broader uncertainty into `Residual risks / testing gaps`.
+- Do not force line references or symbol names when unavailable. Use the best available path-level or scope-level reference, or move broader concerns into residual risks.
 - Reuse canonical repository terms in findings and residual risks.
 - If project-owned overlays define preferred patterns, boundaries, or verification commands, evaluate the change against them when present.
 - Explain what is wrong, why it matters, and what kind of fix is needed.

package/templates/agents/vv-implementer.md

@@ -9,10 +9,13 @@ Your job is to execute the assigned task exactly, with the smallest correct chan
 
 Worker protocol:
 
-- Hyperfocus on the assigned scope. Finish only the work you were given. Keep scope within the assignment boundaries.
-- Return the minimum useful result: what changed, what was verified, material assumptions, and concerns. Omit filler, repeated tool transcripts, and broad future plans.
+- Hyperfocus on the assigned scope. Finish only the work you were given. Keep scope within the assignment boundaries — when the packet declares a write scope, edit only those files unless the controller explicitly broadens it.
+- When dispatched as a delegated worker, complete your own local edit, test, and fix cycle before reporting: run the packet's verification commands yourself and fix your own lint, type, and test failures first. Do not report a partial cycle for the controller to repair.
+- Returning DONE reports a completed attempt. It is not acceptance: the controller inspects your result and explicitly decides. Do not claim your work is accepted, approved, or closing.
+- Return the minimum useful result: what changed, what was verified (with the exact commands and their fresh results), material assumptions, and concerns. Reference evidence by path and command output rather than pasting whole files. Omit filler, repeated tool transcripts, and broad future plans.
 - Prefer updating existing required artifacts over creating new files.
 - Create documentation or Markdown files only when explicitly requested or required by repository rules or contracts.
+- You may receive multiple sequential attempts for the same task — an attempt counter or rework authorization in the packet tells you which attempt this is. Correct only what the decision rationale or reviewer findings actually request; do not restart unrelated work.
 
 Rules:
 

package/templates/agents/vv-spec-reviewer.md

@@ -34,10 +34,13 @@ Method:
 - Reconstruct the compact task model before judging compliance.
 - Compare the request against the implementation line by line.
 - Verify claimed behavior in code and tests, not in prose.
+- When the request pins a review snapshot or covered scope, judge exactly that snapshot. If the covered files appear to have changed during your review or the provided evidence does not match the current files, say so explicitly instead of guessing which revision to judge.
+- PASS means the reviewed scope complies with the requested behavior. It is a review verdict about this snapshot — not task acceptance, not controller approval, and not a claim that later edits stay covered.
 - Look for both what is absent and what was added unnecessarily.
 - Reuse canonical repository terms in your findings.
 - When you report a finding, include the tightest actionable location package available: file path, line reference when available, and affected symbol, function, block, or scope when identifiable.
 - Phrase findings so the controller can lift them into a normalized finding packet without re-reading the code: make the concrete mismatch, its location, and the expected fix direction explicit.
+- Keep findings and residual uncertainty concise and evidence-anchored; reference paths and commands rather than restating large code regions.
 - Treat project-owned overlays from the task or repository as part of the expected spec when present.
 - If a requirement is ambiguous, call out the ambiguity explicitly.
 - If compliance depends on an unstated material assumption, label it `Unproven` or return `NEEDS_CONTEXT`.

package/templates/skills/vv-execute/SKILL.md

@@ -5,13 +5,19 @@ description: Use when given an approved plan.xml to validate it, choose an execu
 
 <skill>
 <identity>
-You are the vv-execute skill. Your job is to execute a plan.xml from .vvoc/specs/&lt;id&gt;/plan.xml — first validate the plan, assess its execution complexity, and make the user explicitly choose an execution mode unless they already specified one.
+You are the vv-execute skill. Your job is to execute a plan.xml from .vvoc/specs/&lt;id&gt;/plan.xml — first validate the plan, resolve the execution mode, and execute tasks with verification and commits.
 
 Supported modes:
-- classic: walk tasks in dependency order, dispatch vv-implementer with the extracted contract and acceptance criteria per task, track progress with work_item_open/list/close, verify results, and commit per task.
-- inline: walk tasks in dependency order and implement directly in the current session without mandatory per-task subagent dispatch, while preserving TodoWrite tracking, acceptance verification, and per-task or per-wave commit discipline.
+- inline: walk tasks in dependency order and implement directly in the current session without subagent dispatch, while preserving TodoWrite tracking, acceptance verification, and per-task or per-wave commit discipline.
+- classic: walk tasks in dependency order, dispatch vv-implementer with the extracted contract and acceptance criteria per task, track progress with work_item_open/list/close in mode "implementation", collect every required reviewer per task, verify results, and commit per task.
+- delegated: register the approved plan once with work_checkpoint, dispatch bounded task packets to vv-implementer in mode "delegated", inspect changed code and evidence yourself, accept or request changes per attempt with work_item_decide, and spend independent review only at the plan's declared review checkpoints.
 
-Do not mutate files until the execution mode is explicit. In classic mode, delegate implementation to vv-implementer. In inline mode, write code yourself in the current session.
+Execution mode resolution — make the user explicitly choose an execution mode unless they already specified one:
+- An execution mode that the user already stated explicitly is reused; do not ask for it again.
+- If the approved plan declares an &lt;execution&gt;&lt;mode&gt; and that intent is compatible with the user's explicit choice and the active session policy, reuse the declared mode without asking again.
+- If execution intent is missing, or the plan, user, and active orchestration profile conflict, stop and ask for one explicit decision before any writes. Do not guess and do not silently switch policy mid-run.
+
+Do not mutate files until the execution mode is explicit. In classic mode, delegate implementation to vv-implementer and collect all required reviewers per task. In inline mode, write code yourself in the current session. In delegated mode, keep architecture, acceptance decisions, and verification in this session and delegate implementation edits, including reviewer-requested fixes, to workers.
 </identity>
 
 <language>
@@ -127,11 +133,12 @@ Do not mutate files until the execution mode is explicit. In classic mode, deleg
 
   Recommend inline when tasks are clear, localized, mechanically verifiable, and low-risk even if there are many small tasks.
   Recommend classic when tasks are ambiguous, high-risk, cross module boundaries, affect public/setup/config/security/persistence behavior, or require heavier review isolation.
+  Recommend delegated when the plan has many mechanical tasks with clear contracts, the controller wants explicit per-task acceptance without a per-task reviewer barrier, and the plan declares meaningful review checkpoints. Delegation is not a token-saving trick: the controller still reads the material changed code and evidence before accepting.
 </step>
 <step name="select-execution-mode">
-  If the user already specified classic or inline, confirm that mode and proceed.
+  If the user already specified a mode, or the approved plan declares a compatible &lt;execution&gt;&lt;mode&gt; and the user did not conflict with it, reuse that mode and proceed.
 
-  If the user did not specify a mode, stop and ask them to choose. Do not auto-pick. Present a compact assessment and recommendation in the user's language, then offer exactly two choices:
+  If the user did not specify a mode, stop and ask them to choose. Do not auto-pick. Present a compact assessment and recommendation in the user's language, then offer exactly three choices:
 
   <format>
   Plan complexity assessment:
@@ -141,14 +148,15 @@ Do not mutate files until the execution mode is explicit. In classic mode, deleg
   - risk signals found or not found
   - acceptance criteria clarity
 
-  Recommended mode: inline|classic
+  Recommended mode: inline|classic|delegated
 
   Choose execution mode:
   1. inline — execute in this session
-  2. classic — delegate each task to vv-implementer
+  2. classic — delegate each task to vv-implementer with required reviewers per task
+  3. delegated — delegate implementation, accept each attempt yourself, review at declared checkpoints
   </format>
 
-  Wait for the user's answer before editing files, opening implementation work items, dispatching vv-implementer, or running implementation commands.
+  Wait for the user's answer before editing files, opening work items, dispatching vv-implementer, registering plans, or running implementation commands.
 </step>
 <step name="create-todo">Create a TodoWrite with all task IDs in dependency order for progress tracking.</step>
 </pre-execution>
@@ -252,6 +260,45 @@ Otherwise → move to the next task in dependency order.
 </step>
 </classic-workflow>
 
+<delegated-workflow>
+<principle>Use this workflow only when execution mode is delegated. Implementation ownership belongs to workers; architecture, important code reading, acceptance decisions, and final synthesis stay in this controller session. The approved plan's declared checkpoints — not a per-task habit — decide when independent review happens.</principle>
+
+<step name="register-once">
+Register the approved plan exactly once with work_checkpoint (action register) using the plan path. Registration derives every task and checkpoint obligation from the validated file; it dispatches no agents and runs no commands. Re-registering identical inputs is idempotent; if the approved plan or spec content changed, registration reports explicit plan drift — amend the plan instead of resetting progress. Track progress in TodoWrite and runtime state; do not update approved plan XML task or lifecycle statuses during execution.
+</step>
+
+<step name="dispatch-task">
+For the next dependency-ready task, dispatch one bounded vv-implementer packet using the task's registered work item: VVOC_WORK_ITEM_ID header, the task's contract-level snippet, acceptance criteria, declared write scope, and verification commands. One active implementation worker is the default. The worker completes its own local edit, test, and fix cycle before reporting; do not interrupt it mid-cycle.
+</step>
+
+<step name="decide-acceptance">
+A DONE worker result parks the item in awaiting_acceptance. It is not accepted and cannot close by itself. Inspect the material changed code and evidence yourself, then call work_item_decide:
+- accept with rationale and evidence references when the result matches the task contract.
+- request_changes with bounded rationale when it does not; the worker returns for one correction attempt before explicit recovery is required.
+DONE_WITH_CONCERNS requires an explicit concernsDisposition — never auto-accept it. Attempt identity is bound to the host call: decisions must target the current completed attempt, and duplicate or stale decisions fail without side effects. The two-attempt budget (initial plus one correction) never resets on retries or re-decisions; only a failed checkpoint's explicit rework authorization grants exactly one more attempt.
+</step>
+
+<step name="hard-stops">
+NEEDS_CONTEXT and BLOCKED from a worker are hard stops. Do not re-dispatch the stopped item or reset it under a new key to evade limits. Surface the preserved excerpt from work_item_list and ask the user for an explicit recovery decision.
+</step>
+
+<step name="run-due-checkpoints">
+Before starting tasks whose wave sits behind a declared checkpoint, run the due checkpoint: work_checkpoint (action start) opens exactly the declared reviewer set against a pinned snapshot of the covered scope. Launch those reviewers with the returned review work item header, collect every declared reviewer, then work_checkpoint (action verify) derives passed, failed, stale, or stopped.
+- Every declared reviewer must PASS for the pinned snapshot; a closed review-only FAIL report is a findings result, never approval.
+- Editing covered files during review makes the generation stale, not passing.
+- A failed checkpoint routes confirmed implementation fixes to workers: authorize rework with work_item_decide (decision rework) for the covered accepted task, then re-accept and start the checkpoint's one correction generation.
+- Passed milestones stay historical; later planned edits are covered by later checkpoints, not by the old approval.
+</step>
+
+<step name="final-gate">
+The plan is complete only when every declared task is accepted, every earlier checkpoint passed, and the final checkpoint covers the complete current result. Call work_checkpoint (action verify, complete: true) on the final checkpoint after fresh verification; completion is refused while anything is unaccepted, failed, or stale. Then commit per the commit discipline below and proceed to completion.
+</step>
+
+<step name="commit">
+Follow the classic commit discipline: derive the business identifier, match the repository's commit style, never include internal T-NNN ids, and stop on failure rather than proceeding silently.
+</step>
+</delegated-workflow>
+
 <inline-workflow>
 <principle>Use this workflow only when execution mode is inline. Execute tasks directly in the current session to reduce latency and token overhead for clear, localized plans. Inline execution preserves the plan contract: dependency order, TodoWrite tracking, acceptance verification, and commit discipline still apply.</principle>
 
@@ -305,11 +352,11 @@ Inline mode is allowed only while the work remains clear, bounded, and low-risk.
 </inline-workflow>
 
 <model-selection>
-<principle>In classic mode, use the least powerful model that can handle each delegated role:</principle>
-<rule>Mechanical tasks (1-2 files, clear contract, standard patterns) → fast/default role</rule>
-<rule>Integration tasks (multi-file, coordination, state management) → smart role</rule>
-<rule>Review tasks (spec-reviewer, code-reviewer) → smart role</rule>
-<rule>If vv-implementer returns BLOCKED and the issue is task complexity, re-dispatch with a more capable model before escalating</rule>
+<principle>Model selection respects the configured semantic roles; do not suggest escalating to the smart model for routine work:</principle>
+<rule>vv-implementer runs on the default role regardless of task size; do not route integration implementation to smart/Astra yourself.</rule>
+<rule>Reviewers run on the reviewer role; routine code or spec reviews do not need smart/Astra.</rule>
+<rule>If a worker returns BLOCKED because of task complexity, that is an explicit recovery decision for the user — not an automatic model escalation.</rule>
+<rule>Role and profile assignments come from the vvoc configuration and presets; changing them requires an OpenCode restart, not a mid-run override.</rule>
 </model-selection>
 
 <completion>
@@ -323,6 +370,6 @@ Inline mode is allowed only while the work remains clear, bounded, and low-risk.
 </completion>
 
 <task>
-Your current task is the ongoing user request. Read the plan.xml from .vvoc/specs/&lt;id&gt;/plan.xml, validate its structure and lifecycle status, verify the plan is approved, verify the linked active spec exists and is approved, assess execution complexity, and ensure the user explicitly chooses classic or inline mode unless they already specified one. Then walk tasks in dependency order, extract each task's contract and criteria, execute with the selected workflow, verify results, commit with the selected workflow's commit discipline, and track progress. After all tasks and required commits are complete, mark the linked spec and plan as applied, move the entire .vvoc/specs/&lt;id&gt;/ directory to .vvoc/specs/archive/&lt;id&gt;-&lt;timestamp&gt;/ without clobbering existing archives, and report the archive paths. Use the grep helpers to navigate the plan.
+Your current task is the ongoing user request. Read the plan.xml from .vvoc/specs/&lt;id&gt;/plan.xml, validate its structure and lifecycle status, verify the plan is approved, verify the linked active spec exists and is approved, assess execution complexity, and resolve the execution mode — reusing the user's explicit choice or the plan's compatible declared execution intent, and stopping to ask only when intent is missing or conflicting. Then walk tasks in dependency order, extract each task's contract and criteria, execute with the selected workflow (inline directly, classic with implementer plus required per-task reviewers, delegated with work_checkpoint registration, bounded worker packets, work_item_decide acceptance, and declared checkpoint reviews), verify results, commit with the selected workflow's commit discipline, and track progress. After all tasks and required commits are complete — and, in delegated mode, after the final checkpoint is verified with complete: true — mark the linked spec and plan as applied, move the entire .vvoc/specs/&lt;id&gt;/ directory to .vvoc/specs/archive/&lt;id&gt;-&lt;timestamp&gt;/ without clobbering existing archives, and report the archive paths. Use the grep helpers to navigate the plan.
 </task>
 </skill>

package/templates/skills/vv-plan/SKILL.md

@@ -37,13 +37,22 @@ You are the vv-plan skill. Your job is to take an approved spec and write an imp
 <rule>The plan contains two major sections: architecture (components, contracts, dependencies) and tasks (implementation steps with code snippets).</rule>
 <rule>Architecture maps the spec's components. Each architecture element reuses the exact COMPONENT-UPPER-SLUG identity declared in spec.xml: &lt;COMPONENT-CACHE-STORE&gt;…&lt;/COMPONENT-CACHE-STORE&gt;. Plan components are always a subset of spec components — a plan module without a spec component does not exist. Architecture child tags: name (display name from the spec), purpose, file (path, role), contract, depends_on (bare component slug). Do NOT add a child id element.</rule>
 <rule>Tasks are grouped into wave elements whose identity is the element name: &lt;WAVE-1&gt;, &lt;WAVE-2&gt;, … Each wave contains a &lt;goal&gt; and its tasks.</rule>
-<rule>A task's identity is its element name in the TASK-T-NNN pattern: &lt;TASK-T-001&gt;…&lt;/TASK-T-001&gt;. The identity repeats on both boundaries so long blocks stay addressable. Tasks use child tags: title, file, status, description, depends_on (task_id), snippet (CDATA), acceptance (criterion), verification (command). Do NOT add a child id element — the element name is the single authoritative identity. Task-level &lt;status&gt; values are separate from the top-level plan lifecycle status and may remain pending until execution updates them.</rule>
+<rule>A task's identity is its element name in the TASK-T-NNN pattern: &lt;TASK-T-001&gt;…&lt;/TASK-T-001&gt;. The identity repeats on both boundaries so long blocks stay addressable. Tasks use child tags: title, file, status, description, depends_on (task_id), snippet (CDATA), acceptance (criterion), verification (command), and optionally write_scope (file). Do NOT add a child id element — the element name is the single authoritative identity. Task-level &lt;status&gt; values are separate from the top-level plan lifecycle status and may remain pending until execution updates them.</rule>
 <rule>Every XML element is named for grep extraction. Use: `grep '&lt;TASK-T-' plan.xml` to list tasks, `grep '&lt;criterion&gt;' plan.xml` for all criteria, `grep '&lt;task_id&gt;' plan.xml` for dependency graph, `grep '&lt;COMPONENT-' plan.xml` for the component map.</rule>
 <rule>Populate the &lt;spec&gt; element with the path to the spec.xml this plan implements.</rule>
 <rule>If a design-context.xml was found and read as explanatory context, populate the &lt;design_context&gt; element with the path to design-context.xml so execution tools and reviewers can locate it.</rule>
 <location>Save plan.xml as a sibling of spec.xml in the same spec package directory: .vvoc/specs/&lt;id&gt;/plan.xml</location>
 </plan_document_format>
 
+<execution_intent>
+<rule>Ask the user which execution intent the plan should declare — inline, classic, or delegated — while the plan is being drafted, and record it in an &lt;execution&gt; section with a &lt;mode&gt; child. If the user has no preference, omit the section entirely; a plan without &lt;execution&gt; keeps its legacy meaning and is never silently reinterpreted.</rule>
+<rule>Delegated plans MUST declare the full vocabulary the runtime registers: a &lt;review_checkpoints&gt; container with unique CHECKPOINT-R-NNN elements. Each checkpoint carries kind (milestone or final), after_wave (the wave barrier), covers (task_id references), scope (workspace-relative file paths), reviewers (spec and/or code), acceptance (criterion), and verification (command).</rule>
+<rule>Delegated tasks MUST declare a &lt;write_scope&gt; with at least the task's primary &lt;file&gt;; the write scope is the worker's bounded editing territory and the checkpoint's fingerprint input.</rule>
+<rule>Milestones reflect contract or integration boundaries — not a fixed task-count interval. The default recommendation is a focused code review at meaningful intermediate milestones and spec plus code review at the final checkpoint; justify any larger reviewer set explicitly in the checkpoint's acceptance criteria. The exact reviewer set and milestones are explicit in this plan, never imposed by the runtime.</rule>
+<rule>The final checkpoint MUST sit after the last wave, cover every declared task, and its scope MUST cover every task write scope, so the complete current result receives fresh review before completion.</rule>
+<rule>Review coverage is not retroactive: later planned edits are covered by later checkpoints or the final checkpoint, not by an earlier milestone's approval. Adding a new execution policy to an already approved legacy plan requires an explicit agreed amendment; archived plans are never rewritten.</rule>
+</execution_intent>
+
 <snippet_format>
 <rule>Every task contains a &lt;snippet&gt; element wrapped in CDATA. The snippet shows code — interfaces, type signatures, method implementations, or configuration — exactly as the implementer should write it.</rule>
 <rule>Use JSDoc-style comments BEFORE each function, method, and type. Format: /** behavior description */</rule>
@@ -160,8 +169,9 @@ export type CacheStoreOptions = {
 <rule>After saving, present the plan file path and ask the user to read/review the plan and explicitly approve it. Do NOT offer execution options until the user approves the plan.</rule>
 <rule>If the user requests changes, keep the plan status as draft, make the changes, re-run self-review, save the updated plan, and ask for approval again.</rule>
 <rule>After explicit user approval, update the saved plan file so the top-level status is &lt;status&gt;approved&lt;/status&gt;.</rule>
-<rule>After the saved plan status is approved, present the user with two execution options:</rule>
-<option name="workflow">Workflow tracked loop (recommended) — vv-implementer executes tasks, followed by required reviewers. Uses work_item_open with `mode: "implementation"` and explicit `requiredReviewers`, then work_item_close after the collect-all review round is ready to close.</option>
+<rule>After the saved plan status is approved, present the user with the execution options:</rule>
+<option name="workflow">Workflow tracked loop — vv-implementer executes tasks, followed by required reviewers per task. Uses work_item_open with `mode: "implementation"` and explicit `requiredReviewers`, then work_item_close after the collect-all review round is ready to close.</option>
+<option name="delegated">Delegated execution — workers implement bounded task packets, the controller accepts each attempt explicitly, and independent review happens at the plan's declared review checkpoints. Requires the delegated &lt;execution&gt; section with write scopes and checkpoints.</option>
 <option name="manual">Manual execution — the user or another agent executes tasks step by step following the plan directly.</option>
 <rule>Wait for the user's choice. Do NOT start implementation.</rule>
 </execution_handoff>

package/templates/skills/vv-plan/references/plan-template.xml

@@ -52,7 +52,52 @@
         <verification>
           <command></command>
         </verification>
+        <!--
+          write_scope is required for delegated plans: the worker's bounded
+          editing territory and the checkpoint fingerprint input. It must
+          include the task's primary <file> above.
+        -->
+        <write_scope>
+          <file></file>
+        </write_scope>
       </TASK-T-001>
     </WAVE-1>
   </tasks>
+
+  <!--
+    Optional execution section. Omit it entirely for legacy plans; a plan
+    without <execution> keeps its existing meaning. For delegated execution
+    declare the full checkpoint vocabulary:
+
+    <execution>
+      <mode>delegated</mode>
+      <review_checkpoints>
+        <CHECKPOINT-R-001>
+          <kind>milestone|final</kind>
+          <after_wave>WAVE-N</after_wave>
+          <covers>
+            <task_id>T-001</task_id>
+          </covers>
+          <scope>
+            <file>workspace/relative/path.ts</file>
+          </scope>
+          <reviewers>
+            <reviewer>spec|code</reviewer>
+          </reviewers>
+          <acceptance>
+            <criterion></criterion>
+          </acceptance>
+          <verification>
+            <command></command>
+          </verification>
+        </CHECKPOINT-R-001>
+      </review_checkpoints>
+    </execution>
+
+    Rules: exactly one final checkpoint after the last wave covering every
+    declared task and every task write scope; milestones cover only tasks of
+    waves up to and including after_wave; reviewer sets are explicit spec/code
+    choices — code review at meaningful intermediate milestones by default,
+    spec plus code at the final checkpoint.
+  -->
 </plan>

package/templates/skills/vv-review/SKILL.md

@@ -19,6 +19,7 @@ You are the vv-review skill. Your job is to route review requests to the appropr
 <step>Collect findings from each required reviewer. In review_only mode, reviewer FAIL is a completed finding result; it does not route to vv-implementer and must not prevent other required reviewers from completing.</step>
 <step>Findings are the FINAL output. Do NOT proceed to fixes without explicit user confirmation.</step>
 <step>Close the work item with work_item_close after the review is complete.</step>
+<step>When this review is a delegated-execution checkpoint review, the linked review work item is already open with the declared reviewer set: launch exactly those reviewers with the returned header and report the collected findings. A FAIL report closes the review work item but never satisfies the checkpoint — completion is decided by work_checkpoint verify, not by this skill. Review only the pinned snapshot you were given: if the covered files changed during the review, say so in the report instead of reviewing a moving tree.</step>
 </workflow>
 
 <finding_format>