@open-agent-toolkit/cli 0.3.19 → 0.3.20

package/README.md

@@ -62,7 +62,8 @@ Use these commands when you want structured runtime/project state out of the CLI
 - `oat config dump --json` - emit merged OAT config with per-key source attribution
 - `oat project status --json` - emit the active project's full parsed control-plane state
 - `oat project list --json` - emit summary state for tracked projects under the configured projects root
-- `oat project closeout-check <project-path> --json` - report whether a configured, autonomous, or lite closeout's `oat_post_implement_sequence` snapshot permits terminal completion, and which step or approval owns it next (read-only)
+- `oat project closeout-check <project-path> --json` - report whether a configured, autonomous, or lite closeout's `oat_post_implement_sequence` snapshot permits terminal completion and, for a goal project, whether the declaration, outcome audit, and delivery coverage boundary holds, and which step, approval, or skill owns it next (read-only)
+- `oat project delivery check --project <path> --subject <mNN|dNN> --json` - read-only goal delivery evidence report for a milestone or registered delivery (`status: ok`, or `undeliverable` with exit 1)
 - `oat project complete-state <project-path>` - emit the canonical completed lifecycle shape into a tracked project's `state.md`; refuses the same incomplete closeout `closeout-check` reports
 
 ## Requirements

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

@@ -1,6 +1,6 @@
 ---
 name: oat-phase-implementer
-version: 1.1.8
+version: 1.1.9
 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`, `import`, `lite`, or `brief`;
+- `workflow_mode`: `spec-driven`, `quick`, `import`, `lite`, `brief`, or `goal`;
 - `commit_convention`: exact task/fix commit convention;
 - `phase_base_head`: root-recorded HEAD before phase dispatch;
 - `worktree`: assigned phase worktree or orchestration checkout;
@@ -132,10 +132,13 @@ Read each required artifact once at phase start:
   `implementation.md`; and sections 3, 6, 7, and 10 of
   `oat-project-brief/references/brief-contract.md`. Discovery, spec, and design
   are absent by design.
+- `goal`: everything `brief` reads, plus the `## Milestones` table and
+  section 12 of the brief contract. The Phase Scope names the milestone,
+  recovery, or terminal scope the phase belongs to.
 
 Extract all phase tasks, dependency order, file boundaries, verification
 commands, commit messages, and phase-wide verification before editing. In
-`brief` mode there are no planned tasks to extract: extract the phase's Intent,
+`brief` and `goal` modes there are no planned tasks to extract: extract the phase's Intent,
 its Exit evidence as the phase-wide verification, and the Phase Scope's commit
 convention, and follow `## Brief Mode` below.
 
@@ -424,6 +427,25 @@ belongs to a revision phase the root appends.
 the Task column with its terminal status and commit, and add
 `**Phase anchors:** {anchor_base}..{head}` below the header fields.
 
+## Goal Mode
+
+This section applies only when `workflow_mode` is `goal`. Every `## Brief Mode`
+rule applies unchanged, and section 12 of the brief contract wins where this
+section restates it.
+
+- **Scope.** Execute only the dispatched phase. Its milestone, recovery, or
+  terminal scope is context, never permission to touch another milestone's
+  phases.
+- **Root-owned goal records.** Never write `oat_milestone`,
+  `oat_milestone_status`, `oat_goal_status`, `oat_goal_outcome_audit`,
+  `oat_goal_recovery`, `oat_milestone_gates`, `oat_deliveries`, or the
+  `## Milestones` table. Milestone closeout, the exit-gate carrier, recovery
+  stages, delivery registration, and the declaration are root and skill
+  transitions, not phase work.
+- **Recovery phases.** A recovery scope's phase (often a `p-revN` that
+  corrects an older milestone's phase) follows the brief late-fix and revision
+  rules; report its head like any sequential phase.
+
 ## Mode: Implement
 
 ### 1. Verify Phase Base
@@ -562,6 +584,7 @@ After all task commits:
   - `import`: `plan.md` and the imported plan, plus design/spec when present;
   - `brief`: the phase's Intent and Exit evidence plus the brief's Outcomes,
     Constraints and Out of Scope, and Decisions;
+  - `goal`: as `brief`, within the dispatched milestone's scope;
 - confirm no task boundary or dependency was missed; and
 - report Medium/Low concerns without launching a reviewer.
 

package/assets/agents/oat-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: oat-reviewer
-version: 1.2.12
+version: 1.2.13
 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,10 +50,10 @@ 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` | `lite` | `brief` (default to `spec-driven` if absent)
+- **workflow_mode**: `spec-driven` | `quick` | `import` | `lite` | `brief` | `goal` (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). In `brief` mode these are the execution-record IDs under the phases in scope; they label commits and never narrow the range.
-- **Brief anchor record**: For `brief` code reviews, the caller supplies `oat_review_requested_scope`, `oat_review_phase_ids` (ordered), `oat_review_base_sha`, `oat_review_scope_source` (`anchors` | `merge-base-range` | `explicit` | `merge-base` | `narrowed`), and, when they apply, `oat_review_fallback_reason`, `oat_review_integration_commits`, and `oat_review_narrowed_from`. Copy them verbatim into artifact frontmatter (Step 8).
+- **Brief anchor record**: For `brief` code reviews, the caller supplies `oat_review_requested_scope`, `oat_review_phase_ids` (ordered), `oat_review_base_sha`, `oat_review_scope_source` (`anchors` | `merge-base-range` | `explicit` | `merge-base` | `narrowed`), and, when they apply, `oat_review_fallback_reason`, `oat_review_integration_commits`, and `oat_review_narrowed_from`. Copy them verbatim into artifact frontmatter (Step 8). In `goal` mode the same record applies; for an integrated milestone or delivery review `oat_review_requested_scope` is the milestone or delivery ID (`mNN` or `mNN/dNN`) and `oat_review_phase_ids` is the explicit ordered phase set.
 - **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.
 - **oat_review_invocation**: Optional provenance selector for artifact-mode reviews. Use `manual`, `auto`, or `gate`; default to `manual` when absent.
 - **Code-review provenance**: For artifact-mode code reviews, resolve the authoritative range head with `git rev-parse <authoritative-range-head>^{commit}` and record the resulting full 40-character commit SHA as `oat_review_head_sha`. If the review is narrowed, also record the resolved range, prior artifact path, and prior reviewed head supplied by the caller.
@@ -131,6 +131,7 @@ Use workflow mode to determine required evidence:
 - **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.
 - **brief**: `plan.md` (a Project Brief) and `implementation.md` (the per-phase journal) are expected; discovery, spec, and design are absent by design. `oat-project-brief/references/brief-contract.md` defines the brief sections, phase grammar, journal markers, and anchor rules, and the caller supplies it with the Review Scope.
+- **goal**: as **brief**, plus the canonical `## Milestones` table in `plan.md` and the goal state in `state.md`; section 12 of the brief contract defines milestones, explicit review scopes, the delivery registry, and the terminal audit.
 
 Do not mark missing optional artifacts as findings.
 If required artifacts for the mode are unexpectedly missing, record a workflow contract gap.
@@ -166,6 +167,8 @@ Only review files/changes within the provided scope.
 
 In `brief` mode the authoritative code-review range comes from the recorded phase anchors: `Base..Head` for one phase, or the first selected base through the last selected phase's head for a range or `final`. Commit-message `(pNN-` matches only label which commits belong to which phase and never narrow the range. When `oat_review_scope_source` is `merge-base-range`, review the entire supplied range. If an anchor is missing, does not exist, or contradicts the ordering rules in brief contract section 10, record a workflow contract gap rather than narrowing silently. Treat the listed integration commits as inside the range.
 
+In `goal` mode an integrated milestone or delivery review judges exactly the explicit ordered phase set in `oat_review_phase_ids`, never a first–last expansion. The Git range may be wider: commits of phases outside the set that the Review Scope lists under `Intervening changes:` are context, not scope, so do not record findings against them and do not treat them as covered. A parallel group member's pre-fan-in review is member evidence only; integrated delivery evidence comes from the integration heads.
+
 Do NOT:
 
 - Review unrelated work outside the scope
@@ -183,6 +186,7 @@ For each requirement in scope, use the best available requirement source by mode
 - `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.
 - `brief`: each phase in scope's `**Intent:**` and `**Exit evidence:**` lines plus the brief's Outcomes, Constraints and Out of Scope, and Decisions. A `final` review also audits every numbered Outcome against its observed evidence in the journal; an Outcome with neither evidence nor a recorded deferral is a finding. Execution records are evidence of committed work, not requirements.
+- `goal`: as `brief`, scoped to the milestone or delivery set under review. A plan (artifact) review of a goal brief or amendment also checks the `## Milestones` table against brief contract section 12.1: every executable phase in exactly one milestone, phase IDs never reused, and no frozen delivery phase moved or removed.
 
 Then verify:
 
@@ -290,6 +294,7 @@ Treat the artifact as a product deliverable. Verify it is:
    - 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.
+   - **Goal plan review** follows the brief plan review below, except that `## Milestones` holds the canonical table (brief contract section 12.1) instead of being empty, and an amendment review judges the named milestone's appended phases and any changed Outcomes, Decisions, or authority.
    - **Brief plan review** replaces the task-oriented items above with the brief section list: Goal; numbered Outcomes, each naming its intended evidence; Approach (optional `### Design`); Constraints and Out of Scope; Decisions with rationale and rejected alternatives; Known Unknowns, each with the phase that settles it; Delivery endpoint and authority; an empty `## Milestones` section; `## Phase pNN:` blocks with non-empty Intent and Exit evidence, a `**Provisional:**` value of `yes` or `no`, and a concrete first phase; Parallelism; Reviews (preserved rows); Implementation Complete; References. Stable, never-reused phase IDs in document order replace stable task IDs. There is no task requirement; `### Task` headings in a brief are a finding, because execution records belong in the journal. Check that every Outcome is reachable through some phase's Exit evidence and that any declared parallel group passes the independence test in brief contract section 6.
 
 6. **Necessary**

package/assets/bundle-metadata.json

@@ -1,4 +1,4 @@
 {
   "schemaVersion": 1,
-  "oatVersion": "0.3.19"
+  "oatVersion": "0.3.20"
 }

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

@@ -100,15 +100,18 @@ Lifecycle](../workflows/backlog-and-planning/backlog-lifecycle.md).
 
 Notable commands introduced in the current CLI surface:
 
-- `oat project new <slug> [--mode spec-driven|quick|import|lite|brief] --scope shared|local|synced [--force]` - create a
+- `oat project new <slug> [--mode spec-driven|quick|import|lite|brief|goal] --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, `lite` for a single-sitting change that scaffolds only
   `plan.md`, `state.md`, and `implementation.md`, and `brief` for one delivery
   planned as a Project Brief, which scaffolds the `plan-brief` and
-  `implementation-brief` templates plus `references/research/`. Start brief
-  projects with `oat-project-brief`, which runs this command itself. See
+  `implementation-brief` templates plus `references/research/`, and `goal` for
+  an outcome delivered in milestones, which scaffolds the same files with
+  `oat_plan_source: goal` and the canonical `| Milestone | Phases |` table
+  header. Start brief and goal projects with `oat-project-brief` or
+  `oat-project-goal`, which run this command themselves. See
   [Lifecycle](../workflows/projects/lifecycle.md) for the per-lane flow. Without
   `--scope`, creation uses
   `projects.defaultScope`, which defaults to `synced`. Project slugs are
@@ -193,17 +196,19 @@ 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 or brief project to quick mode. For a lite project, 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`. For a brief project, it migrates each phase by state: accepted phases keep their completed execution records as quick tasks or get one synthesized `Accepted via phase evidence` task against the phase's `**Head:**`, active phases keep their completed records, and pending or provisional phases stay taskless and are listed in `oat_promotion_pending_phases` (quick plan readiness stays false until that list is empty); it renders the brief's sections into `discovery.md`, archives the original as `references/brief-archive.md`, and sets `oat_promoted_from: brief`. There is no reverse direction. It refuses unsupported targets, projects that are neither lite nor brief, unreadable projects, an existing lite-plan reference, invalid authored sections, an existing brief archive (`brief-archive-exists`), an extracted journal phase (`extracted-phases`), a brief with no parseable phases (`invalid-brief-plan`), an accepted brief phase with no completed record and no `**Head:**` anchor (`missing-phase-head`), unresolved scope, unavailable templates, failed writes, or failed persistence. JSON output is `{ status: "promoted" | "refused", reason, files }`, plus an optional `phases` array naming the refused phases when `reason` is `missing-phase-head`; `reason` is the stable categorical contract and refused results exit non-zero.
+- `oat project promote <project-path> --to quick [--json]` - promote an authored lite, brief, or settled goal project to quick mode. For a lite project, 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`. For a brief project, it migrates each phase by state: accepted phases keep their completed execution records as quick tasks or get one synthesized `Accepted via phase evidence` task against the phase's `**Head:**`, active phases keep their completed records, and pending or provisional phases stay taskless and are listed in `oat_promotion_pending_phases` (quick plan readiness stays false until that list is empty); it renders the brief's sections into `discovery.md`, archives the original as `references/brief-archive.md`, and sets `oat_promoted_from` to the source mode (`brief`, or `goal` for a goal project). There is no reverse direction. A goal project promotes like a brief, but only at a settled delivery boundary: the active milestone is `delivered`, every `oat_deliveries` entry is `at_endpoint` or `superseded`, and no `oat_goal_recovery` is pending; otherwise it refuses with `goal-milestone-active`, `goal-recovery-pending`, or `goal-delivery-unsettled` (with a `deliveries` array naming the unsettled entries; an empty registry is also unsettled), and its archive appends the delivery history after the original brief. It refuses unsupported targets, projects that are neither lite, brief, nor goal, unreadable projects, an existing lite-plan reference, invalid authored sections, an existing brief archive (`brief-archive-exists`), an extracted journal phase (`extracted-phases`), a brief with no parseable phases (`invalid-brief-plan`), an accepted brief phase with no completed record and no `**Head:**` anchor (`missing-phase-head`), unresolved scope, unavailable templates, failed writes, or failed persistence. JSON output is `{ status: "promoted" | "refused", reason, files }`, plus an optional `phases` array naming the refused phases when `reason` is `missing-phase-head`; `reason` is the stable categorical contract and refused results exit non-zero.
 - `oat template resolve <name> [--output <path>] [--json]` - resolve a template in repository (`<repo>/.oat/templates/`), user (`~/.oat/templates/`), then bundled order and report `name`, `found`, `tier` (`repository` | `user` | `bundle`), and `path`. `path` is set only for the repository and user tiers; it is `null` for the bundled tier, so callers never depend on a package-manager path. `<name>` accepts `plan` or `plan.md` and rejects path separators and `..`. `--output <path>` copies the resolved content to that file, replacing an existing file, and does not create missing parent directories; JSON output adds the absolute `output` path. A template missing from every tier exits 1 with `found: false`. Lifecycle skills use `--output` to copy their artifact templates, so a user-scope-only install works without a repository `.oat/templates/` directory.
 - `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 closeout-check <project-path> [--autonomous] [--json]` - read-only check of the closeout invariant: a closeout that must snapshot its post-implementation sequence cannot reach terminal completion until its `oat_post_implement_sequence` snapshot exists, every stored step is recorded complete, approval is recorded, and the snapshot reached `status: complete`. A snapshot is required when the effective layered `workflow.postImplementSequence` is configured, when the closeout is autonomous (`--autonomous`, or `OAT_AUTONOMOUS=1` in the environment even without the flag), or when `oat_workflow_mode` is `lite`. Once a snapshot exists its recorded state is authoritative and current configuration is not consulted. JSON output reports `status` (`complete`, `not_required`, or `incomplete`), the missing `invariant` (`snapshot_missing`, `snapshot_malformed`, `sequence_failed`, `pre_approval_step_pending`, `approval_pending`, `post_approval_step_pending`, or `sequence_not_complete`), `route` (`oat-project-implement` when incomplete), `nextOwner` (the next stored step and its skill, or the approval), and the evaluated `inputs`. An incomplete or malformed result exits 1.
-- `oat project complete-state <project-path> [--archived] [--autonomous]` - apply the canonical completed-state mutation to a project's `state.md`; used by `oat-project-complete` during lifecycle closeout. It first evaluates the same closeout invariant as `oat project closeout-check` and refuses, with the same message and without writing, a configured, autonomous, or lite closeout whose snapshot is absent, malformed, or incomplete. A project whose implementation finished before closeout snapshots existed recovers by running `oat-project-implement`, which persists the snapshot (`completion-and-closeout.md` Step 15) and completes its stored steps; there is no override flag. An unconfigured, interactive, non-lite closeout without a snapshot completes as before.
+- `oat project closeout-check <project-path> [--autonomous] [--json]` - read-only check of the closeout invariant: a closeout that must snapshot its post-implementation sequence cannot reach terminal completion until its `oat_post_implement_sequence` snapshot exists, every stored step is recorded complete, approval is recorded, and the snapshot reached `status: complete`. A snapshot is required when the effective layered `workflow.postImplementSequence` is configured, when the closeout is autonomous (`--autonomous`, or `OAT_AUTONOMOUS=1` in the environment even without the flag), or when `oat_workflow_mode` is `lite`. Once a snapshot exists its recorded state is authoritative and current configuration is not consulted. JSON output reports `status` (`complete`, `not_required`, or `incomplete`), the missing `invariant` (`snapshot_missing`, `snapshot_malformed`, `sequence_failed`, `pre_approval_step_pending`, `approval_pending`, `post_approval_step_pending`, or `sequence_not_complete`), `route` (`oat-project-implement` when incomplete), `nextOwner` (the next stored step and its skill, or the approval), and the evaluated `inputs`. An incomplete or malformed result exits 1. For a goal project (`oat_workflow_mode: goal`) the goal boundary is checked first and read-only: it requires `oat_goal_status: declared_met`, a valid exhaustive `oat_goal_outcome_audit`, resolved extractions, a successful `gh pr view` observation of every terminal delivery member, and delivery coverage of every accepted phase (each in a terminal delivery's effective scope with a passed, fresh integrated review and its persisted `exit_gate`); refusals report `goal_inputs_unreadable`, `goal_not_declared`, `goal_audit_invalid`, `goal_extraction_unresolved`, `goal_observation_failed`, or `goal_coverage_incomplete`, and `nextOwner` is `{ kind: "goal", skill, reasons }`, where each reason is `{ code, message, subject? }` and `skill` is the owner of the first reason: for example `not-declared` and `audit-invalid` route to `oat-project-goal`, `review-not-fresh` to `oat-project-review-provide`, `exit-carrier-not-fresh` to `oat-project-implement`, delivery and endpoint reasons such as `endpoint-unmet` to `oat-project-pr-progress`, and `phase-uncovered` to `oat-project-pr-final`. A goal snapshot may record its `pr` step as satisfied by delivery coverage (`satisfied_by: { pr: delivery-coverage }`) only once `pr` is in the completed prefix.
+- `oat project delivery refresh --project <path> [--json]` - goal only. Observes every registered delivery member with `gh pr view <url> --json state,headRefOid,baseRefOid` and persists, in `state.md`, only the observations (`observed_head`, `observed_base`, member `status`), the delivery `status` (`open` or `at_endpoint`), the first observed `endpoint_attainment`, and derived staleness (`integrated_review.disposition: stale`, the milestone exit carrier's `freshness: stale` with `freshness_reason`). It never rewrites a reviewed revision, a member base, or the first endpoint attainment, never writes `oat_milestone_status` or `oat_goal_recovery`, and never manufactures a passed review or a fresh carrier. `oat-project-pr-progress` and `oat-project-goal` run it before registration and re-alignment.
+- `oat project delivery check --project <path> --subject <mNN|dNN> [--json]` - goal only, read-only. Reports whether a milestone (before registration, against the branch head) or a registered delivery (against its observed member revisions) is deliverable: a passed integrated review that is still fresh under the bookkeeping-successor rule and an allowed, fresh milestone exit carrier (reported as `exit.source: milestone-carrier`; the closeout boundary judges each delivery's persisted `exit_gate` instead). Evidence reviewed at R covers a later head only when every intervening commit changes permitted bookkeeping in this project's tracking files (`state.md`, `plan.md`, `implementation.md`, `project-log.md`, `summary.md`) and review artifacts (including those of deliveries sharing the same member pull request); any change to `summary.md` is bookkeeping because it is derived memory, never the authority for the brief's content; code changes, edits to approved brief content, and a substantive change followed by its revert fail. JSON output carries `status` (`ok` or `undeliverable`), the subject, its ordered `scope`, `publishedHeads`, `review`, `exit`, and `deliverable`; an undeliverable subject exits 1 with the full report. A stale `review` or `exit` result carries a `reason` that starts with a code, such as `review-missing`, `review-scope-narrow`, `member-unobserved`, `base-changed`, `bound-revision-mismatch` (a bound revision differs from its member's set-once `reviewed_head`), `subject-changed`, `configuration-changed`, or a bookkeeping-successor failure: `missing-revision`, `missing-object`, `not-ancestor`, `inspection-failed`, `disallowed-path`, or `substantive-change`.
+- `oat project complete-state <project-path> [--archived] [--autonomous]` - apply the canonical completed-state mutation to a project's `state.md`; used by `oat-project-complete` during lifecycle closeout. It first evaluates the same closeout invariant as `oat project closeout-check` and refuses, with the same message and without writing, a configured, autonomous, or lite closeout whose snapshot is absent, malformed, or incomplete. A project whose implementation finished before closeout snapshots existed recovers by running `oat-project-implement`, which persists the snapshot (`completion-and-closeout.md` Step 15) and completes its stored steps; there is no override flag. An unconfigured, interactive, non-lite closeout without a snapshot completes as before. A goal project is also refused, without writing, by the goal boundary that `closeout-check` describes.
 - `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 verifies the complete selected package and every immutable file byte, then atomically exports one self-contained `.oat/repo/reference/project-recaps/<YYYYMMDD-project-slug>.html` page before deleting the active project. The full original package remains in the archived project. JSON `projectRecapExport` identifies `runId`, `page.sourceRelativePath`, `page.originalSha256`, `page.exportedSha256`, `verifiedArtifactCount`, and the flat `exportRoot`. No tracked sidecar is created. Matching dated pages are adopted on retry; conflicting destinations, incomplete inventory coverage, stale bytes, path escapes, and recipe mismatches fail without removing the active project. Summary and PR links point to the tracked page. 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. 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>` - validate one generic dispatch record plus its namespaced OAT evidence event and print the result with `status: validated-only`. The command writes nothing; launches are recorded in the calling workflow's run record. Managed, effort-pinned Claude launches run it before launch: the input carries `claudeLaunch` with the real resolver result, generated definition, and proposed payload, plus `recordBase` and `event`. The command validates their agreement and derives the configured invocation fields; callers cannot copy those fields into `recordBase`. One validation run reports every violation across `claudeLaunch`, `recordBase`, and `event` in a single error message, one `stage path: message` line each; the `recordBase` cross-field rules run even when a required field is missing, checks that need a value that failed to parse are skipped and named on a final line, secret-shaped values and absolute paths are scrubbed from the message, and the exit code stays 1. A validated input per role is published at `.agents/skills/oat-dispatch-subagents/references/managed-claude-example.json`. The command validates 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 echoed in the output, 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/advanced/evidence-layers.md).
 - `oat project dispatch canonical-role --role <name> --request-id <id> --skill-dir <dir> [--json]` - resolve a canonical role through the loaded, user (`$HOME/.agents`), and project (`<repo>/.agents`) tiers and print the `canonical-role-resolution` event that `oat project dispatch record` accepts unchanged: redacted `canonicalPath` and `selectedPath` in the form `<loaded|user|project>/agents/<name>.md`, the role's `contentDigest`, and `candidateMisses`. `--skill-dir` is required because the loaded tier is derived from the loaded skill's directory; a missing or invalid directory exits 1 with a redacted error. An unknown role prints `missing` evidence with its recovery commands. Read-only; the dependency is the `workflows` pack.
-- `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. Brief plans (`oat_workflow_mode: brief`) are validated with the brief profile: phases need non-empty `**Intent:**` and `**Exit evidence:**`, a `**Provisional:**` value of `yes` or `no`, unique IDs, and a concrete first phase; `### Task` headings in a brief are reported as a warning, and taskless parallel groups are valid. See [Implementation Execution](../workflows/projects/execution/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. Brief plans (`oat_workflow_mode: brief`) are validated with the brief profile: phases need non-empty `**Intent:**` and `**Exit evidence:**`, a `**Provisional:**` value of `yes` or `no`, unique IDs, and a concrete first phase; `### Task` headings in a brief are reported as a warning, and taskless parallel groups are valid. Goal plans add the goal profile: `oat_plan_source: goal`, a valid `## Milestones` table (`goal-milestones-missing`, `goal-milestones-malformed`, `goal-duplicate-milestone`, `goal-milestone-empty`, `goal-milestone-unknown-phase`, `goal-phase-in-multiple-milestones`, `goal-phase-without-milestone`), no parallel group spanning milestones (`goal-group-crosses-milestone`), canonical persisted phase IDs (`goal-noncanonical-phase-id`), and no change to a shipped milestone or a registered delivery's frozen scope (`goal-shipped-milestone-changed`, `goal-delivered-scope-changed`); phases the journal marks `extracted` need no milestone. See [Implementation Execution](../workflows/projects/execution/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](../workflows/projects/execution/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 and artifact reviews default to 30 minutes, while task code 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`. When post-selection work fails after the reviewer already committed a run-correlated artifact, the gate re-validates that selected snapshot through the same eligibility path rather than re-parsing whatever the path now holds, never re-dispatching, and returns the ordinary `ok` or `blocked` envelope with additive `postSelectionRecovery: true`; the artifact must still be present and unchanged for re-validation to succeed. When nothing recovers, `review_failed` names the failing sub-step in `postSelection.step` and its cause in `postSelection.code`. 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](../workflows/advanced/workflow-gates.md).

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

@@ -323,6 +323,7 @@ Not all workflow modes require every artifact:
 - `import`: imported plan + implementation (spec/design optional)
 - `lite`: single-phase plan + implementation (summary/documentation optional at closeout)
 - `brief`: Project Brief in `plan.md` + per-phase journal in `implementation.md` (`references/research/` scaffolded; no discovery, spec, or design)
+- `goal`: the brief artifact set, with a `## Milestones` table in `plan.md` and the milestone state, gate carriers, delivery registry and outcome audit in `state.md`
 
 ## `.oat/repo/` structure
 

package/assets/docs/reference/project-artifacts.md

@@ -50,7 +50,7 @@ archive metadata own terminal reachability and retry identity.
 
 Mode-sensitive notes:
 
-- `state.md` includes workflow mode metadata (`spec-driven`, `quick`, `import`, `lite`, `brief`) for routing.
+- `state.md` includes workflow mode metadata (`spec-driven`, `quick`, `import`, `lite`, `brief`, `goal`) for routing.
 - `plan.md` remains the canonical execution artifact across all modes.
 
 | Mode          | Core authored artifacts                                                                                                                | Optional artifacts                         |
@@ -60,6 +60,7 @@ Mode-sensitive notes:
 | `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 |
 | `brief`       | `plan.md` as a Project Brief (phases with Intent and Exit evidence) and `implementation.md` as the per-phase journal                   | `references/research/`, `project-log.md`   |
+| `goal`        | The brief artifacts, with a `## Milestones` table in `plan.md` and the goal fields in `state.md`                                       | `references/research/`, `project-log.md`   |
 
 Every Lite plan keeps Summary, Decisions, Assumptions, Out of Scope, and
 Validation Criteria. User-visible changes add numbered, testable Product
@@ -91,6 +92,60 @@ line per numbered Outcome. When a brief artifact gate is configured,
 `state.md` records its outcome as `oat_brief_gate`, with the same core fields
 as `oat_quick_start_gate`.
 
+In goal mode, `plan.md` is the same Project Brief with a filled
+`## Milestones` table: one `| Milestone | Phases |` row per milestone listing
+its ordered phase IDs, every phase (revision phases included) in exactly one
+milestone. Later milestones are appended at re-alignment, and a phase frozen in
+a registered delivery is never removed or reassigned. `state.md` adds the
+goal fields:
+
+- `oat_milestone` and `oat_milestone_status` (`aligning`, `implementing`,
+  `reviewing`, `delivering`, `delivered`), the active milestone;
+- `oat_goal_status` (`active` or `declared_met`) and
+  `oat_goal_outcome_audit`, the exhaustive per-phase and per-outcome audit
+  written at the terminal declaration;
+- `oat_goal_recovery`, the record of an interrupted recovery, which may target
+  an older milestone without moving the active one;
+- `oat_milestone_gates`, one `plan` and one `exit` gate carrier per
+  milestone; and
+- `oat_deliveries`, the delivery registry: one entry per delivery (`dNN`) with
+  its milestone, frozen phase scope, agreed endpoint, status, member pull
+  requests and their observed revisions, the integrated review it was
+  delivered on, its exit-gate binding and the first observed endpoint
+  attainment. A delivery's `status` is `registering`, `open`, `at_endpoint`,
+  or `superseded`, and its agreed `endpoint` is `open` or `merged`. A
+  replacement delivery names its one direct predecessor in `covers_scope_of`,
+  and the predecessor's `superseded_by` points back; only a delivery that never
+  reached its agreed endpoint may be replaced. A correction of a delivery that
+  did reach it is additive (`corrects_delivery_id`, new phase IDs, no inherited
+  coverage). `oat_pr_status` and `oat_pr_url` project the latest member pull
+  request.
+
+Delivery evidence stays fresh across later commits that change only bookkeeping:
+`state.md`, `plan.md` (outside its approved content), `implementation.md`,
+`project-log.md` appends, `summary.md`, and the review artifacts of the
+delivery and of any delivery sharing its pull request.
+
+A delivery's evidence identity is set once: its `exit_gate`, its
+`integrated_review` identity (`artifact`, `scope`, `bound_revisions`), and each
+member's `reviewed_head`. They change only in a commit that records a new
+review artifact of that delivery, one its own `## Reviews` rows name and never
+a sharing delivery's; any other change to them is not bookkeeping. A bound
+revision that disagrees with its member's `reviewed_head` is not fresh
+(`bound-revision-mismatch`).
+
+`oat project delivery refresh` writes only observations and derived staleness
+into `oat_deliveries` and the milestone carriers. The terminal declaration is
+recorded as one `**Goal declared met:**` line in the journal's Final Summary.
+
+Extraction of goal work into another project is manual. A phase moved to a
+linked project gets `**Extracted to:** <slug>` in the brief and the marker pair
+`**Status:** extracted` / `**Extracted to:** <slug>` in the journal, and the
+child project records `oat_extracted_from: <goal slug>` in its `state.md`. The
+brief and journal targets must match. The outcome audit requires the child to
+be complete or its outstanding obligation to carry an approved deferral, and
+promotion of the goal to quick refuses any extracted phase.
+
 ## Blockers in state.md
 
 `oat_blockers` accepts legacy reason strings and structured workflow records:

package/assets/docs/reference/project-state-machine.md

@@ -17,8 +17,8 @@ This page is the compact contract for how project lifecycle state and review sta
 
 === "Diagram"
 
-    ![Project state machine: discovery, spec, design, plan and implementation phases, then PR open and complete; a review loop returns to implementation, a revise loop runs from PR open and back, and lite and brief enter at planning](/diagrams/project-state-machine-light.svg)
-    ![Project state machine: discovery, spec, design, plan and implementation phases, then PR open and complete; a review loop returns to implementation, a revise loop runs from PR open and back, and lite and brief enter at planning](/diagrams/project-state-machine-dark.svg)
+    ![Project state machine: discovery, spec, design, plan and implementation phases, then PR open and complete; a review loop returns to implementation, a revise loop runs from PR open and back, and lite, brief and goal enter at planning](/diagrams/project-state-machine-light.svg)
+    ![Project state machine: discovery, spec, design, plan and implementation phases, then PR open and complete; a review loop returns to implementation, a revise loop runs from PR open and back, and lite, brief and goal enter at planning](/diagrams/project-state-machine-dark.svg)
 
 === "Mermaid source"
 
@@ -41,12 +41,14 @@ This page is the compact contract for how project lifecycle state and review sta
       PASSED --> I
 
       LITE["Lite: batched interview\n(no discovery/spec/design)"] -. entry point .-> P
-      BRIEF["Brief: alignment interview\n(one Project Brief)"] -. entry point .-> P
+      BRIEF["Brief or goal: interview\n(one Project Brief)"] -. entry point .-> P
     ```
 
-The solid chain is the spec-driven progression. Lite and brief enter at **Plan
-in progress** and never set `oat_phase` to `discovery`, `spec`, or `design`;
-quick and import projects also skip part of the leading chain.
+The solid chain is the spec-driven progression. Lite, brief and goal enter at
+**Plan in progress** and never set `oat_phase` to `discovery`, `spec`, or
+`design`; quick and import projects also skip part of the leading chain. Goal
+adds a milestone state machine inside implementation, described under
+[Goal progression](#goal-progression).
 
 ## Phase status values
 
@@ -107,6 +109,38 @@ A brief project can move to the quick chain with `oat project promote
 `oat_promotion_pending_phases` lists phases that still need tasks. See
 [Lifecycle](../workflows/projects/lifecycle.md#promoting-a-brief-project-to-quick).
 
+### Goal progression
+
+A goal project runs the brief chain once per milestone. `oat_phase` and
+`oat_phase_status` keep their meaning; the milestone loop lives in its own
+`state.md` fields, owned as follows:
+
+| `oat_milestone_status` | Meaning                                                  | Next owner and transition                                                                                                                                                                                                                                                                                        |
+| ---------------------- | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `aligning`             | The next milestone is being planned or awaits activation | `oat-project-goal` activates it (`implementing`) after review, its `plan` carrier, approval, and the previous delivery observed at its agreed endpoint                                                                                                                                                           |
+| `implementing`         | The milestone's phase-units are executing                | Implement's milestone closeout runs the `exit` gate and writes `reviewing`                                                                                                                                                                                                                                       |
+| `reviewing`            | The exit carrier is fresh; the integrated review is next | `oat-project-review-receive` writes `delivering` on a clean receive of the integrated review, or `implementing` when fixes are queued                                                                                                                                                                            |
+| `delivering`           | A passed, fresh integrated review and exit carrier       | `oat-project-pr-progress` registers the delivery (`dNN`) and writes `delivered`; stale evidence sends it back to `reviewing`; `oat-project-review-receive` returns it to `implementing` when a delivery-time review queues fixes                                                                                 |
+| `delivered`            | The delivery is registered, open and review-ready        | `oat-project-goal` re-aligns (`aligning` for the next milestone) once the delivery reaches its endpoint, or records the terminal declaration; `oat-project-pr-progress` returns it to `reviewing` when `oat-project-goal` hands back a stale delivery whose integrated review or exit carrier is no longer fresh |
+
+`oat_goal_status` is `active` until the user declares the goal met
+(`declared_met`) with an exhaustive `oat_goal_outcome_audit`. Recovery of an
+older milestone's delivery is recorded in `oat_goal_recovery` and never moves
+`oat_milestone` or its status. `oat-project-revise` may return the active
+milestone from `delivered` or `delivering` to `implementing` for inline
+feedback. The router reads only these persisted fields; delivery freshness
+comes from `oat project delivery refresh` and `oat project delivery check`.
+
+`delivered` and the registry's `at_endpoint` are different: `delivered` means
+the pull request is registered and open, `at_endpoint` means it has reached
+the agreed endpoint (`open` or `merged`). Re-alignment may draft and approve
+the next milestone while a `merged` endpoint is pending, but activation waits
+for it. Terminal closeout (`oat project closeout-check`,
+`oat project complete-state`) requires the declaration, the audit and delivery
+coverage of every accepted phase. A goal project can move to quick at a settled
+delivery boundary; see
+[Lifecycle](../workflows/projects/lifecycle.md#promoting-a-goal-project-to-quick).
+
 ## Review progression
 
 In `plan.md` Reviews table:
@@ -120,5 +154,5 @@ Do not move to the next lifecycle state if review/state artifacts indicate unres
 ## Reference artifacts
 
 - `.oat/projects/<scope>/<project>/state.md`
-- `.oat/projects/<scope>/<project>/plan.md` (`## Reviews`)
+- `.oat/projects/<scope>/<project>/plan.md` (`## Reviews`, and `## Milestones` for goal)
 - `.oat/projects/<scope>/<project>/implementation.md`

package/assets/docs/skills/brainstorm.md

@@ -47,8 +47,9 @@ instead). Saving a brainstorming reference file under the active project also
 commits or pushes that file. Promoting to a new project runs
 `oat project new`, which scaffolds the project and makes it your active
 project, and then writes a completed `discovery.md` (or, for a lite project,
-fills in its `plan.md`; for a brief project, writes a research note under
-`references/research/` and leaves the brief to `oat-project-brief`). Capturing a new idea also sets it as your active
+fills in its `plan.md`; for a brief or goal project, writes a research note
+under `references/research/` and leaves the brief to `oat-project-brief` or
+`oat-project-goal`). Capturing a new idea also sets it as your active
 idea in local OAT config. Each destination is confirmed before anything is
 written.
 

package/assets/docs/skills/index.md

@@ -42,7 +42,7 @@ make only the changes you approve.
 
 ## Key Skills by Use Case
 
-- Start a new tracked project: `oat-project-new`, `oat-project-quick-start`, or `oat-project-lite` for a single-sitting change with one batched interview and one approval (quick start accepts a project name plus optional description; if you omit the description it should ask before discovery begins)
+- Start a new tracked project: `oat-project-new`, `oat-project-quick-start`, `oat-project-lite` for a single-sitting change with one batched interview and one approval (quick start accepts a project name plus optional description; if you omit the description it should ask before discovery begins), `oat-project-brief` for one delivery agreed in conversation, or `oat-project-goal` for an outcome delivered in milestones
 - Resume an existing project: `oat-project-open` to select it,
   `oat-project-progress` to see where it stands, then `oat-project-next` to
   continue. See
@@ -118,6 +118,8 @@ for policy, storage, approval, and recovery details.
     - `oat-project-new`
     - `oat-project-quick-start`
     - `oat-project-lite`
+    - `oat-project-brief`
+    - `oat-project-goal`
     - `oat-project-import-plan`
     - `oat-project-promote-spec-driven`
     - `oat-project-open`
@@ -305,15 +307,16 @@ Visibility reports source metadata: “user” is `user-invocable` and “model
 
 ### Project entry
 
-| Skill                                                                                                    | Description                                                                                                                                                                                                         | Visibility                       | Needs an active project? |
-| -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- | ------------------------ |
-| [`oat-project-brief`](../workflows/projects/planning/starting-projects.md#oat-project-brief)             | Use when one delivery needs a design-aligned interview, a single approved Project Brief with phases of intent and exit evidence instead of planned tasks, and resumable OAT implementation.                         | user: true; model disabled: true | No                       |
-| [`oat-project-capture`](../workflows/projects/planning/starting-projects.md#oat-project-capture)         | Use when work happened outside the OAT project workflow and needs retroactive project tracking. Creates a full project from an existing branch and conversation context.                                            | user: true; model disabled: true | No                       |
-| [`oat-project-import-plan`](../workflows/projects/planning/starting-projects.md#oat-project-import-plan) | Use when you have an external markdown plan to execute with OAT. Preserves the source plan and normalizes it into canonical plan.md format.                                                                         | user: true; model disabled: true | No                       |
-| [`oat-project-lite`](../workflows/projects/planning/starting-projects.md#oat-project-lite)               | Use when a single-sitting change needs a critical interview, an approved single-phase plan, and resumable OAT implementation with minimal ceremony.                                                                 | user: true; model disabled: true | No                       |
-| [`oat-project-new`](../workflows/projects/planning/starting-projects.md#oat-project-new)                 | Use when starting a spec-driven OAT project from scratch. Scaffolds a new project under PROJECTS_ROOT and sets it active.                                                                                           | user: true; model disabled: true | No                       |
-| [`oat-project-quick-start`](../workflows/projects/planning/starting-projects.md#oat-project-quick-start) | Use when a task is small enough for quick mode or rapid iteration is preferred. Scaffolds a lightweight OAT project from discovery directly to a runnable plan, with optional brainstorming and lightweight design. | user: true; model disabled: true | No                       |
-| [`oat-project-split`](../workflows/projects/planning/starting-projects.md#oat-project-split)             | Use when a discovery or brainstorm should split one broad scope into coordinated OAT child projects.                                                                                                                | user: true; model disabled: true | No                       |
+| Skill                                                                                                    | Description                                                                                                                                                                                                                              | Visibility                       | Needs an active project? |
+| -------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- | ------------------------ |
+| [`oat-project-brief`](../workflows/projects/planning/starting-projects.md#oat-project-brief)             | Use when one delivery needs a design-aligned interview, a single approved Project Brief with phases of intent and exit evidence instead of planned tasks, and resumable OAT implementation.                                              | user: true; model disabled: true | No                       |
+| [`oat-project-capture`](../workflows/projects/planning/starting-projects.md#oat-project-capture)         | Use when work happened outside the OAT project workflow and needs retroactive project tracking. Creates a full project from an existing branch and conversation context.                                                                 | user: true; model disabled: true | No                       |
+| [`oat-project-goal`](../workflows/projects/planning/starting-projects.md#oat-project-goal)               | Use when an outcome needs several deliveries over time - one approved Project Brief with a Milestones table, a milestone loop of activation, delivery and re-alignment, and a terminal declaration audited against the brief's outcomes. | user: true; model disabled: true | No                       |
+| [`oat-project-import-plan`](../workflows/projects/planning/starting-projects.md#oat-project-import-plan) | Use when you have an external markdown plan to execute with OAT. Preserves the source plan and normalizes it into canonical plan.md format.                                                                                              | user: true; model disabled: true | No                       |
+| [`oat-project-lite`](../workflows/projects/planning/starting-projects.md#oat-project-lite)               | Use when a single-sitting change needs a critical interview, an approved single-phase plan, and resumable OAT implementation with minimal ceremony.                                                                                      | user: true; model disabled: true | No                       |
+| [`oat-project-new`](../workflows/projects/planning/starting-projects.md#oat-project-new)                 | Use when starting a spec-driven OAT project from scratch. Scaffolds a new project under PROJECTS_ROOT and sets it active.                                                                                                                | user: true; model disabled: true | No                       |
+| [`oat-project-quick-start`](../workflows/projects/planning/starting-projects.md#oat-project-quick-start) | Use when a task is small enough for quick mode or rapid iteration is preferred. Scaffolds a lightweight OAT project from discovery directly to a runnable plan, with optional brainstorming and lightweight design.                      | user: true; model disabled: true | No                       |
+| [`oat-project-split`](../workflows/projects/planning/starting-projects.md#oat-project-split)             | Use when a discovery or brainstorm should split one broad scope into coordinated OAT child projects.                                                                                                                                     | user: true; model disabled: true | No                       |
 
 ### Project execution
 

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

@@ -337,7 +337,9 @@ and a dispatch policy is already configured. You authorize the bounded
 resumable-export goal through a final PR without ordinary mid-run approval
 pauses. Autonomous entry chooses
 lite, brief, quick, or spec-driven review density from the actual uncertainty and
-invokes its owning creation skill. If an export-filter project is already
+invokes its owning creation skill. It never selects goal: each milestone's
+approval and the final declaration need a person, so an existing goal project
+stops at a product-judgment boundary instead of running unattended. If an export-filter project is already
 active, the second example explicitly resumes its earliest incomplete step
 instead of replaying finished phases.
 

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

@@ -22,8 +22,8 @@ constraints:
   agents to implement and review each phase, or no cap, or leaving model choice
   to the provider; and deciding where the list of candidate models (the
   _ladder_) is stored.
-- **Who needs it:** anyone starting a quick, spec-driven, lite, or imported
-  project, because planning asks you to choose a policy; and team leads who
+- **Who needs it:** anyone starting a quick, spec-driven, lite, brief, goal,
+  or imported project, because planning asks you to choose a policy; and team leads who
   manage model cost.
 - **Know first:** there is no default policy, and a policy set in any config
   file overrides the one each project chose. A tier is a cap: phase agents may

package/assets/docs/workflows/advanced/workflow-gates.md

@@ -98,7 +98,7 @@ 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`,
-`oat-project-lite`, `oat-project-brief`, and `oat-project-import-plan` are currently gate-aware. Gate awareness is declared
+`oat-project-lite`, `oat-project-brief`, `oat-project-goal`, 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.
@@ -282,6 +282,19 @@ committed brief, carries exactly the same core with the same outcome rules. It
 is provenance only: no route reads it back, and the brief's single approval
 still follows the gate.
 
+A goal project records its gate outcomes per milestone instead, in
+`oat_milestone_gates`, and never in `oat_brief_gate`. The configured
+`oat-project-goal` gate on the brief or a milestone amendment becomes that
+milestone's `plan` carrier, `oat_milestone_gates[mNN].plan`, written with
+`status: allowed` only after the artifact review, the gate, and your approval;
+for a re-alignment amendment it is the only approval evidence. The implement
+exit gate at milestone closeout writes `oat_milestone_gates[mNN].exit` (never
+`oat_implement_exit_gate`, which goal uses only at terminal closeout). It runs
+before the milestone's integrated review and runs again after queued fixes.
+`oat project delivery check` reports the exit carrier's freshness, and
+`oat project delivery refresh` marks it stale when delivery evidence no longer
+holds.
+
 `oat-project-next` and `oat-project-progress` report the quick-start record
 (and `oat-project-progress` the brief record) as recorded: status, disposition, `decided_at`, and `config_fingerprint` as
 provenance, or `malformed` when the fields do not form a valid record. They do
@@ -845,7 +858,7 @@ oat gate set oat-project-implement \
 ```
 
 Apply the same command shape to `oat-project-plan`,
-`oat-project-quick-start`, `oat-project-lite`, `oat-project-brief`, and `oat-project-import-plan` when those lifecycle
+`oat-project-quick-start`, `oat-project-lite`, `oat-project-brief`, `oat-project-goal`, 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.
 
@@ -1239,8 +1252,8 @@ as a failed gate, never as a pass.
 
 How the skills handle that case differs:
 
-- `oat-project-implement`, `oat-project-lite`, and `oat-project-brief` keep it blocked whatever
-  `onFailure` says, so even a `warn` gate does not let them continue.
+- `oat-project-implement`, `oat-project-lite`, `oat-project-brief`, and
+  `oat-project-goal` keep it blocked whatever `onFailure` says, so even a `warn` gate does not let them continue.
 - `oat-project-plan`, `oat-project-quick-start`, and `oat-project-import-plan`
   apply your `onFailure` setting to any failed gate run, including one where no
   review happened. With `block`, they retry and then hand the problem to you,