refactor(agents): trim verification guidance

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 (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.
+- **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.
 
 ## Hooks
 

docs/background-orchestration.md

@@ -171,31 +171,16 @@ guards.
 Specialist outputs are inputs, not final truth. The orchestrator reconciles them
 against each other and the original user goal.
 
-### 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.
+### 5. Verify
+
+Verification remains orchestrator-owned and should be proportionate to the
+change. Use focused checks against the final state, broadening them only when
+risk or uncertainty warrants it. Oracle review is conditional: dispatch it for
+material semantic or architectural risk, unresolved uncertainty, or another
+high-cost decision—not automatically.
+
+The final response should only happen after relevant background work is terminal,
+reconciled, and supported by final-state evidence.
 
 ---
 
@@ -498,22 +483,18 @@ Make background subagents first-class in this plugin.
 The orchestrator should do something like:
 
 1. Create todos for discovery, design, implementation, docs, tests, and
-   proportionate verification.
+   verification.
 2. Launch Explorer in background to map task-session hooks and task lifecycle.
-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.
+3. Launch Oracle in background only if the change has material semantic or
+   architectural risk or unresolved uncertainty.
 4. Continue by preparing the dependency graph and file ownership plan.
-5. Wait for Explorer and, if it was launched, Oracle via hook-driven
-   completion.
+5. Wait for the launched specialists 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. 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.
+9. Reconcile the implementation and dispatch Oracle only if remaining risk or
+   uncertainty makes independent review worthwhile.
+10. Run proportionate checks against the final state.
 11. Report final state.
 
 At no point does the orchestrator become the main implementer.

docs/loop-engineering-research.md

@@ -75,17 +75,14 @@ Osmani's framework identifies five primitives that compose a loop, plus durable
 
 | Feature | Claude Code | Codex | OpenCode |
 |---------|-------------|-------|----------|
-| `/goal` command | Yes | Yes | No |
-| `/loop` command | Yes | No | Yes (registered, prompt-driven) |
+| `/goal` command | Yes | Yes | No (spec only) |
+| `/loop` command | Yes | No | No (spec only) |
 | `/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 a registered, prompt-driven `/loop` entry point, but no scheduling
-automation or fully integrated runtime `LoopEngine`; `LoopSession` primitives
-exist separately.
+**Verdict:** Claude Code and Codex both ship full automation primitives. OpenCode has the loop engine fully designed in spec but not yet implemented.
 
 ### Worktrees (Isolation)
 
@@ -94,7 +91,7 @@ exist separately.
 | 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 (runtime integration absent) |
+| Loop integration | Yes | Yes | No (spec only) |
 
 **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.
 
@@ -104,13 +101,11 @@ exist separately.
 |---------|-------------|-------|----------|
 | `SKILL.md` format | Yes | Yes | Yes |
 | Per-agent assignment | Yes | Yes | Yes (with permissions) |
-| Bundled skills | No (user-created) | Yes (Agent Skills) | Yes (8 bundled) |
+| Bundled skills | No (user-created) | Yes (Agent Skills) | Yes (7 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 8 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 7 bundled skills, per-agent permission control, and automatic sync on plugin updates.
 
 ### Connectors / MCP
 
@@ -143,17 +138,14 @@ plugin updates.
 
 | Feature | Claude Code | Codex | OpenCode |
 |---------|-------------|-------|----------|
-| 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.
+| 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.
 
 ---
 
@@ -221,47 +213,30 @@ In its purest form, Ralph is a Bash loop. That's it.
 
 | Building Block | Status | Implementation |
 |----------------|--------|----------------|
-| **Skills** | Mature | 8 bundled skills, per-agent permissions, auto-sync |
+| **Skills** | Mature | 7 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** | 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.
+| **Loop engine** | Spec only | Fully designed, not implemented |
 
 ### What's Designed But Not Built
 
 The planned loop engineering runtime includes:
 
 - **LoopEngine** class with event-driven orchestration
-- **Integrated runtime wiring** from `/loop` parsing through `LoopSession`,
-  background execution, verification, iteration, and escalation
+- **LoopSession** state machine (executing <-> verifying binary oscillation)
 - **SuccessCriterion** routing (test, build, lint, fileExists, command, oracle, observer)
 - **Convergence signals** (totalErrors, timeoutCount, lastErrorAt)
-- **Integrated history compaction** across loop attempts and sessions
+- **.loop-history.md** context compaction
 - **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 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.
+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.
 
-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.
+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.
 
 ---
 
@@ -329,11 +304,7 @@ lands, OpenCode will have a complete loop engineering stack.
 
 5. **Cost is the immediate bottleneck.** Token consumption scales linearly with loop iterations. Budget caps are mandatory, not optional.
 
-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.
+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.
 
 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

@@ -14,22 +14,9 @@ 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.
+Use a proportionate final-state verification plan for each change. Run checks
+required by repository and release instructions; add independent review or
+broader evidence only when the change's risk or uncertainty warrants it.
 
 ---
 
@@ -241,9 +228,8 @@ 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.
-- 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.
+- Use a proportionate final-state verification plan before final integration,
+  including checks required by repository and release instructions.
 
 See **[Worktrees](worktrees.md)** for the detailed safety protocol.
 

src/agents/designer.ts

@@ -55,25 +55,12 @@ ${WRITABLE_FILE_OPERATIONS_RULES}
 ## Review Responsibilities
 - Review existing UI for usability, responsiveness, visual consistency, and polish when asked
 - 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.
+
+## Verification
+- Run only validation assigned by the Orchestrator; do not broaden it
+  automatically.
+- Report validation results and skips accurately.
+- Assigned validation should be user-visible.
 
 ## 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,17 +20,10 @@ ${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.
+**Verification**:
+- Run only validation assigned by the Orchestrator; do not broaden it
+  automatically.
+- Report validation results and skips accurately.
 
 **Output Format**:
 <summary>

src/agents/orchestrator.ts

@@ -197,24 +197,13 @@ 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.
+- Every delegation names a validation owner and allowed scope.
 
 ## 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
-- 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.
@@ -260,30 +249,9 @@ Balance: respect dependencies, avoid parallelizing what must be sequential, and
 - Do not leave \`task_id\` empty when intending to reuse; omitted or empty \`task_id\` creates a new specialist session.
 
 ## 6. Verify
-- Define the observable success criteria from the user's request.
-- 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.
+- Reconcile all writer lanes before final validation.
+- Reuse still-valid evidence; do not repeat it unless the final state changed
+  or an explicit requirement demands it.
 
 </Workflow>
 

src/agents/verification-ownership.test.ts

@@ -1,107 +1,40 @@
 import { describe, expect, test } from 'bun:test';
 import { createDesignerAgent } from './designer';
 import { createFixerAgent } from './fixer';
-import {
-  buildOrchestratorPrompt,
-  createOrchestratorAgent,
-} from './orchestrator';
+import { buildOrchestratorPrompt } from './orchestrator';
 
 describe('verification ownership prompt contracts', () => {
-  test('orchestrator assigns ownership and limits final-state verification', () => {
+  test('orchestrator assigns validation ownership and scope', () => {
     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',
+      'Every delegation names a validation owner and allowed scope',
     );
-    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',
+      'Reconcile all writer lanes before final validation',
     );
-    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',
+      'Reuse still-valid evidence; do not repeat it unless the final state changed',
     );
-    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/);
+    expect(prompt).toContain('an explicit requirement demands it');
   });
 
-  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',
-    );
+  test('fixer runs and reports only assigned validation', () => {
+    const prompt = createFixerAgent('test/model').config.prompt as string;
 
-    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(prompt).toContain(
+      'Run only validation assigned by the Orchestrator; do not broaden it',
     );
-    expect(designerAppend.config.prompt).toEndWith('designer append prompt');
+    expect(prompt).toContain('Report validation results and skips accurately');
   });
 
-  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',
-    );
+  test('designer runs and reports only assigned user-visible validation', () => {
+    const prompt = createDesignerAgent('test/model').config.prompt as string;
 
-    expect(replacement.config.prompt).toBe(
-      'replacement orchestrator prompt\n\norchestrator append prompt',
+    expect(prompt).toContain(
+      'Run only validation assigned by the Orchestrator; do not broaden it',
     );
-    expect(appended.config.prompt).toEndWith('orchestrator append prompt');
+    expect(prompt).toContain('Report validation results and skips accurately');
+    expect(prompt).toContain('Assigned validation should be user-visible');
   });
 });

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

@@ -129,24 +129,13 @@ Review available agents and lane rules. Before beginning non-trivial work, ident
 - 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.
+- Every delegation names a validation owner and allowed scope.
 
 ## 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
-- 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.
@@ -195,30 +184,9 @@ Balance: respect dependencies, avoid parallelizing what must be sequential, and
 - Do not leave \`task_id\` empty when intending to reuse; omitted or empty \`task_id\` creates a new specialist session.
 
 ## 6. Verify
-- Define the observable success criteria from the user's request.
-- 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.
+- Reconcile all writer lanes before final validation.
+- Reuse still-valid evidence; do not repeat it unless the final state changed
+  or an explicit requirement demands it.
 
 </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?
-- What focused evidence would reveal a behavior change in the final state?
+- What proportionate final-state verification will reveal a behavior change?
 
 ### 2. Follow Project Conventions
 
@@ -108,9 +108,8 @@ Make one simplification at a time.
 For each simplification:
 
 1. Make the change
-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
+2. Use the proportionate final-state verification plan to check preservation
+3. Keep it only when the evidence supports preservation
 
 Separate refactoring from feature work whenever possible.
 
@@ -130,16 +129,8 @@ After simplifying, confirm:
 - Favor explicit names and smaller focused helpers when they improve readability
 - Keep refactors tightly scoped to the task or review feedback
 
-## Final-state verification budget
+## Final-state verification
 
-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.
+Use a proportionate final-state verification plan for the final diff. Run checks
+required by repository and release instructions; add or repeat evidence only
+when the changed scope or a stated uncertainty warrants it.

src/skills/verification-planning/SKILL.md

@@ -39,17 +39,12 @@ 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.
+At the final state, state the distinct claims, assign one owner to establish or
+refute each, and choose the minimum non-duplicative evidence that covers the
+claims and important boundaries. Reuse evidence only while its relevant code,
+inputs, environment, and state remain valid. Required repository and release
+checks still apply; broaden or repeat verification only when a stated condition
+justifies it.
 
 ## 3. Create a verification affordance when needed
 

src/skills/worktrees/SKILL.md

@@ -135,17 +135,13 @@ keeps them readable to OpenCode.
 
 ### Phase 3: Integration & Validation
 Before merging or integrating the worktree branch:
-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
+1. Apply a proportionate final-state verification plan to the changed behavior
+   and its important boundaries. Run checks required by repository or release
+   instructions.
+2. Generate and display a clear diff comparing the worktree branch to the
    integration base branch.
-4. Ask the user for confirmation to integrate.
-5. Perform the approved integration, such as merge or cherry-pick, from the main
+3. Ask the user for confirmation to integrate.
+4. Perform the approved integration, such as merge or cherry-pick, from the main
    checkout or the user-approved integration checkout.
 
 ### Phase 4: Cleanup & Pruning