@1aboveio/skills 1.0.15 → 1.0.17

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

@@ -31,33 +31,155 @@ bundle invocations do not install global hooks. Scripted recovery alone is not
 proof that a Codex surface triggers it; native host compaction/resume certification
 must pass before that surface is advertised as supported.
 
-## Model catalog
+## Model slots
 
-Owner: [`harness-runtime`](../../harness-runtime/) (catalog doctrine and seed
-under `references/`, `model-catalog.mjs`, `discover-models.mjs`). Before
-reading the doctrine, run the fast path:
+Owner: the harness agent catalog. The workflow names four **roles** — implementer,
+explorer, diagnoser (escalation), reviewer — and the harness decides which model
+fills each one and how that role is launched on this host. The shared bridge is
+[`harness-runtime/agent-catalog.mjs`](../../harness-runtime/agent-catalog.mjs);
+this skill owns no ladder, no tier ranking, and no model list.
+
+### Native Pi preflight
+
+When Pi advertises `agents_catalog` and role-based spawning, use the live catalog
+for a run with no task model/effort override or separately declared authoritative
+host preference. Check those inputs before selecting this path: an unpinned task
+can still have `hostPreferences`. The native catalog resolves roles against this
+session's model registry and effort support; a second, caller-built inventory is
+unnecessary.
+
+1. Call `agents_catalog` with `action: "list"`, then `action: "inspect"` for
+   `developer`, `explorer`, and `reviewer`. Inspect all three even when the explorer
+   will not run. The diagnoser uses the same developer role.
+2. Require each inspection's live `launchable: yes` and `availability: available`,
+   with its actual resolved model and effort. `definitionValid` and
+   `catalogLaunchable` alone establish only definition validity, not runtime
+   availability. A missing or blocked live decision stops preflight with that
+   diagnostic; saved defaults do not replace it.
+3. Record the catalog revision and each role's **actual** model and effort as run
+   metadata. A tier fallback can differ from the displayed default. Use the
+   developer result for implementer and diagnoser. Require the reviewer's actual
+   model id to differ from the implementer's, regardless of effort; otherwise
+   stop and report the conflict without choosing a replacement.
+   Save each fill in `selections` as `source: "native-catalog"`, `role`, `id`
+   (actual model), `key` (`id@effort` when effort is present), `effort` (actual
+   effort), `launch: { role }`, `instructions`
+   from the inspection, and the observed `catalogRevision`. Retain the native
+   inspection as `selection` evidence, including requested/actual values and
+   availability. This is native provenance, not a fabricated portable
+   `selection` object or `catalogDigest`.
+4. Record the later launch by role (`{ role: "developer" }`, `{ role: "explorer" }`, or
+   `{ role: "reviewer" }`), adding the task brief and authorized workspace/tool
+   controls. The native catalog applies its live instructions and defaults again
+   at admission. Record actual launch provenance if it differs from preflight.
+
+This completes model preflight; continue to the provisional target without
+running `preflight-models.mjs` or manufacturing `available[]`. Worker capacity is
+a separate scheduling input, not model evidence. An explicit task model or effort
+override or authoritative host model/effort preference still needs validation for
+that exact request: use the portable path below when the native inspection cannot
+validate it and preserve its structured launch fields. Keep the request; an
+unresolved request does not authorize a default launch.
+
+### Portable preflight
+
+For a host without native role resolution, or a task override or authoritative
+host preference requiring portable validation, write observed host capabilities
+to a temporary JSON file (any writable path; the run directory does not exist yet
+at step 1):
+
+```json
+{ "available": [{ "model": "provider/model", "nativeModel": "host-id", "supportedEfforts": ["medium", "high"] }],
+  "foregroundModel": "provider/model",
+  "launchCapabilities": { "model": true, "effort": true, "instructions": true },
+  "hostPreferences": { "developer": { "model": "provider/model" } },
+  "fallbackToForeground": false }
+```
+
+Every field is evidence the host reports, never something to fill in from memory;
+a field you cannot observe is left out, and the bridge never completes one.
+
+| Field | Meaning |
+|---|---|
+| `available[]` | This turn's models. Each entry needs verified `supportedEfforts`; IDs alone from configuration or `discover-models.mjs` do not supply effort support. `nativeModel` is required for a harness whose slots are launched by a bare host id (Codex); pass the advertised mapping unchanged. |
+| `launchCapabilities` | The launch controls this host exposes: `model`, `effort`, `instructions`, each a boolean. All three must be stated; omission is not "probably true". A native id and an effort say what the catalog chose, never that the adapter can set it. |
+| `hostPreferences` | This host's own role preferences, keyed by **role** (`developer`, `explorer`, `reviewer`), each `{ model?, effort? }`. Below a task override and above the role default: it is how a host says "this machine runs the developer role on this model". |
+| `fallbackToForeground` | Set `true` only when this host may use the foreground model as a fallback. Pi always may; another harness must opt in. Absent, no foreground fallback happens for it. |
+| `tiers` | `{ tiers: { name: { members: [], candidates: [] } } }` — tier membership plus the ordered candidates that may replace an unavailable preferred model. `members` and `candidates` are `provider/model` ids; a candidate may be `{ model, crossProvider: true }` to allow another provider. An empty `candidates` list means no substitution. |
+| `overrides` | The task's own pins, keyed by **slot** (`implementer`, `explorer`, `diagnoser`, `reviewer`). Highest precedence. |
+
+`hostPreferences` is how a machine states its own choice instead of leaving it to the
+saved role default. Example: this host's personal developer role points at a small
+local model, but this machine runs the developer role on a stronger
+`provider/model`. Declaring `"hostPreferences": { "developer": { "model":
+"provider/model", "effort": "high" } }` outranks the role default; the catalog
+reports it as an explicit request and the Pi launch keeps it instead of stripping
+it back to `{ role }`. Omit the effort and only the model is pinned.
+
+Then run:
 
 ```bash
 node <skill-base-dir>/scripts/preflight-models.mjs \
-  --harness <pi|codex|claude-code> --risk <routine|high> \
-  --available <comma-separated-current-turn-model-ids> --ask-only
+  --harness <pi|codex|claude-code> --capabilities /tmp/resolve-issues-capabilities.json
 ```
 
-Record its fills without asking. Use its `options` (up to four, recommended
-first) for the implementer question at the approval; accept an `alternate`
-or any discovered model the human names. Never run scripts under
-`archive/resolve-issues/`.
+Record its fills by exact id and effort as run metadata, and show them on the
+board. No role is a question: this workflow never asks which model should
+implement, and the script emits no option list. The resolver is
+`pi-agent-catalog` on PATH, or the JSON argv in `PI_AGENT_CATALOG_COMMAND` when
+a host wraps it. Never run scripts under `archive/resolve-issues/`.
 
-| Slot | Selection |
-|---|---|
-| Implementer, routine | `gpt-6.1-sol@high`, `gpt-6-luna@high`, `grok-4.6@high`, `mimo-v2.6-pro@high` |
-| Implementer, high risk | `gpt-6.1-sol@high`, `gpt-6-astra@high`, `gpt-5.6-sol@high`, `grok-4.7@high` |
-| Explorer | `gpt-6.1-sol@medium`, then the routine ladder without `gpt-6.1-sol@high` |
-| Escalation (test-first workers, and fix workers after a cycle without progress; `preflight-models.mjs` key `diagnoser`) | The high-risk ladder, at any risk |
-| Reviewer | `gpt-6-astra@medium`; `gpt-5.6-sol@medium` when Astra implements; otherwise the payload's distinct-model ranking |
-
-Use only discovered or named models. Sync the catalog only after the
-approval. Require each spawn's read-back to match its slot.
+| Role | Payload | Spawn with |
+|---|---|---|
+| Implementer | `implementer` | its own `launch` + `instructions` |
+| Explorer | `explorer` | its own `launch` + `instructions` |
+| Escalation (test-first workers, and fix workers after a cycle without progress) | `diagnoser` (developer role) | its own `launch` + `instructions` |
+| Reviewer | `reviewer` | its own `launch` + `instructions` |
+
+Each fill carries `{ id, key, effort, role, launch, instructions, selection }`,
+and the payload carries the `catalogDigest` they were resolved under.
+
+**Launch the fill, not the model.** On Pi a `launch` is `{ role }` plus a `model`
+and `thinking` only when something explicitly asked for them: the human's task
+override, or the host's own preference, which the catalog reports as an explicit
+selection. A resolved role default is never copied in — the live Pi catalog keeps
+supplying that. On Codex the `launch` is `{ model, effort, instructions }` with the
+adapter's native id, and the run is blocked unless the host advertised every
+control that launch needs: a slot whose harness cannot express the selection is a
+blocked run (`launch-unsupported`), never a launch that claims a model it did not
+set; never describe a model choice in the brief and call it selection.
+
+Use the implementer fill for the run and show it as resolved. A model the human
+names is an explicit override: rerun the fast path with `--implementer
+<id[@effort]>` and use that result. A pinned implementer that the catalog
+declines is `ok: false` with `code: pinned-implementer-unavailable`; end the run
+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
+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.
+
+`capabilities-missing` describes incomplete resolver input, not proof that the
+host cannot launch workers. Check the supplied file and this turn's native
+capability source before declaring a harness limitation. Repair an omitted field
+from verified evidence and retry preflight; if that evidence is unavailable,
+report the exact missing input. Never derive effort ranges from a selected role
+default or use free worker slots as a model inventory.
+
+**No fallback is invented.** The catalog substitutes only an available model from
+the same tier's configured `candidates`, and never for an explicit request: an
+unavailable pin or host preference blocks rather than sliding to a neighbour, and
+a non-Pi host does not inherit the foreground model unless it set
+`fallbackToForeground: true`. Nothing here upgrades, downgrades, or keeps a
+previous run's pick to avoid a block.
+
+The `harness-runtime` package's legacy `model-catalog.mjs` and `discover-models.mjs`
+modules remain for other consumers that still import them; this workflow imports
+only `detectHarness` from `discover-models.mjs` and never uses either to select a
+model slot. The skill's own compatibility wrappers for those commands are gone.
 
 ## Leaf skills
 

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

@@ -1,6 +1,6 @@
 # Task plan
 
-Draft the plan in preflight, before exploration, and update it on every
+Draft the plan in preflight, before the assessment, and update it on every
 worker and stage transition.
 
 ## Initialize the run
@@ -92,7 +92,7 @@ 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 |
-| `estimatedLines` | Explorer estimate |
+| `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)) |
 | `pr`, `headSha`, `reviewedHead` | PR URL, current HEAD (recorded from the implementer's first pushed commit on, so the draft PR opens early), last HEAD whose verdict was `pass` (reviewed or carried) |
@@ -117,15 +117,27 @@ Run fields: optional `installation` holds the explicit native installation descr
 pinned external root mappings). Capture from the selected bundle and preserve it
 through workers and recovery; never replace it with a newer cache or shared copy.
 Other run fields: `skill` (`resolve-issues` or `rush-issues`; the scheduler and
-rehydrate read it, and `next-actions.mjs` exits 2 without it), `planRevision`, models and efforts, `targetBranch`,
+rehydrate read it, and `next-actions.mjs` exits 2 without it), `planRevision`, `selections`, `targetBranch`,
 `workspaceLifecycle: 1` and `repoRoot` ([workspaces.md](workspaces.md)),
 `deliveryMode` and its check, `mergeMode`, run directory, `specLocator`
 (`owner/name#N` or an issue URL; any other name turns off the issue-tree sync),
 exploration path, `decisions`, `standingOrders`, `schedulerMode` (`full`, `narrow`, or `off`), timestamps, and `excluded` (issues in the
 tree that are deliberately not units, each `{issue, reason}`: release or
-approval gates, and rollups the explorer found empty). A run resumed from an
+approval gates, and rollups the assessment found empty). A run resumed from an
 older wave run keeps `merged` (unit ids merged by earlier runs).
 
+`selections` records each slot's fill from the selected
+[model-preflight path](shared-modules.md#model-slots). A native Pi fill records
+`source: "native-catalog"`, `role`, actual `id`, `key` and `effort`, `launch: { role }`,
+inspected `instructions`, `catalogRevision` and the retained native inspection
+as `selection`. A portable fill is what `preflight-models.mjs` returned —
+`id`, `key`, `effort`, `role`, `launch`, `instructions`, `selection`, and the
+`catalogDigest` it was resolved under — beside the explicit task or host override
+that produced it, when one did
+([shared-modules.md](shared-modules.md#model-slots)). Its `id` and `effort` are
+recorded evidence of what the catalog resolved, not a pin to replay. The fill is
+what a later launch of the slot repeats; a pair of model ids is not.
+
 `reviewFindings` entry: id, `severity` P0-P2 (P3 is skipped, never recorded), summary, locator, `status`
 (`open`, `resolved`, `deferred`), `resolvedHead`, `dropboxId` or `followUpUrl`. Copy them
 from `review-verdict.mjs`: on `fix` its `fix` list as `open`; on `pass` its
@@ -139,6 +151,41 @@ question it settles (`results/<unit>-<label>.json`, or
 agent's recommendation adds `source: agent-recommendation` and the
 recommendation's reason; its human's words are the invocation.
 
+### Worker selection on resume
+
+**A 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)):
+its `launch` is `{ role }` unless an explicit task override or this host's own
+preference asked for a model or effort, and a resolved role default is never
+written out as an explicit pin. On a non-Pi host the recorded `launch` is the
+payload, and it names only the controls that host advertised. What a worker
+actually launched with, its model and effort included, and its result are that
+worker's run evidence: record them, keep them immutable, and never re-apply them
+to another launch or rewrite them.
+
+A plan saved before `selections` holds model ids and efforts and nothing saying
+who chose them. Read such a value as evidence of what ran, never as a pin: do
+not pass it as an explicit Pi model or effort. Before launching new workers,
+repeat this host's model-preflight path ([preflight.md](preflight.md#1-model-slots))
+with only the overrides the run can evidence — a `standingOrders` line, a
+human-authored decision, or an explicit override in the invocation, never an
+agent recommendation or stored metadata alone — and record its resolved fills
+as `selections`. When an override's provenance, or a launch control the current
+host must advertise, cannot be established, block the new launch and name what
+is missing: report the code and reason and start nothing, rather than guessing a
+pin. Workers already running or finished keep their configuration and history.
+A resume asks no model question; a human who changes one does so as a separate
+task input, recorded as a decision and resolved the same way.
+
+For `source: "native-catalog"`, recheck current task overrides and authoritative
+host preferences on resume. With neither, repeat live native inspection rather
+than demanding a portable `catalogDigest` or running the portable script. A newly
+declared preference or override returns through the exact-request validation path;
+do not replay role-only defaults in its place. Keep
+the old inspection as historical evidence; refresh preflight selection metadata
+without rewriting any worker's actual launch history. A native inspection is not
+an override, and its saved model and effort never become launch arguments.
+
 ### Standing orders
 
 **`standingOrders` are the run's only constraints.** A numbered list, one
@@ -178,14 +225,20 @@ Example: someone files #61 under epic #12 mid-run; the next resume prints
 - A failed fetch keeps the saved tree; a partial one never drops a unit or
   changes dependencies. A failed fetch before finishing never finishes:
   `next-actions.mjs` with [live capacity](implementation.md#live-capacity) prints `sync` until a fetch reads the tree.
-- `set-deps` only adds; a dependency the explorer recorded stays.
+- At start and resume, fetch current spec and existing unit issue bodies from
+  their source and compare their criteria with the saved requirements, decisions,
+  contracts and relevant guidance. The tree fetch updates membership and links,
+  not issue bodies; unchanged sync output does not establish unchanged criteria.
+  Reassess affected units under [assessment reuse](exploration.md#reuse-first),
+  or reassess when the prior inputs cannot be established, before scheduling them.
+- `set-deps` only adds; a dependency recorded in findings stays.
 - `cycle`: units depend on, or are chained on, each other, so none can move.
   Remove the link that is not a real dependency (on GitHub and in the plan);
   for a `stacksOn` loop, restack the unit it names onto the target.
 - `blocked-outside`: put the blocker into the tree (as a sibling of the
   waiting issue) or remove the link; never leave a unit waiting on an issue
   the run cannot see.
-- A rollup the explorer finds empty goes to `excluded` with "nothing left:
+- A rollup the assessment finds empty goes to `excluded` with "nothing left:
   close it", and into the handback.
 - A unit that depends on an `excluded` issue waits for a human: it stays
   `pending` (not started), `next-actions.mjs` with [live capacity](implementation.md#live-capacity) gives it no action, and
@@ -196,7 +249,7 @@ Example: someone files #61 under epic #12 mid-run; the next resume prints
 ## Scope changes
 
 Record a new requirement as a decision, update the affected criteria,
-continue the explorer on affected and new units, rerun the size check, and
+reassess affected and new units using [owner routing](exploration.md#choose-the-owner), rerun the size check, and
 show the board. Put the change in in-flight units' next brief; never copy
 files into a running workspace. Add new units as rows and schedule them
 normally.
@@ -279,7 +332,8 @@ text board. Keep the board and file in agreement. Never show an unsaved transiti
 
 ## Board
 
-Show the first board before the explorer spawn, as a record.
+Show the first board before the preflight assessment, as a record. The fleet
+`explore` row tracks that assessment, with a worker only when one is delegated.
 
 ```text
 resolve-issues  rev 12  workers 2  elapsed 18m  delivery stack

package/skills/engineering/resolve-issues/scripts/findings-reuse.mjs

@@ -66,7 +66,7 @@ export function findingsReuse({ prior, units, head = 'HEAD' }) {
   let baseKnown = typeof prior?.base === 'string' && prior.base.trim() !== ''
   let changed = []
   if (baseKnown) {
-    try { changed = git(['diff', '--name-only', prior.base, headSha]).split('\n').filter(Boolean) } catch { baseKnown = false }
+    try { changed = git(['diff', '--name-only', '--no-renames', prior.base, headSha]).split('\n').filter(Boolean) } catch { baseKnown = false }
   }
   const ids = units?.length ? units : Object.keys(prior?.units ?? {})
   return { base: prior?.base ?? null, head: headSha, ...decideReuse(prior, ids, changed, baseKnown) }

package/skills/engineering/resolve-issues/scripts/next-actions.mjs

@@ -16,8 +16,8 @@
 //                   GitHub call. Sync after the run files an issue
 //   unblock         a unit marked blocked without a reason from BLOCK_REASONS
 //                   (`blockedReason`), or human-decision without `humanItem` (1-5) and
-//                   `humanNeed`: reopen it now; and on --resume, every blocked unit:
-//                   reopen it with fresh limits; its next step follows. A note never keeps a
+//                   `humanNeed`: reopen it now; on --resume, reopen prior blocks with fresh
+//                   limits except a current size stop without accepted runWhole. A note never keeps a
 //                   unit blocked. A complete review at the unit's HEAD that holds a P0/P1 but
 //                   wrote no fix brief and awaits no GitHub reviewer (a handback) gets a
 //                   fresh full round, so review-verdict hands it back again only if its
@@ -122,7 +122,7 @@ import { BLOCKING } from './review-verdict.mjs'
 export const WORKER_KINDS = Object.freeze(['implement', 'fix', 'review'])
 export const SKILL_PATH = join(dirname(dirname(fileURLToPath(import.meta.url))), 'SKILL.md')
 // Printed after every text call, and by rehydrate.mjs after a compaction.
-export const RULES = 'Per unit, run only implement, fix, and review workers, recorded as workerKind: no planning, architecture, product, or setup workers. Exploration continues the run\'s one explorer, on the fleet explore row. You coordinate: never edit product code. In full mode take every step from next-actions.mjs; in every mode the run ends only when it reports done. A HEAD after a passing review is carried; any other new HEAD takes the tier rereview-scope.mjs picks, never yours. Decide before you defer: a question a worker or review raises is answered and recorded, then the unit continues; retrying or deferring never answers it. Never block on the human: take the automatic answer and keep going. Fix the root cause, never only its symptom. Before each scheduling pass, refresh subagent_settings and pass its snapshot with --capacity-json; do not reuse a run-start budget or subtract workflow workers again.'
+export const RULES = 'Per unit, run only implement, fix, and review workers, recorded as workerKind: no planning, architecture, product, or setup workers. You own preflight findings; use an optional explorer on the fleet explore row only for concrete planning unknowns (exploration.md). You coordinate: never edit product code. In full mode take every step from next-actions.mjs; in every mode the run ends only when it reports done. A HEAD after a passing review is carried; any other new HEAD takes the tier rereview-scope.mjs picks, never yours. Decide before you defer: a question a worker or review raises is answered and recorded, then the unit continues; retrying or deferring never answers it. Never block on the human: take the automatic answer and keep going. Fix the root cause, never only its symptom. Before each scheduling pass, refresh subagent_settings and pass its snapshot with --capacity-json; do not reuse a run-start budget or subtract workflow workers again.'
 export const DEFAULT_QUIET_MINUTES = 45
 // The reasons a unit may stay blocked (expire.md#reason-codes). Waiting on another unit, an
 // infrastructure or external blocker (a tree issue the unit waits on), and a size hold in a rush
@@ -205,15 +205,15 @@ export function nextActions(plan, reviews = {}, capacity, { resume = false, now,
   if (!Array.isArray(saved) || saved.length === 0) throw new NextActionsError('task plan has no units')
   const excluded = excludedIds(plan)
   const gates = (u) => (u.dependsOn ?? []).map(String).filter((d) => excluded.has(d))
-  // In a rush run, a size-held unit is split, never deferred: it gets `split` until the sync
-  // drops it (split into sub-issues) or a rerun size check clears it.
+  // A current size stop survives resume. Rush splits it; a normal run may hand it back.
   const shortcut = plan.skill === 'rush-issues'
-  const sizeHeld = (u) => shortcut && (u.sizeCheck?.verdict ?? u.sizeCheck?.scope) === 'stop' && u.sizeCheck?.runWhole !== true && !codeDone(u)
+  const heldForSize = (u) => (u.sizeCheck?.verdict ?? u.sizeCheck?.scope) === 'stop' && u.sizeCheck?.runWhole !== true && !codeDone(u)
     && !hasWorker(u) && u.status !== 'succeeded' && u.status !== 'cancelled' && gates(u).length === 0
     && !excluded.has(String(u.id))
+  const sizeHeld = (u) => shortcut && heldForSize(u)
   const reasonOk = (u) => BLOCK_REASONS.includes(u.blockedReason) && !(shortcut && u.blockedReason === 'size-hold')
     && (u.blockedReason !== 'human-decision' || namesHumanItem(u))
-  const reopen = (u) => (resume || !reasonOk(u)) && u.status === 'blocked' && !hasWorker(u) && gates(u).length === 0 && !sizeHeld(u)
+  const reopen = (u) => (resume || !reasonOk(u)) && u.status === 'blocked' && !hasWorker(u) && gates(u).length === 0 && !heldForSize(u)
   // `stack` and `chain` both open a child's PR once its parents' PRs are open; only the PR base differs.
   if (plan.deliveryMode !== undefined && !['stack', 'chain', 'wait'].includes(plan.deliveryMode)) throw new NextActionsError(`deliveryMode must be stack, chain, or wait: ${JSON.stringify(plan.deliveryMode)}`)
   const chain = plan.deliveryMode === 'chain'

package/skills/engineering/resolve-issues/scripts/plan-sync.mjs

@@ -139,7 +139,7 @@ export function planSync(plan, tree) {
     const { deps } = wants(key)
     const id = idFor(key, repo)
     const rollup = (node.children ?? []).length > 0
-    add('add-unit', id, `add unit ${id} for ${key} "${node.title}"${deps.length ? ` with dependsOn [${deps.join(', ')}]` : ''}: fetch its issue into the run, continue the explorer for it, rerun the size check${rollup ? '; every sub-issue is closed, so the explorer records what is left or that nothing is (then hand back "close it")' : ''}`, { issue: key, dependsOn: deps })
+    add('add-unit', id, `add unit ${id} for ${key} "${node.title}"${deps.length ? ` with dependsOn [${deps.join(', ')}]` : ''}: fetch its issue into the run, assess it using exploration.md's owner routing, rerun the size check${rollup ? '; every sub-issue is closed, so record what is left or that nothing is (then hand back "close it")' : ''}`, { issue: key, dependsOn: deps })
   }
   for (const [key, u] of byKey) {
     if (DONE.has(u.status)) continue