@open-agent-toolkit/cli 0.2.1 → 0.2.3

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

@@ -1,12 +1,12 @@
 ---
 name: oat-project-implement
-version: 2.1.3
+version: 2.1.4
 description: Use when plan.md is ready for execution. Dispatches one phase implementer per phase, owns independent phase review and bounded fix routing, and supports plan-declared worktree-isolated parallel phases.
 oat_gateable: true
 argument-hint: '[--retry-limit <N>] [--dry-run]'
 disable-model-invocation: true
 user-invocable: true
-allowed-tools: Read, Write, Bash(git:*), Bash(oat project log:*), Glob, Grep, AskUserQuestion, Task
+allowed-tools: Read, Write, Bash(git:*), Bash(oat:*), Bash(oat project log:*), Glob, Grep, AskUserQuestion, Task
 ---
 
 # Implementation Phase
@@ -204,4 +204,6 @@ Rules:
 - Implementation.md tracks all progress
 - Final verification passes
 - Final review passes (no Critical/Important findings)
+- The configured implementation exit gate has an allowed and fresh disposition
+  before approval-aware sequencing, completion state, or success output
 - No unresolved blockers

package/assets/skills/oat-project-implement/references/completion-and-closeout.md

@@ -35,7 +35,7 @@ Options:
 3. Modify plan to address blocker
 ```
 
-### Step 11: Mark Implementation Complete
+### Step 11: Prepare Final Closeout Baseline
 
 When all plan tasks are complete (i.e., there is no next incomplete `pNN-tNN` task):
 
@@ -48,11 +48,11 @@ When all plan tasks are complete (i.e., there is no next incomplete `pNN-tNN` ta
   - Design deltas (if any)
 - This should reflect **what was actually implemented**, including any deviations from design and any review-fix work.
 
-Update frontmatter:
+Keep implementation in progress while clearing the completed task pointer:
 
 ```yaml
 ---
-oat_status: complete
+oat_status: in_progress
 oat_ready_for: null
 oat_blockers: []
 oat_last_updated: { today }
@@ -60,11 +60,13 @@ oat_current_task_id: null
 ---
 ```
 
-**Important:** `oat_current_task_id` should never point at an already-completed task. If all tasks are done, set it to `null` and proceed to the final review gate.
-
-### Step 12: Update Project State
+**Important:** `oat_current_task_id` should never point at an already-completed
+task. If all tasks are done, set it to `null`, but do not mark implementation
+complete before final verification, final review, the configured implementation
+exit gate, and the approval-aware closeout sequence finish.
 
-Update `"$PROJECT_PATH/state.md"` so other skills reflect task completion and review gating:
+Update `"$PROJECT_PATH/state.md"` so other skills reflect task completion while
+closeout remains in progress:
 
 **Frontmatter updates:**
 
@@ -72,11 +74,9 @@ Update `"$PROJECT_PATH/state.md"` so other skills reflect task completion and re
 - `oat_last_commit: {final_commit_sha}`
 - `oat_blockers: []`
 - `oat_phase: implement`
-- `oat_phase_status: in_progress` (until final review passes)
+- `oat_phase_status: in_progress` (until all closeout boundaries pass)
 - `oat_project_state_updated: "{ISO 8601 UTC timestamp}"`
-- **If** `"implement"` is in `oat_hill_checkpoints`: append `"implement"` to `oat_hill_completed` array
-
-**Note:** Only append to `oat_hill_completed` when the phase is configured as a HiLL gate.
+- Do not append `"implement"` to `oat_hill_completed` yet.
 
 Update content:
 
@@ -95,21 +95,23 @@ Implementation - Tasks complete; awaiting final review.
 - ⧗ Awaiting final review
 ```
 
-**Bookkeeping commit (required):**
+**Baseline bookkeeping commit (required):**
 
 **DO NOT SKIP.** This commit prevents state drift across sessions.
 
-After updating state.md to reflect implementation completion, refresh the repo dashboard when available and commit all modified project tracking files:
+After updating state.md to reflect task completion and pending closeout, refresh
+the repo dashboard when available and commit all modified project tracking
+files:
 
 ```bash
 oat state refresh
 git add "$PROJECT_PATH/implementation.md" "$PROJECT_PATH/state.md" "$PROJECT_PATH/plan.md"
-git diff --cached --quiet || git commit -m "chore(oat): update tracking artifacts for implementation complete"
+git diff --cached --quiet || git commit -m "chore(oat): prepare final implementation closeout"
 ```
 
 Do not use `git add -A` or glob patterns. Only commit the three project artifacts listed above; `.oat/state.md` is a generated, gitignored dashboard.
 
-### Step 13: Final Verification
+### Step 12: Final Verification
 
 Run project-wide verification:
 
@@ -129,7 +131,7 @@ pnpm build
 
 All must pass before proceeding.
 
-### Step 14: Trigger Final Review
+### Step 13: Trigger Final Review
 
 **At the final plan phase boundary, a code review is required before PR.**
 
@@ -167,7 +169,7 @@ filename and never move its status backward.
   echo "$FINAL_ROW" | grep -qE "^\\|\\s*final\\s*\\|.*\\|\\s*passed\\s*\\|" && echo "passed"
   ```
 
-  - Continue to Step 15 (final closeout)
+  - Continue to Step 14 (configured implementation exit gate)
 
 **If final review is not marked `passed`:**
 
@@ -183,7 +185,7 @@ highest target-preserving route before launch, and run
 
 - If receive creates fix tasks, return through the normal bounded implement and
   re-review loop.
-- Continue to Step 15 only when the final Reviews row is `passed`.
+- Continue to Step 14 only when the final Reviews row is `passed`.
 - A failed blocking review, unresolved Critical finding, exhausted route, or
   missing credential with no adequate fallback is an autonomy boundary. Persist
   the review state and report the exact resume action instead of falling
@@ -282,7 +284,318 @@ To run in a separate session use: oat-project-review-provide code final
 - 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**.
+- Continue to **Gate Execution**.
+
+### Step 14: Gate Execution
+
+The configured implementation exit gate is independent from the optional
+`oat_phase_review_gate`, the root-owned phase reviews, and the mandatory final
+lifecycle review. A missing, disabled, or unconfigured phase gate never disables
+or satisfies this configured exit gate.
+
+**Persisted transition contract:**
+
+`"$PROJECT_PATH/state.md"` is the routing source of truth. Store one closeout
+generation as a sibling of `oat_post_implement_sequence`:
+
+```yaml
+oat_implement_exit_gate:
+  status: pending # pending | allowed | blocked | stale
+  resolution: configured # configured | no_gate
+  disposition: null # null | passed | warned | prompt_approved | no_gate
+  config_fingerprint: '<stable hash of the resolved declaration>'
+  resolved_command: null
+  resolved_description: null
+  on_failure: block # block | prompt | warn | null
+  max_attempts: 2
+  attempts_completed: 0
+  reviewed_head: null
+  implementation_fingerprint: null
+  launch_state: not_started # not_started | intent_persisted | accepted | result_persisted | not_accepted
+  launch_attempt_id: null
+  launch_started_at: null
+  launch_result_receipt: null
+  gate_run_marker: null
+  gate_run_id: null
+  envelope_status: null
+  artifact: null
+  handoff: null
+  receive_state: not_started # not_started | intent_persisted | completed | reconciliation_required
+  receive_correlation: null
+  receive_source_artifact: null
+  receive_archived_artifact: null
+  receive_event_identity: null
+  receive_pre_head: null
+  receive_commit: null
+  receive_eligible: false
+  receive_completed: false
+  failure: null
+  updated_at: '2026-07-18T00:00:00Z'
+```
+
+At the start of a new closeout generation, require a current passed final
+lifecycle review, capture `reviewed_head`, and compute a deterministic
+`implementation_fingerprint` from the gate-reviewed basis. Resolve
+`workflow.gates.skills.oat-project-implement` once. Canonically serialize the
+resolved command, description, `onFailure`, and `maxAttempts` to derive
+`config_fingerprint`; persist the complete resolved inputs with `status:
+pending` before any gate launch. Missing state means unresolved, never no gate.
+A `null` resolution persists `allowed/no_gate` with `disposition: no_gate`,
+null run/artifact/receive provenance, and the current implementation basis.
+
+An in-flight `pending` or `blocked` generation reuses its persisted resolved
+configuration and never re-resolves it. Recompute the fingerprint from those
+persisted inputs before resume. If the persisted resolved configuration does
+not reproduce `config_fingerprint`, mark the generation `stale` and fail
+closed. External configuration changes are considered only when a new
+generation starts; they never rewrite an in-flight snapshot.
+
+**Launch acceptance and reconciliation:**
+
+The launch state advances only as `not_started` → `intent_persisted` →
+`accepted` → `result_persisted`; an explicit pre-start rejection instead
+records `not_accepted`. Before invoking the configured command, generate and
+persist `launch_attempt_id`, `launch_started_at`, and
+`launch_result_receipt` before invoking the command. The receipt is a
+closeout-owned path selected before launch; capture the command's stdout there
+without changing its configured argv.
+
+For `oat --json gate review`, the gate CLI run marker is acceptance evidence
+established before its reviewer child launch. Observe the marker that uniquely
+matches the normalized project and starts no earlier than
+`launch_started_at`; persist its path as `gate_run_marker`, its run ID as
+`gate_run_id`, and `launch_state: accepted`. More than one matching marker is
+ambiguous and blocks reconciliation.
+
+On resume from `intent_persisted` or `accepted`, reconcile the exact
+`gate_run_marker`, durable result receipt, and run-correlated active or archived
+artifact before deciding the next transition:
+
+- A still-present matching marker proves an accepted run may be active. Preserve
+  `accepted`, wait for that run, and never launch a replacement.
+- A complete result receipt must parse as exactly one structured envelope whose
+  run ID matches the marker and artifact. Persist its envelope fields and
+  `launch_state: result_persisted` before receive or policy handling.
+- A matching artifact without its result receipt proves acceptance but not the
+  terminal outcome. Persist
+  `blocked/launch_result_reconciliation_required`; do not infer `ok` or
+  `blocked` from findings or exit status.
+- Relaunch only after durable `not_accepted` evidence proves that no gate
+  process or reviewer child was accepted. This requires an explicit pre-start
+  launcher rejection plus absence of a matching marker, result receipt, and
+  active or archived artifact.
+- Absent or ambiguous evidence persists
+  `blocked/launch_reconciliation_required` and never relaunches automatically.
+  Surface the persisted attempt ID, marker/receipt paths, and exact recovery
+  action so a human can reconcile or explicitly retire that attempt.
+
+Persist and commit every state transition before crossing its launch, receive,
+stop, approval-aware sequence, completion, or output boundary. Append a concise
+audit event to `implementation.md`; that prose and review ledger rows are
+evidence, not routing state.
+
+**Structured outcomes, receive, and policy:**
+
+- Accept only a complete structured envelope whose status and correlation
+  fields are internally consistent. Receive is eligible only for `ok` or
+  `blocked` with `receiveEligible: true` and a corroborated non-null `handoff`.
+  Ineligible, null, or contradictory handoffs, unknown statuses,
+  `review_failed`, `artifact_validation_failed`, and
+  `targeting_correlation_failed` persist `blocked`, remain outside receive, and
+  cannot produce an allowed disposition. They ignore `on_failure`, including
+  `warn`; policy handling is unavailable without a validated, receive-eligible
+  `blocked` envelope whose eligible receive completed durably.
+- Manual review provenance is rejected: only `oat_review_invocation: gate` with
+  the matching `oat_gate_run_id` may satisfy the configured gate. A normal
+  final review, phase review, or manually produced independent-review artifact
+  cannot populate configured-gate provenance.
+
+**Receive intent and reconciliation:**
+
+The receive state advances only as `not_started` → `intent_persisted` →
+`completed` or `reconciliation_required`. For a receive-eligible `ok` or
+`blocked` envelope, first resolve the receiver's collision-safe archive
+destination. Then persist the receive correlation, source and expected archived
+artifact paths, exact Reviews event identity, and `receive_pre_head` before
+invoking receive. `receive_correlation` binds the gate run ID, handoff, source
+artifact, scope, type, and source filename; set `receive_state:
+intent_persisted` and commit it before calling `oat-project-review-receive`.
+
+On normal return or resume from `intent_persisted`, reconcile all three durable
+receipt components:
+
+1. the exact archived artifact at `receive_archived_artifact`, carrying the
+   matching `oat_gate_run_id`;
+2. the bound Reviews event identified by Scope + Type + original source
+   filename, with its artifact set to that archived path and a monotonic
+   received/fix/passed status; and
+3. the receive bookkeeping commit after `receive_pre_head`, whose bounded diff
+   contains that archive move and the matching project tracking updates.
+
+When the exact archived artifact, the bound Reviews event, and the receive
+bookkeeping commit all corroborate the persisted correlation, store that commit
+as `receive_commit`, set `receive_state: completed`, and set
+`receive_completed: true` from that corroborated durable receipt without
+invoking receive again. An already-completed receive is idempotent and must not
+run again.
+
+If any component is missing, contradictory, or cannot be uniquely correlated,
+persist `blocked/receive_reconciliation_required` and stop with the recovery
+command `oat-project-review-receive`; do not invoke it automatically. Surface
+the expected source/archive paths, event identity, pre-receive HEAD, and
+candidate commit so a human can repair or confirm the durable receipt before
+resume. A receive failure persists `blocked` and cannot become an allowed
+disposition.
+
+- After successful receive, `ok` persists `allowed/passed`. Apply the persisted
+  `on_failure` policy only to a validated, receive-eligible `blocked` envelope
+  after its eligible receive is durably completed.
+- `block` outcomes consume remediation attempts only after a valid configured
+  gate result and its eligible receive disposition are durably processed.
+  Increment `attempts_completed` before remediation/rerun. Below
+  `maxAttempts`, remediate, mark the changed implementation basis `stale`, rerun
+  Steps 12-13 for that basis, and return to `pending` with updated
+  `reviewed_head` and `implementation_fingerprint` while preserving the
+  persisted configuration and consumed attempt count. At `maxAttempts`,
+  persist `blocked` and stop without another gate launch.
+- Launch failures, missing CLIs, unavailable runtimes, and transport failures
+  do not increment `attempts_completed`. Persist failure context and
+  `status: blocked`, then stop or escalate without treating infrastructure
+  recovery as a remediation attempt or applying `on_failure`.
+- Envelope validation/correlation failures and receive failures likewise remain
+  `blocked` regardless of `on_failure`; they cannot persist `allowed/warned`,
+  `allowed/prompt_approved`, or any other allowed disposition.
+- An explicit prompt continuation persists `allowed/prompt_approved`; defer or
+  no response persists `blocked` and stops. A warn continuation persists
+  `allowed/warned` before closeout proceeds.
+
+**Interruption, resume, and freshness:**
+
+- Resume `pending` or `blocked` from the persisted transition without replacing
+  its generation. Continue from the first incomplete launch, envelope, receive,
+  policy, or persistence boundary.
+- A fresh `allowed` result resumes after the gate without executing the gate or
+  receive a second time. Reuse requires a valid disposition, complete
+  configured-gate provenance when configured, an unchanged implementation
+  fingerprint, and any eligible receive marked complete.
+- Closeout-only descendants include configured gate artifacts and receipts,
+  project tracking, `project-log.md` appends, summary/documentation/PR sequence
+  outputs, final HiLL bookkeeping, and completion bookkeeping. Classify
+  gate-owned `oat project log append` mutations introduced with PR #156 as
+  closeout-only; they do not invalidate the reviewed implementation basis.
+- Determine freshness from every path changed after `reviewed_head`, and require
+  each descendant commit to contain only recognized closeout work. An unknown
+  changed path fails closed as substantive implementation change.
+  Implementation, test, skill, template, or workflow configuration changes
+  make the prior result `stale`. Preserve its provenance for audit, require a
+  current final lifecycle review for the new basis, and start a new generation.
+
+Before approval-aware sequencing, final HiLL approval, implementation
+completion, or success output, run the configured gate:
+
+1. Classify persisted state. A fresh allowed generation proceeds to Step 15
+   without duplicate gate or receive execution. A valid `pending` or `blocked`
+   generation resumes its first incomplete boundary with its persisted
+   configuration. For absent or stale state, start a new generation and resolve
+   the gate for this skill:
+
+   ```bash
+   oat gate resolve oat-project-implement --json
+   ```
+
+   Persist the resolution and configuration fingerprint before launch. If the
+   command returns JSON `null`, persist the allowed no-gate transition; no gate
+   is configured; proceed directly to the completion steps in Step 15 below.
+
+2. Export the resolved project path into the command shell:
+
+   ```bash
+   export PROJECT_PATH
+   ```
+
+   If the resolved command invokes review, parse its argv before launch and
+   require the canonical global-JSON shape
+   `oat --json gate review --project "$PROJECT_PATH" ...`. The configured review
+   command must place the global `--json` before `gate review`, must already
+   include `--project "$PROJECT_PATH"`, and must not include `--target <id>`. Reject
+   `oat gate review ...` without the global `--json` flag before launch because
+   it emits human-oriented output rather than the structured envelope. For any
+   invalid shape, stop and require the user to migrate the stored declaration
+   before execution; never rewrite user or local configuration during closeout,
+   and never inject, reorder, or append arguments at execution time.
+
+3. If launch reconciliation does not already prove an accepted or completed
+   attempt, persist the launch intent and preselected result receipt, then
+   execute the resolved command exactly as configured. Capture stdout directly
+   into that durable receipt while separately retaining stderr and the exit
+   code; the capture wrapper must not alter the configured command argv.
+   Observe and persist the gate run marker before treating the reviewer child as
+   accepted. A zero exit code means the review passed its threshold, but it does
+   not by itself authorize artifact receipt or complete the handoff. Validate
+   the receipt as one structured envelope, then persist the run ID, envelope
+   status, artifact, eligibility, handoff correlation, failure details, and
+   `launch_state: result_persisted` before receive or policy handling.
+
+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.
+   - After eligible receive succeeds, persist `receive_completed: true` before
+     applying the terminal disposition. Never invoke receive again for that
+     persisted run.
+
+5. Do not route policy from a generic nonzero exit. Apply persisted
+   `on_failure` and `max_attempts` only after Step 4 validates a
+   receive-eligible `blocked` envelope and its eligible receive is durably
+   completed. Use `description` to orient these validated blocking-finding
+   outcomes:
+   - `block`: read gate feedback, remediate, and re-run the gate up to
+     `maxAttempts` attempts (default `2`). Persist each consumed remediation
+     attempt. If the gate ends in `block` after attempts are exhausted,
+     escalate to the human with accumulated feedback and append that feedback
+     to `implementation.md`.
+   - `prompt`: persist the blocked boundary, surface the gate failure, and ask
+     the human how to proceed. Continue only after an explicit persisted
+     approval.
+   - `warn`: persist the warned allowance and failure details before continuing.
+
+   Any nonzero result without that validated and durably received `blocked`
+   envelope remains blocked and skips all three policies. In particular,
+   `warn` plus `review_failed` remains `blocked`, and `warn` plus an invalid,
+   malformed, or contradictory envelope remains `blocked`. Launch failures,
+   missing CLIs, unavailable runtimes, transport failures, validation or
+   correlation failures, and receive failures cannot continue to sequencing,
+   final HiLL, completion, or success output regardless of `on_failure`.
+
+   When the gate ends in `block` after attempts are exhausted or remains at an
+   unresolved `prompt` boundary, the completion steps below MUST NOT run. The
+   project stays `in_progress` and resumable through `oat-project-implement`.
+
+6. Runtime selection note: the step runs the gate `command` as-is and reads no
+   OAT runtime env var. By default, `oat gate review` avoids the resolved
+   producer family. Exact review scopes use a claimable producer identity from
+   the matching dispatch stamp. Final/range reviews aggregate in-scope
+   implementer/fix stamps; when a stamp's producer is not claimable or has an
+   unknown family, its launcher-owned configured target may contribute a
+   lower-confidence family exclusion without becoming runtime identity. If no
+   claimable family remains, selection degrades to same-runtime avoidance.
+   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 15: Final HiLL Closeout Sequence
 
@@ -291,12 +604,19 @@ and root-owned phase review have finished. Do not move lifecycle sequencing
 into phase or optional nested workers or weaken exact target selection for
 child dispatches.
 
+Before creating or resuming `oat_post_implement_sequence`, and again before
+every dispatch, final HiLL transition, completion mutation, and success output,
+require `oat_implement_exit_gate` to remain allowed and fresh. If it becomes
+stale, malformed, pending, or blocked, persist/retain that state, stop the
+sequence, and resume through `oat-project-implement`.
+
 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.
 
-Run final verification (Step 13). Final review must be `passed` before any
+Run final verification (Step 12). Final review must be `passed` and the
+configured implementation exit gate in Step 14 must be allowed 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.
@@ -407,7 +727,52 @@ snapshot. Retain the existing next-step prompt only after final approval when a
 final checkpoint is configured. Under autonomy, the default snapshot above
 always resolves the unset case.
 
-### Step 16: Prompt for Next Steps
+### Step 16: Mark Implementation Complete
+
+Run this step only after the configured gate passes or resolves to a
+policy-allowed disposition, including an allowed no-gate outcome, and the Step
+15 closeout sequence has reached its terminal allowed state. A configured gate
+that is blocked, unresolved, malformed, or stale leaves implementation in
+progress.
+
+Update `"$PROJECT_PATH/implementation.md"` frontmatter:
+
+```yaml
+---
+oat_status: complete
+oat_ready_for: null
+oat_blockers: []
+oat_last_updated: { today }
+oat_current_task_id: null
+---
+```
+
+Update `"$PROJECT_PATH/state.md"`:
+
+- `oat_current_task: null`
+- `oat_last_commit: {final_commit_sha}`
+- `oat_blockers: []`
+- `oat_phase: implement`
+- `oat_phase_status: complete`
+- `oat_project_state_updated: "{ISO 8601 UTC timestamp}"`
+- If `"implement"` is in `oat_hill_checkpoints`, append `"implement"` to
+  `oat_hill_completed`; otherwise leave it unchanged.
+
+Update the current phase and progress content to record that implementation,
+final review, the configured exit gate, and closeout sequencing are complete.
+Then refresh the dashboard and create the required completion bookkeeping
+commit:
+
+```bash
+oat state refresh
+git add "$PROJECT_PATH/implementation.md" "$PROJECT_PATH/state.md" "$PROJECT_PATH/plan.md"
+git diff --cached --quiet || git commit -m "chore(oat): mark implementation complete"
+```
+
+Do not use `git add -A` or glob patterns. Only commit the three project
+artifacts listed above; `.oat/state.md` is a generated, gitignored dashboard.
+
+### Step 17: Prompt for Next Steps
 
 Run the standard next-step prompt only when `OAT_AUTONOMOUS` is not `1`,
 `workflow.postImplementSequence` was unset, and no sequence snapshot was
@@ -449,7 +814,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 17: Output Summary
+### Step 18: Output Summary
 
 ```
 Implementation complete for {project-name}.
@@ -471,39 +836,3 @@ Final review:
 
 Next: Create PR or run the oat-project-pr-final skill (when available)
 ```
-
-### Gate Execution
-
-Before reporting this skill as complete, run the configured gate as the final step:
-
-1. Resolve the gate for this skill:
-
-   ```bash
-   oat gate resolve <this-skill> --json
-   ```
-
-   If the command returns JSON `null`, no gate is configured; 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.
-
-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.
-
-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.
-
-6. Runtime selection note: the step runs the gate `command` as-is and reads no OAT runtime env var. By default, `oat gate review` avoids the resolved producer family. Exact review scopes use a claimable producer identity from the matching dispatch stamp. Final/range reviews aggregate in-scope implementer/fix stamps; when a stamp's producer is not claimable or has an unknown family, its launcher-owned configured target may contribute a lower-confidence family exclusion without becoming runtime identity. If no claimable family remains, selection degrades to same-runtime avoidance. 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.