@open-agent-toolkit/cli 0.1.51 → 0.1.53

package/assets/skills/oat-dispatch-subagents/references/record-schema.md

@@ -0,0 +1,100 @@
+# Dispatch Record Schema
+
+Load this reference only when constructing or validating dispatch evidence.
+Use neutral scope, action, role, and authority fields. Calling workflows may
+add namespaced metadata without redefining these fields.
+
+## Request
+
+```yaml
+request_id: dispatch-unique-id
+caller: oat-repo-improve
+scope: repo:packages/cli
+objective: Audit CLI correctness hotspots
+action: analysis
+role:
+  name: repo-audit-scout
+  class: recon
+provider: codex
+dispatch_context: root-native
+dispatch_policy: economy
+dispatch_ceiling: high
+authority: read-only
+expected_output: structured-findings
+verification_evidence: file-line-references
+deadline_seconds: 300
+retry_limit: 1
+authorization_scope: this-audit-run
+fallback:
+  mode: explicit-downgrade
+  target: reduced-quick-audit
+escalate_when:
+  - evidence requires cross-package reconciliation
+  - security impact is consequential
+```
+
+`dispatch_policy` and `dispatch_ceiling` are optional resolved inputs. The
+general engine does not resolve their source.
+
+## Record
+
+```yaml
+request_id: dispatch-unique-id
+caller: oat-repo-improve
+scope: repo:packages/cli
+objective: Audit CLI correctness hotspots
+action: analysis
+role_name: repo-audit-scout
+role_class: recon
+provider: codex
+dispatch_context: root-native
+dispatch_policy: economy
+dispatch_ceiling: high
+catalog_snapshot:
+  id: root-native-1
+  source: tool-schema
+  observed_at: 2026-07-12T00:00:00Z
+authority: read-only
+role_selector: oat-recon-worker
+model_selector: opaque-provider-selector
+model_selector_granularity: opaque
+effort_selector: economical
+selection_source: explicit-call
+candidates_considered:
+  - opaque-provider-selector
+selection_reason: native-catalog
+selected_route: native
+deadline_seconds: 300
+retry_limit: 1
+payload: {}
+launch_status: accepted
+child_outcome: completed
+configured_invocation_evidence: []
+runtime_confirmation: not-reported
+diagnostics: []
+continuation_events: []
+```
+
+`role_selector` is the exact provider or harness agent-type selector, when that
+surface exists. Preserve opaque selectors byte-for-byte.
+
+## Recon Wave
+
+```yaml
+wave_id: repo-audit-wave-1
+scope: repo:packages/cli
+shared_dispatch_record: dispatch-unique-id
+lanes:
+  - lane_id: correctness
+    scope: packages/cli/src
+    launch_status: accepted
+    child_outcome: completed
+  - lane_id: security
+    scope: packages/cli/src
+    launch_status: accepted
+    child_outcome: completed
+```
+
+The wave scope is the aggregate boundary. Lane scope may narrow it. Use one
+shared record only when every dispatch axis listed in the main skill is
+identical.

package/assets/skills/oat-project-dispatch-subagents/SKILL.md

@@ -0,0 +1,218 @@
+---
+name: oat-project-dispatch-subagents
+version: 1.0.0
+description: Use when an OAT project lifecycle skill needs to translate project state, phase or task scope, gates, and write authority into a provider-neutral subagent dispatch.
+disable-model-invocation: true
+user-invocable: false
+allowed-tools: Read, Bash
+---
+
+# Dispatching OAT Project Subagents
+
+Use this internal adapter for OAT project lifecycle delegation. It resolves
+project policy and lifecycle authority, then invokes `oat-dispatch-subagents`
+for provider selection, launch, recovery, and generic evidence.
+
+## Progress Indicators (User-Facing)
+
+This skill is an internal dependency; the calling project lifecycle skill owns
+progress indicators and decides whether a sub-banner is useful. When surfacing
+a distinct project dispatch wave, use:
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+OAT ▸ PROJECT SUBAGENT DISPATCH
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Do not repeat the banner for every task. Return a compact project-scope and
+dispatch summary for the caller to incorporate.
+
+## Required Loading
+
+Resolve and read `oat-dispatch-subagents` from the active skill catalog before
+every lifecycle dispatch. Follow its provider-reference loading rule and
+request/record contract. Do not copy provider mechanics into this adapter.
+
+If the engine skill is unavailable, stop before project mutation or child
+launch and tell the user to install the utility pack at the matching scope:
+
+```bash
+oat tools install utility --scope project
+```
+
+Use `--scope user` when workflows are intentionally user-scoped. Do not fall
+back to duplicated inline dispatch logic.
+
+## Ownership Boundary
+
+This adapter owns:
+
+- active project, workflow mode, phase, and task scope resolution;
+- project and phase dispatch policy and named ceiling resolution;
+- lifecycle role policy, gates, task IDs, write roots, commits, and worktrees;
+- translation into a generic dispatch request;
+- project-specific outcome bookkeeping layered on the generic record.
+
+The general dispatch skill owns capability, authorization, catalogs,
+candidate intersection, route selection, launch acceptance, continuation, and
+recovery. Calling lifecycle skills still own sequencing, plan mutation,
+cross-task synthesis, user checkpoints, and final artifact writes.
+
+## Resolve Project Context
+
+Resolve a user-supplied project path first. Otherwise use the active project.
+Read state through the OAT CLI source of truth rather than ad-hoc YAML parsing:
+
+```bash
+oat project status --project-path "$PROJECT_PATH" --json
+```
+
+Before dispatch, establish:
+
+- project path, workflow mode, current phase, and phase status;
+- lifecycle scope such as phase ID or `pNN-tNN` task ID;
+- declared dependencies and parallel group, when applicable;
+- task file boundary, required verification, and write authority;
+- worktree and commit expectations;
+- configured HiLL, phase-review, and lifecycle-gate requirements;
+- effective dispatch policy and named ceiling.
+
+If project state cannot be resolved or conflicts with the requested lifecycle
+scope, block before invoking the general engine.
+
+## Resolve Dispatch Policy
+
+Use the current OAT CLI resolver contract for the active provider and
+lifecycle role. Do not duplicate dispatch matrices or parse configuration
+layers directly. Preserve the resolver's exact candidate selectors and
+provider arguments.
+
+Project policy may cap or select a target. Translate the resolved policy and
+ceiling into the generic request; do not ask the general engine to read
+`state.md` or infer project configuration.
+
+## Lifecycle Roles
+
+Map each lifecycle role to a generic baseline class and add project policy:
+
+| Lifecycle role             | Generic class | Project-specific contract                                                                                                                |
+| -------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
+| Phase coordinator          | `coordinator` | Own one phase dossier. Prefer an explicit suitable native target; inherit only when the root/session target is deliberately suitable.    |
+| Task worker                | `worker`      | Own one task and bounded files. Use an explicit native or pre-selected alternate target; never silently inherit an expensive root model. |
+| Fix worker                 | `worker`      | Own listed findings and bounded files. Preserve retry/fix-loop limits and original task context.                                         |
+| Planning self-review       | `reviewer`    | Inherit the planning parent by default unless the plan-writing contract requires an exact independent reviewer.                          |
+| Implementation self-review | `reviewer`    | Target the resolved reviewer ceiling; inherit only when the review-owning dispatcher is known to satisfy it.                             |
+| Phase gate                 | `reviewer`    | Use the configured independent target and fail closed when unavailable.                                                                  |
+| Lifecycle gate             | `reviewer`    | Stay independent of producer context and fail closed rather than substituting same-context self-review.                                  |
+
+The calling lifecycle skill remains authoritative when its reviewed contract
+is stricter than this table.
+
+## Adapt the Request
+
+For every lifecycle dispatch:
+
+1. Validate project state and requested phase/task scope.
+2. Resolve lifecycle role policy, provider, named ceiling, and exact
+   configuration through current CLI interfaces.
+3. Define objective, bounded files or read scope, expected output,
+   verification evidence, escalation conditions, authority, deadline, retry
+   limit, and fallback.
+4. Map the lifecycle role to a generic class.
+5. Add project metadata without replacing neutral request fields.
+6. Invoke `oat-dispatch-subagents` with the complete request.
+7. Preserve its generic dispatch record unchanged.
+8. Add lifecycle outcome metadata and let the calling workflow perform state,
+   plan, implementation-log, commit, or review-table writes.
+
+Example adapter input:
+
+```yaml
+project_path: .oat/projects/shared/example
+project_mode: quick
+project_phase: implement
+scope: p01-t02
+lifecycle_role: task-worker
+file_boundary:
+  - packages/cli/src/example.ts
+verification:
+  - pnpm --filter @open-agent-toolkit/cli test
+commit_policy: one-commit-per-task
+worktree: root
+```
+
+Example namespaced metadata added to the generic request:
+
+```yaml
+project:
+  path: .oat/projects/shared/example
+  mode: quick
+  phase: implement
+  phase_id: p01
+  task_id: p01-t02
+  file_boundary:
+    - packages/cli/src/example.ts
+  commit_policy: one-commit-per-task
+  worktree: root
+```
+
+## Coordinator and Worker Topology
+
+Use a phase coordinator only when the lifecycle workflow declares that
+topology. A coordinator may dispatch task workers when nesting and authority
+permit it, but it must not widen task boundaries, alter plan sequencing, or
+take over user checkpoints.
+
+For parallel groups, preserve plan-declared isolation. Each worktree receives
+only its assigned phase/task boundaries and must not mutate sibling worktrees.
+The root lifecycle workflow retains merge ordering and conflict resolution.
+
+## Gates and Independence
+
+Gate independence is project policy layered on the generic reviewer class.
+Resolve the configured gate target before launch and pass it as exact selection
+input. If the required independent target cannot be enforced, block the gate;
+do not silently downgrade to producer-context review.
+
+Treat gate artifacts, receive eligibility, and lifecycle disposition as caller
+concerns. The dispatch engine returns evidence and output but does not mutate
+review tables or project state.
+
+## Lifecycle Record Extension
+
+Preserve the generic record and attach project metadata separately:
+
+```yaml
+project_dispatch:
+  project_path: .oat/projects/shared/example
+  workflow_mode: quick
+  phase: implement
+  phase_id: p01
+  task_id: p01-t02
+  lifecycle_role: task-worker
+  file_boundary:
+    - packages/cli/src/example.ts
+  worktree: root
+  commit_policy: one-commit-per-task
+  gate_requirement: none
+generic_dispatch_record: dispatch-unique-id
+lifecycle_outcome:
+  task_status: complete
+  verification_status: passed
+  commit: abc1234
+```
+
+Do not rewrite generic route, selector, acceptance, outcome, or diagnostic
+fields inside the lifecycle extension.
+
+## Failure Boundaries
+
+- Invalid or stale project state: block before generic dispatch.
+- Scope outside the plan or assigned worktree: block and return to the caller.
+- Incomplete resolver result: do not invent a target; surface the diagnostic.
+- Generic pre-start rejection: apply caller retry policy through the general
+  engine.
+- Accepted child failure: return the terminal outcome to the lifecycle caller;
+  do not select a replacement automatically.
+- Required gate target unavailable: fail closed.
+- Verification or commit failure after worker completion: lifecycle caller owns
+  repair and bookkeeping; do not falsify the child outcome.

package/assets/skills/oat-project-implement/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-project-implement
-version: 2.0.35
+version: 2.0.36
 description: Use when plan.md is ready for execution. Dispatches phase coordinators that select one exact target-pinned worker per task; supports bounded fix loops and plan-declared worktree-isolated parallel phases.
 oat_gateable: true
 argument-hint: '[--retry-limit <N>] [--dry-run]'
@@ -1451,7 +1451,7 @@ git add {PROJECT_PATH}/implementation.md {PROJECT_PATH}/state.md {PROJECT_PATH}/
 git commit -m "chore(oat): bookkeeping after {pNN} {pass|fail}"
 ```
 
-Then run the optional external phase review gate for the completed phase when `oat_phase_review_gate` selects it. After the gate passes or is skipped, check HiLL checkpoint — if the phase ID is in `oat_plan_hill_phases`, pause for user approval before continuing.
+Then run the optional external phase review gate for the completed phase when `oat_phase_review_gate` selects it. After the gate passes or is skipped, check the HiLL checkpoint. A non-final checkpoint pauses at this boundary; defer a final-phase checkpoint to **Final HiLL Closeout Sequence** after final verification, final review, and any configured pre-approval steps succeed.
 
 ### Step 8: Check Plan Phase Completion
 
@@ -1495,12 +1495,20 @@ Before pausing at a checkpoint, check if auto-review is enabled:
 
 3. If disabled: skip directly to the checkpoint pause.
 
-When pausing:
+When pausing at a non-final checkpoint:
 
 - Output phase summary (tasks completed, commits made)
 - Ask user: "Phase {N} ({phase_name}) complete. Continue to next phase?"
 - Wait for user approval before proceeding to next plan phase
 
+**Final checkpoint deferral:** If the current phase is the final implementation
+phase and it is configured as a HiLL checkpoint, do not ask the generic
+"Continue to next phase?" question. Final checkpoint auto-review above still
+runs exactly as written, including `oat-project-review-provide code final` and
+its no-duplicate-final-review rule. Then continue through Steps 9–14. Final
+approval occurs only in **Final HiLL Closeout Sequence**, after final review and
+the stored pre-approval sequence complete.
+
 **Restart safety (required):**
 
 - At the end of each task and at each phase boundary, ensure `implementation.md` is persisted and internally consistent:
@@ -1541,7 +1549,7 @@ Do not use `git add -A` or glob patterns. Only commit the three project artifact
 **Note on HiLL types:**
 
 - **Workflow HiLL** (`oat_hill_checkpoints` in state.md): Gates between workflow phases (discovery → spec → design → plan → implement). Checked by oat-project-progress router.
-- **Plan phase checkpoints** (`oat_plan_hill_phases` in plan.md): Gates at plan phase boundaries during implementation. `[]` means pause after every phase; a populated array pauses only after listed phases. The field may be absent only before the first implementation-run confirmation. Listed phases are where you stop AFTER completing them.
+- **Plan phase checkpoints** (`oat_plan_hill_phases` in plan.md): Gates at plan phase boundaries during implementation. `[]` means pause after every phase; a populated array pauses only after listed phases. The field may be absent only before the first implementation-run confirmation. Listed phases are where you stop AFTER completing them. A checkpoint on the final implementation phase is deferred to final closeout so final verification, final review, and configured pre-approval work finish before explicit approval.
 - **Phase review gate** (`oat_phase_review_gate` in plan.md): Optional non-pausing external review gate after a completed phase passes the standard reviewer. Missing/disabled means skip; `phases: []` means gate every implementation phase. Passing gates continue automatically; blocking gates are received/fixed before execution proceeds.
 
 **Revision phase completion handling:**
@@ -1715,10 +1723,12 @@ echo "$FINAL_ROW"
 - Example row:
   - `| final | code | passed | 2026-01-28 | reviews/final-review-2026-01-28T140322Z.md |`
 - Check:
+
   ```bash
   echo "$FINAL_ROW" | grep -qE "^\\|\\s*final\\s*\\|.*\\|\\s*passed\\s*\\|" && echo "passed"
   ```
-- Skip to Step 15 (PR prompt)
+
+  - Continue to Step 15 (final closeout)
 
 **If final review is not marked `passed`:**
 
@@ -1807,36 +1817,100 @@ To run in a separate session use: oat-project-review-provide code final
 
 **After final review is marked `passed`:**
 
-- Update `"$PROJECT_PATH/state.md"` frontmatter:
-  - `oat_phase: implement`
-  - `oat_phase_status: complete`
-  - `oat_project_state_updated: "{ISO 8601 UTC timestamp}"`
-  - Append `"implement"` to `oat_hill_completed` (only if configured as a HiLL gate)
-- Update state content to "Implementation complete".
-- Update `"$PROJECT_PATH/plan.md"`:
-  - Set the `final` review row status to `passed` (if not already)
-  - Ensure `## Implementation Complete` totals reflect any review fix tasks that were added
-- Update `"$PROJECT_PATH/implementation.md"`:
-  - Ensure `oat_current_task_id: null`
-  - Ensure the "Review Received" section reflects completed fixes and points to the next action (PR) rather than "execute fix tasks"
+- Record the passed final review and keep the project in implementation closeout.
+- Do not append `"implement"` to `oat_hill_completed`, set
+  `oat_phase_status: complete`, or offer the normal next-step prompt yet.
+- Continue to **Final HiLL Closeout Sequence**.
 
-### Step 15: Prompt for Next Steps
+### Step 15: Final HiLL Closeout Sequence
 
-After final review passes (no Critical/Important findings):
+The final-closeout orchestrator owns this sequence after the rebased phase
+coordinator has finished. Do not move lifecycle sequencing into task workers or
+weaken exact target selection for child dispatches.
 
-**Workflow preference check (before prompting):**
+Identify the final implementation phase from the plan. A final HiLL checkpoint
+exists when `oat_plan_hill_phases` is `[]` (every phase) or when it explicitly
+contains that final phase ID. Defer only a checkpoint on the final implementation
+phase; non-final checkpoint behavior remains unchanged.
 
-```bash
-POST_IMPL=$(oat config get workflow.postImplementSequence 2>/dev/null || true)
-```
+Run final verification (Step 13). Final review must be `passed` before any
+pre-approval dispatch. If final checkpoint auto-review is enabled, Step 8 has
+already run `oat-project-review-provide code final`; do not run a duplicate
+final review here.
+
+Read the effective `workflow.postImplementSequence` once. For a configured
+legacy or structured preference, normalize legacy values before snapshotting:
+`wait` → `{ preApproval: [], postApproval: [] }`, `summary` →
+`{ preApproval: ["summary"], postApproval: [] }`, `pr` → `{ preApproval:
+["summary", "pr"], postApproval: [] }`, and `docs-pr` → `{ preApproval:
+["summary", "document", "pr"], postApproval: [] }`.
 
-- **If `POST_IMPL` is `wait`:** Print `Post-implementation: wait (from workflow.postImplementSequence). Run follow-up skills manually when ready.` Exit without auto-chaining.
-- **If `POST_IMPL` is `summary`:** Print `Post-implementation: summary (from workflow.postImplementSequence).` Invoke `oat-project-summary`. Stop after summary completes.
-- **If `POST_IMPL` is `pr`:** Print `Post-implementation: pr (from workflow.postImplementSequence).` Invoke `oat-project-pr-final` (which auto-generates `summary.md` as part of its flow).
-- **If `POST_IMPL` is `docs-pr`:** Print `Post-implementation: docs-pr (from workflow.postImplementSequence).` Invoke `oat-project-document` then `oat-project-pr-final` (summary included via pr-final).
-- **If unset or invalid:** Fall through to the standard prompt below.
+Persist this immutable state before dispatching a child:
+
+```yaml
+oat_post_implement_sequence:
+  status: pre_approval # pre_approval | awaiting_approval | post_approval | failed | complete
+  final_phase: pNN
+  pre_approval: [summary, document, pr]
+  pre_approval_completed: []
+  approval: pending # pending | approved | not_required
+  post_approval: []
+  post_approval_completed: []
+  failure: null
+```
 
-**Rationale:** `oat-project-pr-final` already auto-generates/refreshes `summary.md` as part of its flow, so `pr` and `docs-pr` do not need a separate summary step. The `summary` value exists as a standalone option for the rare case where you want just the summary without PR.
+The snapshot is immutable for this closeout: never re-resolve
+`workflow.postImplementSequence` while it is incomplete. Iterate
+`pre_approval` and `post_approval` in their stored array order; do not sort or
+substitute a vocabulary order. Resume from the first incomplete stored step,
+including a partially completed noncanonical order.
+
+For every pending `summary`, `document`, or `pr`, dispatch respectively
+`oat-project-summary`, `oat-project-document`, or `oat-project-pr-final`.
+Every `summary`, `document`, and `pr` child receives the authoritative snapshot
+and must merge state updates without replacing `oat_post_implement_sequence`.
+Re-read and verify the snapshot after every child returns before recording step
+success. If a child removed or altered it, restore the authoritative snapshot,
+record that step as failed, and stop with the boundary, failed step, and exact
+resume command: `oat-project-implement`.
+
+Commit each completed step before dispatching the next step. On failure, persist
+`status: failed`, the boundary, the failed step, and concise recovery context.
+A pre-approval failure leaves `approval: pending`; a post-approval failure
+retains `approval: approved`. Fail fast with the boundary, failed step, and
+exact resume command: `oat-project-implement`.
+
+1. Dispatch incomplete `pre_approval` steps in stored order.
+2. When they succeed and a final checkpoint exists, commit `status:
+awaiting_approval` with `approval: pending` before asking for final HiLL
+   approval.
+3. Record explicit approval as `approval: approved` and `status: post_approval`
+   before any post-approval dispatch. Then dispatch incomplete `post_approval`
+   steps in stored order.
+4. A decline or defer keeps `status: awaiting_approval` and `approval: pending`;
+   record neither approval nor failure and run no post-approval step. State the
+   boundary and exact resume command: `oat-project-implement`.
+5. If no final checkpoint exists, commit `approval: not_required` before
+   post-approval dispatch. `approval: not_required` is valid only when no final
+   checkpoint exists.
+6. After all stored steps finish, commit `status: complete`. Only then complete
+   implementation state, append the configured final HiLL completion, and
+   continue to the existing next-step behavior.
+
+If the preference is unset, do not create a sequence snapshot. When the
+preference is unset, retain the existing next-step prompt only after final
+approval when a final checkpoint is configured.
+
+### Step 16: Prompt for Next Steps
+
+Run the standard next-step prompt only when
+`workflow.postImplementSequence` was unset and no sequence snapshot was
+created. It occurs after final approval when a final checkpoint is configured.
+A configured legacy or structured preference has already completed through
+**Final HiLL Closeout Sequence**; do not re-dispatch its steps here. When the
+completed snapshot came from configured `wait`, print
+`Post-implementation: wait (from workflow.postImplementSequence). Run
+follow-up skills manually when ready.` and exit without auto-chaining.
 
 **Standard prompt (when preference is unset):**
 
@@ -1869,7 +1943,7 @@ Do not route directly to `oat-project-complete`. The `pr_open` status set by pr-
 
 Tell user: "Run the skills individually when ready: oat-project-summary → oat-project-document → oat-project-pr-final"
 
-### Step 16: Output Summary
+### Step 17: Output Summary
 
 ```
 Implementation complete for {project-name}.

package/assets/skills/oat-project-import-plan/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-project-import-plan
-version: 1.4.4
+version: 1.4.5
 description: Use when you have an external markdown plan to execute with OAT. Preserves the source plan and normalizes it into canonical plan.md format.
 argument-hint: '<path-to-plan.md> [--provider codex|cursor|claude] [--project <name>]'
 oat_gateable: true
@@ -16,7 +16,7 @@ Import a markdown plan from an external coding provider and normalize it into OA
 Provider native plan mode uses this same path: provider-plan-via-import
 preserves the provider plan first, and provider plan dispatch readiness
 inherits the same import workflow contract below, including complete ladder
-adoption, the project named ceiling, the `Shared Phase-Review Setup Contract`,
+adoption, the project named ceiling, the `Shared Phase Gate Review Setup Contract`,
 and the rule that readiness and completion follow only after a durable review
 disposition. It does not add a separate provider-plan prompt.
 
@@ -277,10 +277,10 @@ maximum. Use the canonical
 project ceiling resolves. `Uncapped` and `Inherit Host Defaults` remain
 explicit modes; `Leave Unresolved` is not implementation-ready.
 
-### Step 4.25: Configure Optional Phase Review
+### Step 4.25: Configure Optional Phase Gate Review
 
 After normalization has produced stable phase IDs and before Step 4.5 starts
-the import-aware plan artifact review, invoke the `Shared Phase-Review Setup
+the import-aware plan artifact review, invoke the `Shared Phase Gate Review Setup
 Contract` from `oat-project-plan-writing`. Provider native plan mode uses this
 same import step and inherits its result.
 
@@ -289,10 +289,10 @@ through the shared contract without probing, prompting, or mutation. Resumed or
 imported explicit values remain authoritative without re-prompting. 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
+declines, leave Phase gate review disabled and continue with the contract's concise
 status output.
 
-This phase-review setup is independent from HiLL checkpoints. Do not read or
+This Phase gate 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.
 

package/assets/skills/oat-project-next/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-project-next
-version: 1.0.6
+version: 1.0.7
 description: Use when continuing work on the active OAT project. Reads project state, determines the next lifecycle action, and invokes the appropriate skill automatically.
 disable-model-invocation: true
 user-invocable: true
@@ -259,6 +259,13 @@ Entry condition: `oat_phase == "implement"` AND (`oat_phase_status == "complete"
 
 Apply the following checks in priority order. Stop at the first match:
 
+**5.0: Incomplete approval-aware post-implementation sequence**
+
+Before every other post-implementation route, inspect `oat_post_implement_sequence`
+in project state. When the snapshot exists and is incomplete, route to
+`oat-project-implement`. This applies even when `oat_phase_status` is `pr_open`
+or a summary exists. A completed snapshot falls through to the normal router.
+
 **5.1: Incomplete revision tasks**
 
 Grep plan.md for `p-revN` phases. If any `p-revN` tasks exist with status != completed in implementation.md:

package/assets/skills/oat-project-plan/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: oat-project-plan
-version: 1.3.12
+version: 1.3.13
 description: Use when design.md is complete and executable implementation tasks are needed. Breaks design into bite-sized TDD tasks in canonical plan.md format.
 oat_gateable: true
 disable-model-invocation: true
@@ -203,7 +203,7 @@ oat_template: false
 
 When Overwrite restored an explicit phase-review snapshot, keep that exact
 entry in this first rewritten frontmatter. Do not let the generic frontmatter
-update remove or replace it. The shared phase-review setup in Step 12.25 must
+update remove or replace it. The shared Phase gate review setup in Step 12.25 must
 observe the restored key and preserve it without probing, prompting, or
 mutation. When the key was absent from the overwritten plan, do not invent it
 before the shared setup contract runs.
@@ -417,20 +417,20 @@ Ask: "Does this breakdown make sense? Any tasks missing?"
 
 Iterate until user confirms.
 
-### Step 12.25: Configure Optional Phase Review
+### Step 12.25: Configure Optional Phase Gate Review
 
 After the confirmed plan has stable phase IDs and before Step 12.5 starts the
-plan artifact review, invoke the `Shared Phase-Review Setup Contract` from
+plan artifact review, invoke the `Shared Phase Gate Review Setup Contract` from
 `oat-project-plan-writing`.
 
 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
+declines, leave Phase gate review disabled and continue with the contract's concise
 status output.
 
-This phase-review setup is independent from HiLL checkpoints. Do not read or
+This Phase gate 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.