orchestrator-workflow 0.27.0 → 0.28.0

package/CHANGELOG.md

@@ -7,6 +7,37 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.28.0] - 2026-09-04
+
+### Added
+
+- The explorer, reviewer, and implementer prompts, and `SKILL.md`'s
+  Discover step, each gained one tool-agnostic sentence pointing the role
+  at a connected structural code-search, verify, or mutation-probe runner
+  when one is available in the session, in place of raw grep, hand-editing
+  probe files, or reading full logs. Anchored by a pandora-workspace
+  measurement of subagent tool-call patterns (see run
+  `.ai/runs/2026-09-03-agent-tools-kit`).
+
+### Changed
+
+- `init`'s interactive harnesses prompt on a target whose own manifest
+  recorded a real `harnesses: []` (a deliberate `--harness none`
+  templates-only install) now starts with nothing pre-checked, matching
+  `apply`'s existing semantics, instead of pre-checking whatever
+  `detectHarnesses(targetDir)` found on disk. Decision D-002 (agent-dx
+  7669907c): the weak-signal argument that motivated `apply`'s own fix
+  (agent-tasks fe834823, a stray harness config left on disk, e.g. a
+  `.claude/` directory, is not the recorded intent, the manifest is)
+  applies to `init` identically, and the earlier fix's concern (ask
+  instead of silently falling back to templates-only) is preserved
+  because the prompt still appears and still annotates detection with a
+  " (detected)" label; only the pre-check now follows recorded intent
+  instead of on-disk detection. `init` and `apply` now share one
+  resolution inside `resolveInitInputs` (`stickyPreChecked ?? []`,
+  `stickyAnnotateDetected ?? detected`) instead of `init`'s own call site
+  relying on a different default.
+
 ## [0.27.0] - 2026-09-01
 
 ### Added

package/README.md

@@ -89,9 +89,10 @@ files on disk from something else; add a harness back with an explicit
 `--profile`/`--models`/`--tiers` use, applied to the no-harness case. An
 **interactive** re-run is different: it still prompts, with nothing forced
 pre-selected, instead of silently skipping straight back to templates-only
-without asking; deselect every checkbox to stay templates-only. `init`
-pre-checks whatever it detects on disk; `apply` pre-checks nothing at all
-(both still annotate what is detected with a " (detected)" label).
+without asking; deselect every checkbox to stay templates-only. `init` and
+`apply` both pre-check nothing at all on this prompt, and both still
+annotate what is detected on disk with a " (detected)" label; select a
+harness to install it.
 
 ```bash
 npx orchestrator-workflow init --harness none --yes
@@ -399,12 +400,9 @@ what `init` would have auto-detected) -- except a target whose own
 manifest recorded a real `harnesses: []` (a deliberate templates-only
 install, see "Templates-only mode" above), which stays templates-only on
 a flagless run regardless of the operator's defaults or what is on disk;
-an **interactive** re-run on such a target still prompts, but with
-nothing pre-checked at all -- neither whatever `apply`'s harness fallback
-(recorded harnesses, else operator defaults, else detection) would
-otherwise have picked, nor a harness config left on disk from something
-else, which is a weak signal next to the target's own recorded
-`harnesses: []`.
+an **interactive** re-run on such a target still prompts, with the same
+nothing-pre-checked behaviour described in "Templates-only mode" above
+(it applies identically to `apply`).
 Pass `--sync` to invert that for
 profile, tiers, and models: the operator's defaults then win over whatever
 the target already had recorded. A target pinned to a kit version other
@@ -504,3 +502,11 @@ organizational guidance (when to use agents at all, review depth, risk tiers)
 live in the sibling package
 [agentic-coding-playbook](../agentic-coding-playbook), which the skill
 references.
+
+## okf-kit version pin
+
+`test/docs-consistency.test.ts` pins the `okf-kit@<version>` this repo's own
+`.github/workflows/` install against the sibling `packages/okf-kit`
+package's version, so a release of `okf-kit` must bump those pins in the
+same commit as the version cut; see `CONTRIBUTING.md`'s "Releasing okf-kit"
+section (repo root) for the order.

package/assets/agents/explorer.md

@@ -16,10 +16,11 @@ Rules:
   repository; follow the question.
 - Before mapping terrain by hand, check whether the repo carries a curated
   knowledge bundle (for example a `docs/okf/` directory with an `index.md`):
-  if one exists, read its index first and then the relevant docs it points
-  to, treating their claims as leads to verify, not as ground truth. If a semantic
+  if one exists, read its index first and then the relevant docs it points to,
+  treating their claims as leads to verify, not as ground truth. If a semantic
   code-search tool is connected in the session, prefer it over raw grep for
-  orientation questions.
+  orientation questions; when a structural code-search tool is available,
+  prefer it over text grep for symbol lookups (callers, definitions).
 - Report what you actually found, with `file:line` references. Distinguish
   verified facts from inference, and never present a guess as a fact.
 - Surface the constraints and conventions a plan must respect (existing

package/assets/agents/implementer.md

@@ -19,6 +19,10 @@ Rules:
   field when probes were named is treated as a misfire, not evidence. When
   the assignment names no mutation probes, return `mutation_probes: []`
   rather than omitting the field.
+- When a verify runner is available, run it for the checks the acceptance
+  criteria name and report its summary under `tests.executed`; when a
+  mutation-probe runner is available, run the named probes through it and
+  copy its fields into `mutation_probes`.
 - Report the full sha of every commit you produced on the task branch, in
   order, in the `commits` field of your output; an output missing that field
   when the task assignment asked for a commit is treated as a misfire, not

package/assets/agents/reviewer.md

@@ -64,6 +64,10 @@ Rules:
   implementer's log — and record the method, sample size, and result against
   the implementer's claim in the `reproduction` field. Deterministic checks
   (a single test run, `tsc`, lint) do not trigger this.
+- When a mutation-probe runner is available in the session, run probes
+  through it instead of editing files by hand, and carry its result fields
+  into your findings and `reproduction`; when a verify runner is available,
+  read its summary before opening full logs.
 
 Return exactly this structure as your final output, nothing else:
 

package/assets/skill/SKILL.md

@@ -140,9 +140,10 @@ directory and the subagents.
    check for a curated knowledge bundle (for example a `docs/okf/` directory
    with an index) before mapping terrain by hand, treating any claims found
    there as leads to verify, not as ground truth, and prefer a connected
-   semantic code-search tool over raw grep for orientation questions. Fold its
-   findings into a
-   "Terrain" section of `01-plan.md`. Skip this step when the change is well
+   semantic code-search tool over raw grep for orientation questions; when a
+   structural code-search tool is available, prefer it over text grep for
+   symbol lookups (callers, definitions). Fold its findings into a "Terrain"
+   section of `01-plan.md`. Skip this step when the change is well
    understood. If the explorer surfaces a question only the operator can
    answer, ask the operator instead of guessing. Under a `minimal` profile
    there is no explorer subagent to send; run this step inline with the same

package/dist/cli-init.d.ts

@@ -0,0 +1,20 @@
+import type { Harness } from "./detect.js";
+import type { Manifest } from "./init.js";
+import type { InitResolutionOptions, ResolveInitInputsParams } from "./cli-inputs.js";
+/**
+ * Builds `init`'s own `resolveInitInputs` params. Mirrors
+ * `buildApplyInitInputs` (`cli-apply.ts`): kept in its own side-effect-free
+ * module, rather than inline in `cli.ts`'s action, so a future edit to the
+ * call site cannot silently reintroduce a `stickyPreChecked` (or
+ * `stickyAnnotateDetected`) override without a targeted test catching it.
+ * `init`'s call site never overrides either field: the sticky branch must
+ * fall back to `resolveInitInputs`'s own `stickyPreChecked ?? []` and
+ * `stickyAnnotateDetected ?? detected` defaults (D-002, agent-dx 7669907c;
+ * see `ResolveInitInputsParams.stickyPreChecked`'s doc comment for why),
+ * exactly as `apply` does via its own hardcoded `[]`. Unlike
+ * `buildApplyInitInputs`, this builder does not set those two fields at
+ * all, since `init` has no analogue of `apply`'s already-resolved
+ * `chosenHarnesses` to guard against; omitting them is what lets
+ * `resolveInitInputs`'s defaults do the pinning.
+ */
+export declare function buildInitInitInputs(detected: Harness[], previous: Manifest | undefined, interactive: boolean, opts: InitResolutionOptions): ResolveInitInputsParams;

package/dist/cli-init.js

@@ -0,0 +1,29 @@
+/**
+ * Builds `init`'s own `resolveInitInputs` params. Mirrors
+ * `buildApplyInitInputs` (`cli-apply.ts`): kept in its own side-effect-free
+ * module, rather than inline in `cli.ts`'s action, so a future edit to the
+ * call site cannot silently reintroduce a `stickyPreChecked` (or
+ * `stickyAnnotateDetected`) override without a targeted test catching it.
+ * `init`'s call site never overrides either field: the sticky branch must
+ * fall back to `resolveInitInputs`'s own `stickyPreChecked ?? []` and
+ * `stickyAnnotateDetected ?? detected` defaults (D-002, agent-dx 7669907c;
+ * see `ResolveInitInputsParams.stickyPreChecked`'s doc comment for why),
+ * exactly as `apply` does via its own hardcoded `[]`. Unlike
+ * `buildApplyInitInputs`, this builder does not set those two fields at
+ * all, since `init` has no analogue of `apply`'s already-resolved
+ * `chosenHarnesses` to guard against; omitting them is what lets
+ * `resolveInitInputs`'s defaults do the pinning.
+ */
+export function buildInitInitInputs(detected, previous, interactive, opts) {
+    return {
+        detected,
+        interactive,
+        previous,
+        opts,
+        // `previous` here is `readInstalledManifest(targetDir)` (undefined, or
+        // the target's own actually-recorded manifest), unlike `apply`'s
+        // synthetic operator-defaults "floor" object: an empty harnesses array
+        // is a real recorded `--harness none` install here.
+        previousIsRecordedManifest: true,
+    };
+}

package/dist/cli-inputs.d.ts

@@ -52,34 +52,36 @@ 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 `detected` when omitted, which
-     * is `init`'s own call site's behaviour (it does not pass this field at
-     * all): a fresh interactive re-run on a templates-only `init` target
-     * still pre-checks whatever `detectHarnesses(targetDir)` finds on disk,
-     * unchanged from before this field existed. `apply`'s call site passes
-     * `[]` instead: the operator's 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). Only the sticky branch reads this
-     * field; the normal (non-recorded-empty) branch still prompts from
-     * `detected` unchanged, matching `apply`'s existing pre-check behaviour
-     * on a normal target.
+     * harnessesRecordedEmpty`). Defaults to `[]` when omitted: `init` and
+     * `apply` share this semantics (D-002, agent-dx 7669907c). 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
+     * 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
+     * pre-check behaviour on a normal target.
      */
     stickyPreChecked?: Harness[];
     /**
      * The sticky branch's own `promptHarnesses` " (detected)" label source,
      * independent of `stickyPreChecked` (which drives what is actually
-     * pre-checked, not what is merely labelled). Defaults to
-     * `stickyPreChecked ?? detected` when omitted, matching `promptHarnesses`'
-     * own default and `init`'s call site (which omits both fields, so its
-     * sticky prompt still labels from real on-disk detection, unchanged).
-     * `apply`'s call site passes `[]` for `stickyPreChecked` (nothing is
-     * pre-checked; see that field's doc comment) but still wants the
-     * operator to see which harness is actually on disk, so it passes a
-     * fresh `detectHarnesses(targetDir)` call here instead: 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).
+     * pre-checked, not what is merely labelled). Defaults to `detected`
+     * when omitted: even though nothing is pre-checked (see
+     * `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
+     * 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
+     * `detected` parameter is `resolveApplyHarnesses`'s chosen-harnesses
+     * result, not real on-disk detection, and would mislabel the checkbox
+     * if relied on as the default here.
      */
     stickyAnnotateDetected?: Harness[];
 }
@@ -110,13 +112,12 @@ export interface ResolvedInitInputs {
  * omitted) keeps the previously installed value; a fresh install with no
  * prior manifest falls back to the shipped default.
  *
- * `params.detected` doubles as the fallback-chain input the non-sticky
- * "else" branch below prompts and falls back from, and (for `init`'s call
- * site only, since it omits `stickyPreChecked`) the harnesses-stickiness
- * branch's own pre-check. `apply`'s call site's `detected` is
- * `resolveApplyHarnesses`'s fallback-chain result (never empty), which is
- * not what the sticky branch should pre-check (see
- * `ResolveInitInputsParams.stickyPreChecked`'s doc comment), so it passes
- * that field separately (`[]`) for the sticky branch to read instead.
+ * `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).
  */
 export declare function resolveInitInputs(params: ResolveInitInputsParams): Promise<ResolvedInitInputs>;

package/dist/cli-inputs.js

@@ -5,12 +5,13 @@ import { detectProvider, loadOpencodeCatalog, resolveAlias, resolveOpencodeModel
 export async function promptHarnesses(detected, installed, fallbackToClaude = true, 
 // Drives only the checkbox's " (detected)" label suffix, independent of
 // `detected`'s own role in pre-checking a choice: defaults to `detected`
-// so every call site that omits this parameter keeps annotating exactly
-// what it pre-checks from, unchanged. `apply`'s sticky-branch call site
-// is the one caller that passes a different value here: it pre-checks
-// nothing (`stickyPreChecked ?? detected` is `[]`) but still wants the
-// operator to see which harness is actually on disk, so it annotates
-// from a fresh `detectHarnesses(targetDir)` call instead
+// so a call site that omits this parameter keeps annotating exactly what
+// it pre-checks from, unchanged. `resolveInitInputs`'s harnesses-
+// stickiness branch (shared by `init` and `apply`, D-002, agent-dx
+// 7669907c) always passes an explicit value here (`stickyAnnotateDetected
+// ?? detected`) instead of relying on this default: that branch pre-checks
+// nothing but still wants the operator to see which harness is actually
+// on disk, so labelling and pre-checking are resolved separately
 // (agent-tasks fe834823, fix round 3).
 annotateDetected = detected) {
     const known = [...new Set([...detected, ...installed])];
@@ -18,22 +19,17 @@ annotateDetected = detected) {
     // case pre-checks `claude` as a sane default (`fallbackToClaude`'s default
     // `true`). The templates-only re-run branch below opts OUT of that
     // (`fallbackToClaude: false`): a repo the operator explicitly recorded as
-    // `harnesses: []` has no harness files by construction, so `detected` is
-    // always empty there too, and pre-checking `claude` on Enter would
-    // silently re-widen an explicit `--harness none` install -- contradicting
-    // README.md's and this function's own "nothing forced pre-selected" claim
-    // (see CHANGELOG). That "`detected` is always empty there too" premise
-    // holds for `init`'s own call site, where `detected` is
-    // `detectHarnesses(targetDir)` on a target with no harness files by
-    // construction. `apply`'s call site (`resolveInitInputs`'s interactive
-    // branch just below) does not call this function with its own
-    // `resolveApplyHarnesses` result at all for this branch: that result is
-    // never empty (it falls back through the operator default, then
-    // detection, then `["claude"]`), so it passes `stickyPreChecked: []`
-    // here instead, regardless of what is actually on disk -- the operator's
-    // recorded `harnesses: []` is the intent that matters, not a harness
-    // config a harness itself left behind (agent-tasks fe834823; the
-    // residual noted in docs/okf/log.md's 2026-08-31 entry is closed).
+    // `harnesses: []` has no harness files by construction, and pre-checking
+    // `claude` on Enter would silently re-widen an explicit `--harness none`
+    // install -- contradicting README.md's and this function's own "nothing
+    // forced pre-selected" claim (see CHANGELOG). `resolveInitInputs`'s
+    // harnesses-stickiness branch (shared by `init` and `apply`, D-002,
+    // agent-dx 7669907c) always calls this function with `stickyPreChecked ??
+    // []` regardless of what is actually on disk or previously chosen --
+    // the operator's recorded `harnesses: []` is the intent that matters,
+    // not a harness config a harness itself left behind (agent-tasks
+    // fe834823; the residual noted in docs/okf/log.md's 2026-08-31 entry is
+    // closed).
     const preselected = known.length > 0 ? known : fallbackToClaude ? ["claude"] : [];
     const { harnesses } = await inquirer.prompt([
         {
@@ -134,14 +130,13 @@ export async function promptModels(base, roles) {
  * omitted) keeps the previously installed value; a fresh install with no
  * prior manifest falls back to the shipped default.
  *
- * `params.detected` doubles as the fallback-chain input the non-sticky
- * "else" branch below prompts and falls back from, and (for `init`'s call
- * site only, since it omits `stickyPreChecked`) the harnesses-stickiness
- * branch's own pre-check. `apply`'s call site's `detected` is
- * `resolveApplyHarnesses`'s fallback-chain result (never empty), which is
- * not what the sticky branch should pre-check (see
- * `ResolveInitInputsParams.stickyPreChecked`'s doc comment), so it passes
- * that field separately (`[]`) for the sticky branch to read instead.
+ * `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).
  */
 export async function resolveInitInputs(params) {
     const { detected, interactive, previous, opts, previousIsRecordedManifest, stickyPreChecked, stickyAnnotateDetected, } = params;
@@ -176,28 +171,31 @@ export async function resolveInitInputs(params) {
         // as `[]` (not the recorded `previous.harnesses`) so nothing is
         // pre-checked from the previous install, unlike the "else" branch
         // below's normal re-run prompt.
-        // `stickyPreChecked ?? detected` is used here rather than plain
-        // `detected`: `init` does not pass `stickyPreChecked` at all, so its
-        // own call site keeps pre-checking whatever `detectHarnesses(targetDir)`
-        // finds on disk, unchanged from before this field existed. `apply`
-        // passes `stickyPreChecked: []`: the operator's recorded
-        // `harnesses: []` is the intent that matters here, not a harness
-        // config left on disk (a weak signal `apply`'s own `detected` --
-        // `resolveApplyHarnesses`'s fallback-chain result, never empty --
-        // cannot represent either), so the interactive prompt on a templates-
-        // only `apply` target starts with nothing pre-checked at all
-        // (agent-tasks fe834823). `fallbackToClaude: false` closes the same
-        // gap for the case where nothing is pre-checked either: without it,
-        // `promptHarnesses` would pre-check `claude` on its own "nothing
-        // known" fallback, re-widening the install on a bare Enter.
-        // `stickyAnnotateDetected` is passed through as the fourth argument so
-        // the checkbox's " (detected)" label can still point at what is
-        // actually on disk even though nothing is pre-checked from it; when
-        // omitted (as `init`'s call site does), `promptHarnesses` defaults it
-        // to its own first argument, i.e. `stickyPreChecked ?? detected`,
-        // matching pre-round-3 labelling behaviour exactly.
+        // `stickyPreChecked ?? []` pre-checks nothing by default: `init` and
+        // `apply` share this semantics (D-002, agent-dx 7669907c; see
+        // CHANGELOG). Neither call site needs to pass `stickyPreChecked`
+        // itself for this default to apply (`apply` still does, as defence in
+        // depth; see `buildApplyInitInputs`'s doc comment); a bare Enter on a
+        // target recorded as `harnesses: []` must not re-widen a deliberate
+        // `--harness none` install just because a harness config happens to
+        // still be on disk, which is a weak signal, not the recorded intent
+        // (agent-tasks fe834823; the same argument applies identically to
+        // `init`). `fallbackToClaude: false` closes the same gap for the case
+        // where nothing is pre-checked either: without it, `promptHarnesses`
+        // would pre-check `claude` on its own "nothing known" fallback,
+        // re-widening the install on a bare Enter.
+        // `stickyAnnotateDetected ?? detected` is passed through as the fourth
+        // argument so the checkbox's " (detected)" label still points at what
+        // is actually on disk even though nothing is pre-checked from it: the
+        // label is a hint, not an intent signal, so `init`'s call site (which
+        // omits `stickyAnnotateDetected`) still labels from its own
+        // `detectHarnesses(targetDir)` result via this default, and `apply`'s
+        // call site still passes a fresh `detectHarnesses(targetDir)` call
+        // explicitly, since its own `detected` parameter is
+        // `resolveApplyHarnesses`'s chosen-harnesses result, not real on-disk
+        // detection.
         harnesses = interactive
-            ? await promptHarnesses(stickyPreChecked ?? detected, [], false, stickyAnnotateDetected)
+            ? await promptHarnesses(stickyPreChecked ?? [], [], false, stickyAnnotateDetected ?? detected)
             : [];
     }
     else {

package/dist/cli.js

@@ -5,6 +5,7 @@ import { Command } from "commander";
 import inquirer from "inquirer";
 import { PACKAGE_VERSION } from "./assets.js";
 import { buildApplyInitInputs } from "./cli-apply.js";
+import { buildInitInitInputs } from "./cli-init.js";
 import { resolveInitInputs } from "./cli-inputs.js";
 import { HARNESSES, detectHarnesses } from "./detect.js";
 import { DEFAULT_MODELS, PROFILES } from "./models.js";
@@ -124,17 +125,13 @@ program
             : "none recorded";
         console.log(`Found existing install (${version.startsWith("unknown") ? version : `v${version}`}, harnesses: ${installedFor}, profile: ${previous.profile}, tiers: ${previous.tiers})`);
     }
-    const { harnesses, profile, models, tiers, opencodeModels, opencodeClassModels, warnings, } = await resolveInitInputs({
-        detected,
-        interactive,
-        previous,
-        opts,
-        // `previous` here is `readInstalledManifest(targetDir)` (undefined,
-        // or the target's own actually-recorded manifest), unlike `apply`'s
-        // synthetic operator-defaults "floor" object: an empty harnesses
-        // array is a real recorded --harness none install here.
-        previousIsRecordedManifest: true,
-    });
+    const { harnesses, profile, models, tiers, opencodeModels, opencodeClassModels, warnings, } = await resolveInitInputs(
+    // The sticky-branch wiring itself (neither `stickyPreChecked` nor
+    // `stickyAnnotateDetected` overridden, so `resolveInitInputs`'s own
+    // `?? []` / `?? detected` defaults apply) is pinned inside
+    // `buildInitInitInputs` and covered by a dedicated test
+    // (`test/cli-init.test.ts`), not by this call site.
+    buildInitInitInputs(detected, previous, interactive, opts));
     for (const w of warnings) {
         process.stderr.write(`${w}\n`);
     }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "orchestrator-workflow",
-  "version": "0.27.0",
+  "version": "0.28.0",
   "description": "Installer for an orchestrator-led agent workflow: .ai/ run state, an AGENTS.md policy section, and per-harness subagent definitions for Claude Code, OpenAI Codex, and opencode",
   "main": "dist/index.js",
   "type": "module",