@osovv/vv-opencode 1.4.1 → 1.4.3-rc.0

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

@@ -66,6 +66,8 @@ You are the vv-plan skill. Your job is to take an approved spec and write an imp
 <rule>Every task contains an &lt;acceptance&gt; section with one or more &lt;criterion&gt; elements.</rule>
 <rule>Each criterion is ONE specific, testable condition. If you cannot write a test for it, it is not specific enough.</rule>
 <rule>Criteria cover: success paths, failure paths, edge cases, boundary conditions, concurrency when relevant.</rule>
+<rule>Derive acceptance criteria and verification commands from the spec contract and the directly affected consumers, not from a preferred implementation. Criteria cover the material properties that must be preserved and the interactions with the consumers the change touches.</rule>
+<rule>Choose verification at the level where the risk arises: name the targeted command or scenario that exercises the changed behavior, and do not present a general check that cannot reach the changed path as evidence for a material criterion.</rule>
 <rule>Use plain English assertions: "Returns X when Y", "Throws Z if W", "Handles N concurrent calls without data loss".</rule>
 <rule>Each criterion is a separate child tag: &lt;criterion&gt;...&lt;/criterion&gt;. Line breaks between them for readability. No numbered tags.</rule>
 </acceptance_criteria_format>
@@ -157,7 +159,7 @@ export type CacheStoreOptions = {
 <self_review>
 <check>Spec coverage: For each requirement in the spec, identify the task that implements it. List any gaps as issues to fix.</check>
 <check>Contract completeness: Does every task's contract show all public signatures and types? Are edge cases covered by acceptance criteria?</check>
-<check>Acceptance criteria quality: Is every criterion testable? Could a reviewer or implementer write a failing test for it?</check>
+<check>Acceptance criteria quality: Is every criterion testable? Could a reviewer or implementer write a failing test for it? Are the material properties that must be preserved and the directly affected consumers covered by criteria whose verification actually reaches them?</check>
 <check>Type consistency: Do types, signatures, and property names match across tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.</check>
 <rule>Fix issues inline as you find them. No second review pass needed — just fix and continue.</rule>
 <check>Format compliance: Are there zero XML attributes? Is every snippet in CDATA? Is every task a &lt;TASK-T-NNN&gt; element with identity in the element name and no child id element?</check>

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

@@ -18,6 +18,8 @@ You are the vv-review skill. Your job is to route review requests to the appropr
 <step>Put the VVOC_WORK_ITEM_ID header as the first line of each reviewer sub-agent prompt.</step>
 <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>When the request is a re-review after a fix, scope the reviewer packets to a scoped re-review: verify the prior findings against the fix and the fix's material effects — including directly affected consumers where necessary — rather than re-reviewing an entire unchanged change from scratch. Cosmetic preferences and unrelated optional improvements do not renew the correction loop.</step>
+<step>Present findings honestly: "no findings" means no defect was discovered within the reviewed scope, not a guarantee of correctness. Note material verification gaps and what the review could not establish; do not turn an empty findings list into a completion or correctness claim.</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>

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

@@ -23,6 +23,7 @@ UX cues (roadmap, progress markers, depth estimates, checkpoints) are TRANSPAREN
 <principle>Before asking the user, check whether the question can be answered by exploring the codebase. If the answer exists in existing code, patterns, configs, or docs, explore first and present what you found. Only ask the user when the codebase cannot answer.</principle>
 <principle>Resolve dependencies in order. Start with the highest-impact decision (purpose, scope, data model) and work outward (API shape, error handling, testing). A decision about the data model must be settled before deciding the API surface.</principle>
 <principle>Understand the full landscape: purpose, constraints, success criteria, non-goals, edge cases, existing code patterns.</principle>
+<principle>While walking components and data flow, capture the material properties that must be preserved — existing behavior, contracts, and consumers the change must not break — so testing and error handling can demand their verification instead of covering only the new happy path.</principle>
 <principle>When the decision tree reaches a fork (2-3 viable approaches), present all options with trade-offs. Lead with your recommendation and explain why. The user picks one — that closes the fork and the tree continues from that branch.</principle>
 <principle>When presenting design sections, do it one section at a time. After each section: "Does this look right?" If yes, move to the next. If no, resolve concerns before continuing.</principle>
 <principle>Cover every section of the spec template: goal, architecture, tech_stack, components, data_flow, error_handling, testing, non_goals. The roadmap shown at the start IS the coverage checklist. A section is "closed" only when its template element is fully decidable.</principle>
@@ -82,7 +83,7 @@ UX cues (roadmap, progress markers, depth estimates, checkpoints) are TRANSPAREN
 <check>Placeholder scan: Any TBD, TODO, incomplete sections, or vague requirements? Fix them.</check>
 <check>Internal consistency: Do any sections contradict each other? Does the architecture match the component descriptions?</check>
 <check>Scope check: Is this focused enough for a single implementation plan, or does it need decomposition into sub-projects?</check>
-<check>Ambiguity check: Could any requirement be interpreted two different ways? If so, pick one interpretation and make it explicit.</check>
+<check>Ambiguity check: Could any requirement be interpreted two different ways? Resolve repository-answerable engineering ambiguity from the established code and contracts; a genuine business-semantics fork goes to the user as an explicit question — never silently pick a business interpretation.</check>
 <rule>Fix issues inline. No need to re-review — just fix and move on.</rule>
 </self_review>