@1aboveio/skills 1.0.10 → 1.0.11

package/skills/engineering/resolve-issues/SKILL.md

@@ -8,16 +8,25 @@ dependencies:
   - better-review
   - golden-path
   - harness-runtime
-release-version: 0.44.1
+release-version: 0.45.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Resolve issues
 
+Before substantive work, if `update_todo` is advertised in this turn, capture the
+known objective with `update_todo({outcome:{objective:<objective>}})`; include only
+known, useful criteria or boundaries. No checklist is required. The interface is
+optional and must never be enabled as a precondition. Read the source requirements
+as authoritative; later user corrections take precedence. A reminder is not
+permission to continue. See [checkpoints](references/task-plan.md#checkpoints).
+
 ## Goal
 
-**Resolve the spec's issues autonomously, in the shortest wall-clock time, at the bar the spec
-already sets: every PR reviewed and green on required CI.** Make the decisions that get there;
-the principles are guidelines, and every rule serves the goal: when one would slow the run
+**Deliver the spec's business outcomes autonomously, in the shortest wall-clock time, at the bar the spec
+already sets: every PR reviewed and green on required CI.** A working end-to-end feature is progress;
+more guards, tests, frameworks, or gates are not progress by themselves. Supporting work belongs only
+when the outcome needs it, a binding requirement calls for it, or the change introduces a concrete defect.
+Make the decisions that get there; the principles are guidelines, and every rule serves the goal: when one would slow the run
 without protecting the bar, take the faster path and record why in `decisions`. The bar is the
 human's criteria. The only constraints are the plan's [standingOrders](references/task-plan.md#standing-orders) and the
 invocation's settings (implementer pin, target, merge and scheduler mode); any other limit, wherever
@@ -31,49 +40,9 @@ what did not pass).
 
 ## Principles
 
-Guidelines, not restrictions; put them in every brief. When two pull apart, take the one that
-ships sooner at the same bar.
-
-1. **Deliver when the agreed plan and required CI pass.**
-   Example: the plan names the charge unit tests and typecheck; both pass and
-   CI is green, so mark the PR ready. Do not also run the emulator journey
-   "to be safe".
-2. **Never add work the plan does not name.**
-   Example: a check flaked: fix its cause (principle 11), and write no incident disposition, failure
-   fingerprint, or review of either. A problem outside the unit goes to the
-   [dropbox](references/dropbox.md). A choice (spec meaning, design, approach) is no
-   failure: answer it, never retry it ([expire.md](references/expire.md#decide-before-you-defer)).
-3. **Add a check only for a concrete doubt that could change delivery.**
-   Example: "the fix changed refund rounding; if `refund.test.ts` fails, the
-   code must change", so run it. "More coverage would be reassuring": skip.
-4. **Reuse a passing result until what it tested changes.**
-   Example: a commit that only rewords its message keeps every result. A
-   fix to `refund.ts` reruns the refund tests, not the whole plan.
-5. **Push early; CI is the full test.**
-   Example: push each fix to the draft PR once its focused tests pass,
-   without asking first and without running the full suite locally.
-6. **Carry a HEAD pushed after a passing review; give every other new HEAD the tier `better-review`'s scope script picks.**
-   Example: a CI fix or a merge of main after a pass: `--carry`, no
-   reviewer. A P0/P1 fix: delta; one that rewrote most of the PR: full.
-7. **Coordinate first.** On every completion notice, read fresh capacity and run `scripts/next-actions.mjs --run <run>`
-   with the [live capacity arguments](references/implementation.md#live-capacity); do everything it prints
-   before resuming your own work; keep a [heartbeat](references/expire.md#waits).
-   Example: mid-way through an emulator debug, a notice says `impl-1322`
-   finished; the script prints `start-review 1322` and `fill-slot 1323`, so
-   start both, then return to the debug. On a new invocation, call it first with `--resume`.
-   Only it decides the run is done: end a turn only when it prints nothing due, only `wait`, or `finish`.
-8. **Run as much at once as the plan and live host capacity allow.** Start every `fill-slot` before your own work;
-   never hold a ready unit back; link a unit only to what its change needs.
-   Example: a slot is free while you debug CI: start the ready unit, then debug. Five slices need one helper: the first builds it, the rest depend on it.
-9. **Record what remains once, in the issue that owns it.**
-   Example: the release device campaign is still to run, so add one comment
-   on the release issue and link it from the handback. Never report "device
-   tests passed" from a unit build.
-10. **Never block on the human.** After the approval, take the [automatic answer](references/preflight.md#never-block-on-the-human)
-   wherever you could ask or wait, record it, and keep going; a later message changes course from there.
-11. **Fix the root cause.** Find why a failure happens and fix that, in the plan or outside it ([expire.md](references/expire.md#infrastructure-failures));
-   never only its symptom (a blind retry, a longer timeout, a skip, a guessed fix sent to CI: reproduce a failed journey
-   with `proof.suite.local` first). Defer only a [human-only](references/expire.md#human-only) cause.
+Read the [delivery principles](references/principles.md) before substantive work
+and include them verbatim in every worker brief. They are guidelines, not
+restrictions: when two pull apart, take the one that ships sooner at the same bar.
 
 `/rush-issues` runs this workflow with every answer defaulted ([shortcut mode](references/preflight.md#shortcut-mode)).
 
@@ -87,7 +56,8 @@ preflight: ready label -> model fills -> plan draft
   -> exploration -> size check (only scope or an open question holds a unit, with a split)
   -> one approval (implementer, target branch, merge mode, scheduler mode, plan)
   -> schedule runnable units within live host capacity:
-       implement -> first coherent commit: draft PR (CI starts) once parents' PRs are open
+       prepare a unit's workspace when its first worker is admitted (never all units up front)
+       -> implement -> first coherent commit: draft PR (CI starts) once parents' PRs are open
        (stack, chain) or merged (wait) -> validate -> self-review -> fix and re-validate
   -> when a unit's code is done, for that unit:
        rebase on its parent (stack, chain) or the target (wait)
@@ -98,8 +68,8 @@ preflight: ready label -> model fills -> plan draft
        -> CI red: fix, push; after a passing review, carry it (no reviewer)
        -> review passed and CI green on one HEAD: mark ready
        -> autonomous: merge (through the queue; stack, chain: enqueue a line's deepest PR); supervised: hand back merge-ready
-       -> after a merge, optional: read-only warehouse canary on that commit
-  -> done: every PR merged (autonomous) or handed back merge-ready (supervised)
+       -> after a merge, clean that unit's workspace and resources (retained = report it); optional: read-only warehouse canary on that commit
+  -> done: every PR merged (autonomous) or handed back merge-ready (supervised), every delivered environment cleaned or retained with a reason
 ```
 
 Read each procedure right before its stage; never substitute your own.
@@ -111,6 +81,7 @@ Read each procedure right before its stage; never substitute your own.
 | Exploration (preflight step 4) | [references/exploration.md](references/exploration.md) |
 | Implementation loop and opening each PR | [references/implementation.md](references/implementation.md) |
 | Read-only warehouse canary | [references/canary.md](references/canary.md) |
+| Owned workspaces: plan, prepare, cleanup, recover, inventory | [references/workspaces.md](references/workspaces.md) |
 | Independent review | [references/review.md](references/review.md) |
 | Routing small problems; posting them at the end | [references/dropbox.md](references/dropbox.md) |
 | CI, queue, and merge | [references/ci.md](references/ci.md) |
@@ -128,7 +99,7 @@ Read each procedure right before its stage; never substitute your own.
   ([Done](#done)); an infrastructure or external blocker becomes a tree issue the units wait on
   ([expire.md](references/expire.md#infrastructure-failures)); a unit that only waits on another unit is not
   started (`pending`), never `blocked`; what stays blocked ends deferred on its owning issue, never done.
-- **Your role.** Coordinate first ([principle 7](#principles)); between notices you may do bounded work
+- **Your role.** Coordinate first ([principle 7](references/principles.md)); between notices you may do bounded work
   yourself: reproduce a failing browser or emulator journey, investigate an infrastructure failure, run a short
   check. Leave code changes to workers so your attention stays on scheduling, and record each worker as the
   unit's `workerKind` (`implement`, `fix`, `review`). Exploration continues the run's one explorer. After a context compaction, read this file in
@@ -159,7 +130,7 @@ infrastructure, and report verified behavior. Full acceptance and required CI st
 ## Every brief contains
 
 Use the full [brief checklist](references/delivery-progress.md#every-brief-contains),
-including the Goal and Principles verbatim, checkpoint history and result contract.
+including the Goal and [Principles](references/principles.md) verbatim, checkpoint history and result contract.
 Treat a missing or unreadable result as incomplete; resume a dead spawn once in its workspace.
 
 ## Workflow
@@ -181,13 +152,15 @@ Follow [preflight.md](references/preflight.md):
 5. **Size check:** run `size-check.mjs` (exit 0; read `verdict`). On `hold` or `stop`, hold the listed
    units (their dependents wait, not started) and draft their splits (yours when none is drafted); on `exploration-unfinished`, continue the explorer.
 6. **Approval:** ask once for implementer, target, merge mode, scheduler mode, and plan;
-   record the answers and create workspaces.
+   record the answers; plan each unit's branch, workspace, base, and lifecycle
+   intent, and prepare a workspace only when its first worker is admitted
+   ([workspaces.md](references/workspaces.md#prepare-at-admission-once)).
    In shortcut mode, take the defaults: on `hold` or `stop`, file the splits (never defer
    for size), accept recommended answers, and run the rest ([shortcut mode](references/preflight.md#shortcut-mode)).
 
 ### 2. Implement and open the PR
 
-Give each unit a branch, workspace, and implementer with its findings entry
+Give each unit a branch, its prepared workspace, and an implementer with its findings entry
 and parents' contracts; state outcome and validation, not method. Refill
 slots at once. At a unit's first coherent commit its PR opens as a draft, so CI
 starts and the work is safe; later work goes to the same PR (in a Mergify stack
@@ -217,20 +190,26 @@ Enqueue through the queue's skill only when CI is green and the verdict is `pass
 on the same HEAD.
 After 2 cycles without progress ([expire.md](references/expire.md)), or a harness-reported stuck worker, take the failure kind's response
 ([expire.md](references/expire.md)).
+A landed unit's workspace and resources are cleaned then, alongside independent units, never by age
+([workspaces.md](references/workspaces.md#cleanup-after-delivery-before-finish)).
 
 ## Task plan and board
 
 Keep the task plan as the only source of truth; only you update it
-([task-plan.md](references/task-plan.md)). On Pi, bind or reload with
-`update_plan({workflow:{path:<absolute-plan-path>,revision:<persisted-planRevision>}})`;
-with no event this is read-only. Save transitions through `update_plan`'s
-`workflow` payload with the current revision; it persists the plan and
-refreshes the TUI. Never edit the bound plan directly.
-Render the board from the saved plan under that same `planRevision`.
+([task-plan.md](references/task-plan.md)). When `update_todo` is advertised, capture
+the known outcome before substantive work and bind or reload the saved plan with
+`update_todo({workflow:{path:<absolute-plan-path>,revision:<persisted-planRevision>},outcome:{objective:<objective>}})`.
+Binding with no event is read-only for the plan. Save transitions through its
+`workflow` payload with the current revision; never edit the bound plan directly.
+When the tool is absent or disabled, use the existing file transition in
+[task-plan.md](references/task-plan.md#other-harnesses-and-display). Never enable the
+optional interface as a precondition. Render the board from the saved plan under
+that same `planRevision`.
 
 ## Done
 
-First [settle blocked units](references/done.md#settle-blocked-units). Every PR is reviewed, green on its exact HEAD, and merged (`autonomous`) or
+First [clean every delivered unit's environment](references/done.md#clean-before-handoff), then
+[settle blocked units](references/done.md#settle-blocked-units). Every PR is reviewed, green on its exact HEAD, and merged (`autonomous`) or
 handed back merge-ready (`supervised`). For a blocked unit, hand back it, its
 dependents, and the merged units. Link each issue the run filed into the spec's tree, and each `excluded` rollup to close;
 hand back the draft from `<run>/splits/` only for a unit still held, and the link to the pending device record. Report one short record per unit:

package/skills/engineering/resolve-issues/references/ci.md

@@ -97,9 +97,19 @@ provider shows that PR merged.
 
 ## After the merge
 
-Remove the unit workspace, then its review clone:
+Clean that unit's workspace and resources, then finish it, in every scheduler
+mode: `next-actions.mjs` prints `cleanup-workspace` until its cleanup settles.
+First record the intent through the [checkpoint mechanism](task-plan.md#checkpoints) (`lifecycle.cleanup`
+`{state: applying, headSha: <the unit's headSha>}`), then run:
 
 ```bash
-node <skill-base-dir>/scripts/cleanup-runs.mjs --merged <unit-workspace> --apply
-node <skill-base-dir>/scripts/cleanup-runs.mjs --merged <review-clone> --apply
+node <skill-base-dir>/scripts/cleanup-runs.mjs cleanup --run <run> --unit <unit> \
+  --revision <saved planRevision> --apply --json
 ```
+
+Persist its returned lifecycle ([workspaces.md](workspaces.md#cleanup-after-delivery-before-finish)).
+It runs alongside independent units. `complete` settles the unit; `retained`
+keeps the whole environment and reports it as **not cleaned**, with the
+helper's reason, in the handoff. `pending` or `applying` cleanup blocks
+`finish`. Only a proven cleanup removes a tree: no `--merged <path>` on its
+own, and no deletion by age.

package/skills/engineering/resolve-issues/references/delivery-progress.md

@@ -49,11 +49,12 @@ issue or automatic scheduler gate. They do not waive required validation.
 - the [immediate acceptance checkpoint](#delivery-progress), existing baseline (or none),
   and, for a continuation, the last result, remaining uncertainty and next distinguishing
   test; retain the same checkpoint/history when changing workers
-- the [Goal](../SKILL.md#goal) and [Principles](../SKILL.md#principles), verbatim (a reviewer gets review.md's two rules instead)
+- the [Goal](../SKILL.md#goal) and [Principles](principles.md), verbatim (a reviewer gets review.md's two rules instead)
 - the result path, `<run>/results/<unit>-<label>.json` (`<label>`: kind and attempt, e.g. `fix-2`), with `unit` and `decisionNeeded` (null or a choice)
 - at the deadline: stop starting work, commit, and report
-- environment rules: write only inside the workspace (and the findings directory for the explorer),
-  with tool caches and temp files there (`TMPDIR`, `npm_config_cache`, `UV_CACHE_DIR`); use the machine's
+- environment rules: write only inside the workspace and its planned resources (and the findings directory for the explorer),
+  with private caches and temp files registered before use (`TMPDIR`, `npm_config_cache`, `UV_CACHE_DIR`);
+  reuse them through retries and return them to the cleanup owner ([workspaces](workspaces.md)); use the machine's
   installed JDK, Android SDK, system images, and browsers (`JAVA_HOME`, `ANDROID_HOME`) where they fit,
   or the repo's pinned Playwright image where the runner has no browser (`github-actions` runners.md);
   edit with the harness's tools, never a shell `apply_patch`

package/skills/engineering/resolve-issues/references/done.md

@@ -1,7 +1,7 @@
 # Done
 
-End a run in three steps, in order: settle blocked units, report, then close
-the run in the harness.
+End a run in four steps, in order: clean each delivered unit's environment,
+settle blocked units, report, then close the run in the harness.
 
 ## Settle blocked units
 
@@ -13,6 +13,15 @@ itself is not settled while `next-actions.mjs` prints `wait` or
 `retry-blocked` for it ([expire.md](expire.md#reason-codes)). End only when
 nothing is left to settle.
 
+## Clean before handoff
+
+Clean every delivered unit's workspace and resources before the report, in every
+scheduler mode ([workspaces.md](workspaces.md#cleanup-after-delivery-before-finish)).
+Its `lifecycle.cleanup` is `complete`, or `retained` with the current `headSha`
+and a reason; `pending` or `applying` blocks the handoff. Report each retained
+environment as **not cleaned**, with its reason, and say so for every blocked,
+cancelled, pending, or merge-ready handed-back unit that keeps its environment.
+
 ## Close the run
 
 After the report ([SKILL.md](../SKILL.md#done)):

package/skills/engineering/resolve-issues/references/expire.md

@@ -2,6 +2,11 @@
 
 Expire an attempt at these limits. Never drop an expired unit from the spec.
 
+These counters track progress toward the agreed outcome, not a reason to create
+more work. Count only required checks and concrete defects that affect delivery;
+do not keep an attempt alive by adding guards, tests, gates, or diagnostics that
+the feature does not need.
+
 **Count progress, not attempts: expire after 2 cycles without progress, and
 never after a fixed number of cycles.** A fix cycle makes progress only when
 its count reaches a new low, below every earlier cycle of the attempt; a
@@ -277,8 +282,10 @@ merge waits for its proof.
 
 ## Infrastructure failures
 
-**Diagnose each infrastructure failure to its cause and fix it.** Never
-wait for someone else to diagnose it.
+**Diagnose infrastructure that prevents an agreed required check or feature from
+running, and fix its cause.** Do not use this section to harden healthy infrastructure,
+repair unrelated debt, or create a new test platform for speculative assurance. Never
+wait for someone else to diagnose a blocker the run can resolve.
 
 "The same failure" means the same command failing with the same error.
 Example: `./gradlew assembleDebug` fails with `Could not resolve

package/skills/engineering/resolve-issues/references/implementation.md

@@ -6,10 +6,15 @@ Give these to every implementer and fix worker, with SKILL.md's
 [Principles](../SKILL.md#principles). Each is a guideline toward the
 [Goal](../SKILL.md#goal), then an example.
 
-1. **Done is the criteria passing at `proof.level` on the final HEAD.**
-   Example: `proof.level` is `database`; the new repository test passes
-   against the disposable PostgreSQL, so finish. No browser run on top.
-2. **Add no criteria, checks, evidence, or work items the brief does not name.**
+1. **Done is the requested outcome working and its agreed criteria passing at `proof.level`.**
+   Example: the Charge layout persists per installation and the repository test passes
+   against disposable PostgreSQL, so finish. No browser run on top.
+2. **Keep the first working business flow in view.** Build the smallest complete path
+   through the existing system; do not build a general framework before its first use.
+   Supporting code or tests need a direct dependency, an agreed requirement, or a
+   concrete defect introduced by this change. Do not add speculative guards, retries,
+   fallbacks, coercions, or compatibility modes; retain the protections the supported
+   behavior actually needs. Never enlarge the criteria, CI gates, or evidence campaign.
    Example: you notice the export also lacks currency. Run `dropbox.mjs
    check` on it: `inDiff` false, so report it as a dropbox item; do not fix or test
    it in this unit. `inDiff` true means your change caused it: fix it.
@@ -32,22 +37,26 @@ After the approval, schedule runnable units continuously within
 
 ## Workspaces
 
-Give each unit its own branch and isolated Git workspace at
-`.resolve-issues/rush/<run-id>/units/<unit>/`, on the target or on its
-parent's branch in `stack` or `chain` mode. Keep it through implementation, fixes,
-and expiry; never wipe it on spawn death or timeout. Give a unit
-one workspace, one emulator profile (AVD), and at most one scratch copy,
-reused across retries and fixes; never one per attempt.
-
-On Pi, never run a Git-mutating sandboxed worker in a linked worktree: on the
-first such spawn pass `git_clone_workspace:true` with a dedicated
-`sandbox_dir`, record the clone as the workspace, and reuse it for retries.
-Use `sandbox:false` only when the caller accepts unrestricted writes.
+Give each unit its own branch and one prepared workspace at
+`.resolve-issues/rush/<run-id>/units/<unit>/`, on the target or on its parent's
+branch in `stack` or `chain` mode ([workspaces.md](workspaces.md)). Keep it
+through implementation, fixes, and expiry; never wipe it on spawn death or
+timeout. Give a unit one workspace, one emulator profile (AVD), and at most one
+scratch copy, planned as a resource and reused across retries and fixes; never
+one per attempt.
+
+Prepare it when the unit's first worker is admitted, and persist the helper's
+ready identity before that worker starts ([workspaces.md](workspaces.md#prepare-at-admission-once)).
+Every later worker reuses the same tree. A sandboxed Git-mutating worker gets an
+independent clone prepared before its first spawn; after that, never pass
+`git_clone_workspace:true` again, and use `sandbox:false` only when the caller
+accepts unrestricted writes.
 
 ## Brief
 
 Add to SKILL.md's brief list: whole-spec context and neighboring unit
-boundaries, the branch, dependencies, and shared surfaces; "push the branch at
+boundaries, the branch, the prepared workspace and its recorded resources,
+dependencies, and shared surfaces; "push the branch at
 your first coherent commit and after each later one (in a Mergify stack
 repository, amend the one commit), and write its head SHA to
 `<run>/results/<unit>-head.json`; do not open the PR yourself" (the
@@ -108,8 +117,13 @@ transcript.
 - Prove `browser` and `emulator` levels with the existing end-to-end suite;
   with none, the unit builds the journey its proof needs
   ([expire.md](expire.md#proof-stays-with-its-unit)).
+- Reuse existing tests that already prove an outcome. Add focused cases for the
+  changed behavior and material failures, at the lowest level that proves them for
+  real. Decide whether a new defensive branch belongs before writing a test for it;
+  do not make an invented fallback permanent by treating its test as a requirement.
 - Prove logic with unit, database, or component tests; keep journeys for what
-  only they show.
+  only they show. A journey can satisfy several obligations it actually exercises;
+  a new branch does not automatically need another test layer.
 - When CI runs the unit's `browser` or `emulator` suite, CI proves it: push
   and read the journey's result on the pushed HEAD. CI confirms a fix; it
   never debugs one. After a failed journey, reproduce it with
@@ -148,6 +162,8 @@ transcript.
 ## Scheduling
 
 - Start runnable units together within [live host capacity](#live-capacity).
+  A printed `prepare-workspace` is work that admits the worker printed after it:
+  run it, persist the returned identity, then spawn.
   Separately, this machine runs one local emulator at a time unless its
   suite proves more is safe. Treat it as a queue the coordinator hands out,
   in arrival order: to emulator proof CI does not run and to failures only

package/skills/engineering/resolve-issues/references/preflight.md

@@ -352,7 +352,9 @@ Record each answer in `decisions`, sync the catalog, then:
 - Run the rest: mark held units `blocked` (`blockedReason: size-hold`) with the split path;
   their dependents stay not started (`pending`).
 
-Create the unit branches and workspaces, and start. From here on, ask nothing ([never block on the human](#never-block-on-the-human)).
+Record the unit branches and workspace intents, then prepare each workspace only
+when its first worker is admitted ([workspaces](workspaces.md#prepare-at-admission-once)).
+From here on, ask nothing ([never block on the human](#never-block-on-the-human)).
 
 ### Environment checks
 

package/skills/engineering/resolve-issues/references/principles.md

@@ -0,0 +1,52 @@
+# Delivery principles
+
+Guidelines, not restrictions; put them in every brief. When two pull apart, take the one that
+ships sooner at the same bar.
+
+1. **Deliver when the requested behavior works and the agreed checks pass.**
+   Example: the cashier can submit the Charge, the plan's charge tests and typecheck
+   pass, and required CI is green, so mark the PR ready. Do not add another
+   journey or a hardening campaign "to be safe".
+2. **Keep supporting work tied to the outcome; never enlarge acceptance on your own.**
+   Add a guard, fallback, retry, compatibility path, abstraction, or test setup only
+   for a supported requirement, a concrete dependency, or a demonstrated defect.
+   Preserve necessary security, financial correctness, tenancy, data integrity, and
+   cleanup. Do not turn a feature into a coverage, CI, observability, framework,
+   or repository-cleanup project. A problem outside the unit goes to the
+   [dropbox](dropbox.md); do not fix it merely because you found it.
+   A choice (spec meaning, design, approach) is no failure: answer it, never retry
+   it ([expire.md](expire.md#decide-before-you-defer)).
+3. **Add a check only for a concrete doubt that could change delivery.**
+   Example: "the fix changed refund rounding; if `refund.test.ts` fails, the
+   code must change", so run it. "More coverage would be reassuring": skip.
+4. **Reuse a passing result until what it tested changes.**
+   Example: a commit that only rewords its message keeps every result. A
+   fix to `refund.ts` reruns the refund tests, not the whole plan.
+5. **Push early; CI is the full test.**
+   Example: push each fix to the draft PR once its focused tests pass,
+   without asking first and without running the full suite locally.
+6. **Carry a HEAD pushed after a passing review; give every other new HEAD the tier `better-review`'s scope script picks.**
+   Example: a CI fix or a merge of main after a pass: `--carry`, no
+   reviewer. A P0/P1 fix: delta; one that rewrote most of the PR: full.
+7. **Coordinate first.** On every completion notice, read fresh capacity and run `scripts/next-actions.mjs --run <run>`
+   with the [live capacity arguments](implementation.md#live-capacity); do everything it prints
+   before resuming your own work; keep a [heartbeat](expire.md#waits).
+   Example: mid-way through an emulator debug, a notice says `impl-1322`
+   finished; the script prints `start-review 1322` and `fill-slot 1323`, so
+   start both, then return to the debug. On a new invocation, call it first with `--resume`.
+   Only it decides the run is done: end a turn only when it prints nothing due, only `wait`, or `finish`.
+8. **Run as much at once as the plan and live host capacity allow.** Start every `fill-slot` before your own work;
+   never hold a ready unit back; link a unit only to what its change needs.
+   Example: a slot is free while you debug CI: start the ready unit, then debug. Five slices need one helper: the first builds it, the rest depend on it.
+9. **Record what remains once, in the issue that owns it.**
+   Example: the release device campaign is still to run, so add one comment
+   on the release issue and link it from the handback. Never report "device
+   tests passed" from a unit build.
+10. **Never block on the human.** After the approval, take the [automatic answer](preflight.md#never-block-on-the-human)
+   wherever you could ask or wait, record it, and keep going; a later message changes course from there.
+11. **Fix the cause of what actually blocks delivery.** Diagnose a failed agreed check or
+   a concrete defect introduced by the change; fix the cause, not a blind retry, longer
+   timeout, skip, or guessed CI fix. Reproduce a failed journey with `proof.suite.local`
+   first. Infrastructure repair follows [expire.md](expire.md#infrastructure-failures)
+   only when the required acceptance needs it; unrelated debt stays in the dropbox.
+   Defer a necessary fix only for the documented [human-only](expire.md#human-only) causes.

package/skills/engineering/resolve-issues/references/review.md

@@ -15,8 +15,10 @@ restate its rules in the brief beyond the two below.
   provides and builds on.
 - Have it compute its own merge-base with `origin/<targetBranch>`, or the
   parent's branch when stacked or chained.
-- Give each unit one review clone at `<run>/reviews/<unit>/`, reused every
-  round by fetching the new HEAD; never a fresh clone or sandbox per round.
+- Prepare each unit one review clone at `<run>/reviews/<unit>/clone`, recorded as
+  its `review` resource before the first reviewer is admitted, and reuse it every
+  round by fetching the new HEAD; never a fresh clone or sandbox per round
+  ([workspaces.md](workspaces.md#prepare-at-admission-once)).
 - Give it the result path and tell it to file no follow-up issues: give each
   P2 its `file` and `line`; you add them to the
   [dropbox](dropbox.md). It reports no P3. It changes no code and pushes nothing.
@@ -25,8 +27,9 @@ restate its rules in the brief beyond the two below.
   instead of rerunning them. Example: CI ran the 876-test suite green; the
   reviewer reads that run and runs only the changed files' tests.
 - Repeat two rules in every brief, as a safety net:
-  - A blocker names what breaks and how, with a counterexample; without one
-    it is P2 at most.
+  - A blocker names a concrete supported failure with a counterexample, or cites
+    an explicit unmet requirement or missing agreed required proof and its evidence.
+    A missing optional test or hypothetical improvement is P2 at most.
   - A check you cannot run is not a finding: record it as not run.
 
 ## Tier, then verdict
@@ -140,14 +143,21 @@ the PR author; `github-reviews.mjs` reads them and decides what blocks.
    stall guard reads every earlier `<unit>-r<K>.json` beside the prior and
    answers `review-again` when one is missing, so keep every round's file under that name.
 
-3. Add the round's P2 to the dropbox, merge the
+3. **Before running the old fix or adding a new one, apply the same finding bar.**
+   Keep accepted criteria and binding checks fixed. A proposed fallback, compatibility
+   mode, harness, gate, or wider test campaign needs a concrete dependency or defect;
+   a reviewer preference alone does not authorize it. Return an unsupported request
+   for clarification or as a non-blocking follow-up, never silently downgrade a real
+   security, money, tenancy, or data-integrity defect.
+
+   Add the round's P2 to the dropbox, merge the
    [GitHub reviews](#github-reviews) into the file, then run the verdict
    script and follow its `verdict`, never the reviewer's prose (it exits 0 whenever it ran, 2 if it could not):
 
    ```bash
    node <skill-base-dir>/scripts/dropbox.mjs from-review --dropbox <run>/dropbox.json \
      --review <run>/reviews/<unit>-r<N>.json --pr <PR url> \
-     --git <run>/reviews/<unit> --base <review base> &&
+     --git <run>/reviews/<unit>/clone --base <review base> &&
    node <skill-base-dir>/scripts/github-reviews.mjs merge --pr <owner/name#N> \
      --head <PR headSha> --review <run>/reviews/<unit>-r<N>.json &&
    node <skill-base-dir>/scripts/review-verdict.mjs \
@@ -190,17 +200,17 @@ Give the fix worker only the `fixBrief`, and act on its `action`:
 
 | `action` | When | Fix worker |
 |---|---|---|
-| `fix` | first blocking round | Fix each finding's `rule` at its one owner and close every row in its `paths`. |
-| `test-first` | a P0/P1 survived the last fix | On the escalation model, for each `recurring` finding, before changing code: name the rule it breaks, list every path that can break it (with this id's trigger from every earlier round), write one test per path, and see the open ones fail. Fix the rule at its one owner until every test passes. "Fixed" is every path's test passing. |
+| `fix` | first blocking round | Make the smallest complete fix for each finding's `rule` and close every applicable row in its `paths`; do not require centralization. |
+| `test-first` | a P0/P1 survived the last fix | On the escalation model, for each `recurring` finding, before changing code: name the broken rule and its concrete open paths, reuse sufficient tests and add focused cases for missing proof, and see the open cases fail. Fix the rule until the applicable cases pass. A table-driven test may cover several paths; no new architecture is required. |
 | `one-by-one` | the last fix introduced new P0/P1 | One fix worker per finding, in turn, each with the smallest change that closes every row of its `paths` at the rule's owner. |
 
-**Fix the rule, at its one owner, on every path.**
-Example: a stale-session finding is patched at sign-out, then at
-revalidation, then at resume, each with its own guard. The rule is "an old
-async completion never changes a newer session's credentials"; its owner is
-the credential store (clear only when the stored session matches the
-caller's); test every path that clears credentials against a same-person and
-a different-person new sign-in.
+**Fix the broken rule on every applicable path, without requiring a refactor.**
+A shared owner is useful when it makes the fix smaller and clearer; it is not a
+prerequisite for closing the finding.
+Example: for an old async completion overwriting a newer session, ensure every
+credential-clearing path checks the relevant session identity. A shared store check
+or focused handler checks can both resolve it; prove the supported same-person and
+different-person sign-in cases without inventing unrelated event combinations.
 
 Have each fix worker run the checks its change affects and return the
 commands and results; push, and let CI run. Then pick the new HEAD's