@open-agent-toolkit/cli 0.1.48 → 0.1.51

package/assets/agents/oat-phase-implementer.md

@@ -1,6 +1,6 @@
 ---
 name: oat-phase-implementer
-version: 1.0.4
+version: 1.0.5
 description: Acts as a phase coordinator that dispatches one exact target-pinned task worker at a time, or executes exactly one bounded Task Scope when dispatched as a worker. Used by oat-project-implement.
 tools: Read, Write, Edit, Bash, Grep, Glob, Task
 color: cyan
@@ -148,10 +148,12 @@ downgrade for a managed task.
 
 #### 4. Build the Exact Invocation Before Logging
 
-- Codex: use `providers.codex.dispatchArgs.variant` as the actual `agent_type`.
-  If the native host cannot select that registered role, launch a fresh Codex
-  child pinned to `selection.target.model` and `selection.target.effort` with
-  these canonical instructions and the Task Scope. If neither exact route is
+- Codex: use `providers.codex.dispatchArgs.variant` as the actual `agent_type`
+  and attempt the exact materialized `agent_type` first. Only explicit
+  pre-start native role-selection rejection of that exact `agent_type`, before
+  any child starts, permits a fresh pinned fallback: launch a fresh Codex child
+  pinned to `selection.target.model` and `selection.target.effort` with these
+  canonical instructions and the Task Scope. If neither exact route is
   available, block.
 - Claude: pass `providers.claude.dispatchArgs.model` as the actual Task `model`.
 - Cursor: pass `providers.cursor.dispatchArgs.model` byte-for-byte as the actual
@@ -163,6 +165,15 @@ transient retry must reuse the same exact role/model/effort payload. A
 substantive escalation must re-resolve another configured candidate without
 exceeding the same named maximum.
 
+The launcher-owned `target`, `model_axis`, and `effort_axis` come only from the
+resolver output and constructed invocation payload. They are immutable and
+must not be populated, replaced, or contradicted by worker self-report. Spawn
+acceptance confirms that configured invocation; worker output is only task
+outcome data. Missing telemetry, missing self-report, and accepted terminal
+results including `BLOCKED` never trigger fallback. Once a child starts, every
+terminal result is authoritative for that attempt and is not native
+role-selection rejection.
+
 #### 5. Dispatch and Verify Serially
 
 Run one exact task worker at a time, serially in the same worktree:

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

@@ -381,6 +381,47 @@ has verified equivalent current-host controls for explicit inherit,
 managed-uncapped, or base-role behavior. Capped managed reviews still require
 the exact registered role, pinned child, or resolver-returned model argument.
 
+### Cursor validation pass and live evidence
+
+Config adoption and doctor validate Cursor candidates with one command-scoped
+pass context. Duplicate references to the same byte-for-byte candidate share
+one Task/subagent probe. If a decisive probe is unavailable, the pass resolves
+the broad catalog once, with at most one `--list-models` fallback. The cache
+ends with that adopt or doctor command; it is not process-global and has no
+TTL.
+
+A correlated Task start/completion pair that preserves the exact model argument
+and returns the sentinel establishes that the argument is eligible for that
+account and client. A structured rejection or exact allow-list exclusion can
+establish `unknown-value`. Neither result identifies the backend runtime model:
+`runtimeIdentity` remains `not-reported` unless trusted Cursor telemetry or
+Cursor support confirms it. Parent prose and broad catalog presence are
+diagnostic-only, so OAT preserves `unvalidated` when launcher evidence is
+absent instead of inferring capability from candidate spelling.
+
+The [dated GPT-5.6 Cursor verification evidence](https://github.com/voxmedia/open-agent-toolkit/blob/main/.oat/repo/reference/project-summaries/20260711-cursor-gpt-5-6-subagent-verification.md)
+preserves the original text-mode pass and a versioned stream-JSON second pass.
+The second pass ran a dynamic positive control and deliberate invalid control
+before candidates. Both parent runs completed without a Task event, making the
+controls inconclusive; the stop rule therefore executed zero of the 13
+recommended candidates and did not execute exploratory
+`gpt-5.6-sol-high-fast`. The recommendation remains unchanged and candidate
+eligibility remains unresolved.
+
+The tracked artifact's structured second-pass block contains only allowlisted
+event structure, derived outcomes, sanitized auth-presence context, and
+non-reversible identifier hashes. Exact request/session/tool-call IDs and
+credential-redacted unprojected streams from that pass stay under gitignored
+`.oat/projects/local/` storage for possible Cursor support diagnosis.
+
+The same public artifact intentionally retains the sanitized historical v1
+text-mode record for provenance. That older section includes command arguments
+and prompts, stdout and stderr, exit and duration data, and capture-environment
+details such as user-specific binary paths; it is not limited to the structured
+second-pass allowlist. Re-run after a Cursor client rollout exposes Task in
+headless mode or Cursor support confirms the private requests; review the open
+verification item by 2026-08-08.
+
 ### Legacy compatibility
 
 The command and docs path retain `dispatch-ceiling` for compatibility. Legacy

package/assets/docs/cli-utilities/workflow-gates.md

@@ -94,6 +94,23 @@ model that ran, and the reviewer must not replace them with self-identification.
 The CLI compares the copied values with its gate-owned record before it applies
 the severity threshold.
 
+### Gate dispatch report semantics
+
+When gate dispatch is represented in a `DispatchReportV1`, consumers require
+`schemaVersion: 1` and keep three facts independent:
+
+- `gateInvocation` is the immutable configured run ID, target, runtime, model,
+  reasoning effort, and source.
+- `runtimeIdentity` is observed or otherwise supported producer identity; it is
+  `not-reported` when no runtime evidence exists.
+- gate `diversity` describes producer/reviewer routing and achieved separation;
+  it does not overwrite either configured invocation or runtime identity.
+
+Configured target values, requested controls, producer stamps, and reviewer
+self-report are not interchangeable. The human report is rendered from the
+versioned object, and any parseable `Dispatch:` compatibility line is derived
+from that same report rather than rebuilt from target IDs or model names.
+
 ### Review project resolution and corroboration
 
 `--project <path-or-name>` is a declaration. OAT normalizes the declared path
@@ -501,7 +518,7 @@ Gate failure behavior is owned by the gate-aware skill:
 available target. Once a target actually runs, its exit code is the gate result;
 OAT does not try another target after a failed review.
 
-Gate target execution has a child-process timeout (default 10 minutes, override
+Gate target execution has a child-process timeout (default 15 minutes, override
 with `OAT_GATE_EXEC_TIMEOUT_MS`). When a review target times out, JSON output
 reports `status: review_failed`, `outcome: review_did_not_complete`,
 `timedOut: true`, and the timeout value so automation can distinguish a hung

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

@@ -21,7 +21,7 @@ These command definitions inherit the cross-cutting CLI conventions in:
 
 - What it does: defines the day-to-day provider-sync command surface for inspecting state, reconciling provider views, and changing provider enablement.
 - When to use it: after you have canonical assets in place and need to check sync state, write provider views, or change provider config.
-- Primary commands: `oat status`, `oat sync`, `oat providers list`, `oat providers inspect`, `oat providers set`
+- Primary commands: `oat status`, `oat sync`, `oat providers list`, `oat providers inspect`, `oat providers set`, `oat providers codex materialize`
 
 ## `oat status`
 
@@ -71,6 +71,34 @@ Key behavior:
 - Options: `--enabled <providers>`, `--disabled <providers>` (comma-separated)
 - Changes take effect on next `oat sync`
 
+## `oat providers codex materialize`
+
+Purpose:
+
+- Materialize one canonical Markdown agent as a Codex TOML role and register it
+  in Codex configuration
+
+Required operands:
+
+```bash
+oat providers codex materialize <agent-name> \
+  --model <model-id> \
+  --effort <reasoning-effort>
+```
+
+Key behavior:
+
+- Project scope is the default and writes only `.codex/config.toml` plus the
+  project role file; `--scope user` writes only under `~/.codex`
+- `--agent-path` selects a specific canonical agent and `--role-name` overrides
+  the generated role name
+- Managed role registration enables multi-agent support and merges an
+  `agents.max_depth` floor of `2`
+- Project writes preserve a higher existing project depth or inherited user
+  depth without mutating user configuration; user writes do not inspect or
+  mutate project configuration
+- Existing unrelated Codex configuration and custom roles are preserved
+
 ## Notes
 
 - `oat init --scope project` is commonly used before provider-interop commands because it initializes `.oat/sync/config.json`.

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

@@ -21,7 +21,11 @@ description: 'Provider-specific path mappings for Claude, Cursor, Copilot, Gemin
     - 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 exact `providers.cursor.dispatchArgs.model` value selected from the candidate ladder. OAT passes it byte-for-byte as the actual Task-level `model`; a `model` frontmatter value is only a default/fallback mechanism.
     - Cursor model strings are opaque. OAT does not infer family, effort, cost, or capability from their spelling; the configured candidate position owns the named tier meaning.
-    - 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.
+    - Cursor model validation checks whether the selected model is eligible for subagent Task dispatch. Each adopt/doctor command probes each distinct exact candidate once and shares one lazy broad-catalog lookup across that pass; the cache ends with the command.
+    - A correlated accepted Task carrying the exact model argument plus the child sentinel proves argument eligibility for that account/client. It does not prove backend runtime identity; that remains `not-reported` without trusted Cursor telemetry or support confirmation. Structured rejection can establish `unknown-value`, while parent prose and broad `cursor-agent models` catalog presence remain diagnostic-only.
+    - The [dated GPT-5.6 verification artifact](https://github.com/voxmedia/open-agent-toolkit/blob/main/.oat/repo/reference/project-summaries/20260711-cursor-gpt-5-6-subagent-verification.md) preserves the original probe and a stream-JSON control pass. The controls observed no Task events, so the stop rule ran zero recommendation or exploratory candidates and retained the recommendation unchanged.
+    - The artifact's structured second-pass block contains only allowlisted event fields, derived outcomes, sanitized auth presence, and identifier hashes. Exact request/session/tool-call IDs and credential-redacted unprojected streams from that pass remain in gitignored local project storage for support escalation.
+    - The same public artifact retains the sanitized historical v1 text-mode record for provenance. That older section includes command arguments and prompts, stdout and stderr, exit and duration data, and capture-environment details such as user-specific binary paths; it is not limited to the structured second-pass allowlist.
     - Rule files render as `.cursor/rules/*.mdc`
 
 === "Copilot"
@@ -57,6 +61,9 @@ description: 'Provider-specific path mappings for Claude, Cursor, Copilot, Gemin
     - Codex `max` is a first-class dispatch effort. It is present only for the Sol family in the committed supported catalogue, for both implementer and reviewer roles.
     - 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
+    - Managed Codex roles require `agents.max_depth >= 2` for the native topology: root (depth 0) → phase coordinator (depth 1) → task worker (depth 2). Sync and direct materialization merge that floor without lowering a higher target value; project writes also preserve a higher inherited user value.
+    - Project sync or materialization writes only the project's `.codex/config.toml`; explicit user-scope materialization writes only `~/.codex/config.toml`. Project scope may read the lower-precedence user depth, but never mutates user configuration.
+    - When managed roles exist and effective depth is missing, invalid, or below `2`, `oat doctor` and managed implementation preflight explain the topology and recommend `oat sync --scope project` or `oat sync --scope user` for the affected scope. Direct materialization with the same scope is the single-role repair path.
     - `oat-phase-implementer` is dual-mode: Phase Scope makes it a phase coordinator, while Task Scope makes the exact materialized variant a one-task worker. The coordinator does not implement ordinary tasks itself.
 
 ## Managed dispatch views
@@ -80,10 +87,16 @@ that repository change.
 
 At implementation time, the phase coordinator passes the recorded named
 maximum through invocation-only `--ceiling-tier`, resolves one exact candidate
-per bounded task, and dispatches one task worker at a time. Codex uses the
-resolver-returned materialized role. Claude and Cursor bind the exact model
-arguments described above. A missing or unselectable managed target blocks
-rather than falling back to the coordinator or a base role.
+per bounded task, and dispatches one task worker at a time. Codex first
+attempts the resolver-returned materialized role as the native `agent_type`.
+The launcher records the target, model axis, and effort axis from that resolved
+payload; worker self-report is not provenance and cannot replace those values.
+Only an explicit pre-start native role-selection rejection permits a fresh
+pinned-child fallback. An accepted child, including one that later returns
+`BLOCKED` or lacks telemetry, is a task outcome rather than a fallback signal.
+Claude and Cursor bind the exact model arguments described above. A missing or
+unselectable managed target blocks rather than falling back to the coordinator
+or a base role.
 
 ## Scope rules
 

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

@@ -48,9 +48,22 @@ Rules are currently project-scoped canonical content. Unlike skills and agents,
 - `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 writes `.codex/config.toml` and `.codex/agents/*.toml` at command layer after path-mapping sync. Every generated project Codex variant and registration is repository-owned, version-controlled provider output. OAT provides no automatic ignore mechanism for this project output; collaborators review and commit it like other project configuration.
+- Managed Codex roles require an effective `agents.max_depth` of at least `2` for `root (0) → phase coordinator (1) → task worker (2)`. Sync and direct materialization apply that floor without lowering a higher target value. A project write may read a higher lower-precedence user value and preserves it in the project configuration; it writes only project `.codex/config.toml`. User scope writes only `~/.codex/config.toml` and does not read or change project configuration.
+- If a managed role has missing, invalid, or insufficient effective depth, `oat doctor` and managed implementation preflight report the topology and give a scope-specific repair: `oat sync --scope project` for project scope or `oat sync --scope user` for user scope. For a single role, use `oat providers codex materialize` with the same explicit scope.
 - Codex aggregate config drift is reported via sync/status extension metadata (`aggregateConfigHash`); it is not persisted as a separate manifest schema entry.
 - Codex user-config materialization writes user-owned implementer and reviewer roles under the user provider directory, `~/.codex`; it does not write those roles into the repository.
 
+## Codex managed dispatch
+
+For managed Codex work, the resolver-returned materialized role is attempted as
+the native `agent_type` first. The launcher owns the resulting target, model,
+and reasoning-effort provenance, derived from the resolved candidate and
+compiled invocation payload; worker output cannot populate or overwrite it.
+A fresh pinned child is allowed only after explicit pre-start native
+role-selection rejection. Missing runtime telemetry, missing self-report, or a
+child accepted by the native route that later returns `BLOCKED` are not
+role-selection rejection and do not permit fallback.
+
 ## Non-interop namespaces in the same CLI
 
 - `oat project new <name>` (workflow/project scaffolding)

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

@@ -263,6 +263,33 @@ Reviewers use the final candidate at the configured review ceiling. Managed
 reviewer behavior. A timeout retry preserves the same exact role or complete
 Claude/Cursor model payload.
 
+### Cursor evidence authority
+
+Cursor resolution and runtime evidence answer different questions. Resolution
+proves which opaque candidate OAT requested. A stream-JSON Task start and
+correlated completion prove launcher behavior only when the model argument is
+preserved byte-for-byte. An accepted Task plus the child sentinel establishes
+argument eligibility for that account and client; a structured rejection can
+establish `unknown-value`. Runtime producer identity remains `not-reported`
+unless trusted Cursor telemetry or Cursor support independently confirms it.
+
+The [2026-07-11 GPT-5.6 evidence record](https://github.com/voxmedia/open-agent-toolkit/blob/main/.oat/repo/reference/project-summaries/20260711-cursor-gpt-5-6-subagent-verification.md)
+ran positive and negative controls before candidate probes. Neither control
+emitted a Task event, so the harness stopped without probing the 13 recommended
+arguments or exploratory `gpt-5.6-sol-high-fast`. This is a harness/account
+boundary, not model rejection, and it supports no recommendation change.
+
+The tracked artifact's structured second-pass block exposes only an allowlisted
+event projection and non-reversible identifier hashes. Exact
+request/session/tool-call IDs and credential-redacted unprojected streams from
+that pass stay in gitignored local project storage for support diagnosis.
+
+The same public artifact intentionally preserves the sanitized historical v1
+text-mode record for provenance. That older section includes command arguments
+and prompts, stdout and stderr, exit and duration data, and capture-environment
+details such as user-specific binary paths; it is not limited to the structured
+second-pass projection.
+
 ## Coordinator and Worker Layers
 
 `oat-phase-implementer` has two explicit modes:
@@ -279,19 +306,44 @@ Workers run serially in the same worktree. Parallelism remains limited to
 plan-declared phase worktrees. See
 [Implementation Execution](implementation-execution.md) for the full loop.
 
-## Producer Provenance
+## Dispatch Report V1 and Producer Provenance
+
+Resolver calls that pass `--report-scope` and `--report-action` include a
+`dispatchReport` object in JSON output. Consumers must require
+`dispatchReport.schemaVersion: 1` before dispatch. The report keeps four
+different decisions separate:
+
+| Report area                                                         | What it means                                                        |
+| ------------------------------------------------------------------- | -------------------------------------------------------------------- |
+| `policy`                                                            | The resolved managed/inherit policy, its status, name, and source    |
+| `selection.ceilingTier` / `selection.ceilingTarget`                 | The maximum allowed tier and its boundary target                     |
+| `selection.requestedCandidate` / `candidateTier` / `candidateIndex` | The exact candidate requested for this bounded task and its position |
+| `selection.exactSelectedTarget` / `route.target`                    | The compiled provider target and actual invocation route             |
+
+A named policy or ceiling is never a substitute for the requested candidate or
+exact selected target. `requestedControls` records what OAT put into the host
+payload. `configuredDefaults` records fallback configuration and is explicitly
+not a runtime observation.
+
+`gateInvocation` is an immutable copy of configured gate controls.
+`runtimeIdentity` is separate and stays `not-reported` until independently
+observed or otherwise supported runtime evidence exists. Requested controls,
+configured defaults, role-name parsing, and reviewer self-identification do not
+become observed runtime identity.
 
-Dispatch notes retain a parseable stamp for later review gates:
+Human output comes from `formatDispatchReport(dispatchReport)`. Dispatch notes
+also retain a parseable compatibility stamp for later review gates:
 
 ```text
 Dispatch: scope=p06-t03 action=implementation role=implementer producer=gpt-5.6-sol provenance=declared model_axis=selected:gpt-5.6-sol effort_axis=selected:high dispatch_policy=high dispatch_ceiling=high target=oat-phase-implementer-gpt-5-6-sol-high
 ```
 
-`producer` is the resolved model slug when OAT can establish it; otherwise it is
-`unknown`. `provenance` is `declared`, `observed`, `inferred`, or `unknown`.
-Concrete Claude/Cursor model arguments can declare identity. Codex roles retain
-exact model and effort axes from resolver output even when producer identity is
-not independently observable.
+The stamp must be derived through `toDispatchStampRecord(dispatchReport)` and
+`formatDispatchStamp`; callers must not reconstruct it from policy labels, role
+names, candidate strings, or target names. `producer` is the runtime model slug
+when OAT can establish it; otherwise it is `unknown`. `provenance` is
+`declared`, `observed`, `inferred`, or `unknown`. Selected model and effort axes
+can remain exact even when runtime producer identity is not reported.
 
 ## Legacy Compatibility
 

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

@@ -88,6 +88,18 @@ import performs the same readiness setup:
 
 See [Dispatch Policy](dispatch-ceiling.md) for ladder shapes and ownership.
 
+### Validating plan metadata
+
+Before building the phase schedule, implementation validates plan parallelism:
+
+```bash
+oat project validate-plan --project-path .oat/projects/shared/example
+```
+
+The command rejects malformed groups, unknown phase IDs, duplicate membership,
+and singleton groups. Invalid metadata blocks execution rather than silently
+falling back to a different schedule.
+
 Before phase work, implementation runs provider preflight:
 
 ```bash
@@ -101,6 +113,19 @@ An unresolved non-interactive preflight blocks. Managed `Uncapped` and
 `Inherit Host Defaults` are explicit modes; omitted policy state is not an
 implicit fallback.
 
+For a managed Codex implementer, preflight also resolves the effective
+`agents.max_depth`. Native `root (0) → phase coordinator (1) → task worker (2)`
+execution requires a depth of at least `2`. Missing, invalid, or lower values
+block before dispatch and identify the owning scope:
+
+- Project scope: run `oat sync --scope project`
+- User scope: run `oat sync --scope user`
+- Single-role repair: rerun `oat providers codex materialize` with the required
+  agent name, model, effort, and matching scope
+
+Project preflight may inherit a valid higher user depth, but remediation never
+writes across the project/user boundary.
+
 ## Resolve the Effective Named Maximum
 
 For each phase, the orchestrator determines the task maximum:
@@ -190,9 +215,14 @@ candidate above the maximum or absent from the configured ladder blocks.
 Build the complete host payload before writing dispatch logs:
 
 - **Codex:** use `providers.codex.dispatchArgs.variant` as the actual
-  `agent_type`. If the registered role cannot be selected, launch a fresh Codex
-  child pinned to `selection.target.model` and `selection.target.effort` with
-  canonical `oat-phase-implementer` instructions and the Task Scope.
+  `agent_type`. An accepted launch with that exact materialized role is
+  authoritative evidence of the configured invocation for coordinators and
+  task workers. A fresh Codex child pinned to `selection.target.model` and
+  `selection.target.effort` is permitted only after an actual native
+  role-selection rejection; missing self-reporting or model/effort telemetry
+  does not justify the fallback. An accepted child, including one that later
+  returns `BLOCKED`, is a task outcome and never triggers another pinned-child
+  fallback.
 - **Claude:** pass `providers.claude.dispatchArgs.model` as the actual Task
   `model`. Its separate effort axis is `not-applicable`.
 - **Cursor:** pass `providers.cursor.dispatchArgs.model` byte-for-byte as the
@@ -204,6 +234,36 @@ If exact controls cannot be applied, fail closed. A transient retry reuses the
 same complete provider payload. Substantive escalation re-resolves another
 configured candidate within the same named maximum and bounded retry budget.
 
+## Dispatch Reports During Execution
+
+Every implementation, fix, and review resolver call supplies explicit report
+context:
+
+```text
+--report-scope <phase-or-task> --report-action <implementation|fix|review>
+```
+
+The completed JSON must contain `dispatchReport.schemaVersion: 1` before the
+provider invocation begins. The coordinator reads the requested candidate,
+candidate tier, ceiling, exact selected target, requested controls, configured
+defaults, and runtime identity from that report as distinct fields. It does not
+infer any of them from a materialized role name or opaque Cursor string.
+
+The human dispatch block is rendered from the report. The formal `Dispatch:`
+line is a compatibility view derived from the same report through the dispatch
+stamp adapter. It is not a second schema and must not be assembled by hand.
+Configured defaults and configured gate invocation remain distinct from runtime
+identity; when runtime identity is not observed, the report says so without
+weakening exact requested model or effort controls.
+
+After constructing the complete payload, the launcher records the selected
+target and requested model/effort controls in the report. Those configured
+invocation fields are launcher-owned and derive from resolver output plus the
+actual payload; worker output cannot populate or overwrite them. Optional
+coordinator or worker self-report remains non-authoritative runtime evidence.
+Runtime attestation, when available, is separate host-generated metadata rather
+than an agent claim.
+
 ## Task Scope and Commit Verification
 
 Each worker receives only one task:

package/assets/docs/workflows/projects/reviews.md

@@ -207,7 +207,24 @@ Final review `passed` gate requires:
   - Project-scope Codex role files are generated from canonical `.agents/agents/*.md` during `oat sync --scope project`.
   - User-config Codex roles materialize under `~/.codex`; project-config and supported-catalogue roles remain in the project-scoped, version-controlled `.codex` view.
   - Some Codex hosts require explicit user authorization before the skill may call `spawn_agent`. In those hosts, `oat-project-review-provide` should ask whether to delegate to `oat-reviewer` instead of reporting the reviewer as unresolved.
-- If subagent dispatch is unavailable, follow the existing fallback path (fresh session preferred, inline reset as fallback).
+  - An accepted launch using the exact materialized `agent_type` is authoritative
+    configured-invocation evidence for a reviewer. After the complete payload
+    is built, the launcher records its `target`, `model_axis`, and
+    `effort_axis`; reviewer self-report cannot supply or overwrite those
+    fields. Optional self-report is non-authoritative, while runtime
+    attestation is host-generated metadata.
+  - A fresh pinned CLI child is a fallback only for an actual native
+    role-selection rejection, never for absent self-reporting or model/effort
+    telemetry. A child accepted by the native host, including one that later
+    returns `BLOCKED`, has produced a review outcome and cannot trigger the
+    fallback.
+  - An accepted reviewer that returns `BLOCKED` blocks the relevant review. It
+    cannot trigger the pinned fallback, and absent findings in that blocked
+    outcome cannot be interpreted as a pass.
+- For unmanaged review dispatch, if subagent dispatch is unavailable, follow
+  the existing fallback path (fresh session preferred, inline reset as
+  fallback). This generic fallback does not override managed exact-target
+  rules: a managed reviewer that cannot be launched exactly blocks the review.
 
 ## Reference artifacts
 

package/assets/public-package-versions.json

@@ -1,6 +1,6 @@
 {
-  "cli": "0.1.48",
-  "docs-config": "0.1.48",
-  "docs-theme": "0.1.48",
-  "docs-transforms": "0.1.48"
+  "cli": "0.1.51",
+  "docs-config": "0.1.51",
+  "docs-theme": "0.1.51",
+  "docs-transforms": "0.1.51"
 }

package/assets/skills/oat-agent-instructions-analyze/references/docs/provider-reference.md

@@ -220,6 +220,8 @@ The package manager for the agent skills ecosystem. Installs skills across 27+ a
 - Enable feature flag in config:
   - `[features]`
   - `multi_agent = true`
+- For OAT's nested root → coordinator → worker topology, configure
+  `[agents] max_depth = 2` or higher.
 - Define role(s) in config:
   - `[agents.oat-reviewer]` (or role names your workflow dispatches)
 - Dispatch by role name using `agent_type` (not `subagent_type`).
@@ -228,8 +230,12 @@ The package manager for the agent skills ecosystem. Installs skills across 27+ a
 **Note on OAT provider sync:**
 
 - Codex runtime dispatch is config-role based (`[agents.<name>]`) and TOML-backed.
-- OAT currently does not sync canonical markdown agents into `.codex/agents`.
-- Canonical markdown agent definitions require a markdown→TOML adapter to become Codex-executable role configs.
+- OAT sync exports canonical Markdown agents as `.codex/agents/*.toml` role
+  configs and registers them in `.codex/config.toml`.
+- Project-scoped output is repository-owned and version controlled. Explicit
+  user-scope materialization writes under `~/.codex` instead.
+- Sync and direct materialization merge an `agents.max_depth` floor of `2`
+  without lowering a higher project or inherited user value.
 
 ### Other Codex Resources
 

package/assets/skills/oat-agent-instructions-apply/references/docs/provider-reference.md

@@ -220,6 +220,8 @@ The package manager for the agent skills ecosystem. Installs skills across 27+ a
 - Enable feature flag in config:
   - `[features]`
   - `multi_agent = true`
+- For OAT's nested root → coordinator → worker topology, configure
+  `[agents] max_depth = 2` or higher.
 - Define role(s) in config:
   - `[agents.oat-reviewer]` (or role names your workflow dispatches)
 - Dispatch by role name using `agent_type` (not `subagent_type`).
@@ -228,8 +230,12 @@ The package manager for the agent skills ecosystem. Installs skills across 27+ a
 **Note on OAT provider sync:**
 
 - Codex runtime dispatch is config-role based (`[agents.<name>]`) and TOML-backed.
-- OAT currently does not sync canonical markdown agents into `.codex/agents`.
-- Canonical markdown agent definitions require a markdown→TOML adapter to become Codex-executable role configs.
+- OAT sync exports canonical Markdown agents as `.codex/agents/*.toml` role
+  configs and registers them in `.codex/config.toml`.
+- Project-scoped output is repository-owned and version controlled. Explicit
+  user-scope materialization writes under `~/.codex` instead.
+- Sync and direct materialization merge an `agents.max_depth` floor of `2`
+  without lowering a higher project or inherited user value.
 
 ### Other Codex Resources