@open-agent-toolkit/cli 0.2.58 → 0.2.62

package/assets/agents/oat-phase-implementer.md

@@ -1,6 +1,6 @@
 ---
 name: oat-phase-implementer
-version: 1.1.3
+version: 1.1.5
 description: Implements one plan phase end-to-end, commits each task separately, self-checks between tasks, and handles bounded review fixes when resumed by oat-project-implement.
 tools: Read, Write, Edit, Bash, Grep, Glob, Task
 color: cyan
@@ -29,7 +29,7 @@ The root supplies:
 - `mode`: `implement`, `fix`, or `recover`;
 - `artifact_paths`: available plan, design, spec, discovery, implementation,
   and imported-plan paths;
-- `workflow_mode`: `spec-driven`, `quick`, or `import`;
+- `workflow_mode`: `spec-driven`, `quick`, `import`, or `lite`;
 - `commit_convention`: exact task/fix commit convention;
 - `phase_base_head`: root-recorded HEAD before phase dispatch;
 - `worktree`: assigned phase worktree or orchestration checkout;
@@ -120,6 +120,11 @@ Read each required artifact once at phase start:
 - `quick`: phase section from plan and discovery; design/spec when present;
 - `import`: phase section from plan and imported plan; design/spec when
   present.
+- `lite`: read the whole plan.md requirements contract: the assigned phase
+  section plus Summary, Decisions, Assumptions, Out of Scope, and Validation
+  Criteria, and the Product Behavior and/or Technical Design selected by its
+  recorded `minimal`, `product`, `technical`, or `both` content shape.
+  Discovery, spec, and design are absent by design.
 
 Extract all phase tasks, dependency order, file boundaries, verification
 commands, commit messages, and phase-wide verification before editing.
@@ -402,7 +407,20 @@ For every task:
 
 1. Record `PRE_TASK_HEAD`.
 2. Read the task steps and declared file boundary.
-3. Follow RED/GREEN/refactor ordering when specified.
+3. Execute the task's declared implementation and proof strategy without
+   silently substituting TDD. Follow RED/GREEN/refactor ordering only when the
+   selected strategy specifies it.
+   For required manual or visual proof, inspect the effective runtime tool
+   catalog for an available computer-use capability; never infer availability
+   from planning prose, configuration, or another agent's tools. Use available
+   computer-use for required visual proof and record the performed proof. When
+   no available executor can perform the criterion, stop before committing the
+   task or marking the task or phase complete. Under `OAT_AUTONOMOUS=1`, return
+   `BLOCKED` with an explicit `IMPLEMENT-20 unverified proof boundary` and name
+   the criterion and missing capability. In an interactive run, return
+   `NEEDS_CONTEXT` and wait for the operator to execute the criterion or direct
+   the next action. Neither path may mark unavailable proof
+   deferred-but-verified.
 4. Implement only that task. Optional nested help does not transfer task
    ownership or commit authority.
 5. Apply the Prevention and Post-Commit Recovery ordering: format, run every
@@ -440,7 +458,12 @@ After all task commits:
 - apply the same post-commit recovery contract to an eligible phase-level
   composition failure;
 - verify task outputs compose correctly;
-- compare the phase result with design/spec/discovery;
+- compare the phase result with the requirements source selected by workflow
+  mode:
+  - `lite`: the complete `plan.md` requirements contract loaded at phase start;
+  - `spec-driven`: `plan.md`, `design.md`, and `spec.md`;
+  - `quick`: `plan.md` and `discovery.md`, plus design/spec when present; and
+  - `import`: `plan.md` and the imported plan, plus design/spec when present;
 - confirm no task boundary or dependency was missed; and
 - report Medium/Minor concerns without launching a reviewer.
 

package/assets/agents/oat-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: oat-reviewer
-version: 1.2.1
+version: 1.2.3
 description: Unified reviewer for OAT projects - mode-aware verification of requirements/design alignment and code quality. Writes a review artifact to disk by default, or returns structured findings in-memory when dispatched in structured-output mode.
 tools: Read, Bash, Grep, Glob, Write, Task
 color: yellow
@@ -50,7 +50,7 @@ You will be given a "Review Scope" block including:
 - **commits/range**: Git commits or SHA range for changed files. For code review, this is the authoritative review surface.
 - **files_changed**: Optional orientation hint listing files believed to be modified in scope. If this disagrees with the commit range, trust the commit range.
 - **analysis_artifact**: For `type: analysis`, path to the severity-rated analysis artifact to fact-check.
-- **workflow_mode**: `spec-driven` | `quick` | `import` (default to `spec-driven` if absent)
+- **workflow_mode**: `spec-driven` | `quick` | `import` | `lite` (default to `spec-driven` if absent)
 - **artifact_paths**: Paths to available artifacts (spec/design/plan/implementation/discovery/import reference)
 - **tasks_in_scope**: Task IDs being reviewed (if task/phase scope)
 - **oat_output_mode**: Optional output-sink selector. Absent (or any value other than `structured`) means **artifact mode** — write the review artifact to disk per Step 8. `structured` means **structured-output mode** — return a `StructuredFindings` object in-memory and write NO artifact file (see **Structured-Output Mode**). This key parallels the existing `oat_review_invocation` dispatch-payload naming.
@@ -122,6 +122,7 @@ Use workflow mode to determine required evidence:
 - **spec-driven**: `spec.md`, `design.md`, `plan.md` are expected.
 - **quick**: `discovery.md` + `plan.md` are expected (`spec.md`/`design.md` optional if present).
 - **import**: `plan.md` is expected (`references/imported-plan.md` preferred; `spec.md`/`design.md` optional).
+- **lite**: `plan.md` and `implementation.md` are expected; discovery, spec, and design are absent by design.
 
 Do not mark missing optional artifacts as findings.
 If required artifacts for the mode are unexpectedly missing, record a workflow contract gap.
@@ -144,6 +145,7 @@ Read available artifacts to understand what SHOULD have been built:
    - `spec-driven`: read `spec.md` and `design.md`.
    - `quick`: read `discovery.md` and `plan.md`; read `spec.md`/`design.md` only if they exist.
    - `import`: read `plan.md` and `references/imported-plan.md` (if present); read `spec.md`/`design.md` only if they exist.
+   - `lite`: read `plan.md` and `implementation.md`; do not require discovery, spec, design, or an import reference.
 3. For `type: analysis`, read `analysis_artifact` and then inspect only the cited evidence sources needed to verify its findings:
    - `scope: docs`: consult the docs contract, docs navigation/index files, and cited docs source files relevant to the analysis.
    - `scope: agent-instructions`: consult the repo/root instruction files, provider instruction files, and cited skill/agent instruction files relevant to the analysis.
@@ -168,6 +170,7 @@ For each requirement in scope, use the best available requirement source by mode
 - `spec-driven`: `spec.md` (primary), `design.md` mapping (secondary)
 - `quick`: `discovery.md` + `plan.md`
 - `import`: normalized `plan.md` + `references/imported-plan.md` (if present)
+- `lite`: the requirements contract in `plan.md`: Summary, Decisions, Assumptions, Out of Scope, and Validation Criteria. Also use Product Behavior and/or Technical Design when selected by the recorded `minimal`, `product`, `technical`, or `both` content shape.
 
 Then verify:
 
@@ -176,10 +179,17 @@ Then verify:
    - Check acceptance criteria are met
    - If missing: add to Critical findings
 
-2. **Is the Verification satisfied?**
-   - Check if tests exist matching declared verification intent in available artifacts
-   - If `design.md` exists, cross-reference Requirement-to-Test Mapping
-   - If tests missing for P0 requirements: add to Critical findings
+2. **Is the applicable verification intent satisfied?**
+   - First identify the verification intent declared by the applicable workflow
+     artifacts. When that contract declares an `Implementation and Proof
+Strategy`, check whether the evidence matches the declared strategy, covers
+     its observable risk, and is capable of failing when the claim is false.
+   - A missing or unjustified proof strategy is a finding only when the
+     applicable workflow artifact declares that strategy. When it does not,
+     review the plan's existing verification commands and produced evidence
+     without inventing a missing strategy field.
+   - If `design.md` exists, cross-reference Requirement-to-Test Mapping.
+   - The absence of an automated test alone is not a finding.
 
 3. **Is there extra work?**
    - Code that doesn't map to any requirement
@@ -207,6 +217,7 @@ Treat the artifact as a product deliverable. Verify it is:
      - `spec-driven`: spec + design
      - `quick`: discovery (+ spec/design if present)
      - `import`: imported-plan reference (+ discovery/spec/design if present)
+     - `lite`: plan.md Summary, Decisions, Assumptions, Out of Scope, and Validation Criteria. Also review the Product Behavior and/or Technical Design required by its recorded content shape; challenge `minimal` when an observable shape trigger applies.
    - For import-mode `plan` reviews, bias findings toward canonical-format conformance and completeness. Do not rewrite the imported author's intent merely to match OAT house style.
 
 4. **Actionable**
@@ -220,7 +231,7 @@ Treat the artifact as a product deliverable. Verify it is:
    - Stable task IDs: task headings use `pNN-tNN`, IDs are monotonic within each phase, and review-generated tasks do not reuse prior IDs.
    - Required sections: the plan includes Reviews, Implementation Complete, and References sections without placeholder-only critical content.
    - Review-table preservation: existing review rows are preserved; never require deleting rows to "clean up" the table.
-   - Task atomicity and verifiability: each task is independently committable, has bounded file scope, and declares verification that can actually be run.
+   - Task atomicity and verifiability: each task is independently committable, has bounded file scope, and has executable verification intent. Require a proportionate implementation and proof strategy only when the applicable workflow plan contract declares it; otherwise review the task's existing verification commands and evidence.
    - Coverage of design/discovery: every in-scope design component or discovery decision is mapped to at least one task or explicitly deferred/out of scope.
    - Parallelism-claim sanity: any parallel phase group or parallelism statement is consistent with declared file boundaries and dependency order.
 
@@ -228,7 +239,7 @@ Treat the artifact as a product deliverable. Verify it is:
 
 This step applies to **code reviews** only.
 
-If `design.md` is absent in quick/import mode, mark design alignment as "not applicable (design artifact not present for mode)" and continue.
+If `design.md` is absent in quick/import/lite mode, mark design alignment as "not applicable (design artifact not present for mode)" and continue.
 
 For each design decision relevant to scope:
 
@@ -283,10 +294,10 @@ Pragmatic code quality review (not exhaustive):
    - Off-by-one errors, null handling
    - Missing error handling for likely failures
 
-2. **Test coverage**
-   - Critical paths have tests
-   - Edge cases covered
-   - Unhappy paths tested
+2. **Evidence coverage**
+   - Critical paths have evidence matching the declared proof strategy
+   - Edge cases are covered where relevant
+   - Behavioral claims have a control that fails without the change
 
 3. **Security**
    - Input validation at boundaries
@@ -307,14 +318,14 @@ Group findings by severity:
 - Missing P0 requirements
 - Security vulnerabilities
 - Broken functionality
-- Missing tests for critical paths
+- Missing capable evidence for critical paths
 
 **Important** (should fix before merge)
 
 - Missing P1 requirements
 - Missing error handling
 - Significant maintainability issues
-- Missing tests for important paths
+- Missing capable evidence for important paths
 - Stale spec/design/plan artifact that conflicts with a defensible implementation and should be aligned before closeout
 
 **Medium** (default fix before pass)

package/assets/bundle-metadata.json

@@ -1,4 +1,4 @@
 {
   "schemaVersion": 1,
-  "oatVersion": "0.2.58"
+  "oatVersion": "0.2.62"
 }

package/assets/docs/cli-utilities/configuration.md

@@ -367,6 +367,22 @@ Repo-local and user config can also hold workflow defaults, including
 example, one user may prefer `claude -p` as a gate target while another prefers
 `codex exec`.
 
+### Per-project gate posture
+
+Project state is a separate surface from the five config layers. One project can
+disable a configured lifecycle gate for itself through
+`oat_skill_gate_overrides` in that project's `state.md`, keyed by gate-aware
+skill name with the single permitted value `disabled`.
+
+Config layers decide whether a gate exists; the project override then decides
+whether an existing gate runs for that project. An override never creates
+configuration, never mutates any config layer, and is never written by a
+non-interactive run. Resolve it with
+`oat gate resolve <skill> --project <path-or-name> --json`; without `--project`
+the command keeps its original raw output. See
+[Workflow gates](./workflow-gates.md) for the full resolution envelope and the
+phase-review and autonomous exclusions.
+
 In practice, you usually inspect these via:
 
 ```bash

package/assets/docs/cli-utilities/workflow-gates.md

@@ -62,12 +62,89 @@ A valid command is stored byte-for-byte. `oat gate resolve` returns that exact
 string, and the lifecycle executes it unchanged; OAT does not inject, reorder,
 or rewrite its shell arguments.
 
-`oat-project-plan`, `oat-project-implement`, `oat-project-quick-start`, and
-`oat-project-import-plan` are currently gate-aware. Gate awareness is declared
+`oat-project-plan`, `oat-project-implement`, `oat-project-quick-start`,
+`oat-project-lite`, and `oat-project-import-plan` are currently gate-aware. Gate awareness is declared
 in skill frontmatter with `oat_gateable: true`, and
 `oat internal validate-oat-skills` warns when config targets a missing or
 non-gateable skill.
 
+### Per-project gate overrides
+
+Gate configuration is shared, but one project can opt out of a configured
+lifecycle gate without changing any config layer. The override lives only in
+that project's `state.md`:
+
+```yaml
+oat_skill_gate_overrides:
+  oat-project-implement: disabled
+```
+
+The map is strict. Keys are gate-aware skill names and the only permitted value
+is the literal `disabled`. Arrays, booleans, `enabled`, unknown values,
+duplicate keys, and malformed maps are rejected with the offending project state
+path. An absent map means follow configuration; keeping every gate leaves the
+map absent.
+
+Override keys are accepted only for skills that declare `oat_gateable: true`.
+A configured gate may still be resolved and executed for a lifecycle skill that
+is not gate-aware — `oat-project-discover` and `oat-project-design` are the
+current examples — but because no override key for such a skill is accepted,
+their configured gates apply to every project and cannot be disabled per
+project.
+
+Precedence is layered, not merged: config layers decide whether a gate exists
+at all, and the project override then decides whether an existing gate runs for
+that project. An override never creates configuration, so a project may record
+an override for a skill that has no configured gate; the gate stays absent.
+Overrides never mutate shared, local, or user config, and config changes never
+rewrite a project's override.
+
+Interactive project setup offers a keep-or-disable choice per configured gate,
+one skill at a time; there is no single switch that disables every gate.
+Non-interactive runs never prompt and never write a new map, and an explicit
+existing map is preserved unchanged on resume and import.
+
+Resolution is opt-in. Without `--project`, `oat gate resolve` keeps returning
+the raw `GateConfig | null` that existing consumers parse:
+
+```bash
+oat gate resolve oat-project-implement --json
+```
+
+With project context it returns a discriminated envelope instead:
+
+```bash
+oat gate resolve oat-project-implement --project "$PROJECT_PATH" --json
+```
+
+The envelope's `resolution` is one of three values:
+
+| `resolution`                     | Meaning                                   | `configuredGate` | `effectiveGate` |
+| -------------------------------- | ----------------------------------------- | ---------------- | --------------- |
+| `configured`                     | A configured gate runs for this project.  | the gate         | the gate        |
+| `configured_disabled_by_project` | Configured, but this project disabled it. | the gate         | `null`          |
+| `not_configured`                 | No gate is configured for this skill.     | `null`           | `null`          |
+
+`configured_disabled_by_project` retains `configuredGate` so evidence of a
+deliberate opt-out can never be mistaken for absent configuration. It also
+carries `configSource` and a `projectOverride` record naming the
+`state.md:oat_skill_gate_overrides` source.
+
+`configSource` reports the layer that owned the decision. For
+`not_configured` it is the layer that explicitly declared the skill `null`, and
+`null` only when no layer mentions the skill at all, so a deliberate
+layer-level disable stays distinguishable from an absent declaration.
+`configuredGate` is `null` in both cases, so neither reads as configured.
+
+Disabled is a posture, not an outcome. A project-disabled gate launches no
+process and never enters the passed, missing, or failed branches. Project
+progress reports every active override by skill key so the deliberate posture
+stays visible to reviewers.
+
+This mechanism covers configured lifecycle skill gates only. It does not affect
+the optional `oat_phase_review_gate`, HiLL policy, or autonomous design-gate
+behavior, and it cannot disable every gate with one project-wide boolean.
+
 ### Implementation exit-gate closeout
 
 For `oat-project-implement`, the configured skill gate is a final, resumable
@@ -82,14 +159,22 @@ configured command. The state records:
 
 - `pending`, `allowed`, `blocked`, or `stale` status;
 - a `configured` or `no_gate` resolution;
-- `passed`, `warned`, `prompt_approved`, or `no_gate` allowed dispositions;
+- `passed`, `warned`, `prompt_approved`, `project_disabled`, or `no_gate`
+  allowed dispositions;
 - the resolved configuration fingerprint, reviewed HEAD, implementation
   fingerprint, gate run, envelope, and receive provenance; and
 - launch and receive reconciliation data needed to resume without duplicating
   an accepted run or completed receive.
 
-A `null` resolution is explicit success for that closeout generation:
-`allowed/no_gate` with `disposition: no_gate`. Configured success becomes
+Only a `not_configured` resolution is explicit success for that closeout
+generation: `allowed/no_gate` with `disposition: no_gate`. A null, missing,
+malformed, or unrecognized resolver result fails closed as unresolved and is
+never treated as no gate. A gate this project disabled
+persists `allowed/configured` with `disposition: project_disabled`, the
+configured command retained as never-executed evidence, null launch and receive
+provenance, and a `project_override` record. `config_fingerprint` covers the
+resolved override state, so re-enabling the gate changes the fingerprint and a
+stored `project_disabled` result is routed as stale instead of reused. Configured success becomes
 `allowed/passed`; `warn` and an explicit `prompt` continuation persist their
 own allowed dispositions only for a validated, receive-eligible `blocked`
 envelope after eligible receive completes durably. Unresolved, malformed,
@@ -525,7 +610,7 @@ oat gate set oat-project-implement \
 ```
 
 Apply the same command shape to `oat-project-plan`,
-`oat-project-quick-start`, and `oat-project-import-plan` when those lifecycle
+`oat-project-quick-start`, `oat-project-lite`, and `oat-project-import-plan` when those lifecycle
 skills have configured review gates. Do not add `--target`; explicit targets
 remain manual/debug or deliberate local/user-specific overrides.
 

package/assets/docs/contributing/skills.md

@@ -277,15 +277,37 @@ Use `create-agnostic-skill` or `create-oat-skill` as the starting point; both in
 
 ## Gate-aware skills
 
-A skill that supports configured final gates must declare `oat_gateable: true`
+A skill that supports configured final gates should declare `oat_gateable: true`
 in frontmatter and include a final Gate Execution step in its process contract.
-Without both pieces, a configured `workflow.gates.skills.<skill>` entry is a
-validation warning rather than an executable contract.
+Without both pieces, a configured `workflow.gates.skills.<skill>` entry raises a
+`Configured gate targets skill without oat_gateable: true` validation warning.
+
+The warning does not make the gate inert. `oat_gateable` governs per-project
+override eligibility, not executability: `oat gate resolve` runs the same
+lookup for every skill name, so a configured gate on a non-gate-aware skill
+still resolves as `configured` and still executes if that skill carries a Gate
+Execution step. `oat-project-discover` and `oat-project-design` are the current
+examples. Because no `oat_skill_gate_overrides` key is accepted for a skill
+outside `oat_gateable`, their configured gates apply to every project and can
+never resolve `configured_disabled_by_project`. Prefer declaring
+`oat_gateable: true` for any skill whose gate should be disableable per project.
 
 The Gate Execution step should:
 
-1. Run `oat gate resolve <this-skill> --json`.
-2. Treat `null` as "no gate configured."
+1. Run `oat gate resolve <this-skill> --project "$PROJECT_PATH" --json`
+   (`$PROJECT_PATH` is the resolved project path exported in step 3).
+   Project context is required. Without `--project` the command returns the
+   legacy raw gate and can never report a project override, so the skill would
+   silently run a gate the project deliberately disabled.
+2. Handle all three `resolution` values explicitly:
+   - `configured` - run `effectiveGate` exactly as configured.
+   - `configured_disabled_by_project` - the project disabled this configured gate. Do not launch any process; emit `configured but disabled by project override`, including the project path and the `projectOverride` source, and finish the skill. The returned `configuredGate` is evidence only and is never executed.
+   - `not_configured` - no gate is configured; finish the skill.
+
+   A null, missing, malformed, or unrecognized result is an operational failure
+   that fails closed as unresolved. Never treat it as "no gate configured." See
+   [Per-project gate overrides](../cli-utilities/workflow-gates.md#per-project-gate-overrides).
+
 3. Export the resolved path with `export PROJECT_PATH` before launching the
    command shell.
 4. For `oat gate review`, require the configured command to use

package/assets/docs/provider-sync/commands.md

@@ -88,6 +88,29 @@ Key behavior:
   `versionSkew` array (`{ scope, producingVersion, invokingVersion }`) in both
   `--dry-run` and apply envelopes; a scope without skew is omitted from the
   array.
+- When a run's only effect is that restamp — no planned operations and no
+  failures, but skew present — apply reports
+  `Manifest version refreshed; no content changes required.` instead of
+  `No changes required.`, so a manifest write is never described as a no-op.
+
+`oat sync` is not the only command that replaces a manifest's producer version.
+`oat init`, `oat remove skill`, and `oat status` each capture the manifest's
+pre-mutation `oatVersion` while loading and planning, compare it with the
+invoking CLI version, and log the same advisory immediately before a qualifying
+save when the two differ:
+
+```text
+Manifest version restamp [init user]: manifest produced by oat "0.2.58" will be restamped to oat "0.2.59".
+```
+
+The advisory sits immediately before the save, so a run that aborts earlier
+never announces a restamp it did not perform; a save that fails after the
+advisory still leaves the manifest unrestamped. An equal or absent version stays
+quiet. JSON mode suppresses the human warning; `oat init` and `oat remove skill`
+report the applied restamps under a top-level `manifestVersionRestamps` array of
+`{ scope, producingVersion, invokingVersion }` entries. The `oat remove skill`
+dry-run payload omits the field rather than naming a restamp no save will
+perform.
 
 Preview project and user cleanup before applying it:
 

package/assets/docs/reference/cli-reference.md

@@ -56,8 +56,14 @@ The first practical expansion path is to keep improving the existing owners: [Do
 
 Notable commands introduced in the current CLI surface:
 
-- `oat project new <slug> --scope shared|local|synced [--force]` - create a
-  project in an explicit scope. Without `--scope`, creation uses
+- `oat project new <slug> [--mode spec-driven|quick|import|lite] --scope shared|local|synced [--force]` - create a
+  project in an explicit scope. `--mode` selects the workflow mode and therefore
+  which artifacts are scaffolded; it defaults to `spec-driven`. Use `quick` for a
+  bounded feature with clear requirements, `import` to normalize an externally
+  authored plan, and `lite` for a single-sitting change that scaffolds only
+  `plan.md`, `state.md`, and `implementation.md`. See
+  [Lifecycle](../workflows/projects/lifecycle.md) for the per-lane flow. Without
+  `--scope`, creation uses
   `projects.defaultScope`, which defaults to `synced`. Project slugs are
   unique across all scopes by default, including recorded or remotely
   published synced projects. `--force` deliberately permits a duplicate; use
@@ -133,13 +139,14 @@ Notable commands introduced in the current CLI surface:
 - `oat project status --field <path>` - print one arbitrary dot-path field from the same status payload, e.g. `project.workflowMode` or `project.timestamps.stateUpdated`. Missing/null fields print `null`; object and array fields print compact JSON.
 - `oat project status --project-path <path>` - read from a repo-relative or absolute project path instead of `.oat/config.local.json`'s active project pointer. Combine it with `--field` or `--shell` when a skill has already resolved the target project path.
 - `oat project status --shell NAME=path ...` - print shell-safe assignments for one or more fields from one status read, e.g. `WORKFLOW_MODE='quick'`. This is the preferred multi-field read API for skills. See [Writing Skills → Reading project state](../contributing/skills.md#reading-project-state) for examples and the `npx`-backed `oat` shim contract.
+- `oat project promote <project-path> --to quick [--json]` - promote an authored lite project to quick mode. The command derives `discovery.md` from the lite plan's Summary, Decisions, Assumptions, Out of Scope, and Validation Criteria; carries Product Behavior into Success Criteria and Technical Design into a carried-forward discovery section when those adaptive sections are present; preserves the original as `references/lite-plan.md`; and scaffolds a fresh quick `plan.md`. It refuses unsupported targets, non-lite or unreadable projects, an existing lite-plan reference, invalid authored sections, unresolved scope, unavailable templates, failed writes, or failed persistence. JSON output is `{ status: "promoted" | "refused", reason, files }`; `reason` is the stable categorical contract and refused results exit non-zero.
 - `oat review latest --json` - find the newest review artifact by `oat_generated_at`, scanning the active or specified project's `reviews/` and `reviews/archived/` directories plus ad-hoc review locations. Same-time candidates use target priority, then lifecycle recency (`final` > higher phase/task > lower phase/task). The JSON contract returns `path`, `scope`, `generatedAt`, `kind` (`project` or `adhoc`), `archived`, and `actionable`, with `null` values when no review exists. Archived project reviews remain discoverable as history but return `actionable: false`.
 - `oat project list --json` - summary state for tracked projects under the configured projects root
 - `oat project complete-state <project-path>` - apply the canonical completed-state mutation to a project's `state.md`; used by `oat-project-complete` during lifecycle closeout
 - `oat project archive [project-path] [--project-recap-run <project-relative-path>] [--no-commit]` - archive a tracked project through the same local move, summary export, and configured S3 upload path used by completion. When omitted, the project path falls back to the active project. The optional recap path must identify a `project-recap` run inside the project's `explainers/` directory. Archive stages the selected complete package into `.oat/repo/reference/project-recaps/<YYYYMMDD-project-slug>/`, verifies every manifest-declared immutable file byte, then atomically installs the export before deleting the active project. Existing destinations, incomplete legacy hash coverage, stale bytes, path escapes, and recipe mismatches fail without removing the active project. For synced projects, a configured S3 upload must succeed before terminal cleanup. Successful closeout makes `refs/oat/completed/<project>` authoritative, deletes the tracked JSON record and nested checkout, and leaves archive metadata sufficient for an idempotent recordless retry. Legacy complete records receive a cleanup diagnosis rather than pull/open guidance. With `--json`, the terminal receipt reports `completedRef`, `verifiedSourceSha`, whether `activeAliasDisposition` was `retained` or `removed`, whether `recordRetired` completed, and the parent `lifecycleCommit`. `--no-commit` is a manual/library-only option: for a synced project it still removes the checkout but deliberately leaves `lifecycleCommit` null. Never pass it through `oat-project-complete`, which requires that receipt.
 - `oat repo archive sync [project-name]` - hydrate archived project snapshots from the configured repo-scoped S3 archive into `.oat/projects/archived/`. The old `oat project archive sync` path remains as a deprecated shim.
 - `oat project dispatch record --event-file <json-file-or-dash> [--project <project-path>]` - validate one generic dispatch record plus its namespaced OAT evidence event, and persist it into the project's append-only `dispatch/` journal. Omit `--project` to validate without persisting. Revision 1 is `dispatch/<request-id>.json` and every later revision is `dispatch/<request-id>@<NNNN>.json`; superseded revisions are never replaced or removed. The command validates and records evidence only — it never launches a provider. A `runtime-observation` event may carry either a finished `observation` or the provider `metadata` envelope (`provider`, `observedAt`, `entries`) to normalize, but not both. `entries` may be raw provider output: they are projected through the owning parser's allowlist, are never persisted, and both forms have their `match` derived from the record's configured invocation rather than trusted from the caller, with the observation's `provider` bound to the record's. With `--json`, the result adds `runtimeIdentity` with separate `configured` and `observed` objects plus a `match` of `matching`, `mismatching`, `not-comparable`, or `null`; observation is corroboration only and never overrides configured invocation. Error output is redacted on a best-effort basis; absolute paths in identity fields are rejected outright, while some prose forms (colon-prefixed, URL routes) can survive. See [Evidence Layers](../workflows/projects/evidence-layers.md).
-- `oat project validate-plan --project-path <path>` - validates `oat_plan_parallel_groups` metadata in `plan.md`; exits non-zero on invalid. See [Implementation Execution](../workflows/projects/implementation-execution.md#parallel-phase-groups).
+- `oat project validate-plan --project-path <path>` - validates `oat_plan_parallel_groups` metadata in `plan.md`; exits non-zero on invalid. Lite plans must contain exactly one phase, declare no parallel groups, and give every Validation Criteria bullet either a backticked command or a `manual:` instruction. See [Implementation Execution](../workflows/projects/implementation-execution.md#parallel-phase-groups).
 - `oat project log append|check|synthesize|rollup` - manage the optional append-only project observation log: append validated judgment or structural entries, inspect grammar and synthesis status, complete end-of-run synthesis, and roll observations into `summary.md` plus the configured repository ledger. See [Project Log](../cli-utilities/project-log.md).
 - `oat project set-mode` — deprecated no-op. Execution mode is no longer user-selectable; emits a deprecation warning and preserves the `--json` contract.
 - `oat gate review <prompt...>` - run a stateful, headless OAT review through the target registry, parse the produced review artifact, and exit nonzero for configured blocking findings. `--timeout-ms <milliseconds>` overrides target, `workflow.gateTimeouts`, environment, and scope defaults; accepted values are 1,000–14,400,000. Final/phase/range code reviews default to 30 minutes, while task code and artifact reviews default to 15 minutes. With `--json`, the result envelope on exit is the canonical completion signal: `status` is `ok` | `blocked` | `review_failed` | `artifact_missing` | `artifact_validation_failed` | `targeting_correlation_failed`, alongside `runId`, `generatedAt`, and `artifactPath` when available. `artifact_missing` means an accepted child exited cleanly without an artifact; fix synchronous review/artifact completion and start a new run, without review-receive or same-run remediation. For `targeting_correlation_failed`, correct the project declaration or artifact routing and start a new run; do not run review-receive even if an artifact path is present. For `artifact_validation_failed`, correct the artifact and rerun the gate until it revalidates as `ok` or `blocked`. Invoke `oat-project-review-receive` only when all three conditions hold: `status` is `ok` or `blocked`, `receiveEligible` is `true`, and `handoff` is non-null. `review_failed` may include structured `refusal`, `noOutputProduced`, and metadata-only `activityEvidence`; these diagnostic fields never make a run receive-eligible. After a timeout, a validated run-correlated artifact returns the ordinary `ok` or `blocked` envelope with additive `lateCompletion: true`. Duplicate run-ID matches or a changed artifact with a mismatched run ID retain `targeting_correlation_failed` and `receiveEligible: false`. Orchestrators should read the structured result rather than poll the filesystem. See [Workflow Gates](../cli-utilities/workflow-gates.md).

package/assets/docs/reference/oat-directory-structure.md

@@ -305,6 +305,7 @@ Not all workflow modes require every artifact:
 - `spec-driven`: discovery + spec + design + plan + implementation
 - `quick`: discovery + plan + implementation (spec/design optional)
 - `import`: imported plan + implementation (spec/design optional)
+- `lite`: single-phase plan + implementation (summary/documentation optional at closeout)
 
 ## `.oat/repo/` structure
 

package/assets/docs/workflows/ideas/index.md

@@ -37,4 +37,4 @@ If the thought is still pre-shape — you don't know whether it should land as a
 
 ## Promotion Path
 
-When an idea becomes concrete, summarize it and then start a tracked OAT project in quick or spec-driven mode depending on design risk.
+When an idea becomes concrete, summarize it and then start a tracked OAT project in lite, quick, or spec-driven mode depending on scope and design risk. Lite suits a single-sitting change and seeds `plan.md` directly; quick and spec-driven seed `discovery.md` instead.

package/assets/docs/workflows/index.md

@@ -44,6 +44,7 @@ Stay with direct CLI usage when:
 ## Workflow Modes In Practice
 
 - CLI only: direct commands, no tracked project artifacts
+- Lite mode: a batched interview and one approval produce a single-phase `plan.md` for a single-sitting change
 - Quick mode: tracked work with a lighter upfront planning path
 - Spec-driven mode: explicit discovery, requirements, design, and plan artifacts
 - Import mode: an externally-authored plan imported into OAT for tracked execution

package/assets/docs/workflows/projects/artifacts.md

@@ -50,9 +50,30 @@ archive metadata own terminal reachability and retry identity.
 
 Mode-sensitive notes:
 
-- `state.md` includes workflow mode metadata (`spec-driven`, `quick`, `import`) for routing.
-- `spec.md` and `design.md` are required in spec-driven mode, optional in quick/import mode. Quick mode offers a lightweight `design.md` (architecture, components, testing strategy) at a post-discovery decision point.
-- `plan.md` remains canonical execution artifact across all modes.
+- `state.md` includes workflow mode metadata (`spec-driven`, `quick`, `import`, `lite`) for routing.
+- `plan.md` remains the canonical execution artifact across all modes.
+
+| Mode          | Core authored artifacts                                                                                                                | Optional artifacts                         |
+| ------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ |
+| `spec-driven` | `discovery.md`, `spec.md`, `design.md`, `plan.md`                                                                                      | -                                          |
+| `quick`       | `discovery.md`, `plan.md`                                                                                                              | Lightweight `design.md`, `spec.md`         |
+| `import`      | `references/imported-plan.md`, `plan.md`                                                                                               | `spec.md`, `design.md`                     |
+| `lite`        | Single-phase `plan.md` with Summary, Decisions, Assumptions, Out of Scope, Validation Criteria, and an explicit adaptive content shape | `summary.md` and documentation at closeout |
+
+Every Lite plan keeps Summary, Decisions, Assumptions, Out of Scope, and
+Validation Criteria. User-visible changes add numbered, testable Product
+Behavior. Changes that cross module boundaries, alter data or state formats,
+or change a contract consumed by another surface add Technical Design. That
+section covers current operation, proposed changes, and data flow when data or
+state crosses a boundary. The Decisions section records the selected shape and
+why it fits.
+
+Each Lite task also records an implementation and proof strategy: the risk it
+covers, why the evidence is proportionate, and the exact command or manual
+proof. Strategies may be test-first, characterization-first,
+implementation-then-regression, static/build, or manual/visual. Static or build
+checks alone fit only changes that cannot affect runtime behavior; every
+behavioral change needs evidence that fails without the change.
 
 ## Supporting artifacts
 

package/assets/docs/workflows/projects/autonomy.md

@@ -136,8 +136,11 @@ At final closeout, autonomy follows the same authoritative order as an
 interactive run: final verification, mandatory final lifecycle review,
 configured implementation exit gate, pre-approval sequence, final HiLL
 approval, post-approval sequence, then implementation completion and success
-output. A null gate resolution persists an explicit no-gate allowance before
-the sequence starts.
+output. A `not_configured` resolution persists an explicit no-gate allowance
+before the sequence starts; a null, missing, or unrecognized resolver result
+fails closed as unresolved. A gate this project disabled persists an
+`allowed/configured` result with `disposition: project_disabled` and never
+launches the configured command.
 
 Autonomy does not turn an ordinary independent review into configured-gate
 provenance. A configured review must produce a gate-originated artifact with

package/assets/docs/workflows/projects/dispatch-ceiling.md

@@ -438,7 +438,8 @@ write authority. See
 ## Dispatch Report V1 and Producer Provenance
 
 Resolver calls that pass `--report-scope` and `--report-action` include a
-`dispatchReport` object in JSON output. Consumers must require
+`dispatchReport` object in JSON output, plus the additive `dispatchStamp`
+string described below. Consumers must require
 `dispatchReport.schemaVersion: 1` before dispatch. The report keeps these
 concerns separate:
 
@@ -485,18 +486,53 @@ also retain a parseable compatibility stamp for later review gates:
 Dispatch: scope=p06-t03 action=implementation role=implementer producer=gpt-5.6-sol provenance=declared model_axis=selected:gpt-5.6-sol effort_axis=selected:high dispatch_policy=high dispatch_ceiling=high target=oat-phase-implementer-gpt-5-6-sol-high
 ```
 
-The stamp must be derived through `toDispatchStampRecord(dispatchReport)` and
-`formatDispatchStamp`; callers must not reconstruct it from policy labels, role
-names, candidate strings, or target names. `producer` is the runtime model slug
-when OAT can establish it; otherwise it is `unknown`. `provenance` is
-`declared`, `observed`, `inferred`, or `unknown`. Selected model and effort axes
-can remain exact even when runtime producer identity is not reported.
+`producer` is the runtime model slug when OAT can establish it; otherwise it is
+`unknown`. `provenance` is `declared`, `observed`, `inferred`, or `unknown`.
+Selected model and effort axes can remain exact even when runtime producer
+identity is not reported.
 
 Before launching an implementation, fix, or reviewer, surface the structured
 notices in `dispatchReport.notices` and render the report. Structured notices
 and runtime disclosure use the effective target returned by that resolver call,
 never a target inferred from the bundled recommendation version.
 
+### The additive `dispatchStamp` field
+
+JSON responses that carry `dispatchReport` also carry `dispatchStamp`, a single
+canonical string produced by the same formatter that owns the grammar above:
+
+```json
+{
+  "status": "resolved",
+  "dispatchReport": { "schemaVersion": 1 },
+  "dispatchStamp": "Dispatch: scope=p06-t03 action=implementation role=implementer ..."
+}
+```
+
+Field eligibility matches report eligibility exactly. The field is present when
+and only when `dispatchReport` is present, so non-report resolver calls and
+error envelopes never carry it. `DispatchReportV1`, its schema version, and the
+stamp grammar are unchanged; the field is purely additive.
+
+Eligibility tracks report presence, not dispatch authorization or exit code. A
+`status: blocked` response that was asked for report context therefore carries
+both `dispatchReport` and `dispatchStamp` while still exiting `1`: the stamp
+records what OAT resolved, and a blocked resolution is a resolved fact about an
+unusable route rather than a missing report. Only a call without report context,
+or an error envelope that never built a report, omits the field.
+
+Consumers read `dispatchStamp` directly, validate that it is a non-empty string
+beginning with the canonical `Dispatch:` prefix, and copy it byte-for-byte into
+dispatch and audit metadata. Reformatting the report through
+`toDispatchStampRecord(dispatchReport)` and `formatDispatchStamp` is an optional
+corroboration where that library is already loaded; it is never the normal path,
+and no out-of-tree shim is required. Callers must not reconstruct the stamp from
+policy labels, role names, candidate strings, or target names.
+
+A stamp carrying `producer=unknown provenance=unknown` is truthful, not
+degraded: the resolver reports configured invocation, and those fields stay
+`unknown` until an independent runtime observation exists.
+
 ## Legacy Compatibility
 
 The following remain readable during migration: