Review Flavors
OAT projects run reviews at several different lifecycle points, and those points have different independence requirements. A self-review that checks a freshly written plan does not need the same producer isolation as a lifecycle gate that signs off on the final artifact. Rather than force one reviewer-selection rule onto every point, OAT recognizes four review flavors, each with its own target-resolution policy layered on the shared reviewer role class.
The distinguishing question is always "who resolves this review's target, and
how independent must that target be from whatever produced the work?" The four
flavors answer it differently while preserving one invariant: the reviewer runs
at or above the ceiling (see Dispatch Policy). Gate
independence is project policy layered on the generic reviewer role class
described in the oat-project-dispatch-subagents lifecycle-role table; this page
covers which flavor fires when and who resolves its target, and links out
for the deep review request/receive mechanics.
Quick Look
- What it does: names the four review flavors and states who resolves each one's reviewer target.
- When to use it: when you need to know which review fires at a lifecycle point and whether it inherits, pins the ceiling, or requires an independent gate.
- Primary sources:
oat-project-implementphase-execution mechanics, theoat-project-dispatch-subagentslifecycle-role table, and project design Decision #11.
Flow map
The dotted branch marks the only flavor that may spawn a nested managed reviewer child inside the gate exec target: the lifecycle/final gate.
The four flavors
| Flavor | Lifecycle point | Target resolution |
|---|---|---|
| Planning-phase artifact self-review | Auto artifact-review loop for plan/spec/design | Inherit the planning parent by default (root is already at/above ceiling) |
| Implementation-phase self-review | Phase and final code reviews dispatched by oat-project-implement | Resolve the dispatch ceiling; pin the ceiling's final candidate (at-ceiling pin); inherit only when the review-owning dispatcher is known to be at/above ceiling; else select an exact CLI reviewer pre-launch |
| Phase review gate (external) | Optional non-pausing gate after a phase passes its self-review | Independent configured cross-family CLI/exec target (gates.execTargets), host-avoidance, unconstrained by native catalog; fail closed if unavailable |
| Lifecycle / final gate | End-of-lifecycle sign-off | Cross-runtime CLI exec target, independent of producer context; fails closed rather than substituting same-context self-review; may spawn a nested managed reviewer child inside the gate exec target |
The first two flavors are self-reviews. Planning review inherits its producing parent by default; implementation phase review is dispatched by the project root after the phase producer returns. The last two are gates — an external, configured, producer-independent target. Phase implementation may run below the review ceiling for cost reasons, but review must never silently inherit the below-ceiling phase agent.
Independence and fail-closed semantics
The invariant across all four flavors is that the reviewer runs at or above the ceiling. What changes between flavors is the required independence from the producer, and that independence is enforced by failing closed rather than silently downgrading:
- Planning self-review needs the least independence. The planning root already runs at or above the review ceiling, so inheriting the parent model satisfies the invariant without managed re-pinning. Pinning is possible once the ceiling is resolved during planning, but it is not the default.
- Implementation self-review needs ceiling-level capability but not cross-family isolation. The root resolves the dispatch ceiling and pins the tier's final candidate after the phase report. Inheritance is allowed only when the root dispatcher is known to be at or above the ceiling; otherwise an exact provider CLI reviewer is selected before launch. Reviewer selection is never delegated to the phase implementer.
- Phase review gate adds cross-family independence. It uses a configured
independent exec target from
gates.execTargetswith host-avoidance, unconstrained by the harness's native subagent catalog. If the required independent target cannot be enforced, the gate fails closed — it does not downgrade to producer-context review. - Lifecycle / final gate requires the strongest independence: a cross-runtime CLI exec target chosen independently of the producer context. It fails closed rather than substituting a same-context self-review, and it is the one flavor permitted to spawn a nested managed reviewer child inside the gate exec target when the gate's own contract calls for it.
Gate independence is not a property of the generic reviewer class; it is project policy layered on top of it. The dispatch adapter resolves the configured gate target before launch and passes it as exact selection input. Fail-closed behavior for both gate flavors is deliberate: an unavailable independent target blocks the gate instead of quietly reusing whatever produced the work. For the gate configuration keys and non-pausing behavior, see Workflow gates and the phase review gate section of the review doc.
Related
- Reviews — the review request/receive flows and the deep review contract these flavors plug into.
- Dispatch Policy — named ceilings, at-ceiling reviewer selection, and the Dispatch Report V1 / producer-provenance record.
- HiLL Checkpoints — how the non-pausing phase review gate relates to pauseable lifecycle checkpoints.
- Orchestration Model — the native-first dispatch topology these reviewer roles run inside.
- Workflow gates — gate configuration and exec-target selection.
- Smoke testing — how the fixture makes these flavors observable and assertable.