Require persistent implementation workspaces and recovery evidence; bump plugin to 0.1.3

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

@@ -1,6 +1,6 @@
 {
   "name": "staged-implementation",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "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.
+- 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.
 

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

@@ -33,6 +33,7 @@ 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.
+   - 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.
 

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

@@ -50,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 delegating edits, establish persistent implementation and evidence locations under **Persistent Workspaces**. 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.
@@ -191,6 +192,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
+- 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
@@ -204,6 +206,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 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
@@ -221,6 +224,14 @@ 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.
 
+## 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 existing retention and cleanup checks 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 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.

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

@@ -126,6 +126,8 @@ 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 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.
@@ -286,6 +288,7 @@ Every orchestrator prompt must include:
 - 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 in the handoff that authorization to run orchestration includes routine cleanup of that run's tracked, disposable temporary resources after ownership, retention and consumer-release checks pass. No separate cleanup approval question is needed within those bounds. Carry this scope into worker assignments and honor explicit retention/no-deletion instructions and higher-priority restrictions. On resuming the same run, accumulated resources qualify only after their run ownership and release conditions are verified and recorded. Unknown ownership, shared caches, files predating the run, unrelated resources and anything still needed remain excluded. Standalone planning/implementation/validation or commit permission does not grant this orchestration cleanup scope; ask for concrete additional authority only when needed outside it. Never propose blanket clearing of `/tmp`.

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

@@ -60,6 +60,7 @@ 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.
+   - 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.