@open-agent-toolkit/cli 0.1.45 → 0.1.46

package/assets/agents/oat-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: oat-reviewer
-version: 1.1.4
+version: 1.1.5
 description: Unified reviewer for OAT projects - mode-aware verification of requirements/design alignment and code quality. Writes a review artifact to disk by default, or returns structured findings in-memory when dispatched in structured-output mode.
 tools: Read, Bash, Grep, Glob, Write
 color: yellow
@@ -68,7 +68,7 @@ You will be given a "Review Scope" block including:
 
 The orchestrator owns dispatch control. Do not read `plan.md` Dispatch Profile rows to self-select a tier.
 
-For Codex, deterministic review dispatch under a capped managed policy uses pinned reviewer variants (`oat-reviewer-low`, `oat-reviewer-medium`, `oat-reviewer-high`, or `oat-reviewer-xhigh`) selected by the resolved OAT dispatch policy cap. Managed `Uncapped` and inherit/default policies have no reviewer target, so the base `oat-reviewer` role is used as a provider-default/unpinned fallback. If you are running as the base role, report any provided `provider_default_effort` as context but do not treat it as managed uncapped selection or an OAT cap.
+For Codex, deterministic review dispatch under a capped managed policy uses the materialized Codex role name returned by `providers.codex.dispatchArgs.variant`; the orchestrator also supplies `providers.codex.selection.target` context when available and should derive `model_axis` and `effort_axis` from resolver output. Managed `Uncapped` and inherit/default policies have no reviewer target, so the base `oat-reviewer` role is used only when the resolver returns no `dispatchArgs.variant`, as a provider-default/unpinned fallback. If you are running as the base role, report any provided `provider_default_effort` as context but do not treat it as managed uncapped selection or an OAT cap. Use base `oat-reviewer` only when the resolver returns no `dispatchArgs.variant`.
 
 For Claude Code, review dispatch is model-axis based and the effort axis is `not-applicable`.
 

package/assets/docs/cli-utilities/config-and-local-state.md

@@ -113,6 +113,13 @@ Use `oat config` for repo runtime config inspection and supported key mutation.
 
 Use `oat config dump --json` when you need the whole resolved config in one machine-readable response rather than a single key or a human-oriented list view.
 
+Dispatch policy keys are part of this surface, but provider-specific generation
+still belongs to provider commands. Use `oat config describe
+workflow.dispatchPolicy.policy` to inspect capped managed, managed uncapped,
+inherit/default, and unresolved behavior; use `oat providers codex materialize`
+or `oat sync --scope project` to create materialized Codex roles from explicit
+model+effort targets.
+
 Archive lifecycle settings live here as shared repo config:
 
 - `archive.s3Uri`

package/assets/docs/cli-utilities/configuration.md

@@ -235,30 +235,70 @@ entries are either bare slugs or objects with `harness`, `model`, and optional
 }
 ```
 
-`Uncapped` is explicit managed state. Do not represent it by leaving policy
-state absent. To request no OAT model/effort selection, set:
+`Uncapped` is explicit managed state: OAT still selects the preferred
+provider-specific dispatch target, but does not apply a maximum cap. Do not
+represent it by leaving policy state absent. To request no OAT model/effort
+selection, set:
 
 ```bash
 oat config set workflow.dispatchPolicy.mode inherit
 ```
 
+If no managed policy, legacy cap, or inherit/default mode resolves during an
+implementation preflight, the policy remains unresolved. Interactive
+implementation may ask once and persist a choice; non-interactive
+implementation blocks rather than silently falling back to host defaults.
+
 ### How enforcement works
 
 OAT applies managed policies where the provider exposes a reliable mechanism.
 Providers without an adapter receive them as advisory/unsupported.
 
-| Provider | Mechanism                 | Enforcement mode                |
-| -------- | ------------------------- | ------------------------------- |
-| Codex    | Pinned role variants      | `enforced`                      |
-| Claude   | Task `model` parameter    | `enforced`                      |
-| Cursor   | `--model` argument        | `enforced` when a cell resolves |
-| Others   | None (informational only) | `advisory` / `unsupported`      |
+| Provider | Mechanism                            | Enforcement mode                |
+| -------- | ------------------------------------ | ------------------------------- |
+| Codex    | Materialized model+effort role names | `enforced`                      |
+| Claude   | Task `model` parameter               | `enforced`                      |
+| Cursor   | `--model` argument / Task `model`    | `enforced` when a cell resolves |
+| Others   | None (informational only)            | `advisory` / `unsupported`      |
+
+Codex managed dispatch compiles an explicit `model` plus reasoning `effort`
+target into a materialized OAT role name, for example
+`oat-phase-implementer-gpt-5-6-terra-xhigh`. OAT-managed Codex roles are not
+the old hard-coded effort-only pins; they come from resolver targets, dispatch
+matrix cells, or an explicit materialization command. Base roles such as
+`oat-phase-implementer` and `oat-reviewer` are fallback paths that follow the
+provider default effort when inherit/default behavior is selected or no
+materialized target resolves.
 
-Codex uses effort (`low < medium < high < xhigh`) and pinned OAT role variants.
 Claude uses Task `model` (`haiku < sonnet < opus < fable`) and keeps
 `effort_axis=not-applicable`. Cursor and other model-arg providers use opaque
 matrix slugs; OAT validates availability when a provider oracle is available,
-but the configured matrix owns tier meaning.
+but the configured matrix owns tier meaning. For Cursor subagents, validation
+checks the model can actually be used by Task subagent dispatch, not just that
+the broad `cursor-agent models` catalog lists the slug.
+
+### Codex role materialization
+
+Use `oat providers codex materialize` when you need to materialize one
+canonical agent as a Codex role outside a full sync run:
+
+```bash
+oat providers codex materialize oat-reviewer --model gpt-5.6-terra --effort xhigh --dry-run
+oat providers codex materialize oat-phase-implementer --model gpt-5.6-terra --effort high
+```
+
+Required inputs are the canonical agent name, `--model <model-id>`, and
+`--effort <reasoning-effort>`. The command defaults to project scope, reads
+`.agents/agents/<agent-name>.md`, writes `.codex/agents/<role>.toml`, and
+upserts `.codex/config.toml` unless `--dry-run` is present. `--agent-path` can
+point at a specific canonical agent markdown file, and `--role-name` can
+override the generated role name.
+
+Normal project sync also materializes Codex roles for configured matrix targets:
+
+```bash
+oat sync --scope project
+```
 
 **Verify-on-upgrade:** when the requested tier exceeds the current orchestrator
 tier (an upgrade request), the resolver sets `verifyOnDispatch: true`. The skill
@@ -320,7 +360,7 @@ Workflow preference keys live under the `workflow.*` namespace:
 - `workflow.autoArtifactReview.plan` — boolean, default `true`. Automatically run the bounded artifact-review loop for generated `plan.md` files before implementation handoff. Set to `false` only when you intentionally want to skip the plan artifact review.
 - `workflow.autoArtifactReview.analysis` — boolean, default `true`. Automatically run the bounded accuracy-review loop for generated docs and agent-instructions analysis artifacts before the matching apply workflow consumes them.
 - `workflow.dispatchPolicy.mode` — `managed` or `inherit`. `managed` means OAT selects model/effort controls from `workflow.dispatchPolicy.policy`; `inherit` means OAT leaves controls to host/provider defaults.
-- `workflow.dispatchPolicy.policy` — `economy`, `balanced`, `high`, `frontier`, or `uncapped`. `economy` through `frontier` are capped managed policies; `uncapped` keeps OAT-managed preferred selection without provider caps.
+- `workflow.dispatchPolicy.policy` — `economy`, `balanced`, `high`, `frontier`, or `uncapped`. `economy` through `frontier` are capped managed policies; `uncapped` keeps OAT-managed preferred selection without provider caps. It is distinct from `workflow.dispatchPolicy.mode=inherit`, which leaves controls to the host/provider.
 - `workflow.dispatchCeiling.preset` — legacy compatibility alias (`balanced`, `maximum`, or `cost-conscious`) for capped managed policy setup.
 - `workflow.dispatchCeiling.providers.<provider>` — dispatch matrix provider column or legacy bare provider target.
 - `workflow.dispatchCeiling.providers.<provider>.<tier>` — one matrix cell for `economy`, `balanced`, `high`, or `frontier`.

package/assets/docs/provider-sync/config.md

@@ -95,7 +95,11 @@ canonical `.agents/skills` inventory.
   - unset: provider falls back to directory detection.
 - `defaultStrategy` is used when no provider-specific `strategy` is set.
 - At runtime, config is normalized so `providers` is always present in memory.
-- Codex project sync also manages generated role variants derived from canonical agents. `oat-phase-implementer-low|medium|high|xhigh` and `oat-reviewer-low|medium|high|xhigh` are managed outputs used by dispatch-ceiling-aware implementation. They should not be adopted as stray roles.
+- Codex project sync also manages generated materialized roles derived from
+  canonical agents and explicit model+effort targets. Dispatch-aware roles such
+  as `oat-phase-implementer-gpt-5-6-terra-xhigh` and
+  `oat-reviewer-gpt-5-6-terra-xhigh` are managed outputs and should not be
+  adopted as stray roles.
 
 ## Recommended management flow
 

package/assets/docs/provider-sync/manifest-and-drift.md

@@ -69,7 +69,12 @@ After adoption, `oat sync` regenerates the managed provider copies from the cano
 
 ### Generated provider roles
 
-Some Codex roles are **generated-derived** — produced by the Codex sync extension rather than mapped 1:1 from a canonical `.agents/agents/*.md` file. The effort-specific implementer variants (`oat-phase-implementer-low`, `oat-phase-implementer-medium`, `oat-phase-implementer-high`) are the current example.
+Some Codex roles are **generated-derived** - produced by the Codex sync
+extension rather than mapped 1:1 from a canonical `.agents/agents/*.md` file.
+Materialized dispatch roles are the current example: a matrix target or
+`oat providers codex materialize` command supplies a canonical agent, model, and
+reasoning effort, and OAT writes a role such as
+`oat-phase-implementer-gpt-5-6-terra-xhigh`.
 
 `oat status` and `oat init` treat any role listed in the Codex extension plan's `managedRoles` set as managed, so generated variants are **not** reported as `stray` and are **not** offered for adoption — even though they have no canonical `.agents` source. A genuinely orphaned Codex role (no canonical source and not in `managedRoles`) is still flagged.
 

package/assets/docs/provider-sync/providers.md

@@ -18,6 +18,8 @@ description: 'Provider-specific path mappings for Claude, Cursor, Copilot, Gemin
     - Project: `.agents/skills` -> `.cursor/skills`, `.agents/agents` -> `.cursor/agents`, `.agents/rules` -> `.cursor/rules`
     - User: `~/.agents/skills` -> `~/.cursor/skills`, `~/.agents/agents` -> `~/.cursor/agents`
     - Subagent invocation in Cursor is prompt-driven (`/name` or natural mention), not `subagent_type`
+    - OAT-controlled Cursor dispatch uses the generic `.cursor/agents/<name>.md` file plus the Task-level `model` argument selected from the dispatch matrix. A `model` frontmatter value is only a default/fallback mechanism.
+    - Cursor model validation checks whether the selected model is eligible for subagent Task dispatch; the broad `cursor-agent models` catalog alone is not enough proof.
     - Rule files render as `.cursor/rules/*.mdc`
 
 === "Copilot"
@@ -42,9 +44,10 @@ description: 'Provider-specific path mappings for Claude, Cursor, Copilot, Gemin
       - `.codex/agents/<role>.toml`
       - `.codex/config.toml` (`[features] multi_agent = true`, `[agents.<role>]` upserts)
     - Codex role files include OAT managed provenance headers and are regenerated by `oat sync --scope project`
-    - The Codex sync extension also generates effort-specific implementer role variants — `oat-phase-implementer-low`, `oat-phase-implementer-medium`, `oat-phase-implementer-high`, each setting `model_reasoning_effort` — alongside the canonical-derived roles; the base `oat-phase-implementer` role represents inherited effort. These generated variants are managed by `oat sync` and are not treated as strays (see Manifest and Drift → Generated provider roles)
+    - The Codex sync extension also generates materialized roles from explicit model+effort targets, such as `oat-phase-implementer-gpt-5-6-terra-xhigh` or `oat-reviewer-gpt-5-6-terra-xhigh`, alongside canonical-derived base roles. These generated variants are managed by `oat sync` and are not treated as strays (see Manifest and Drift -> Generated provider roles)
+    - A single role can be materialized directly with `oat providers codex materialize <agent-name> --model <model-id> --effort <reasoning-effort>`; `--agent-path` selects a specific canonical markdown agent, `--role-name` overrides the generated role name, and `--scope user` writes a one-off user-scope role.
     - Aggregate Codex config drift metadata (`aggregateConfigHash`) is emitted in sync/status codex extension output and intentionally not stored as a separate manifest row
-    - User-scope Codex role generation (`~/.codex`) remains deferred
+    - User-scope Codex role generation via provider sync (`~/.codex`) remains deferred
     - Codex multi-agent dispatch uses config-defined roles (`[agents.<name>]`) and `agent_type`
     - Codex subagent workflows require `[features] multi_agent = true` in active Codex config layers
 
@@ -53,7 +56,7 @@ description: 'Provider-specific path mappings for Claude, Cursor, Copilot, Gemin
 - Project scope: skills + agents + rules
 - User scope: skills + agents (provider mappings vary by adapter)
 - Rules are project-scoped only in this release
-- Codex user-scope role generation under `~/.codex` remains deferred in this release
+- Codex user-scope role generation under `~/.codex` via provider sync remains deferred in this release; direct one-off materialization can use `--scope user`
 
 ## Adoption model
 

package/assets/docs/provider-sync/scope-and-surface.md

@@ -34,6 +34,7 @@ Rules are currently project-scoped canonical content. Unlike skills and agents,
 - `oat providers list`
 - `oat providers inspect`
 - `oat providers set`
+- `oat providers codex materialize`
 
 ## Adjacent CLI commands (commonly used with provider interop)
 
@@ -46,7 +47,7 @@ Rules are currently project-scoped canonical content. Unlike skills and agents,
 - Project provider enablement is stored in `.oat/sync/config.json` (`providers.<name>.enabled`).
 - `oat init --scope project` (interactive) prompts for supported providers and persists explicit true/false values.
 - `oat sync --scope project` uses config-aware provider activation and can prompt to remediate detected mismatches.
-- Codex project-scope subagent sync is generated output (`.codex/agents/*.toml` + `.codex/config.toml`) computed at command layer after path-mapping sync. Generated Codex roles — including the effort-specific implementer variants — are tracked as managed by `oat status` and `oat init`, not as strays.
+- Codex project-scope subagent sync is generated output (`.codex/agents/*.toml` + `.codex/config.toml`) computed at command layer after path-mapping sync. Generated Codex roles - including materialized model+effort implementer and reviewer variants - are tracked as managed by `oat status` and `oat init`, not as strays.
 - Codex aggregate config drift is reported via sync/status extension metadata (`aggregateConfigHash`); it is not persisted as a separate manifest schema entry.
 - Codex user-scope role generation remains intentionally deferred in this release.
 

package/assets/docs/reference/oat-directory-structure.md

@@ -107,9 +107,9 @@ Current schema keys:
 | `git.defaultBranch`                         | `string`   | `"main"`                 | Default branch for PR creation. Auto-detected during `oat init` via `gh repo view` or `origin/HEAD`. Used by `oat-project-pr-final` and `oat-project-pr-progress`.                                                                                                                                      |
 | `workflow.autoReviewAtHillCheckpoints`      | `boolean`  | unset                    | When `true`, completing a HiLL checkpoint automatically runs the extra lifecycle review. Does not control Tier 1 per-phase `oat-reviewer` gates. Can be overridden per-project via `oat_auto_review_at_hill_checkpoints` in `plan.md` frontmatter. Legacy `autoReviewAtCheckpoints` remains a fallback. |
 | `workflow.dispatchPolicy.mode`              | `string`   | unset                    | Dispatch policy mode: `managed` lets OAT select model/effort controls; `inherit` leaves controls to the host/provider defaults.                                                                                                                                                                         |
-| `workflow.dispatchPolicy.policy`            | `string`   | unset                    | Managed dispatch policy: `economy`, `balanced`, `high`, `frontier`, or `uncapped`. Capped policies compile to provider targets; `uncapped` keeps OAT-managed preferred selection without provider caps.                                                                                                 |
+| `workflow.dispatchPolicy.policy`            | `string`   | unset                    | Managed dispatch policy: `economy`, `balanced`, `high`, `frontier`, or `uncapped`. Capped policies compile to provider targets; `uncapped` keeps OAT-managed preferred selection without provider caps. `inherit` mode is separate and leaves controls to the host/provider.                            |
 | `workflow.dispatchCeiling.preset`           | `string`   | unset                    | Legacy compatibility preset for capped managed policy setup (`balanced`, `maximum`, `cost-conscious`). `maximum` maps to `high`; `cost-conscious` maps to `economy`.                                                                                                                                    |
-| `workflow.dispatchCeiling.providers.codex`  | `string`   | unset                    | Legacy concrete Codex capped target (`low`, `medium`, `high`, or `xhigh`). Codex provider default effort is informational only for explicit inherit/default behavior or base/unpinned fallback paths.                                                                                                   |
+| `workflow.dispatchCeiling.providers.codex`  | `string`   | unset                    | Legacy concrete Codex capped target (`low`, `medium`, `high`, or `xhigh`). New managed Codex dispatch resolves explicit model+effort targets to materialized role names; provider default effort is informational only for explicit inherit/default behavior or base/unpinned fallback paths.           |
 | `workflow.dispatchCeiling.providers.claude` | `string`   | unset                    | Legacy concrete Claude capped target (`haiku`, `sonnet`, `opus`, or `fable`). Claude has no separate per-dispatch effort axis. The flat keys `workflow.dispatchCeiling.codex` and `workflow.dispatchCeiling.claude` were removed (no migration).                                                        |
 | `workflow.gates.skills`                     | `object`   | unset                    | Per-skill final gate config keyed by skill name. Managed with `oat gate set/unset`; gate-aware skills declare `oat_gateable: true`.                                                                                                                                                                     |
 | `workflow.gates.execTargets`                | `object`   | built-ins                | Cross-runtime exec target registry keyed by opaque target id. Managed with `oat gate target set/unset`; built-ins cover Codex, Claude, and Cursor defaults.                                                                                                                                             |

package/assets/docs/workflows/projects/dispatch-ceiling.md

@@ -28,18 +28,20 @@ per-tier value, or an ordered route for escalation.
 
 ## Policy Choices
 
-| Policy                  | Mode    | Codex target | Claude target | Meaning                                      |
-| ----------------------- | ------- | ------------ | ------------- | -------------------------------------------- |
-| `Economy`               | managed | `medium`     | `sonnet`      | Lower-cost managed cap                       |
-| `Balanced`              | managed | `high`       | `sonnet`      | Default managed cap                          |
-| `High`                  | managed | `xhigh`      | `opus`        | High-capability managed cap                  |
-| `Frontier`              | managed | `xhigh`      | `fable`       | Top managed tier currently exposed by OAT    |
-| `Uncapped`              | managed | none         | none          | OAT selects preferred controls without a cap |
-| `Inherit Host Defaults` | inherit | none         | none          | OAT does not select model/effort controls    |
+| Policy                  | Mode    | Codex cap | Claude target | Meaning                                      |
+| ----------------------- | ------- | --------- | ------------- | -------------------------------------------- |
+| `Economy`               | managed | `medium`  | `sonnet`      | Lower-cost managed cap                       |
+| `Balanced`              | managed | `high`    | `sonnet`      | Default managed cap                          |
+| `High`                  | managed | `xhigh`   | `opus`        | High-capability managed cap                  |
+| `Frontier`              | managed | `xhigh`   | `fable`       | Top managed tier currently exposed by OAT    |
+| `Uncapped`              | managed | none      | none          | OAT selects preferred controls without a cap |
+| `Inherit Host Defaults` | inherit | none      | none          | OAT does not select model/effort controls    |
 
 `Uncapped` is explicit managed state. It is not represented by omitting policy
 state. Existing projects with absent legacy ceiling state remain unresolved or
-legacy-compatible; they do not silently become managed `Uncapped`.
+legacy-compatible; they do not silently become managed `Uncapped`. `Unresolved`
+is a deferral state for planning/preflight only. Implementation preflight must
+resolve a managed policy or inherit/default mode before work starts.
 
 ## Config Shapes
 
@@ -173,18 +175,25 @@ Selection modes:
 
 ## Provider Behavior
 
-|                   | Codex                                       | Claude Code                             | Cursor / model-arg providers | Unsupported provider |
-| ----------------- | ------------------------------------------- | --------------------------------------- | ---------------------------- | -------------------- |
-| Managed mechanism | Pinned role variants                        | Task `model` argument                   | `--model` argument           | None                 |
-| Axis              | effort (`low < medium < high < xhigh`)      | model (`haiku < sonnet < opus < fable`) | opaque model slug            | None                 |
-| Capped policy     | selected pinned variant up to cap           | selected Task model up to cap           | selected matrix cell         | advisory/unsupported |
-| Uncapped          | preferred pinned variant, no cap            | preferred Task model, no cap            | preferred matrix cell        | advisory/unsupported |
-| Inherit/default   | base/unpinned role follows provider default | omit `model`                            | omit `--model`               | normal behavior      |
-
-Codex uses pinned variants because per-call effort controls were unreliable in
-dogfooding. For managed `Uncapped`, OAT still selects the preferred pinned
-variant; the dispatching host should verify whether upward effort selection is
-actually honored in the current session.
+|                   | Codex                                                 | Claude Code                             | Cursor / model-arg providers | Unsupported provider |
+| ----------------- | ----------------------------------------------------- | --------------------------------------- | ---------------------------- | -------------------- |
+| Managed mechanism | Materialized roles with explicit `model` and `effort` | Task `model` argument                   | Task/CLI `model` argument    | None                 |
+| Axis              | model plus effort (`low < medium < high < xhigh`)     | model (`haiku < sonnet < opus < fable`) | opaque model slug            | None                 |
+| Capped policy     | materialized target selected up to cap                | selected Task model up to cap           | selected matrix cell         | advisory/unsupported |
+| Uncapped          | preferred materialized target, no cap                 | preferred Task model, no cap            | preferred matrix cell        | advisory/unsupported |
+| Inherit/default   | base/unpinned role follows provider default           | omit `model`                            | omit model selection         | normal behavior      |
+
+Codex uses materialized roles because per-call model/effort controls were
+unreliable in dogfooding. The resolver compiles an explicit model+effort target
+into a role name such as `oat-phase-implementer-gpt-5-6-terra-xhigh`, and the
+Codex spawn payload uses that role as `agent_type`. For managed `Uncapped`, OAT
+still selects the preferred materialized target. If the Codex preferred value is
+an effort rather than a matrix tier, OAT looks up the highest managed tier that
+compiles to that effort before resolving the matrix target; for example,
+`--preferred xhigh` resolves through the `frontier` matrix cell. The dispatching
+host should verify whether upward effort selection is actually honored in the
+current session. The old effort-only Codex pins are not the managed dispatch
+contract for new projects.
 
 Claude Code uses the per-call Task `model` argument. It has no OAT-managed
 per-dispatch effort axis, so dispatch logs use `effort_axis=not-applicable`.
@@ -192,7 +201,10 @@ per-dispatch effort axis, so dispatch logs use `effort_axis=not-applicable`.
 
 Cursor and other model-arg providers use matrix values as opaque slugs. OAT
 validates availability with provider oracles when possible, but tier semantics
-come from the configured matrix, not from a built-in model catalog.
+come from the configured matrix, not from a built-in model catalog. For Cursor,
+that validation checks subagent Task eligibility, not just broad catalog
+visibility, because a slug can appear in `cursor-agent models` and still be
+rejected for subagent dispatch.
 
 ## Producer Provenance
 
@@ -205,9 +217,10 @@ Dispatch: scope=p06 action=implementation role=implementer producer=gpt-5.5-xhig
 
 `producer` is the resolved model slug when OAT knows it, otherwise `unknown`.
 `provenance` is one of `declared`, `observed`, `inferred`, or `unknown`.
-Concrete same-harness model arguments can be declared. Codex pinned effort
-variants declare effort, not concrete producer identity, unless an observed or
-inferred model is available.
+Concrete same-harness model arguments can be declared. Codex materialized
+model+effort roles declare `model_axis=selected:<model>` and
+`effort_axis=selected:<effort>` from resolver output, but producer identity
+remains `unknown` unless an observed or inferred model identity is available.
 
 ## Implementer, Fix, and Reviewer Behavior
 
@@ -234,9 +247,9 @@ say `provider-default`.
 Examples:
 
 ```text
-Dispatch policy: balanced; selected=high; cap=high (codex, enforced — variant oat-phase-implementer-high)
-Dispatch policy: high; selected=xhigh; cap=xhigh (codex, enforced — variant oat-reviewer-xhigh)
-Dispatch policy: uncapped; selected=xhigh; cap=none (codex, enforced — variant oat-phase-implementer-xhigh)
+Dispatch policy: balanced; selected=high; cap=high (codex, enforced — variant oat-phase-implementer-gpt-5-6-terra-high)
+Dispatch policy: high; selected=xhigh; cap=xhigh (codex, enforced — variant oat-reviewer-gpt-5-6-terra-xhigh)
+Dispatch policy: uncapped; selected=xhigh; cap=none (codex, enforced — variant oat-phase-implementer-gpt-5-6-sol-xhigh)
 Dispatch policy: inherit host defaults; selected=none; cap=none (codex, advisory — base role follows provider default)
 Dispatch policy: frontier; selected=fable; cap=fable (claude, enforced — Task model arg)
 ```

package/assets/docs/workflows/projects/implementation-execution.md

@@ -70,16 +70,16 @@ Runtime dispatch reads the resolved policy and provider-specific selection only.
 For Codex, provider default effort is displayed when available but is not treated as managed `Uncapped` or as a cap. Provider defaults apply only to explicit inherit/default behavior or base/unpinned fallback paths.
 
 ```text
-Dispatch policy: balanced (codex, managed capped — pinned-variant)
+Dispatch policy: balanced (codex, managed capped — materialized-role)
 Resolved cap: high
 Source: project state
 Provider default effort: medium
-Note: OAT will use pinned subagent variants up to high. Base/unpinned roles resolve through the provider default only on fallback paths.
+Note: OAT will use resolver-returned materialized Codex role names up to high. Base/unpinned roles resolve through the provider default only on fallback paths.
 ```
 
 **Enforcement modes** (from resolver):
 
-- `enforced` — the adapter compiled concrete dispatch args and the provider accepted them (Codex: pinned variants; Claude: Task `model` parameter).
+- `enforced` — the adapter compiled concrete dispatch args and the provider accepted them (Codex: materialized model+effort roles; Claude: Task `model` parameter).
 - `advisory` — the provider is supported but no value resolved, or an upgrade request was not honored by the provider.
 - `unsupported` — the provider has no registered adapter; the policy is informational only. Dispatch follows provider behavior.
 
@@ -112,7 +112,14 @@ Model and effort are separate axes. Each axis logs one of these states:
 - `not-applicable` — this host/API has no meaningful per-dispatch concept for that axis.
 - `host-auto` — exceptional; the host uses that axis internally but the orchestrator cannot read or pin it.
 
-In Codex, implementation and fix dispatch classify a preferred effort (`low`, `medium`, `high`, or `xhigh`) and pass it to `oat project dispatch-ceiling resolve --provider codex --role implementer --preferred <effort>`. For capped managed policies, the resolver selects `min(preferred, resolved_cap)` and returns the matching pinned role. For managed `Uncapped`, the resolver selects the preferred pinned role with no cap. For inherit/default mode, it returns no pinned role and OAT uses the base/unpinned role. Reviewer dispatch targets the configured cap only when a capped managed policy exists; managed `Uncapped` and inherit/default use base `oat-reviewer` fallback.
+In Codex, implementation and fix dispatch classify a preferred effort (`low`, `medium`, `high`, or `xhigh`) and pass it to `oat project dispatch-ceiling resolve --provider codex --role implementer --preferred <effort>`. For capped managed policies, the resolver selects `min(preferred, resolved_cap)` and returns a materialized role name compiled from an explicit model+effort target. For managed `Uncapped`, the resolver selects the preferred materialized role with no cap. For inherit/default mode, it returns no materialized role and OAT uses the base/unpinned role. Reviewer dispatch targets the configured cap only when a capped managed policy exists; managed `Uncapped` and inherit/default use base `oat-reviewer` fallback.
+
+Because Codex preferred values are effort names while dispatch matrix cells are
+keyed by OAT tiers, managed `Uncapped` maps preferred efforts through the
+managed tier table before resolving matrix targets. For example, `xhigh` maps to
+the highest matching tier, `frontier`, so `--preferred xhigh` can resolve a
+`frontier` Codex matrix target such as
+`oat-phase-implementer-gpt-5-6-sol-xhigh`.
 
 In Claude Code, implementation and fix dispatch classify a preferred model tier (`haiku`, `sonnet`, `opus`, or `fable`) and pass it to `oat project dispatch-ceiling resolve --provider claude --role implementer --preferred <model> --orchestrator-tier <current-orchestrator-tier>`. Capped policies select `min(preferred, resolved_cap)`, managed `Uncapped` selects the preferred model, and inherit/default omits `model`. Reviewer dispatch passes a `model` only when the resolver returns one. The separate effort axis is `not-applicable`.
 
@@ -135,9 +142,9 @@ Selected effort: medium
 Policy source: repo config
 Provider default effort: high
 Selection mode: capped
-Model axis: inherited
+Model axis: selected:gpt-5.6-terra
 Effort axis: selected:medium
-Dispatch target: oat-phase-implementer-medium
+Dispatch target: oat-phase-implementer-gpt-5-6-terra-medium
 Rationale: shared TypeScript/config substrate; high preferred due to integration risk, capped by configured policy.
 
 OAT Dispatch: Phase p03 review
@@ -148,9 +155,9 @@ Selected effort: xhigh
 Policy source: project state
 Provider default effort: medium
 Selection mode: review-target
-Model axis: inherited
+Model axis: selected:gpt-5.6-terra
 Effort axis: selected:xhigh
-Dispatch target: oat-reviewer-xhigh
+Dispatch target: oat-reviewer-gpt-5-6-terra-xhigh
 Rationale: reviewer runs at the configured policy cap for deterministic quality gate behavior.
 
 OAT Dispatch: Phase p03 implementation
@@ -162,10 +169,10 @@ Selected effort: xhigh
 Policy source: project state
 Provider default effort: medium
 Selection mode: uncapped
-Model axis: inherited
+Model axis: selected:gpt-5.6-sol
 Effort axis: selected:xhigh
-Dispatch target: oat-phase-implementer-xhigh
-Rationale: high-risk phase; managed uncapped policy allows the preferred pinned variant.
+Dispatch target: oat-phase-implementer-gpt-5-6-sol-xhigh
+Rationale: high-risk phase; managed uncapped policy allows the preferred materialized target.
 
 OAT Dispatch: Phase p04 implementation
 Host: Other
@@ -203,10 +210,10 @@ Add Dispatch Profile rows only when the user has an explicit constraint or prefe
 For each phase in the plan (whether sequential or inside a parallel group):
 
 1. **Select runtime dispatch control** for the phase and log the chosen control plus rationale.
-2. **Dispatch the selected implementer role** with a Phase Scope block (project path, phase id, artifact paths, commit convention, workflow mode, and dispatch context when known). In Codex, `effort_axis=selected:low|medium|high|xhigh` uses `oat-phase-implementer-low|medium|high|xhigh`. Base `oat-phase-implementer` means provider-default/unpinned fallback.
+2. **Dispatch the selected implementer role** with a Phase Scope block (project path, phase id, artifact paths, commit convention, workflow mode, and dispatch context when known). In Codex, selected model+effort axes use the resolver-returned materialized role name, such as `oat-phase-implementer-gpt-5-6-terra-xhigh`. Base `oat-phase-implementer` means provider-default/unpinned fallback.
 3. **Receive the summary:** `DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED`.
    - `BLOCKED` stops the run and surfaces the blocker to the user.
-4. **Dispatch the selected reviewer role** with a Review Scope block (phase id, commit range, optional files-changed hint, and dispatch context). The commit range is authoritative; the file list is only orientation metadata. In Codex, pass this as a self-contained packet with `fork_context: false`; use an `oat-reviewer-<value>` variant only for capped managed policies, and use base `oat-reviewer` for managed `Uncapped` or inherit/default. In Claude Code, pass a review `model` only when the resolver returns one and always record `effort_axis=not-applicable`. If the reviewer does not conclude on the first wait, poll once more, then send a concise "return now with current findings" nudge before falling back inline for that phase.
+4. **Dispatch the selected reviewer role** with a Review Scope block (phase id, commit range, optional files-changed hint, and dispatch context). The commit range is authoritative; the file list is only orientation metadata. In Codex, pass this as a self-contained packet with `fork_context: false`; use the resolver-returned materialized reviewer role only for capped managed policies, and use base `oat-reviewer` for managed `Uncapped` or inherit/default. In Claude Code, pass a review `model` only when the resolver returns one and always record `effort_axis=not-applicable`. If the reviewer does not conclude on the first wait, poll once more, then send a concise "return now with current findings" nudge before falling back inline for that phase.
 5. **Parse the verdict:** zero Critical + zero Important findings → `pass`; otherwise `fail`.
 6. **On fail, run the bounded fix loop** (see below).
 7. **Update artifacts** (`implementation.md`, `plan.md` review row, `state.md`) and make the mandatory bookkeeping commit.

package/assets/public-package-versions.json

@@ -1,6 +1,6 @@
 {
-  "cli": "0.1.45",
-  "docs-config": "0.1.45",
-  "docs-theme": "0.1.45",
-  "docs-transforms": "0.1.45"
+  "cli": "0.1.46",
+  "docs-config": "0.1.46",
+  "docs-theme": "0.1.46",
+  "docs-transforms": "0.1.46"
 }