feat: select subagent models per task

README.md

@@ -31,26 +31,22 @@ The user can overrule the gate in ordinary language by clearly directing VoltFlo
 
 ## Model routing
 
-The bootstrap router uses five profiles:
+The main session selects a model and reasoning effort for each concrete assignment from the capabilities exposed by the current Codex installation. It chooses by difficulty, ambiguity, risk, and verifiability rather than pinning a model family to a role.
 
-| Work | Model and effort |
-| --- | --- |
-| Discovery, tests, mechanical edits | Luna high |
-| Standard implementation | Terra max |
-| Planning, integration, composite review | Sol medium |
-| Routine adversarial or correctness review | Sol high |
-| Security, architecture, migrations, difficult ambiguity | Sol max |
+Mechanical work tends toward the fastest capable model at low or medium effort. Bounded implementation tends toward a balanced coding model at medium or high effort. Ambiguous integration, holistic review, and named high-risk boundaries justify stronger models or more reasoning. Independent reviewers should use a different model or reasoning configuration from the author when one is available.
 
-Direct `model` and `reasoning_effort` overrides are used when the active spawn schema supports them. Otherwise VoltFlow selects a matching agent profile when possible; if neither route exists, it inherits the parent and reports `routing degraded` instead of pretending the requested profile ran.
+Direct `model` and `reasoning_effort` overrides are used when the active spawn schema supports them. Otherwise VoltFlow uses the closest matching profile or inherits the parent only when its effort is known and not `ultra`; these fallbacks report `routing degraded`. If no compliant route exists, VoltFlow refuses the spawn and reports `routing blocked`. Explicit user selections are never silently substituted or downgraded.
 
-This table starts from the community [Codex quota frontier analysis](https://www.reddit.com/r/codex/comments/1ut3bnp/the_codex_pareto_frontier_luna_high_terra_max_sol/), checked against the different [Artificial Analysis API-cost frontier](https://artificialanalysis.ai/articles/gpt-5-6-intelligence-vs-cost-across-sol-terra-luna). It is a prior, not a permanent benchmark result. OpenAI's [GPT-5.6 prompt guidance](https://developers.openai.com/api/docs/guides/prompt-guidance-gpt-5p6) supplies the prompt shape: one outcome, explicit constraints, evidence, and a stopping condition, with each rule stated once.
+VoltFlow never selects `ultra` reasoning for a subagent. An explicit `ultra` request is rejected as a policy conflict rather than replaced with another effort.
+
+The complete selection rubric is in [routing.md](skills/voltflow/references/routing.md). The chosen model, effort, and task-based rationale are recorded with the assignment or result so routing decisions remain reviewable.
 
 ## Multi-agent compatibility
 
 VoltFlow does not call a subagent API from its Node runtime. The main Codex agent uses whichever host schema is available:
 
 - Multi-agent v1 uses the namespaced `multi_agent_v1.spawn_agent` fields, including direct `model` and `reasoning_effort` overrides.
-- Multi-agent v2 uses the flat `spawn_agent` shape with `task_name`, `message`, and `fork_turns: "none"`. VoltFlow never uses full-history inheritance for a v2 spawn. It passes model settings only when that schema exposes them; otherwise it uses a pinned agent profile or reports degraded routing.
+- Multi-agent v2 uses the flat `spawn_agent` shape with `task_name`, `message`, and `fork_turns: "none"`. VoltFlow never uses full-history inheritance for a v2 spawn. It passes model settings only when that schema exposes them; otherwise it uses a verified non-ultra profile or parent, or refuses the spawn.
 
 The lifecycle hooks consume `SubagentStart` and `SubagentStop`, so review receipts are independent of the spawn API version. Both host schemas are supported; the active schema still determines whether direct model and reasoning overrides are available.
 

skills/voltflow/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: voltflow
-description: Run a lean, risk-scaled software workflow that enforces behavioral TDD, surgical edits, bounded subagent delegation, adversarial review, and a diff-bound deployment gate. Use for implementing, fixing, refactoring, reviewing, validating, or deploying code when Codex should choose proportional planning, GPT-5.6 model/reasoning profiles, and parallel slices without unnecessary ceremony.
+description: Run a lean, risk-scaled software workflow that enforces behavioral TDD, surgical edits, bounded subagent delegation, adversarial review, and a diff-bound deployment gate. Use for implementing, fixing, refactoring, reviewing, validating, or deploying code when Codex should choose proportional planning, task-specific model and reasoning settings, and parallel slices without unnecessary ceremony.
 ---
 
 # VoltFlow
@@ -45,6 +45,8 @@ Read [references/routing.md](references/routing.md) before spawning. Scale concu
 
 When the active spawn schema is v2, always set `fork_turns: "none"`. Never use full-history inheritance, including when overriding `model` or `reasoning_effort`.
 
+Never select `ultra` reasoning for a subagent. Do not use a pinned profile or inherit the parent unless its effort is known and not `ultra`; refuse the spawn when no compliant route exists. If the user explicitly requests `ultra`, report the policy conflict instead of substituting another effort.
+
 Each spawn prompt contains five labeled fields and nothing repetitive:
 
 - `WORK LAYER`: discovery, planning, implementation, validation, or review.
@@ -71,7 +73,7 @@ Before spawning a reviewer, state the supported product boundary and material co
 
 When failures share one mechanism, fix and test that mechanism once. Do not keep adding syntax-specific patterns after the boundary is characterized. If complete enforcement would require a shell parser, a general solver, or control over an interception surface the host does not provide, keep the local guard conservative, document the limit, and route authoritative enforcement to the controller or project configuration.
 
-After a failed review, group findings by root cause and rerun only affected coverage. If a rerun finds another variant of the same bounded limitation, stop patching variants and reassess the abstraction or accepted boundary. Finish when the original acceptance criteria have current evidence and no material ordinary-use blocker remains. Use Sol high for routine independent review; raise effort only for a named risk that changes the completion bar.
+After a failed review, group findings by root cause and rerun only affected coverage. If a rerun finds another variant of the same bounded limitation, stop patching variants and reassess the abstraction or accepted boundary. Finish when the original acceptance criteria have current evidence and no material ordinary-use blocker remains. Select each reviewer's model and reasoning effort from the current task and live capabilities under [references/routing.md](references/routing.md). Prefer a configuration different from the author when available, and raise capability or effort only when the review scope, uncertainty, or a named high-risk boundary changes the completion bar.
 
 ## Gate deployment
 

skills/voltflow/references/routing.md

@@ -1,29 +1,35 @@
-# GPT-5.6 routing
+# Model and reasoning routing
 
-Use the smallest profile that clears the task. These profiles seed VoltFlow's routing table; rerun the eval suite when model behavior or quota accounting changes.
+Choose the model and reasoning effort for the concrete assignment from the capabilities available in the current Codex installation. This is a selection rubric, not a fixed profile table; rerun the eval suite when model behavior, availability, or quota accounting changes.
 
-| Profile | Route work here |
-| --- | --- |
-| `gpt-5.6-luna`, `high` | Read-heavy discovery, focused test execution, mechanical edits, and simple pattern-following work. |
-| `gpt-5.6-terra`, `max` | Standard implementation inside established architecture and bounded multi-file changes. |
-| `gpt-5.6-sol`, `medium` | Planning, integration, and composite review that need global coherence without max-cost reasoning. |
-| `gpt-5.6-sol`, `high` | Routine adversarial review, correctness checks, and bounded security review without a named high-risk boundary. |
-| `gpt-5.6-sol`, `max` | High-risk architecture, security, concurrency, migrations, and ambiguous work where a missed constraint is expensive. |
+Inspect the active spawn schema before delegating. Treat its model descriptions and supported reasoning efforts as authoritative, and do not infer capability from a model name alone.
+
+| Task characteristics | Model tendency | Reasoning tendency |
+| --- | --- | --- |
+| Mechanical, read-heavy, repetitive, or easy to verify | Fastest capable model | Low or medium |
+| Bounded implementation with clear acceptance checks | Balanced coding model | Medium or high |
+| Ambiguous planning, difficult debugging, or cross-cutting integration | Strongest suitable model | High, xhigh, or max |
+| Adversarial or holistic review | Capable reviewer, preferably configured differently from the author | Scale with ambiguity and the strength of deterministic checks |
+| Named high-risk boundary where a miss is expensive | Strongest suitable model | High, xhigh, or max |
 
 ## Routing rules
 
-1. Choose by difficulty, not by role title. A mechanical security-file edit can use Luna; a subtle one-file race can require Sol max.
-2. Set `model` and `reasoning_effort` directly when the spawn schema exposes them. Omit `service_tier`.
-3. If only `agent_type` is available, select a profile that pins the required model and effort. If neither override surface exists, inherit the parent and state `routing degraded` once in the result.
-4. Use Sol medium for the normal planner and composite reviewer, and Sol high for routine independent review lanes. Raise to Sol max only for a named high-risk fact.
-5. Size each wave to the useful independent slices and the host's available concurrency. Do not create slices solely to increase agent count.
+1. Choose by task difficulty, ambiguity, risk, and verifiability rather than role title. A mechanical security-file edit can use a fast model at medium effort; a subtle one-file race can need the strongest model at high effort.
+2. The main session owns the selection. Set `model` and `reasoning_effort` directly when the spawn schema exposes them, and omit `service_tier` unless the user requests one.
+3. For independent review, prefer a model or reasoning configuration different from the author when available. Raise capability or effort only when the review scope, uncertainty, or named risk justifies it.
+4. Named high-risk boundaries include authorization, private data, payments, bookings, destructive or data-integrity migrations, and cross-cutting architecture. They establish a higher selection floor without prescribing one model family.
+5. Never select `ultra` reasoning for a subagent. If the user explicitly requests it, report the policy conflict instead of substituting another effort.
+6. Honor any other explicit user selection. If the requested model or effort is unavailable, report that instead of silently substituting or downgrading it.
+7. If only `agent_type` is available, select the closest matching profile whose effort is known and not `ultra`. If no override surface exists, inherit the parent only when its effort is known and not `ultra`; state `routing degraded` once in the result. If neither compliant route exists, refuse the spawn and state `routing blocked`.
+8. Record the selected model, reasoning effort, and short task-based rationale in the assignment or result so routing decisions remain reviewable.
+9. Size each wave to the useful independent slices and the host's available concurrency. Do not create slices solely to increase agent count.
 
 ## Spawn schema
 
 Inspect the active tool schema before spawning and use only fields it declares.
 
 - Multi-agent v1: call `multi_agent_v1.spawn_agent` with `message`, `fork_context: false`, and the chosen `model` and `reasoning_effort`. Add `agent_type` only when a matching role improves the assignment.
-- Multi-agent v2: always call the flat `spawn_agent` with `task_name`, `message`, and `fork_turns: "none"`. Never use full-history inheritance. Pass model settings only when the schema declares them; otherwise use a matching pinned profile or inherit the parent and report `routing degraded`.
+- Multi-agent v2: always call the flat `spawn_agent` with `task_name`, `message`, and `fork_turns: "none"`. Never use full-history inheritance. Pass model settings only when the schema declares them; otherwise use a verified non-ultra profile or parent and report `routing degraded`. Refuse the spawn when no compliant route exists.
 
 The hook workflow observes subagent lifecycle events rather than calling either API, so review collection does not depend on the spawn schema.