Include bounded temporary cleanup in orchestration scope; bump plugin to 0.1.2

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

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

plugins/staged-implementation/README.md

@@ -110,6 +110,7 @@ The usual flow is:
 - 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.
+- 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

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

@@ -33,6 +33,8 @@ The prompt should define scope, non-goals, requirements, invariants, validation,
    - Use `update_plan` for non-trivial work.
    - Keep exactly one step in progress.
    - Revise the plan when scope or findings change.
+   - 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.
@@ -56,6 +58,7 @@ The prompt should define scope, non-goals, requirements, invariants, validation,
    - 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.
@@ -67,12 +70,15 @@ The prompt should define scope, non-goals, requirements, invariants, validation,
 7. Report results.
    - Summarize changed files and behavior.
    - Distinguish fresh validation from verified reused evidence; give results/artifact paths instead of repeating full logs. Retain raw evidence and inspect failures/unexpected output.
+   - 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.
    - 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
 
+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.

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

@@ -27,6 +27,7 @@ Prefer a task packet containing:
 - prompt output directory or naming convention
 - validation expectations
 - 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
 
 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.
@@ -49,6 +50,7 @@ Before delegating implementation, run a readiness preflight:
 1. Establish current state.
    - Read project instructions first.
    - Establish context from the plan, checklist, prompt map, current handoff/review and relevant git/worktree state. On continuation, read changed instructions/contracts and affected scope rather than reloading unchanged history.
+   - 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.
@@ -102,6 +104,7 @@ For each authorized ready chunk:
 
 9. Continue.
    - Update one 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 **Temporary Resources and Cleanup** before the next large allocation.
    - Choose the next ready chunk.
    - Stop when all chunks are complete, blocked, or no ready chunk remains.
 
@@ -188,6 +191,7 @@ When spawning an implementer sub-agent:
 - instruct it not to commit
 - keep the task narrow and self-contained
 - where supported, use scoped context instead of a full-history fork, carrying all applicable instructions, authority and contract references; preserve model/effort choices
+- 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
@@ -200,6 +204,7 @@ When invoking a validator pass:
 - 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 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
@@ -216,6 +221,28 @@ Use automation for repeatable regression/mechanical checks and browser inspectio
 
 Report concise results, failures and evidence paths; retain raw logs/artifacts and inspect unexpected output. Link evidence instead of duplicating logs/galleries across reviews. Efficiency does not authorize model changes, missed cases, weaker contracts or unsafe rollback.
 
+## 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 this 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 the lifecycle boundaries above, including run completion, rather than waiting for disk pressure. 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.
+
 ## Review Rules
 
 Review against:
@@ -245,7 +272,7 @@ If there are no findings, state an acceptable verdict clearly before summaries.
 
 ## Commit Rules
 
-Commit behavior is controlled only by the explicit commit policy. Supported policies are:
+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`

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

@@ -126,6 +126,10 @@ Prefer existing tests/harnesses and the smallest validation surface that credibl
 
 Specify evidence reuse conditions: relevant source, harness, dependencies, configuration and environment must match, retaining original limits. Changed inputs require affected checks; uncertain applicability requires a rerun. A correction need not repeat unrelated builds/screenshots/reviews, but efficiency cannot weaken an acceptance case.
 
+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
 
 When asked to write or update an implementation checklist from a plan, make it operational enough for fresh implementer sessions. Include, as applicable:
@@ -138,6 +142,7 @@ When asked to write or update an implementation checklist from a plan, make it o
 - exit criteria
 - 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.
@@ -254,6 +259,14 @@ End implementer prompts by asking for a proposed commit message. When a chunk ID
 
 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.
@@ -271,8 +284,12 @@ Every orchestrator prompt must include:
 - 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
 - stopping conditions
 
+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`

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

@@ -60,6 +60,8 @@ Follow the assigned acceptance level: local implementation, integration, or actu
    - 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.
+   - 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.
@@ -67,6 +69,7 @@ Follow the assigned acceptance level: local implementation, integration, or actu
    - 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.
@@ -81,6 +84,7 @@ Follow the assigned acceptance level: local implementation, integration, or actu
    - 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, independently verify the change's impact and 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 and avoid recreating unchanged reports/galleries. Shared-owner changes may require broader coverage.
 
@@ -119,8 +123,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.