Enforce autonomous review gates in subagent orchestration skill

[tkstang]

Context

The oat-project-subagent-implement skill defines a two-stage autonomous review gate (Step 4: spec compliance + code quality) that runs after each subagent completes. However, the current design has no hard enforcement — the merge step (Step 5) can proceed without the review gate having been executed.

This was observed during the first real usage of the skill (adding Copilot and Gemini providers), where Phase 1 subagents were dispatched and merged without the review gate running.

Proposed Solution

Orchestrator-driven review loop:

1. Orchestrator dispatches implementer subagent → gets back commits + summary
2. Orchestrator dispatches reviewer subagent (read-only, in same worktree) → gets back findings
3. If Critical/Important findings exist, orchestrator dispatches a fix subagent with findings → repeat step 2
4. Loop bounded by oat_orchestration_retry_limit (default: 2)

Why this approach:

• Orchestrator maintains full visibility and control over the loop state
• Review verdicts can be properly logged to implementation.md orchestration runs section
• Avoids subagent nesting complexity (reviewer is a peer, not a child of the implementer)
• The reviewer subagent is lightweight (read-only, no commits) so it's fast

Alternatives considered:

• Having the implementing subagent handle the full review cycle internally — hides interaction from orchestrator, harder to log
• Folding review into the dispatch prompt — makes subagent prompts very long, still no hard gate

Acceptance Criteria

• Merge step refuses to proceed if review gate hasn't been executed for that unit
• Review verdicts are logged in the orchestration run section of implementation.md
• Fix loop respects oat_orchestration_retry_limit
• Failed units (retry limit exhausted) are excluded from merge with clear reporting

Labels

skill, oat-workflow