docs: standardize verification handoffs and lane claims

.config/opencode/agents/coder.md

@@ -23,5 +23,14 @@ Implement only the assigned lane.
 - Follow the provided spec and stay inside the requested scope.
 - Reuse existing project patterns before introducing new ones.
 - Report notable assumptions, touched files, and any follow-up needed.
+- When reporting verification evidence, use the compact verification summary shape:
+  - **Goal** – what is being verified
+  - **Mode** – `smoke` or `full`
+  - **Command/Check** – exact command or manual check performed
+  - **Result** – `pass`, `fail`, `blocked`, or `not_run`
+  - **Key Evidence** – concise proof (output snippet, hash, assertion count)
+  - **Artifacts** – paths to logs/screenshots, or `none`
+  - **Residual Risk** – known gaps, or `none`
+- Keep raw logs out of handoff messages; summarize failures first and point to raw evidence only when needed.
 - Clean up temporary artifacts from the assigned lane (e.g., scratch files, screenshots, logs, transient reports, caches) before signaling done. Intended committed deliverables are not cleanup targets.
-- Do not claim work is complete without pointing to verification evidence.
+- Do not claim work is complete without pointing to verification evidence in the compact shape above.

.config/opencode/agents/reviewer.md

@@ -19,6 +19,9 @@ Act as a skeptical reviewer.
   - `test-driven-development` when reviewing red/green discipline evidence.
 
 - Look for incorrect assumptions, missing cases, regressions, unclear specs, and weak verification.
+- Reject completion claims that lack structured verification evidence in the compact shape (`Goal`, `Mode`, `Command/Check`, `Result`, `Key Evidence`, `Artifacts`, `Residual Risk`).
+- Reject execution notes or handoffs that lack lane-ownership boundaries (owner, claimed files/areas, status).
 - Prefer concrete findings over broad advice.
 - When reviewing a plan, call out ambiguity before execution starts.
 - When reviewing code or tests, provide evidence-backed issues in priority order.
+- Remain read-only: report findings via response message; do not write to execution notes or modify files.

.config/opencode/agents/tester.md

@@ -24,7 +24,15 @@ Own verification and failure evidence.
   - `javascript-typescript-development` when verifying JS/TS code.
 
 - Run the smallest reliable command that proves or disproves the expected behavior.
-- Capture failing commands, key output, and suspected root causes.
+- Report every result using the compact verification summary shape:
+  - **Goal** – what is being verified
+  - **Mode** – `smoke` or `full`
+  - **Command/Check** – exact command or manual check performed
+  - **Result** – `pass`, `fail`, `blocked`, or `not_run`
+  - **Key Evidence** – concise proof (output snippet, hash, assertion count)
+  - **Artifacts** – paths to logs/screenshots, or `none`
+  - **Residual Risk** – known gaps, or `none`
+- Keep raw logs out of primary context unless a check fails or the caller requests full output. Summarize the failure first, then point to raw evidence.
 - Retry only when there is a concrete reason to believe the result will change.
 - Flag any temporary artifacts observed during verification (e.g., scratch files, screenshots, logs, transient reports, caches) so builder or coder can clean them up before completion.
 - Do not make code edits.

.config/opencode/skills/dispatching-parallel-agents/SKILL.md

@@ -10,26 +10,29 @@ Use this skill before parallel fan-out.
 
 ## Isolation Test (Required)
 
-Parallel lanes are allowed only when lanes do not share:
+Before fan-out, verify that no two lanes share:
 
-- files under active mutation
+- **Claimed Files/Areas** under active mutation (paths or named workflow surfaces from the lane-claim entries)
 - APIs or schemas being changed
-- verification steps that must run in sequence
+- **Sequential verification dependencies** (verification steps that must run in order across lanes)
 
-If any of these overlap, run sequentially.
+Overlapping claimed files/areas or sequential verification dependencies **forbid** parallel fan-out. Run those lanes sequentially.
 
 ## Workflow
 
-1. Define lanes with explicit scope, inputs, and outputs.
-2. Assign a single integrator (usually builder) for merge and final validation.
-3. Require each lane to provide verification evidence, not just code output.
-4. Integrate in dependency order.
-5. Run final end-to-end verification after integration.
+1. **Builder creates lane-claim entries** in the execution note before fan-out, recording for each lane: `Owner`, `Status` (→ `active`), `Claimed Files/Areas`, `Depends On`, and `Exit Condition`.
+2. Run the isolation test above against the claimed files/areas and dependencies. Abort fan-out on any overlap.
+3. Define lane scope, inputs, and outputs for each subagent.
+4. Assign a single integrator (usually builder) for merge and final validation.
+5. Each lane must return **compact verification evidence** in the shared shape (`Goal`, `Mode`, `Command/Check`, `Result`, `Key Evidence`, `Artifacts`, `Residual Risk`) — not just code output.
+6. Integrate in dependency order; update lane statuses to `released` or `done`.
+7. Run final end-to-end verification (`full` mode) after integration.
 
 ## Planner/Builder Expectations
 
-- Planner: design parallel lanes only when isolation is demonstrable.
-- Builder: load this skill before fan-out and enforce lane boundaries strictly.
+- **Planner**: define intended lanes and claimed files/areas in the approved plan when parallelization is expected.
+- **Builder**: load this skill before fan-out, create or update lane-claim entries in the execution note, mark them `active`/`released`/`done`/`blocked`, and enforce lane boundaries strictly.
+- Claims are advisory markdown metadata, not hard runtime locks. Do not invent lockfiles or runtime enforcement.
 
 ## Red Flags
 

.config/opencode/skills/verification-before-completion/SKILL.md

@@ -19,15 +19,25 @@ Use this skill before declaring work done, handing off, or approving readiness.
 
 ## Evidence Standard
 
-- Include exact commands run.
-- Include pass/fail outcomes and key output.
-- Tie evidence to each acceptance condition.
+Use the compact verification summary shape for every evidence entry:
+
+- **Goal** – what is being verified
+- **Mode** – `smoke` (intermediate checkpoints) or `full` (final completion)
+- **Command/Check** – exact command or manual check performed
+- **Result** – `pass`, `fail`, `blocked`, or `not_run`
+- **Key Evidence** – concise proof (output snippet, hash, assertion count)
+- **Artifacts** – paths to logs/screenshots, or `none`
+- **Residual Risk** – known gaps, or `none`
+
+Keep raw logs out of primary context by default. When a check fails, summarize the failure first and then point to the raw evidence. Include full output only when explicitly requested.
+
+Tie each evidence entry to an acceptance condition from the plan.
 
 ## Role Expectations
 
-- Builder and tester: no completion claim without concrete verification evidence.
-- Reviewer: reject completion claims that are not evidence-backed.
-- Coder: point to verification evidence from assigned lane before signaling done.
+- Builder and tester: no completion claim without verification evidence in the compact shape above.
+- Reviewer: reject completion claims that lack structured evidence or lane-ownership boundaries.
+- Coder: include compact-shape verification evidence from the assigned lane before signaling done.
 
 ## If Verification Fails