@ikon85/agent-workflow-kit 0.33.0 → 0.34.1

package/.agents/skills/ask-matt/SKILL.md

@@ -49,7 +49,8 @@ Prefer the smallest depth that produces a clear next action.
   undertaking, several independently-shippable stages. Run `/scale-check`
   first (it owns the altitude criteria catalog — this router only names it);
   two or more criteria tripped routes to a program grill → `/to-prd` →
-  `/to-waves`.
+  `/to-issues`. The explicit Program identity makes the Planning facade select
+  its internal graph engine; the user never chooses that engine.
 - **Deep:** `/grill-with-docs` followed by `/to-prd` and `/to-issues` when
   terminology, contracts, rollout order, or ownership are still uncertain.
 - **Medium:** `/to-issues` for a ready artefact that needs slicing.
@@ -73,9 +74,9 @@ A starting situation that generates work, then merges onto the main flow.
 
 - **Bugs and requests piling up** → **`/triage`**. Moves issues through triage and produces agent-ready issues that `/implement` later picks up. Only for issues **you didn't create** — `/to-issues` output is already agent-ready, don't triage it.
 - **Something's broken** → **`/diagnose`**. For the hard ones: the bug that resists a first glance, the intermittent flake, the regression between two known-good states. Refuses to theorise until it has a **tight feedback loop** — one command that already goes red on *this* bug — then fixes with a regression test. Its post-mortem hands off to **`/improve-codebase-architecture`** when the finding is that there's no good seam.
-- **A huge, foggy effort too big for one agent session** — a greenfield build or a sprawling feature where the way from here to the destination isn't yet visible, and it's still **pre-spec** (before any grill or PRD) → **`/wayfinder`** (user-invoked). It charts a **shared map** of investigation slices on the tracker and resolves them one at a time — producing **decisions, not deliverables** — until the fog lifts and the route is clear, then merges onto the main flow at **`/to-prd`** (or, if the effort turned out small enough, straight to **`/implement`**). Where `/grill-with-docs` sharpens an idea you can hold in one session, wayfinder is for the one you can't. Once an undertaking has already resolved into several independently-shippable waves, `/scale-check` → `/to-waves` stays the primary route.
+- **A huge, foggy effort too big for one agent session** — a greenfield build or a sprawling feature where the way from here to the destination isn't yet visible, and it's still **pre-spec** (before any grill or PRD) → **`/wayfinder`** (user-invoked). It charts a **shared map** of investigation slices on the tracker and resolves them one at a time — producing **decisions, not deliverables** — until the fog lifts and the route is clear, then merges onto the main flow at **`/to-prd`** (or, if the effort turned out small enough, straight to **`/implement`**). Where `/grill-with-docs` sharpens an idea you can hold in one session, wayfinder is for the one you can't. Once an undertaking has already resolved into several independently-shippable waves, `/scale-check` → `/to-issues` stays the primary route.
 - **A backlog to cluster** → **`/board-to-waves`**. Groups an existing board into themed waves when you need to *find* the next wave rather than start fresh.
-- **A whole wave to LAND** → **`/orchestrate-wave`**. When a wave anchor (file-disjoint slices, specs already locked) is ready to build, verify and land end-to-end — often AFK: it dispatches an implementer per slice in its own worktree, integrates serially, verifies centrally, and lands the wave. The execute-and-land node of the wave ladder (`scale-check` → `to-waves`/`board-to-waves` → `orchestrate-wave`). A single slice just goes to `/implement`.
+- **A whole wave to LAND** → **`/orchestrate-wave`**. When a wave anchor (file-disjoint slices, specs already locked) is ready to build, verify and land end-to-end — often AFK: it dispatches an implementer per slice in its own worktree, integrates serially, verifies centrally, and lands the wave. The execute-and-land node of the wave ladder (`scale-check` → `to-issues`/`board-to-waves` → `orchestrate-wave`). A single slice just goes to `/implement`.
 
 ## Cross-model review (Codex)
 

package/.agents/skills/audit-skills/SKILL.md

@@ -114,6 +114,12 @@ otherwise stay invisible.
 
 ### 2. Audit in parallel — one subagent per skill
 
+Before dispatch, resolve a provider-neutral Routing intent through
+`src/lib/routeDispatcher.mjs` and require a Dispatch receipt from the shared
+spawn guard. A detected transport is not authorization; AFK dispatch stops
+unless requested/applied route, model/effort enforcement, environment
+precedence, and catalog/access/policy revisions are proved.
+
 Run **one read-only research subagent per skill** — several in parallel in a
 SINGLE message (they are independent and read-only, so they don't contend for the
 git index). Per subagent prompt:

package/.agents/skills/board-to-waves/SKILL.md

@@ -36,7 +36,11 @@ to-issues        slices + promotes (sets type:cluster + Wave at ≥2 slices)
 
 **Stops at stubs.** No slice plan, no PRD, no sub-issue link, no promotion. Whether/when a stub becomes a real wave = separate step (`to-prd → to-issues`), <maintainer>'s call.
 
-**S4 exit — no stub at all.** A candidate that trips the `scale-check` altitude criteria (Splitter S4 below) skips the stub step entirely — it is reported as an escalation, pointing at `scale-check` (→ a program grill → `to-prd` program mode → `to-waves`), never at `to-prd`/`to-issues` directly. Still <maintainer>'s call, still no board write here.
+**S4 exit — no stub at all.** A candidate that trips the `scale-check` altitude
+criteria (Splitter S4 below) skips the stub step entirely — it is reported as
+an escalation, pointing at `scale-check` (→ a program grill → `to-prd` Program
+mode → `to-issues`), never straight into ordinary Feature decomposition. Still
+<maintainer>'s call, still no board write here.
 
 Model: **strongest available reasoning model for board-wide judgment calls** (survey/plan/brainstorm — cross-board judgment, <maintainer>'s table).
 
@@ -64,7 +68,7 @@ Model: **strongest available reasoning model for board-wide judgment calls** (su
 - **S1 Too big** — > ~7 slices / not shippable in a manageable sequence → split into two waves.
 - **S2 Foreign parent** — issue already hangs under another wave (GitHub 1-parent; `to-issues` link check is the final word).
 - **S3 "Same type alone" ≠ wave** — type is a booster, never a gate. Otherwise "all refactors" becomes a junk drawer.
-- **S4 Programm-Verdacht** — the candidate trips the `scale-check` altitude criteria (`.claude/skills/scale-check/SKILL.md` § "Altitude criteria (the single source of truth)" — referenced here, **never** re-forked; e.g. staged delivery + several subsystems that each stand on their own) → **escalate to the Program route instead of creating a candidate stub**: report it in the candidate list (§3/§5) pointing at `scale-check` (grill once into a Program-PRD with a Wellenplan, then `to-waves` unfolds it), not `to-prd`/`to-issues`. The bottom-up Wave-stamping rule above is unaffected — an escalated candidate is still just a proposal, not yet a committed wave, exactly like any other candidate.
+- **S4 Programm-Verdacht** — the candidate trips the `scale-check` altitude criteria (`.claude/skills/scale-check/SKILL.md` § "Altitude criteria (the single source of truth)" — referenced here, **never** re-forked; e.g. staged delivery + several subsystems that each stand on their own) → **escalate to the Program route instead of creating a candidate stub**: report it in the candidate list (§3/§5) pointing at `scale-check` (grill once into a Program-PRD with a Wellenplan, then `to-issues` selects the Program graph path from that explicit identity), not directly to a hidden engine. The bottom-up Wave-stamping rule above is unaffected — an escalated candidate is still just a proposal, not yet a committed wave, exactly like any other candidate.
 
 **Rule:** issue → candidate X if **Gate(X) satisfied AND ≥1 booster fires** and no splitter applies. Otherwise: own candidate or leftover bucket "unclustered / standalone issue".
 

package/.agents/skills/code-review/SKILL.md

@@ -73,6 +73,12 @@ When `projectEnrichment` is active, read `docs/agents/code-review.md` first. App
 
 ## Execution
 
+Before dispatch, resolve a provider-neutral Routing intent through
+`src/lib/routeDispatcher.mjs` and require a Dispatch receipt from the shared
+spawn guard. A detected transport is not authorization; AFK dispatch stops
+unless requested/applied route, model/effort enforcement, environment
+precedence, and catalog/access/policy revisions are proved.
+
 - Run both axes as **parallel sub-agents** — separate context each, so neither poisons the other's read. Give the Standards sub-agent the Standards sources **plus** the full Fowler baseline in its prompt; it has no other way to see the baseline.
 - Report **side by side**, under `## Standards` and `## Spec` headers, verbatim or lightly cleaned — never merge or re-rank the two into one combined verdict.
 - Cap each sub-agent's report under 400 words — findings, not padding.

package/.agents/skills/codebase-design/DESIGN-IT-TWICE.md

@@ -18,7 +18,17 @@ Show this to the user, then immediately proceed to Step 2. The user reads and th
 
 ### 2. Spawn sub-agents
 
-Spawn 3+ sub-agents in parallel using the Agent tool. Each must produce a **radically different** interface for the deepened module.
+Before dispatch, resolve a provider-neutral Routing intent through
+`src/lib/routeDispatcher.mjs` and require a Dispatch receipt from the shared
+spawn guard. A detected transport is not authorization; AFK dispatch stops
+unless requested/applied route, model/effort enforcement, environment
+precedence, and catalog/access/policy revisions are proved.
+
+<!-- mirror-xform:start codex-parallel-subagent-dispatch -->
+When the user has authorized subagent delegation, make 3+ parallel
+`spawn_agent` calls using only `task_name`, `message`, and `fork_turns`. Each
+must produce a **radically different** interface for the deepened module.
+<!-- mirror-xform:end -->
 
 Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [DEEPENING.md](DEEPENING.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
 

package/.agents/skills/codex-adapter-sync/SKILL.md

@@ -22,23 +22,27 @@ correct issue or slice worktree before the first edit. Never apply adapter
 changes on `main`; move any accidental main-checkout diff into the worktree and
 leave the main checkout clean.
 
-## Model routing
-
-Default to inherited parent model configuration. Do not pin a model merely
-because the source workflow delegates, and do not invent model or role fields
-on a spawn call. The supported built-in agent names are `default`, `worker`, and
-`explorer`; custom agents declare overrides in their TOML files.
-
-When an explicit custom-agent model is genuinely justified, route by task
-shape:
-
-- `gpt-5.6-sol` for complex, open-ended judgment work.
-- `gpt-5.6-terra` for everyday tool-using development.
-- `gpt-5.6-luna` for clear, repeatable, high-volume work.
-
-Use `model_reasoning_effort` for a supported reasoning override. The family
-name `gpt-5.6` describes the family and is not a fourth concrete variant in
-this routing table. Keep user gates, security judgment, and approval decisions
+## Routing intent
+
+Durable issues and handoffs describe task shape with provider-neutral
+`routing-intent` and `reasoning-intent` values. Never persist a provider model
+identifier or copy a resolved route back into shared work. The supported
+built-in agent names remain `default`, `worker`, and `explorer`.
+
+At dispatch time, resolve the intent by comparing the Kit-owned Evidence
+catalog with the user-local Access graph and Routing policy. Keep those
+contracts separate: catalog facts include inaccessible models, the Access graph
+attests available paths and enforcement, and personal policy filters facts
+without changing them. Report the best overall route separately from the best
+currently executable route. Unknown transports and stale capability evidence
+block; missing routing infrastructure may fall back only through explicit
+`inherit`.
+
+Apply any selected provider route only through the active surface's verified
+adapter. An AFK dispatch must prove its requested and applied route plus model
+and effort enforcement in a one-execution Dispatch receipt. Credentials,
+personal access state, and personal policy stay outside repositories and
+package-owned files. Keep user gates, security judgment, and approval decisions
 in the main thread.
 
 ## Scope
@@ -148,8 +152,8 @@ Run validation from the repository root and keep the evidence in the report:
    - Leave clearly Claude-only setup, hook, or personal/meta skills out unless
      the user explicitly wants them ported.
    - Translate Claude-specific delegation rather than copying it literally.
-     Apply the Model routing section above only when an explicit custom-agent
-     override is justified; otherwise preserve inherited parent configuration.
+     Apply the Routing intent section above only when an explicit user-local
+     route is justified; otherwise preserve explicit inheritance.
    - Keep dual-surface generic/vendored skill bodies content-synced. When a
      Codex mirror must intentionally differ from the Claude source, bracket the
      source region and the Codex replacement with a matching transform marker

package/.agents/skills/improve-codebase-architecture/INTERFACE-DESIGN.md

@@ -18,6 +18,12 @@ Show this to the user, then immediately proceed to Step 2. The user reads and th
 
 ### 2. Spawn sub-agents
 
+Before dispatch, resolve a provider-neutral Routing intent through
+`src/lib/routeDispatcher.mjs` and require a Dispatch receipt from the shared
+spawn guard. A detected transport is not authorization; AFK dispatch stops
+unless requested/applied route, model/effort enforcement, environment
+precedence, and catalog/access/policy revisions are proved.
+
 <!-- mirror-xform:start codex-parallel-subagent-dispatch -->
 When the user has authorized subagent delegation, spawn 3+ sub-agents in parallel with `spawn_agent`. Each must produce a **radically different** interface for the deepened module.
 <!-- mirror-xform:end -->

package/.agents/skills/improve-codebase-architecture/SKILL.md

@@ -35,8 +35,17 @@ This skill is _informed_ by the project's domain model. The domain language give
 
 Read the project's domain glossary and any ADRs in the area you're touching first.
 
+Before dispatch, resolve a provider-neutral Routing intent through
+`src/lib/routeDispatcher.mjs` and require a Dispatch receipt from the shared
+spawn guard. A detected transport is not authorization; AFK dispatch stops
+unless requested/applied route, model/effort enforcement, environment
+precedence, and catalog/access/policy revisions are proved.
+
 <!-- mirror-xform:start codex-explorer-dispatch -->
-When the user has authorized subagent delegation, use `spawn_agent` with `agent_type: explorer` to walk the codebase; otherwise explore locally. Don't follow rigid heuristics — explore organically and note where you experience friction:
+When the user has authorized subagent delegation, use `spawn_agent` with only
+`task_name`, `message`, and `fork_turns` to walk the codebase; otherwise explore
+locally. Don't follow rigid heuristics — explore organically and note where you
+experience friction:
 <!-- mirror-xform:end -->
 
 - Where does understanding one concept require bouncing between many small modules?

package/.agents/skills/kit-release/SKILL.md

@@ -1,13 +1,14 @@
 ---
 name: kit-release
-description: "Prepare a verified release PR for agent-workflow-kit, delegate landing to wrapup, then monitor the trusted post-merge publishing flow through npm/GitHub parity."
+description: "Prepare and integrate a verified agent-workflow-kit release, then record separately confirmed publication intent with an annotated version tag and monitor npm/GitHub parity."
 ---
 
 # Kit Release
 
 Prepare a release deterministically. This skill owns the shipped-delta decision,
-metadata preparation, and verification. It does not implement commit, push, PR,
-merge, registry publishing, tags, or release creation.
+metadata preparation, verification, and the separate post-merge publication
+gate. It delegates commit, branch push, PR, merge, and cleanup to wrapup. It
+never publishes to a registry or creates a GitHub release directly.
 
 ## Workflow
 
@@ -42,7 +43,20 @@ merge, registry publishing, tags, or release creation.
    `scripts/wrapup-land.py` exclusively own commit, push, PR creation, merge,
    and cleanup. Do not reproduce those operations here.
 
-5. After merge, monitor the `release.yml` workflow and inspect its externally
+5. After merge, report the exact integrated version and commit as
+   `awaiting-tag`. Merging integrates the prepared release; it cannot start
+   publication. Ask the user for a second, explicit confirmation to publish
+   that exact `v<version>`. The earlier Semver confirmation authorized metadata
+   preparation, not publication.
+
+6. After that confirmation, verify that the package version on current
+   `origin/main` is exactly `<version>`. Create a matching annotated
+   `v<version>` tag on that commit and push only that tag. A lightweight tag,
+   mismatching version, or commit outside canonical `main` is invalid release
+   intent. Never infer a tag target, move an existing tag, or tag an unmerged
+   commit.
+
+7. Monitor the tag-triggered `release.yml` workflow and inspect its externally
    reconstructable state:
 
    ```sh
@@ -56,6 +70,17 @@ merge, registry publishing, tags, or release creation.
    release asset have identical version, manifest hash, and tarball integrity.
    The release is complete only at `released`.
 
+   Manual dispatch is recovery only. It requires the explicit existing
+   annotated tag and runs the same idempotent reconciler:
+
+   ```sh
+   gh workflow run release.yml -f tag=v<version>
+   ```
+
+   Use it only after reconstructing the release state for that tag. Never use
+   dispatch as the normal publication route or substitute a new version for a
+   partial release.
+
    The registry identity is **`@ikon85/agent-workflow-kit`**. The unscoped
    `agent-workflow-kit` package is owned by another publisher and must never be
    queried, published, or treated as this repository's release.

package/.agents/skills/kit-update/SKILL.md

@@ -57,6 +57,19 @@ release contain the same artifact.
    (`missing-file`, `missing-section`, `empty-section`, or
    `divergent-section`); it never echoes consumer content.
 
+   Independently, run the routing-profile read-only preflight before applying
+   the package candidate. A valid unchanged user-local profile reports
+   `still valid` and causes zero prompts. Ask after successful Kit activation
+   only when the profile is missing, invalid, materially stale, references a
+   removed route, or a newly detected surface creates a meaningful choice.
+   Re-inspect after package activation, present a typed delta containing only
+   that changed choice, and preserve unaffected personal fields. Fingerprint
+   and exclusively lock the destination before writing; a concurrent personal
+   edit blocks reconciliation and remains untouched. Unattended update records
+   `needs-reconcile`; it never invents a personal answer. Declining the
+   routing reconcile leaves the successful Kit update applied because package
+   installation and personal policy are separate transactions.
+
 3. Read the terminal report. `aktuell` proves a second run found no upstream
    delta or pending readiness migration. A conflict report names and counts
    every category and leaves every consumer file untouched. Follow its

package/.agents/skills/orchestrate-wave/SKILL.md

@@ -92,7 +92,7 @@ node scripts/readiness.mjs check --skill orchestrate-wave --json
 Pass only host-supplied inventory through `capabilityAdapter.claude` or `.codex`,
 then call the selector. It returns exactly one target; missing or `unknown` evidence
 degrades A → B → C. A model claim is not evidence; do not emulate a missing primitive.
-
+Before any spawn, resolve the provider-neutral Routing intent through the shared resolver and spawn guard, then use the active Claude or Codex adapter. Codex contributes only its dated host attestation through `routingAdapters/codex.mjs`; it does not create a second catalog, Access graph, or Routing policy. A detected transport is not authorization. The Dispatch receipt must show requested and applied route, model/effort enforcement, environment precedence on mismatch, and catalog/access/policy revisions. AFK blocks unverified, unauthorized, overridden, unenforced, or silently degraded routes; a Codex host without model and effort selectors blocks differentiated AFK before spawn, and unreachable routes follow policy handoff/inherit/block exactly.
 - **Path A:** requires the literal `Workflow` tool, callable and permitted, plus
   individually proven named phases, run identity, runtime output validation,
   journal, and resume. Then read [its recipe](references/dispatch-workflow.md).

package/.agents/skills/orchestrate-wave/references/dispatch-subagents.md

@@ -5,13 +5,14 @@ requires proven native spawn, wait, and aggregate primitives plus effective
 concurrency and thread capacity ≥2. Route from proven capabilities only, never
 from a surface name, and do not emulate a missing primitive.
 
-This recipe is **dormant on the current Codex host.** A verify spike against
-codex-cli 0.144.6 (2026-07-21) proved native start plus bounded wait, and an
-effective concurrency of 4, but the host exposes tool entries carrying only a
-name and a description: no tool schema, no callable or permitted flags, no
-thread capacity. The adapter therefore emits `unknown` for those fields and the
-selector fails closed to Path C. Only a future host that supplies the complete
-normalized inventory selects this path.
+This recipe is **dormant unless the current host's complete orchestration
+inventory proves Path B.** The dated Codex routing attestation is a separate
+gate: the observed explicit-spawn schema exposes only `task_name`, `message`,
+and `fork_turns`, with no model or effort selector. Therefore
+`routingAdapters/codex.mjs` blocks differentiated AFK before spawn even when
+native start/wait/aggregate evidence is otherwise sufficient for Path B. A
+future host may enable the route only by attesting both orchestration primitives
+and applied model/effort controls; neither is inferred from the surface name.
 
 ## Main-thread preparation
 
@@ -55,10 +56,21 @@ Reconciliation is never delegated to a subagent.
 
 For the current reconciled batch, spawn **one builder per slice**, again as one
 concurrent batch joined by an explicit wait. Give each builder the verbatim
-builder contract, its reconciled allowlist, and its required commands. The host
-exposes no per-agent role, model, or reasoning selector, so routing falls back
-to the parent session configuration — record the tier you intended in the
-prompt itself rather than assuming the host honoured it.
+builder contract, its reconciled allowlist, and its required commands. Resolve
+the provider-neutral Routing intent immediately before each spawn. Pass the
+decision through `routeDispatcher.mjs` and the active surface adapter. Claude
+uses its native or explicitly policy-approved transport attestation; Codex uses
+only its dated `routingAdapters/codex.mjs` host attestation. Both must prove
+their requested and applied model and effort controls before invocation.
+Detection alone never authorizes a transport.
+
+The spawn guard compares the requested route with the adapter's applied route
+and environment precedence. It emits the shared Dispatch receipt with
+catalog/access/policy revisions. An unverified control, unauthorized transport,
+override mismatch, or unenforced effort blocks AFK before spawn. A genuinely
+unreachable route follows the policy's handoff, inherit, or block result; never
+silently inherit. A host without a proved per-agent selector remains on its
+existing parent-session fallback only when explicit non-AFK policy permits it.
 
 Each builder returns exactly one builder report. Validate it against the builder
 schema and then run `semanticVerify` on it in the main thread. A subagent's own

package/.agents/skills/orchestrate-wave/references/dispatch-workflow.md

@@ -48,6 +48,14 @@ current reconciled batch, make one `agent()` call per slice with explicit
 the reconciled allowlist and required commands in each verbatim builder prompt;
 the main thread still performs `semanticVerify` on every returned report.
 
+Before each `agent()` call, resolve its provider-neutral Routing intent and pass
+the decision through the shared spawn guard and active surface adapter. The
+Claude adapter must attest Workflow model/effort precedence in the current
+environment; a future Codex host may use this path only when its dated
+`routingAdapters/codex.mjs` attestation proves the same controls. Create the
+Dispatch receipt before invocation; any requested/applied mismatch, unverified
+control, or unauthorized transport blocks AFK rather than silently degrading.
+
 ## Resume exactly once
 
 Resume an interrupted Recon or Build run with its recorded `resumeFromRunId`

package/.agents/skills/research/SKILL.md

@@ -3,6 +3,12 @@ name: research
 description: "Investigate a question against high-trust primary sources and capture the findings as a Markdown file in the repo. Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent."
 ---
 
+Before dispatch, resolve a provider-neutral Routing intent through
+`src/lib/routeDispatcher.mjs` and require a Dispatch receipt from the shared
+spawn guard. A detected transport is not authorization; AFK dispatch stops
+unless requested/applied route, model/effort enforcement, environment
+precedence, and catalog/access/policy revisions are proved.
+
 Spin up a **background agent** to do the research, so you keep working while it reads.
 
 Its job:

package/.agents/skills/scale-check/SKILL.md

@@ -87,8 +87,9 @@ skills — this skill only picks the entry point.
 
 ### Program (≥2 criteria)
 
-A multi-wave undertaking: grill it once into a Program-PRD with a wave plan, then
-unfold that plan onto the board after a chat preview gate.
+A multi-wave undertaking: grill it once into a Program-PRD with a wave plan,
+then hand that explicit Program identity to the public Planning facade. The
+facade unfolds the plan onto the board after a chat preview gate.
 
 ```
 New program: <one-sentence outcome from Q2>.
@@ -97,10 +98,11 @@ Tripped altitude criteria: <e.g. C1 staged delivery, C2 multiple subsystems, C4
    structure-bearing decisions (escalate a single bounded choice to `decision-gate`).
 2. `to-prd` — it auto-detects the program mode from the Wellenplan chapter and writes
    a Program-PRD (native anchor over the waves).
-3. `to-waves` — after one complete chat preview, materialize the whole Program with
-   **all waves execute-ready by default**: complete slice contracts, buckets,
-   dependencies and handoffs. Decision Gates, Verify Spikes and Design-Grill waves
-   are explicit planned exceptions; generic late-binding cleanup is not.
+3. `to-issues` — its explicit Program identity selects the internal graph path.
+   After one complete chat preview, materialize the whole Program with **all
+   waves execute-ready by default**: complete slice contracts, buckets,
+   dependencies and handoffs. Decision Gates, Verify Spikes and Design-Grill
+   waves are explicit planned exceptions; generic late-binding cleanup is not.
 ```
 
 ### Feature (0–1 criteria, or any doubt)
@@ -134,7 +136,7 @@ Bug: <what's broken — expected vs. actual>.
 ```
 scale-check: verdict=<Program | Feature | Direct-Slice | Bug>
   criteria tripped=<C1,C2,… | none | n/a (bug/direct)>
-  route=<program grill → to-prd → to-waves (all waves execute-ready by default) | grill-with-docs → to-prd → to-issues | implement | diagnose>
+  route=<program grill → to-prd → to-issues (Program mode; all waves execute-ready by default) | grill-with-docs → to-prd → to-issues (Feature mode) | implement | diagnose>
   start-prompt: <the paste-ready block above, filled in>
 ```
 

package/.agents/skills/setup-workflow/SKILL.md

@@ -28,6 +28,7 @@ This is a prompt-driven skill, not a deterministic script. Explore, present what
 | `docs/agents/census.md` | optional-census choice, paths, state, and safe disable contract seeded from [census.md](./census.md) (Section A3) |
 | `docs/agents/workflow-capabilities.json` + capability assets | consumer-owned Worktree Lifecycle, Memory Lifecycle, Workflow Advisories, and Safety Guardrails choices (Sections A4–A7) |
 | `.claude/settings.json` | additive activation of the advisory kit-origin Edit/Write hint (Section A8) |
+| user-local routing profile | familiar agent surfaces + switching autonomy (Section A9; never package- or repository-owned) |
 
 ## Idempotency contract — read before writing anything
 
@@ -60,6 +61,9 @@ Read the current state; don't assume. For every target file, read its first line
 - `docs/agents/census.md`, `.census/profile.json`, `.census/active.json` — an existing census choice or consumer-owned census to adopt.
 - `docs/agents/workflow-capabilities.json`, `.claude/settings.json`, `git config --get core.hooksPath` — existing capability choices/profile plus Worktree Lifecycle, Workflow Advisories, Safety Guardrails, and kit-origin hint wiring to adopt.
 - `.memory/active/`, `.memory/archive/`, and `.memory/receipts/` — consumer-owned Memory Lifecycle policies or recovery evidence to adopt without normalization.
+- The Kit routing-profile preflight — adopt a valid user-local choice without
+  printing or copying it into the repository. Never infer personal routing
+  policy from instruction files, credentials, or package-owned metadata.
 - `gh auth status` (if GitHub) — is `gh` authenticated, and with which scopes?
 
 ### 2. Section A — Issue tracker
@@ -280,6 +284,41 @@ This is an additive, idempotent settings edit, not a settings rewrite:
    `PreToolUse`, are consumer-owned conflicts: leave the file untouched and
    report the skipped activation. Never replace or normalize them.
 
+### 2h. Section A9 — Agent surfaces and switching autonomy
+
+> Routing setup asks which familiar agent apps you use and whether the Kit may
+> switch between them. Surface adapters establish providers, transports,
+> selectors, and enforcement capabilities; the default interview never asks
+> the user to describe those technical facts.
+
+Read the versioned agent-surface registry and detection result. Show its
+multi-select labels with detected entries preselected; never embed a separate
+list in prompt prose. Then ask only one plain-language autonomy question:
+
+- **Switch automatically** — record `automatic`.
+- **Ask before switching** — record `ask`.
+- **Stay in the current app** — record `current-surface-only`.
+
+When exactly one surface is selected, skip the autonomy question and use
+`current-surface-only`. Show an activation summary with explicit **Back**,
+**Advanced**, **Approve**, and **Safe current surface** actions. Back revisits
+the simple choices. Advanced is the only flow that may collect model
+preferences or optimization overrides, but those values remain a draft and
+return to the activation summary; Advanced alone never writes. Only a later
+Approve or Safe current surface action activates the draft. Safe current
+surface activates the selection with `current-surface-only`.
+
+Store the answer through `src/lib/routingProfile.mjs` in its user-local state
+location, outside the consumer repository and package manifest. Never print
+credentials or derive personal choices from detected transports. A valid
+existing profile is terminal and reports `still valid`; do not prompt again.
+Missing or invalid profiles receive one migration interview. Reconcile a
+materially stale profile, a removed route, or a newly detected meaningful
+surface with a typed delta that names only the changed choice and preserves
+unaffected surfaces, autonomy, and advanced values. Re-read the profile before
+activation and use its fingerprint plus the exclusive profile lock; a
+concurrent user-local change blocks activation and remains byte-preserved.
+
 ### 3. Section B — Triage labels
 
 > When `triage` processes an incoming issue it applies labels (or your tracker's equivalent). It needs strings you've actually configured, or it creates duplicates.
@@ -309,7 +348,14 @@ Seed `docs/agents/domain.md` from [domain.md](./domain.md).
 
 **Fallback (the single catch-all — no board / >1 / ambiguous / scope error / read failure):** do **not** auto-create a board (`gh project create` alone cannot provision the Status options + workflow fields a board needs). Write `board-sync.md` with `state=stub`, `mode=github-projects-v2`, and inline **instructions**: which fields the workflow profile needs (a Status single-select with your stage options; optionally a Wave number, a Cluster text, a Spec-Path / Plan-Path text), how to create the board in the GitHub UI / `gh`, and "then run `/setup-workflow` again — it will discover and fill the IDs." Retryable.
 
-**Optional — Phase field + saved Views (Program route only):** never auto-discovered or auto-created, unlike the fields above — a Phase field's option set is plan-specific. If this project plans to use the Program route (`scale-check` → `to-waves` → `validate-graph`), point the user at the seeded [board-sync.md](./board-sync.md)'s "Optional: the Program route" section for the `gh project field-create` command, the optional `fields.phase` / `labels.programType` profile keys, and the two saved Views to create by hand.
+**Optional — Phase field + saved Views (Program route only):** never
+auto-discovered or auto-created, unlike the fields above — a Phase field's
+option set is plan-specific. If this project plans to use the Program route
+(`scale-check` → `to-issues` with explicit Program identity → internal graph
+validation), point the user at the seeded [board-sync.md](./board-sync.md)'s
+"Optional: the Program route" section for the `gh project field-create`
+command, the optional `fields.phase` / `labels.programType` profile keys, and
+the two saved Views to create by hand.
 
 ### 6. Section E — Spec-layer seeds (non-interactive)
 

package/.agents/skills/setup-workflow/board-sync.md

@@ -16,7 +16,7 @@ How the board-managed workflow skills (`to-prd`, `to-issues`, `board-to-waves`,
 | Cluster | text | optional | thematic cluster tag |
 | Spec-Path | text | optional | link from an issue to its spec doc |
 | Plan-Path | text | optional | link from an issue to its plan doc |
-| Phase | single-select | optional | groups waves into phases for the Program route (`to-waves`/`validate-graph`) — only needed if this project uses it |
+| Phase | single-select | optional | groups waves into phases for the Program route (`to-issues` Program mode / internal graph validation) — only needed if this project uses it |
 
 ## Machine profile (SSOT) — `scripts/board_config.py` reads this
 
@@ -112,7 +112,12 @@ their titles unchanged; set it once to match your board's language.
 
 ## Optional: the Program route (Phase field + saved Views)
 
-Skip this section entirely unless this project actually plans to use the Program route (`scale-check` → `to-waves` → `validate-graph`) — `fields.phase` / `labels.programType` are never auto-discovered or auto-created (a Phase field's option set is plan-specific, not something `/setup-workflow` can guess), and a profile without them keeps loading unchanged.
+Skip this section entirely unless this project actually plans to use the Program
+route (`scale-check` → `to-issues` with explicit Program identity → internal
+graph validation) — `fields.phase` / `labels.programType` are never
+auto-discovered or auto-created (a Phase field's option set is plan-specific,
+not something `/setup-workflow` can guess), and a profile without them keeps
+loading unchanged.
 
 1. **Create the Phase field:** `gh project field-create <number> --owner <owner> --name Phase --data-type SINGLE_SELECT --single-select-options "P1,P2,P3"` (name the options after this project's actual phases).
 2. **Fill `fields.phase`** in the `<!-- board-sync:profile -->` block above with the same `{id, options}` shape as `fields.status` — read both back via `gh project field-list <number> --owner <owner> --format json`.

package/.agents/skills/setup-workflow/workflow-overview.md

@@ -8,8 +8,7 @@ Use this section as the entry-point map for agent-assisted work. The individual
 - **A new build whose size is unclear** (a new app, a big cross-cutting feature, an unclear where-to-start): run `scale-check` — a short plain-language dialog that routes it to a program, a feature, a single slice, or a bug, and hands back a paste-ready start prompt.
 - **New capability or unclear change:** start with `grill-with-docs` when the domain language or decisions need sharpening, then publish the agreed shape with `to-prd`.
 - **A slice hinges on an unresolved fact or trade-off before it can be built:** clear it first — a binary yes/no question against real code/runtime/platform with `verify-spike`, a bounded "which option" choice with `decision-gate`.
-- **Existing plan, PRD, or ready issue:** use `to-issues` to split it into independently buildable tracer-bullet slices.
-- **A Program-PRD with a wave plan:** use `to-waves` to unfold it into named wave stubs + slice leaves on the board, after a chat preview gate that shows the whole plan before any write.
+- **Existing plan, PRD, or ready issue:** use `to-issues`, the single Planning facade. Explicit Feature identity selects tracer-bullet decomposition; explicit Program identity selects the internal graph path and its complete preview before any write.
 - **A backlog of open issues needs clustering into themed waves:** use `board-to-waves`.
 - **A whole wave anchor (file-disjoint slices, specs already locked) to build, verify and land end-to-end — often AFK:** use `orchestrate-wave` — it dispatches implementers per slice, integrates serially, verifies centrally, and lands. (A single slice just goes to `implement`.)
 - **Bugs or requests piling up that you didn't create:** use `triage` to move them into agent-ready issues.