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

@@ -6,7 +6,7 @@ Codex plugin marketplace for reusable agent 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.2`). 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.
+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
 

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

@@ -1,6 +1,6 @@
 {
   "name": "staged-implementation",
-  "version": "0.2.0-alpha.2",
+  "version": "0.2.0-alpha.5",
   "description": "Experimental coordinated staged implementation with planner, coordinator, bounded orchestrator, implementer, and validator roles.",
   "author": {
     "name": "Local developer"

plugins/staged-implementation/README.md

@@ -10,7 +10,7 @@ Staged Implementation bundles five skills with two execution entry points:
 
 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.2`.** 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.
+**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
 
@@ -119,6 +119,8 @@ The usual flow is:
 3. Use `validator` when runtime, UI, API, integration, or regression evidence is needed.
 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 |
@@ -132,7 +134,7 @@ The usual flow is:
 
 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 transfers resources and retires descendants; Coordinator verifies the subtree's state and capacity before dispatching another fresh orchestrator. Nested delegation, scoped context and capacity recycling must be demonstrated, not inferred from an agent's idle status. Unsupported operation holds the coordinated loop; direct/manual execution requires an explicit alternative, not silently weakened validation.
+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.
 
@@ -140,9 +142,9 @@ The existing plan/checklist/prompt map and one live handoff remain authoritative
 
 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/blocked/end-of-assignment workers retire after handoff: stop work and dispatch, close when supported, otherwise establish inactivity and report retained slots/processes. Default coordinated scheduling is one active assignment at a time; broader concurrency requires explicit qualified authority. 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.

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

@@ -16,21 +16,21 @@ Before dispatch, read the shared [Execution Contract](references/execution-contr
 ## 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. 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.
+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 that retiring a completed subtree permits a fresh orchestrator and its workers to launch; an idle/interrupted worker may still occupy a slot. Reuse applicable recorded qualification, not unsupported assumptions. Use the bounded [Pilot Validation](references/pilot-validation.md) when this runtime/model arrangement is unqualified. If unavailable or unsafe, hold coordinated execution and propose direct/manual operation; do not silently flatten the hierarchy, bypass independent validation or restart active work.
+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. 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 assignment/worker mapping 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. Required user updates use information already received, with uncertainty stated honestly; do not initiate inspections or descendant status requests solely to refresh a progress message. 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.
+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. Transfer outstanding resources/holds, retire the complete worker subtree and verify capacity for the next assignment. Closing a parent does not prove its children/processes stopped. Preserve held source, failed evidence and future gate/rollback consumers. Reconcile eligible cleanup and allocations before further work.
+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

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

@@ -15,6 +15,18 @@ Shared by Coordinator and Orchestrator. Use existing prompt, handoff and chunk-e
 
 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.
@@ -29,6 +41,18 @@ The active orchestrator alone stages/commits its accepted scope under its commit
 
 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:
@@ -42,4 +66,18 @@ Return concise fields with accessible evidence links; omit empty optional sectio
 
 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. Runtime capacity must be available for subsequent assignments; unsupported closure is not proof that slots were released.
+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

@@ -6,7 +6,7 @@ Use for a new or materially changed runtime/delegation arrangement, not as a man
 
 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, retirement of the complete subtree and ability to launch its successor. Check actual agent capacity; marking an assignment retired is insufficient.
+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.
@@ -14,8 +14,12 @@ Before consequential unattended work, qualify a small disposable fixture project
 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

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

@@ -76,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.

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

@@ -15,7 +15,7 @@ Read the shared [Execution Contract](../coordinator/references/execution-contrac
 
 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 nested tools/capacity and inherited restrictions before dispatch; do not create another coordinator or orchestrator layer. If required tools are unavailable, hold the assignment and report a direct/manual alternative, never omit independent validation or change models as an implicit fallback.
+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
 
@@ -123,11 +123,11 @@ For each authorized ready unit within the assignment (validation-only gates need
 
 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, a blocked return or assignment end, transfer required responsibilities and retire descendants: stop further assigned work, remove them from dispatch and close when supported. If closure is unavailable, establish inactivity and record retained slots/processes; do not claim interruption closed a worker or released resources. Preserve held source/evidence and record any retention exception with purpose/release condition. Return descendant identities so coordinator retirement 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.
+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
 
@@ -211,7 +211,7 @@ 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, blocker reporting and required safety/resource checks remain required. Apply the shared execution contract's communication boundary: routine in-scope corrections stay here, and user updates do not trigger descendant polling.
+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.
 

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

@@ -303,9 +303,9 @@ For a coordinator launch, delegate global scheduling/status and shared-resource
 
 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 lifecycle: retain same-chunk repair continuity without writes during validation; verify writer cessation and ownership transfer before replacement. Retire the complete subtree after the bounded result and transfer resources/holds. Runtime inactivity does not prove capacity or process release. 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.
+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 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.
+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`.
 

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

@@ -99,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