@open-agent-toolkit/cli 0.2.58 → 0.2.62

package/assets/skills/oat-project-implement/references/phase-execution.md

@@ -15,6 +15,21 @@ optional bounded child for beneficial recon, isolated fanout, or specialist
 work under the shared dispatch contract. The phase implementer remains
 responsible for file boundaries, verification, and task commits.
 
+#### Required Manual or Visual Proof Boundary
+
+Before committing a task that declares required manual or visual proof, the
+active phase executor must inspect its effective runtime tool catalog for an
+available computer-use capability. Do not infer availability from planning
+prose, configuration, or another agent's tools. Use available computer-use for
+required visual proof and record the observed result.
+
+When `OAT_AUTONOMOUS=1` and no autonomous executor can perform the required
+manual or visual criterion, return `BLOCKED` with an explicit
+`IMPLEMENT-20 unverified proof boundary`. Name the criterion and missing
+capability, and stop before committing the task or marking the task or phase
+complete. Never mark unavailable proof deferred-but-verified. Outside autonomy,
+stop at the same proof boundary for operator execution.
+
 #### Resolve and Dispatch the Phase Implementer
 
 Before each phase:
@@ -54,7 +69,7 @@ Before each phase:
      spec: {PROJECT_PATH}/spec.md
      implementation: {PROJECT_PATH}/implementation.md
      discovery: {PROJECT_PATH}/discovery.md
-   workflow_mode: {spec-driven|quick|import}
+   workflow_mode: {spec-driven|quick|import|lite} # lite is always a single phase
    active_provider: {codex|claude|cursor|other}
    phase_base_head: {PHASE_BASE_HEAD}
    worktree: {assigned checkout}

package/assets/skills/oat-project-implement/references/plan-and-resume.md

@@ -110,7 +110,25 @@ Example:
 
 ### Step 2.5: Confirm Plan HiLL Checkpoints
 
-Read `oat_plan_hill_phases` from `"$PROJECT_PATH/plan.md"` frontmatter when present and validate it.
+#### Lite checkpoint bypass
+
+Resolve `oat_workflow_mode` from project state before any generic checkpoint
+field read. When `oat_workflow_mode` is `lite`, resolve checkpoint state as
+`none` without reading or interpreting `oat_plan_hill_phases`; for other modes,
+an empty list means every phase and therefore cannot represent lite's policy.
+Write this plan frontmatter value:
+
+```yaml
+oat_auto_review_at_hill_checkpoints: false # lite: no checkpoints
+```
+
+Skip the workflow preference prompt, standard checkpoint prompt, and
+auto-review preference prompt in both interactive and autonomous runs. Continue
+directly to Step 2.6. The standard root-owned per-phase review and final review
+remain required; only HiLL approval pauses are absent.
+
+For every other workflow mode, read `oat_plan_hill_phases` from
+`"$PROJECT_PATH/plan.md"` frontmatter when present and validate it.
 
 - **Valid format:** JSON-like array of phase IDs (e.g., `["p01","p03"]`)
 - **Allowed pre-confirmation state:** field missing entirely on the first implementation run

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

@@ -1,6 +1,6 @@
 ---
 name: oat-project-import-plan
-version: 1.4.12
+version: 1.4.14
 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
@@ -221,6 +221,44 @@ Dispatch Profile import handling:
   effort preferences.
 - Do not generate Dispatch Profile recommendation rows during import.
 
+### Step 3.5: Lite Offer
+
+After normalization, count exact level-two phase headings. Offer lite only when
+the normalized plan has exactly one `## Phase` heading and
+`oat_plan_parallel_groups` is present as an empty list. Any additional phase or
+any declared parallel group keeps the project in import mode without an offer.
+
+When eligible, use AskUserQuestion with these choices:
+
+1. **Run as lite (Recommended)** — use the single authored plan contract and
+   collapsed single-phase lifecycle.
+2. **Keep import mode** — preserve the standard imported-plan lifecycle.
+
+State the tradeoff verbatim: "Single-phase plans can still be multi-session
+work; choose import mode when the author intentionally kept a longer-running
+project in one phase."
+
+If accepted, set an in-memory `LITE_OFFER_ACCEPTED=true` decision for the
+remaining steps and reshape `plan.md` into the `plan-lite.md` section order:
+
+1. Summary
+2. Decisions
+3. Assumptions
+4. Out of Scope
+5. Validation Criteria
+6. Parallelism
+7. the single Phase and its tasks
+8. Reviews, Implementation Complete, and References
+
+Lift Summary, Decisions, Assumptions, and Out of Scope from the external plan's
+prose when present. Where prose is absent, write an explicit assumption that
+names the missing source detail instead of leaving a template placeholder.
+Derive Validation Criteria from the tasks' verification steps and retain their
+commands or manual checks. Preserve the external source at
+`references/imported-plan.md`, keep `oat_plan_source: imported`, and preserve
+all `oat_import_*` fields; accepting lite changes execution mode, not import
+provenance.
+
 ### Step 4: Update Plan Metadata
 
 Set frontmatter in `"$PROJECT_PATH/plan.md"`:
@@ -295,6 +333,10 @@ Contract` from `oat-project-plan-writing`: load the current
 Provider native plan mode uses this
 same import step and inherits its result.
 
+When the Step 3.5 lite offer was accepted, skip Step 4.25 phase-gate setup
+entirely. Lite has one phase and no phase-gate prompts; continue directly to
+the import-aware plan artifact review while preserving imported provenance.
+
 If `plan.md` already contains an explicit `oat_phase_review_gate`, preserve it
 through the shared contract without probing, prompting, or mutation. Resumed or
 imported explicit values remain authoritative without re-prompting. Otherwise
@@ -307,6 +349,25 @@ This Phase gate review setup is independent from HiLL checkpoints. Do not read o
 change HiLL fields here, and do not add a provider/model `--target` to any
 lifecycle command.
 
+### Step 4.35: Configure Lifecycle Gate Posture
+
+After normalization has produced stable phase IDs and before Step 4.5 starts
+the import-aware plan artifact review, invoke the `Shared Lifecycle Gate Posture Setup Contract` from
+`oat-project-plan-writing`: load the current
+`oat-project-plan-writing/SKILL.md` and follow that contract as written. This
+runs adjacent to, but independently from, the phase gate review setup above.
+
+If `"$PROJECT_PATH/state.md"` already contains an explicit
+`oat_skill_gate_overrides` map, preserve it through the shared contract without
+probing, prompting, or mutation. Otherwise let the contract probe the configured
+gate-aware skills and offer a keep-or-disable choice for each configured gate
+independently.
+
+Persist only disabled choices, and only in `"$PROJECT_PATH/state.md"`. Keeping
+every gate leaves the map absent. Never modify the shared, local, or user
+configuration layers, and never prompt or write a new map in non-interactive
+mode.
+
 ### Step 4.5: Run Import-Aware Plan Artifact Review Loop
 
 Before dispatching the artifact reviewer, invoke the `Managed Dispatch
@@ -392,8 +453,10 @@ them before stopping. Never expose a partially reviewed imported plan to
 
 Set `"$PROJECT_PATH/state.md"` frontmatter:
 
-- `oat_workflow_mode: import`
+- `oat_workflow_mode: lite` when `LITE_OFFER_ACCEPTED=true`; otherwise `oat_workflow_mode: import`
 - `oat_workflow_origin: imported`
+- preserve `oat_import_reference`, `oat_import_source_path`, `oat_import_provider`, and any other `oat_import_*` fields
+- keep `oat_plan_source: imported` in `plan.md` on both branches
 - `oat_phase: plan`
 - `oat_phase_status: complete`
 - `oat_current_task: null`
@@ -452,13 +515,19 @@ fi
 
 Before reporting this skill as complete, run the configured gate as the final step after artifact review, state sync, dashboard refresh, and the import artifact commit:
 
-1. Resolve the gate for this skill:
+1. Resolve the gate for this skill with project context:
 
    ```bash
-   oat gate resolve <this-skill> --json
+   oat gate resolve <this-skill> --project "$PROJECT_PATH" --json
    ```
 
-   If the command returns JSON `null`, no gate is configured; the skill is complete.
+   Handle all three `resolution` values explicitly:
+   - `not_configured`: no gate is configured; the skill is complete.
+   - `configured_disabled_by_project`: the operator disabled this configured gate for this project. Do not launch any process. Emit `configured but disabled by project override`, including the project path and the `projectOverride` source from the envelope, then the skill is complete. A project-disabled gate never enters the passed, missing, or failed branches, and its `configuredGate` is evidence only, never executed.
+   - `configured`: continue with the steps below, executing `effectiveGate` exactly as configured.
+
+   A null, missing, malformed, or unrecognized result is an operational failure
+   that fails closed as unresolved. Never treat it as "no gate configured."
 
 2. Export the resolved project path into the command shell:
 
@@ -528,7 +597,7 @@ Report:
 - ✅ Canonical `plan.md` generated with OAT task structure.
 - ✅ `plan.md` metadata marks `oat_plan_source: imported`.
 - ✅ `plan.md` records the import-aware plan artifact review row unless `workflow.autoArtifactReview.plan` was explicitly disabled.
-- ✅ `state.md` marks `oat_workflow_mode: import`.
+- ✅ `state.md` marks `oat_workflow_mode: lite` when the single-phase lite offer was accepted, otherwise `import`; imported origin and `oat_import_*` provenance remain intact.
 - ✅ `implementation.md` is present and resumable.
 - ✅ `oat_plan_hill_phases` left unset in frontmatter (deferred to `oat-project-implement` Step 2.5).
 - ✅ `## Planning Checklist` items left unchecked (HiLL configuration deferred to implementation).

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

@@ -0,0 +1,467 @@
+---
+name: oat-project-lite
+version: 1.1.1
+description: Use when a single-sitting change needs a critical interview, an approved single-phase plan, and resumable OAT implementation with minimal ceremony.
+argument-hint: '<project-name> ["project description"]'
+oat_gateable: true
+disable-model-invocation: true
+user-invocable: true
+allowed-tools: Read, Write, Bash, Glob, Grep, AskUserQuestion
+---
+
+# Lite Project
+
+Create or resume a project in **lite mode** and produce one approved,
+single-phase `plan.md` for `oat-project-implement`.
+
+## Prerequisites
+
+- A repository initialized for OAT (`.oat/` and `.agents/` exist).
+- A change intended to fit one implementation sitting.
+
+## Mode Assertion
+
+**OAT MODE: Lite**
+
+**Purpose:** Preserve a critical interview, explicit validation, approval,
+resumable task commits, managed review, and a final gate while removing
+multi-phase planning ceremony.
+
+When `OAT_AUTONOMOUS=1`, read `references/docs/autonomy-contract.md` and keep
+`OAT_NON_INTERACTIVE=1` set for the run. Resolve every interactive decision
+through its `LITE-0N` row and stop only where that row declares a boundary:
+
+- `LITE-01`: inherited dirty tree;
+- `LITE-02`: missing project name or description;
+- `LITE-03`: batched critical interview;
+- `LITE-04`: escalation to quick;
+- `LITE-05`: plan approval;
+- `LITE-06`: dispatch-ladder scope;
+- `LITE-07`: project dispatch policy;
+- `LITE-08`: plan artifact-review findings; and
+- `LITE-09`: configured exit gate; and
+- `LITE-10`: configured lifecycle gate posture.
+
+Record each autonomous resolution and its provenance in the artifact named by
+the row. Never persist either autonomy environment signal.
+
+**BLOCKED Activities:**
+
+- No `design.md` or `spec.md` authoring.
+- No multi-phase plan or parallel group.
+- No implementation code changes.
+
+**ALLOWED Activities:**
+
+- Lite scaffolding and project metadata updates.
+- One batched critical interview and a conditional clarification round.
+- One single-phase plan with executable validation criteria.
+- Plan approval, artifact review, dispatch policy resolution, and gate review.
+
+**Self-Correction Protocol:**
+
+- If the work cannot fit one sitting, promote the authored plan to quick mode.
+- If a design decision is not safely resolvable, promote rather than invent it.
+- If implementation code is about to change, stop and hand off to
+  `oat-project-implement`.
+
+## Progress Indicators (User-Facing)
+
+Print this banner once after entry:
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+OAT ▸ LITE
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Use these compact progress lines:
+
+- `[0/7] Checking inherited git state…`
+- `[1/7] Resolving the lite project…`
+- `[2/7] Running the critical interview…`
+- `[3/7] Authoring and checking the single-phase plan…`
+- `[4/7] Confirming plan approval…`
+- `[5/7] Resolving dispatch and reviewing the artifact…`
+- `[6/7] Running the configured gate…`
+- `[7/7] Marking the plan ready for implementation…`
+
+## Artifact Persistence (Required)
+
+- Save every change to `plan.md`, `state.md`, and `implementation.md`
+  immediately. Never leave interview answers only in conversation.
+- After Step 3 authoring, commit the scoped project artifacts before the Step
+  3.5 escalation check and before the Step 4 approval gate. Promotion must
+  consume a durable authored plan.
+- After Step 6 records the structured review disposition, commit the same
+  scoped artifacts before Gate Execution so the gate sees a committed
+  core-artifact baseline.
+- After a receive-eligible gate handoff, commit its receive bookkeeping. The
+  Step 7 completion transition is a separate scoped commit and runs only after
+  the gate passes or resolves.
+- Before each scoped commit, resolve the project scope. Scope resolution fails
+  closed. A synced project uses `oat project push` with the same message;
+  another scope uses only `git add -- "$PROJECT_PATH/plan.md"
+"$PROJECT_PATH/state.md" "$PROJECT_PATH/implementation.md"` followed by a
+  commit when the index is non-empty. Never stage unrelated paths.
+
+## Artifact Hygiene
+
+Artifact hygiene contract: Before finishing or committing, format every file you created or edited. Use the concrete write/fix formatting command supplied by the governing plan, task, or brief. If none is usable, discover the repository's documented write/fix command from applicable `AGENTS.md`/`CLAUDE.md` instructions and relevant package manifests; do not infer or hardcode a formatter. Prefer a file-scoped invocation when supported, and avoid rewriting unrelated files. If no command is discoverable, warn once with `no format command discovered in repo instructions; skipping`, then continue.
+
+After formatting, run only repository checks relevant to the files changed;
+writing lifecycle artifacts does not imply unrelated full test suites.
+
+## Process
+
+### Step 0 (Preflight): Inherited Git State
+
+Before scaffolding, surface the working tree state so unrelated changes don't
+get carried into the project workflow's bookkeeping commits.
+
+1. Run `git status --porcelain`. If empty, continue silently.
+2. If `.oat/sync/manifest.json` is the only entry **and** its two-character
+   status code is either `??` or made up solely of the letter `M` and blanks —
+   a plain modification, staged, unstaged, or both — commit it without asking:
+   `git add -- .oat/sync/manifest.json` then `git commit -m "chore: run sync"`.
+   Report the commit and continue. Every other code falls through, including
+   `MD`, `MT`, `AM`, `RM`, `CM`, and every unmerged state.
+3. Otherwise, present the dirty list to the user and offer commit now, proceed
+   anyway, or abort (`LITE-01`). Note generated provider-view paths when they
+   appear. Commit now stages only the paths the user selected.
+4. When the response channel is unavailable and `OAT_NON_INTERACTIVE=1`, apply
+   `LITE-01`: proceed without staging unrelated files. Destructive cleanup is
+   a stop boundary.
+
+Once the dirty list has been presented, do not advance past this gate without
+an explicit choice. The step 2 manifest-only auto-commit is not a choice point
+and continues on its own.
+
+### Step 0.5: Resolve Active Project or Scaffold Lite
+
+```bash
+PROJECT_PATH=$(oat config get activeProject 2>/dev/null || true)
+PROJECTS_ROOT="${OAT_PROJECTS_ROOT:-$(oat config get projects.root 2>/dev/null || echo ".oat/projects/shared")}"
+PROJECTS_ROOT="${PROJECTS_ROOT%/}"
+```
+
+If no valid active lite project exists, resolve a project name and substantive
+description from `$ARGUMENTS`. A bare name is insufficient. Ask for the
+missing startup input under `LITE-02`; in autonomous mode derive both only from
+the explicit goal and stop if it is not substantive.
+
+Create the project through the canonical scaffolder:
+
+```bash
+oat project new "{project-name}" --mode lite
+PROJECT_PATH=$(oat config get activeProject)
+```
+
+Confirm `state.md` reports `oat_workflow_mode: lite`, `oat_phase: plan`, and
+`oat_phase_status: in_progress`. Do not create discovery or design artifacts.
+
+### Step 1: Read Repository Knowledge
+
+Read repository instructions and the minimum durable context needed for the
+change. Start with root `AGENTS.md`/`CLAUDE.md`. If `.oat/repo/AGENTS.md`
+exists, follow its routing into current state, decisions, and references.
+Inspect only the code surfaces necessary to challenge the request and produce
+an executable plan.
+
+### Step 2: Batched Critical Interview
+
+Present **one batched round** of critical questions covering behavior, scope,
+constraints, decisions, assumptions, exclusions, and proof. Keep the batch
+small and load-bearing. Wait for the complete response before proceeding
+(`LITE-03`).
+
+Use the interview to select exactly one plan content shape: `minimal`,
+`product`, `technical`, or `both`. Product content is required whenever the
+change alters user-visible behavior. Technical content is required when the
+work crosses module boundaries, changes a data or state format, or changes a
+contract consumed by another surface. Select `both` when both triggers apply.
+Select `minimal` only when neither trigger applies.
+
+Run a second round only for questions that the first round's answers created.
+It may clarify those new ambiguities; it must not reopen the whole
+interview. If the user says "just proceed", choose the most careful supported
+interpretation of every open question and record those careful assumptions in
+`plan.md`. Under autonomy, answer from repository evidence and stop on material
+product ambiguity that the evidence cannot resolve.
+
+### Step 3: Author the Single-Phase Plan
+
+Write the interview result into `"$PROJECT_PATH/plan.md"` before any escalation
+or approval decision. Preserve the lite scaffold frontmatter, including
+`oat_template: true`, until Step 7.
+
+The authored plan contains, in order:
+
+1. `## Summary`
+2. `## Decisions`
+3. `## Product Behavior` when the selected shape is `product` or `both`
+4. `## Technical Design` when the selected shape is `technical` or `both`
+5. `## Assumptions`
+6. `## Out of Scope`
+7. `## Validation Criteria`
+8. the required single-phase task list in the `oat-project-plan-writing`
+   grammar
+
+In Decisions, record the selected shape and a one-line rationale tied to the
+triggers above. Product Behavior is a numbered list of testable outcomes, not
+implementation steps. Technical Design describes current operation and the
+proposed changes; include data flow only when state or data crosses a boundary.
+Use file-and-symbol references instead of line numbers. A short snippet is
+allowed only to establish a proposed interface shape.
+
+`minimal` fits a typo or copy-only documentation edit, a version or pin update,
+or a semantics-preserving mechanical rename. A configuration edit that changes
+runtime behavior is not minimal. Keep each optional section to roughly one
+screen. If either needs more space to remove ambiguity, promote to Quick.
+
+Every validation criterion is one bullet and names its proof as a backticked
+command or test name, or a `manual:` visual-proof instruction. A criterion
+without one of those checks is a defect. The task graph has exactly one phase,
+no parallel groups, stable task IDs, declared files, a task-level implementation
+and proof strategy, verification commands, and one commit message per task.
+
+For each task, name the strategy, the observable risk it covers, why the
+evidence is proportionate, and the exact command or `manual:` proof. Supported
+strategies include test-first development, characterization-first work,
+implementation followed by a focused regression, static or build checks, and
+manual or computer-use visual proof. Apply these tiebreakers:
+
+- Static or build checks alone are sufficient only when the change cannot alter
+  runtime behavior.
+- Every behavioral change has at least one proof that fails without the change.
+  For reusable skill, template, or agent wording, a lightweight assertion in
+  the existing `skills.test.ts` suite is proportionate when removing the
+  contract makes it fail; do not create a prose-only fixture or harness.
+- A bug fix preserves a pre-fix reproduction. Waive this only after a bounded
+  attempt proves the original environment or state unavailable; record that
+  evidence, use the strongest alternate regression control, and require
+  reviewer acceptance.
+- A user-interface change requires visual proof. Under autonomy, use available
+  computer-use capability or stop at the `IMPLEMENT-20` proof boundary.
+- Security, provenance, approval, receipt, publication, and other
+  assurance-sensitive contracts require reproduction-grade negative and valid
+  controls.
+- Refactors default to characterization-first unless existing tests already
+  cover the preserved behavior. Documentation-only work may use link, spelling,
+  formatting, or build proof. Behavior-changing configuration requires
+  behavioral proof. Deletions require a negative search plus the relevant build
+  or composition check.
+
+`oat project validate-plan` enforces proof syntax for Validation Criteria, not
+semantic adequacy. Artifact review challenges the selected shape and strategy;
+code review verifies that the declared evidence exists and can prove the claim.
+
+Initialize or update `implementation.md` with the first task pointer while
+keeping implementation in progress. Run:
+
+```bash
+oat project validate-plan --project-path "$PROJECT_PATH"
+```
+
+Format the authored artifacts, resolve project scope, and create the scoped
+pre-approval commit required by Artifact Persistence. Only after that commit is
+durable may Step 3.5 or Step 4 run.
+
+### Step 3.5: Escalation Check
+
+Read the now-populated and committed `plan.md`. Apply `LITE-04`:
+
+- Promote if the task list will not fit one sitting.
+- Promote if an implementation-affecting design decision remains unresolvable.
+- Otherwise record why lite remains appropriate and continue.
+
+Promotion must invoke the real command against the authored project:
+
+```bash
+oat project promote "$PROJECT_PATH" --to quick --json
+```
+
+On success, stop lite execution and point to `oat-project-quick-start`. The
+promotion consumes the authored sections, so interview content is preserved.
+Never simulate the promotion with direct file edits.
+
+### Step 4: Single Approval Gate
+
+This is the only approval gate. Use `AskUserQuestion` exactly once to offer:
+
+1. Approve the recorded requirement set and plan.
+2. Revise the plan, then return to Step 3 and persist it again.
+3. Promote to quick mode through Step 3.5.
+
+Under `OAT_AUTONOMOUS=1`, apply `LITE-05`: auto-confirm the recorded
+requirement set and write the approval decision and evidence into `plan.md`.
+Contradictory or materially incomplete requirements stop at a product-judgment
+boundary. Do not add another approval pause later.
+
+### Step 5: Resolve Dispatch Ceiling
+
+Invoke the complete **Managed Dispatch Readiness and Review Contract** from
+`oat-project-plan-writing`. Load the current `oat-project-plan-writing/SKILL.md`
+and follow that contract as written. Resolve and, when necessary, adopt the
+dispatch ladder before selecting a project policy. Do not copy model names into
+the skill.
+
+For the ladder ownership decision, apply `LITE-06`, which is identical to
+`QS-08`: check existing user, local, then authorized shared configuration in
+that fixed order; skip scalar-blocked candidates; adopt once; re-run the
+preflight resolver. Stop before writing if none is compatible.
+
+Resolve the project policy through `LITE-07`, identical to `QS-09`: preserve an
+explicit or configured policy; unresolved non-interactive state blocks. The
+project policy remains a named ceiling, uncapped managed selection, or host
+inheritance, never a pinned provider target.
+
+Run the reviewer readiness check:
+
+```bash
+oat project dispatch-ceiling resolve --provider "$ACTIVE_PROVIDER" --role reviewer --preflight --json
+```
+
+Lite has no workflow-preference prompt, no phase review setup step, and no
+HiLL setup. Built-in implementation review remains unchanged.
+
+### Step 5.5: Configure Lifecycle Gate Posture
+
+After the complete Lite plan has stable phase IDs and before its plan artifact
+review, invoke the `Shared Lifecycle Gate Posture Setup Contract` from the
+shared planning contract. At this boundary, load the current
+`oat-project-plan-writing/SKILL.md` and follow that contract as written. This
+setup remains independent from Lite's project-aware Gate Execution and does not
+add phase-review or HiLL setup.
+
+Apply `LITE-10` to the shared contract's interaction. When
+`oat_skill_gate_overrides` already exists, preserve it through the shared
+contract without probing, prompting, or mutation. Otherwise, in interactive
+planning, offer Keep or Disable independently for each configured gate.
+Persist only disabled choices to `"$PROJECT_PATH/state.md"`. Never modify the
+shared, local, or user configuration layers. In non-interactive planning,
+preserve configured gates and do not invent or write an override.
+
+### Step 6: Run Plan Artifact Review Loop
+
+Invoke the `Auto Artifact-Review Loop` from `oat-project-plan-writing`. Load
+the current `oat-project-plan-writing/SKILL.md` and follow that loop as written,
+with:
+
+- `target: plan`
+- `type: artifact`
+- `scope: plan`
+- `artifact_path: "$PROJECT_PATH/plan.md"`
+- `oat_output_mode: structured`
+
+The loop is structured and adds no user pause. Resolve
+`workflow.autoArtifactReview.plan`; only explicit `false` skips it. Keep review
+at the current planning parent unless the shared managed-dispatch contract
+proves the exception route is required. Accepted handles are never replaced.
+
+Apply `LITE-08`, using the same shape as `IMPORT-08`: apply only unambiguous
+artifact-local canonicalization fixes, never rewrite source intent, and stop
+on unresolved Critical findings or material ambiguity. Record the actual plan
+review row or explicit skip in `plan.md`.
+
+Format and validate the artifacts again. Resolve scope and create the required
+post-review scoped commit before Gate Execution. Do not mark the plan complete
+yet; the committed baseline remains resumable and `in_progress`.
+
+### Gate Execution
+
+The lite exit-gate review scope is the committed `plan.md`, `state.md`, and
+`implementation.md` bundle. It runs after Step 6 and before Step 7.
+
+1. Resolve the gate for this skill with project context:
+
+   ```bash
+   oat gate resolve <this-skill> --project "$PROJECT_PATH" --json
+   ```
+
+   Handle all three `resolution` values explicitly:
+   - `not_configured`: no gate is configured; proceed directly to the completion steps in Step 7 below.
+   - `configured_disabled_by_project`: the operator disabled this configured gate for this project. Do not launch any process. Emit `configured but disabled by project override`, including the project path and the `projectOverride` source from the envelope, then proceed directly to the completion steps in Step 7 below. A project-disabled gate never enters the passed, missing, or failed branches, and its `configuredGate` is evidence only, never executed.
+   - `configured`: continue with the steps below, executing `effectiveGate` exactly as configured.
+
+   A null, missing, malformed, or unrecognized result is an operational failure
+   that fails closed as unresolved. Never treat it as "no gate configured."
+
+2. Export `PROJECT_PATH`. If the stored command invokes lifecycle gate review,
+   its canonical form is:
+
+   ```bash
+   oat --json gate review --project "$PROJECT_PATH" ...
+   ```
+
+   Use global `--json` before `gate review`. Reject `oat gate
+review ...` without the global `--json` placement. Reusable declarations
+   must not contain `--target <id>` or add it at runtime. Stop and migrate an invalid stored
+   declaration before execution; never inject or append execution-time argv.
+
+3. When the current planning parent's model identity is available and the
+   command is `oat gate review`, export
+   `OAT_GATE_PRODUCER_IDENTITY=<model>:declared` only for that invocation.
+   Otherwise ensure it is unset. Do not persist it or alter the command.
+4. Execute the resolved command exactly as configured. Capture stdout, stderr,
+   exit code, and structured JSON. Exit code alone never authorizes receipt.
+5. Invoke receive only when all three conditions hold: status is `ok` or
+   `blocked`, `receiveEligible: true`, and a non-null `handoff` corroborates
+   the artifact. `receiveEligible: false` is a hard stop.
+   `targeting_correlation_failed` is never receivable. Correct and revalidate
+   `artifact_validation_failed` before receipt. Unknown, contradictory, or
+   malformed results stop.
+6. For a validated, receive-eligible `blocked` result, apply `LITE-09`:
+   - `block`: remediate and retry up to the configured limit;
+   - `prompt`: report an unresolved human boundary;
+   - `warn`: record the validated gate failure and continue.
+
+Operational, validation, targeting, launch, and receive failures never inherit
+`onFailure` continuation semantics.
+
+A gate that ends in `block` after attempts are exhausted, or at an unresolved
+`prompt` boundary, means the completion steps below MUST NOT run; the project
+stays `in_progress` and resumable. Persist eligible receive bookkeeping in its
+own scoped commit. A no-gate result is not success output; it continues to
+Step 7.
+
+### Step 7: Mark Plan Complete and Hand Off
+
+Run only after the configured gate passes or resolves according to its
+validated `onFailure` policy.
+
+Update `plan.md` atomically:
+
+- `oat_status: complete`
+- `oat_ready_for: oat-project-implement`
+- `oat_phase_status: complete`
+- `oat_template: false`
+
+Update `state.md`:
+
+- `oat_workflow_mode: lite`
+- `oat_phase: plan`
+- `oat_phase_status: complete`
+- `oat_current_task: null`
+- `oat_project_state_updated: "{ISO 8601 UTC timestamp}"`
+
+Ensure `implementation.md` is present and points to the plan's first task with
+status `in_progress`. Run `oat state refresh`, format the scoped artifacts,
+resolve project scope, and create the separate completion commit. Then report:
+
+```text
+Lite plan approved and ready. Next: oat-project-implement
+```
+
+## Success Criteria
+
+- Exactly one batched interview ran, with only a causally created conditional
+  clarification round.
+- The plan contains Summary, Decisions, Assumptions, Out of Scope, executable
+  Validation Criteria, and exactly one sequential phase.
+- The authored plan was committed before escalation and approval.
+- Exactly one approval gate ran.
+- No spec, design, phase review setup, or HiLL setup was added.
+- Reviewer dispatch readiness and the structured artifact-review loop resolved.
+- The configured gate saw a committed core-artifact baseline and used canonical
+  global `--json` placement without `--target`.
+- Completion state was committed separately and routes to
+  `oat-project-implement`.