@1aboveio/skills 1.0.20 → 1.0.22

package/skills/engineering/harness-runtime/references/subagent-sessions.md

@@ -0,0 +1,75 @@
+# Saved subagent conversations on Pi
+
+Use this contract when an engineering workflow continues a Pi worker after its
+attempt has finished. Other harnesses use their advertised continuation API.
+
+## Check the active interface
+
+Read the tool schema advertised in the current turn. Continuation requires
+`subagent_spawn` with `session_id`; a tool name or an installed package version
+alone does not establish that the running extension has loaded that parameter.
+A stale running extension may need the human's `/reload` after an update. Report
+that mismatch and use the workflow's documented fallback; updating packages or
+changing tool permissions is a separate authorized action.
+
+## Record the conversation separately from the attempt
+
+Keep these values from the actual launch receipt:
+
+- `runId`: the attempt used for results, failures, logs, and the active worker slot.
+- `sessionId`: the native Pi conversation used for later follow-up.
+- `cwd`: the worker's recorded workspace.
+
+Every continuation creates a new `runId` while keeping `sessionId`. Read the
+native session id from the structured receipt, batch launch entry, or explicit
+`session_id` in list output. An attempt id is not a substitute, even when the two
+happen to match on the first launch.
+
+For an older plan missing `sessionId`, locate the exact recorded `runId` in
+`subagent_list` and record its native `session_id` before continuing. Use
+`all: true` when it is outside the caller's folder. If that identity cannot be
+verified, report unavailable continuity and follow the workflow's explicit
+replacement path with its saved evidence.
+
+## Continue through spawn
+
+```javascript
+subagent_spawn({ session_id: owner.sessionId, prompt: "Fix the remaining findings." })
+```
+
+The prompt is the next turn, not a repetition of the original assignment or role.
+Keep the saved worker configuration; pass model or effort only for an explicit,
+authorized escalation supported by the current schema. Record the returned new
+attempt id and verify that its session id is still the selected conversation.
+Per-job `session_id` in `subagent_spawn_batch` has the same meaning; the shared
+batch options do not select one conversation for every job.
+
+The caller may be a different foreground session. Completion reports to that
+caller. Continue from a completed attempt; a running or orphaned writer must
+settle before another continuation starts. A failed, killed, lost, or otherwise
+refused attempt follows the workflow's recovery or replacement rules rather than
+selecting an older completion. Current mandatory permissions still apply.
+Missing history or workspace is a refusal, not permission to create a replacement
+conversation under the same identity.
+
+## Discover locally or globally
+
+`subagent_list()` searches the current folder and descendants across foreground
+sessions. `subagent_list({ all: true })` searches globally. Each row identifies
+both the attempt and the saved conversation. `session_name` is a convenience for
+one exact, unambiguous name in the local folder scope; a workflow with recorded
+ownership uses its exact `sessionId` rather than choosing a worker by name.
+Duplicate names require an explicit session id.
+
+## Keep the lifecycle small
+
+Native session history and completed launch recipes persist by default.
+`subagent_resume`, `subagent_release`, and `retain_session` are not part of this
+contract. A completed attempt frees its capacity slot automatically. Ordinary
+workspace/resource cleanup remains owned by the workflow; no session-release
+acknowledgement is required. Preserving history does not keep a deleted workspace
+available for later continuation.
+
+Keep the implementation conversation through repairs. An unfinished review may
+continue only within the workflow's existing HEAD and scope rules. A completed
+independent review round gets a fresh reviewer for the next required round.

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

@@ -8,7 +8,7 @@ dependencies:
   - better-review
   - golden-path
   - harness-runtime
-release-version: 0.50.0
+release-version: 0.50.2
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Resolve issues
@@ -119,15 +119,31 @@ Read each procedure right before its stage; never substitute your own.
 - **Proof.** Treat producer reports as claims until the reviewer or CI checks them. Tests and diagnostic probes
   encode failure in their exit status under [Proof](references/implementation.md#proof); printing an exception
   and returning 0 is not a passing check. Coordination CLIs keep their documented structured-verdict contracts.
-  A unit owes coding acceptance only: its criteria at its `proof.level` plus the required CI
-  on its final HEAD. Integrated release acceptance (a device or system campaign the spec or repository assigns
-  to a release or campaign gate) runs at that gate, never per unit; the handback links its owning issue. Produce
-  no evidence documents; the plan, findings, and reviews are the only records.
+  Apply the [Acceptance criteria](#acceptance-criteria) contract below. Use the plan,
+  findings, reviews and CI artifacts as the records; produce an additional checklist or
+  evidence document only when the issue or repository requires it, deriving results from actual runs.
 - **Delivery.** A dependent starts on its parent's finished code. Stack its PR on the parent's (a GitHub-native
   stack) under a live Mergify queue; chain it when the merge keeps commits; else open it once the parent merges. Live
   steps are only the read-only warehouse canary (never blocks) and the isolated, run-owned resources
   [preflight.md](references/preflight.md#never-block-on-the-human) allows.
 
+## Acceptance criteria
+
+Treat Acceptance Criteria, other issue requirements and later corrections as the contract.
+Reuse or implement automated tests at the lowest sufficient level. Workers deliver behavior
+and tests, run focused local checks, and return with CI pending. CI qualifies the candidate;
+the coordinator verifies results. Human or hardware criteria stay pending until their step passes.
+
+At preflight, record coverage, missing automation, the CI lane and manual remainder in
+findings. Reuse sufficient tests; one may cover several criteria. Acceptance-focused issues
+are supported: automate criteria, fix in-scope defects and qualify results in CI.
+Tests added or code merged alone do not satisfy acceptance.
+
+Defer acceptance only when the issue or agreed policy assigns it to a later gate; link
+its owner. An issue requesting the campaign remains incomplete until its criteria pass.
+Preserve required checks and merge rules. Surface missing execution or enforcement;
+change neither branch protection nor acceptance scope without authorization.
+
 ## Delivery progress
 
 Before briefing or continuing a unit, read [delivery-progress.md](references/delivery-progress.md).
@@ -171,7 +187,7 @@ efforts are run metadata, never a question.
 ### 2. Implement and open the PR
 
 Give each unit a branch, its prepared workspace, and an implementer with its findings entry
-and parents' contracts; retain its [implementation owner](references/implementation.md#implementation-owner)
+and parents' contracts; keep its [implementation owner](references/implementation.md#implementation-owner)
 through review/CI fixes, separately from its active worker slot. 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
@@ -219,6 +235,9 @@ that same `planRevision`.
 
 ## Done
 
+Check each issue's [acceptance contract](#acceptance-criteria) against qualifying results;
+record later-gate obligations. A merged PR does not close pending acceptance.
+
 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

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

@@ -7,6 +7,18 @@ the queue owner's watcher where applicable. Workers may make short status reads
 fetch failed logs for diagnosis, but must not run `gh run watch`,
 `gh pr checks --watch`, a delivery watcher, or create background monitoring.
 
+Qualify the issue's Acceptance Criteria as well as required repository checks.
+Verify that the mapped tests actually ran in the assigned lane against the intended
+candidate and their assertions cover the claimed behavior. A skipped case, missing
+acceptance job, or green unrelated check is not acceptance. Use CI results and artifacts
+for any required checklist; retain manual or explicitly later-gate obligations with
+their owner. Worker completion with CI pending is not issue acceptance. Queue checks
+qualify the combined candidate; post-deploy checks qualify the deployed revision.
+Require each result at its assigned stage: PR admission checks before enqueue,
+queue acceptance before merge, and deployed acceptance after deployment or before
+promotion as specified. Queue-only acceptance is pending at admission, not missing
+PR CI; it cannot be required to pass before the queue candidate exists.
+
 1. Watch the required checks for every pushed HEAD. Pushes to the unit's own
    PR branch need no approval. Green means every required check ran and passed
    on that HEAD: a check that never reported is missing, not passed. Example: a
@@ -105,10 +117,8 @@ provider shows that PR merged.
 
 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 [release any session retention still held](implementation.md#settle-session-retention)
-for it, even while other units remain active; a conversation launched without protection has
-nothing to release. Then record the intent through the [checkpoint mechanism](task-plan.md#checkpoints) (`lifecycle.cleanup`
-`{state: applying, headSha: <the unit's headSha>}`), then run:
+Record the intent through the [checkpoint mechanism](task-plan.md#checkpoints) (`lifecycle.cleanup`
+`{state: applying, headSha: <the unit's headSha>}`), while other units remain active, then run:
 
 ```bash
 node <skill-base-dir>/scripts/cleanup-runs.mjs cleanup --run <run> --unit <unit> \

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

@@ -45,7 +45,7 @@ issue or automatic scheduler gate. They do not waive required validation.
 
 ## Every brief contains
 
-Use the full checklist for a fresh or replacement worker. For a retained conversation,
+Use the full checklist for a fresh or replacement worker. For a continued conversation,
 send the new feedback, current checkpoint, latest failure/fix brief and local evidence,
 current standing orders and changed decisions, affected skill/proof pointers, and new
 result path. Re-read the saved source/criteria after context loss; do not resend the original
@@ -59,6 +59,8 @@ acceptance bar, launch-authority rules and history; it is not a new setup or pro
 - model id, effort, and a required read-back
 - an absolute skill path when the stage invokes a leaf skill; for validating, the unit's `proof.suite` `skill` (read it first) and `local`, when set
 - the outcome and validation, with no prescribed method or evidence format
+- the Acceptance Criteria mapping: existing or missing tests, qualifying CI lane,
+  and manual or explicitly later-gate obligations; include any issue-required checklist
 - 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

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

@@ -15,12 +15,9 @@ nothing is left to settle.
 
 ## Clean before handoff
 
-[Release any session retention still held](implementation.md#settle-session-retention) for each
-unit before normal workspace cleanup; this also applies at each merge while other units
-continue. A launch that asked for none has nothing to release, and an acknowledgement is
-recorded only where protection was actually held. Record any
-resource intentionally kept under the existing lifecycle; never claim it was cleaned
-because its worker exited.
+Clean each delivered unit's workspace and resources at its settlement; this also applies at
+each merge while other units continue. Record any resource intentionally kept under the
+existing lifecycle; never claim it was cleaned because its worker exited.
 
 Clean every delivered unit's workspace and resources before the report, in every
 scheduler mode ([workspaces.md](workspaces.md#cleanup-after-delivery-before-finish)).
@@ -31,6 +28,11 @@ cancelled, pending, or merge-ready handed-back unit that keeps its environment.
 
 ## Close the run
 
+Before closing, distinguish run completion from issue acceptance. Verify the issue's
+Acceptance Criteria against qualifying CI results and required manual results. Keep
+an issue open when its own acceptance remains pending, even if its automation PR
+merged or its human-only remainder was excluded. Link that obligation in the report.
+
 After the report ([SKILL.md](../SKILL.md#done)):
 
 The run is done when nothing it can do is left: every unit landed,

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

@@ -242,10 +242,10 @@ missing, or names a step without a reason.
 | A capability the unit needs is missing and no unit builds it (a shared driver, fixture, or hook) | Build it inside the first unit that needs it; units that need it later get `dependsOn` on that unit. Only when that puts the unit past the size check's line limit, file it as its own issue beside them, with `blocked_by` on the units that use it, never on their parent issue. Example: three proof units each need a device-state reader: the first builds it, the other two depend on the first. |
 | [Human-only](#human-only) blocker | Take its automatic answer ([preflight.md](preflight.md#never-block-on-the-human)); when that defers it, mark `blocked` (`blockedReason: human-decision`, its `humanItem` and `humanNeed`), keep the work, and record what is needed on its owning issue; never ship part of the unit. |
 
-Continue the retained owner in the kept workspace with the current checkpoint, findings
+Continue the saved owner in the kept workspace with the current checkpoint, findings
 and failure evidence. If its process state or required selection prevents continuation,
 use an explicit replacement under the [owner contract](implementation.md#implementation-owner),
-keeping its old session reference for settlement; replacement briefs use those local facts
+keeping the replaced reference as evidence; replacement briefs use those local facts
 rather than an old transcript. Keep the response limits and history above. Record a queue stall with the
 provider pending as a wait and watch again. End the run only when
 `next-actions.mjs`, invoked with [live capacity](implementation.md#live-capacity), prints `finish`, and never claim the spec complete.

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

@@ -125,6 +125,12 @@ The coordinator and any delegated explorer use these rules:
 5. **`layers`:** the parts changed (`backend`, `web`, `android`, `shared`,
    `migration`).
 6. **`proof`:**
+   Map the issue's Acceptance Criteria and other binding requirements to existing
+   tests, missing automation, the qualifying CI lane, and any manual remainder in
+   the existing notes/proof fields. Preserve criterion identifiers when supplied;
+   no new ledger or schema is required. For acceptance-focused issues, include
+   implementing the cases and connecting their execution to CI in the unit's scope.
+
    - `level`: the weakest the run can reach that shows the behaviors work:
      `unit`, `database`, `browser`, or `emulator`.
    - `suite` (`browser`/`emulator` only): the repository's end-to-end suite
@@ -157,9 +163,10 @@ The coordinator and any delegated explorer use these rules:
      Example: a campaign's 25 scenario groups each cover one feature issue; 20
      share "owned emulator, database, and fixture pool" (900 lines).
 
-   `level` is coding acceptance. Integrated acceptance the spec or repository
-   assigns to a later gate (a release device campaign, all-ABI or signed
-   builds, a cross-feature journey) goes in `handback`, naming its gate.
+   `level` selects the test depth for automated acceptance. Put integrated acceptance
+   in `handback`, naming its gate and owner, only when the issue or agreed repository
+   policy assigns it to a later gate. A cross-feature or device journey is not deferred
+   merely because it is expensive; an issue requesting that acceptance still owes it.
 7. **`estimatedLines`: your honest estimate of changed source and test
    lines,** excluding generated files and docs, including every missing
    prerequisite. Do not pad it: the size check scales it by 1.3.

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

@@ -27,7 +27,8 @@ the coordinator.
    not the backend suite.
 5. **Run focused checks locally; CI runs the rest.**
    Example: run the touched package's tests and typecheck, push, and let CI
-   run the full matrix. Never rebuild a release device campaign in a unit.
+   run the full matrix. Run release campaigns only at their assigned gate;
+   implement campaign automation when the current issue requests it.
 6. **Report in one short record and return.**
    Example: "Persists the Charge layout per installation. Ran charge tests
    and typecheck: pass. CI: pending. Pending: release device campaign
@@ -55,51 +56,62 @@ accepts unrestricted writes.
 
 ## Implementation owner
 
+On Pi, read the shared [saved conversation contract](../../harness-runtime/references/subagent-sessions.md)
+for the active schema check, discovery scope, and conversation lifecycle. The rules below
+bind that contract to unit ownership and review repairs.
+
 Keep one implementation conversation per unit through local proof, independent review,
 review fixes and CI repairs. Its saved conversation outlives the active worker slot: launch
 each worker normally, single or batch as the assignment needs, and record the receipt as
-`implementationOwner` ([task-plan.md](task-plan.md#shape)). `retain_session` is optional
-protection from later cleanup, not a precondition for continuing: a completed conversation is
-resumed by its `runId` whether or not retention was requested, and the harness never asks for
-it on resume. Request it only when this caller needs the conversation protected through a long
-wait before cleanup, using the exact argument the launched tool advertises and never inventing
-one for a call that lacks it. A parked owner has no live process and reserves no slot. The
-coordinator still owns scheduling, plan writes, external CI, readiness and delivery;
-reviewers use separate conversations.
-
-`next-actions.mjs` supplies `continuation`, `workerKind`, and, for
-`owner-resume`, `owner`. Resume that completed attempt with
-`subagent_resume({id: owner.runId, prompt: <current brief>})`; record the new attempt ID
-without changing the conversation ID. Selection follows [continuation versus new launch](task-plan.md#worker-selection-on-resume): omit model/effort for ordinary continuation. Use only
-authorized, supported explicit overrides; when a required role-only fill cannot be expressed
-by the resume API, replace from that fill with the retained evidence instead of creating a
-pin from its resolved model ID. Clear `worker` when an attempt
-ends, but keep `implementationOwner` while review or CI is pending. Keep all counters and
-earlier results across attempts. `one-by-one` fixes findings sequentially in this owner.
+`implementationOwner` ([task-plan.md](task-plan.md#shape)): the native `sessionId` and that
+attempt's `runId`, kept as separate fields. A parked owner has no live process and reserves
+no slot. The coordinator still owns scheduling, plan writes, external CI, readiness and
+delivery; reviewers use separate conversations.
+
+Continuation is a spawn into the saved session, not a resume call:
+`subagent_spawn({session_id: owner.sessionId, prompt: <current brief>})` continues that exact
+native session and returns a new attempt `runId` with the same `sessionId`. Record the new
+`runId` as `implementationOwner.runId` and keep the `sessionId`. Never pass an attempt `runId`
+as `session_id`, and never invent a session id a receipt does not hold: a first launch can show
+similar-looking ids, which is not evidence they are interchangeable. Continue from a completed
+attempt: a running or orphaned writer settles first. A conversation started
+from another foreground session still continues: the launch origin does not restrict
+continuation. `subagent_list()` covers the caller's folder and descendants across foreground
+sessions; `all: true` searches globally.
+In a batch, the job's own selector continues that job's session.
+
+`next-actions.mjs` supplies `continuation`, `workerKind`, and, for `owner-resume` or
+`owner-recovery`, `owner`.
+Selection follows [continuation versus new launch](task-plan.md#worker-selection-on-resume):
+omit model/effort for ordinary continuation. Use only authorized, supported explicit
+overrides; when a required role-only fill cannot be expressed by the continuation call,
+replace from that fill with the retained evidence instead of creating a pin from its resolved
+model ID. `session_name` selects an existing conversation by an exact, unambiguous name
+within the caller's folder and descendants; it does not name a new conversation. Fresh
+launches omit both session selectors and may use an advertised fresh-launch naming control.
+A workflow that records ids continues
+`implementationOwner.sessionId` rather than looking a session up by name. Clear `worker` when
+an attempt ends, but keep `implementationOwner` while review or CI is pending. Keep all
+counters and earlier results across attempts. `one-by-one` fixes findings sequentially in this
+owner.
 
 A missing history/workspace, an unusable saved owner, or an owner that cannot continue
 requires an explicit replacement reason and the retained checkpoint, failures and reproducer
-references in the replacement brief. Try the saved conversation first: a `retentionReleased`
-marker says only that optional protection lapsed, so it is not a replacement reason by itself
-and the conversation it names usually still resumes. Report lost continuity; never label a
-new conversation a resume. Existing recovery/stop rules still apply, and old plans without
-an owner use the fresh-worker path. Do not install or update the harness during a run merely
-to obtain continuation.
-
-### Settle session retention
-
-When this unit settles (merged, cancelled, deferred or handed back merge-ready), release any
-retention still held for its `implementationOwner`, `reviewSession` and `retiredSessions` with
-`subagent_release({id: <runId>})` before its normal workspace/resource cleanup. Only a
-conversation launched with `retain_session` has anything to release, so a normal launch skips
-this and a second release is not owed. Record the acknowledgement on that reference when it
-was actually held; an unavailable or refused release stays explicit rather than being
-recorded as done.
-
-Reopening is the ordinary case: resume the saved conversation even when its protection was
-released, because release stops protection and leaves the history in place. Start a fresh
-replacement only when continuation is genuinely unavailable, and carry the original
-checkpoint/findings/counters into it. The same rule covers a released unfinished review,
+references in the replacement brief. Report lost continuity; never label a new conversation a
+resume. Existing recovery/stop rules still apply, and old plans without an owner use the
+fresh-worker path. Do not install or update the harness during a run merely to obtain
+continuation.
+
+A plan written before this contract may hold `implementationOwner {runId}` and no `sessionId`.
+`next-actions.mjs` prints `continuation: "owner-recovery"` for it: first match that exact
+`runId` in `subagent_list({all: true})` or in the verified spawn receipt. A match that names
+its session continues that session and records both ids; with no match, launch an explicit
+replacement with the retained evidence and say why. A `retentionReleased` field left on an old
+plan is inert history: no step reads it, reverses it, or owes a release for it.
+
+Reopening is the ordinary case: continue the saved session; there is no release step in the way.
+Start a fresh replacement only when continuation is genuinely unavailable, and carry the
+original checkpoint/findings/counters into it. The same rule covers an unfinished review,
 keeping its round and existing full-review fallback.
 
 ## Brief
@@ -156,8 +168,10 @@ On `resume` (in flight, no worker, code not done), continue the unit's
    step, error message and evidence path the worker observed. An exit code alone is
    not a failure; keep the first failure separate from cleanup errors. Fix workers
    write the same file. Return
-   nothing else: no artifact hashes, version inventories, screenshots,
-   copied logs, or earlier attempts. For a continuation, include the current checkpoint,
+   only that result by default. When the issue or repository requires a checklist
+   or evidence document, produce it from actual results and link CI artifacts;
+   otherwise omit artifact hashes, inventories, screenshots and copied logs.
+   For a continuation, include the current checkpoint,
    outcome and relevant prior-result links in the existing integration notes; do not
    duplicate the full attempt history. After focused validation, the permitted push,
    and the result, return without waiting for external CI or PR monitoring. Report
@@ -168,14 +182,19 @@ On `resume` (in flight, no worker, code not done), continue the unit's
    not prohibit long local tests or builds needed for the assigned validation.
 
 After 2 fix cycles without progress, or a stuck or late worker, follow
-[expire.md](expire.md). Apply the next response through the retained owner where its
+[expire.md](expire.md). Apply the next response through the saved owner where its
 completed conversation and required launch controls permit continuation. A replacement
 uses the same workspace and the findings entry, failing command/output and `git diff <base>`;
-record why it replaces the owner and retain its session reference as above. Give replacement
+record why it replaces the owner and keep the replaced reference as evidence. Give replacement
 workers those local facts rather than copying the old transcript. Keep all progress counters.
 
 ## Proof
 
+- **Implement the acceptance contract.** Read the issue's Acceptance Criteria and
+  the preflight mapping. Reuse sufficient tests and add missing assertions at the
+  lowest level that exercises the required behavior. Ensure CI selects and executes
+  them in the assigned lane. Return test/criterion references and pending CI or manual
+  obligations in the existing result; the coordinator qualifies acceptance.
 - **Make diagnostic failures executable.** Reuse the existing test runner/assertions.
   A standalone probe exits nonzero for an unexpected exception, failed assertion or
   result outside the expected contract. A catch used to add context rethrows or sets
@@ -226,12 +245,11 @@ workers those local facts rather than copying the old transcript. Keep all progr
   failure ([expire.md](expire.md#infrastructure-failures)): one bounded
   investigation that fixes what the run can; a shared blocker issue only
   when the cause stays unfound or its fix is human-only. Keep the rest moving.
-- Keep `proof.physical` and integrated release acceptance out of the unit's
-  acceptance. A device campaign, all-ABI or signed build, or cross-feature
-  journey the spec or repository assigns to a release or campaign gate runs
-  at that gate: never rebuild it in the unit. Report it as pending in the
-  result; the coordinator records it once in its owning issue, never as
-  passed.
+- Keep `proof.physical` and explicitly assigned later release acceptance pending
+  at their named gate and owning issue. Build the automated tests the current issue
+  requests even when CI runs them as a campaign. If the current issue requests the
+  campaign's result, test implementation alone is not completion. Report manual or
+  unavailable checks as pending, never passed.
 
 ## Scheduling
 
@@ -384,11 +402,15 @@ parent another child holds.
    line's PRs bottom first (`--base <targetBranch>` when it is not the default
    branch); with the Mergify stack hooks installed, push with the `mergify`
    skill's `stack-push.mjs` instead. Keep the body to one short record:
-   `Closes #<issue>`, the behavior delivered, the checks run with their
+   the issue link, the behavior delivered, the checks run with their
    results, and any outstanding blocker or pending obligation as an issue
    link; add the parent PR in `stack` and `chain` mode. CI posts its own run link; cite
    CI-generated artifacts where provenance is required, never hashes or
    logs copied by hand.
+   Use `Closes #<issue>` only when merging this PR will satisfy that issue's own
+   acceptance contract. With outstanding manual or post-merge acceptance, use
+   `Refs #<issue>` in both the PR body and commit message so merging automation
+   does not close the original issue. The coordinator closes it after acceptance.
 3. Record the PR URL and `headSha`; once the code is done, start review while CI runs. Mark the
    PR ready only when review passes and CI is green on the same HEAD
    ([ci.md](ci.md)).

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

@@ -155,6 +155,12 @@ Example: epic #12's #20 (signed release and go/no-go) and #21
 (physical acceptance) stay out of the plan; the run ends when its code units
 land instead of waiting on them.
 
+An automated browser or emulator acceptance campaign is implementable work, including
+when it proves already-merged features. Include its tests, CI execution and requested
+results in scope. For mixed automated/manual criteria, keep the automation unit and
+record the human-only remainder with its owner; report the original issue incomplete
+until that remainder passes. Exclusion records a pending obligation, not acceptance.
+
 ## 4. Assess the plan
 
 Follow [exploration.md](exploration.md#choose-the-owner) on the provisional

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

@@ -11,10 +11,10 @@ restate its rules in the brief beyond the two below.
 - Start a fresh reviewer conversation after each completed review round; the existing
   scope script still chooses delta/full/skip, so freshness adds no review round or test
   campaign. Give it retained records and code evidence as claims to verify, not an
-  implementer transcript. Launch it normally and keep its attempt reference as
-  `reviewSession`, separate from `implementationOwner`, so an unfinished same-HEAD round
-  can continue in that saved conversation; `retain_session` is optional protection, not
-  what makes it continuable. A round after a completed review is a fresh conversation.
+  implementer transcript. Launch it normally and keep its `sessionId` and latest attempt
+  `runId` as `reviewSession`, separate from `implementationOwner`, so an unfinished
+  same-HEAD round can continue in that saved session; a round after a completed review is a
+  fresh conversation.
 - Reviewer model: a different id from the implementer's
   ([preflight.md](preflight.md#1-model-slots)). Launch the reviewer with the
   plan's recorded reviewer fill — its `launch`, `instructions`, `selection` and
@@ -126,23 +126,22 @@ the unfinished work rather than repeating the whole assignment; preserve complet
 valid passes. A wrong HEAD or invalid scope must be corrected, not carried as
 completed proof.
 
-On Pi, use `subagent_resume({id: reviewSession.runId, prompt: <unfinished work>})`
-when that attempt completed as a process and its saved conversation is available;
-update only its attempt reference, keeping this review's round, HEAD and counter.
-A killed/lost attempt or an unavailable continuation follows replacement below. Once the
-review record is complete, the next required review is a fresh conversation. Clear an
-unpinned `reviewSession` directly. If it holds retention, release that protection before
-clearing; on failure, save its exact reference and error in `retiredSessions` before clearing
-so settlement can retry while the fresh review proceeds. Never use a reviewer as the
-implementation owner.
+On Pi, use `subagent_spawn({session_id: reviewSession.sessionId, prompt: <unfinished work>})`
+when that attempt completed as a process and its saved session is available; it returns a new
+attempt `runId` on the same session, so record that `runId` and keep the `sessionId`, preserving
+this review's round, HEAD and counter. A saved record holding only `runId` needs recovery first:
+match that exact attempt in `subagent_list({all: true})` or the verified spawn receipt, continue
+the session it names, and replace it with retained evidence if nothing matches; never pass the
+attempt id as `session_id`. A killed/lost attempt or an unavailable continuation follows
+replacement below. Once the review record is complete, the next required review is a fresh
+conversation. Clear `reviewSession` when the round completes; keep a replaced reviewer's
+reference in `retiredSessions` as evidence, with no release operation owed. Never use a
+reviewer as the implementation owner.
 
 If that reviewer cannot continue, state why replacement is necessary, which
-retained evidence the replacement reads, and what it redoes before launching it.
-A `retentionReleased` marker on the old reference is not a reason by itself: released
-protection leaves the saved conversation in place, so try it again before replacing it.
-While an old reference is still worth resuming or still needs release, keep it as an entry
-in `retiredSessions` ([task-plan.md](task-plan.md#shape)) rather than dropping it; a later
-release of the new session does not release the old conversation. The replacement reviews every pass with `tier: "full"`. Keep the round number,
+retained evidence the replacement reads, and what it redoes before launching it. A
+`retentionReleased` field on an old reference is inert history, not a replacement reason.
+The replacement reviews every pass with `tier: "full"`. Keep the round number,
 `fixRound`, unit `attempt` and earlier round files; incompleteness neither resets
 history nor counts as progress. Launch the replacement from the same recorded
 reviewer fill, in the same structured launch arguments as [the brief](#brief)

package/skills/engineering/resolve-issues/references/shared-modules.md

@@ -157,7 +157,13 @@ and substitute nothing.
 
 **A blocked result ends the run.** `ok: false` — no resolver, no capabilities,
 a declined request, an unadvertised launch control, a missing native selection —
-means report its `code` and `reason` and start nothing. Never reuse an earlier
+means report its `code` and `reason` and start nothing. An unsupported control
+required by the fresh-launch fill is the same block. A missing continuation selector
+alone makes the saved conversation unavailable: report the active schema and use the
+[explicit evidenced replacement](implementation.md#implementation-owner) from the
+authorized fresh-launch fill. It does not block other runnable units. Refreshing a stale
+runtime (`/reload`) is the user's action; never fabricate a call or install/update the
+harness mid-run. Never reuse an earlier
 pick, never fall back to the skill-owned catalog, and never let the reviewer share
 the implementer's model id: the catalog enforces independence, and re-picking a
 replacement here would silently break it.

package/skills/engineering/resolve-issues/references/task-plan.md

@@ -92,9 +92,9 @@ Fleet `status`: `pending`, `in-flight`, `succeeded`, `failed`,
 | `attempt`, `retries`, `escalations` | Attempt number; cycle counts; escalation-model attempts |
 | `worker`, `workerSince`, `clock` | Slot identifier of any worker running for the unit (implementer, reviewer, fix), `null` when none; when that worker started (ISO time, for [stuck-worker checks](expire.md#waits)); attempt and cumulative wall time |
 | `workerKind` | `implement`, `fix`, or `review`, set with `worker`; the [live-capacity scheduler](implementation.md#live-capacity) (`next-actions.mjs`) prints `worker-kind` for any other kind or none. An infrastructure diagnosis or a test-first worker is a `fix` worker. The explorer is the `explore` fleet row's worker, never a unit's; a merge-queue watcher is not a worker |
-| `implementationOwner` | Optional saved implementation conversation: `{runId, sessionId?, cwd?, kind?, retentionReleased?}`. `runId` is its latest attempt; `kind` is `implement` (default) or `fix`, never `review`; `cwd`, when recorded, matches `workspace`. Save spawn/resume receipts here, independently of `worker`; a parked owner occupies no slot. The scheduler emits `owner-resume` for a usable owner or an explicit `ownerUnavailable` reason for replacement; `retentionReleased: true` only records that optional cleanup protection lapsed, so it never makes the owner unusable and the saved conversation stays the resume target while the harness holds it. Old plans remain readable. See [ownership](implementation.md#implementation-owner). |
-| `reviewSession` | Optional `{runId, sessionId?, head, round, retentionReleased?}` for the current unfinished review. Keep it only for same-HEAD/same-scope continuation, and clear it when that round completes so the next completed-review round starts fresh. A `retentionReleased` marker is history, not a reason to replace: try the same round's saved conversation while it exists. It is never an implementation owner or a slot reservation. |
-| `retiredSessions` | Optional references kept beside a replaced implementation owner or unfinished reviewer: `{runId, sessionId?, kind, retentionReleased?, reason?}`. Only for a conversation still worth resuming or still holding protection that must be released later; an ordinary resume or replacement needs no entry here, and a later release of the new session does not release an older conversation. |
+| `implementationOwner` | Saved implementation conversation: `{sessionId, runId?, cwd?, kind?}`. `sessionId` is the native session to continue and is what `subagent_spawn({session_id})` takes; `runId` is that session's latest attempt, never a `session_id`. `kind` is `implement` (default) or `fix`, never `review`; `cwd`, when recorded, matches `workspace`. Save the spawn receipt here, independently of `worker`; a parked owner occupies no slot. The scheduler emits `owner-resume` for a usable owner, `owner-recovery` for a legacy record that holds only an attempt id, or an explicit `ownerUnavailable` reason for replacement. `retentionReleased` on an old plan is inert history: nothing reads or releases it. Old plans remain readable. See [ownership](implementation.md#implementation-owner). |
+| `reviewSession` | Optional `{sessionId, runId?, head, round}` for the current unfinished review: the same session/attempt split, continued only for the same HEAD and scope. Clear it when that round completes, so the next completed-review round starts fresh. It is never an implementation owner or a slot reservation. |
+| `retiredSessions` | Optional references kept beside a replaced implementation owner or unfinished reviewer: `{sessionId?, runId?, kind, reason?}`. Only as evidence for the replacement brief and for the record; no release operation is owed. |
 | `estimatedLines` | Preflight assessment estimate |
 | `sizeCheck` | Measures, `verdict` (the size check's per-unit verdict; `stop` means held), scope and proof verdicts, split or verification path; `runWhole: true` once a recommendation to run a held unit whole is accepted |
 | `note` | SHA, expiry reason code, failure and response, or blocker; for active debugging, the immediate acceptance checkpoint, baseline/result link and next distinguishing test ([delivery progress](../SKILL.md#delivery-progress)) |
@@ -160,13 +160,21 @@ recommendation's reason; its human's words are the invocation.
 ### Worker selection on resume
 
 Distinguish resuming the workflow from continuing one saved conversation. For an ordinary
-same-conversation `subagent_resume`, pass its attempt ID and new feedback, omitting role,
-model and effort so the harness preserves its recorded recipe. The resume tool's schema
-may differ from spawn: do not replay a role selector it cannot accept. A required changed
-selection can continue only through controls both explicitly authorized and advertised by
-that API; otherwise record why replacement is needed and launch fresh from the required
-fill with its retained evidence. A resolved role default alone never authorizes a model pin.
-Keep the original model/effort as run evidence and preserve all review/progress counters.
+same-conversation continuation call `subagent_spawn({session_id: <saved sessionId>, prompt:
+<new feedback>})`: it continues that exact native session and returns a new attempt id, so omit
+role, model and effort and let the harness preserve its recorded recipe. An attempt `runId` is
+never a `session_id`, and no session id is invented for a record that lacks one. A batch carries
+its selector per job: each job in `subagent_spawn_batch({shared, jobs})` names its own session;
+the shared part does not. There is no public resume, release or retain-session call in this
+contract, so never invoke one. If only the continuation selector is missing, report the
+actual schema and lost continuity, then use the explicit evidenced replacement from the
+authorized fresh-launch fill. If that fresh fill requires an unsupported control, the
+catalog's blocked-result rule applies. `/reload` is the user's action; never install or
+update the harness mid-run to gain a capability. A required changed selection can continue only through controls both explicitly
+authorized and advertised by that call; otherwise record why replacement is needed and launch
+fresh from the required fill with its retained evidence. A resolved role default alone never
+authorizes a model pin. Keep the original model/effort as run evidence and preserve all
+review/progress counters.
 
 **A fresh or replacement launch repeats the saved fill, never a reconstruction of it.** On Pi the
 launch authority stays the live role resolver ([shared-modules.md](shared-modules.md#model-slots)):