orchestrator-workflow 0.28.0 → 0.30.0

package/assets/skill/SKILL.md

@@ -54,8 +54,8 @@ rule, not its full scope.
 
 Where the harness supports subagent definitions, the explorer, slicer,
 implementer, reviewer, and advisor roles are installed as named subagents
-(Claude Code: `.claude/agents/`, opencode: `.opencode/agents/`) with
-preselected models.
+(Claude Code: `.claude/agents/`, Codex: `.codex/agents/`, opencode:
+`.opencode/agents/`) with preselected models and pinned effort.
 Only the roles this install's profile carries exist as named subagents (see
 `profile` in `.ai/workflow/manifest.json`); run any missing role inline with
 the same contract. Spawn the installed roles instead of improvising role
@@ -134,6 +134,17 @@ directory and the subagents.
    including the run-base marker (see Run state): operator request, goal,
    non-goals, constraints, assumptions, open questions. Write the `.ai/run`
    pointer (see Run state) in every worktree the run touches.
+   For a new run adopting the acceptance contract, record `Acceptance contract:
+   acceptance-baseline/v1` in `00-goal.md` before planning, slicing, or
+   delegation, then freeze its canonical `acceptance_baseline` and
+   `acceptance_criteria` records. Existing runs continue under their recorded
+   original contract; missing v1 fields neither identify a legacy run nor
+   impose a migration. If adoption or contract provenance is unknown, report
+   that uncertainty and resolve it before dependent delegation rather than
+   inventing a version. Communicate the recorded selection in every delegation.
+   All acceptance-baseline/v1-specific obligations below apply only to a run
+   with that explicit declaration; they do not retroactively add a blocker to
+   an existing run.
    If the task can proceed on reasonable assumptions, proceed without blocking.
 2. **Discover (optional, read-only).** When the goal, the solution, or the
    terrain is unclear, send the explorer subagent before planning. Have it
@@ -152,9 +163,10 @@ directory and the subagents.
    rollback considerations where relevant.
 4. **Slice tasks.** For non-trivial changes, fill `02-tasks.md`. Delegate to
    the task-slicer subagent when the change is large enough to benefit. Each
-   task carries: id, title, goal, relevant files, relevant docs, acceptance
-   criteria, constraints, suggested tests, allowed changes, forbidden
-   changes, dependencies, risk. A high-risk task whose acceptance criteria
+   explicitly adopted v1 task carries: id, title, goal, acceptance baseline, acceptance criteria,
+   relevant files, relevant docs, constraints, suggested tests, allowed changes, forbidden
+   changes, dependencies, risk. Apply Contract selection below for a recorded
+   original contract. A high-risk task whose acceptance criteria
    allow recording the divergence instead of changing behavior, so its
    outcome is undetermined at slice time (for example, phrased along the
    lines of "... or record the divergence as a deliberate, documented
@@ -163,9 +175,20 @@ directory and the subagents.
    shipping should not wait on it. Under a `minimal` profile there is no
    task-slicer subagent to delegate to; slice the tasks inline yourself with
    the same contract.
+   For every identifier, config value, build context, or documented command
+   the task will change, enumerate every file and doc site that references it
+   in `relevant_files` or `relevant_docs`, with an annotation for a site the
+   task will not edit.
 5. **Validate tasks.** Check the slices are independently understandable, small
    enough, testable, ordered correctly, and aligned with the goal. Fix the
-   slicing before any implementation starts.
+   slicing before any implementation starts. For an explicitly adopted v1 run,
+   freeze the acceptance baseline in
+   `00-goal.md`: its canonical `acceptance_baseline: { id, revision }` and each
+   `acceptance_criteria` record with stable ID, required status, exact text,
+   verification definition, and negative space. For an explicitly adopted v1
+   run, copy the relevant records unchanged into each `02-tasks.md` task
+   contract; the sliced task contract is a lossless superset, not an
+   opportunity to revise the criteria.
 6. **Delegate implementation.** Send each implementer subagent one narrow task
    contract (format below). The unsuffixed implementer carries a pinned
    effort: `medium` in its own file, whether or not tier variants are
@@ -188,8 +211,40 @@ directory and the subagents.
    for real, observe the named test fail, restore, re-verify). Hold the
    implementer's report to the claim-only-what-was-measured rule too: treat any
    verification claim there that is not backed by a check it actually ran as
-   unverified. Record meaningful decisions in `03-decisions.md` and consolidate
-   evidence in `04-implementation-summary.md`.
+   unverified. On any round after the task's first, the briefing also names
+   every mutation probe named in an earlier round of this task (on the
+   task's first round there are none), drawn from the run's
+   `04-implementation-summary.md`; the implementer replays each one, not
+   only the round's new probes, before the next reviewer spawn, and
+   reports each in `mutation_probes` with the four evidence fields plus
+   `replayed: true`. A replayed probe whose mutant now survives or can no
+   longer be applied is a regression signal, reported as such (`result`
+   `survived` or `not_applicable` with the reason) and resolved before the
+   next reviewer spawn. Record meaningful decisions in
+   `03-decisions.md` and consolidate evidence in
+   `04-implementation-summary.md`, recording each probe the implementer
+   reports as a row in `04-implementation-summary.md`'s Mutation Probes
+   subsection, with the round it was named in. For any diff that adds or
+   changes a GitHub Actions `run:` step, the installed `implementer.md`
+   prompt requires replaying it locally under the shell the step actually
+   runs, with the expected-success and the expected-failure inputs, before
+   treating it as tested.
+   For an explicitly adopted v1 run, index the implementer's returned
+   `criterion_evidence` references for each assigned criterion in the
+   implementation summary against its baseline ID/revision. Empty references
+   remain unresolved with a reason; required unresolved criteria block
+   acceptance. Automated results
+   identify attempt, repository, checked revision including relevant dirty
+   state, cwd, applied check definition, status, exit/abort information, and
+   baseline/criterion identities. Manual results identify the artifact revision, reviewer,
+   method, pass/fail standard, reasoned result, and baseline/criterion
+   identities and remain explicitly
+   manual. Missing, aborted, skipped, unresolved, wrong-state, or
+   wrong-baseline evidence remains an open required residual and blocks
+   acceptance; the coverage index is not a results database or acceptance
+   engine. Only the orchestrator can explicitly revise a baseline, recording
+   old/new revisions, affected IDs, authority and reason, invalidated evidence,
+   and verified rationale for carrying unchanged evidence forward.
 7. **Delegate review.** Send the diff to the reviewer subagent, naming in the
    briefing the base and head revision the diff was generated from. When tier
    variants are installed, pick the reviewer tier (the installed
@@ -218,19 +273,45 @@ directory and the subagents.
    implementer's log — and record the method, sample size, and result against
    the implementer's claim in the reviewer output contract's `reproduction`
    field. This does not apply to deterministic checks (a single test run,
-   `tsc`, lint): only claims that could vary run to run trigger it. When
-   this is not the task's first review round, name the round number in the
-   briefing; the reviewer marks each finding's `recurrence` as `new` or
-   `repeated` against the earlier rounds it was told about, which is what
-   lets the orchestrator detect the Review-round escalation budget's
-   trigger (see below) without re-deriving it by hand.
+   `tsc`, lint): only claims that could vary run to run trigger it. The
+   GitHub Actions shell replay named in step 6 is a second, explicitly
+   non-probabilistic trigger for the same field, with `sample_size:
+   not_applicable` allowed when the replay itself has no meaningful sample
+   size. A change that deletes or renames an exported identifier, type, config
+   key, or file is also checked for identifier drift (docs or comments still
+   describing the old name as current), by the reviewer or by the orchestrator
+   itself when it reviews a trivial rename per Scaling delegation, using a
+   connected drift check when one exists. When this is not the task's first
+   review round, name the round
+   number in the briefing; the reviewer marks each finding's `recurrence` as
+   `new` or `repeated` against the earlier rounds it was told about, which is
+   what lets the orchestrator detect the Review-round escalation budget's
+   trigger (see below) without re-deriving it by hand. When the implementer's
+   report replays a prior round's mutation probe, the orchestrator's reviewer
+   briefing names the replayed probes the implementer reports as killed
+   together with their `mutant` and `verified_applied_via` values; the reviewer
+   may then skip re-running those. The reviewer output contract itself is
+   unchanged. For an explicitly adopted v1 run, ask the reviewer to compare the frozen delegated criteria with
+   the referenced evidence and judge semantic adequacy, including whether a
+   manual check is actually concrete and reasoned.
 8. **Decide acceptance.** Accept, request fixes, defer, or escalate to the
    operator. High or critical findings block acceptance until fixed or
    explicitly waived: critical findings require operator sign-off; high
    findings require the orchestrator to record a rationale. Deferring a high
    or critical finding counts as a waiver and follows the same rules. Record
    all decisions and waivers in `03-decisions.md` and summarize waivers in
-   the Accepted Waivers section of `06-handoff.md`. Watch for the round-2
+   the Accepted Waivers section of `06-handoff.md`. A reviewer recommendation is not orchestrator acceptance and cannot authorize a critical waiver; only the operator may authorize a critical waiver. For newly created decision records, identify a stable ID, trigger/evidence, decision, accountable authority/source with concrete approval evidence, consequences, and a superseded decision ID when revising a prior decision. Link baseline revisions and waivers to those decision IDs. Established runs retain their recorded decision format; absent fields never create a retroactive blocker. Routine decisions within the delegated contract remain the orchestrator's responsibility; an out-of-scope change requires an operator decision. Markdown records evidence of real authority and never grant it by themselves. Do not accept while a
+   required baseline criterion in an explicitly adopted v1 run has an open residual; a residual retains its ID
+   and cannot be converted away. After independent review,
+   the orchestrator may close a docs-only delta without another reviewer round only
+   when the entire unreviewed delta contains only explanatory
+   documentation, comments, or citations; contains no source- or test-file
+   edits and no semantic change to executable commands, configuration,
+   policy, instructions, or behavior; and closes only low/medium
+   documentation or maintainability findings. This option never closes a
+   high/critical or other ineligible finding. Record the concrete verification
+   in a `05-review-findings.md` row, keeping its Severity and Decision headers
+   unchanged and setting Decision to `accepted`. Watch for the round-2
    halt signal across repeated review-fix cycles (see Round-2 halt rule
    below). By the second round-2 halt signal or the third `fix_required`
    review round on the same task, apply the Review-round escalation budget
@@ -290,19 +371,41 @@ open_questions:
 recommendation: ""
 ```
 
+## Contract selection
+
+Contract selection: use `acceptance-baseline/v1` only when the orchestrator
+recorded `Acceptance contract: acceptance-baseline/v1` in `00-goal.md` at run
+creation, before slicing, and communicated that selection in the delegation.
+Existing runs use their recorded original contract. Unknown provenance is
+reported and resolved before dependent delegation; missing fields never select
+a version. For a recorded original string-list contract, retain the original
+`acceptance_criteria` strings and omit only the introduced `acceptance_baseline`
+and `criterion_evidence` fields; keep all existing role output fields. This
+selection governs the rules and every YAML block below.
+
 ## Subagent input contract
 
+Use this v1 block subject to Contract selection above, retaining the complete
+input envelope and scope fields for the selected contract.
+
 ```yaml
 role: advisor | explorer | implementer | reviewer | task_slicer
 task_id: T-000
 goal: ""
+acceptance_baseline:
+  id: ""
+  revision: ""
+acceptance_criteria:
+  - id: ""
+    required: true
+    text: ""
+    verification: ""
+    negative_space: ""
 context:
   relevant_files: []
   relevant_docs: []
 constraints:
   - ""
-acceptance_criteria:
-  - ""
 allowed_changes:
   - ""
 forbidden_changes:
@@ -313,10 +416,19 @@ expected_output:
 
 ## Implementer output contract
 
+Use this v1 block subject to Contract selection above.
+
 ```yaml
 status: done | partial | blocked
 role: implementer
 task_id: T-000
+acceptance_baseline:
+  id: ""
+  revision: ""
+criterion_evidence:
+  - criterion_id: ""
+    evidence_refs:
+      - ""
 summary:
   - ""
 changed_files:
@@ -333,6 +445,7 @@ mutation_probes:
     verified_applied_via: ""
     result: ""
     restored_verified: ""
+    replayed: false | true
 risks:
   - severity: low | medium | high
     description: ""
@@ -343,12 +456,32 @@ commits:
   - ""
 ```
 
+For v1, return the delegated baseline identity and one `criterion_evidence`
+entry for every assigned criterion. Each `evidence_refs` string resolves
+relative to the directory containing the owning `04-implementation-summary.md`
+and includes a precise artifact or fragment locator when needed. Empty
+`evidence_refs: []` means unresolved; explain why in `risks` or `open_questions`.
+These fields index producer artifacts, without copying their result metadata.
+An automated artifact identifies its attempt, repository, checked revision
+including relevant dirty-state identity, cwd, applied check definition, status,
+exit or abort information, and baseline/criterion identities. A manual artifact
+identifies the reviewed artifact and revision, reviewer, method, pass/fail
+standard, reasoned result, and baseline/criterion identities; it stays manual.
+
 When the task assignment names mutation probes to run, the implementer
 reports each one in the `mutation_probes` field (mutant,
 verified_applied_via, result, restored_verified); when the assignment
 names none, it returns `mutation_probes: []` rather than omitting the
 field, so 'none asked for' is distinguishable from 'asked for and not
-reported'.
+reported'. Each item also carries `replayed`: `false` for a probe newly
+introduced this round, `true` for a prior round's probe replayed this
+round under the replay rule in step 6. On any round after the task's
+first, the implementer replays every probe named in an earlier round of
+this task (on the task's first round there are none), not only this
+round's new probes, before the next reviewer spawn, reporting each one in
+`mutation_probes` alongside the round's new probes. A replayed probe
+whose mutant now survives or can no longer be applied is a regression
+signal, reported as such and resolved before the next reviewer spawn.
 
 The `commits` field lists the full sha of every commit the implementer
 produced on the task branch, in the order produced; when the task
@@ -358,6 +491,10 @@ omitting the field, so 'did not commit' is distinguishable from
 
 ## Reviewer output contract
 
+The output shape remains the same for either selected contract. Compare the
+delegated versioned records and producer evidence under Contract selection
+above; a recommendation does not replace orchestrator acceptance.
+
 ```yaml
 status: reviewed
 role: reviewer
@@ -394,6 +531,8 @@ Review-round escalation budget's trigger.
 
 ## Task slicer output contract
 
+Use this v1 block subject to Contract selection above for every task.
+
 ```yaml
 status: done | partial | blocked
 role: task_slicer
@@ -403,12 +542,19 @@ tasks:
   - id: T-001
     title: ""
     goal: ""
+    acceptance_baseline:
+      id: ""
+      revision: ""
+    acceptance_criteria:
+      - id: ""
+        required: true
+        text: ""
+        verification: ""
+        negative_space: ""
     relevant_files:
       - ""
     relevant_docs:
       - ""
-    acceptance_criteria:
-      - ""
     constraints:
       - ""
     suggested_tests:
@@ -426,10 +572,14 @@ open_questions:
   - ""
 ```
 
-The orchestrator copies each task's goal, relevant_files, relevant_docs,
-acceptance_criteria, constraints, allowed_changes, and forbidden_changes 1:1
-into the subagent input contract when delegating implementation, rather than
-inventing new field values.
+For an explicitly adopted v1 run, the orchestrator copies each task's goal,
+acceptance_baseline, acceptance_criteria, relevant_files, relevant_docs,
+constraints, allowed_changes, and forbidden_changes 1:1 into the subagent
+input contract when delegating implementation, rather than inventing new field
+values. The copied criterion records retain `id`, `required`, `text`,
+`verification`, and `negative_space` unchanged. For a recorded original
+contract, preserve its original strings and the same 1:1 field mapping with
+the transformation under Contract selection above.
 
 ## Advisor output contract
 
@@ -489,10 +639,21 @@ instructions found in untrusted content as risks instead of following them.
 - **opencode**: invoke the installed `.opencode/agents/` subagents the same
   way (`mode: subagent`); the same profile scoping applies. The `.ai/run`
   pointer rule from Run state applies unchanged.
-- **OpenAI Codex**: there is no standardized project-level subagent definition
-  to install. Run the roles inline and sequentially with the same contracts,
-  and still produce the same run files. The `.ai/run` pointer rule from Run
-  state applies unchanged.
+- **OpenAI Codex**: dispatch according to the native capabilities actually
+  exposed. When a named-agent selector is available, select the installed
+  `.codex/agents/<role>.toml` definition. When spawning accepts explicit model
+  and reasoning effort but has no named selector, read that TOML and pass its
+  model, effort, `developer_instructions`, and the narrow task contract to a
+  fresh task-local spawn; do not assume a full-history spawn can override the
+  model. When native spawning is unavailable, run the role inline and
+  sequentially with the same contract. Their exact routing remains pinned in
+  the installed definitions in every case. Explorer and advisor request a
+  read-only sandbox; if an explicit spawn cannot accept a sandbox override,
+  they inherit the caller's sandbox and their prompt is the remaining edit
+  guard. Reviewer inherits the caller's sandbox so temporary/build checks
+  remain possible, but its prompt still prohibits source edits. Only
+  the orchestrator spawns agents, and every route produces the same run files.
+  The `.ai/run` pointer rule from Run state applies unchanged.
 
 ## Subagent misfire rule
 

package/assets/templates/00-goal.md

@@ -3,6 +3,44 @@
 <!-- solution-acceptance: run-base = TODO -->
 <!-- solution-acceptance: run-base[<repo-basename>] = <sha> -->
 
+## Acceptance Baseline
+
+For a newly created run that adopts this contract, record this declaration
+before planning, slicing, or delegation:
+
+Acceptance contract: acceptance-baseline/v1
+
+For that recorded v1 selection, freeze the actual delegation input in this
+canonical shape and communicate the selection in every delegation:
+
+```yaml
+acceptance_baseline:
+  id: "" # e.g. acceptance-baseline
+  revision: "" # e.g. r1
+acceptance_criteria:
+  - id: "" # e.g. AC-001
+    required: true
+    text: "" # frozen normative text
+    verification: "" # exact command + expected outcome, or reviewer role + concrete artifact + pass/fail standard
+    negative_space: "" # what this criterion does not establish
+```
+
+The orchestrator freezes these records before delegation. An implementer must
+not change a criterion or its normative verification command. A baseline
+revision records the old and new revisions, affected IDs, decision authority
+and reason, invalidated evidence, and any verified rationale for carrying
+unchanged evidence forward. Scope changes beyond the request need an operator
+decision; invalidated evidence is rerun before acceptance.
+
+This contract applies only to runs that explicitly record the declaration
+above. Existing runs continue under their recorded original contract: missing
+v1 fields neither identify a legacy run nor block it, and uncertain adoption
+or provenance is reported and resolved before dependent delegation rather
+than inferred. For a recorded original string-list contract, retain the
+original `acceptance_criteria` strings and omit the introduced
+`acceptance_baseline` and `criterion_evidence` fields. Keep the existing role
+output fields; do not rewrite an old run to adopt this block.
+
 ## Operator Request
 
 <!-- Original user/operator request. -->

package/assets/templates/02-tasks.md

@@ -1,9 +1,36 @@
 # Tasks
 
+## Delegated Acceptance Baseline
+
+For a run that explicitly adopted `acceptance-baseline/v1`, each task carries
+the relevant frozen records in its own contract. Copy these canonical fields
+from `00-goal.md` unchanged; the task list is a lossless superset, not a
+second place to revise criteria. This selection must have been recorded in
+`00-goal.md` at run creation before slicing and communicated in delegation.
+Existing runs keep their recorded original contract: retain original
+`acceptance_criteria` strings and omit the introduced `acceptance_baseline`
+and `criterion_evidence` fields, keeping existing role output fields. Unknown
+provenance is resolved before dependent delegation; missing fields never
+select a version. The YAML block below is the v1 shape under this selection.
+
 ## Task List
 
 ### T-001: <!-- Title -->
 
+**Delegated Acceptance Contract**
+
+```yaml
+acceptance_baseline:
+  id: "" # copied unchanged from 00-goal.md
+  revision: "" # copied unchanged from 00-goal.md
+acceptance_criteria:
+  - id: "" # copied unchanged
+    required: true # copied unchanged
+    text: "" # copied unchanged
+    verification: "" # copied unchanged
+    negative_space: "" # copied unchanged
+```
+
 **Goal**
 
 <!-- What this task should achieve. -->
@@ -18,7 +45,11 @@
 
 **Acceptance Criteria**
 
-- [ ] <!-- criterion -->
+For v1 this is non-normative tracking keyed to the frozen criterion IDs in
+the delegated block above; do not rewrite criterion text here. For a recorded
+original contract, keep the original checklist semantics.
+
+- [ ] <!-- frozen criterion ID (v1), or original criterion (original contract) -->
 
 **Constraints**
 

package/assets/templates/03-decisions.md

@@ -1,8 +1,15 @@
 # Decisions
 
-| Date | Decision | Reason | Consequences |
-|---|---|---|---|
-| YYYY-MM-DD | <!-- decision --> | <!-- reason --> | <!-- consequences --> |
+<!-- For newly created decision records, this table is descriptive evidence, not an authorization mechanism. Record the real accountable source and its concrete approval evidence; a role label or this Markdown alone does not grant authority. Established runs retain their recorded decision format. -->
+
+| ID | Date | Trigger / Evidence | Decision | Authority / Source | Consequences | Supersedes |
+|---|---|---|---|---|---|---|
+| D-001 | YYYY-MM-DD | <!-- trigger and evidence --> | <!-- decision --> | <!-- accountable source and approval evidence --> | <!-- consequences --> | <!-- prior D-ID, or blank for first decision --> |
+
+<!-- Baseline revisions and accepted waivers link to their D-ID. A revision's
+Supersedes cell names the prior decision it replaces. Routine in-scope
+orchestrator decisions, operator-approved scope changes, and operator-only
+critical waivers remain distinct. -->
 
 ## Review-round escalation
 

package/assets/templates/04-implementation-summary.md

@@ -14,6 +14,44 @@ not_started | in_progress | done | partial | blocked
 |---|---|
 | <!-- path --> | <!-- reason --> |
 
+## Acceptance-Baseline Coverage
+
+The Acceptance-Baseline Coverage and Open Required Residuals sections apply
+only to a run that recorded `Acceptance contract: acceptance-baseline/v1` in
+`00-goal.md` at creation before slicing. Existing runs retain their recorded
+original summary contract. Unknown provenance is resolved before dependent
+delegation; missing fields never select a version or require migration.
+
+This table indexes the implementer's returned `criterion_evidence` references
+against the frozen `acceptance_baseline` and assigned criteria. Empty
+`evidence_refs: []` stays unresolved, with its reason in risks/open questions.
+This table indexes result artifacts; it is not a results database and does not
+itself accept work. A required criterion with missing, aborted, skipped,
+unresolved, wrong-state, or wrong-baseline evidence remains an open residual
+and blocks acceptance.
+
+| Criterion ID | Baseline ID / revision | Evidence reference | Result |
+|---|---|---|---|
+| <!-- AC-001 --> | <!-- acceptance-baseline / r1 --> | <!-- relative result artifact reference --> | <!-- pass/fail/manual/residual --> |
+
+An automated result artifact identifies its attempt, repository, checked
+revision including relevant dirty-state identity, cwd, applied check definition,
+status, exit or abort information, and baseline/criterion identities. A manual reference
+identifies the artifact revision, reviewer, method, pass/fail standard, and
+reasoned result and baseline/criterion identities; it remains explicitly manual. Coverage never turns a reviewer
+recommendation or accepted risk into automated verification.
+
+Each reference resolves relative to the directory containing this summary
+file, with a precise artifact or fragment locator when needed. It must identify the
+same baseline and criterion as the frozen delegated record; a copied label or
+an optional row cannot stand in for a required criterion.
+
+## Open Required Residuals
+
+| Criterion ID | Why evidence is not decisive | Acceptance effect |
+|---|---|---|
+| <!-- AC-001 --> | <!-- missing/aborted/skipped/unresolved/wrong state or baseline --> | blocks acceptance |
+
 ## Test Evidence
 
 ### Executed
@@ -28,6 +66,12 @@ not_started | in_progress | done | partial | blocked
 
 <!-- Explain why, if applicable. -->
 
+### Mutation Probes
+
+| Round | Mutant | Verified Applied Via | Result | Restored Verified | Replayed |
+|---|---|---|---|---|---|
+| <!-- round --> | <!-- mutant --> | <!-- verified_applied_via --> | <!-- result --> | <!-- restored_verified --> | <!-- replayed --> |
+
 ## Risks / Notes
 
 - <!-- note -->

package/dist/cli-apply.d.ts

@@ -1,6 +1,7 @@
 import type { ResolveInitInputsParams } from "./cli-inputs.js";
 import type { Harness } from "./detect.js";
 import type { Manifest } from "./init.js";
+import type { HarnessRouting } from "./routing.js";
 /** The subset of `apply`'s commander options that feed input resolution. */
 export interface ApplyResolutionOptions {
     harness?: string;
@@ -8,6 +9,7 @@ export interface ApplyResolutionOptions {
     profile?: string;
     opencodeProvider?: string;
     tiers?: boolean;
+    routing?: HarnessRouting;
 }
 /**
  * Builds `apply`'s own `resolveInitInputs` params, pinning the sticky-branch

package/dist/cli-inputs.d.ts

@@ -1,6 +1,8 @@
 import type { Harness } from "./detect.js";
 import type { Manifest } from "./init.js";
-import type { ModelClass, Profile, Role } from "./models.js";
+import type { Profile, Role } from "./models.js";
+import type { OpencodeModelMaps } from "./routing-state.js";
+import type { HarnessRouting } from "./routing.js";
 export declare function promptHarnesses(detected: Harness[], installed: Harness[], fallbackToClaude?: boolean, annotateDetected?: Harness[]): Promise<Harness[]>;
 export declare function promptProfile(base: Profile): Promise<Profile>;
 export declare function promptModels(base: Record<Role, string>, roles: Role[]): Promise<Record<Role, string>>;
@@ -11,6 +13,7 @@ export interface InitResolutionOptions {
     profile?: string;
     opencodeProvider?: string;
     tiers?: boolean;
+    routing?: HarnessRouting;
 }
 export interface ResolveInitInputsParams {
     /** Result of `detectHarnesses(targetDir)`; passed in so the caller can
@@ -52,15 +55,14 @@ export interface ResolveInitInputsParams {
      * The entries pre-checked in the interactive prompt when the target
      * recorded `harnesses: []` (the harnesses-stickiness gate's branch,
      * gated on `previousIsRecordedManifest && previous.
-     * harnessesRecordedEmpty`). Defaults to `[]` when omitted: `init` and
-     * `apply` share this semantics (D-002, agent-dx 7669907c). A fresh
+     * harnessesRecordedEmpty`). Defaults to `[]` when omitted, so `init` and
+     * `apply` share this semantics. A fresh
      * interactive re-run on a templates-only target starts with nothing
      * pre-checked, because the recorded `harnesses: []` is the intent that
      * matters, not a `.claude/`-style directory the harness itself left on
      * disk, which is a weak signal and must not re-widen a deliberate
-     * `--harness none` install just because a bare Enter is pressed
-     * (agent-tasks fe834823; the same argument applies identically to
-     * `init`). `apply`'s call site still passes `[]` explicitly, as defence
+     * `--harness none` install just because a bare Enter is pressed. `apply`'s
+     * call site still passes `[]` explicitly, as defence
      * in depth (see `buildApplyInitInputs`'s doc comment). Only the sticky
      * branch reads this field; the normal (non-recorded-empty) branch still
      * prompts from `detected` unchanged, matching `apply`'s existing
@@ -75,7 +77,7 @@ export interface ResolveInitInputsParams {
      * `stickyPreChecked`'s doc comment), the operator still sees which
      * harness is actually on disk, because labelling is a hint, not an
      * intent signal, so it is safe to annotate what the pre-check itself
-     * must not read (agent-tasks fe834823, fix round 3). `init`'s call site
+     * must not read. `init`'s call site
      * omits this field and gets its own `detectHarnesses(targetDir)` result
      * via this default; `apply`'s call site passes a fresh
      * `detectHarnesses(targetDir)` call explicitly, since its own
@@ -85,13 +87,12 @@ export interface ResolveInitInputsParams {
      */
     stickyAnnotateDetected?: Harness[];
 }
-export interface ResolvedInitInputs {
+export interface ResolvedInitInputs extends OpencodeModelMaps {
     harnesses: Harness[];
     profile: Profile;
     models: Record<Role, string>;
     tiers: boolean;
-    opencodeModels?: Record<Role, string | undefined>;
-    opencodeClassModels?: Record<ModelClass, string | undefined>;
+    routing: HarnessRouting;
     /**
      * Warning lines to print, in order, exactly as `init` printed them to
      * stderr before this extraction (each written as `${line}\n`). Returned
@@ -112,12 +113,7 @@ export interface ResolvedInitInputs {
  * omitted) keeps the previously installed value; a fresh install with no
  * prior manifest falls back to the shipped default.
  *
- * `params.detected` is the fallback-chain input the non-sticky "else"
- * branch below prompts and falls back from. It plays no role in the
- * harnesses-stickiness branch's own pre-check any more: that branch
- * always pre-checks `stickyPreChecked ?? []` (D-002, agent-dx 7669907c),
- * never `detected`, so `init` and `apply` share one semantics there. It
- * still feeds that branch's " (detected)" label by default (see
- * `ResolveInitInputsParams.stickyAnnotateDetected`'s doc comment).
+ * `params.detected` is the non-sticky fallback-chain input; see
+ * `ResolveInitInputsParams.stickyPreChecked` for the sticky rule.
  */
 export declare function resolveInitInputs(params: ResolveInitInputsParams): Promise<ResolvedInitInputs>;