@femtomc/mu-agent 26.2.105 → 26.2.106

package/README.md

@@ -30,6 +30,7 @@ into `~/.mu/skills/` (or `$MU_HOME/skills/`) by the CLI store-initialization pat
 - `hud`
 - `orchestration`
 - `control-flow`
+- `model-routing`
 - `code-mode`
 - `tmux`
 - `subagents`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@femtomc/mu-agent",
-  "version": "26.2.105",
+  "version": "26.2.106",
   "description": "Shared operator runtime for mu assistant sessions and serve extensions.",
   "keywords": [
     "mu",
@@ -25,7 +25,7 @@
     "themes/**"
   ],
   "dependencies": {
-    "@femtomc/mu-core": "26.2.105",
+    "@femtomc/mu-core": "26.2.106",
     "@mariozechner/pi-agent-core": "^0.54.2",
     "@mariozechner/pi-ai": "^0.54.2",
     "@mariozechner/pi-coding-agent": "^0.54.2",

package/prompts/skills/crons/SKILL.md

@@ -154,6 +154,7 @@ For DAG execution workloads, combine with:
 - `planning`
 - `orchestration`
 - `control-flow` (when explicit loop/termination policy is required)
+- `model-routing` (when per-issue model/provider/thinking policy is required)
 - `subagents`
 - `heartbeats` (for short-cadence wake loops)
 

package/prompts/skills/heartbeats/SKILL.md

@@ -147,6 +147,7 @@ For hierarchical DAG execution, pair this skill with:
 - `planning`
 - `orchestration`
 - `control-flow` (when explicit loop/termination policy is required)
+- `model-routing` (when per-issue model/provider/thinking policy is required)
 - `subagents`
 
 For wall-clock scheduling semantics (`at`, `every`, `cron`), use `crons`.

package/prompts/skills/hud/SKILL.md

@@ -19,7 +19,7 @@ This skill is the canonical HUD reference for:
 - [HudDoc shape](#huddoc-shape)
 - [Recommended turn loop](#recommended-turn-loop)
 - [Ownership and teardown protocol](#ownership-and-teardown-protocol)
-- [Planning and subagents profiles](#planning-and-subagents-profiles)
+- [Planning, subagents, and model-routing profiles](#planning-subagents-and-model-routing-profiles)
 - [Determinism and rendering limits](#determinism-and-rendering-limits)
 - [Evaluation scenarios](#evaluation-scenarios)
 
@@ -143,7 +143,7 @@ that skill declares HUD-required behavior.
 
 1. **Own explicit `hud_id` values**
    - Each active skill owns one canonical doc id (for example `planning`,
-     `subagents`, `control-flow`).
+     `subagents`, `control-flow`, `model-routing`).
    - Prefer `remove <hud_id>` over `clear` to avoid deleting other skills’ docs.
 
 2. **Teardown is mandatory at skill end**
@@ -168,12 +168,13 @@ Example full teardown (no next HUD skill):
 {"action":"off"}
 ```
 
-## Planning and subagents profiles
+## Planning, subagents, and model-routing profiles
 
 Use profile-specific `hud_id` values:
 
 - planning profile: `hud_id: "planning"`
 - subagents profile: `hud_id: "subagents"`
+- model-routing profile: `hud_id: "model-routing"`
 
 Treat these as conventions layered on top of this generic contract.
 

package/prompts/skills/model-routing/SKILL.md

@@ -0,0 +1,336 @@
+---
+name: model-routing
+description: "Adds a model-selection overlay for issue DAG execution, recommending provider/model/thinking per issue from live harness capabilities."
+---
+
+# model-routing
+
+Use this skill when execution should choose different models for different issue
+kinds (for example code vs docs), while preserving orchestration protocol
+semantics.
+
+## Contents
+
+- [Purpose](#purpose)
+- [Required dependencies](#required-dependencies)
+- [Core contract](#core-contract)
+- [Overlay identity (`route:model-routing-v1`)](#overlay-identity-routemodel-routing-v1)
+- [Tag vocabulary](#tag-vocabulary)
+- [Recommendation packet contract](#recommendation-packet-contract)
+- [Selection algorithm (deterministic)](#selection-algorithm-deterministic)
+- [Transition table](#transition-table)
+- [Planning handoff contract](#planning-handoff-contract)
+- [Subagents/heartbeat execution contract](#subagentsheartbeat-execution-contract)
+- [Failure + fallback policy](#failure--fallback-policy)
+- [HUD visibility and teardown](#hud-visibility-and-teardown)
+- [Evaluation scenarios](#evaluation-scenarios)
+
+## Purpose
+
+Model-routing policies are overlays. They do not replace `orchestration`
+protocol semantics.
+
+Examples:
+- use a strong coding model for implementation leaves
+- use a stronger writing model for docs/synthesis leaves
+- choose lower-cost fast models for routine triage
+- escalate to deeper thinking for high-risk or complex nodes
+
+## Required dependencies
+
+Load these skills before applying model-routing policies:
+
+- `orchestration` (protocol primitives/invariants)
+- `subagents` (durable execution runtime)
+- `heartbeats` and/or `crons` (scheduler clock)
+- `hud` (required visibility/handoff surface)
+- `control-flow` (optional; when loop/termination overlays are also active)
+
+## Core contract
+
+1. **Overlay, don’t fork protocol**
+   - Keep `hierarchical-work.protocol/v1` + `proto:hierarchical-work-v1`.
+   - Do not redefine `kind:*`, `ctx:*`, issue lifecycle semantics, or DAG validity.
+
+2. **Harness is source-of-truth**
+   - Drive recommendations from `mu control harness --json`.
+   - Only consider authenticated providers unless policy explicitly allows otherwise.
+
+3. **Recommend, then apply**
+   - Route decisions are explicit artifacts (forum packets + optional tags),
+     not hidden implicit behavior.
+
+4. **Non-blocking by default**
+   - Routing failure should degrade safely (fallback model / default model)
+     unless a hard requirement cannot be met.
+
+5. **Bounded pass per tick**
+   - One routing decision and one bounded mutation/action bundle per heartbeat pass.
+
+6. **Per-issue/session overrides preferred**
+   - Use `mu exec --provider/--model/--thinking` or `mu turn ...` overrides.
+   - Avoid changing workspace-global operator defaults for per-issue routing.
+
+## Overlay identity (`route:model-routing-v1`)
+
+- Tag scope root (or selected subtree root) with: `route:model-routing-v1`
+- Routing metadata remains orthogonal to `kind:*`, `ctx:*`, and `flow:*`.
+
+## Tag vocabulary
+
+Recommended routing tags (policy metadata):
+
+- Scope:
+  - `route:model-routing-v1`
+- Task family:
+  - `route:task:code`
+  - `route:task:docs`
+  - `route:task:research`
+  - `route:task:ops`
+  - `route:task:review`
+  - `route:task:synth`
+  - `route:task:general`
+- Depth intent:
+  - `route:depth:fast`
+  - `route:depth:balanced`
+  - `route:depth:deep`
+- Budget intent:
+  - `route:budget:low`
+  - `route:budget:balanced`
+  - `route:budget:premium`
+- Hard modality requirement:
+  - `route:modality:image` (omit for text-only)
+- Pin indicator:
+  - `route:pin` (exact provider/model comes from packet metadata)
+
+Notes:
+- Keep tags concise and stable.
+- Put detailed routing config in forum packets (not in tag strings).
+
+## Recommendation packet contract
+
+Post one `ROUTE_RECOMMENDATION` packet to `issue:<issue-id>` before launching work
+with a selected model.
+
+Suggested packet shape (JSON block inside forum message):
+
+```text
+ROUTE_RECOMMENDATION:
+{
+  "version": "route:model-routing-v1",
+  "issue_id": "<issue-id>",
+  "harness_fingerprint": "<sha256>",
+  "selected": {
+    "provider": "<provider>",
+    "model": "<model>",
+    "thinking": "<thinking-level>"
+  },
+  "alternates": [
+    { "provider": "<provider>", "model": "<model>", "thinking": "<thinking-level>" }
+  ],
+  "constraints": {
+    "task": "code|docs|research|ops|review|synth|general",
+    "depth": "fast|balanced|deep",
+    "budget": "low|balanced|premium",
+    "modality": "text|image",
+    "min_context_window": 0
+  },
+  "rationale": [
+    "provider authenticated",
+    "supports required thinking level",
+    "meets context/modality constraints",
+    "best score under budget/depth policy"
+  ],
+  "created_at_ms": 0
+}
+```
+
+Optional root-level packet for custom preferences:
+
+```text
+ROUTE_POLICY:
+{
+  "version": "route:model-routing-v1",
+  "task_preferences": {
+    "code": [
+      { "provider": "openai-codex", "model": "gpt-5.3-codex", "thinking": "xhigh" }
+    ],
+    "docs": [
+      { "provider": "openrouter", "model": "google/gemini-3.1-pro-preview", "thinking": "high" }
+    ]
+  }
+}
+```
+
+If a preference entry is unavailable under current harness/auth state, skip it and
+continue deterministic fallback selection.
+
+## Selection algorithm (deterministic)
+
+### Inputs
+
+- Issue tags (`route:task:*`, `route:depth:*`, `route:budget:*`, `route:modality:image`, `route:pin`)
+- Optional `ROUTE_POLICY` and per-issue constraints from forum/body
+- Live harness snapshot (`mu control harness --json`)
+
+### Step 1: gather live capabilities
+
+```bash
+mu control harness --json --pretty
+```
+
+### Step 2: build candidate set
+
+1. Start from authenticated providers only.
+2. Flatten model entries across providers.
+3. Filter by hard requirements:
+   - required modality (`text` and optional `image`)
+   - minimum context window (if specified)
+   - pin requirement (`route:pin`) if specified
+4. Resolve target thinking from depth intent:
+   - `fast` -> `minimal`
+   - `balanced` -> `medium`
+   - `deep` -> `xhigh` if available, else `high`
+5. Clamp chosen thinking to model-supported `thinking_levels`.
+
+### Step 3: score candidates
+
+Use deterministic score components (example):
+
+- Hard-fit gates (must pass): auth, modality, context, thinking compatibility
+- Soft score:
+  - task preference match (`ROUTE_POLICY`/task family)
+  - reasoning/xhigh capability vs depth
+  - context headroom
+  - budget penalty from per-token cost
+
+Tie-breaker: lower estimated cost, then lexicographic `provider/model`.
+
+### Step 4: select + alternates
+
+- pick top candidate as `selected`
+- keep next N as `alternates` (recommended N=2)
+- post `ROUTE_RECOMMENDATION` packet
+
+### Step 5: apply selection
+
+For one-shot execution:
+
+```bash
+mu exec --provider <provider> --model <model> --thinking <thinking> \
+  "Use skills subagents, orchestration, model-routing, and hud. Work issue <issue-id>."
+```
+
+For existing session turn:
+
+```bash
+mu turn --session-kind cp_operator --session-id <session-id> \
+  --provider <provider> --model <model> --thinking <thinking> \
+  --body "Continue issue <issue-id> with current routing selection."
+```
+
+## Transition table
+
+Given an executable issue under `route:model-routing-v1`:
+
+1. **No routing decision yet**
+   - action: compute recommendation + post `ROUTE_RECOMMENDATION` packet
+
+2. **Routing decision exists and still valid**
+   - action: execute issue using selected provider/model/thinking
+
+3. **Selected route fails at launch/runtime**
+   - action: choose next alternate, post `ROUTE_FALLBACK`, retry bounded once
+
+4. **All alternates exhausted**
+   - action: degrade to harness default model, post `ROUTE_DEGRADED`
+
+5. **Hard requirement unmet (no valid candidates)**
+   - action: create `kind:ask` node (`ctx:human`, `actor:user`) requesting
+     provider auth/config change or constraint relaxation
+
+## Planning handoff contract
+
+When planning a routed subtree:
+
+1. Tag policy scope with `route:model-routing-v1`.
+2. Tag executable nodes with task/depth/budget intent.
+3. Record any hard constraints (modality/context) in issue body or forum packet.
+4. Optionally add root `ROUTE_POLICY` preferences.
+5. Ensure DAG remains valid under `orchestration` invariants:
+   - `mu issues ready --root <root-id> --tag proto:hierarchical-work-v1 --pretty`
+   - `mu issues validate <root-id>`
+
+## Subagents/heartbeat execution contract
+
+Per orchestrator tick:
+
+1. Read tree + ready set + latest route packet on target issue.
+2. Read harness snapshot once per pass.
+3. Select one routing transition from the table above.
+4. Apply one bounded mutation bundle (recommend/fallback/ask/execute-start).
+5. Verify with:
+   - `mu issues ready --root <root-id> --tag proto:hierarchical-work-v1 --pretty`
+   - `mu issues validate <root-id>`
+6. Update HUD state.
+7. Post one concise `ORCH_PASS` status update.
+8. If root is final, disable supervising heartbeat.
+
+Reusable heartbeat prompt fragment:
+
+```text
+Use skills orchestration, model-routing, subagents, and hud.
+For root <root-id>, enforce route:model-routing-v1.
+Run exactly one bounded routing/orchestration transition pass: compute or validate
+one issue's model recommendation from live `mu control harness` capabilities,
+apply one action, verify DAG state, post one ORCH_PASS, then stop.
+If validate is final, disable the supervising heartbeat and report completion.
+```
+
+## Failure + fallback policy
+
+1. **Provider/model unavailable or auth drift**
+   - post `ROUTE_FALLBACK`
+   - move to next alternate
+
+2. **Thinking level unsupported for selected model**
+   - clamp to nearest supported lower level
+   - post rationale in fallback packet
+
+3. **No candidates satisfy hard constraints**
+   - create `kind:ask` escalation with clear options:
+     - authenticate provider X
+     - relax modality/context/depth constraint
+     - approve default-model execution
+
+4. **Auditability requirement**
+   - every route change emits forum packet (`ROUTE_RECOMMENDATION`,
+     `ROUTE_FALLBACK`, `ROUTE_DEGRADED`)
+
+## HUD visibility and teardown
+
+HUD usage is not optional for active model-routing execution.
+
+- If subagents HUD is active, publish routing state there (selected model,
+  alternates remaining, last fallback reason).
+- If running model-routing standalone, own `hud_id:"model-routing"`.
+- Update HUD each bounded pass before ORCH_PASS output.
+- Follow `hud` skill ownership/teardown protocol on completion or handoff.
+
+## Evaluation scenarios
+
+1. **Coding leaf selects deep coding model**
+   - Setup: `route:task:code`, `route:depth:deep`, authenticated coding provider.
+   - Expected: recommendation picks a deep reasoning coding model and starts work.
+
+2. **Docs leaf prefers writing model**
+   - Setup: `route:task:docs` with root `ROUTE_POLICY` preference for docs.
+   - Expected: recommendation uses preferred docs model when available, otherwise fallback.
+
+3. **Auth/provider drift fallback**
+   - Setup: selected provider becomes unauthenticated mid-run.
+   - Expected: `ROUTE_FALLBACK` packet and alternate selection in next bounded pass.
+
+4. **Hard requirement escalation**
+   - Setup: issue requires image input but no authenticated image-capable models.
+   - Expected: `kind:ask` node created; downstream remains blocked until user action.

package/prompts/skills/mu/SKILL.md

@@ -179,6 +179,7 @@ mu cron --help
 When work is multi-step and issue-graph driven, use `planning` to shape the DAG,
 then `hud` for canonical HUD behavior, then `orchestration` to keep DAG
 semantics consistent, then `control-flow` for explicit loop/termination policy,
+then `model-routing` for per-issue provider/model/thinking selection overlays,
 then `subagents` for durable execution.
 For REPL-driven exploration and context compression, use `code-mode`.
 For persistent terminal sessions and worker fan-out mechanics, use `tmux`.
@@ -206,6 +207,7 @@ For wall-clock schedules (one-shot, interval, cron-expression), use `crons`.
 - HUD contract/state updates across surfaces: **`hud`**
 - Shared DAG semantics for planning + execution: **`orchestration`**
 - Loop/termination policy overlays (review gates, retries, escalation): **`control-flow`**
+- Per-issue model/provider/thinking selection overlays: **`model-routing`**
 - Live REPL execution and context engineering via tmux: **`code-mode`**
 - Persistent tmux session management + worker fan-out primitives: **`tmux`**
 - Durable multi-agent orchestration: **`subagents`**

package/prompts/skills/orchestration/SKILL.md

@@ -13,7 +13,7 @@ This skill supersedes the previous `hierarchical-work-protocol` skill name.
 
 - [Protocol identity](#protocol-identity)
 - [Canonical tags and node roles](#canonical-tags-and-node-roles)
-- [Control-flow overlays](#control-flow-overlays)
+- [Policy overlays](#policy-overlays)
 - [Protocol primitives](#protocol-primitives)
 - [Required invariants](#required-invariants)
 - [Planning handoff contract](#planning-handoff-contract)
@@ -65,19 +65,24 @@ Node role rules:
    - Must include: `proto:hierarchical-work-v1`, `kind:ask`, `ctx:human`, `actor:user`
    - Must be non-executable (`node:agent` removed)
 
-## Control-flow overlays
+## Policy overlays
 
-Control-flow is layered on top of this protocol and should not redefine protocol
-primitives or `kind:*` semantics.
+Policy overlays are layered on top of this protocol and should not redefine
+protocol primitives or `kind:*` semantics.
 
 - Keep orchestration protocol tags/kinds as source-of-truth for structure.
-- Represent policy-specific behavior (for example review gates, retry rounds,
-  escalation thresholds) with `flow:*` tags/metadata.
-- Compile control-flow policy decisions into existing primitives (`spawn`, `fork`,
-  `expand`, `ask`, `complete`, `serial`) instead of introducing ad-hoc mutations.
-
-Current compositional control-flow policy skill:
+- Represent policy-specific behavior with overlay tags/metadata:
+  - loop/termination policy (for example review gates, retry rounds,
+    escalation thresholds): `flow:*`
+  - per-issue model/provider/thinking routing policy: `route:*`
+- Compile overlay decisions into existing primitives (`spawn`, `fork`, `expand`,
+  `ask`, `complete`, `serial`) and per-turn/per-session model overrides
+  (`mu exec` / `mu turn` with `--provider --model --thinking`) instead of
+  introducing ad-hoc mutations.
+
+Current compositional overlay skills:
 - `control-flow` (for example `flow:review-gated-v1` behavior)
+- `model-routing` (for example `route:model-routing-v1` behavior)
 
 ## Protocol primitives
 

package/prompts/skills/planning/SKILL.md

@@ -61,6 +61,11 @@ If the user asks for explicit loop/termination behavior (for example review-gate
 retry rounds), load **`control-flow`** and encode policy via `flow:*` overlays
 without changing orchestration protocol semantics.
 
+If the user asks for per-issue model/provider/thinking recommendations based on
+live harness capabilities, load **`model-routing`** and encode policy via
+`route:*` overlays plus route packets (for example `ROUTE_POLICY`) without
+changing orchestration protocol semantics.
+
 ## Core contract
 
 1. **Investigate first**
@@ -71,6 +76,7 @@ without changing orchestration protocol semantics.
    - Create root and child issues that comply with `hierarchical-work.protocol/v1`.
    - Encode dependencies so the DAG reflects execution order and synth fan-in.
    - Add clear titles, scope, acceptance criteria, and protocol tags.
+   - When model specialization is required, attach explicit `route:*` intent tags/constraints to executable nodes.
 
 3. **Drive communication through the planning HUD**
    - Load `hud` and use its canonical `mu_hud`/`HudDoc` contract.
@@ -234,4 +240,5 @@ Required HUD updates during the loop:
 - Keep tasks small enough to complete in one focused pass.
 - Explicitly call out uncertain assumptions for user confirmation.
 - Prefer reversible plans and incremental checkpoints.
+- If `model-routing` is in scope, route intent/constraints are explicit and non-conflicting.
 - HUD state must be fresh, accurate, and aligned with user-visible status updates.

package/prompts/skills/subagents/SKILL.md

@@ -10,6 +10,7 @@ description: "Orchestrates issue-driven subagent execution with heartbeat superv
 - [Purpose (what this skill is for)](#purpose-what-this-skill-is-for)
 - [Shared protocol dependency](#shared-protocol-dependency)
 - [Control-flow dependency](#control-flow-dependency)
+- [Model-routing dependency](#model-routing-dependency)
 - [HUD skill dependency](#hud-skill-dependency)
 - [tmux skill dependency](#tmux-skill-dependency)
 - [When to use](#when-to-use)
@@ -58,6 +59,19 @@ an overlay on orchestration primitives.
 - Compile control-flow decisions into protocol primitives (`spawn`, `expand`,
   `ask`, `complete`, `serial`), not ad-hoc mutations.
 
+## Model-routing dependency
+
+When a subtree declares per-issue model/provider/thinking policy (for example
+`route:model-routing-v1`), load **`model-routing`** and apply routing transitions
+as an overlay on orchestration primitives.
+
+- Keep DAG structure protocol-valid (`orchestration` remains source-of-truth).
+- Drive recommendations from live harness capabilities (`mu control harness --json`).
+- Apply route selections with per-turn/per-session overrides (`mu exec`/`mu turn`
+  `--provider --model --thinking`) instead of mutating workspace-global defaults.
+- Emit auditable route packets (`ROUTE_RECOMMENDATION`, `ROUTE_FALLBACK`,
+  `ROUTE_DEGRADED`) in forum topics.
+
 ## HUD skill dependency
 
 Before emitting or mutating subagent HUD state, load **`hud`** and follow its canonical contract.
@@ -142,6 +156,7 @@ For claimed issue `<issue-id>` under `<root-id>`:
 
 1. Run `read_tree`.
 2. Choose one primitive:
+   - route policy present and no valid route decision -> apply one `model-routing` transition
    - missing input -> `ask`
    - needs decomposition -> `expand`
    - directly solvable -> `complete`
@@ -171,7 +186,7 @@ mu heartbeats create \
   --title "hierarchical-work-v1 <root-id>" \
   --reason orchestration_v1 \
   --every-ms 15000 \
-  --prompt "Use skills subagents, orchestration, control-flow, and hud for root <root-id>. Run exactly one bounded orchestration pass: inspect the proto:hierarchical-work-v1 queue, perform exactly one corrective orchestration action (including in_progress-without-worker drift recovery) or claim/work-start one ready issue, then verify state. If flow:* policy tags are present, apply one control-flow transition from the control-flow skill in this pass. Report human-facing progress as a titled status note plus one concise paragraph that explains project context, milestone moved, impact, overall progress, and next high-level step; avoid low-level orchestration internals unless diagnosing a blocker/anomaly. Post a matching ORCH_PASS update to issue:<root-id>. Stop when 'mu issues validate <root-id>' is final."
+  --prompt "Use skills subagents, orchestration, control-flow, model-routing, and hud for root <root-id>. Run exactly one bounded orchestration pass: inspect the proto:hierarchical-work-v1 queue, perform exactly one corrective orchestration action (including in_progress-without-worker drift recovery) or claim/work-start one ready issue, then verify state. If flow:* policy tags are present, apply one control-flow transition from the control-flow skill in this pass. If route:* policy tags are present, apply one model-routing transition from the model-routing skill in this pass using live `mu control harness` capabilities and per-turn provider/model/thinking overrides. Report human-facing progress as a titled status note plus one concise paragraph that explains project context, milestone moved, impact, overall progress, and next high-level step; avoid low-level orchestration internals unless diagnosing a blocker/anomaly. Post a matching ORCH_PASS update to issue:<root-id>. Stop when 'mu issues validate <root-id>' is final."
 ```
 
 Reusable status-voice add-on for heartbeat prompts (copy/paste):
@@ -191,7 +206,7 @@ run_id="$(date +%Y%m%d-%H%M%S)"
 for issue_id in $(mu issues ready --root <root-id> --tag proto:hierarchical-work-v1 --json | jq -r '.[].id' | head -n 3); do
   session="mu-sub-${run_id}-${issue_id}"
   tmux new-session -d -s "$session" \
-    "cd '$PWD' && mu exec 'Use skills subagents, orchestration, control-flow, and hud. Work issue ${issue_id} using hierarchical-work.protocol/v1. If flow:* policy tags are present, apply the control-flow overlay before selecting the next primitive. Claim first, then run one full control loop.' ; rc=\$?; echo __MU_DONE__:\$rc"
+    "cd '$PWD' && mu exec 'Use skills subagents, orchestration, control-flow, model-routing, and hud. Work issue ${issue_id} using hierarchical-work.protocol/v1. If flow:* policy tags are present, apply the control-flow overlay before selecting the next primitive. If route:* policy tags are present, apply the model-routing overlay using live harness capabilities before selecting the next primitive. Claim first, then run one full control loop.' ; rc=\$?; echo __MU_DONE__:\$rc"
 done
 ```
 
@@ -233,6 +248,10 @@ Tool: `mu_hud`
    - Setup: worker encounters missing critical input.
    - Expected: skill applies protocol `ask` semantics, creates a human-input node, and downstream work remains blocked until the answer issue closes.
 
+4. **Model-routing overlay with fallback**
+   - Setup: ready issue tagged `route:model-routing-v1` and selected model fails at launch.
+   - Expected: one bounded pass emits `ROUTE_FALLBACK`, selects alternate/provider fallback deterministically, and continues execution without violating DAG protocol rules.
+
 ## Reconciliation
 
 - Run `mu issues validate <root-id>` before declaring completion.