Refine worker lifecycle and review efficiency; preserve resource safeguards; release staged-implementation 0.1.5

.nvmrc

@@ -0,0 +1 @@
+22

AGENTS.md

@@ -0,0 +1,38 @@
+- Before doing anything get general project context by reading README.md and plugins/staged-implementation/README.md
+
+- Always make a Plan before implementing. 
+
+  For example:
+
+  • Updated Plan
+    └ Created an implementation plan for WsLite integration and wiring in Bootstrapper.
+      □ Add WsLite module in brain-core
+      □ Implement broadcast binding (guarded)
+      □ Register WsLite in Bootstrapper
+      □ Set ui_state callback (g_ota_bs)
+      □ Remove stub and adjust flags
+      □ Sanity compile Bootstrapper target
+      □ Update docs on flags/endpoint
+
+- Always favor a clean implementation or fix over a quick fix or bandaid solution
+
+When asked for a commit message always provide a oneline commit message and separate sentences with `;`
+
+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.
+
+## Change Discipline
+
+- If the prompt is a question and verifying in-repo first would improve answer quality, do so.
+- Treat questions, observations, and suggestions as analysis-only; only implement changes when the user explicitly says to implement/apply a patch.
+- No freeform edits: use apply_patch with ≥3 context lines; keep diffs surgical; do not mix unrelated changes.
+- Use spaces (no tabs) for indentation; keep indentation consistent with surrounding code and avoid whitespace-only churn in diffs
+- Plan discipline: keep update_plan synced; exactly one step in_progress; revise when scope shifts.
+- Ambiguity rule: if any symbol/endpoint/data source is unclear, stop and ask — do not guess.
+- Preserve contracts: do not change public API schemas, event semantics, or observable behavior unless explicitly requested.
+- Minimal glue: add only imports/exports/helpers strictly required for the change; no opportunistic refactors.
+- Validate changes: build/typecheck affected targets and run quick verifications relevant to the edit.
+- No legacy/backward‑compat migrations or auto‑fallback heuristics unless explicitly requested.
+- Do not change route paths, auth checks, or CORS policy unless explicitly in scope.
+- Clean cutover only by default; never implement legacy/dual-format parsing or fallback behavior unless explicitly requested.

README.md

@@ -1,6 +1,6 @@
 # Arcana Codex Plugins
 
-This repository is a Codex plugin marketplace for Arcana workflows.
+Codex plugin marketplace for reusable agent workflows.
 
 ## Included Plugins
 
@@ -11,7 +11,7 @@ This repository is a Codex plugin marketplace for Arcana workflows.
 Add this Git repository as a Codex marketplace:
 
 ```bash
-codex plugin marketplace add ssh://git@your-git-server/path/arcana-codex-plugins.git --ref main
+codex plugin marketplace add dayowe/arcana-codex-plugins --ref master
 ```
 
 Install the staged implementation plugin:
@@ -41,9 +41,16 @@ plugins/
 
 ## Updating
 
-After changing a plugin, commit and push the repository, then refresh the marketplace:
+After pushing changes, refresh the marketplace snapshot:
 
 ```bash
 codex plugin marketplace upgrade arcana-codex-plugins
+```
+
+If `plugins/staged-implementation/` changed, reinstall the plugin:
+
+```bash
 codex plugin add staged-implementation@arcana-codex-plugins
 ```
+
+Start a new Codex session after reinstalling so updated skills are loaded.

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

@@ -1,6 +1,6 @@
 {
   "name": "staged-implementation",
-  "version": "0.1.0",
+  "version": "0.1.5",
   "description": "Planner, implementer, validator, and orchestrator skills for staged implementation workflows.",
   "author": {
     "name": "Local developer"

plugins/staged-implementation/README.md

@@ -31,7 +31,7 @@ staged-implementation/
 Codex installs plugins from a marketplace catalog. To publish this from Git, put the plugin inside a marketplace repository:
 
 ```text
-codex-plugins/
+arcana-codex-plugins/
   .agents/
     plugins/
       marketplace.json
@@ -50,9 +50,9 @@ Example `.agents/plugins/marketplace.json`:
 
 ```json
 {
-  "name": "my-codex-plugins",
+  "name": "arcana-codex-plugins",
   "interface": {
-    "displayName": "My Codex Plugins"
+    "displayName": "Arcana Codex Plugins"
   },
   "plugins": [
     {
@@ -76,13 +76,13 @@ Example `.agents/plugins/marketplace.json`:
 Add the marketplace repository:
 
 ```bash
-codex plugin marketplace add ssh://git@your-git-server/path/codex-plugins.git --ref main
+codex plugin marketplace add dayowe/arcana-codex-plugins --ref master
 ```
 
 Install the plugin:
 
 ```bash
-codex plugin add staged-implementation@my-codex-plugins
+codex plugin add staged-implementation@arcana-codex-plugins
 ```
 
 Start a new Codex session after installation so the bundled skills are available.
@@ -105,11 +105,27 @@ The usual flow is:
 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.
 
+## 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.
+- 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.
+- 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.
+- Read the resource reference for initial persistence verification before edits and before substantial allocations (including large builds in the main checkout), worktree/resource management or cleanup. Reuse applicable instructions and verified setup rather than reloading them for routine steps.
+
+These are efficiency rules, not acceptance shortcuts. Required independent validation, fresh gates, contract checks and evidence remain mandatory where the task requires them.
+
 ## Notes
 
 - 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.
+- 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.
 
 ## Development
@@ -126,4 +142,6 @@ Validate an individual skill:
 python3 /path/to/skill-creator/scripts/quick_validate.py /path/to/staged-implementation/skills/planner
 ```
 
-When updating an installed local plugin, bump or cache-bust the plugin version and reinstall it from the marketplace so Codex picks up the new files.
+After pushing marketplace changes, 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/implementer/SKILL.md

@@ -20,22 +20,25 @@ Expect either:
 - a saved implementer prompt path, plus repo root when not obvious
 - or a complete in-chat implementer prompt
 
-The prompt should define scope, non-goals, requirements, invariants, validation, and test posture. If any required contract, symbol, endpoint, data source, output path, or validation target is unclear, stop and ask. Do not guess.
+The prompt should define scope, non-goals, requirements, invariants, validation, and test posture. Under orchestration it should also carry a stable `Chunk ID`, `Assignment ID`, and assignment mode (`new-chunk`, `correction`, or `replacement`) so the parent can distinguish same-chunk repair from next-chunk work. If any required contract, symbol, endpoint, data source, output path, or validation target is unclear, stop and ask. Do not guess.
 
 ## Workflow
 
 1. Read context.
    - Read project instructions first.
    - Read the supplied implementer prompt.
-   - Read only the plan, checklist, docs, source files, and tests needed for the declared chunk.
+   - Read the plan, checklist, docs, source and tests needed for the chunk using targeted searches/relevant sections; expand to full files when dependencies or findings require it. Avoid repeated unchanged dumps. Parse large logs/JSON programmatically where useful without hiding relevant evidence.
 
 2. Make a plan before implementation.
    - Use `update_plan` for non-trivial work.
    - Keep exactly one step in progress.
    - Revise the plan when scope or findings change.
+   - Before the first edit, verify source workspace and backing Git metadata are persistent, not `/tmp`, memory-backed or automatically cleaned storage. Use the assigned workspace or suitable existing checkout; never move unique edits into a disposable build copy. When isolation needs a new location without an established convention/authorization, ask the parent (or user when standalone) to resolve it before creation. Nested worktree paths must be ignored and untracked in the containing repository and protected from broad cleanup. Keep new/untracked source and required evidence durable as produced; do not rely on transcripts or saving only at handoff.
+   - Record exact temporary paths as created, purpose/owner and remaining consumers in the existing handoff. Check target-filesystem headroom before large builds/installations/copies; hold unsafe allocations and report insufficient space. Reuse compatible environments only when isolation and candidate identity remain intact.
+   - Coordinate large allocation starts with the parent and report completion/retained bytes; recheck after substantial allocations. Defaults unless explicitly overridden: below 5 GiB free report/serialize large allocations; 2 GiB or less pause write-heavy work and report a blocker. Admission must leave more than the critical reserve after combined remaining peak usage, not merely pass an independent free-space check. Outside orchestration, apply the same checks to known competing allocations and serialize when uncertain.
 
-3. Extract contracts before coding.
-   - For contract-heavy chunks, write down the required MUSTs, invariants, exact fields, response shapes, event semantics, error mappings, persistence formats, and non-goals before editing.
+3. Verify contracts before coding.
+   - For contract-heavy chunks, verify an existing applicable checklist against authoritative MUSTs, invariants, exact fields, response shapes, event semantics, error mappings, persistence formats and non-goals. Reuse it when complete; add missing requirements or create one if none is suitable. An omitted invariant still applies. Share requirement IDs but keep this pass's findings/evidence separate from independent validation.
    - Treat those requirements as the acceptance checklist for the diff.
    - Do not use placeholders such as "same as today" for contract behavior in code or tests.
 
@@ -51,10 +54,14 @@ The prompt should define scope, non-goals, requirements, invariants, validation,
    - Never revert unrelated dirty changes.
 
 5. Validate.
+   - Before expensive checks, preflight working directory/paths, tool versions, generated-input prerequisites and relevant file-type/symlink handling; reuse verified setup and recheck changed or uncertain assumptions. Derive intended assertions from frozen contracts and use source for implementation facts; investigate disagreement rather than making tests mirror a defect. Reuse applicable harness/verification helpers and candidate input records; create only the smallest missing helper when needed. Preflight does not replace behavioral tests.
+   - Batch compatible independent checks, preserving each underlying operation's exit status and success/failure/timeout/cancellation/unexecuted result. Shared fixtures, ports, generated files or build destinations require sequencing unless isolation is established; respect candidate and allocation boundaries. Keep required full logs durable, return concise results and inspect failures. Filtering/parsing success or no matching error text does not establish a pass; surface incomplete output/parser failures and inspect raw evidence as needed.
    - Run the validation commands requested in the prompt when feasible.
    - Run targeted additional checks only when they directly reduce risk for the edited surface.
+   - For corrections, identify affected behavior/consumers and rerun affected checks. Reuse evidence only when the assignment permits it and relevant inputs still match; retain original limits. Rerun if applicability is uncertain. Never skip a required fresh check or broaden into unrelated matrices/harnesses.
    - If a command must be adjusted, report the exact adjustment and why.
    - If validation cannot run, report the blocker clearly.
+   - On critical disk space or disk-full/quota/inode errors, stop affected writes and safely halt owned write-heavy operations; report immediately, without retrying or deleting beyond the assigned cleanup scope. After safe headroom is restored, inspect incomplete outputs and rerun affected checks against the identified candidate. Preserve user pauses and recovery evidence.
 
 6. Self-audit.
    - Inspect the actual diff before finishing.
@@ -64,14 +71,22 @@ The prompt should define scope, non-goals, requirements, invariants, validation,
    - Confirm unaffected behavior was preserved when the prompt requires it.
 
 7. Report results.
+   - Echo the supplied chunk/assignment IDs and assignment mode when present.
    - Summarize changed files and behavior.
-   - List validations run and their results.
+   - 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.
    - List blockers, ambiguities, or residual risk.
-   - Include the requested contract verification matrix for contract-heavy chunks.
+   - 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.
 
 ## Implementation Rules
 
+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.
+
+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.
+
 - Treat questions, observations, and suggestions as analysis-only unless the user explicitly asks for code or patches.
 - Stop on ambiguity instead of choosing a reasonable-looking contract.
 - Keep diffs surgical and localized.
@@ -96,10 +111,14 @@ Do not silently broaden the test strategy in a way that changes project structur
 
 Keep the final response concise and factual:
 
+- ready for review | blocked | incomplete; candidate baseline plus scoped changes/build identity as applicable, not self-acceptance
+- chunk/assignment IDs and assignment mode when supplied
 - changed files and behavior
-- validation results
+- fresh/reused validation, failures and missing evidence
 - blockers, ambiguities, or residual risk
-- contract verification matrix when requested
+- owned-resource retention/release needs and accessible evidence links, including a required matrix unless explicitly requested in full
 - proposed commit message
 
+Omit empty optional sections. A compact return is a navigation aid, not a substitute for the parent's actual-diff review or acceptance checks.
+
 When asked for a commit message, provide a one-line message. If multiple sentence-like clauses are needed, separate them with semicolons. Do not invent a chunk ID; use one only when the prompt or task packet defines it.

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

@@ -1,6 +1,6 @@
 ---
 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: 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: "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."
 ---
 
 # Orchestrator
@@ -20,15 +20,19 @@ 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
 - plan path
 - implementation checklist path
 - prompt map path
+- readiness audit path or permission to create/update one beside the plan/checklist
 - prompt output directory or naming convention
 - validation expectations
-- whether commits are authorized
+- commit policy: `authorized-for-accepted-chunks`, `ask-before-each-commit`, or `do-not-commit`
+- cleanup scope/restrictions and retained evidence/recovery requirements, using the routine run-owned default below when temporary resources are used
 - stopping conditions
 
-If any required path, contract, data source, validation target, or output location is unclear, stop and ask. Do not guess.
+Resolve required paths and output locations from explicit instructions and established repository/workflow conventions first. For saved prompts, use the identified companion plan/checklist location and a descriptive filename if no narrower convention exists; state the chosen path and do not overwrite unrelated artifacts. Ask when a required location cannot be established or conflicting instructions remain. Do not guess unresolved contracts, data sources or validation targets.
+Resolve and normalize commit authorization under **Commit Rules** before implementation. A missing literal policy label does not require clarification when existing instructions already establish its meaning.
 
 ## Authority Boundaries
 
@@ -36,68 +40,121 @@ If any required path, contract, data source, validation target, or output locati
 - 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.
-- Commit only when the user explicitly authorizes committing accepted chunks.
+- Commit only according to the explicit commit policy.
 - Do not push, reset, discard, or revert unrelated changes unless explicitly asked.
 - Stop on contract ambiguity instead of pushing an implementer to guess.
 
 ## High-Level Loop
 
-For each ready chunk:
+Before delegating implementation, run a readiness preflight:
 
 1. Establish current state.
    - Read project instructions first.
-   - Read the plan, checklist, prompt map, recent review notes, and relevant git/worktree state.
-   - Identify the next ready chunk from the checklist and prompt map.
+   - 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.
+   - 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.
+   - 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.
+   - Surface all contract blockers and small freezes to the user before implementation starts.
+   - 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:
+
+2. Select the next chunk.
+   - Identify the next ready chunk from the checklist, prompt map, and readiness audit.
    - 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.
 
-2. Write the implementer prompt.
+3. Write the implementer prompt.
    - Produce one surgical prompt for that chunk only.
+   - Give the pass a stable `Chunk ID`, `Assignment ID` and mode under **Run State and Worker Lifecycle**.
    - Save official prompts beside the companion plan/checklist unless the user requests another output path.
    - Re-read the saved prompt before delegating.
 
-3. Delegate implementation.
+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`.
+   - 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.
 
-4. Review the result.
+5. Review the result.
    - Inspect the actual diff/worktree, not just the sub-agent summary.
    - Compare against the frozen plan, checklist, prompt, and declared scope.
    - Verify the implementer's self-audit claims against the diff.
    - Lead review with findings ordered by severity.
    - Save or update review outcomes beside the companion plan/checklist when the run is maintaining staged workflow artifacts.
 
-5. Handle review outcome.
-   - If contract ambiguity exists, stop and identify the exact missing decision.
+6. Handle review outcome.
+   - If contract ambiguity exists, hold the affected chunk and identify the exact missing decision; apply **Stopping Conditions** before continuing other work.
    - If implementation violates the prompt or frozen contracts and the docs are clear, write a surgical follow-up prompt.
-   - Send the follow-up to the same implementer sub-agent when continuity helps; spawn a new implementer if a fresh pass is safer.
+   - Reuse the designated repair agent when continuity helps; if a fresh pass is safer, follow the replacement ownership-transfer procedure under **Run State and Worker Lifecycle** before permitting edits.
    - Repeat review/follow-up until accepted, blocked, or stopped by the user.
 
-6. Validate when evidence is required.
+7. Validate when evidence is required.
    - Run direct validation yourself for simple build, test, or diff checks.
+   - Keep direct checks on the same stable-candidate/provenance boundary required below for delegated validation.
    - 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 frozen plan/checklist/prompt/review findings and exact validation target.
+   - 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.
 
-7. Accept the chunk.
-   - Confirm required validation passed or that the user accepted the validation gap.
+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.
+   - Establish that candidate source/diff and relevant build still match the reviewed/validated identity, reusing verified continuity under the provenance rule below where applicable; changes invalidate affected evidence until reconciled and revalidated.
    - Confirm no out-of-scope work remains.
-   - Commit only if the user authorized commits.
+   - Apply the explicit commit policy.
    - 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.
 
-8. Continue.
-   - Update or report checklist, prompt-map, and review-outcome state as appropriate.
+9. Continue.
+   - 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.
+   - Reconcile temporary-resource ownership/retention and perform eligible authorized cleanup under **Resource Lifecycle** before the next large allocation.
    - Choose the next ready 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.
+
+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.
+
+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.
+
+## 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.
+
+- chunk ID/name
+- readiness classification: `ready`, `blocked-by-contract-decision`, `blocked-by-dependency`, `blocked-by-environment`, or `needs-small-freeze-before-prompt`
+- exact missing decision, dependency, or environment blocker
+- why an implementer must not decide it
+- recommended default when the written docs support one
+- options and tradeoffs when the user must decide
+- plan/checklist/prompt-map updates required after the decision
+
+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.
+
+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.
+
 ## Prompt Writing Rules
 
 Every implementer prompt must include:
 
 ```text
 Repo root:
+Chunk ID:
+Assignment ID:
+Assignment mode: new-chunk | correction | replacement
 Read these first:
 Task:
 Scope for this pass:
@@ -126,23 +183,30 @@ Every implementer prompt must require:
 For contract-heavy chunks, require:
 
 ```text
-Before coding, extract the explicit MUST / invariant / field / response-shape / event / error-mapping requirements into a concrete checklist.
-After coding, audit the actual diff against that checklist before finishing.
-In the final summary, include a contract verification matrix and explicitly confirm no out-of-scope work was included.
+Before coding, verify an existing applicable checklist against authoritative MUST / invariant / field / response-shape / event / error-mapping requirements. Reuse it when complete; add missing requirements or create a checklist if none is suitable.
+After coding, audit the actual diff against those requirements. Shared requirement IDs do not merge implementer and independent-validator findings/evidence; keep each pass attributable and investigate obligations outside the checklist.
+Keep the contract verification matrix in durable evidence and link it in the final summary, with blocking findings, missing evidence and scope deviations visible. Include the full matrix in the response if explicitly requested; verify linked artifacts exist and are accessible.
 ```
 
 Keep the implementer `Read these first:` list focused:
 
 - include project instruction/context docs required by the repo
-- include the feature plan
+- include relevant feature-plan sections, not unrelated phases/history
 - include the implementation checklist only when it adds chunk-relevant boundaries or state not restated in the prompt
 - include chunk-specific docs/artifacts the implementer actually needs
+- identify the current authoritative reading path, including any still-binding amendments; keep historical evidence accessible without routinely loading superseded narratives. Expand inspection when dependencies or findings require it.
 - do not include the prompt map by default
 - do not include planner/reviewer/orchestrator process docs
 - do not list the prompt file itself in its own `Read these first:` block
 
 ## Delegation Rules
 
+For new implementer and independent-validator assignments, default to fresh scoped context without full parent-history inheritance when supported; explicitly select the supported no-history setting rather than relying on tool defaults. Carry the task, applicable instructions/contracts, candidate identity, source locations, known findings, dependencies, validation obligations and authority. Context selection is separate from model selection: explicitly preserve authorized model/effort through supported controls if changing context mode changes defaults; never silently substitute a configuration for smaller context. If scoped context is unavailable, use supported controls while preserving required independence and obligations. Reuse an appropriate worker for bounded same-assignment corrections; use a fresh worker when independence, persistent misunderstanding or stale context warrants it, not because a fixed context threshold was crossed.
+
+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.
+
 When spawning an implementer sub-agent:
 
 - start with a fresh sub-agent for each new chunk by default
@@ -151,21 +215,54 @@ When spawning an implementer sub-agent:
 - 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
+- assign the verified persistent source workspace and evidence destinations; workers must not relocate implementation into disposable storage
+- pass cleanup scope, retention requirements and disk/allocation restrictions; require workers to report exact owned resource paths and outstanding consumers on handoff
 - avoid delegating planner/reviewer decisions
 - wait only when the result is needed for the next critical-path step
-- close sub-agents when their chunk is accepted or permanently blocked
 
-If sub-agent edits are not visible in the main workspace after completion, stop and report the integration limitation instead of reviewing a summary as if it were a diff.
+If sub-agent edits are not inspectable as the actual candidate diff, hold that chunk and report the integration limitation instead of reviewing a summary as if it were a diff. Apply **Stopping Conditions** before continuing other work.
 
 When invoking a validator pass:
 
 - instruct it to use `$validator`
-- provide the exact expected behavior, frozen contracts, and validation target
+- 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
 - provide approved credential or environment sources only when needed
+- pass persistent evidence/recovery destinations and identify the durable source behind any disposable validation copy
+- pass the run's bounded cleanup scope and any restrictions, retention requirements, disk thresholds and allocation restrictions; require owned-resource handoff
 - ask for pass/fail/blocked evidence, residual risk, and untested areas
 - do not ask the validator to edit production code or commit
 - review the validator's evidence before accepting the chunk
 
+Use lightweight provenance sufficient to identify what was tested, such as a scoped diff/input digest and build identifier; do not require exhaustive repository/dependency hashing by default. Establish identity at validation entry. Verification can cover adjacent reporting, acceptance and commit boundaries when controlled ownership and applicable change checks demonstrate unchanged source, relevant inputs and build; a prior agent's claim alone is insufficient. Do not automatically rescan full inventories at every boundary. Mutation, interruption that makes continuity uncertain, or other identity uncertainty requires renewed verification. If relevant inputs change during a pass, stop affected validation, preserve the old evidence with its limits, and establish the corrected candidate before revalidation. Non-overlapping work is safe only when it cannot alter those inputs, target or results.
+
+## Review and Validation Effort
+
+Efficiency changes organization and communication, not what must be understood, implemented or proven. Required correctness and acceptance obligations take priority over token savings; do not impose token/turn caps that force incomplete work.
+
+Keep roles distinct: implementer self-audit; parent actual-diff/integration/contract review; validator independent checks of assigned behavior/risks. Do not automatically add a general reviewer for each correction. Reuse a validator for bounded corrections while context remains valid; a changed mechanism, disputed finding, new risk or explicit gate may require a fresh challenge. All mandated independent reviews remain required.
+
+For parent review, start with the actual scoped diff, frozen requirements and relevant evidence. Inspect surrounding code, callers and shared behavior as needed to assess impact; do not wait for a discovered defect to justify broader reading. Avoid repeatedly rereading unchanged full files or rerunning successful worker checks merely to restate evidence. Run parent-owned checks when required for acceptance, when worker evidence is missing/stale/uncertain, or when an independent check directly reduces a concrete risk.
+
+Reuse reliable verification helpers and a canonical candidate-scoped input record where useful; verify their coverage/applicability rather than rebuilding them per worker. Keep prior candidate provenance intact when inputs change, and keep concurrent candidates separate. Create only the smallest missing helper when justified, not a mandatory evidence framework. Before expensive checks, preflight relevant paths, tool versions, generated prerequisites and file-type/symlink handling. Recheck changed or uncertain setup; preflight does not replace behavioral assertions. Validators independently verify inputs and expected outcomes against the frozen contract, not an unexamined helper or previous verdict.
+
+For same-contract corrections, reference the original assignment and current candidate, then send the concrete finding, affected scope, required revalidation and proposed evidence reuse. Do not regenerate valid assignments, matrices, environment audits or evidence packages. A replacement worker needs enough baseline context to interpret the delta. Group coherent findings from the current review when practical, but report urgent safety/contract blockers immediately. Reuse only after verifying relevant source, harness, dependencies, build configuration and environment match, preserving original limits. A commit ID alone is insufficient. Rerun if applicability is uncertain; shared owners/styles may affect many consumers. Required fresh checks cannot be skipped.
+
+Use targeted searches/relevant sections and programmatic extraction from large logs/JSON; expand to full files or raw evidence when needed. Avoid repeatedly dumping unchanged documents, inventories or successful logs into model context. Store required full logs durably and return concise results with failures, limitations and paths. Capture the underlying operation's exit status, not only a filter/parser's success; distinguish success, failure, timeout, cancellation and unexecuted work. Incomplete output or parser failure must be surfaced and investigated, never treated as a clean pass.
+
+Batch compatible independent reads/mechanical checks and inspect every result together. Preserve individual statuses; tests sharing ports, fixtures, generated files or build destinations remain sequential unless isolation is established. Keep dependent edits, mutations, approvals and decisions sequential. Apply existing candidate-freeze and disk-allocation rules; do not hide failures inside a large command batch. Use browser inspection for relevant visual/focus behavior and discrepancies rather than automatically repeating the full matrix with every tool. Retain every required case at its assigned gate and all mandated fresh checks; local/reused evidence cannot silently pass a later platform gate.
+
+Report concise differences, counts, failures, skipped/not-tested obligations, evidence limits and artifact paths; retain raw logs/artifacts and inspect unexpected output. Link any existing canonical input record and detailed results instead of regenerating/reproducing unchanged inventories, hashes or packages. Apply process improvements prospectively; do not reorganize historical evidence merely to match a new convention. Briefly record causes of recurring setup failures or reasons for repeated checks in the existing report, not a new tracking system. Efficiency does not authorize model changes, missed cases, weaker contracts or unsafe rollback.
+
+## Resource Lifecycle
+
+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.
+
+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.
+
 ## Review Rules
 
 Review against:
@@ -195,37 +292,72 @@ If there are no findings, state an acceptable verdict clearly before summaries.
 
 ## Commit Rules
 
-Commit accepted chunks only when the user has explicitly authorized commits for the run.
+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`
+- `ask-before-each-commit`
+- `do-not-commit`
+
+Resolve the policy from current user instructions, still-applicable earlier explicit authorization for this run, or an unambiguous project/workflow policy. Normalize clear ordinary language into a supported value and record it with its source in the handoff or current execution record. Later explicit instructions take precedence. Do not ask the user to repeat authorization or spell the exact label.
+
+For example, "commit each accepted chunk after validation" authorizes `authorized-for-accepted-chunks`; "ask me before every commit" means `ask-before-each-commit`; "do not commit" means `do-not-commit`. General permission to implement, a hypothetical workflow example, or permission for a single commit does not authorize committing all chunks.
+
+If authority remains missing, conflicting or ambiguous after checking those sources, stop and ask before starting implementation. Do not invent a default. A normalized commit policy does not override a user pause or authorize pushing, publishing or unrelated changes.
+
+For `authorized-for-accepted-chunks`:
+
+- commit after each accepted chunk once review and required validation pass
+- never commit unrelated dirty changes
+- use one-line commit messages with the chunk ID prefix when one exists
+
+For `ask-before-each-commit`:
+
+- stop after each accepted chunk
+- report the proposed one-line commit message
+- ask the user before committing
+
+For `do-not-commit`:
+
+- do not commit
+- report the proposed one-line commit message for each accepted chunk
+
+If the user explicitly approves a validation exception, first record its exact scope, residual risk and missing evidence as a change to the acceptance contract. It is not a PASS for the omitted check, does not waive other gates, and cannot override higher-priority safety/authority constraints. Efficiency or permission to continue working is not such an exception.
 
 Before committing:
 
-- inspect the diff
+- inspect the exact staged diff against the accepted scope, including the absence of held/unrelated work
+- establish that staged content and relevant build match the accepted candidate identity; verified continuity may cover adjacent boundaries without another full inventory/hash scan or test run, but never replaces staged-diff inspection. Renew verification when identity is uncertain and resolve affected evidence mismatches before committing
 - confirm the reviewed chunk is acceptable
-- confirm validation passed or that the user accepted the validation gap
+- confirm required validation passed under the current recorded acceptance contract
 - confirm no unrelated changes are included
 - use a one-line commit message
 - preserve the chunk ID prefix when one exists
 - separate sentence-like clauses with semicolons when needed
 
-Do not commit if:
+Do not commit the target chunk if:
 
 - review findings remain
 - a contract ambiguity is unresolved
-- required validation failed or could not run
+- validation required by that acceptance contract failed or could not run
 - unrelated dirty changes cannot be separated safely
-- the user did not authorize commits
+- the commit policy is `do-not-commit`
+- the commit policy is `ask-before-each-commit` and the user has not approved that specific commit
+- commit authority remains unresolved or cannot be normalized to a supported policy
 
 ## Stopping Conditions
 
-Stop and report clearly when:
+Hold the affected chunk and its dependents, leaving them unaccepted, when:
 
-- a contract, symbol, endpoint, data source, or output path is ambiguous
+- a contract, symbol, endpoint or data source is ambiguous, or a required output location remains unresolved after checking instructions and established conventions
 - the plan/checklist/prompt map disagree and the correct contract cannot be inferred from written docs
+- a `needs-small-freeze-before-prompt` decision affects the next implementation path
 - implementation needs scope widening
-- validation cannot run and the risk cannot be resolved locally
+- required validation fails or cannot run at that chunk's assigned gate
 - sub-agent changes are not inspectable as an actual diff
-- no ready chunks remain
-- all chunks are complete
+
+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.
+
+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.
 
 ## Final Response
 
@@ -233,6 +365,7 @@ For each orchestration run, report:
 
 - chunks completed
 - chunks blocked and why
+- readiness audit status
 - commits made, if any
 - validations run
 - residual risk

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

@@ -0,0 +1,33 @@
+# Orchestrator 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.
+
+## Persistent Workspaces
+
+Unfinished source must live on persistent storage from the first edit. Verify resolved workspace paths and backing Git/common-directory storage are not temporary, memory-backed or subject to automatic cleanup; a persistent-looking name or `.git` file alone is insufficient. The current checkout may itself be a worktree. Use it for safe sequential work; use isolated worktrees when delegation/concurrency or candidate isolation requires them. Prefer the project's established persistent worktree location. If none is suitable or already authorized, propose one dedicated location and ask once before creation; do not automatically scatter siblings or use `/tmp` as a fallback. Reuse the chosen location and same-chunk workspace; create only needed worktrees.
+
+Nested worktrees are allowed only when their paths are ignored and untracked in the containing repository. Verify both before creation; do not force-add them. Ignore rules prevent ordinary staging, not deletion: protect worktree containers and shared Git metadata from broad cleanup, including `git clean -fdx`, and never remove a containing checkout while nested worktrees or dependent Git metadata remain needed. Record workspace/common-directory paths, owners and consumers in the existing durable handoff. Preserve unfinished/held candidates; release integrated worktrees only after the retention and cleanup checks below pass.
+
+Reserve `/tmp` and other disposable storage for reproducible resources. A disposable build/test copy requires a complete persistent source candidate, including staged, unstaged, new/untracked files and required local inputs, with provenance linking the copy to it. No unique implementation edits belong there. Write required evidence and recovery artifacts to persistent destinations as produced, rather than waiting for acceptance or pause. A reboot can happen between handoffs. Persistence does not require premature commits or acceptance. On resume, missing/changed source requires recovery and diff verification before continuation; transcripts/Git metadata are recovery aids, not proof of complete recovery. Reconstructed candidates require applicable revalidation before acceptance.
+
+## 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.
+
+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`.
+
+Use these disk defaults automatically unless explicit project/run instructions override them; record any override in the existing handoff. Per filesystem, below **5 GiB free** means report low headroom and serialize large allocations; **2 GiB or less free** means a critical disk-space blocker and pause write-heavy work. They are operating defaults, not proof that a particular build fits.
+
+Before large builds, dependency/browser installations, checkout copies or archives, the parent checks every receiving filesystem and coordinates active/planned allocations there. Admit a start only when measured free space minus their conservative remaining additional peak, including the proposed operation, stays above the critical reserve. Account for starts already authorized to other workers before authorizing another; different directories may share one filesystem. If combined peak is uncertain, serialize and reassess; if even the single operation's headroom cannot be established, hold it. Use existing handoff/assignment notes, not a quota service. Workers must coordinate additional large allocations outside their assigned scope with the parent. Prefer compatible existing environments without sharing mutable candidate inputs or violating isolation.
+
+Recheck before large allocations and after substantial allocations or cleanup, rather than after every command. Completion releases an allocation assignment, not its retained bytes: remeasure free space and account for remaining consumers before scheduling more work. No continuous monitoring system is required.
+
+At observed critical space, or any disk-full/quota/inode-exhaustion error regardless of free bytes, stop launching affected writes, safely halt affected owned write-heavy operations and immediately report the blocker. State the filesystem, available capacity/error, held operations, known run-owned resources and eligible cleanup or needed user intervention. Do not retry failed writes, launch a large emergency archive or treat partial outputs as valid evidence. Only already-authorized bounded cleanup may reclaim resources; do not invent deletion authority or override a user pause. Independent read-only work may continue only if safe and authorized; stop the run when storage pressure prevents reliable work globally. Resume affected writes only after rechecking safe headroom and allocation conditions; inspect potentially partial/corrupt outputs, restore candidate identity and rerun affected checks before acceptance.
+
+At validation release, acceptance, abandonment or pause/handoff, classify resources as still in use, retained evidence/recovery, or disposable. The parent owns disposition across workers and later gates. Preserve required raw evidence, unique failed/unfinished state, uncommitted source and rollback packages until their retention condition is resolved. A failed run need not keep every duplicate dependency tree forever, but do not discard anything needed to substantiate/reproduce findings or satisfy a pending gate.
+
+Before releasing an evidence-bearing workspace, preserve the required artifacts in the agreed durable location, verify they remain readable/identifiable, and update references. Keep original failure identity; do not leave the only evidence behind a deleted temporary path. Moving bytes to the same filesystem is not space reclamation, and copying entire disposable workspaces or committing bulky generated output is not the default preservation method.
+
+Use the run's bounded cleanup scope, carried into each assignment. Check each exact path is run-owned and within that scope, with no active process/validator, retained artifact or pending consumer depending on it. Release owned processes/handles before removal, respecting pauses and operational authority. Do not traverse symlinks/mounts into unrelated locations, clear `/tmp` broadly, delete by wildcard/prefix, or prune shared caches, files predating the run, user files or resources belonging to other runs. Worker resources may be cleaned by the parent after a recorded ownership handoff, subject to the same authorization and release checks; resources still owned by another worker remain protected. Use the owning tool's safe lifecycle for managed resources such as Git worktrees, without forced removal of uncommitted work. If ownership, retention or authority is unclear, keep the resource and ask with concrete paths/reasons.
+
+Perform eligible cleanup at lifecycle boundaries, including run completion, rather than waiting for disk pressure. After accepted integration, explicitly resolve redundant candidate/build copies: verify persistent source/evidence preservation, rollback needs and consumer release, then remove eligible copies or record a specific retention reason and release condition. An evidence archive alone does not establish disposability; uncommitted work remains protected. Record removed paths, retained paths with reasons/revisit conditions, and resulting headroom after substantial cleanup. If cleanup is blocked or a pause does not permit it, preserve the inventory for handoff; do not silently forget resources or relax acceptance to recover space. Cleanup beyond the run-owned scope requires separate authority.

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, choose the next implementation chunk, write an implementer 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, 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.
 ---
 
 # Planner
@@ -19,7 +19,7 @@ Treat questions, observations, and suggestions as analysis-only unless the user
 
 - Read the relevant plan, checklist, prompt map, surrounding code, and recent git state needed for the requested action.
 - Own design clarity, scope boundaries, staged review, and next-chunk definition.
-- Freeze contracts, invariants, schemas, routes, event semantics, error mappings, and observable behavior before implementation starts.
+- Freeze applicable contracts, invariants, schemas, routes, event semantics, error mappings, and observable behavior before their dependent implementation starts.
 - Keep chunks narrow, reviewable, and testable.
 - Review against written docs and the actual diff, not intent, summaries, or memory.
 - If a review finding exposes a real contract gap, stop treating it as implementation work and clarify the docs first.
@@ -38,11 +38,14 @@ 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
 
 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.
 
 ## Workflow
 
+Use existing artifacts when they satisfy the requested step. A scoped update or review does not require recreating the entire planning sequence.
+
 1. Prepare or read the plan.
    - Identify the design, contracts, invariants, and semantics that implementation must preserve.
    - Identify what must not be guessed during implementation.
@@ -51,29 +54,38 @@ If a path, contract, data source, diff target, or output location is required an
    - Split work into gates or chunks.
    - Keep the checklist operational, with exit criteria and validation surfaces, not aspirational.
 
-3. Choose the next chunk.
+3. Prepare or read the prompt map.
+   - Map gates/chunks to implementer prompt artifacts.
+   - Track readiness, sequencing, dependencies, and blocked chunks.
+
+4. Run the implementation readiness audit.
+   - Initially inspect every chunk in the plan, checklist and prompt map; subsequently verify changed scope and affected dependencies, broadening when shared contracts change or impact is uncertain.
+   - Surface contract blockers, dependencies, environment blockers, and small decisions that should be frozen before prompting.
+   - Resolve blockers on the intended implementation path; unrelated contract blockers require an explicitly authorized ready-subset run. Follow the readiness rules below for later engineering freezes.
+
+5. Choose the next chunk.
    - Pick one coherent behavioral, contract, or validation unit.
    - Prefer chunks that are independently reviewable and testable.
    - Define in-scope work, explicit non-goals, invariants, validation, and test posture.
 
-4. Write the implementer prompt.
+6. Write the implementer prompt.
    - Write one surgical prompt for the chosen chunk only.
    - Save official next-chunk prompts beside the companion plan/checklist unless the user explicitly asks for chat-only output or gives another path.
    - Do not save ad hoc follow-up/fix prompts unless explicitly asked.
    - Re-read any saved official prompt before finishing.
 
-5. Review implementation.
+7. Review implementation.
    - Inspect the actual diff target. Use `git diff --cached` for staged review unless the user asks for another target.
    - Compare the diff to frozen docs, the prompt, and scope boundaries.
    - Start with findings ordered by severity. If no findings exist, start with a clear acceptable verdict.
 
-6. Resolve ambiguity through docs.
+8. Resolve ambiguity through docs.
    - If docs allow multiple interpretations, identify the exact missing decision.
    - Clarify or request clarification before writing a fix prompt.
    - Do not leave important contract clarifications only in chat when docs should be updated.
 
-7. Define the next handoff.
-   - Continue only after the current chunk is accepted, corrected, or blocked on a documented ambiguity.
+9. Define the next handoff.
+   - Hand off corrections to the current chunk, or record acceptance/a documented contract, dependency or environment hold before selecting another chunk. Continue only independently authorized ready work; preserve held work and honor run-wide pauses/authority limits.
 
 ## Chunk Sizing
 
@@ -85,7 +97,7 @@ A good chunk:
 - has explicit non-goals
 - can be validated without finishing the whole feature
 - has validation commands that prove the unit, not just an internal helper edit
-- is large enough to justify a separate prompt/review cycle
+- justifies a separate prompt/review/validation cycle without combining unrelated risk or rollback boundaries
 
 Prefer merging adjacent checklist items when they:
 
@@ -102,7 +114,25 @@ Prefer splitting work when:
 - restart, migration, upgrade, rollback, or safety risk deserves isolated review
 - one part is still ambiguous while adjacent work is already frozen
 
-Do not create separate prompts just because a second file is touched, a helper is extracted, or a checklist has multiple bullets that share the same risk and validation surface.
+Do not create separate prompts just because a second file is touched, a helper is extracted, or a checklist has multiple bullets that share the same risk and validation surface. Avoid micro-chunks whose extra handoffs, fresh contexts and repeated review/validation cost more than the isolation benefit they provide.
+
+## Planning and Evidence Proportionality
+
+Give each artifact one job: plan = architecture/rationale; checklist = work/dependencies/acceptance; prompt map = assignment routing/inputs; prompt = bounded execution pass. Link authoritative contracts or restate the exact applicable subset instead of copying whole contracts into every artifact. Preserve all applicable obligations and make them accessible to a fresh worker.
+
+Efficiency changes organization and communication, not what must be understood, implemented or proven. Required correctness and acceptance obligations take priority over token savings; do not impose token/turn caps that force incomplete work.
+
+Design validation alongside chunk boundaries. Assign each obligation to the first gate that needs it: local implementation, integrated behavior, or actual platform/device/release. Record its target and prerequisites. Do not require later release evidence before a local chunk unless correctness or safe activation depends on it. An unavailable mandatory check remains pending at its assigned gate; emulation/local success cannot pass that gate.
+
+Prefer existing tests/harnesses and the smallest validation surface that credibly proves the contract. Plan a cheap setup preflight before expensive validation: working directory/paths, tool versions, generated-input prerequisites and relevant file-type/symlink handling; subsequently recheck changed or uncertain assumptions. Intended test outcomes come from frozen contracts; source establishes implementation facts, not permission to copy a defect into the expected result. Investigate disagreement. Expand for shared-owner impact or newly found risk. Do not prescribe every appearance × viewport × state combination, another harness or another general review without a coverage need. Retain required integration/independent review and any explicitly mandated matrix or fresh run unless expressly amended.
+
+Specify evidence reuse conditions: relevant source, harness, dependencies, configuration and environment must match, retaining original limits. Prefer one applicable verification helper and canonical input record per candidate over duplicate evidence packages; neither a helper nor a manifest is mandatory for a small chunk. Preserve prior candidate records when inputs change. Require trustworthy identity at handoff/reporting/acceptance/commit, not a full scan at each boundary: verified continuity can cover adjacent boundaries, while mutation or uncertainty requires renewed verification. Independent validators still verify scope/applicability and assigned behavior. A correction need not repeat unrelated builds/screenshots/reviews, but efficiency cannot weaken an acceptance case.
+
+Plan persistent implementation storage from the first edit, including backing Git metadata. Use the existing checkout for safe sequential work; when isolation is needed, prefer the project's established persistent worktree location and reuse the same workspace for same-chunk corrections. If no suitable convention or authorized location exists, propose one dedicated location and ask once before creation; never automatically create sibling directories or fall back to `/tmp`. For nested worktrees, require the paths to be ignored and untracked in the containing repository and protected from broad cleanup. Record the location in the handoff. Required evidence/recovery artifacts also need persistent destinations from creation; a pause-time copy or a transcript is not a durability strategy. This does not authorize premature commits or change acceptance gates.
+
+Plan the temporary-resource lifecycle alongside validation: identify required evidence/recovery retention, durable destinations and release conditions for disposable checkouts, builds and browser profiles. Put a compact ownership/retention record in the existing handoff, not another reporting system. Require headroom checks before large allocations and prefer compatible existing environments when reuse preserves isolation and candidate identity. Copying large workspaces elsewhere on the same filesystem does not reclaim space; generated artifacts do not belong in Git by default.
+
+Carry disk defaults into assignments without asking for routine configuration: below 5 GiB free warns/serializes large allocations; 2 GiB or less pauses write-heavy work and reports a blocker. Allow explicit project/run overrides, recorded in the handoff. Require parent coordination of concurrent additional peak usage on each receiving filesystem so admitted operations leave more than the critical reserve; disk-full/quota/inode errors stop affected writes regardless of thresholds.
 
 ## Checklist Artifacts
 
@@ -114,8 +144,9 @@ When asked to write or update an implementation checklist from a plan, make it o
 - frozen contracts, invariants, exact fields, routes, states, event semantics, persistence formats, and error mappings
 - implementation tasks grouped by behavior or contract surface
 - exit criteria
-- validation commands or validation posture
+- validation commands/posture, acceptance level and required environment; distinguish local, integration and platform/release gates
 - test posture: extend existing tests, add minimal local tests, or no new test harness
+- temporary-resource ownership, retained evidence/recovery needs and cleanup boundary when large disposable resources are expected
 - ambiguity/blocker notes with the exact missing decision
 
 Do not promote every plan bullet into a separate chunk. Apply the merge/split rules before finalizing the checklist.
@@ -136,6 +167,38 @@ When asked to write or update a prompt map, map checklist gates/chunks to implem
 
 Use the prompt map to preserve sequencing for the planner/reviewer. Do not include the prompt map in downstream implementer prompts by default unless the chosen chunk uses prompt-map readiness or may update the prompt map.
 
+## Readiness / Ambiguity Audit
+
+After the plan, checklist and prompt map exist, audit all chunks once before the first implementer prompt or orchestration, including major feasibility risks and environment availability. Reuse a current audit; subsequently inspect changes and affected dependencies instead of repeating the entire audit. Broaden when a shared contract changes or the affected scope cannot be established.
+
+Classify every chunk as one of:
+
+- `ready`
+- `blocked-by-contract-decision`
+- `blocked-by-dependency`
+- `blocked-by-environment`
+- `needs-small-freeze-before-prompt`
+
+For every non-ready or weakly-ready chunk, produce a decision ledger entry with:
+
+- chunk ID/name
+- exact missing decision, dependency, or environment blocker
+- why the implementer must not decide it
+- recommended default when the written docs support one
+- options and tradeoffs when the user must decide
+- plan/checklist/prompt-map updates required after the decision
+
+One shared blocker can name all affected chunks. Dependency-only holds need the missing predecessor and acceptance link, not a repeated options/decision essay.
+
+Before implementation starts, require one of these outcomes:
+
+- contract blockers are resolved and the intended chunk's required engineering freezes are written into the authoritative artifacts
+- or the user explicitly authorizes starting only the `ready` subset while unrelated contract-blocked chunks remain held
+
+Schedule later mechanism freezes before their first dependent chunk, using actual predecessor code. Incomplete later implementation detail need not block independent ready work; investigate architectural feasibility and irreversible migration risks early. Never relabel an unresolved product/API contract as a routine engineering choice to bypass approval.
+
+Do not treat dependency-pending chunks as contract-ambiguous unless a missing decision blocks their future prompt. Summarize actual blockers clearly. Each further experiment should identify the question and an observation that distinguishes mechanisms. If equivalent experiments cannot resolve it, report the blocker/decision and continue only independently authorized ready work.
+
 ## Implementer Prompt Rules
 
 Before writing the prompt:
@@ -143,15 +206,18 @@ Before writing the prompt:
 - verify the correct next chunk from the checklist, prompt map, recent git history, and current worktree state when available
 - use `git status --short` and relevant `git log --oneline` checks before claiming a chunk is next, landed, or ready for review
 - state which chunk you chose and why
+- verify readiness covers the intended chunk and current dependencies; update affected entries, or complete the initial audit if missing
+- do not write an execution prompt for a chunk affected by unresolved `blocked-by-contract-decision` or `needs-small-freeze-before-prompt` items; ready-subset authorization permits only unaffected ready chunks
 - stop if an ambiguity blocks an implementer-quality prompt
 - include current-state context only to the extent needed for the implementer to execute the chunk without relying on prior chat memory
 
 Keep the implementer `Read these first:` list focused:
 
 - include project instruction/context docs required by the repo
-- include the feature plan
+- include relevant feature-plan sections, not unrelated phases/history
 - include the implementation checklist only when it adds chunk-relevant boundaries or state not restated in the prompt
 - include chunk-specific docs/artifacts the implementer actually needs
+- identify the current authoritative reading path, including any still-binding amendments; keep historical evidence accessible without routinely loading superseded narratives. Expand inspection when dependencies or findings require it.
 - do not include the prompt map by default; it is mainly a planner/reviewer sequencing artifact
 - do not include planner/reviewer process docs by default
 - do not list the prompt file itself in its own `Read these first:` block
@@ -160,6 +226,9 @@ Use this prompt structure unless the user explicitly requests a different shape:
 
 ```text
 Repo root:
+Chunk ID:
+Assignment ID:
+Assignment mode: new-chunk | correction | replacement
 Read these first:
 Task:
 Scope for this pass:
@@ -189,15 +258,73 @@ Every implementer prompt must carry these default requirements unless the task p
 For contract-heavy chunks, add a contract checklist and self-audit requirement:
 
 ```text
-Before coding, extract the explicit MUST / invariant / field / response-shape / event / error-mapping requirements into a concrete checklist.
-After coding, audit the actual diff against that checklist before finishing.
-In the final summary, include a contract verification matrix and explicitly confirm no out-of-scope work was included.
+Before coding, verify an existing applicable checklist against authoritative MUST / invariant / field / response-shape / event / error-mapping requirements. Reuse it when complete; add missing requirements or create a checklist if none is suitable.
+After coding, audit the actual diff against those requirements. Shared requirement IDs do not merge implementer and independent-validator findings/evidence; keep each pass attributable and investigate obligations outside the checklist.
+Keep the contract verification matrix in durable evidence and link it in the final summary, with blocking findings, missing evidence and scope deviations visible. Include the full matrix in the response if explicitly requested; verify linked artifacts exist and are accessible.
 ```
 
 End implementer prompts by asking for a proposed commit message. When a chunk ID exists, require the commit message to start with that chunk ID prefix.
 
 When the user asks the planner for a commit message, output a one-line commit message. If multiple sentence-like clauses are needed, separate them with semicolons.
 
+## Planning Checkpoint Before Orchestration
+
+At the final handoff to start orchestration, verify that the reviewed planning package is committed. Do not interrupt ordinary plan/checklist/prompt-map drafting or review with checkpoint requests. Finish the requested documents and applicable checks first, then inspect the exact staged, unstaged and untracked planning changes. If a checkpoint is missing and no applicable authorization exists, identify the proposed files and one-line commit message, explain that the planning baseline is uncommitted, and ask whether to commit it before orchestration. The handoff may be prepared, but must not claim this boundary is resolved while the answer is pending.
+
+Reuse explicit planning-checkpoint authorization already granted; otherwise ordinary planning work or permission to start orchestration does not itself authorize that commit. Keep planning-document authorization separate from the implementation-chunk commit policy: neither implies the other. Commit only reviewed planning changes within the authorized scope, preserving unrelated changes, and verify the resulting commit covers the intended baseline. Report its commit ID with the final handoff; no document needs to embed its own commit hash.
+
+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
+
+When asked to write, produce, or prepare an orchestrator prompt, treat it as an official durable handoff artifact, not casual chat output.
+
+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.
+
+Every orchestrator prompt 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
+- plan path
+- implementation checklist path
+- prompt map path
+- readiness audit path or permission to create/update one beside the plan/checklist
+- prompt output directory or naming convention
+- validation expectations
+- commit policy
+- planning checkpoint status: verified baseline or explicit uncommitted disposition under **Planning Checkpoint Before Orchestration**
+- cleanup scope: routine run-owned cleanup default, applicable restrictions, required retention and resource handoff
+- 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.
+
+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.
+
+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`.
+
+The commit policy must be explicit and must use one of:
+
+- `authorized-for-accepted-chunks`
+- `ask-before-each-commit`
+- `do-not-commit`
+
+Resolve commit behavior from the user's current instructions, still-applicable earlier explicit authorization for this run, or an unambiguous project/workflow policy. Normalize clear ordinary-language instructions to one of the supported values and briefly identify their source in the handoff. The user need not supply the exact label. Later explicit instructions take precedence; do not ask again for authorization already given and not withdrawn.
+
+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:
+
+```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.
+```
+
+For `ask-before-each-commit`, require the orchestrator to stop after each accepted chunk and ask before committing.
+
+For `do-not-commit`, require the orchestrator to avoid commits and report the proposed one-line commit message for each accepted chunk.
+
 ## Prompt Output Hygiene
 
 Before presenting or saving a prompt:
@@ -228,6 +355,8 @@ A review outcome should capture:
 - validation status and residual risk
 - next recommended action
 
+Maintain one current outcome per chunk and one live execution handoff. Link raw evidence and distinct reviewer verdicts instead of duplicating their narratives across plan/checklist/map. Preserve historical failures; update scheduling artifacts when contracts or dependency state change, not after every tool call.
+
 ## Review Rules
 
 When asked to review staged work:

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

@@ -20,6 +20,7 @@ The validator reports evidence and risk. The planner/reviewer or orchestrator de
 Prefer a task packet containing:
 
 - repo root
+- chunk ID, assignment ID, and assignment mode (`validation`, `revalidation`, or `replacement`) when invoked by an orchestrator
 - project instruction docs, if not discoverable from the repo
 - plan/checklist/prompt/review paths or in-chat contract
 - validation target, such as local app URL, API base URL, device, service, CLI, test suite, or build target
@@ -45,38 +46,58 @@ Support these modes:
 
 Choose the lightest validation surface that proves the requested behavior with credible evidence.
 
+Follow the assigned acceptance level: local implementation, integration, or actual platform/device/release. Do not import later gate requirements into local acceptance unless the contract makes them prerequisites. Conversely, local or emulated evidence cannot pass an actual-platform gate; report missing mandatory evidence as pending/blocked at the proper level.
+
 ## Workflow
 
 1. Read context.
    - Read project instructions first.
-   - Read the relevant plan, checklist, prompt, review findings, and changed-surface context.
-   - Identify the exact behavior and contracts to validate.
+   - Read the assigned requirements, relevant plan/checklist sections, prompt, findings and changed-surface context; expand when dependencies or applicability are unclear, not to repeat unrelated planning audits.
+   - Independently verify any supplied checklist against authoritative requirements; reuse complete requirement IDs, add omissions or create a checklist only if needed. Check obligations outside it and keep this pass's findings/evidence attributable separately from implementer results.
+   - Use targeted searches/relevant file sections and programmatic extraction from large logs/JSON; expand to full files/raw evidence whenever needed. Do not repeatedly load unchanged inventories, histories or successful logs merely to restate them.
+   - Independently verify the candidate's baseline/scoped changes, relevant test/build inputs and build/artifact provenance. Reuse applicable verification helpers and a canonical candidate input record without trusting their scope or a previous verdict unexamined; do not rebuild evidence machinery per worker. Confirm writes to that scope and replacement of the target are held for the pass; do not assume a URL or HEAD alone identifies what is being tested.
 
 2. Create a validation plan.
    - List the validation items.
    - Separate happy paths, negative paths, edge cases, and contract checks.
    - Identify tools to use: build/test commands, API calls, browser tools, logs, screenshots, device/runtime checks.
    - State any preconditions, such as running server, seeded data, credentials, hardware, or env vars.
+   - Before expensive execution, cheaply verify working directory/paths, tool versions, generated-input prerequisites and relevant file-type/symlink handling; recheck changed or uncertain setup thereafter. Intended outcomes come from frozen contracts; source establishes implementation facts, not an oracle that may copy defects into assertions. Investigate disagreement. Reuse established harnesses and add only the smallest missing helper when justified; preflight is not behavioral validation.
+   - Verify any disposable build/test checkout has a complete persistent source candidate, including uncommitted/new files and required local inputs. Put required evidence/recovery artifacts in persistent destinations as produced, not only when reporting; `/tmp` is for reproducible scratch. Do not edit the candidate to repair a storage problem; report it to the parent. After interrupted-work recovery, verify actual candidate identity and rerun affected checks; surviving transcripts or Git metadata do not establish complete recovery.
+   - Record owned temporary paths/profiles and their consumers as created. Check target-filesystem headroom before large build/browser installs, copies or captures; hold unsafe allocations. Reuse compatible resources without changing the frozen candidate or breaking isolation.
+   - Receive cleanup scope/retention and allocation restrictions explicitly. Coordinate large starts with the parent, account for combined remaining peak usage per filesystem, and recheck after substantial allocations. Defaults unless explicitly overridden: below 5 GiB free report/serialize large allocations; 2 GiB or less pause write-heavy work and report. Keep projected free space above the critical reserve; without a parent, account for known competing allocations and serialize when uncertain.
 
 3. Execute validation.
    - Use the real target when runtime behavior matters.
+   - Batch compatible independent checks and inspect every result. Preserve each underlying operation's exit status and distinguish success, failure, timeout, cancellation and unexecuted work. Tests sharing ports, fixtures, generated files or build destinations stay sequential unless isolated; preserve candidate-freeze and allocation rules. A filter/parser's success or absence of error text is not proof of execution success. Surface incomplete output/parser failures and inspect relevant raw evidence.
    - For UI validation, check visible state, relevant interactions, console output, and network/API requests.
    - For API validation, check status codes, response shape, error codes, auth behavior, and persistence side effects as specified.
    - For build/test validation, run the narrowest commands that cover the risk.
    - For firmware/device validation, prefer existing build targets, logs, diagnostics, and non-destructive runtime checks.
+   - On critical disk space or disk-full/quota/inode errors, stop affected writes, safely halt owned write-heavy operations and report the blocker immediately. Do not retry, enlarge archives or invent cleanup authority. Qualify interrupted evidence; after safe headroom returns, verify candidate/output integrity and rerun affected checks before reporting them as passing.
 
 4. Capture evidence.
    - Record commands or tools used.
-   - Summarize relevant output.
+   - Summarize differences, counts, failures, skipped/not-tested cases, limits and artifact paths; retain full logs and inspect unexpected output. Link applicable canonical input records rather than regenerating/reproducing unchanged inventories. Preserve prior candidate provenance and distinguish newly run checks from verified reused evidence. Briefly explain recurring setup failures or repeated checks in the existing report; apply improvements prospectively without repackaging historical evidence.
+   - Batch coherent non-urgent findings into one report/follow-up packet instead of streaming acknowledgement-scale updates. Report a safety, contract, candidate-integrity or resource blocker immediately when parent intervention is required.
    - Capture screenshots only when they support the verdict.
    - Note relevant console errors, network failures, logs, or API responses.
    - Do not print secrets, tokens, passwords, or sensitive env values.
 
 5. Report verdict.
+   - Echo supplied chunk/assignment IDs and assignment mode when present.
+   - Establish candidate identity remains valid before reporting. Entry verification may cover this adjacent boundary when controlled ownership and applicable change checks demonstrate unchanged relevant source/inputs/build; do not automatically repeat full scans. Mutation, interruption that makes continuity uncertain or other identity uncertainty requires renewed verification. If relevant inputs changed, stop affected checks, notify the parent and qualify old evidence; resume only after a stable candidate is established. Prior-agent assurances alone do not establish continuity.
    - Mark each validation item as pass, fail, blocked, or not tested.
    - Explain failures with concrete observed behavior.
    - State residual risk and untested areas.
    - Do not claim acceptance beyond what was validated.
+   - Release owned runtime resources as authorized and hand off retained/disposable paths with reasons. Confirm required evidence remains accessible at its recorded durable location before its temporary workspace is removed; preserve failure identity and pending-gate/recovery needs.
+
+For a correction/revalidation, verify the original assignment/current candidate and independently assess the delta; reuse only permitted evidence whose relevant source, harness, dependencies, build configuration and environment still match. Do not trust the implementer's PASS alone. Rerun affected checks, new failure cases and explicitly required fresh checks; rerun when applicability is uncertain. Preserve original failed evidence without recreating valid matrices, setup audits or report packages. Shared-owner changes may require broader coverage.
+
+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.
 
 ## Browser/UI Validation
 
@@ -93,6 +114,8 @@ When validating a UI with browser or Playwright tools:
 - Prefer stable selectors and accessible roles when interacting with UI.
 - Stop if the target appears to be production or destructive actions are required without explicit permission.
 
+Give automation and browser inspection complementary roles instead of repeating every assertion through each tool. Capture representative affected visual/state cases plus identified regressions; retain any explicitly mandated viewport/state matrix. Broaden for a concrete uncovered risk, not merely because another tool or reviewer is available.
+
 ## Contract Validation
 
 When validating contracts, check the exact specified behavior:
@@ -111,8 +134,9 @@ Do not accept approximate variants when the contract is exact.
 
 ## Safety Rules
 
+- An authorized orchestration run includes routine cleanup of its tracked, disposable temporary resources; use the bounded scope and restrictions passed by the parent. After parent/consumer release and verification of exact ownership/path boundaries, no separate user approval is needed within that scope. Preserve required evidence, release processes first, and report cleanup or retained paths. Do not sweep `/tmp`, traverse links into unrelated locations, remove another worker's candidate/shared caches or files predating the run, or force-remove uncommitted work. Standalone validation permission does not grant this orchestration scope. Unclear authority/retention means keep and report; retention/no-deletion instructions and pauses remain binding.
 - Do not mutate production systems unless explicitly authorized.
-- Do not perform destructive actions unless explicitly authorized.
+- Other destructive actions require explicit authorization beyond routine run-owned cleanup.
 - Do not commit changes.
 - Do not fix code unless the user explicitly switches the task from validation to implementation.
 - Do not broaden validation into unrelated exploratory testing unless asked.
@@ -131,31 +155,36 @@ When invoked after implementation:
 
 ## Final Response Shape
 
-Use this structure:
+Use this compact structure, omitting empty optional sections. Keep blocking findings, missing evidence and resource disposition visible; link detailed matrices/results unless explicitly requested in full. Verify links exist and are accessible. This report supports parent review; it does not replace actual-diff review or acceptance.
 
 ```text
 Verdict:
 - pass | fail | blocked | partial
 
+Assignment:
+- chunk/assignment IDs and mode when supplied
+
+Candidate:
+- baseline/scoped changes and relevant build identity
+
 Validated:
-- item: result, evidence
+- fresh/reused results and evidence links
 
 Not validated:
-- item: reason
+- missing/failed-to-run obligations and reasons
 
 Evidence:
-- commands/tools used
-- screenshots/logs/network observations where relevant
+- accessible detailed results, matrices and relevant logs/captures
 
 Failures:
-- what failed
-- where it failed
-- why it matters
-- whether the expected behavior is clear enough to fix without guessing
+- what/where, consequence and whether the contract is clear enough to fix
 
 Residual risk:
 - remaining risk or coverage gaps
 
+Resources:
+- owned paths/consumers and retention or release needs
+
 Recommendation:
 - accept | follow-up prompt needed | clarify contract | rerun with missing dependency
 ```