feat(agents): add verification ownership budgets

CONTEXT.md

@@ -47,7 +47,7 @@ A glossary of the terms used in this project's domain. Definitions describe what
 
 ## Skills
 
-- **Skill** — A bundled, self-contained workflow or capability shipped with the plugin. Bundled skills: codemap, clonedeps, simplify, deepwork, reflect, worktrees, oh-my-opencode-slim. Note: `loop-engineering` exists on disk but is not registered as a bundled skill.
+- **Skill** — A bundled, self-contained workflow or capability shipped with the plugin. Bundled skills (eight, including managed `verification-planning`): codemap, clonedeps, simplify, deepwork, verification-planning, reflect, worktrees, oh-my-opencode-slim. Note: `loop-engineering` exists on disk but is not registered as a bundled skill.
 
 ## Hooks
 

docs/background-orchestration.md

@@ -171,19 +171,31 @@ guards.
 Specialist outputs are inputs, not final truth. The orchestrator reconciles them
 against each other and the original user goal.
 
-### 5. Verify
-
-Verification remains orchestrator-owned, but not necessarily orchestrator-run.
-
-Examples:
-
-- route UI review to `designer`,
-- route code review to `oracle`,
-- route test writing or test updates to `fixer`,
-- run final shell checks directly only when appropriate.
-
-The final response should only happen after relevant background work is terminal
-and reconciled.
+### 5. Verify with a proportionate budget
+
+Verification remains orchestrator-owned, but not necessarily
+orchestrator-run. The orchestrator defines the success criteria, selects the
+minimum evidence that can establish them, reconciles the final state, and
+reports material uncertainty. Specialists own the focused validation of their
+bounded work and must return the checks and evidence they produced.
+
+Treat verification as a budget based on scope, semantic risk, uncertainty, and
+impact:
+
+- Start with the narrowest relevant validation.
+- Broaden it only when integration scope, uncertainty, or a failed focused
+  check justifies the additional cost.
+- Do not run project-wide checks by habit or impose a fixed
+  lint/build/format/test checklist merely because files changed.
+- Route UI review to `designer`, test writing or updates to `fixer`, and run
+  focused shell checks directly when that is the most efficient evidence path.
+- Treat Oracle as an independent escalation, not a default verification gate.
+  Dispatch it when semantic risk, architectural uncertainty, persistent
+  failures, or another high-cost decision makes the expected risk reduction
+  worth the coordination cost.
+
+The final response should only happen after relevant background work is
+terminal, reconciled, and covered by proportionate final-state evidence.
 
 ---
 
@@ -485,16 +497,23 @@ Make background subagents first-class in this plugin.
 
 The orchestrator should do something like:
 
-1. Create todos for discovery, design, implementation, docs, tests, review.
+1. Create todos for discovery, design, implementation, docs, tests, and
+   proportionate verification.
 2. Launch Explorer in background to map task-session hooks and task lifecycle.
-3. Launch Oracle in background to review architecture risks.
+3. If the change has material semantic or architectural risk, launch Oracle in
+   background to review that risk; otherwise keep the Oracle review budget for
+   a later uncertainty that merits it.
 4. Continue by preparing the dependency graph and file ownership plan.
-5. Wait for Explorer and Oracle via hook-driven completion.
+5. Wait for Explorer and, if it was launched, Oracle via hook-driven
+   completion.
 6. Dispatch Fixer to implement prompt/config/hook changes with clear ownership.
 7. Dispatch a second Fixer for tests if file ownership is separate.
 8. Wait for implementation results.
-9. Dispatch Oracle for final review.
-10. Run final checks.
+9. Reconcile the implementation and dispatch Oracle for final review only if
+   semantic risk or unresolved uncertainty makes independent review worthwhile.
+10. Run the narrowest final-state checks that establish the requested behavior
+    and integration state; do not apply an unconditional lint/build/format/test
+    checklist.
 11. Report final state.
 
 At no point does the orchestrator become the main implementer.

docs/loop-engineering-research.md

@@ -75,14 +75,17 @@ Osmani's framework identifies five primitives that compose a loop, plus durable
 
 | Feature | Claude Code | Codex | OpenCode |
 |---------|-------------|-------|----------|
-| `/goal` command | Yes | Yes | No (spec only) |
-| `/loop` command | Yes | No | No (spec only) |
+| `/goal` command | Yes | Yes | No |
+| `/loop` command | Yes | No | Yes (registered, prompt-driven) |
 | `/batch` command | Yes | No | No |
 | Scheduled automations | Yes (hooks, GitHub Actions) | Yes (Automations tab) | No (Phase 4) |
 | Event triggers | Yes (hooks) | Yes (triage inbox) | No |
 | Cron-like scheduling | Yes | Yes | No |
 
-**Verdict:** Claude Code and Codex both ship full automation primitives. OpenCode has the loop engine fully designed in spec but not yet implemented.
+**Verdict:** Claude Code and Codex both ship full automation primitives. OpenCode
+has a registered, prompt-driven `/loop` entry point, but no scheduling
+automation or fully integrated runtime `LoopEngine`; `LoopSession` primitives
+exist separately.
 
 ### Worktrees (Isolation)
 
@@ -91,7 +94,7 @@ Osmani's framework identifies five primitives that compose a loop, plus durable
 | Git worktree support | Yes (`--worktree`) | Yes (built-in per thread) | Yes (orchestrator skill) |
 | Sub-agent isolation | Yes (`isolation: worktree`) | Yes (built-in) | Yes (apply-patch hook) |
 | Programmatic creation | Yes | Yes | No (skill-only, prompt-driven) |
-| Loop integration | Yes | Yes | No (spec only) |
+| Loop integration | Yes | Yes | No (runtime integration absent) |
 
 **Verdict:** Claude Code and Codex have worktrees as runtime primitives integrated with their loop engines. OpenCode has worktrees as an orchestrator skill with apply-patch support, but no programmatic runtime integration yet.
 
@@ -101,11 +104,13 @@ Osmani's framework identifies five primitives that compose a loop, plus durable
 |---------|-------------|-------|----------|
 | `SKILL.md` format | Yes | Yes | Yes |
 | Per-agent assignment | Yes | Yes | Yes (with permissions) |
-| Bundled skills | No (user-created) | Yes (Agent Skills) | Yes (7 bundled) |
+| Bundled skills | No (user-created) | Yes (Agent Skills) | Yes (8 bundled) |
 | Skill marketplace | Yes (plugins) | Yes | No |
 | Intent debt prevention | Yes | Yes | Yes |
 
-**Verdict:** All three have mature skill systems. OpenCode's is notably rich with 7 bundled skills, per-agent permission control, and automatic sync on plugin updates.
+**Verdict:** All three have mature skill systems. OpenCode's is notably rich
+with 8 bundled skills, per-agent permission control, and automatic sync on
+plugin updates.
 
 ### Connectors / MCP
 
@@ -138,14 +143,17 @@ Osmani's framework identifies five primitives that compose a loop, plus durable
 
 | Feature | Claude Code | Codex | OpenCode |
 |---------|-------------|-------|----------|
-| Built-in loop command | Yes (`/goal`, `/loop`) | Yes (`/goal`) | No (spec only) |
-| Success criteria | Yes (test, build, lint) | Yes | Yes (designed: test, build, lint, fileExists, command, oracle, observer) |
-| Iteration cap | Yes | Yes | Yes (designed) |
-| No-progress detection | Yes | Yes | Yes (designed: totalErrors, timeoutCount) |
-| Escalation to human | Yes | Yes | Yes (designed: @council at Layer 0) |
-| Cost budgeting | Limited | Limited | Yes (designed) |
-
-**Verdict:** Claude Code and Codex have working loop primitives. OpenCode's loop engine is fully designed with a 3-layer architecture (Orchestrator -> LoopEngine -> Specialists) but not yet implemented.
+| Built-in loop command | Yes (`/goal`, `/loop`) | Yes (`/goal`) | Yes (`/loop`, registered and prompt-driven) |
+| Success criteria | Yes (test, build, lint) | Yes | Partial (criteria types exist in `LoopSession`; no integrated runtime) |
+| Iteration cap | Yes | Yes | Partial (`LoopSession` stores `maxAttempts`; no integrated runtime) |
+| No-progress detection | Yes | Yes | No integrated runtime (planned signals only) |
+| Escalation to human | Yes | Yes | Partial (`LoopSession` has escalation/manual-review state) |
+| Cost budgeting | Limited | Limited | No integrated runtime (planned) |
+
+**Verdict:** Claude Code and Codex have working loop primitives. OpenCode's
+`/loop` entry point is registered and prompt-driven, and `LoopSession`
+primitives cover definitions, phases, attempts, and history. A fully
+integrated runtime `LoopEngine` is not implemented.
 
 ---
 
@@ -213,30 +221,47 @@ In its purest form, Ralph is a Bash loop. That's it.
 
 | Building Block | Status | Implementation |
 |----------------|--------|----------------|
-| **Skills** | Mature | 7 bundled skills, per-agent permissions, auto-sync |
+| **Skills** | Mature | 8 bundled skills, per-agent permissions, auto-sync |
 | **Connectors/MCP** | Mature | 3 built-in MCPs, per-agent permission system |
 | **Sub-agents** | Mature | 9 agents, Background Job Board, session reuse |
 | **Worktrees** | Skill-only | Orchestrator skill, apply-patch hook support |
 | **Automations** | Not implemented | Deferred to Phase 4 |
-| **Loop engine** | Spec only | Fully designed, not implemented |
+| **Loop engine** | Partial | Registered, prompt-driven `/loop` entry point and `LoopSession` primitives; no fully integrated runtime `LoopEngine` |
+
+### Existing Loop Primitives
+
+OpenCode currently has a registered, prompt-driven `/loop` entry point. The
+`LoopSession` module provides definitions, phases, attempts, success-criterion
+types, manual-review state, and per-attempt history persistence. These are
+building blocks, not a complete runtime loop.
 
 ### What's Designed But Not Built
 
 The planned loop engineering runtime includes:
 
 - **LoopEngine** class with event-driven orchestration
-- **LoopSession** state machine (executing <-> verifying binary oscillation)
+- **Integrated runtime wiring** from `/loop` parsing through `LoopSession`,
+  background execution, verification, iteration, and escalation
 - **SuccessCriterion** routing (test, build, lint, fileExists, command, oracle, observer)
 - **Convergence signals** (totalErrors, timeoutCount, lastErrorAt)
-- **.loop-history.md** context compaction
+- **Integrated history compaction** across loop attempts and sessions
 - **Escalation via @council** at Layer 0 only
 - **Phased rollout:** Phase 1 (runtime engine) -> Phase 2 (loop skill) -> Phase 3 (routine integration) -> Phase 4 (triggers) -> Phase 5 (persistent memory)
 
 ### The Gap
 
-OpenCode has 3 of 5 building blocks fully wired (skills, connectors, sub-agents), worktrees as a skill, and automations + loop engine as unimplemented specs. The sub-agent infrastructure is the strongest piece - the Background Job Board, session reuse, and native depth tracking are more structured than what Claude Code or Codex expose.
+OpenCode has 3 of 5 building blocks fully wired (skills, connectors, sub-agents),
+worktrees as a skill, and automations still unimplemented. Loop support is
+partial: `/loop` is registered and prompt-driven, and `LoopSession` primitives
+exist, but a fully integrated runtime `LoopEngine` does not. The sub-agent
+infrastructure is the strongest piece - the Background Job Board, session reuse,
+and native depth tracking are more structured than what Claude Code or Codex
+expose.
 
-The missing piece is the outer loop itself: the scheduler that runs on a timer, spawns work, and keeps going without human intervention. Once that lands (Phase 1-2 of the spec), OpenCode will have a complete loop engineering stack.
+The missing piece is the integrated outer loop runtime: the scheduler and
+iteration engine that connect the prompt-driven entry point to execution,
+verification, and continued progress without human intervention. Once that
+lands, OpenCode will have a complete loop engineering stack.
 
 ---
 
@@ -304,7 +329,11 @@ The missing piece is the outer loop itself: the scheduler that runs on a timer,
 
 5. **Cost is the immediate bottleneck.** Token consumption scales linearly with loop iterations. Budget caps are mandatory, not optional.
 
-6. **OpenCode is 60% there.** Skills, connectors, and sub-agents are mature. The loop engine and automations are designed but unimplemented. The sub-agent infrastructure is the strongest piece of the stack.
+6. **OpenCode has a strong partial foundation.** Skills, connectors, and
+   sub-agents are mature. `/loop` is registered and prompt-driven, and
+   `LoopSession` primitives exist, but automations and a fully integrated runtime
+   `LoopEngine` remain incomplete. The sub-agent infrastructure is the strongest
+   piece of the stack.
 
 7. **autoresearch proves the minimum viable loop.** You don't need the full 5-block stack. A skill file + git + evaluation metric is enough to run autonomous experiments overnight. Start simple, add complexity when the task demands it.
 

docs/skills.md

@@ -12,6 +12,27 @@ new bundled versions for customized skills are staged under
 
 ---
 
+## Verification and Review Budget
+
+Verification is an orchestrator-owned decision and report, but the evidence may
+be collected by the specialist who owns the change or routed to a focused
+verifier. Treat verification as a budget: choose the minimum evidence that is
+meaningful for the change's scope, semantic risk, uncertainty, and impact.
+
+- Start with the narrowest relevant validation and broaden it only when
+  integration scope, uncertainty, or a failed focused check justifies the cost.
+- Do not run project-wide checks by habit or require a fixed lint/build/format/
+  test checklist merely because files changed.
+- Oracle review is an independent escalation, not a default verification step.
+  Spend that review budget when semantic risk, architectural uncertainty, or a
+  persistent failure makes the expected risk reduction worth the coordination
+  cost.
+- Specialists own validation of their bounded work and must report the checks
+  and evidence they produced. The orchestrator owns final-state reconciliation,
+  verification selection, and disclosure of remaining uncertainty.
+
+---
+
 ## Available Skills
 
 ### Bundled in repo
@@ -220,7 +241,9 @@ Safety defaults:
 - Pre-flight check on Git repo status and dirty worktrees.
 - Strict confirmation gates for all git modifications (`worktree add/remove`, `merge`, `rebase`, `cherry-pick`, `reset --hard`, branch operations).
 - Branch names default to `omo/<slug>` but respect custom user patterns.
-- Automated diff validation and compilation/test check before final integration.
+- Proportionate final-state validation before final integration: inspect the
+  diff and run checks that meaningfully cover the changed behavior and
+  integration risk, rather than an unconditional lint/build/format/test list.
 
 See **[Worktrees](worktrees.md)** for the detailed safety protocol.
 

src/agents/designer.ts

@@ -57,6 +57,24 @@ ${WRITABLE_FILE_OPERATIONS_RULES}
 - Call out concrete UX issues and improvements, not just abstract design advice
 - When validating, focus on what users actually see and feel
 
+## Verification Ownership
+- Run validation only when the Orchestrator explicitly assigns it to a named
+  success claim and within the stated maximum validation scope. Do not infer
+  validation ownership or add checks because the task seems to warrant them.
+- Keep assigned validation focused on user-visible behavior: visual hierarchy,
+  layout, responsive states, affordances, interaction flow, motion, and copy as
+  experienced by the user. Do not substitute broad technical checks for this
+  focus.
+- Do not autonomously add broad lint, typecheck, build, full-test, project-wide,
+  or reviewer work. Do not broaden or repeat a check outside the assigned
+  scope.
+- For every assigned check, report the exact command, result, and limitation.
+  For manual visual or interaction checks, report the exact route, viewport,
+  artifact, or interaction steps instead of inventing a command. Use \`passed\`,
+  \`failed\`, or \`skipped\` accurately; skipped is not passed. If no
+  validation is assigned, report \`Skipped: no validation assigned\` rather
+  than selecting a check yourself.
+
 ## Output Quality
 You're capable of extraordinary creative work. Commit fully to distinctive visions and show what's possible when breaking conventions thoughtfully.`;
 

src/agents/fixer.ts

@@ -20,6 +20,18 @@ ${WRITABLE_FILE_OPERATIONS_RULES}
 - Do not act as the primary reviewer; implement requested changes and surface obvious issues briefly
 - No design work — layout, styling, visual hierarchy, responsive behavior, animation, component feel. Refuse and tell the caller to use @designer.
 
+**Verification Ownership**:
+- Run validation only when the Orchestrator explicitly assigns it to a named
+  success claim and within the stated maximum validation scope. Do not infer
+  validation ownership or add checks because the task seems to warrant them.
+- Do not autonomously add broad lint, typecheck, build, full-test, project-wide,
+  or reviewer work. Do not broaden or repeat a check outside the assigned
+  scope.
+- For every assigned check, report the exact command, result, and limitation.
+  Use \`passed\`, \`failed\`, or \`skipped\` accurately; skipped is not
+  passed. If no validation is assigned, report
+  \`Skipped: no validation assigned\` rather than selecting a check yourself.
+
 **Output Format**:
 <summary>
 Brief summary of what was implemented

src/agents/orchestrator.ts

@@ -196,12 +196,25 @@ Review available agents and lane rules. Before beginning non-trivial work, ident
 
 ${WRITABLE_FILE_OPERATIONS_RULES}
 
+### Delegation Contract
+- Before every delegation, put a bounded contract in the task prompt and task
+  record. Assign the write scope (or explicitly state \`none\` for a read-only
+  lane), the observable success claims, the validation owner, and the maximum
+  validation scope.
+- A validation owner owns a named success claim end to end. Assign each
+  validation claim to exactly one owner; do not create shared or implicit
+  ownership. The owner may be the specialist, the orchestrator, or another
+  explicitly named lane.
+- The maximum validation scope must name the allowed commands, test files,
+  routes, artifacts, and environments. Specialists must not infer additional
+  checks from the task type.
+
 ## 4. Plan and Parallelize
 When the routing threshold calls for delegation, build a short work graph before dispatching:
 - Independent lanes that can run now
 - Dependency-ordered lanes that must wait
 - Advisory ownership for write-capable lanes
-- Verification/review lanes that run after implementation
+- Explicitly assigned validation lanes that run after implementation
 
 ### Todo Continuity
 - When the user adds a new task while a todo list exists, append the new task to the end of the existing todo list instead of replacing the list.
@@ -248,12 +261,29 @@ Balance: respect dependencies, avoid parallelizing what must be sequential, and
 
 ## 6. Verify
 - Define the observable success criteria from the user's request.
-- Choose the minimum verification that produces meaningful evidence for the change's scope, risk, uncertainty, and potential impact.
-- Start with the narrowest relevant validation. Broaden verification only when integration scope, uncertainty, risk, or a failed focused check justifies it.
-- Do not run project-wide checks by habit or merely because files changed.
-- Do not treat verification as a fixed checklist; select evidence that can actually confirm the requested behavior.
-- Request independent review only when its expected risk reduction justifies its coordination cost.
-- Report what was verified and any material remaining uncertainty.
+- Before delegating, assign every success claim a write scope, one validation
+  owner, and a maximum validation scope. Keep that ownership with the claim
+  through integration.
+- Reconcile all writer lanes before entering final-state integration
+  verification: wait for terminal results, inspect the resulting changes,
+  resolve overlapping or partial writes, and establish the final candidate
+  state first.
+- For the final candidate, select the smallest orthogonal set of checks that
+  provides meaningful evidence for the claims, scope, risk, uncertainty, and
+  environment coverage. Do not run project-wide checks by habit or merely
+  because files changed.
+- Reuse reported evidence only while it applies to the final candidate state,
+  including its relevant files, command/configuration, and environment. Treat
+  later writes, scope changes, or mismatched environments as stale evidence.
+- Broaden or repeat checks only for stale, failing, or ambiguous evidence, an
+  explicit mandate, required environment coverage, or a named high-risk case.
+  Do not repeat checks just to increase confidence without one of those
+  reasons.
+- Do not automatically dispatch review lanes. Independent review is separate
+  from required validation and needs an explicit mandate or a named high-risk
+  rationale; it is never implied by implementation completion.
+- Report what was verified, the owner and exact evidence for each claim, and
+  any material remaining uncertainty. A skipped check is not a passed check.
 
 </Workflow>
 

src/agents/verification-ownership.test.ts

@@ -0,0 +1,107 @@
+import { describe, expect, test } from 'bun:test';
+import { createDesignerAgent } from './designer';
+import { createFixerAgent } from './fixer';
+import {
+  buildOrchestratorPrompt,
+  createOrchestratorAgent,
+} from './orchestrator';
+
+describe('verification ownership prompt contracts', () => {
+  test('orchestrator assigns ownership and limits final-state verification', () => {
+    const prompt = buildOrchestratorPrompt();
+
+    expect(prompt).toContain('bounded contract');
+    expect(prompt).toContain('write scope');
+    expect(prompt).toContain('observable success claims');
+    expect(prompt).toContain('validation owner');
+    expect(prompt).toContain('maximum validation scope');
+    expect(prompt).toContain('exactly one owner');
+    expect(prompt).toContain(
+      'Reconcile all writer lanes before entering final-state',
+    );
+    expect(prompt).toContain('smallest orthogonal set of checks');
+    expect(prompt).toContain('Reuse reported evidence only while it applies');
+    expect(prompt).toContain('stale, failing, or ambiguous evidence');
+    expect(prompt).toContain('Do not automatically dispatch review lanes');
+    expect(prompt).toContain('A skipped check is not a passed check');
+  });
+
+  test('fixer limits validation to its assigned claim and scope', () => {
+    const prompt = createFixerAgent('test/model').config.prompt as string;
+
+    expect(prompt).toContain(
+      'only when the Orchestrator explicitly assigns it',
+    );
+    expect(prompt).toContain('success claim');
+    expect(prompt).toContain('maximum validation scope');
+    expect(prompt).toContain('broad lint, typecheck, build, full-test');
+    expect(prompt).toContain('exact command, result, and limitation');
+    expect(prompt).toMatch(/skipped is not\s+passed/);
+    expect(prompt).toContain('Skipped: no validation assigned');
+    expect(prompt).toContain('reviewer work');
+  });
+
+  test('designer preserves user-visible validation ownership', () => {
+    const prompt = createDesignerAgent('test/model').config.prompt as string;
+
+    expect(prompt).toContain(
+      'only when the Orchestrator explicitly assigns it',
+    );
+    expect(prompt).toContain('success claim');
+    expect(prompt).toContain('maximum validation scope');
+    expect(prompt).toContain('user-visible behavior');
+    expect(prompt).toContain('visual hierarchy');
+    expect(prompt).toContain('exact route, viewport,');
+    expect(prompt).toContain('interaction steps');
+    expect(prompt).toContain('exact command, result, and limitation');
+    expect(prompt).toMatch(/skipped is not\s+passed/);
+  });
+
+  test('specialist overrides retain replacement and append semantics', () => {
+    const fixerReplacement = createFixerAgent(
+      'test/model',
+      'replacement fixer prompt',
+      'ignored fixer append',
+    );
+    const fixerAppend = createFixerAgent(
+      'test/model',
+      undefined,
+      'fixer append prompt',
+    );
+    const designerReplacement = createDesignerAgent(
+      'test/model',
+      'replacement designer prompt',
+      'ignored designer append',
+    );
+    const designerAppend = createDesignerAgent(
+      'test/model',
+      undefined,
+      'designer append prompt',
+    );
+
+    expect(fixerReplacement.config.prompt).toBe('replacement fixer prompt');
+    expect(fixerAppend.config.prompt).toEndWith('fixer append prompt');
+    expect(designerReplacement.config.prompt).toBe(
+      'replacement designer prompt',
+    );
+    expect(designerAppend.config.prompt).toEndWith('designer append prompt');
+  });
+
+  test('orchestrator overrides retain replacement and append semantics', () => {
+    const replacement = createOrchestratorAgent(
+      'test/model',
+      'replacement orchestrator prompt',
+      'orchestrator append prompt',
+    );
+    const appended = createOrchestratorAgent(
+      'test/model',
+      undefined,
+      'orchestrator append prompt',
+    );
+
+    expect(replacement.config.prompt).toBe(
+      'replacement orchestrator prompt\n\norchestrator append prompt',
+    );
+    expect(appended.config.prompt).toEndWith('orchestrator append prompt');
+  });
+});

src/hooks/__snapshots__/cache-payload.snapshot.test.ts.snap

@@ -128,12 +128,25 @@ Review available agents and lane rules. Before beginning non-trivial work, ident
 - Before destructive or broad shell operations, verify the target set and quote paths. Prefer a dry-run/listing first when practical.
 - Do not use cat/head/tail/sed/awk only to read code into context; use read/grep unless a shell pipeline is genuinely the better diagnostic.
 
+### Delegation Contract
+- Before every delegation, put a bounded contract in the task prompt and task
+  record. Assign the write scope (or explicitly state \`none\` for a read-only
+  lane), the observable success claims, the validation owner, and the maximum
+  validation scope.
+- A validation owner owns a named success claim end to end. Assign each
+  validation claim to exactly one owner; do not create shared or implicit
+  ownership. The owner may be the specialist, the orchestrator, or another
+  explicitly named lane.
+- The maximum validation scope must name the allowed commands, test files,
+  routes, artifacts, and environments. Specialists must not infer additional
+  checks from the task type.
+
 ## 4. Plan and Parallelize
 When the routing threshold calls for delegation, build a short work graph before dispatching:
 - Independent lanes that can run now
 - Dependency-ordered lanes that must wait
 - Advisory ownership for write-capable lanes
-- Verification/review lanes that run after implementation
+- Explicitly assigned validation lanes that run after implementation
 
 ### Todo Continuity
 - When the user adds a new task while a todo list exists, append the new task to the end of the existing todo list instead of replacing the list.
@@ -183,12 +196,29 @@ Balance: respect dependencies, avoid parallelizing what must be sequential, and
 
 ## 6. Verify
 - Define the observable success criteria from the user's request.
-- Choose the minimum verification that produces meaningful evidence for the change's scope, risk, uncertainty, and potential impact.
-- Start with the narrowest relevant validation. Broaden verification only when integration scope, uncertainty, risk, or a failed focused check justifies it.
-- Do not run project-wide checks by habit or merely because files changed.
-- Do not treat verification as a fixed checklist; select evidence that can actually confirm the requested behavior.
-- Request independent review only when its expected risk reduction justifies its coordination cost.
-- Report what was verified and any material remaining uncertainty.
+- Before delegating, assign every success claim a write scope, one validation
+  owner, and a maximum validation scope. Keep that ownership with the claim
+  through integration.
+- Reconcile all writer lanes before entering final-state integration
+  verification: wait for terminal results, inspect the resulting changes,
+  resolve overlapping or partial writes, and establish the final candidate
+  state first.
+- For the final candidate, select the smallest orthogonal set of checks that
+  provides meaningful evidence for the claims, scope, risk, uncertainty, and
+  environment coverage. Do not run project-wide checks by habit or merely
+  because files changed.
+- Reuse reported evidence only while it applies to the final candidate state,
+  including its relevant files, command/configuration, and environment. Treat
+  later writes, scope changes, or mismatched environments as stale evidence.
+- Broaden or repeat checks only for stale, failing, or ambiguous evidence, an
+  explicit mandate, required environment coverage, or a named high-risk case.
+  Do not repeat checks just to increase confidence without one of those
+  reasons.
+- Do not automatically dispatch review lanes. Independent review is separate
+  from required validation and needs an explicit mandate or a named high-risk
+  rationale; it is never implied by implementation completion.
+- Report what was verified, the owner and exact evidence for each claim, and
+  any material remaining uncertainty. A skipped check is not a passed check.
 
 </Workflow>
 

src/skills/simplify/SKILL.md

@@ -36,7 +36,7 @@ Before every change, ask:
 - Does this produce the same output for every input?
 - Does this maintain the same error behavior?
 - Does this preserve the same side effects and ordering?
-- Do all existing tests still pass without modification?
+- What focused evidence would reveal a behavior change in the final state?
 
 ### 2. Follow Project Conventions
 
@@ -108,8 +108,9 @@ Make one simplification at a time.
 For each simplification:
 
 1. Make the change
-2. Run relevant tests
-3. Keep it only if behavior is preserved
+2. Identify the claim it affects and use the narrowest evidence that can
+   establish whether behavior was preserved
+3. Keep it only when the evidence supports the claim
 
 Separate refactoring from feature work whenever possible.
 
@@ -129,10 +130,16 @@ After simplifying, confirm:
 - Favor explicit names and smaller focused helpers when they improve readability
 - Keep refactors tightly scoped to the task or review feedback
 
-## Verification Checklist
+## Final-state verification budget
 
-- [ ] Existing tests pass without modification
-- [ ] Build/typecheck/lint still pass
-- [ ] No unrelated files were refactored
-- [ ] No error handling was weakened or removed
-- [ ] The result is simpler to review than the original
+Validate the final diff rather than applying a fixed command set. State each
+distinct preservation claim and assign one owner to establish or refute it.
+Reuse earlier evidence only if the relevant code, inputs, environment, and
+state remain valid; otherwise replace it with fresh evidence. Select the
+smallest orthogonal set that covers the claims and important boundaries.
+
+Run checks explicitly required by repository or release instructions. Broaden
+or repeat checks only for a stated narrow condition, such as a changed shared
+boundary, invalidated evidence, nondeterministic results, or stakes requiring
+independent confirmation. Keep the final review focused on behavior, error
+handling, side effects, conventions, and the absence of unrelated changes.

src/skills/verification-planning/SKILL.md

@@ -37,6 +37,20 @@ trustworthy conclusion with proportionate cost, safety, and effort.
 **Complete when:** there is a preferred path, its limitations are understood,
 and a weaker or stronger alternative is available if circumstances change.
 
+## Set a verification budget
+
+Turn the change into distinct claims and assign one owner to establish or refute
+each claim. Reuse existing evidence only while it remains valid for the same
+claim: the relevant code, inputs, environment, and state must still match.
+
+At the final state, choose the minimum orthogonal set of evidence paths that
+covers the claims and important boundaries. Do not repeat overlapping checks
+merely for reassurance. Broaden or repeat verification only under narrow,
+stated conditions, such as a changed shared boundary, invalidated evidence,
+nondeterministic results, or stakes that require independent confirmation.
+Record why any additional evidence earns its cost. This is a budget for
+credible evidence, not a fixed command checklist.
+
 ## 3. Create a verification affordance when needed
 
 When the existing system leaves the decisive truth too indirect or ambiguous,

src/skills/worktrees/SKILL.md

@@ -135,11 +135,17 @@ keeps them readable to OpenCode.
 
 ### Phase 3: Integration & Validation
 Before merging or integrating the worktree branch:
-1. Run lint, build, formatting, and unit tests inside the worktree directory.
-2. Generate and display a clear diff comparing the worktree branch to the
+1. State the distinct final-state claims, assign one owner to establish or
+   refute each, and select the minimum orthogonal evidence set for the changed
+   behavior and its important boundaries.
+2. Reuse evidence only while the relevant code, inputs, environment, and state
+   remain valid. Run checks explicitly required by repository or release
+   instructions, and broaden or repeat checks only when a stated condition
+   warrants the additional cost.
+3. Generate and display a clear diff comparing the worktree branch to the
    integration base branch.
-3. Ask the user for confirmation to integrate.
-4. Perform the approved integration, such as merge or cherry-pick, from the main
+4. Ask the user for confirmation to integrate.
+5. Perform the approved integration, such as merge or cherry-pick, from the main
    checkout or the user-approved integration checkout.
 
 ### Phase 4: Cleanup & Pruning