From 0409a75fb71b6073d7b6e45838ae16f673486814 Mon Sep 17 00:00:00 2001 From: Dayowe Date: Sun, 13 Sep 2026 22:40:56 +0200 Subject: [PATCH] Include bounded temporary cleanup in orchestration scope; bump plugin to 0.1.2 --- .../staged-implementation/.codex-plugin/plugin.json | 2 +- plugins/staged-implementation/README.md | 1 + .../staged-implementation/skills/implementer/SKILL.md | 4 ++-- .../staged-implementation/skills/orchestrator/SKILL.md | 10 ++++++---- plugins/staged-implementation/skills/planner/SKILL.md | 4 ++-- .../staged-implementation/skills/validator/SKILL.md | 4 ++-- 6 files changed, 14 insertions(+), 11 deletions(-) diff --git a/plugins/staged-implementation/.codex-plugin/plugin.json b/plugins/staged-implementation/.codex-plugin/plugin.json index 14bceb1..7cafcb0 100644 --- a/plugins/staged-implementation/.codex-plugin/plugin.json +++ b/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" diff --git a/plugins/staged-implementation/README.md b/plugins/staged-implementation/README.md index 2e19c81..b680d97 100644 --- a/plugins/staged-implementation/README.md +++ b/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 diff --git a/plugins/staged-implementation/skills/implementer/SKILL.md b/plugins/staged-implementation/skills/implementer/SKILL.md index 6c176a9..1ee103a 100644 --- a/plugins/staged-implementation/skills/implementer/SKILL.md +++ b/plugins/staged-implementation/skills/implementer/SKILL.md @@ -58,7 +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. + - 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. @@ -77,7 +77,7 @@ The prompt should define scope, non-goals, requirements, invariants, validation, ## 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. +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. diff --git a/plugins/staged-implementation/skills/orchestrator/SKILL.md b/plugins/staged-implementation/skills/orchestrator/SKILL.md index 305929a..2b66123 100644 --- a/plugins/staged-implementation/skills/orchestrator/SKILL.md +++ b/plugins/staged-implementation/skills/orchestrator/SKILL.md @@ -27,7 +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 +- 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. @@ -204,7 +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 explicit cleanup authority or its absence, retention requirements, disk thresholds and allocation restrictions; require owned-resource handoff +- 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 @@ -223,6 +223,8 @@ Report concise results, failures and evidence paths; retain raw logs/artifacts a ## 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. @@ -237,9 +239,9 @@ At validation release, acceptance, abandonment or pause/handoff, classify resour 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. +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. -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. +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 diff --git a/plugins/staged-implementation/skills/planner/SKILL.md b/plugins/staged-implementation/skills/planner/SKILL.md index 8ab062e..3520b84 100644 --- a/plugins/staged-implementation/skills/planner/SKILL.md +++ b/plugins/staged-implementation/skills/planner/SKILL.md @@ -285,10 +285,10 @@ Every orchestrator prompt must include: - validation expectations - commit policy - planning checkpoint status: verified baseline or explicit uncommitted disposition under **Planning Checkpoint Before Orchestration** -- cleanup authority: explicit scope/source, or not authorized; required retention and resource handoff +- cleanup scope: routine run-owned cleanup default, applicable restrictions, 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. +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: diff --git a/plugins/staged-implementation/skills/validator/SKILL.md b/plugins/staged-implementation/skills/validator/SKILL.md index 039193c..c6e47f9 100644 --- a/plugins/staged-implementation/skills/validator/SKILL.md +++ b/plugins/staged-implementation/skills/validator/SKILL.md @@ -123,9 +123,9 @@ 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. +- 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.