fix(orchestration): restore controller-owned review authority

references/assets/orchestration/contract/handoff-executor-result-v1.md

@@ -6,7 +6,7 @@ The agent-authored semantic content records implemented scope, changed paths, fo
 
 An executor result never issues a product verdict. It contains no implementation-review decision, accepted-result decision, final-audit conclusion, repair recommendation, or knowledge-write authorization. A distinct reviewer compares the exact frozen implementation directly with the verified specification and plan.
 
-Before creation or transition, validate the entire schema, identity, plan/task bindings, canonical path, collision state, and requested lifecycle operation. Write one artifact atomically. After creation, perform only lightweight integrity checks and rebuild the disposable index projection. If an index update fails after the canonical write, report the partial effect truthfully.
+Before creation, active repair, or transition, validate the entire schema, identity, plan/task bindings, canonical path, and requested lifecycle operation. Create or repair the active artifact atomically at the same canonical identity; allocate a new identity only for a genuinely distinct result, and never rewrite a transitioned result. After the write, perform only lightweight integrity checks and rebuild the disposable index projection. If an index update fails after the canonical write, report the partial effect truthfully.
 
 Missing or defective executor-result structure blocks continuation that requires that artifact. It does not veto direct product review when the exact implementation candidate, verified specification/plan, and claim-relevant observations are independently available.
 

references/assets/orchestration/contract/plan-v1.md

@@ -10,6 +10,8 @@ Assign parallel tasks only when dependencies are satisfied and write scopes are
 
 Every task declares `evidence_capability`. Use `mapped` with a lightest-capable task-local oracle for validation-bearing obligations, or `no_validation_bearing_obligation` with a concrete reason.
 
-Run canonical static task admission before semantic review. Structural success cannot establish source-ID coverage, appropriate decomposition, capable validation, or executability. A distinct reviewer compares the stored tree directly with the verified specification and current source evidence and issues `accept`, `repair`, or `blocked`.
+Run canonical static task admission before semantic review. Structural success cannot establish source-ID coverage, appropriate decomposition, capable validation, or executability. A distinct reviewer compares the complete stored tree directly with the verified specification and current source evidence and provides advisory `accept`, `repair`, or `blocked` findings. The controller/orchestrator assesses that advice and owns plan qualification. After a repair, review the complete current tree again; a previous opinion or a review of only the changed fields does not establish the accuracy of the current plan.
+
+`write-plan`, `write-phase`, and `write-task` update an existing active identity at its canonical path. Use a new identity only for a genuinely distinct plan, phase, or task, never to retain intermediate repair versions. Return a verified root plan to `draft` before changing phase or task content, then qualify the complete repaired tree through semantic review.
 
 The canonical semantic plan projection is `canonical-yaml-plan-tree-v1`. A status-only or append-only evidence change declared by the schema is excluded at the exact top-level control locations; all other semantics remain identity-bearing. Current plan and specification revisions do not consume post-execution review rounds.

references/assets/orchestration/contract/specification-v1.md

@@ -23,6 +23,8 @@ execution_workspace:
 
 The immutable `specification-v1` schema owns this structural front matter. The agent supplies the human-readable semantic body and semantic metadata, while `scripts/orch.py write-spec` owns family, schema version, identity, qualification, timestamps, canonical `.work-bundle/orchestration/spec/{state}/{id}.spec.md` location, atomic write, lifecycle movement, and index projection. Caller-authored structural overrides and filenames are invalid.
 
+`write-spec` updates an existing active specification at its canonical identity and returns repaired content to `draft`. Allocate a new identity only for a genuinely distinct specification, not for an intermediate review revision. A distinct reviewer then advises on the complete current specification against the original purpose, accepted authority, and workspace evidence. The controller/orchestrator assesses that advice and owns qualification; review of only the changed passages and an inherited earlier opinion are insufficient.
+
 The front-matter `source_knowledge` contains accepted authority only, as established by bounded retrieval and Source Context reconciliation. Each accepted entry carries a provenance `path` and the already-reconciled task-relevant `constraint`. Candidate, background, blocked, and superseded knowledge remains classified in Source Context or Open Questions and must not appear in this carried-authority list. Downstream planning allocates deterministic `AUTH-NNN` aliases by list order so executor packets remain traceable without exposing knowledge paths. The compiler resolves each allocated alias to `AUTH-NNN: <carried constraint>` in the task brief and review package.
 
 # Introduction

references/assets/orchestration/workflow.md

@@ -1,6 +1,6 @@
 # WorkBundle Orchestration Workflow
 
-WorkBundle separates semantic judgment from schema-owned mechanics. Agents interpret user purpose, accepted authority, product correctness, findings, qualification, and acceptance. Scripts validate schema, identity, bindings, canonical paths, scope safety, lifecycle transitions, immutable bytes, and disposable index projections.
+WorkBundle separates semantic judgment from schema-owned mechanics. Agents interpret user purpose, accepted authority, product correctness, findings, qualification, and acceptance. Scripts validate schema, identity, bindings, canonical paths, scope safety, lifecycle transitions, stored bytes, and disposable index projections.
 
 ## Shared foundation
 
@@ -10,11 +10,13 @@ Canonical artifacts are authority. Derived indexes are regenerable projections.
 
 ## Specification
 
-The agent authors complete specification semantics. The schema-backed writer owns structural fields, canonical location, immutable family identity, lifecycle movement, and index projection. A distinct reviewer judges user-purpose alignment, authority, requirement/constraint/interface/acceptance coverage, conflicts, open questions, and scope before the specification becomes verified.
+The agent authors complete specification semantics. The schema-backed writer owns structural fields, canonical location, immutable family identity, lifecycle movement, and index projection. A distinct reviewer advises on user-purpose alignment, authority, requirement/constraint/interface/acceptance coverage, conflicts, open questions, and scope. The controller/orchestrator assesses that advice and owns specification qualification.
 
 ## Planning
 
-The agent authors root-plan, phase, and task semantics from a verified specification. Each artifact cites exact source IDs. The plan assigns ownership, dependencies, write scopes, task-local methodology, validation capability, and completion criteria. Static admission may report structural and graph facts but cannot qualify the plan. A distinct reviewer judges decomposition and executability.
+The agent authors root-plan, phase, and task semantics from a verified specification. Each artifact cites exact source IDs. The plan assigns ownership, dependencies, write scopes, task-local methodology, validation capability, and completion criteria. Static admission may report structural and graph facts but cannot qualify the plan. A distinct reviewer advises on the accuracy, completeness, decomposition, and executability of the complete current tree; the controller/orchestrator assesses that advice and owns qualification.
+
+Repair current plan content at the existing canonical plan, phase, and task identities. Do not create active copies for intermediate review revisions. Return a verified plan to draft before child-content repair. After every repair, review the complete current tree against the verified specification and bounded source evidence; neither an earlier verdict nor a delta-only check qualifies the repaired content.
 
 Do not optimize task or phase cardinality. Bound expected total orchestration cost at concrete independently owned production, dependency, validation, review, and repair seams. Every authoritative production path needs a production owner. Keep a coherent mechanical increment with one owner, oracle, and repair frontier together. Create phases only for an actual barrier or convergence boundary and reject speculative splits. When a task is materially under-decomposed, return to the plan and reslice only the affected region; do not repeatedly enlarge it.
 
@@ -24,25 +26,25 @@ Disposable task briefs and lightweight development plans compile accepted author
 
 Executors work only within bound task/repository/write scope. Behavior changes use task-local methodology and claim-relevant focused validation. Executors report facts; they never accept the product.
 
-After execution, create one canonical `executor-result-v1` under the catalog-selected result location. It records implemented scope, changed paths, focused validation observations, unresolved product blockers, task fit, repository/CodeGraph facts, delegation, and knowledge disposition. Structural validation, collision checks, and binding checks occur before mutation. Historical handoffs, embedded statuses, override sidecars, and fallback indexes are unsupported and ignored.
+After execution, create one canonical `executor-result-v1` under the catalog-selected result location. It records implemented scope, changed paths, focused validation observations, unresolved product blockers, task fit, repository/CodeGraph facts, delegation, and knowledge disposition. Necessary structural and binding checks occur before mutation. Repair the active result at the same identity; do not retain intermediate revision copies. Historical handoffs, embedded statuses, override sidecars, and fallback indexes are unsupported and ignored.
 
 ## Direct implementation review
 
 Freeze an exact commit or worktree candidate using a path-sorted changed-path manifest. A distinct reviewer compares the actual candidate directly with the verified specification and canonical plan, every planned feature and acceptance obligation, edge and failure behavior, and capable focused observations.
 
-The reviewer issues `accept`, `repair`, or `blocked` from product correctness. Passing tests cannot hide missing behavior. Missing or defective historical artifacts, indexes, knowledge state, or controller ceremony are separate supporting-state defects unless they make the product ambiguous, unsafe, inaccessible, or impossible to review. Store the decision in one canonical `implementation-review-v1`.
+The reviewer issues an advisory `accept`, `repair`, or `blocked` assessment from product correctness. Passing tests cannot hide missing behavior. Missing or defective historical artifacts, indexes, knowledge state, or controller ceremony are separate supporting-state defects unless they make the product ambiguous, unsafe, inaccessible, or impossible to review. Store the advice in the current canonical `implementation-review-v2`; its `verdict` field is a recommendation, not orchestration authority. A complete re-review after repair updates that active identity instead of retaining intermediate verdict copies.
 
 Reviewer execution may use read-only workspace isolation and transient provider diagnostics. Those operational facts do not become semantic or lifecycle authority and are not replayed by downstream consumers.
 
 ## Accepted continuation
 
-After an accepted implementation review when required, create one canonical `accepted-task-result-v1`. It references the exact executor result, accepted implementation review, current validation outcomes, product identity, unresolved material defects, and knowledge disposition. Dependencies and final review consume this compact decision without redispatching the executor or reconstructing review history.
+After assessing the implementation review advice, the controller/orchestrator either routes repair/blocking or creates one canonical `accepted-task-result-v1`. It references the exact executor result, implementation review advice when required, current validation outcomes, product identity, unresolved material defects, and knowledge disposition. Repair its active identity in place. Dependencies and final review consume this compact controller decision without redispatching the executor or reconstructing review history.
 
 ## Final workflow review
 
-A distinct final auditor performs one compact pass over plan/task coverage, accepted implementation verdicts, relevant current tests, unresolved material defects, final knowledge disposition/return, repository finalization facts, and truthful archive readiness. The auditor does not reread source for code quality or repeat implementation review.
+A distinct final auditor performs one compact advisory pass over plan/task coverage, controller-accepted implementation decisions, relevant current tests, unresolved material defects, final knowledge disposition/return, repository finalization facts, and truthful archive readiness. The auditor does not reread source for code quality or repeat implementation review. The controller/orchestrator assesses that advice and owns the closure decision.
 
-Store the verdict in one canonical `final-workflow-review-v1`. Deterministic finalization carries that supplied verdict and validates only canonical references, lifecycle state, clean baselines, archive destinations, index rebuilds, and binding release. Mechanical failure cannot manufacture or reinterpret a semantic verdict.
+Store or repair the controller/orchestrator closure decision at one active canonical `final-workflow-review-v1` identity. Deterministic finalization carries that supplied decision and validates only canonical references, lifecycle state, clean baselines, archive destinations, index rebuilds, and binding release. Mechanical failure cannot manufacture or reinterpret a semantic decision.
 
 ## Knowledge disposition