@open-agent-toolkit/cli 0.1.46 → 0.1.50

package/assets/skills/oat-project-quick-start/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-project-quick-start
-version: 2.1.11
+version: 2.1.13
 description: Use when a task is small enough for quick mode or rapid iteration is preferred. Scaffolds a lightweight OAT project from discovery directly to a runnable plan, with optional brainstorming and lightweight design.
 argument-hint: '<project-name> ["project description"]'
 oat_gateable: true
@@ -434,20 +434,54 @@ git add "$PROJECT_PATH/discovery.md" "$PROJECT_PATH/state.md"
 git diff --cached --quiet || git commit -m "chore(oat): complete quick-start discovery for {project-name}"
 ```
 
+### Step 2.9: Snapshot Explicit Phase-Review Setting Before Plan Rewrite
+
+Before any template-based create, update, replacement, or normalization of
+`"$PROJECT_PATH/plan.md"`, inspect the existing plan frontmatter and snapshot:
+
+1. The key presence of `oat_phase_review_gate` as a separate boolean. Presence
+   is not truthiness: an explicit key is authoritative regardless of validity or
+   value.
+2. When the key is present, the complete explicit value as the exact YAML
+   frontmatter entry, including its full nested mapping or scalar form. Preserve
+   enabled, disabled, selected-phase, `null`, and malformed-for-contract values
+   verbatim; do not normalize, validate, or reconstruct the value while taking
+   the snapshot.
+
+This snapshot protects a resumed explicit value from the template rewrite. Its
+explicit presence must not trigger a target probe or re-prompt, even when the
+preserved value is `null` or malformed for the phase-review contract.
+
 ### Step 3: Generate Plan Directly
 
 Create/update `"$PROJECT_PATH/plan.md"` from `.oat/templates/plan.md`.
 
+Restore the exact snapshot into the resulting `plan.md` frontmatter as part of
+the first resulting plan write, before any later frontmatter rewrite and before
+Step 3.55 invokes the shared setup contract. Carry the snapshot losslessly
+through every subsequent plan update. When the key was explicitly present, its
+complete value must still be present exactly as captured; do not probe,
+re-prompt, validate, or replace it here. When the key was absent, do not invent
+one before the shared setup contract runs.
+
 Required frontmatter updates:
 
-- `oat_status: complete`
-- `oat_ready_for: oat-project-implement`
+- `oat_status: in_progress`
+- `oat_ready_for: null`
 - `oat_phase: plan`
-- `oat_phase_status: complete`
+- `oat_phase_status: in_progress`
 - `oat_plan_source: quick`
 - `oat_import_reference: null`
 - `oat_import_source_path: null`
 - `oat_import_provider: null`
+- `oat_template: true`
+
+These values are the interruption-safe pre-review state. Here,
+`oat_template: true` marks the generated plan as still owned by the current
+planning workflow even after its substantive content has been written. If the
+skill pauses, is interrupted, or cannot resolve dispatch before Step 3.7,
+persist and commit this state. `oat-project-next` must route it back to the
+current planning workflow and cannot advance it to implementation.
 
 Plan requirements — apply `oat-project-plan-writing` canonical format invariants:
 
@@ -470,124 +504,96 @@ Required parallelism pass before finalizing the plan:
 ### Step 3.5: Resolve Dispatch Policy Before Implementation Readiness
 
 Before moving the quick project to ready-for-implementation, resolve the
-dispatch policy.
+complete dispatch ladder and the project named ceiling.
 
-Resolution order:
+Invoke the `Complete Dispatch Ladder Adoption Contract` from
+`oat-project-plan-writing`. If the effective ladder is missing or incomplete,
+show the full bundled recommendation and ask the user to select its owning
+scope before running exactly one command:
 
-1. Config keys `workflow.dispatchPolicy.mode` / `workflow.dispatchPolicy.policy` via the resolver CLI
-2. Layered dispatch matrix / compatibility config under `workflow.dispatchCeiling.providers.<provider>` and `workflow.dispatchCeiling.providers.<provider>.<tier>`
-3. Project `state.md` frontmatter key `oat_dispatch_policy`
-4. Legacy project `state.md` frontmatter key `oat_dispatch_ceiling`
-5. Interactive quick-planning prompt (below)
-6. Leave unresolved for implementation preflight when non-interactive
+```bash
+oat config adopt dispatch-matrix --shared
+oat config adopt dispatch-matrix --local
+oat config adopt dispatch-matrix --user
+```
+
+The selected scope owns only the reusable ladders. A project-specific active
+policy or ceiling must not be written to user `~/.oat/config.json`.
+Adoption preserves explicit cells, so re-run the resolver and completeness
+check. An incomplete or missing ladder after adoption blocks readiness; do not
+overwrite explicit cells or silently infer a fallback. Non-interactive setup
+also blocks on a missing or incomplete ladder.
+
+Then resolve the named ceiling in this order:
 
-If no policy resolves and the session is interactive, present the dispatch
-policy prompt once before finalizing `plan.md`:
+1. Project `state.md` frontmatter `oat_dispatch_policy`
+2. Legacy project `oat_dispatch_ceiling`
+3. Config `workflow.dispatchPolicy.*` as a proposed starting value
+4. Interactive quick-planning prompt
+5. Unresolved non-interactive state blocks implementation readiness
 
-Generate the choice text from canonical CLI metadata immediately before
-presenting it:
+Generate the canonical prompt with:
 
 ```bash
 oat project dispatch-ceiling choices --format markdown
 ```
 
-Do not hand-type the dispatch policy menu or omit canonical choices. If the CLI
-is unavailable in this environment, derive the same labels and descriptions from
-`packages/cli/src/config/dispatch-policy-options.ts`; include every managed
-policy returned by `VALID_MANAGED_DISPATCH_POLICIES` plus `Uncapped`, `Inherit
-Host Defaults`, and `Leave Unresolved`.
-
-At minimum, preserve these semantics in any fallback text:
-
-- `Uncapped`: OAT still manages dispatch selection, but stores no maximum cap.
-  It is not host/default behavior and must not be represented by absent policy
-  state.
-- `Inherit Host Defaults`: OAT does not choose model or effort controls; the
-  executing host/provider owns implementation, fix, and review defaults.
-- `Leave Unresolved`: planning/preflight deferral only. It records no runtime
-  policy. Implementation preflight must block until a policy resolves.
-
-OAT applies managed policies where the provider exposes a reliable mechanism
-(Codex: pinned variants; Claude: Task model parameter). Other providers may
-treat managed policies as advisory until their provider column has a resolvable
-matrix cell.
-
-For multi-family providers such as Cursor, these options choose the abstract
-policy rung; concrete model values live in the dispatch matrix under
-`workflow.dispatchCeiling.providers.*`. If the user wants OAT's recommended
-starting matrix, offer `oat config adopt dispatch-matrix` for the chosen config
-layer before finalizing `plan.md`.
-
-**Managed capped policy selection** persists `mode: managed`,
-`policy`, and the compiled provider targets. On selection, print the exact
-compiled result (e.g., "Dispatch policy set: balanced → Codex: high · Claude:
-sonnet") before proceeding.
-
-If the resolver reports that the selected policy has a missing matrix cell for
-the active provider/tier, run prompt-and-persist once before final review:
-
-1. Ask for the exact provider value for the missing cell, using the provider's
-   native vocabulary (for example, `composer-2.5`, `gpt-5.5-xhigh`, `opus`, or
-   `xhigh`), or an ordered route when escalation needs multiple targets.
-2. Persist the answer to the selected config layer with
-   `workflow.dispatchCeiling.providers.<provider>.<tier>`. Use project
-   `state.md` only for sparse project-specific matrix overrides.
-3. Re-run the resolver. Do not silently treat a missing cell as uncapped,
-   inherited, or provider-default behavior.
-
-**Uncapped** persists explicit managed uncapped state. OAT still manages
-dispatch selection. It does not write provider caps, and it must not be
-represented by leaving dispatch policy state absent.
-
-**Inherit Host Defaults** persists explicit inherit/default state. Use this only
-when the user wants OAT to leave implementation, fix, and review model/effort
-controls to the executing host/provider. OAT does not choose model or effort in
-this mode.
-
-**Leave Unresolved** leaves dispatch policy unset for implementation preflight.
-Use this only when non-interactive planning cannot choose a policy yet.
-Implementation preflight must block until a policy resolves.
-
-Persist the answer in `"$PROJECT_PATH/state.md"` frontmatter using the
-normalized shape:
+Do not hand-type the dispatch policy menu.
+`Uncapped`: OAT still manages dispatch selection. It has no named maximum.
+`Inherit Host Defaults`: OAT does not choose model or effort.
+`Leave Unresolved` is a planning deferral.
+Implementation preflight must block until a runnable ceiling resolves.
 
-```yaml
-oat_dispatch_policy:
-  mode: managed
-  policy: balanced
-  providers:
-    codex: high
-    claude: sonnet
-  source: project-state
-```
-
-For `Uncapped`:
+The menu includes every named tier plus `Uncapped`, `Inherit Host
+Defaults`, and `Leave Unresolved`. A named tier is a maximum, never an
+enduring exact model-family or effort preference. A named `High` ceiling
+keeps lower configured `Economy`, `Balanced`, and `High` candidates
+available at or below that maximum. An optional phase Dispatch Profile may
+narrow the maximum.
 
 ```yaml
 oat_dispatch_policy:
   mode: managed
-  policy: uncapped
+  policy: high
   source: project-state
 ```
 
-For `Inherit Host Defaults`:
+Persist the active project ceiling only in `"$PROJECT_PATH/state.md"`. Do not
+copy compiled provider targets into this shape or user config. `Uncapped` and
+`Inherit Host Defaults` remain explicit modes; `Leave Unresolved` and
+non-interactive unresolved state are not implementation-ready.
 
-```yaml
-oat_dispatch_policy:
-  mode: inherit
-  source: project-state
-```
+### Step 3.55: Configure Optional Phase Review
+
+After the generated quick plan has stable phase IDs and before Step 3.6 starts
+the plan artifact review, invoke the `Shared Phase-Review Setup Contract` from
+`oat-project-plan-writing`.
 
-Do not prompt when `OAT_NON_INTERACTIVE=1` or when no user-response channel
-exists. In that case, leave the value unresolved. `oat-project-implement`
-must block before work starts if it still cannot resolve a policy.
+If `plan.md` already contains an explicit `oat_phase_review_gate`, preserve it
+through the shared contract without probing, prompting, or mutation. Otherwise
+let the contract probe qualifying targets and offer all phases, selected
+phases, or disabled. If the probe fails, no target qualifies, or the user
+declines, leave phase review disabled and continue with the contract's concise
+status output.
 
-Do not treat provider default effort as the OAT dispatch policy. Provider
-defaults apply only for explicit inherit/default behavior or base/unpinned
-fallback paths.
+This phase-review setup is independent from HiLL checkpoints. Do not read or
+change HiLL fields here, and do not add a provider/model `--target` to any
+lifecycle command.
 
 ### Step 3.6: Run Plan Artifact Review Loop
 
+Before dispatching the artifact reviewer, invoke the `Managed Dispatch
+Readiness and Review Contract` from `oat-project-plan-writing`:
+
+```bash
+oat project dispatch-ceiling resolve --provider "$ACTIVE_PROVIDER" --role reviewer --preflight --json
+```
+
+If managed resolution or the complete ladder is unresolved, return to Step
+3.5, adopt the recommendation in the selected ownership scope, and re-run the
+resolver. Do not hand the quick plan to implementation while either contract is
+unresolved.
+
 Invoke the shared `Auto Artifact-Review Loop` from `oat-project-plan-writing` with target `plan` before syncing project state or handing off to implementation.
 
 Required payload:
@@ -602,11 +608,44 @@ Apply the shared loop exactly:
 
 - Resolve `workflow.autoArtifactReview.plan`; only an explicit `false` skips the loop.
 - Resolve `oat_orchestration_retry_limit` from project state, defaulting to `2`.
-- Dispatch `oat-reviewer` in structured mode using Tier 1 subagent when available and Tier 2 inline fallback otherwise.
+- For a concrete managed target, dispatch the exact registered reviewer role. If the host cannot select it, launch a fresh Codex child pinned to the resolved model and reasoning effort with the canonical reviewer instructions.
+- For Claude or Cursor, pass the exact resolver-returned
+  `providers.<provider>.dispatchArgs.model` as the actual invocation's model
+  argument. Preserve the same complete payload on timeout and retry; Cursor
+  strings remain opaque.
+- Run inline only with verified equivalent current-host model and effort controls, or for explicit inherit/default behavior or the managed-uncapped reviewer exception. If none applies, fail closed before artifact review.
+- If the reviewer times out or does not conclude, poll and nudge once, then retry the same exact role or pinned child within the retry bound. If that target-preserving retry still fails, fail closed; never downgrade the review to inline.
 - Apply Critical and Important artifact-local fixes when unambiguous; offer Medium and Minor fixes instead of silently applying them.
 - Re-dispatch after rewrites until clean or the retry bound is exhausted.
 - Update the `plan` artifact row in the `## Reviews` table to `passed` when clean. If residual findings remain, preserve the row and surface the residual findings before downstream handoff.
 
+### Step 3.7: Record Review Disposition and Mark Plan Complete
+
+Before changing readiness, durably record the review outcome in `plan.md`:
+
+- When review ran, update the `plan` review row in the `## Reviews` section to
+  the outcome reached by Step 3.6. Use `passed` only for a clean result. If
+  residual findings remain, retain their actual non-passed status and add a
+  concise residual-finding disposition in the same section.
+- When `workflow.autoArtifactReview.plan` is explicitly `false`, record the
+  explicit skip in the `## Reviews` section as
+  `Plan artifact review: skipped (workflow.autoArtifactReview.plan=false)`.
+  Do not claim that the plan passed review.
+
+The review row or explicit skip must be written to `plan.md`; chat or status
+output alone is not durable. Only after that write succeeds, atomically update
+the plan frontmatter:
+
+- `oat_status: complete`
+- `oat_ready_for: oat-project-implement`
+- `oat_phase_status: complete`
+- `oat_template: false`
+
+If dispatch remains unresolved, review execution fails closed, or the outcome
+cannot be recorded, leave the Step 3 pre-review values unchanged and commit
+them before stopping. Never expose a partially reviewed quick plan to
+`oat-project-implement`.
+
 ### Step 4: Sync Project State
 
 Update `"$PROJECT_PATH/state.md"`:
@@ -666,18 +705,29 @@ Before reporting this skill as complete, run the configured gate as the final st
 
    If the command returns JSON `null`, no gate is configured; the skill is complete.
 
-2. If a gate config is returned, run its `command` exactly as configured. Capture stdout, stderr, and the exit code. A zero exit code means the gate passed and the skill is complete.
+2. Export the resolved project path into the command shell:
+
+   ```bash
+   export PROJECT_PATH
+   ```
+
+   If the resolved command invokes `oat gate review`, the configured review command must already include `--project "$PROJECT_PATH"` and must not include `--target <id>`. A valid reusable shape is `oat gate review --project "$PROJECT_PATH" ...`. If the declaration is missing, stop and migrate the stored gate command; do not inject or append arguments at execution time.
+
+3. Execute the resolved command exactly as configured. Capture stdout, stderr, the exit code, and the structured JSON result. A zero exit code means the review passed its threshold, but it does not by itself authorize artifact receipt or complete the handoff.
 
-3. Review-artifact handoff:
-   - If the gate reports a produced review artifact, the host must run `oat-project-review-receive` to receive and disposition that artifact before treating the review as consumed.
-   - This applies to `oat gate review ...` outputs regardless of whether the gate ultimately exits zero or nonzero; the command output owns the exact artifact path, and receive-review owns disposition and archival.
+4. Review-artifact handoff:
+   - Parse the structured gate result. An exit code or artifact path alone never authorizes `oat-project-review-receive`.
+   - Invoke receive only when all three conditions hold: `status` is `ok` or `blocked`, the envelope explicitly sets `receiveEligible: true`, and a non-null `handoff` confirms the artifact was corroborated.
+   - `receiveEligible: false` is a hard stop even when `artifactPath` is present. Never receive `targeting_correlation_failed`; correct the project/run routing and run a new gate.
+   - Keep `artifact_validation_failed` outside receive until the artifact is corrected and the gate successfully revalidates it. Treat `review_failed`, unknown statuses, null handoffs, and contradictory eligibility fields as operational failures.
+   - `blocked` exits nonzero but is receive-eligible; `ok` exits zero and still requires durable receive disposition. Route by structured status and eligibility, not by exit code.
 
-4. If the command exits nonzero, use `description` to orient the next steps and handle `onFailure`:
+5. If the command exits nonzero, use `description` to orient the next steps and handle `onFailure`:
    - `block`: read gate feedback, remediate, and re-run the gate up to `maxAttempts` attempts (default `2`). If attempts are exhausted, escalate to the human with accumulated feedback and append that feedback to `implementation.md`. Treat a launch failure, missing CLI, or no eligible runtime as escalation-biased and do not spend it as a remediation attempt.
    - `prompt`: surface the gate failure and ask the human how to proceed.
    - `warn`: record the gate failure and continue.
 
-5. Runtime selection note (V1): the step runs the gate `command` as-is and reads no OAT runtime env var. By default, `oat gate review` and `oat gate cross-provider-exec` resolve the current host from built-in `hostDetectionCommand`s and avoid the same runtime when no exact target is supplied. Reusable lifecycle skill-gate commands should normally omit `--target <id>` so independent review stays provider-neutral. Use explicit targets only for manual/debug commands or deliberate local/user-specific overrides; do not hardcode provider/model targets in bundled skill guidance or shared lifecycle gate examples.
+6. Runtime selection note (V1): the step runs the gate `command` as-is and reads no OAT runtime env var. By default, `oat gate review` and `oat gate cross-provider-exec` resolve the current host from built-in `hostDetectionCommand`s and avoid the same runtime when no exact target is supplied. Reusable lifecycle skill-gate commands must not include `--target <id>` so independent review stays provider-neutral. Use explicit targets only for manual/debug commands or deliberate local/user-specific overrides; do not hardcode provider/model targets in bundled skill guidance or shared lifecycle gate examples.
 
 ### Step 7: Output Next Action
 
@@ -700,4 +750,4 @@ Report:
 - ✅ `plan.md` records the plan artifact review row unless `workflow.autoArtifactReview.plan` was explicitly disabled.
 - ✅ `implementation.md` is initialized for resumable execution.
 - ✅ Changed quick-start artifacts are committed before handoff or pause; `.oat/state.md` is refreshed locally when available.
-- ✅ Configured gate has run, and any produced review artifact has been handed off to `oat-project-review-receive` before it is treated as consumed.
+- ✅ Configured gate has run, and only a corroborated, receive-eligible artifact has been handed off to `oat-project-review-receive` before it is treated as consumed.

package/assets/skills/oat-project-review-provide/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-project-review-provide
-version: 1.3.10
+version: 1.3.13
 description: Use when the user explicitly asks to review an OAT project — e.g. "review project", "review the project", "run project review", or confirms a previously offered review. Do NOT auto-invoke on completed work alone. Resolves a project review scope and offers before running.
 disable-model-invocation: false
 user-invocable: true
@@ -31,7 +31,7 @@ Before acting, verify that there is an active OAT project or a user-provided rev
 
 When the invocation is manual, summarize the inferred review type and scope, then ask before running the review.
 
-**Gate-originated mode:** If the request context says the review is gate-originated, set `REVIEW_INVOCATION=gate`, honor any provided review type/scope arguments, and run without interactive confirmation prompts. The gate session is already the explicit authorization boundary. If subagent dispatch is unavailable, run the review inline in the current gate session instead of handing off to a fresh session.
+**Gate-originated mode:** If the request context says the review is gate-originated, set `REVIEW_INVOCATION=gate`, honor any provided review type/scope arguments, and run without interactive confirmation prompts. The gate session is already the explicit authorization boundary, but it does not waive dispatch controls. Resolve the reviewer target and use the exact registered role or explicitly pinned fresh child. Inline gate review is allowed only with verified equivalent current-host model and effort controls or a documented base-role exception; otherwise fail closed.
 
 ## Mode Assertion
 
@@ -428,23 +428,30 @@ Proceed with review?
 
 If `REVIEW_INVOCATION=gate`, print the same scope summary but do not ask `Proceed with review?`; continue directly.
 
-### Step 4.1: Dispatch Profile Override Advisory (Artifact Plan Only)
+### Step 4.1: Dispatch Profile Ceiling Advisory (Artifact Plan Only)
 
-When reviewing `artifact plan`, apply this Dispatch Profile override advisory:
+When reviewing `artifact plan`, apply this Dispatch Profile named-ceiling
+advisory:
 
 - A missing `## Dispatch Profile` section is normal and must not be flagged.
 - Important findings:
   - invalid phase ID that does not match a real plan phase
-  - unknown active-provider tier value
-  - low-tier override for multi-file integration, architecture, or review-heavy work
-  - low-tier override with missing or generic rationale
+  - unknown named ceiling or a phase ceiling above the project ceiling
+  - wording that pins an exact provider model, family, effort, or role instead
+    of a named maximum
+  - low named ceiling for multi-file integration, architecture, or review-heavy
+    work
+  - low named ceiling with missing or generic rationale
 - Medium findings:
   - malformed but recoverable Dispatch Profile table structure
-  - mid-tier override for architecture-heavy work without convincing rationale
+  - mid-tier ceiling for architecture-heavy work without convincing rationale
 - Minor findings:
   - rationale is present but weakly tied to phase scope
 
-Include this advisory in the Review Scope metadata for artifact plan reviews so the reviewer evaluates explicit override rows without treating omitted rows as a gap.
+Include this advisory in the Review Scope metadata for artifact plan reviews so
+the reviewer evaluates explicit ceiling rows without treating omitted rows as a
+gap. A named ceiling is a maximum; lower configured candidates remain eligible
+for later task selection.
 
 ### Step 4.5: Gather Deferred Findings Ledger (Final Scope Only)
 
@@ -510,6 +517,72 @@ Build the "Review Scope" metadata for the reviewer:
 
 ### Step 6: Execute Review (3-Tier Capability Model)
 
+**Step 6.0: Resolve the managed reviewer target**
+
+Before capability-tier selection, resolve the same reviewer contract used by
+plan artifact review and implementation phase/final review:
+
+```bash
+oat project dispatch-ceiling resolve --provider "$ACTIVE_PROVIDER" --role reviewer --preflight --report-scope "$SCOPE_TOKEN" --report-action review --json
+```
+
+Require `dispatchReport.schemaVersion: 1`. Render/consume the resolver's
+versioned report using `formatDispatchReport(dispatchReport)` semantics, and
+derive the formal compatibility line only with
+`formatDispatchStamp(dispatchReport)` / `toDispatchStampRecord(dispatchReport)`.
+Include that derived line in the review dispatch audit metadata; do not
+hand-assemble `Dispatch:` fields from a role name or model string.
+
+The exact managed provider target still comes from
+`providers.<provider>.dispatchArgs` plus
+`providers.<provider>.selection.target`, and the actual reviewer invocation
+must retain it byte-for-byte. The report is an audit/rendering surface, not a
+selection fallback. Configured invocation (including gate-owned immutable
+metadata), work-producer diversity, and independently observed reviewer runtime identity are distinct. Do not promote producer stamps, configured defaults, or
+reviewer self-report into `dispatchReport.runtimeIdentity`; leave it
+`not-reported` unless an independent observation exists.
+
+The reviewer resolver selects the final candidate of the configured review
+ceiling. Do not supply ephemeral implementer candidate requests for artifact,
+phase, project, or final review. A lower candidate is allowed only when a
+separate reviewed contract explicitly authorizes reviewer lowering and defines
+its bounds; a Dispatch Profile row does not authorize it.
+
+Resolve every concrete managed reviewer target before probing generic subagent
+availability or selecting Tier 1/Tier 2/Tier 3. The concrete target takes
+precedence over all availability, preference, timeout, fresh-session, and gate
+fallbacks.
+A concrete managed Codex target takes precedence over tier availability.
+Build the actual provider invocation before reporting the target as enforced:
+
+- Codex uses the exact registered reviewer role or variant from
+  `providers.codex.dispatchArgs.variant` when selectable. If the current host
+  cannot select it, launch a fresh Codex child with the resolver target's
+  explicit model, reasoning effort, canonical role instructions from
+  `.agents/agents/oat-reviewer.md`, and the same Review Scope payload.
+  If that fresh child is unavailable, use only a verified-equivalent inline
+  route or block the review.
+- Claude requires a non-empty `providers.claude.dispatchArgs.model`; the actual
+  provider invocation must include that exact value as its `model` argument.
+- Cursor requires a non-empty `providers.cursor.dispatchArgs.model`; the actual
+  provider invocation must include that exact opaque string as its `model`
+  argument without normalization.
+
+Managed incomplete resolver results, including a missing or incomplete
+candidate ladder, fail closed before review. Route interactive repair through
+the planning workflow's `Complete Dispatch Ladder Adoption Contract`; do not
+invent a reviewer target.
+
+On timeout or retry, reuse the same exact role or complete invocation payload,
+including the Claude or Cursor model argument. If the host cannot apply a
+required role or model argument, fail closed or block unless inline execution
+has verified equivalent current-host controls.
+Workflow correctness must not require provider restart or hot reload.
+Never use a managed base role because a target is missing or unavailable; a
+managed base role is forbidden except for
+explicit inherit/default behavior or the documented managed-uncapped reviewer
+fallback.
+
 **Step 6a: Probe Subagent Availability**
 
 Before selecting a tier, announce the probe and its result so the user can see what's happening:
@@ -526,8 +599,7 @@ Detection logic:
 - If the host is Cursor, invoke `oat-reviewer` using Cursor-native explicit invocation (`/oat-reviewer`) or natural mention, and resolve from `.cursor/agents/oat-reviewer.md` (or `.claude/agents/oat-reviewer.md` compatibility path).
 - If the host is Codex multi-agent, verify Codex requirements first:
   - `[features] multi_agent = true` is enabled in active Codex config.
-  - If explicit role pinning is desired, `agent_type` must be a built-in role (`default`/`worker`/`explorer`) or a custom role declared under `[agents.<name>]`.
-  - Codex may also auto-select and spawn agents without explicit role pinning.
+  - For a concrete managed target, `agent_type` must be the exact custom role declared under `[agents.<name>]`; built-in roles and auto-selection are not equivalent fallbacks.
   - If the current Codex host requires explicit user authorization before calling `spawn_agent`, do not mark `oat-reviewer` as unresolved. Announce `authorization required` and ask one concise confirmation question before selecting Tier 2 or Tier 3:
 
     ```
@@ -535,12 +607,12 @@ Detection logic:
     ```
 
   - If the user authorizes delegation and Codex role prerequisites are satisfied, use **Tier 1**.
-  - If the user declines delegation, continue with the existing Tier 2 / Tier 3 fallback flow.
+  - If the user declines delegation, continue only through a target-preserving pinned-child or guarded inline route. Otherwise block.
 
 - If the runtime can dispatch reviewer work (`subagent_type` in Claude Code, Cursor invocation via `/name` or natural mention, or Codex multi-agent spawn/auto-spawn) → **Tier 1**.
-- If the Task tool is not available or subagent dispatch is not supported → **Tier 2**.
-- If user explicitly requests inline or confirms they are already in a fresh session → **Tier 3**.
-- If `REVIEW_INVOCATION=gate` and Tier 1 is unavailable, skip Tier 2 and use **Tier 3** inline. Do not return fresh-session instructions from a gate invocation.
+- If the Task tool is not available or subagent dispatch is not supported, use **Tier 2** only after applying the target-first contract.
+- If the user explicitly requests inline or confirms they are already in a fresh session, use **Tier 3** only when the guarded inline route is valid.
+- Gate-originated review skips fresh-session handoff instructions and immediately uses the first target-preserving route available from Step 6.0. If none exists, fail closed.
 
 **Step 6b: Tier 1 — Subagent (if available)**
 
@@ -549,9 +621,9 @@ First, pre-compute the review artifact path using Step 7 naming conventions so i
 Then spawn the reviewer:
 
 - Use provider-appropriate dispatch:
-  - Claude Code: Task tool with `subagent_type: "oat-reviewer"` (resolves from `.claude/agents/oat-reviewer.md`).
-  - Cursor: explicit invocation `/oat-reviewer` (or natural mention) with agent resolved from `.cursor/agents/oat-reviewer.md` or `.claude/agents/oat-reviewer.md` compatibility path.
-  - Codex style: ask Codex to spawn agent(s) for review work and wait for all results; optionally pin `agent_type` when a specific built-in/custom role is required.
+  - Claude Code: Task tool with `subagent_type: "oat-reviewer"` (resolves from `.claude/agents/oat-reviewer.md`). For a concrete managed target, the payload must also contain `model: providers.claude.dispatchArgs.model` with the resolver-returned value.
+  - Cursor: explicit invocation `/oat-reviewer` (or natural mention) with agent resolved from `.cursor/agents/oat-reviewer.md` or `.claude/agents/oat-reviewer.md` compatibility path. For a concrete managed target, the invocation must also contain `model: providers.cursor.dispatchArgs.model` with the exact opaque resolver-returned string.
+  - Codex style: for a concrete managed target, spawn the exact resolver-returned `agent_type`; if it cannot be selected, use the explicitly pinned fresh-child route from Step 6.0. Generic auto-selection is permitted only for the documented base-role exceptions.
 - Pass the Review Scope metadata block from Step 5 as the prompt
 - Include the pre-computed artifact path for the subagent to write to
 - **If a worktree was resolved in Step 1.5:** include the worktree path in the prompt so the subagent writes the artifact to the worktree directory, not the current session's working directory
@@ -566,12 +638,12 @@ After the subagent completes:
 
 **Step 6c: Tier 2 — Fresh Session (recommended fallback)**
 
-If subagent not available:
+If target-preserving subagent dispatch is not available:
 
 - If user is already in a fresh session (confirmed), proceed to Tier 3.
 - If Codex reported `authorization required` and the user approved delegation, do **not** use Tier 2. Return to Tier 1 and delegate to `oat-reviewer`.
 - If user prefers fresh session: provide instructions and exit.
-- If `REVIEW_INVOCATION=gate`: do not provide fresh-session instructions; run Tier 3 inline instead.
+- Gate-originated review does not return fresh-session instructions; it uses the guarded route selected in Step 6.0 or fails closed.
 
 Instructions for fresh session:
 
@@ -585,7 +657,13 @@ To run review in a fresh session:
 
 **Step 6d: Tier 3 — Inline Reset (fallback)**
 
-If user insists on inline review in current session:
+If the user requests inline review, first verify equivalent current-host model
+and effort controls. Inline is also allowed for explicit inherit/default or the
+documented managed-uncapped reviewer behavior. User preference alone does not
+override a concrete managed target; if the guard fails, use the exact/pinned
+route or block.
+
+When inline is allowed:
 
 - Run "reset protocol":
   1. Re-read required artifacts for current workflow mode from scratch
@@ -649,6 +727,13 @@ oat_review_scope: { scope }
 oat_review_type: { code|artifact }
 oat_review_invocation: { manual|auto|gate }
 oat_project: { PROJECT_PATH }
+# Gate-only: copy the exact prompt-provided fields below.
+oat_gate_run_id: { gate run id }
+oat_gate_target: { configured target id }
+oat_gate_runtime: { configured runtime }
+oat_invocation_model: { configured model|provider-default|unknown }
+oat_invocation_reasoning_effort: { configured effort|provider-default|unknown }
+oat_invocation_source: { exec-target-config|unknown }
 ---
 
 # {Code|Artifact} Review: {scope}
@@ -669,6 +754,8 @@ When `oat-project-implement` spawns this skill for auto-review at checkpoints, i
 
 When `oat gate review` invokes this skill, it includes gate-originated context instructing the reviewer to write `oat_review_invocation: gate`. Honor that instruction in the artifact frontmatter.
 
+The gate prompt also supplies exact values for `oat_gate_run_id`, `oat_gate_target`, `oat_gate_runtime`, `oat_invocation_model`, `oat_invocation_reasoning_effort`, and `oat_invocation_source`. Copy all six values verbatim for gate-originated artifacts. These fields record OAT's configured invocation; do not derive them from `baseCommand`, the target id, model self-identification, or surrounding dispatch prose. Optional observed/self-reported identity is separate and non-authoritative.
+
 For all other invocations (user-triggered, fresh session), use `manual`.
 
 Gate parsing contract:
@@ -784,7 +871,8 @@ For best review quality, run in a fresh session:
 2. Run the oat-project-review-provide skill with: code {scope}
 3. Return here and run the oat-project-review-receive skill
 
-Or say "inline" to run review in current session (less reliable).
+Or say "inline" to request review in the current session; the managed-target
+guard still applies.
 
 ```
 

package/assets/skills/oat-project-review-provide-remote/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-project-review-provide-remote
-version: 1.0.2
+version: 1.0.3
 description: Use when reviewing a GitHub PR opened on another machine for an active OAT project and posting findings back as a single PR review. Resolves the project from the PR diff, reads project artifacts for mode-aware review, and posts via gh api.
 disable-model-invocation: true
 user-invocable: true
@@ -211,6 +211,33 @@ Guard outcomes:
 
 Mode-aware review against the project artifacts + the `oat-reviewer` checklist + severity model. Scope to the narrowing range when one was chosen; otherwise the full PR diff. Assign finding IDs per severity bucket (`C1`, `I1`, `M1`, `m1`), stable within the dispatch.
 
+**Step 5.0: Resolve and report the exact reviewer target.** Before capability
+probing, run:
+
+```bash
+oat project dispatch-ceiling resolve --provider "$ACTIVE_PROVIDER" --role reviewer --preflight --project-path "$PROJECT_PATH" --report-scope "$SCOPE_TOKEN" --report-action review --json
+```
+
+Require `dispatchReport.schemaVersion: 1`. Render/consume its versioned human
+block with `formatDispatchReport(dispatchReport)` semantics and derive the
+formal audit `Dispatch:` line only through
+`formatDispatchStamp(dispatchReport)` / `toDispatchStampRecord(dispatchReport)`.
+Never hand-build a parallel stamp schema.
+
+Retain the exact managed provider payload from
+`providers.<provider>.dispatchArgs` and
+`providers.<provider>.selection.target` in the actual Tier 1/2/3 invocation;
+the report does not authorize substitution or lowering. Configured gate
+invocation, work-producer diversity, and independently observed reviewer
+`dispatchReport.runtimeIdentity` remain separate. Do not treat PR markers, implementation
+producer stamps, configured defaults, or reviewer self-report as runtime
+confirmation. Leave report runtime identity not-reported unless independently
+observed.
+
+This resolver command is independent of lifecycle gates. Reusable `oat gate
+review` commands must remain provider-neutral and must not contain or add a
+provider/model `--target` argument.
+
 **Step 5a: Probe subagent availability** (mirrors `oat-project-review-provide` Step 6a):
 
 ```

package/dist/commands/config/index.d.ts

@@ -3,6 +3,7 @@ import { type PromptContext } from '../shared/shared.prompts.js';
 import { type OatConfig, type OatLocalConfig, type UserConfig } from '../../config/oat-config.js';
 import { type ResolvedConfig } from '../../config/resolve.js';
 import { type MatrixCellAvailabilityResponse, type ValidateMatrixCellOptions } from '../../providers/identity/availability.js';
+import { createDispatchValidationPassContext, validateDispatchMatrixRefs } from '../../providers/identity/dispatch-validation.js';
 import { Command } from 'commander';
 interface ConfigCommandDependencies {
     buildCommandContext: (options: Parameters<typeof buildCommandContext>[0]) => CommandContext;
@@ -19,6 +20,8 @@ interface ConfigCommandDependencies {
     readFile: (path: string) => Promise<string>;
     confirmAction: (message: string, ctx: PromptContext) => Promise<boolean>;
     validateMatrixCell: (provider: string, value: string, options: ValidateMatrixCellOptions) => Promise<MatrixCellAvailabilityResponse>;
+    createDispatchValidationPassContext: typeof createDispatchValidationPassContext;
+    validateDispatchMatrixRefs: typeof validateDispatchMatrixRefs;
     processEnv: NodeJS.ProcessEnv;
 }
 export declare function createConfigCommand(overrides?: Partial<ConfigCommandDependencies>): Command;