diff --git a/plugins/staged-implementation/skills/implementer/SKILL.md b/plugins/staged-implementation/skills/implementer/SKILL.md index 568327a..6c176a9 100644 --- a/plugins/staged-implementation/skills/implementer/SKILL.md +++ b/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 explicit cleanup authority. 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 +Clean only exact run-owned disposable resources under explicit bounded cleanup authority and after the parent/consumers release them. 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 or force-remove uncommitted work. Without authority or with uncertain retention, leave paths recorded and request clarification; a pause is not new cleanup authority. + - 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. diff --git a/plugins/staged-implementation/skills/orchestrator/SKILL.md b/plugins/staged-implementation/skills/orchestrator/SKILL.md index d90f70a..d5d2158 100644 --- a/plugins/staged-implementation/skills/orchestrator/SKILL.md +++ b/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 authority and retained evidence/recovery requirements, 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. @@ -102,6 +103,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 +190,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 +203,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 explicit cleanup authority or its absence, 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 +220,26 @@ 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 + +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. + +Deletion requires explicit user/project authorization for bounded cleanup, carried into the assignment; implement/validate/commit permission alone is insufficient. 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, pre-existing/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. + +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. These rules define future cleanup procedure, not permission to delete anything by themselves. + ## Review Rules Review against: diff --git a/plugins/staged-implementation/skills/planner/SKILL.md b/plugins/staged-implementation/skills/planner/SKILL.md index e03c128..69a33cc 100644 --- a/plugins/staged-implementation/skills/planner/SKILL.md +++ b/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. @@ -271,8 +276,11 @@ Every orchestrator prompt must include: - prompt output directory or naming convention - validation expectations - commit policy +- cleanup authority: explicit scope/source, or not authorized; required retention and resource handoff - stopping conditions +Carry forward explicit bounded cleanup authorization when already granted. Permission to implement, validate or commit alone does not grant deletion authority, and this skill grants none. If cleanup is not authorized, record that rather than invent permission or block unrelated safe work; request approval for concrete eligible paths before deletion is needed. Never propose blanket clearing of `/tmp`, shared caches or pre-existing files. + The commit policy must be explicit and must use one of: - `authorized-for-accepted-chunks` diff --git a/plugins/staged-implementation/skills/validator/SKILL.md b/plugins/staged-implementation/skills/validator/SKILL.md index bb43dca..039193c 100644 --- a/plugins/staged-implementation/skills/validator/SKILL.md +++ b/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,6 +123,7 @@ Do not accept approximate variants when the contract is exact. ## Safety Rules +- Delete temporary resources only under explicit bounded cleanup authority after parent/consumer release and verification of exact ownership/path boundaries. 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 force-remove uncommitted work. Unclear authority/retention means keep and report; a pause grants no new deletion permission. - Do not mutate production systems unless explicitly authorized. - Do not perform destructive actions unless explicitly authorized. - Do not commit changes.