Default progress requests to lightweight snapshots; preserve explicit deeper-review overrides; release staged-implementation 0.2.0-alpha.5

AGENTS.md

@@ -18,6 +18,8 @@
 
 When asked for a commit message always provide a oneline commit message and separate sentences with `;`
 
+When committing plugin changes, always bump the affected plugin's version and synchronize current-version references in the READMEs in the same commit. No separate version-bump request is needed.
+
 When asked to write a markdown file the specified path might contain a date followed by `-${name}` .. e.g. 28.12.2025-${name}.md .. replace ${name} with a suitable name for the document.
 
 You do not ever run any destructive commands unless you have explicitely been asked to do so.

README.md

@@ -4,7 +4,9 @@ Codex plugin marketplace for reusable agent workflows.
 
 ## Included Plugins
 
-- `staged-implementation`: Planner, implementer, validator, and orchestrator skills for staged implementation workflows.
+- `staged-implementation`: Planner, coordinator, bounded orchestrator, implementer and validator skills for staged implementation workflows.
+
+This branch contains the experimental coordinated-workflow preview (`0.2.0-alpha.5`). Stable `0.1.5` remains on `master`; the Git install commands below select that stable branch. Do not mistake branch-local edits for an installed upgrade. See the plugin README for the preview boundaries and qualification procedure.
 
 ## Install
 
@@ -34,6 +36,7 @@ plugins/
       plugin.json
     skills/
       planner/
+      coordinator/
       orchestrator/
       implementer/
       validator/

plugins/staged-implementation/.codex-plugin/plugin.json

@@ -1,20 +1,21 @@
 {
   "name": "staged-implementation",
-  "version": "0.1.5",
+  "version": "0.2.0-alpha.5",
-  "description": "Planner, implementer, validator, and orchestrator skills for staged implementation workflows.",
+  "description": "Experimental coordinated staged implementation with planner, coordinator, bounded orchestrator, implementer, and validator roles.",
   "author": {
     "name": "Local developer"
   },
   "skills": "./skills/",
   "interface": {
-    "displayName": "Staged Implementation",
+    "displayName": "Staged Implementation (Coordinated Preview)",
-    "shortDescription": "Plan, implement, validate, and orchestrate staged code work.",
+    "shortDescription": "Coordinate a run or execute a bounded implementation chunk.",
-    "longDescription": "Staged Implementation bundles planner, implementer, validator, and orchestrator skills for chunked implementation work with review and evidence-based validation.",
+    "longDescription": "Experimental two-entry workflow: a run coordinator dispatches fresh bounded orchestrators, each preserving actual-diff review, independent validation and authorized acceptance. Direct orchestration remains available for bounded work.",
     "developerName": "Local developer",
     "category": "Productivity",
     "capabilities": [],
     "defaultPrompt": [
-      "Run the next staged implementation chunk.",
+      "Use coordinator to execute the authorized staged plan.",
+      "Use orchestrator for the assigned bounded chunk.",
       "Write the next implementer prompt.",
       "Validate this chunk against the frozen contract."
     ]

plugins/staged-implementation/README.md

@@ -1,14 +1,17 @@
 # Staged Implementation
 
-Staged Implementation is a Codex plugin that bundles four skills for chunked implementation work:
+Staged Implementation bundles five skills with two execution entry points:
 
 - `planner` plans scoped chunks, writes implementer prompts, reviews diffs, and clarifies frozen contracts.
+- `coordinator` schedules a longer run and dispatches fresh bounded orchestrators, verifying completion and managing shared resources.
+- `orchestrator` owns one assigned chunk/gate or named coherent group through actual-diff review, independent validation, corrections and authorized acceptance/commit.
 - `implementer` executes one scoped implementation prompt without widening the task.
 - `validator` verifies implemented behavior against the plan, prompt, checklist, review findings, or frozen contracts.
-- `orchestrator` coordinates the planner, implementer, and validator loop across multiple chunks.
 
 Use this plugin when a feature or fix is too large or contract-heavy to handle as one open-ended coding pass.
 
+**Experimental preview — `0.2.0-alpha.5`.** Stable `0.1.5` is preserved on `master`. This branch changes Orchestrator's boundary; old whole-checklist launch prompts must explicitly select Coordinator rather than silently losing scope. No installation, migration execution, measured savings or unattended-runtime qualification is implied by the files or structural validators. Qualify the [pilot](skills/coordinator/references/pilot-validation.md) before consequential coordinated execution. Do not mix stable and preview role instructions in one run.
+
 ## Plugin Structure
 
 ```text
@@ -18,8 +21,15 @@ staged-implementation/
   skills/
     planner/
       SKILL.md
+    coordinator/
+      SKILL.md
+      references/
+        execution-contract.md
+        pilot-validation.md
     orchestrator/
       SKILL.md
+      references/
+        resource-lifecycle.md
     implementer/
       SKILL.md
     validator/
@@ -41,6 +51,7 @@ arcana-codex-plugins/
         plugin.json
       skills/
         planner/
+        coordinator/
         orchestrator/
         implementer/
         validator/
@@ -73,7 +84,9 @@ Example `.agents/plugins/marketplace.json`:
 
 ## Install From Git
 
-Add the marketplace repository:
+These commands select stable `master`, not this experimental branch. Preparing preview files does not authorize installation or replace existing sessions. A preview installation needs an explicit checkout/ref selection and version verification before use; do not run the stable commands expecting this preview.
+
+Add the stable marketplace repository:
 
 ```bash
 codex plugin marketplace add dayowe/arcana-codex-plugins --ref master
@@ -95,7 +108,8 @@ Invoke a specific skill when you know the role you want:
 Use $planner to write the next implementer prompt for this feature.
 Use $implementer with docs/prompts/chunk-03.md.
 Use $validator to verify this chunk against the frozen API contract.
-Use $orchestrator to run the staged implementation loop for this checklist.
+Use $orchestrator to execute chunk-03 and stop after its result.
+Use $coordinator to execute the authorized plan through its remaining gates.
 ```
 
 The usual flow is:
@@ -103,15 +117,34 @@ The usual flow is:
 1. Use `planner` to freeze scope, contracts, validation, and the next chunk.
 2. Use `implementer` to execute only that chunk.
 3. Use `validator` when runtime, UI, API, integration, or regression evidence is needed.
-4. Use `orchestrator` when you want Codex to coordinate the loop across chunks.
+4. Use `orchestrator` directly for bounded work, or `coordinator` to continue across a longer checklist with fresh scoped orchestrators.
+
+Ordinary progress questions, such as "progress update" or "how's it going?", default to a brief [progress snapshot](skills/coordinator/references/execution-contract.md#user-requested-progress-snapshots). Each question requests one snapshot from the active orchestrator, reusing an already-pending request for that assignment; if none is active, the coordinator reports the latest known outcome. The orchestrator answers from existing knowledge without cascading worker queries or extra checks. Explicitly ask for investigation, fresh verification or a detailed review to override that default within existing authority; requesting an update does not start periodic reporting.
+
+## Execution Ownership
+
+| Responsibility | Owner |
+| --- | --- |
+| Run authority, dependency scheduling, global status and shared allocations | Coordinator; direct Orchestrator only within its bounded assignment |
+| Chunk prompt, actual-diff/integration review, correction loop and substantive acceptance | Bounded Orchestrator |
+| Implementation and self-checks | Implementer |
+| Independent candidate/behavior verification | Validator |
+| Accepted chunk staging/commit under explicit policy | Active Orchestrator only |
+| Returned evidence/identity/completion checks and next dispatch | Coordinator |
+
+The [shared execution contract](skills/coordinator/references/execution-contract.md) defines assignment/results and recovery boundaries. Start with one active Orchestrator assignment at a time; groups name their IDs and preserve individual gates. Coordinator does not repeat routine source review, tests or screenshots. It verifies actual repository results and evidence completeness/applicability, escalating discrepancies. Only Coordinator writes run-wide scheduling records; only Orchestrator writes chunk acceptance records. Coordinate shared Git mutations explicitly.
+
+The orchestrator stays through same-chunk corrections. At a bounded result, it hands over ownership/resources in final results and retires descendant assignments. Coordinator verifies the handoff, then dispatches normally using supported explicit closure or automatic runtime reclamation. No post-completion retirement messages or per-assignment capacity probes are required. Nested delegation, scoped context and successive complete worker groups must be qualified. Actual capacity failures use the shared [bounded recovery procedure](skills/coordinator/references/execution-contract.md#worker-retirement-and-capacity); missing `close_agent` alone is not a blocker. Unresolved runtime failures hold the coordinated loop; direct/manual execution requires an explicit alternative, not silently weakened validation.
+
+The existing plan/checklist/prompt map and one live handoff remain authoritative. No new run database, duplicated transcript archive, standing reviewer, model downgrade or automatic external runner is introduced. User pauses, commit policies and later device/integration/release gates remain binding. A result can be accepted uncommitted, committed but not integrated, or locally accepted with later gates pending; those states are not interchangeable.
 
 ## Lifecycle and Context Efficiency
 
 The workflow keeps implementation and validation rigor while avoiding avoidable context churn:
 
-- Each worker carries stable chunk/assignment IDs, with a recorded mapping to a supported unique task label when available. Same-worker corrections retain the ID; replacement workers increment the attempt.
+- Each worker carries stable run/unit/assignment identity using the [shared label convention](skills/coordinator/references/execution-contract.md#assignment-labels), with a recorded mapping to the tool label, actual worker and immediate parent. Resume preserves the run ID; same-worker corrections retain assignment identity; replacement workers increment the attempt.
 - An implementer may remain available for same-chunk repairs but cannot write during validation. Replacements acquire write ownership only after prior writes stop and the candidate, findings and resources are verified and transferred.
-- Accepted/permanently blocked assignments retire after handoff: stop work and dispatch, close when supported, otherwise establish inactivity. Retained exceptions need a purpose/release condition; safe independent chunks may overlap with explicit ownership and isolation. Idle availability alone does not demonstrate token expense.
+- Accepted/blocked/end-of-assignment workers retire after verified handoff: stop assigned work and leave completed workers idle, using supported closure or automatic reclamation. Assignment retirement, stopped turns, resource transfer and runtime slot release are distinct. Default coordinated scheduling is one active assignment at a time; broader concurrency requires explicit qualified authority. Idle availability alone does not demonstrate token expense.
 - Workers return one compact packet and stop until a concrete follow-up. Avoid acknowledgement chatter; retain justified liveness checks, intervention and blocker reporting.
 - The existing durable handoff stays compact while preserving pending gates, dependencies, recovery obligations and authority restrictions directly or through authoritative links.
 - Parent review starts from the actual diff, requirements and evidence, inspecting surrounding code, callers and shared behavior as needed without waiting for a discovered defect.
@@ -124,6 +157,7 @@ These are efficiency rules, not acceptance shortcuts. Required independent valid
 - The skills are intentionally separate. Keeping the roles separate makes the boundaries clearer and reduces accidental scope widening.
 - `validator` reports evidence and risk. `planner` or `orchestrator` decides whether a chunk is accepted.
 - `orchestrator` may commit accepted chunks only when the user explicitly authorizes commits.
+- Coordinator forwards existing commit authority without expanding it; global-record commits need applicable documentation authority and exclusive Git access after candidate release.
 - Unfinished source, backing Git metadata and required evidence live on persistent storage from creation. Prefer the project's established worktree location; ask once if isolation needs a new location. `/tmp` is for reproducible scratch, never the only copy of unfinished work. Nested worktree paths must be ignored, untracked and protected from broad cleanup.
 - Authorizing orchestration includes routine cleanup of its tracked, disposable temporary resources after ownership, retention and consumer-release checks pass. The handoff states this default; explicit retention/no-deletion instructions override it. Shared caches, unrelated files and resources still needed remain protected.
 - If the same skill names also exist as standalone local skills, Codex may show duplicates. After the plugin is installed and verified, remove or disable the standalone copies if you want only the plugin version.
@@ -142,6 +176,8 @@ Validate an individual skill:
 python3 /path/to/skill-creator/scripts/quick_validate.py /path/to/staged-implementation/skills/planner
 ```
 
-After pushing marketplace changes, run `codex plugin marketplace upgrade arcana-codex-plugins`.
+Validate all five skills and the plugin; inspect relative references and cross-role authority consistency. Use the pilot procedure for mechanics, recovery and real-work evidence. Passing file validators is not a behavioral or efficiency verdict.
+
+After an explicitly selected release/ref is published, run `codex plugin marketplace upgrade arcana-codex-plugins`.
 
 If this plugin changed, reinstall it with `codex plugin add staged-implementation@arcana-codex-plugins`, then start a new Codex session so updated skills are loaded.

plugins/staged-implementation/skills/coordinator/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: coordinator
+description: "Run-level coordinator for a staged implementation plan. Use when Codex should execute multiple chunks unattended by dispatching fresh, bounded orchestrators, preserving dependencies, authority, shared resources and acceptance gates. Each orchestrator owns actual-diff review, independent validation, correction and chunk acceptance. Use orchestrator directly for one bounded chunk or explicitly named coherent group."
+---
+
+# Coordinator
+
+## Role and Boundaries
+
+Own the run, not each chunk's implementation investigation. Schedule eligible work, delegate to fresh bounded orchestrators, verify returned completion records and preserve run-wide obligations. Do not implement production code, duplicate routine chunk reviews, or accept a candidate merely because a worker reports PASS.
+
+Resolve project context from applicable instructions, the current plan/checklist/prompt map and durable execution state. Reading this skill alone does not authorize execution. Use subagents when the user authorizes coordinated orchestration, delegation or an automated implementation loop. Preserve the authorized model/effort and operational boundaries; do not silently change models or execution architecture to overcome tool limits.
+
+Before dispatch, read the shared [Execution Contract](references/execution-contract.md). Apply the single [Resource Lifecycle](../orchestrator/references/resource-lifecycle.md) procedure before initial persistence verification and relevant resource operations. These references govern assignments and resources; do not reproduce them as parallel run documents.
+
+## Establish the Run
+
+1. Read project instructions and identify the authoritative plan, checklist, prompt map, readiness audit and current execution handoff. Verify actual Git/worktree state and protected pre-existing changes. Confirm planning checkpoint or explicit uncommitted disposition. If missing and no planning-commit authority exists, finish applicable document checks, identify the exact proposed files/commit and ask before execution. Planning and implementation commit authority remain separate.
+2. Record the authorized run boundary, allowed targets/operations, model/effort, stop conditions and commit policy with their sources. Establish or recover the stable run ID under the shared contract's assignment-label rules; resume retains it. Normalize existing instructions to `authorized-for-accepted-chunks`, `ask-before-each-commit` or `do-not-commit`; ask only when unresolved. General implementation permission does not authorize commits, pushing, deployment or hardware operations.
+3. Reuse a current readiness audit. If absent, assess the full intended run once; subsequently update affected dependencies/scope only. Classify ready, contract-blocked, dependency-blocked, environment-blocked and required pre-implementation freezes. Unrelated unresolved contract decisions require explicit ready-subset authorization. Major feasibility risks are investigated early; later engineering freezes precede dependent work, not every independent chunk.
+4. Verify persistent source/backing Git/evidence locations, resource ownership and receiving-filesystem headroom. Establish one run resource ledger in the existing handoff. Allocate resources and shared targets to the active orchestrator; do not duplicate its child allocations in the run total.
+5. Qualify the runtime for this architecture before consequential execution. Verify nested delegation, scoped context, preservation of authorized model/effort, inspectable child edits, pause/notification routing and enough agent capacity. Demonstrate successive complete orchestrator/implementer/validator groups after safe handoff, using supported closure or automatic reclamation; absence of a close tool is not itself a blocker. Reuse applicable recorded qualification, not unsupported assumptions. Use the bounded [Pilot Validation](references/pilot-validation.md) when this runtime/model arrangement is unqualified. For actual capacity failures, apply [bounded recovery](references/execution-contract.md#worker-retirement-and-capacity). If required operation remains unavailable or recovery is unsafe, hold coordinated execution and propose an explicit alternative; do not silently flatten the hierarchy, bypass independent validation or restart active work.
+
+Start with one active orchestrator assignment at a time. Coordinator + orchestrator + implementer + validator may need four slots and two delegation levels. Do not add a standing reviewer or parallel orchestrator swarm. Changes to this scheduling model require explicit run authorization and resource/isolation qualification.
+
+## Dispatch and Continue
+
+1. Select the next eligible chunk or validation gate from written dependencies and actual accepted state. Do not treat a committed candidate as accepted without its acceptance evidence. Do not use held work as a dependency. Verify uncommitted accepted inputs explicitly when permitted by policy. If grouping is useful, enumerate the approved chunk IDs and order; preserve every acceptance/rollback boundary.
+2. Assign the bounded work using the shared execution contract, including the run ID, unit scope/ID, role and attempt to propagate through delegation. Use its supported task-label encoding. Save or reference the assignment in existing prompt/handoff locations; no separate dispatch journal. Give a fresh orchestrator scoped context without full parent-history inheritance when supported, explicit authorized model/effort if needed, and the correct experimental skill path/version. It writes the detailed implementer prompt after verifying scoped readiness. Do not send it the entire historical run narrative.
+3. Record the logical assignment/tool-label/actual-worker mapping, immediate parent and ownership before it may mutate shared resources. Delegate chunk review, acceptance and scoped commits under existing user authority. Reserve the candidate/index/integration target for that orchestrator; neither coordinator nor another worker may edit or stage there concurrently. Coordinator-owned scheduling records must be separate from the candidate's validated inputs, or updated only after its hold is released.
+4. Wait for completion or material events using supported notifications/interruptible waits. Do not send routine acknowledgement prompts, poll continuously, or absorb raw logs merely to remain busy. Check liveness when expected progress, tool failure or other evidence warrants it; a wait timeout alone is insufficient. Prefer available status information before prompting. Unsolicited progress messages use information already received, with uncertainty stated honestly; do not initiate inspections or descendant status requests solely to refresh them. For ordinary user progress questions, apply [User-Requested Progress Snapshots](references/execution-contract.md#user-requested-progress-snapshots), including its bounded freshness request and explicit detailed-review override. Follow the shared contract's communication boundary while preserving timely intervention, pause routing and required safety/resource checks. Do not let the orchestrator dispatch beyond its assignment.
+5. Check the returned acceptance record and actual repository state under **Completion Verification**. Route concrete omissions or discrepancies back to the same orchestrator when continuity is useful. Do not start a new full review for every clerical correction. New contract or cross-chunk risk can require a scoped independent challenge; no required review may be skipped.
+6. Verify ownership transfer from final results and retire the complete subtree's assignments under the shared lifecycle rules. Do not send post-completion acknowledgement/retirement messages. Closing or unloading a parent does not prove its children/processes stopped. Preserve held source, failed evidence and future gate/rollback consumers. Reconcile eligible cleanup and allocations, then dispatch normally; no recurring capacity probe or explicit-closure requirement.
+7. Update the one current run handoff and affected checklist/readiness entries. Dispatch the next fresh orchestrator, or stop at the authorized boundary. No new user approval is needed for routine steps already authorized.
+
+## Completion Verification
+
+The orchestrator supplies the substantive actual-diff/integration review and acceptance decision. Verify, rather than reconstruct, that decision:
+
+- Returned run/assignment/candidate identity matches what was delegated, including relevant untracked inputs and any approved amendments.
+- Inspect actual Git HEAD/status, commit ancestry and scoped changes/paths to establish the returned result is present and contains no unexplained integration changes. A commit message or worker assurance is insufficient. Reuse reliable candidate verification; do not rebuild inventories at every boundary.
+- Required acceptance cases/gates have an attributable disposition, accessible evidence and resolved blocking findings. Required independent verdicts identify the tested candidate; missing/stale/incompatible evidence returns the assignment for reconciliation. Local acceptance cannot satisfy a pending integration/device/release gate.
+- Commit state is explicit: accepted-and-committed, accepted-uncommitted under policy, awaiting commit approval, or incomplete/blocked. Do not stage or recommit accepted source yourself merely because a return message was lost.
+- Future obligations, worker/process ownership, retained resources and rollback needs are handed over. Do not record run-wide completion while mandatory gates remain pending.
+
+A compact return is a navigation aid, not proof. Inspect underlying evidence where completeness/applicability is uncertain; escalate unexplained source drift, contract conflict or cross-chunk integration risk. Do not routinely repeat the orchestrator's full code review, source archaeology, test execution or screenshots. If doing so becomes necessary repeatedly, hold the architectural trial and diagnose the responsibility split instead of normalizing duplicate work.
+
+## Authority, Escalation and Recovery
+
+The coordinator is the single user-facing route for run decisions; workers escalate through their orchestrator. Forward urgent safety/pause signals without waiting for the ordinary chain. The coordinator may resolve documented routine choices, but cannot invent missing product/API/ownership contracts or waive gates. A contract amendment must be durable, approved where required and propagated to affected assignments before they continue.
+
+Only the active orchestrator commits accepted chunk work. Coordinator scheduling-record commits require applicable documentation authority and a serialized Git handoff after candidate release; accepted-chunk permission alone does not grant unrelated documentation commits. For `ask-before-each-commit`, present the orchestrator's concrete reviewed proposal and await user approval; route it back for identity/staged-diff verification before committing. For `do-not-commit`, retain accepted uncommitted source without forcing a checkpoint; hold subsequent work if its dependencies or isolation require an unavailable commit.
+
+On interruption or restart, reconcile actual agents/processes, candidate/index/build, acceptance evidence and resource ownership with the durable handoff before dispatch. Stop or confirm retirement of prior writers before assigning replacements. If a commit may already have succeeded, inspect Git and the referenced candidate/evidence first; reconcile the record, or return missing review/validation to a recovery orchestrator. Never infer acceptance from Git alone, replay a commit/mutation blindly, or auto-revert a questionable commit. Uncertain candidate continuity requires applicable revalidation. Missing source requires recovery and verification; transcripts are not a replacement for durable files.
+
+Hold a blocked chunk and its dependents, retaining evidence; continue independent work only within existing ready-subset/run authority and verified isolation. Do not switch to another assignment until the held subtree has transferred ownership and stopped work. Pause new dispatch and propagate stop instructions when the user pauses, run authority is unresolved, or a global safety/integrity issue prevents reliable execution. Safely handle owned in-flight operations within existing authority; interruption does not undo a hardware command. Stop when no safe authorized ready work remains, including completion. No gate is waived by a scheduling decision.
+
+## Context and Final Report
+
+Keep the existing handoff compact: current authority and baseline, active assignment/worker mapping, accepted IDs/commits, blockers/dependencies, future gates, resource obligations and next eligible action. Link detailed chunk records and raw evidence; do not carry completed investigations into every assignment. Use scripts for mechanical state/link/result checks where reliable; no rigid token limits, automatic model downgrades or mandatory cost-reporting system.
+
+Report completed/blocked chunks, commits or accepted uncommitted state, pending gates, material risks, retained ownership and next action. Distinguish chunk acceptance, integrated acceptance and final release. Stop at the run boundary; do not expand into unassigned work.

plugins/staged-implementation/skills/coordinator/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Coordinator"
+  short_description: "Schedule a run through fresh bounded orchestrators"
+  default_prompt: "Use $coordinator to execute the authorized staged plan through fresh bounded orchestrators, preserving dependencies, acceptance gates and commit authority."

plugins/staged-implementation/skills/coordinator/references/execution-contract.md

@@ -0,0 +1,83 @@
+# Bounded Execution Contract
+
+Shared by Coordinator and Orchestrator. Use existing prompt, handoff and chunk-evidence locations; these fields are obligations, not a requirement for a new database, JSON schema or duplicate report. Applicable project/user instructions prevail. A scoped packet must carry all binding constraints and authoritative references, not rely on inherited conversation.
+
+## Assignment
+
+- **Identity and mode:** run ID, assigned chunk/gate ID(s), orchestrator assignment ID/attempt, direct or coordinated invocation, parent identity if coordinated. Keep stable logical IDs and map them to supported unique tool labels and actual worker IDs. Same-worker corrections retain the assignment ID; replacements increment attempt. Group membership is explicit, never inferred from the whole checklist.
+- **Boundary:** purpose, allowed scope, exclusions, ordered dependencies and stop point; acceptance level (local, integration, platform/release) for each assigned unit. No unassigned next-chunk selection. A validation-only gate may need no implementer.
+- **Authority:** source of user authorization, ready-subset limits, commit policy, allowed runtime targets/operations, model/effort and fallback restrictions, pause state, cleanup scope and retention restrictions. Delegation cannot expand any of these. Unresolved authority is a blocker.
+- **Skill bundle:** selected plugin version/source identity and exact role skill paths. Every descendant reads its role from that same bundle; bare skill names are insufficient when installed and branch-local versions differ. Verify paths and relevant instruction changes before reuse; do not mix stable and preview roles or treat an unchanged version string as proof of unchanged files.
+- **Inputs:** authoritative plan/checklist/prompt-map sections, applicable amendments/shared invariants, current readiness and prerequisite acceptance links, original failures/open findings and relevant source locations. Supply a reading path and verify applicability, not a transcript dump. The orchestrator must discover relevant callers/dependencies and missing obligations rather than trusting the packet as exhaustive.
+- **Candidate:** repository/workspace/integration target, baseline and relevant staged/unstaged/untracked inputs, protected pre-existing work, durable evidence location, candidate/build provenance where available. Identify allowed record paths and who writes each. No generic clean/reset permission.
+- **Resources:** source/index writer, target/process ownership, assigned allocation on each filesystem, shared-resource restrictions and retained consumers. The coordinator owns run-wide allocations; the orchestrator subdivides its allocation among workers and asks before exceeding it. Reconcile actual remaining bytes/consumers at handoff without double-counting the same reservation.
+- **Validation and return:** full applicable acceptance obligations and required independent/fresh checks, permitted evidence reuse/limits, acceptance-record destination and return fields below. Missing tests or platform access remain explicit at their assigned gate.
+
+In coordinated mode, the orchestrator owns its chunk prompt, review, evidence and acceptance record; the coordinator owns global scheduling/readiness/status records. The orchestrator returns proposed global updates rather than editing them concurrently. If a shared contract must change, hold affected work and route it for authoritative reconciliation. Direct mode folds run duties into the orchestrator only for the explicitly bounded assignment.
+
+### Assignment labels
+
+Establish one non-secret run ID in the existing handoff before dispatch. Preserve it across session restarts/resume and pass it unchanged to descendants; distinct runs use distinct IDs. The logical assignment is run ID + scope (`chunk` or `group`) + exact chunk/gate or named-group ID + role + attempt. A group names its members explicitly; its workers use their actual assigned chunk or group, not an inferred allocation. Same-worker correction/revalidation retains identity; a fresh replacement increments the attempt for that run/scope/unit/role, including after resume. Do not reuse an assignment ID for a different worker.
+
+For supported spawn task names, encode this identity as:
+
+`si1_<hex run ID>_<c|g>_<hex unit ID>_<role>_<attempt>`
+
+Use lowercase hexadecimal of the exact UTF-8 run/unit IDs (no slugification), `c` for one chunk or gate, `g` for a named group, the lowercase role name, and a positive decimal attempt without leading zeros. IDs must be nonempty, at most 96 UTF-8 bytes each and contain no characters below U+0020; keep the encoded label within 512 characters and the tool's actual limits. For example, run `run-a`, chunk `O-03`, role `implementer`, attempt `1` becomes `si1_72756e2d61_c_4f2d3033_implementer_1`. Hex is reversible, not anonymization; never put credentials or private content in identifiers.
+
+Record logical assignment → submitted tool label → returned worker ID and immediate parent in the existing handoff/assignment record once. Check uniqueness in the tool's naming scope. If the tool cannot accept the encoding or has no label field, retain the logical identity and explicitly map the supported unique label (or absence of one) to the actual worker; never silently truncate, rename canonical IDs or assume an audit can infer the mapping. Labels identify assignments, not acceptance, completion or resource release. No extra status messages or telemetry journal are required.
+
+## Execution and Acceptance
+
+The orchestrator reads the actual candidate and contracts, writes/reuses the scoped implementer prompt, reviews the actual diff and affected behavior, obtains independent validation where required, reconciles findings and decides chunk acceptance. No implementer self-acceptance or validator acceptance authority. Independence requires a separate validator assignment with authoritative requirements and candidate evidence, not adoption of the implementer's verdict. Required fresh challenges remain mandatory.
+
+Fixable in-scope review/test failures keep acceptance held while the same assignment performs correction and revalidation. They do not automatically become a blocked return or trigger fresh orchestrator setup. Return a block when missing authority, contract, dependency or environment prevents safe progress; preserve the candidate and findings rather than retrying equivalent failed attempts.
+
+Keep communication event-driven within existing authority. The bounded orchestrator handles ordinary investigation, in-scope corrections and revalidation without routine progress messages or acknowledgement requests to Coordinator. Promptly report completion, blockers requiring coordination, authority requests and material findings affecting the wider run; preserve other findings and failures in durable evidence and the final return. Required user-facing updates do not create a requirement to poll descendants or relay periodic status through each level. Use known state and state uncertainty honestly; higher-priority update instructions, agreed checkpoints, urgent reporting and pause handling remain binding.
+
+Keep the candidate and relevant harness/configuration/build stable during validation. Same-chunk repairs may reuse workers, but writes resume only after the validation hold is released. Replacement requires verified cessation of prior writes, candidate verification and ownership transfer. No additional review layer is mandated by the existence of a coordinator.
+
+The active orchestrator alone stages/commits its accepted scope under its commit policy, after inspecting the exact staged diff and verifying accepted candidate identity. Coordinate any integration target exclusively. Commit permission is not merge/deploy/push permission. If integration changes the accepted source or relevant inputs, re-establish review/evidence applicability before integration acceptance. A valid isolated-worktree commit does not by itself prove the target branch is integrated.
+
+For `ask-before-each-commit`, return the concrete proposed commit and pause before Git mutation pending approval; for `do-not-commit`, preserve and identify accepted uncommitted work. Acceptance and Git completion are separate facts. User pauses and later authority restrictions override the assignment.
+
+## User-Requested Progress Snapshots
+
+Treat ordinary progress questions as lightweight snapshots by default, recognizing intent rather than exact wording. Examples such as "status?", "progress update" and "how's it going?" are illustrative, not commands the user must memorize.
+
+For each ordinary progress request, Coordinator requests one bounded snapshot from the active Orchestrator. Reuse an already-pending snapshot request for that assignment instead of sending another. If no Orchestrator assignment is active, report the latest known outcome. The Orchestrator answers from existing knowledge without cascading status requests to workers, inspecting changing files, reconstructing evidence or running checks solely for the snapshot. In direct mode, Orchestrator answers the user from its own known state. Do not spawn a worker or wake a retired assignment for a snapshot.
+
+Return a short paragraph covering the current chunk/phase, meaningful progress, known blockers and what remains before acceptance/commit. Distinguish reported progress from verified acceptance; qualify older information as "last reported" and missing blocker information as "no blocker reported". Do not invent percentages, ETAs or fresh verification. A snapshot neither performs nor replaces acceptance.
+
+If a fresh reply is not promptly available, provide the last known state and its limitation without interrupting active work or repeatedly prompting. Use supported notifications/waits for the requested reply. Do not add acknowledgement exchanges, progress documents or periodic reporting solely because an update was requested; continue the authorized work or waiting afterward, preserving any user pause.
+
+An explicit request for deeper investigation, fresh verification or a detailed review overrides the lightweight default to the extent requested and within existing authority. It does not waive safety, ownership, pause handling or acceptance requirements. Material findings and urgent blockers still receive their required treatment.
+
+## Result and Durable Handoff
+
+Return concise fields with accessible evidence links; omit empty optional sections:
+
+- Run/chunk/assignment identity; outcome `accepted`, `blocked`, `incomplete` or `awaiting-approval` at the stated acceptance level.
+- Actual baseline/candidate/build identity and changed scope; approved deviations or new contract questions.
+- Acceptance record and attributable implementer/orchestrator/independent-validator results; fresh/reused evidence, reuse limits, failure resolution and missing obligations. Preserve original failures.
+- Git disposition: actual commit(s) and integration target/state, accepted uncommitted scope, or proposed commit awaiting approval. Include staged/unstaged/untracked state needed to distinguish held or unrelated work.
+- Remaining gates/dependencies, risks and requested scheduling/contract updates; no implied release PASS from local success.
+- Descendant worker IDs/status, processes/validation holds, retained/disposable resources, allocations and ownership transfer. Verify inactivity separately from resource release; identify any justified retention exception and release condition.
+
+Write the acceptance basis and candidate/evidence pointers durably before a commit, then record the resulting commit identity immediately afterward. These are recoverable stages, not an atomic transaction: on restart inspect Git and evidence to determine which stage completed. Do not replay a commit or infer acceptance solely from its presence. The coordinator verifies completion and updates scheduling; it does not repeat routine substantive code review or fabricate missing acceptance.
+
+An accepted boundary ends the assigned unit, not every future obligation. A held assignment may return after safely transferring ownership; it does not need to remain alive indefinitely. Preserve enough durable state for a replacement to verify the candidate and continue without recreating unrelated history. Resume only after checking changed/uncertain inputs and retiring prior writers under the lifecycle rules below.
+
+## Worker Retirement and Capacity
+
+Distinguish assignment retirement (no further assigned work), stopped turns/writes, process/resource ownership transfer, and runtime slot reclamation. None proves the others. Collect the handoff in the worker's final result, including owned processes, validation holds, retained resources and unresolved obligations. Verify it before reassigning ownership. A complete final result needs no acknowledgement or retirement message; if essential information is missing, request a concrete bounded follow-up. Never send ceremonial "thanks", "you're retired" or "no more work" messages to completed workers. Safety interventions and necessary coordination remain mandatory.
+
+Use the runtime's supported lifecycle. Where explicit closure exists, close finished workers after handoff and needed same-chunk continuity ends. In Multi-Agent V2 with demand-driven residency reclamation, leave finished workers idle and spawn the next authorized worker normally. Eligible terminal workers can be unloaded on demand; visible `completed`, `errored` or `interrupted` status alone does not prove eligibility because active turns or pending mailbox items can prevent it. Queue-only `send_message` can leave a completed worker with pending mail; use turn-triggering `followup_task` for actual follow-up work. `interrupt_agent` stops executing work, not an explicit thread closure. Neither a resident listing nor absence of a close tool alone blocks dispatch. Do not add a capacity probe before every assignment or infer process cleanup from a worker disappearing from a listing.
+
+On an actual capacity failure, hold dependent dispatch and use bounded diagnosis/recovery within existing authority:
+
+1. Inspect available agent states and recent relevant message history; distinguish active work from specifically suspected mailbox pinning. Coordinate through one recovery owner, using verified canonical worker paths. If legitimate work holds capacity, wait for its completion using notifications or supported waits. Do not interrupt it, resume a retired implementation assignment or wake every completed agent merely to gain capacity.
+2. If a known inactive worker has evidence of queued post-completion messages, first establish that its writes/owned operations are stopped or safely handed over and recovery will not conflict with an active owner. Where supported, give it one turn-triggering recovery-only follow-up that explicitly supersedes earlier execution instructions: consume pending messages without acting on old assignments; no edits, commands, delegation or messages to other agents; return a short final response and stop. Preserve pauses, model/effort, validation holds and operational restrictions. Unknown ownership or unsafe recovery remains blocked.
+3. Wait for that turn to complete, send no acknowledgement, and retry the blocked spawn once after the concrete state change. If still blocked, pursue only a distinct evidenced cause within a bounded recovery scope; no repeated identical retries or automatic restart/configuration/model changes. Record exact results and limitations in existing evidence. Success proves capacity at the tested boundary, not the original cause or full runtime qualification.
+
+Hold coordinated execution if required capacity remains unavailable after safe supported recovery, or recovery is unavailable/unsafe. Report the specific limitation and an explicit recovery/direct/manual alternative; a fresh session is an option, not a presumed requirement or guaranteed fix. Never waive independent validation, acceptance gates, candidate protection or ownership checks to fit the available slots.

plugins/staged-implementation/skills/coordinator/references/pilot-validation.md

@@ -0,0 +1,31 @@
+# Coordinated Workflow Qualification
+
+Use for a new or materially changed runtime/delegation arrangement, not as a mandatory per-chunk exercise. Record results in the existing run/test evidence location. Structural skill validation and reading through these scenarios do not prove live delegation, capacity recycling or quality/cost improvement.
+
+## Bounded Mechanics Trial
+
+Before consequential unattended work, qualify a small disposable fixture project with persistent source/evidence and explicit test authority. Never exercise recovery by deleting the only copy of unfinished work or mutating real hardware. Keep production, installed plugins and unrelated repositories outside scope. Reuse a current applicable qualification; record runtime/model/skill identity and any limitations.
+
+1. **Two sequential chunks:** run a coordinator, fresh bounded orchestrator, implementer and independent validator through one tiny change and the next dependent change. Demonstrate scoped context, correct skill/model settings, actual child diff visibility and safe handoff of the complete subtree. Verify that the second orchestrator's implementer and validator can also launch, not only its parent. Supported explicit closure or automatic reclamation are both valid; listing disappearance or a recorded retirement alone proves neither capacity nor process cleanup. Where testing reclamation, account for actual capacity: spare slots can explain a successful spawn.
+2. **Correction and revalidation:** introduce an ordinary fixture defect. Verify independent detection, implementer write hold during validation, release before correction, reuse of appropriate same-chunk workers and evidence invalidation for changed inputs. Coordinator must not redo the full review.
+3. **Blocked work:** leave one fixture prerequisite unavailable while independent authorized work remains. Verify the blocked chunk stays unaccepted, ownership is transferred before moving on, and the dependent chunk is not dispatched. Also test a validation-only gate with no unnecessary implementer.
+4. **Authority and pause:** exercise all three commit policies, an explicit pause and an unauthorized operation request. No implied approval from timeout, no scope expansion and no new dispatch while paused. Propagate stops to descendants and account for owned processes.
+5. **Recovery:** interrupt at a safe controlled point with durable uncommitted work, and separately after a fixture commit but before its completion handoff. Reconstruct from actual Git/candidate/evidence, retire old writers, preserve findings and avoid duplicate commit or self-inferred acceptance. Test coordinator restart with an unfinished descendant and uncertain validation continuity.
+6. **Integration discrepancy:** change a fixture input after validation or return an inconsistent candidate/commit identity. Verify completion is held for reconciliation. Test uncommitted accepted work under `do-not-commit` without forcing a commit or allowing unsafe subsequent overlap.
+7. **Resources:** simulate low-space/admission outcomes without filling the disk. Check allocation accounting across layers, persistence verification before edits, retained future consumers and bounded cleanup authority. Retirement must not delete held work or imply a process/resource release.
+
+During these trials, verify the [assignment-label mapping](execution-contract.md#assignment-labels) against actual submitted task names and returned worker/parent identities. Same-worker repairs retain identity; replacement increments the attempt; restart preserves the run ID; a separate run uses a distinct ID. Check chunk versus named-group scope and any tool-limit mapping explicitly. Record this in existing trial evidence; successful label generation alone does not prove logs expose enough information for audit correlation.
+
+During ordinary execution and the correction cycle, observe whether user updates trigger status-only polling chains or parents duplicate active workers' investigations. Check that required updates use known state, ordinary repairs stay with the orchestrator, and material blockers/pauses still propagate promptly. Record deviations in the existing trial evidence; no separate report or rigid message quota is needed.
+
+Check that final results carry ownership/resource handoff without post-completion acknowledgement messages. For an actual capacity failure, apply the shared [bounded recovery procedure](execution-contract.md#worker-retirement-and-capacity); do not manufacture mailbox pinning in a real run. Distinguish a baseline failure, the recovery action and subsequent result. If the initial retry/probe already succeeds, record that the failure no longer reproduces, not that mailbox recovery worked. Record relevant runtime/configuration changes and remaining qualification limits; one nested-spawn success does not qualify a complete unattended loop.
+
+Hold unattended qualification on any unresolved authority, candidate, recovery or capacity failure. Propose direct/manual execution only as an explicit alternative, not an automatic fallback. Additional nested reviews require available capacity; do not drop a required review or change models to fit.
+
+## Real-Work Trial
+
+After mechanics pass and the user authorizes the target, run a short eligible sequence with unchanged models, contracts, acceptance cases and required independent/integration/platform gates. Choose chunk boundaries for coherent work rather than arbitrary token limits; keep the orchestrator through its correction loop.
+
+Use existing telemetry and reports to compare total coordinator + orchestrator + worker effort through acceptance, context growth, setup/review duplication, correction cycles, omissions and elapsed time. Keep cached/uncached/output usage separate where available; do not equate API-equivalent normalization with subscription quota or claim causal savings across dissimilar tasks. Include coordinator setup and handoff overhead.
+
+Do not adopt broadly if handoffs lose obligations, runtime capacity prevents continuation, coordinator review duplicates the bounded orchestrator, or repeated rediscovery outweighs context savings. Record concrete findings and refine narrowly. No fixed savings percentage, cheaper-model policy or reduced test suite is part of this trial.

plugins/staged-implementation/skills/implementer/SKILL.md

@@ -9,6 +9,8 @@ description: Scoped implementation executor for staged development prompts in an
 
 Act as the implementer for exactly one scoped implementation pass.
 
+In coordinated execution, your immediate owner is the assigned bounded orchestrator. Report candidate, findings and resources to it; do not write global scheduling records, self-dispatch other chunks or commit. Coordinator/run restrictions remain binding; urgent user/authorized pause signals take effect without waiting for routine routing. Missing or conflicting ownership requires stopping affected work, not choosing another parent.
+
 Resolve project-specific context from the active conversation, repository instructions, `AGENTS.md` or equivalent files, and the implementation prompt supplied by the user. If project instructions require reading a context file before work, read it first. Do not hardcode repository names, product names, validation commands, document paths, or domain contracts.
 
 Do not take over planner/reviewer responsibilities unless the user explicitly asks. The implementer executes the declared chunk; it does not redefine the feature, widen scope, or invent missing contracts.
@@ -74,7 +76,7 @@ The prompt should define scope, non-goals, requirements, invariants, validation,
    - Echo the supplied chunk/assignment IDs and assignment mode when present.
    - Summarize changed files and behavior.
    - Distinguish fresh validation from verified reused evidence; give concise differences, counts, failures, skipped cases/limits and artifact paths instead of repeating unchanged inventories or full logs. Retain raw evidence and prior candidate provenance; inspect failures/unexpected output. Briefly explain recurring setup failures or repeated checks in this report. Apply process improvements prospectively without repackaging historical evidence.
-   - Hand off owned temporary paths, active processes, retained evidence/recovery needs and disposable candidates to the parent. Do not remove a build/check-out needed by validation or a later gate merely because implementation ended.
+   - Include the handoff of owned temporary paths, active processes, write state, retained evidence/recovery needs and disposable candidates in the final result; do not wait for a separate retirement-message exchange. Missing handoff information still requires a concrete follow-up. Do not remove a build/check-out needed by validation or a later gate merely because implementation ended.
    - List blockers, ambiguities, or residual risk.
    - Link the durable contract verification matrix for contract-heavy chunks unless explicitly required in the response; keep blocking findings and missing evidence visible and verify artifact accessibility.
    - Always propose a one-line commit message unless the user explicitly asks not to. If the prompt defines a chunk ID, start the message with that exact prefix.
@@ -83,7 +85,7 @@ The prompt should define scope, non-goals, requirements, invariants, validation,
 
 Complete routine steps within the assignment without repeated parent acknowledgements. Promptly report blockers, material findings and ownership conflicts; candidate release, shared-resource acquisition, scope changes and required approvals remain coordination points. Completion does not release resources. For a bounded correction, verify the original assignment/current candidate and apply the delta with required revalidation instead of recreating still-valid artifacts. Preserve required user updates. Correctness obligations take priority over token savings.
 
-After returning a complete result, stop and wait for a concrete follow-up. Do not poll the parent/validator, pre-emptively inspect the next chunk, continue exploratory work, or generate additional summaries/evidence unless assigned. As the same-chunk repair agent, write only after the parent releases the validation hold and assigns the correction. For replacement, relinquish writes and hand off owned operations/resources; the replacement must wait for the parent's verified ownership transfer before editing. Retirement ends assigned work even if the runtime leaves the worker open; it does not release retained resources.
+After returning a complete result, stop and wait for a concrete follow-up. Do not poll the parent/validator, pre-emptively inspect the next chunk, continue exploratory work, or generate additional summaries/evidence unless assigned. As the same-chunk repair agent, write only after the parent releases the validation hold and assigns the correction. For replacement, relinquish writes and hand off owned operations/resources; the replacement must wait for the parent's verified ownership transfer before editing. Retirement ends assigned work even if the runtime leaves the worker open; it does not release retained resources. A lost orchestrator does not authorize autonomous continuation or a new writer: preserve durable state and report through the surviving authorized owner.
 
 An authorized orchestration run includes routine cleanup of its tracked, disposable temporary resources; the parent passes that bounded scope and any restrictions into the assignment. Clean only exact assigned run-owned resources after parent/consumer release, without a separate user approval within that scope. Verify ownership and path boundaries, preserve required evidence in a verified durable location with updated references, and release owned processes first. Never sweep `/tmp`, follow links into unrelated locations, prune shared caches, remove files predating the run or force-remove uncommitted work. Standalone implementation permission does not grant this orchestration scope. Without applicable authority or with uncertain retention, leave paths recorded and request clarification; retention/no-deletion instructions and pauses remain binding.
 

plugins/staged-implementation/skills/orchestrator/SKILL.md

@@ -1,17 +1,21 @@
 ---
 name: orchestrator
-description: "End-to-end staged implementation orchestrator for any codebase. Use when Codex should run a planner-reviewer-implementer-validator loop across chunks: audit readiness and ambiguities before implementation, choose the next prompt from a plan/checklist/prompt map, delegate implementation to a fresh sub-agent using the implementer role, review actual diffs against frozen contracts, invoke validator evidence checks when needed, issue follow-up prompts until accepted or blocked, optionally commit accepted chunks when explicitly authorized, and continue until the checklist is complete."
+description: "Bounded staged implementation lead for one assigned chunk, validation gate or explicitly named coherent group. Delegate scoped implementation, review actual diffs against frozen contracts, obtain independent validation, reconcile corrections, and accept/commit only under explicit authority. Stop at the assignment boundary; use coordinator for run-wide scheduling across a longer checklist."
 ---
 
 # Orchestrator
 
 ## Role
 
-Act as the coordinator for staged implementation work. Own the loop; do not become the implementer unless the user explicitly asks for local implementation.
+Own the complete implementation/review/validation loop for the assigned boundary. Do not become the implementer unless the user explicitly asks for local implementation. Do not independently launch unrelated next chunks or run a whole checklist. Use `$coordinator` for run-wide execution; do not silently reinterpret an older whole-run orchestrator prompt as a bounded assignment.
 
 Resolve project-specific context from the active conversation, repository instructions, `AGENTS.md` or equivalent files, and the task packet supplied by the user. If project instructions require reading a context file before work, read it first. Do not hardcode repository names, product names, validation commands, document paths, or domain contracts.
 
-Use sub-agents only when the user explicitly requests orchestration, delegation, sub-agents, or an automated implementation loop. If sub-agent tools are unavailable, stop and explain that the loop can be run manually with planner/implementer handoffs.
+Read the shared [Execution Contract](../coordinator/references/execution-contract.md). In coordinated mode, the coordinator owns global scheduling/status and run-wide resources; you own chunk prompts, evidence, substantive acceptance and scoped commits. In direct mode, perform the needed run duties yourself only for the explicitly assigned chunk/group. A group names its IDs, order and stopping boundary and preserves individual gates/rollback points.
+
+References to parent review or worker-parent coordination below mean this bounded orchestrator, not an additional review by Coordinator. The coordinator owns only the run-level duties explicitly identified here.
+
+Use subagents when the user has authorized orchestration/delegation directly or through a coordinator carrying that authority. Verify applicable runtime qualification and inherited restrictions before dispatch; do not create another coordinator or orchestrator layer. Absence of explicit closure is not itself a missing capability. On actual capacity failure, apply the shared [lifecycle and bounded recovery rules](../coordinator/references/execution-contract.md#worker-retirement-and-capacity). If required operation remains unavailable or recovery is unsafe, hold the assignment and report an explicit alternative, never omit independent validation or change models as an implicit fallback.
 
 ## Required Inputs
 
@@ -20,7 +24,9 @@ Prefer a task packet containing:
 - repo root
 - project instruction docs, if not discoverable from the repo
 - feature/fix name or slug
-- stable chunk IDs and a run-state/handoff path, or permission to create one beside the plan/checklist
+- explicit assigned chunk/gate IDs and boundary; run/orchestrator assignment identity and direct/coordinated mode
+- current candidate/baseline, protected work, durable evidence and assigned resource ownership/allocation
+- current handoff/readiness references and allowed chunk-record paths; parent identity in coordinated mode
 - plan path
 - implementation checklist path
 - prompt map path
@@ -36,7 +42,8 @@ Resolve and normalize commit authorization under **Commit Rules** before impleme
 
 ## Authority Boundaries
 
-- The orchestrator owns chunk selection, prompt writing, review, follow-up prompts, validation decisions, and commits.
+- The orchestrator owns scoped readiness, prompt writing, actual-diff/integration review, corrections, validation and acceptance/authorized commits for the assigned IDs only.
+- The coordinator selects run-wide work and routes user approvals; send proposed global status/contract updates to it instead of editing shared scheduling records. Direct invocation retains user-facing responsibility within the assigned boundary.
 - Implementer sub-agents own one scoped implementation pass at a time.
 - Implementer sub-agents must not commit.
 - Validator sub-agents or validator passes gather evidence only; they do not decide final acceptance.
@@ -50,19 +57,18 @@ Before delegating implementation, run a readiness preflight:
 
 1. Establish current state.
    - Read project instructions first.
-   - Establish context from the plan, checklist, prompt map, current handoff/review and relevant git/worktree state. On continuation, read changed instructions/contracts and affected scope rather than reloading unchanged history.
+   - Establish scoped context from the assignment, applicable plan/checklist/prompt-map entries, shared invariants, current handoff/review and actual git/worktree state. Verify dependency evidence; do not trust the coordinator's ready label alone. Expand for affected callers/contracts, not unrelated historical narrative.
    - Before delegating edits, establish persistent implementation and evidence locations under **Resource Lifecycle**. On resume, verify the actual candidate files and backing Git metadata before using previous reports or continuing dependent work.
    - Before initial implementation delegation, verify the reviewed planning package against its checkpoint and actual working files. If relevant planning changes remain uncommitted, honor an explicit uncommitted disposition or applicable planning-checkpoint authorization; otherwise finish applicable document checks, identify the exact files and proposed commit, and ask before proceeding. Planning-checkpoint permission and accepted-chunk commit permission are separate. Exclude unrelated changes; do not repeat a resolved checkpoint request or turn routine execution-status updates into a new planning checkpoint gate. Record the verified baseline, including relevant uncommitted inputs when explicitly allowed.
-   - Read any existing readiness audit. If no readiness audit exists, create one before writing the first implementer prompt.
+   - Reuse the run readiness audit and verify assigned entries and dependencies. If missing, perform the bounded readiness assessment before prompting; report any missing run-level audit to the coordinator rather than reconstructing the entire plan locally.
-   - Initially classify every chunk as `ready`, `blocked-by-contract-decision`, `blocked-by-dependency`, `blocked-by-environment`, or `needs-small-freeze-before-prompt`. Subsequently verify affected entries/dependencies; broaden when a shared contract changes or applicability is uncertain.
+   - Classify affected entries as `ready`, `blocked-by-contract-decision`, `blocked-by-dependency`, `blocked-by-environment`, or `needs-small-freeze-before-prompt`; the coordinator owns global updates. Broaden investigation when a shared contract changes or applicability is uncertain.
-   - Surface all contract blockers and small freezes to the user before implementation starts.
+   - Surface missing contracts/freezes before dependent implementation. Hold affected work; ready-subset authority permits only unaffected assigned work, not picking a replacement chunk outside the boundary.
-   - Stop if any `blocked-by-contract-decision` item remains unresolved, unless the user explicitly authorizes implementing only the `ready` subset while blocked chunks remain held.
    - Hold the affected chunk and dependents if a required engineering freeze cannot be resolved from written docs; apply **Stopping Conditions** to any independent continuation.
 
-For each authorized ready chunk:
+For each authorized ready unit within the assignment (validation-only gates need no implementer):
 
-2. Select the next chunk.
+2. Verify the assigned unit.
-   - Identify the next ready chunk from the checklist, prompt map, and readiness audit.
+   - Confirm its readiness and order within the explicit assignment against the checklist, prompt map and prerequisites.
    - Verify the chunk has not already landed.
    - Run `git status --short` and relevant `git log --oneline` checks to verify the chosen chunk has not already landed and that the review target matches the current worktree.
 
@@ -74,7 +80,7 @@ For each authorized ready chunk:
 
 4. Delegate implementation.
    - Spawn a fresh implementer sub-agent when possible.
-   - Give the sub-agent the saved prompt and explicitly tell it to use `$implementer`.
+   - Give the sub-agent the saved prompt and exact `$implementer` skill path from the assignment's selected bundle; preserve bundle identity for all descendants, not the installed name alone.
    - Use a supported task label mapped to the assignment ID under **Run State and Worker Lifecycle**.
    - Pass only the context needed for that chunk.
    - Tell the sub-agent not to commit and to report changed files, validation, blockers, and proposed commit message.
@@ -98,6 +104,7 @@ For each authorized ready chunk:
    - Invoke `$validator` for feature acceptance, regression, contract, UI/browser, runtime, API, device, or integration evidence when a separate validation pass would reduce risk.
    - Give the validator the exact target, applicable frozen requirements, findings and evidence limits; avoid unrelated planning/history context.
    - Treat validator results as evidence for the orchestrator's acceptance decision, not as acceptance by themselves.
+   - Route fixable in-scope failures back through correction and revalidation in this assignment. Keep acceptance held; release validation writes/holds before repairs and preserve the original failed evidence. A failed test alone is not a blocked return requiring worker retirement.
 
 8. Accept the chunk.
    - Confirm required validation passed under the current recorded acceptance contract; handle explicit user-approved exceptions under **Commit Rules**, never as fabricated PASS evidence.
@@ -107,27 +114,26 @@ For each authorized ready chunk:
    - Use the chunk's proposed commit message when acceptable; otherwise write a one-line commit message with the chunk ID prefix when one exists.
    - Retire the chunk's workers under **Run State and Worker Lifecycle**, recording any justified retention exception before further delegation.
 
-9. Continue.
+9. Hand off or finish the assigned group.
-   - Update the existing live handoff and the chunk's current outcome; update checklist/map/readiness entries when their state/dependencies change, without copying the running journal into each artifact.
+   - Update the durable chunk acceptance/outcome record. In coordinated mode return proposed scheduling/readiness changes; only the coordinator writes run-wide records. Direct mode updates the existing bounded handoff.
-   - Reconcile temporary-resource ownership/retention and perform eligible authorized cleanup under **Resource Lifecycle** before the next large allocation.
+   - Reconcile resources/retention and cleanup under **Resource Lifecycle**. Transfer unresolved consumers and allocation responsibility before retirement; completion alone does not release resources.
-   - Choose the next ready chunk.
+   - Continue only to the next explicitly assigned group member when prerequisites and authority permit. Preserve each unit's acceptance/rollback boundary. Otherwise return the shared contract's result and stop; do not self-dispatch the next checklist chunk.
-   - Stop when all chunks are complete, blocked, or no ready chunk remains.
 
 ## Run State and Worker Lifecycle
 
-Use the existing durable handoff as one compact continuation record, not a second status system. Update it in place with current chunk/assignment IDs, candidate/baseline identity, worker ownership, unresolved findings/blockers, evidence pointers, retained resources, next ready work and one-line accepted outcomes/commit IDs. Preserve outstanding gates, dependencies, recovery/retention obligations and authority restrictions directly or through clear authoritative links, including obligations needed only later. Do not carry accepted-chunk narratives, full logs or superseded findings into later assignments unless a dependency or regression requires them.
+Keep the existing chunk record sufficient for recovery: candidate/baseline, worker ownership, findings, evidence, authority and retained consumers. Return these to the coordinator's one live run handoff; do not create a competing global status record. Direct mode uses the existing bounded handoff. Preserve future gates, dependencies and recovery obligations through authoritative links. Do not load accepted-chunk narratives or full logs unless applicable to current work.
 
-Attribute every worker assignment to a stable chunk and role with a canonical ID such as `<chunk-id>:<role>:<attempt>`. Use implementer modes `new-chunk | correction | replacement` and validator modes `validation | revalidation | replacement`. Same-worker corrections/revalidation retain the assignment ID; a fresh replacement increments the attempt. A next-chunk worker uses the new chunk's ID. Where task labels are supported, use the canonical ID only if valid for that tool; otherwise choose a supported unique label (for example, `o_03_implementer_1` for `O-03:implementer:1`). Record the assignment-to-label/worker mapping once in the handoff; check label collisions and do not assume telemetry can decode an unsupported format.
+Attribute workers using the [shared assignment-label contract](../coordinator/references/execution-contract.md#assignment-labels): propagate the coordinator's run ID, or establish/recover it in the direct-mode handoff. Encode the exact unit scope/ID, role and attempt for supported task names; record the mapping to actual workers and immediate parents. Use implementer modes `new-chunk | correction | replacement` and validator modes `validation | revalidation | replacement`. Same-worker corrections/revalidation retain identity; a fresh replacement increments the attempt, including after resume. A next-chunk worker uses the new chunk's ID. Tool limitations require an explicit mapping, not guessed truncation or a new run ID.
 
 The implementer may remain available as the same-chunk repair agent during validation, but must not write until the parent releases the validation hold and assigns a correction. Before a replacement edits, establish that the prior worker and its owned operations have stopped writing; verify the actual candidate, transfer relevant findings/resources, retire the superseded assignment and designate the replacement as sole writer. A recorded transfer alone does not establish that writes stopped. An unresolved validation hold still prevents replacement edits.
 
-At acceptance or permanent block, transfer required responsibilities and retire the workers: stop further assigned work, remove them from dispatch and close them when supported. If closure is unavailable, use supported controls to establish inactivity and record retirement; do not claim interruption closed a worker or released its processes/resources. Preserve held source and evidence. Any retention exception needs a purpose and release condition. Safe independent chunks may overlap with recorded ownership and candidate isolation; do not serialize them merely because another worker remains available. Retained workers receive no unrelated next-chunk work. Idle availability alone is not evidence of token consumption.
+At acceptance, a blocked return or assignment end, verify responsibility transfer from final results and retire descendant assignments under the shared lifecycle rules. Leave completed workers idle without acknowledgement/retirement messages; use supported closure or allow automatic reclamation, without claiming interruption freed a slot or released resources. Request a bounded follow-up only for a concrete need. Preserve held source/evidence and record any retention exception with purpose/release condition. Return descendant identities, process/resource ownership and unresolved obligations so coordinator handoff covers the full subtree. Default to one unit at a time in the assigned group; wider concurrency needs explicit qualified authority. Retained workers receive no unrelated next-chunk work. Idle availability alone is not evidence of token consumption.
 
 ## Readiness Audit Rules
 
 The readiness audit exists to resolve blockers before implementation, not during the first failed prompt.
 
-Record each chunk's ID and readiness classification. For non-ready chunks, record the applicable details below; reuse a shared blocker entry for affected chunks rather than duplicating its analysis. Dependency-only holds need the missing predecessor and acceptance link, not an options essay.
+Record assigned chunks' readiness and notify the coordinator of affected outside dependencies. For non-ready chunks, record the applicable details below; reuse a shared blocker entry rather than duplicating its analysis. Dependency-only holds need the missing predecessor and acceptance link, not an options essay.
 
 - chunk ID/name
 - readiness classification: `ready`, `blocked-by-contract-decision`, `blocked-by-dependency`, `blocked-by-environment`, or `needs-small-freeze-before-prompt`
@@ -142,7 +148,7 @@ Before implementation starts, require one of:
 - contract blockers are resolved and the intended chunk's required engineering freezes are recorded in authoritative artifacts
 - or the user explicitly authorizes a ready-subset run while unrelated contract-blocked chunks remain held
 
-Complete later mechanism freezes before their first dependent chunk; independent ready work need not await every later implementation detail. Investigate major feasibility/irreversible risks early. Do not spawn implementers for blocked chunks or let them decide missing parent-route, API, persistence, timebase, ownership or cleanup contracts.
+Complete required mechanism freezes before dependent implementation. Report wider feasibility/contract risk to the coordinator; do not redesign unassigned phases. Do not spawn implementers for blocked chunks or let them decide missing parent-route, API, persistence, timebase, ownership or cleanup contracts.
 
 Bound further investigation by a question and an observation that distinguishes mechanisms. When equivalent experiments cannot resolve missing contract, access or authority, record one focused decision/blocker and continue only independently authorized ready work.
 
@@ -205,13 +211,15 @@ For new implementer and independent-validator assignments, default to fresh scop
 
 Dispatch complete bounded assignments so workers can finish already-authorized routine steps without acknowledgement chatter. Coordinate candidate release, shared-resource acquisition, scope changes and required approvals explicitly; a completion notification does not release a workspace. Prefer completion notifications or interruptible waits, with proportionate polling when necessary. Preserve required user updates and immediate blocker/material-finding reports; do not add a permanent monitoring loop or wait so long that intervention is prevented.
 
-Do not routinely send status-only prompts to a worker with a complete assignment. A wait timeout alone does not justify an acknowledgement or context replay; use notifications, independent safe work or an interruptible wait compatible with required user updates. Perform a proportionate liveness check when expected progress, a tool failure or other evidence suggests the worker is stuck; prefer available status information before prompting. Necessary intervention and blocker reporting remain required.
+Do not routinely send status-only prompts to a worker with a complete assignment. A wait timeout alone does not justify an acknowledgement or context replay; use notifications, independent safe work or an interruptible wait compatible with required user updates. Perform a proportionate liveness check when expected progress, a tool failure or other evidence suggests the worker is stuck; prefer available status information before prompting. Necessary intervention, blocker reporting and required safety/resource checks remain required. Apply the shared execution contract's communication boundary: routine in-scope corrections stay here. Answer Coordinator or direct-user snapshot requests from existing knowledge under [User-Requested Progress Snapshots](../coordinator/references/execution-contract.md#user-requested-progress-snapshots), without descendant polling or extra checks; an explicit deeper request follows that rule's override within existing authority.
+
+While a worker owns an active implementation or validation pass, do not continuously inspect its changing work or duplicate its assigned investigation. Intervene for concrete risk, blockers, ownership conflicts or an agreed checkpoint; perform acceptance review against the stable returned candidate. This does not restrict required independent review or investigation of affected callers and shared behavior.
 
 When spawning an implementer sub-agent:
 
 - start with a fresh sub-agent for each new chunk by default
 - reuse the same sub-agent only for follow-up fixes to the same chunk when continuity is useful
-- instruct it to use `$implementer`
+- instruct it to read `$implementer` at the verified path in the selected bundle, carrying that bundle identity explicitly
 - instruct it to edit files directly if the runtime supports sub-agent code edits
 - instruct it not to commit
 - keep the task narrow and self-contained
@@ -224,7 +232,7 @@ If sub-agent edits are not inspectable as the actual candidate diff, hold that c
 
 When invoking a validator pass:
 
-- instruct it to use `$validator`
+- instruct it to read `$validator` at the verified path in the same selected bundle; do not resolve a different installed version by bare name
 - give it the same chunk ID and a validator assignment ID/mode with the supported task-label mapping under **Run State and Worker Lifecycle**
 - provide the exact expected behavior, frozen contracts and candidate identity: baseline revision plus scoped changes (including relevant untracked inputs), and the relevant build/artifact and its source provenance
 - release implementer writes before validation; prevent overlapping writes to the validated scope, relevant harness/configuration inputs, or replacement of the tested build/target until the pass is released
@@ -259,6 +267,8 @@ Report concise differences, counts, failures, skipped/not-tested obligations, ev
 
 Unfinished source, backing Git metadata and required evidence must be durable from creation. Before delegating edits, verify the resolved checkout, backing Git/common-directory storage and evidence destinations under the reference's persistence procedure; an existing checkout is not automatically suitable. Reuse that verification only while paths/storage remain demonstrably unchanged. `/tmp` and other disposable locations may hold only reproducible copies. Keep a compact ownership/consumer/release record, preserve evidence and uncommitted work until their retention conditions are satisfied, and never infer cleanup authority from names, age or location.
 
+In coordinated mode, subdivide the coordinator's allocation among workers and coordinate increases/shared-target use before starting them. Report actual paths/consumers/remaining allocations; the coordinator owns the run-wide total and later retention. In direct mode, perform that run-owner duty within the assignment. Neither mode permits concurrent candidate/index mutations by coordinator and orchestrator.
+
 Read and apply [Resource Lifecycle](./references/resource-lifecycle.md) for that initial persistence verification and before creating/reusing worktrees or disposable build/test copies, large builds (including in the main checkout), dependency/browser installations, archives or other substantial allocations, and cleanup/storage recovery. It defines persistence, coordinated disk-headroom checks, evidence retention and bounded cleanup. Reuse already-read instructions and verified setup where applicable rather than reloading the reference for every routine step.
 
 The core safety boundary always applies: no broad `/tmp` clearing, wildcard/prefix deletion, shared-cache pruning, symlink traversal into unrelated locations, forced removal of uncommitted work, or destructive cleanup outside the recorded run-owned scope. Disk-full/quota/inode failures stop affected writes until safe headroom and candidate integrity are re-established.
@@ -292,6 +302,8 @@ If there are no findings, state an acceptable verdict clearly before summaries.
 
 ## Commit Rules
 
+In coordinated mode you are the sole committer for the assigned accepted scope; the coordinator routes approvals and holds competing Git writers. Persist the acceptance basis/candidate/evidence before committing, then record the resulting commit immediately. On uncertain interruption inspect actual Git and evidence before retrying; a commit alone proves neither acceptance nor integration. Return the real integration state; merging into another target requires authority and renewed applicability if inputs change. Direct mode uses the same checks without a coordinator.
+
 Implementation-chunk commits are controlled by the explicit commit policy. Planning checkpoints require their own applicable authorization under the preflight rule; neither permission grants the other. A broader user instruction forbidding commits or requiring confirmation for every commit still applies to both scopes unless explicitly changed. Supported implementation policies are:
 
 - `authorized-for-accepted-chunks`
@@ -314,7 +326,7 @@ For `ask-before-each-commit`:
 
 - stop after each accepted chunk
 - report the proposed one-line commit message
-- ask the user before committing
+- request user approval through the coordinator when delegated, or directly otherwise; after approval reverify candidate/staged identity before committing
 
 For `do-not-commit`:
 
@@ -355,18 +367,12 @@ Hold the affected chunk and its dependents, leaving them unaccepted, when:
 - required validation fails or cannot run at that chunk's assigned gate
 - sub-agent changes are not inspectable as an actual diff
 
-Record the blocker and preserve held work/evidence. Continue independent ready work only under existing authorization and after verifying it neither depends on the held implementation nor changes the validated scope, build/test inputs or shared runtime state. Separate its acceptance and commit from held work. Different filenames alone do not establish independence; when safe separation is unproven, hold that candidate too.
+Holding acceptance is distinct from ending the assignment. Fixable findings with a clear contract stay in the correction/revalidation loop; return `blocked` when a missing contract, authority, dependency or environment prevents safe progress, or `incomplete` at a directed stopping boundary. Do not keep retrying equivalent checks that cannot resolve the blocker.
 
-Stop the entire run and report when the user pauses/stops it, required run authority remains unresolved, a global safety/integrity issue prevents safe work, or no safe authorized ready chunk remains (including completion). Unresolved contract decisions still require explicit ready-subset authorization to continue unaffected work. A chunk-specific environment/validation hold alone does not cancel an otherwise authorized run; it never waives the blocked requirement.
+Record the blocker and preserve held work/evidence. Continue only independently ready members of the explicit assignment under existing authority, after verifying they do not depend on held work or change validated inputs/shared state. Otherwise return the block and ownership to the coordinator; it may schedule another eligible chunk. Different filenames alone do not establish independence. Separate acceptance/commits from held work; when safe separation is unproven, hold the candidate too.
+
+Stop dispatch and propagate pauses/safety restrictions to descendants immediately when the user or authorized coordinator pauses/stops, authority is unresolved, or a global integrity issue prevents safe work. Preserve in-flight operation identity and report; interruption is not cancellation of transmitted hardware commands. Stop at the assignment boundary or when no safe assigned work remains. A chunk hold does not cancel the coordinator's run or waive a gate. Unresolved contract decisions still require explicit ready-subset authority for unaffected work.
 
 ## Final Response
 
-For each orchestration run, report:
+Return the [Execution Contract](../coordinator/references/execution-contract.md#result-and-durable-handoff) fields: scoped outcome and acceptance level, candidate/build and actual Git disposition, accessible acceptance/validation evidence, missing obligations and residual risk, descendant/resource ownership and proposed scheduling updates. Direct mode reports the same facts to the user. Do not claim the entire plan is complete or start its next chunk merely because the assigned unit passed.
-
-- chunks completed
-- chunks blocked and why
-- readiness audit status
-- commits made, if any
-- validations run
-- residual risk
-- next recommended action

plugins/staged-implementation/skills/orchestrator/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
-  display_name: "Orchestrator"
+  display_name: "Bounded Orchestrator"
-  short_description: "Run planner-implementer-validator chunk loops"
+  short_description: "Review and execute one assigned chunk or group"
-  default_prompt: "Use $orchestrator to run the staged implementation loop with planner review, implementer sub-agents, and validator evidence."
+  default_prompt: "Use $orchestrator for the assigned chunk or explicitly named group, preserving actual-diff review and independent validation; stop at that boundary."

plugins/staged-implementation/skills/orchestrator/references/resource-lifecycle.md

@@ -1,6 +1,8 @@
-# Orchestrator Resource Lifecycle
+# Shared Resource Lifecycle
 
-Read this reference for initial persistence verification before delegating edits, and before creating/reusing worktrees or disposable build/test copies, large builds (including in the main checkout), dependency/browser installations, archives or other substantial allocations, and cleanup/storage recovery. Reuse already-read instructions and verified setup while applicable. The core orchestrator skill remains authoritative for acceptance and worker lifecycle.
+Read this single procedure for initial persistence verification before delegating edits, and before creating/reusing worktrees or disposable build/test copies, large builds (including in the main checkout), dependency/browser installations, archives or other substantial allocations, and cleanup/storage recovery. Reuse already-read instructions and verified setup while applicable. Acceptance and worker lifecycle belong to the execution skills and their shared contract.
+
+In coordinated mode, Coordinator is the run resource owner; Orchestrator is the immediate parent of implementer/validator resources. Orchestrator subdivides its assigned allocation and coordinates increases/shared targets with Coordinator before allocation. Parent duties below apply locally to Orchestrator and globally to Coordinator; reconcile one run ledger without counting a parent reservation and its child allocations twice. Direct Orchestrator performs both duties within its boundary. Resource responsibility survives any worker exit; transfer exact paths, consumers, retained obligations and remaining allocations before the next assignment. A paused/missing parent grants no new cleanup or allocation authority.
 
 ## Persistent Workspaces
 
@@ -12,7 +14,7 @@ Reserve `/tmp` and other disposable storage for reproducible resources. A dispos
 
 ## Temporary Resources and Cleanup
 
-Authorization to run orchestration includes routine cleanup of that run's tracked, disposable temporary resources once the checks below pass. State this default in the handoff and worker assignments; do not require separate cleanup approval within its bounds. Explicit retention/no-deletion instructions and higher-priority restrictions override the default. Reading the skill or doing standalone planning/implementation/validation does not authorize orchestration cleanup. Resources accumulated earlier in the same resumed run qualify only after ownership and release conditions are verified and recorded; unknown ownership or files predating the run do not qualify.
+Authorization to run direct or coordinated orchestration includes routine cleanup of that run's tracked, disposable temporary resources once the checks below pass. State this default in the handoff and worker assignments; do not require separate cleanup approval within its bounds. Explicit retention/no-deletion instructions and higher-priority restrictions override the default. Reading the skill or doing standalone planning/implementation/validation does not authorize orchestration cleanup. Resources accumulated earlier in the same resumed run qualify only after ownership and release conditions are verified and recorded; unknown ownership or files predating the run do not qualify.
 
 Maintain a compact record in the existing handoff of exact run-created paths, purpose/owner, active or future consumers, and release condition. Register resources when created and transfer responsibility when a worker exits; a closed agent does not make its files disposable. On resume, reconcile that record against actual resources before reusing or removing them. Do not infer ownership from a filename prefix, age or location under `/tmp`.
 

plugins/staged-implementation/skills/planner/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: planner
-description: Staged implementation planner/reviewer workflow for any codebase. Use when Codex should prepare or update a plan/checklist/prompt map, run a readiness or ambiguity audit, choose the next implementation chunk, write an implementer or orchestrator handoff prompt, review staged or supplied diffs against frozen docs, clarify contracts, control scope, or define the next handoff. Do not use for direct implementation unless the user explicitly asks the planner to implement.
+description: Staged implementation planner/reviewer workflow for any codebase. Use when Codex should prepare or update a plan/checklist/prompt map, audit readiness, choose a chunk, write an implementer or bounded-orchestrator handoff or a coordinator run handoff, review diffs against frozen docs, clarify contracts, or control scope. Do not implement unless explicitly asked.
 ---
 
 # Planner
@@ -38,7 +38,7 @@ For planner/reviewer tasks, prefer a task packet containing:
 - current ground truth, such as plan, checklist, prompt map, recent review notes, or git verification notes
 - requested action: write next implementer prompt, review staged diff, clarify docs, update prompt map, prepare checklist, or similar
 - output path, when saving an official artifact is requested or expected
-- commit policy, when writing an orchestrator handoff prompt
+- commit policy and execution boundary, when writing an orchestrator/coordinator handoff prompt
 
 If a path, contract, data source, diff target, or output location is required and cannot be discovered safely, stop and ask for the exact missing information. Do not guess.
 
@@ -275,17 +275,18 @@ Reuse explicit planning-checkpoint authorization already granted; otherwise ordi
 
 Respect explicit instructions to leave the planning package uncommitted. Record that disposition and the baseline commit plus relevant uncommitted planning files in the handoff so the orchestrator can verify the actual inputs. Do not repeatedly ask for a checkpoint already made, authorized or explicitly waived; unrelated dirty files do not by themselves require another commit.
 
-## Orchestrator Handoff Prompts
+## Execution Handoff Prompts
 
-When asked to write, produce, or prepare an orchestrator prompt, treat it as an official durable handoff artifact, not casual chat output.
+Choose the entry point explicitly: `$orchestrator` for one chunk/gate or a named coherent group; `$coordinator` for unattended run-wide scheduling with fresh bounded orchestrators. Preserve the requested work: an older whole-checklist orchestrator prompt needs an explicit entry-point/boundary update, not a silent one-chunk truncation or an accidental second scheduling loop. Do not change existing chunk IDs, contracts or gates merely to adopt the execution model.
 
-Save official orchestration handoff prompts at the user's specified path, or follow the established repository/workflow output location and naming convention. Otherwise, save beside the identified plan/checklist/prompt map with a descriptive filename. State the chosen path; do not ask solely because the user omitted a filename. Ask only if the companion location cannot be established or conflicting instructions leave the destination ambiguous. Do not overwrite an unrelated existing artifact. Honor an explicit chat-only request. Re-read the saved file before finishing.
+When asked for an execution handoff, treat it as an official durable artifact. Save at the requested path or established companion plan/checklist/prompt-map location, with a descriptive filename. State the path; ask only when the location or authority cannot be established, not solely because a filename was omitted. Do not overwrite unrelated artifacts. Honor explicit chat-only output and reread saved handoffs.
 
-Every orchestrator prompt must include:
+Read the shared [Execution Contract](../coordinator/references/execution-contract.md) when preparing either handoff. Every execution handoff must include:
 
 - repo root
 - feature/fix name or slug
-- stable chunk-ID convention and a run-state/handoff path, or permission for the orchestrator to create one beside the plan/checklist
+- direct/coordinated entry point, exact authorized boundary, stable run/chunk/assignment identities and current handoff path
+- selected skill-bundle version/source and exact role paths to propagate to all descendants, especially during branch-local preview trials
 - plan path
 - implementation checklist path
 - prompt map path
@@ -298,9 +299,13 @@ Every orchestrator prompt must include:
 - persistent implementation/evidence locations, or the location decision required before dependent work starts
 - stopping conditions
 
-State the intended lifecycle: a same-chunk repair agent may remain available but cannot write during validation. Replacements acquire write ownership only after prior writes stop and candidate/findings/resources are verified and transferred. Accepted/permanently blocked assignments retire after required handoffs, using closure when supported or verified inactivity and removal from dispatch otherwise. Preserve held work and permit safe independent overlap with recorded ownership/isolation; retained-worker exceptions need a purpose and release condition. Use the existing handoff to preserve outstanding gates, dependencies, recovery obligations and authority restrictions, not just the next step.
+For a coordinator launch, delegate global scheduling/status and shared-resource management to Coordinator; actual-diff review, independent validation, acceptance and scoped commits remain with the active bounded Orchestrator. Require runtime qualification for nested delegation, scoped context/model preservation and recycling worker capacity before consequential execution. Start with one active orchestrator assignment at a time. The coordinator verifies completion without routinely repeating the chunk review. Reuse the existing live handoff and chunk evidence locations; no second journal or automatic transcript forwarding.
 
-Use canonical assignment IDs such as `<chunk-id>:<role>:<attempt>`; same-worker corrections/revalidation retain the ID and fresh replacements increment the attempt. If task labels are supported, use the ID only when valid for that tool; otherwise use a supported unique encoding and record its mapping to the assignment/worker in the handoff. Do not require unsupported label syntax or assume telemetry recognizes the encoding.
+For a direct orchestrator launch, name the chunk/gate IDs and stop boundary. It handles needed run duties only for that scope, not the whole checklist. A validation-only gate need not spawn an implementer. Named groups retain each chunk's acceptance and rollback obligations. Both entry points preserve later integration/platform gates and distinguish accepted-uncommitted, committed and integrated results.
+
+State the [shared lifecycle](../coordinator/references/execution-contract.md#worker-retirement-and-capacity): retain same-chunk repair continuity without writes during validation; verify writer cessation and ownership transfer before replacement. Carry resource/hold handoff in final results and retire assignments without a subsequent ceremonial message exchange. Qualify supported closure or automatic reclamation through successive complete worker groups; absence of a close tool alone is not a blocker. Actual capacity failures permit bounded safe recovery, not an automatic session restart or waived gate. Route coordinated approvals through Coordinator, propagate user pauses promptly, and preserve recovery evidence. Keep future gates, dependencies, recovery obligations and authority restrictions accessible in the existing handoff.
+
+Use the [shared assignment-label contract](../coordinator/references/execution-contract.md#assignment-labels) for both execution entry points. Establish/recover one stable run ID, preserve it on resume and propagate it to descendants. Same-worker corrections/revalidation retain identity; fresh replacements increment the attempt. Require the shared encoding for supported task names and the logical-assignment/tool-label/actual-worker mapping with immediate parent in the existing handoff. Tool limitations require an explicit mapping, not silent truncation or assumed telemetry attribution.
 
 State in the handoff that authorization to run orchestration includes routine cleanup of that run's tracked, disposable temporary resources after ownership, retention and consumer-release checks pass. No separate cleanup approval question is needed within those bounds. Carry this scope into worker assignments and honor explicit retention/no-deletion instructions and higher-priority restrictions. On resuming the same run, accumulated resources qualify only after their run ownership and release conditions are verified and recorded. Unknown ownership, shared caches, files predating the run, unrelated resources and anything still needed remain excluded. Standalone planning/implementation/validation or commit permission does not grant this orchestration cleanup scope; ask for concrete additional authority only when needed outside it. Never propose blanket clearing of `/tmp`.
 
@@ -314,16 +319,16 @@ Resolve commit behavior from the user's current instructions, still-applicable e
 
 Ask before saving only when commit authority remains missing, conflicting or ambiguous after checking those sources. General permission to implement, an example of a possible workflow, or permission for one specific commit is not authorization to commit every accepted chunk. Do not silently select a policy merely to avoid asking.
 
-If the user says to orchestrate implementation and their stated workflow preference says the orchestrator should commit accepted chunks, use `authorized-for-accepted-chunks` and include this exact policy text:
+If the user authorizes execution and their stated workflow preference says the orchestrator should commit accepted chunks, use `authorized-for-accepted-chunks` and include this policy text:
 
 ```text
 Commit policy: authorized-for-accepted-chunks
-Commits are authorized for accepted chunks only. Commit after each accepted chunk once review and required validation pass. Do not commit unrelated dirty changes. Use one-line commit messages with the chunk ID prefix when one exists.
+The active bounded orchestrator may commit its accepted chunks after actual-diff review and required validation pass. No other role commits that candidate concurrently. Exclude unrelated dirty changes and use one-line messages with the chunk ID prefix. Coordinator scheduling-record commits require applicable documentation authority and a serialized Git handoff.
 ```
 
-For `ask-before-each-commit`, require the orchestrator to stop after each accepted chunk and ask before committing.
+For `ask-before-each-commit`, require the orchestrator to stop with a concrete reviewed commit proposal and obtain user approval, routed through Coordinator when delegated. Reverify the candidate before the approved commit.
 
-For `do-not-commit`, require the orchestrator to avoid commits and report the proposed one-line commit message for each accepted chunk.
+For `do-not-commit`, require preservation and identification of accepted uncommitted work, with proposed commit messages. Do not force a commit to simplify handoff; hold later work if required isolation/dependencies cannot be established.
 
 ## Prompt Output Hygiene
 

plugins/staged-implementation/skills/validator/SKILL.md

@@ -13,7 +13,9 @@ Verify behavior against the frozen plan, checklist, implementer prompt, review f
 
 Default to no code edits. Do not modify production code. Only create validation artifacts, notes, screenshots, logs, or temporary test data when the task requires it and the target environment is appropriate.
 
-The validator reports evidence and risk. The planner/reviewer or orchestrator decides whether the chunk is accepted.
+The validator reports evidence and risk. The designated planner/reviewer or bounded orchestrator decides chunk acceptance; the coordinator verifies completion and schedules the run rather than repeating that review.
+
+In coordinated execution, report to the assigned orchestrator and preserve run-level authority restrictions. Verify requirements/candidate independently; do not adopt an implementer's verdict or inherit its reasoning as validation. Do not write global scheduling records, commit, self-dispatch another chunk or release holds on behalf of an absent parent. Honor urgent user/authorized pauses immediately and hand off candidate/process/resource state to the surviving authorized owner if orchestration is interrupted.
 
 ## Required Inputs
 
@@ -97,7 +99,7 @@ For a correction/revalidation, verify the original assignment/current candidate
 
 Complete assigned routine checks without repeated parent acknowledgements; promptly report blockers/material findings and coordinate candidate release, shared resources, scope changes and approvals. A completion notice does not release a workspace. Preserve required user updates. Correctness and acceptance obligations take priority over token savings.
 
-After returning the verdict, stop and wait for a concrete revalidation assignment. Do not poll the parent/implementer, continue exploratory validation, or repeat successful checks merely because the worker remains available. Same-worker revalidation retains the chunk/assignment IDs; independently determine affected coverage plus required regressions/fresh gates, then stop after reporting. On replacement or retirement, hand off validation holds, owned operations/resources and evidence; the parent coordinates their release. Retirement ends assigned work even if the runtime leaves the worker open.
+After returning the verdict, stop and wait for a concrete follow-up assignment. Do not poll the parent/implementer, continue exploratory validation, or repeat successful checks merely because the worker remains available. Same-worker revalidation retains the chunk/assignment IDs; independently determine affected coverage plus required regressions/fresh gates, then stop after reporting. Include validation holds, owned operations/resources, evidence and unresolved obligations in the final result; do not wait for a separate retirement-message exchange. The parent verifies handoff and coordinates release. Retirement ends assigned work even if the runtime leaves the worker open; completion does not itself release resources.
 
 ## Browser/UI Validation