@1aboveio/skills 1.0.15 → 1.0.16

package/skills/engineering/harness-runtime/contracts.md

@@ -13,3 +13,5 @@ Shell code cannot invoke a native question tool inside the agent's current turn.
 When no supported native question tool is advertised, concise free-text input is permitted only for one optionless question. Textual multiple-choice emulation is forbidden. Unsupported multi-select and all secret input fail explicitly rather than degrading silently.
 
 Model discovery and catalog persistence remain separate from question planning. Current-turn tool availability is never inferred from model or harness configuration. Source-tree imports outside `skills/engineering` are unsupported until an installation-aware adapter entrypoint exists; consumers must not copy the runtime to work around that boundary.
+
+`agent-catalog.mjs` is the consumer bridge to the harness-owned agent catalog: one versioned JSON request on stdin (`version`, `harness`, `cwd`, `available`, `foregroundModel`, `fallbackToForeground`, `launchCapabilities`, `hostPreferences`, `overrides`, `tiers`, …) and one JSON response on stdout with four worker slots. It resolves the resolver command from `PI_AGENT_CATALOG_COMMAND` (a JSON argv array, or one bare executable token) or defaults to `pi-agent-catalog` on PATH, runs it with no shell, bounds its output and runtime, and validates the response. Those host fields are validated and forwarded unchanged — nothing is inferred or completed here, so an unstated launch control or tier stays unstated. A missing, broken, or declining resolver is a reported block; the bridge never falls back to a skill-owned model ladder and never installs anything. `discover-models.mjs` and `model-catalog.mjs` remain for consumers that still import them and are no longer part of model-slot selection.

package/skills/engineering/harness-runtime/references/model-catalog.md

@@ -1,6 +1,12 @@
 # Model catalog (skill-owned baseline, per-harness overrides)
 
-resolve-issues preflight must classify every discovered model (family · tier) before it can recommend a pick for each slot. The installed `harness-runtime` package provides the shared catalog baseline at `references/model-catalog-seed.json`; the per-harness JSON files below hold only **explicit, human-confirmed overrides**. A skill install or update replaces the shipped baseline, so its newer classifications apply on the next pre-flight wherever no local override exists. It never copies that baseline into a user file or silently changes an override. Training-data knowledge is not a discovery source, and neither is this file's *absence* of a model: only discovered or explicitly human-named models are eligible ([resolve-issues shared modules](../../resolve-issues/references/shared-modules.md)).
+> **Legacy compatibility surface.** Model-slot selection now belongs to the harness agent catalog,
+> reached through [`agent-catalog.mjs`](../agent-catalog.mjs); `resolve-issues` names roles and reads
+> that bridge instead of classifying models. This document and `model-catalog.mjs` stay for other
+> consumers that still import them, and for the shipped baseline data. Do not use this doctrine to
+> re-derive a model ladder for a workflow.
+
+The legacy resolve-issues preflight classified every discovered model (family · tier) before it could propose a pick for each slot. The installed `harness-runtime` package provides the shared catalog baseline at `references/model-catalog-seed.json`; the per-harness JSON files below hold only **explicit, human-confirmed overrides**. A skill install or update replaces the shipped baseline, so its newer classifications apply on the next pre-flight wherever no local override exists. It never copies that baseline into a user file or silently changes an override. Training-data knowledge is not a discovery source, and neither is this file's *absence* of a model: only discovered or explicitly human-named models are eligible ([resolve-issues shared modules](../../resolve-issues/references/shared-modules.md)).
 
 **Read and write through [`model-catalog.mjs`](../model-catalog.mjs)** rather than hand-editing the JSON — it single-sources the prune predicate and the write paths. Run `model-catalog.mjs help`; the script is the source of truth for the precedence composition, the write-guards, and the shapes. At pre-flight step 2 **prefer `tiers --seen <ids>`**: it composes all three evidence arms (banked → cross-harness → team seed) with the precedence applied *inside* the command. A precedence or filtering rule stated only in prose is applied by an agent mid-gate from memory, and the failure is silent — exactly how rules 5 and 7 went wrong before 2026-07-20.
 

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

@@ -1,6 +1,6 @@
 ---
 name: resolve-issues
-description: "Slash/explicit-only (/resolve-issues). Drive an issue, epic, or feature spec to reviewed, green PRs, one per issue, merged or handed back merge-ready: preflight, task map, exploration and a per-issue slice check, isolated implementers within live host capacity, then per issue its PR, independent better-review, CI, and queue/merge (or merge-ready hand-back) as soon as it is done. Asks once, at the end of preflight (implementer, target branch, merge mode, scheduler mode, plan), then never blocks on the human; small non-blocking problems collect in a dropbox, posted at the end as grouped ready-for-agent issues. /rush-issues is its no-questions shortcut. Do not auto-select. Use for whole-spec delivery, including high-risk work; risk changes model and validation depth, never the workflow. NOT for release work (resolve-release)."
+description: "Slash/explicit-only (/resolve-issues). Drive an issue, epic, or feature spec to reviewed, green PRs, one per issue, merged or handed back merge-ready: preflight, task map, exploration and a per-issue slice check, isolated implementers within live host capacity, then per issue its PR, independent better-review, CI, and queue/merge (or merge-ready hand-back) as soon as it is done. Asks once, at the end of preflight (target branch, merge mode, scheduler mode, plan) and resolves the worker roles' models as run metadata instead of asking, then never blocks on the human; small non-blocking problems collect in a dropbox, posted at the end as grouped ready-for-agent issues. /rush-issues is its no-questions shortcut. Do not auto-select. Use for whole-spec delivery, including high-risk work; risk changes model and validation depth, never the workflow. NOT for release work (resolve-release)."
 disable-model-invocation: true
 metadata:
   workflow-role: coordinator
@@ -8,7 +8,7 @@ dependencies:
   - better-review
   - golden-path
   - harness-runtime
-release-version: 0.47.0
+release-version: 0.48.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Resolve issues
@@ -55,7 +55,7 @@ after 2 fix rounds without a new low of open P0/P1 path rows; no fixed round cap
 ```text
 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)
+  -> one approval (target branch, merge mode, scheduler mode, plan)
   -> schedule runnable units within live host capacity:
        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
@@ -102,7 +102,9 @@ Read each procedure right before its stage; never substitute your own.
   started (`pending`), never `blocked`; what stays blocked ends deferred on its owning issue, never done.
 - **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
+  check. When a journey or case you run fails, copy its `NATIVE_FAILURE` line (or the failing step, error and
+  evidence path) into the unit's plan row; an exit code alone is not a failure record.
+  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
   full again before your next step: the summary keeps the run's state, not these rules. Fill
   free slots before starting your own work, stay within [expire.md](references/expire.md)'s limit, and send
@@ -143,7 +145,8 @@ Follow [preflight.md](references/preflight.md):
 0. **Ready label:** resume the spec's run if one exists; run `ready-check.mjs`;
    stop on an `unreadable` outcome; ask at step 6 on `unlabeled` or a `missing` compaction
    hook (`install-hooks.mjs --check`; shortcut: warn).
-1. **Model slots:** record the fast-path fills without asking.
+1. **Model slots:** record the fast-path fills without asking; the models and
+efforts are run metadata, never a question.
 2. **Provisional target:** the default branch.
 3. **Plan draft:** one unit per issue, links, delivery mode; show the board.
 4. **Exploration:** have one explorer record each unit's `slice` and,
@@ -152,7 +155,7 @@ Follow [preflight.md](references/preflight.md):
    ([exploration.md](references/exploration.md#reuse-first)).
 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;
+6. **Approval:** ask once for target, merge mode, scheduler mode, and plan;
    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)).

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

@@ -49,6 +49,8 @@ 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
+- for a fix after a failed check or case, the last `failure` block (case, step, error,
+  evidence path) verbatim, so the worker starts from the cause
 - a concise worker-specific contract: business outcome and context, full acceptance,
   security and quality requirements, and principles relevant to the assigned work; a
   reviewer gets review.md's two rules instead. Do not forward coordinator scheduling

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

@@ -220,9 +220,12 @@ secret the repository lacks is item 5: hand it back.
 Spawn no separate diagnosis worker for a known failure kind, and write no
 diagnosis document; an unknown infrastructure failure gets one fix worker
 ([Infrastructure failures](#infrastructure-failures)). The failure kind
-is already known from the reason code, the failing check, or
-`review-verdict.mjs`; take its response, keep the branch, workspace, and
-logs, and record one line, with the reason code, in the unit's plan row.
+is already known from the reason code, the failing check, the result's
+`failure` block, or `review-verdict.mjs`; take its response, keep the branch,
+workspace, and logs, and record one line, with the reason code, in the unit's
+plan row. A failed case whose `failure` names the step and error goes straight
+to a fix worker with that block. Assign investigation only when the record is
+missing, or names a step without a reason.
 
 | Failure | Response |
 |---|---|

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

@@ -101,7 +101,12 @@ implementer in its kept workspace with the brief and its findings entry.
    line, kind, one-line summary, whether it needs a human decision), and
    `decisionNeeded`: `null`, or the choice that stops the unit (question,
    options, recommendation; options are ways to proceed, and staying
-   blocked is never one). Fix workers write the same file. Return
+   blocked is never one). When a check or case fails, add
+   `failure`: `{case, step, error, evidenceDir}`, copied from the harness's
+   `NATIVE_FAILURE` line or failure record when it prints one; otherwise the failing
+   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,
    outcome and relevant prior-result links in the existing integration notes; do not

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

@@ -78,16 +78,27 @@ posts them; they join this run's end-of-run review
 
 ## 1. Model slots
 
-Run the fast path and record its fills by exact id and effort, using the
-ladders in [shared-modules.md](shared-modules.md#model-catalog). Never give
-the reviewer the implementer's id, at any effort. Let risk raise the tier and
-add the repository's deterministic domain checks, never change the workflow.
+Write this turn's host evidence to a temporary JSON file and run the fast path
+([shared-modules.md](shared-modules.md#model-slots)); record its fills by exact id
+and effort. The skill names the roles — implementer, explorer, diagnoser,
+reviewer — and the harness agent catalog chooses the models, so rank nothing and
+copy nothing from a ladder. The fills are run metadata: show each role's model
+and effort on the board and never ask which model should implement. A model the
+human names is an explicit override, resolved by rerunning this step with
+`--implementer`, never by offering a list. Never give the reviewer the
+implementer's id, at any effort: the catalog enforces that, and the run blocks
+when it cannot. Let risk
+add the repository's deterministic domain checks and review depth, never change
+the workflow or re-choose the model.
 
 Pass a pinned implementer (`implementer=<id[@effort]>` in the invocation) as
-`--implementer`; when the result is `ok: false` with code `pinned-implementer-unavailable`, end the run as "pinned implementer unavailable"
-and never substitute another model.
-Example: `/rush-issues 1aboveio/ai#1545 implementer=gpt-6-luna@high` with no
-`gpt-6-luna` discovered stops at preflight and starts nothing.
+`--implementer`. Any `ok: false` result ends the run at preflight with its `code`
+and `reason`, starting nothing: `pinned-implementer-unavailable` means the pinned
+model is unavailable and no other implementer is substituted, and
+`catalog-unavailable` or `capabilities-missing` means this host cannot resolve
+roles yet. Never revive the old picker or reuse an earlier run's pick.
+Example: `/rush-issues 1aboveio/ai#1545 implementer=gpt-6-luna@high` on a host
+whose catalog does not offer `gpt-6-luna` stops at preflight and starts nothing.
 
 ## 2. Provisional target
 
@@ -295,7 +306,8 @@ Example: `/resolve-issues` answered "run the rest" files nothing;
 Show the board: units, delivery mode, verdict and reasons by consideration,
 each unit's behaviors, missing prerequisites, proof and suite, environment
 checks, held units with splits, the pending device record, the
-issues missing `ready-for-agent`, and handback steps. Ask
+issues missing `ready-for-agent`, and handback steps. Show each role's resolved
+model and effort as run metadata; no question asks for one. Ask
 in one interaction, with the native single-choice tool when there is one:
 
 0. **Ready label** (only after step 0 `unlabeled`): list the `missing` issues,
@@ -304,20 +316,18 @@ in one interaction, with the native single-choice tool when there is one:
    proceed, record it in `decisions`; on stop, end the run with the list.
    **Compaction hook** (only when `install-hooks.mjs --check` printed `missing:`):
    install it (recommended), or run without it.
-1. **Implementer:** the payload's `options`, recommended first, each with its
-   reviewer. A pinned implementer is already decided: show it, don't ask.
-2. **Target branch:** up to four fetched heads, provisional first.
-3. **Merge mode:** `autonomous` (recommended): merge each
+1. **Target branch:** up to four fetched heads, provisional first.
+2. **Merge mode:** `autonomous` (recommended): merge each
    reviewed, green PR, fixing blockers outside the plan
    ([expire.md](expire.md#infrastructure-failures)); or
    `supervised`: hand each back merge-ready.
-4. **Scheduler mode:** how much `next-actions.mjs` prescribes, recorded as
+3. **Scheduler mode:** how much `next-actions.mjs` prescribes, recorded as
    the plan's `schedulerMode`. `full` (recommended): do every step it
    prints. `narrow`: it prints whether the run is done, the units with work,
    and the guards; you choose each unit's step. `off`: it prints only whether
    the run is done; you plan every step. In every mode the run ends only when
    it reports done.
-5. **Plan:**
+4. **Plan:**
    - `ok`/`warn`: proceed or trim.
    - `hold`: file the splits and run them with the rest (recommended when a
      held unit has a split), run the rest, proceed anyway, or trim; offer to
@@ -336,7 +346,7 @@ in one interaction, with the native single-choice tool when there is one:
    grew to 7,544 lines and was closed. Re-cut as two issues, it merged as
    437 and 341 lines.
 
-Record each answer in `decisions`, sync the catalog, then:
+Record each answer in `decisions`, then:
 
 - New target: fetch it, continue the explorer to recheck the findings, rerun
   the size check; ask again only if it worsens to `hold` or `stop`.
@@ -389,7 +399,6 @@ asking nothing at any point:
 |---|---|
 | Ready label | Proceed: show the `missing` issues as a warning on the board and in the handback |
 | Compaction hook | Run without it: warn on the board with the install command |
-| Implementer | The first `options` entry (the pinned one, when pinned) |
 | Target branch | The default branch |
 | Merge mode | `autonomous` |
 | Scheduler mode | `full`, unless the invocation names `scheduler=narrow` or `scheduler=off` |

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

@@ -9,10 +9,20 @@ restate its rules in the brief beyond the two below.
 ## Brief
 
 - Reviewer model: a different id from the implementer's
-  ([preflight.md](preflight.md#1-model-slots)). Take its model id and effort from
-  the plan's recorded reviewer slot, a model or effort the human named included,
-  and pass them as structured launch arguments (the spawn's model and effort
-  fields), never as brief text and never a model id hardcoded here.
+  ([preflight.md](preflight.md#1-model-slots)). Launch the reviewer with the
+  plan's recorded reviewer fill — its `launch`, `instructions`, `selection` and
+  `catalogDigest` ([task-plan.md](task-plan.md#worker-selection-on-resume)) — as
+  structured launch arguments, never as brief text and never a model id
+  hardcoded here. On Pi that `launch` is what the live role resolver receives,
+  `{ role }` unless an explicit task override or this host's own preference
+  asked for a model or effort; never rebuild a pin from a recorded model id. On
+  another host it is the recorded payload, carrying only the controls that host
+  advertised. Check independence from what actually launched, not from the
+  recorded ids: the catalog preflight checks planned independence only, since
+  runtime prepares each launch without knowing the implementer's model. Verify
+  actual launch provenance yourself, on Pi and on other hosts, and block the
+  round if the actual reviewer matches the implementer or its actual identity
+  cannot be established, rather than yielding a review.
 - Context: spec, repository standards, target branch, unit branch and HEAD,
   parent PR when stacked or chained, exploration path, and the contracts the unit
   provides and builds on.
@@ -103,16 +113,18 @@ completed commands and findings, and why the review stopped. Resolve an open
 `executionIncident` first; ask the reviewer to record missing continuation details.
 
 For the same valid HEAD and scope, resume the same reviewer in the same round
-using its result file, review clone and retained context. Give it the unfinished
-work rather than repeating the whole assignment; preserve completed valid passes.
-A wrong HEAD or invalid scope must be corrected, not carried as completed proof.
+using its result file, review clone, recorded launch and retained context. Give it
+the unfinished work rather than repeating the whole assignment; preserve completed
+valid passes. A wrong HEAD or invalid scope must be corrected, not carried as
+completed proof.
 
 If that reviewer cannot continue, state why replacement is necessary, which
 retained evidence the replacement reads, and what it redoes before launching it.
 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. Use the plan's recorded model and effort in
-structured launch arguments as [the brief](#brief) requires.
+history nor counts as progress. Launch the replacement from the same recorded
+reviewer fill, in the same structured launch arguments as [the brief](#brief)
+requires; never invent or re-pick a model id for it.
 
 ## GitHub reviews
 

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

@@ -31,33 +31,101 @@ 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. Write this turn's
+host evidence to a temporary JSON file first (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. `nativeModel` is required for a harness whose slots are launched by a bare host id (Codex); pass the ids the spawn primitive advertises, unchanged. `supportedEfforts` is the host's verified list per model. |
+| `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.
+
+**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

@@ -117,7 +117,7 @@ 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),
@@ -126,6 +126,14 @@ tree that are deliberately not units, each `{issue, reason}`: release or
 approval gates, and rollups the explorer found empty). A run resumed from an
 older wave run keeps `merged` (unit ids merged by earlier runs).
 
+`selections` records each slot's fill as `preflight-models.mjs` returned it —
+`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 +147,32 @@ 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,
+rerun `preflight-models.mjs` for this host ([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 the fills it returns
+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.
+
 ### Standing orders
 
 **`standingOrders` are the run's only constraints.** A numbered list, one