@open-agent-toolkit/cli 0.3.19 → 0.3.21

package/assets/docs/workflows/projects/planning/planning-skills.md

@@ -13,7 +13,7 @@ For a spec-driven project (one using the full workflow: discovery, design, plan,
 then implementation), the usual path is discovery, then design, then plan.
 Design confirms requirements and produces `spec.md` as well as `design.md`.
 Standalone spec is optional when you want to review requirements before
-designing. Quick, lite, brief, and import workflows author their own plans through
+designing. Quick, lite, brief, goal, and import workflows author their own plans through
 their entry skills. Do not send those projects through spec-driven planning
 just because they contain a file named `plan.md`.
 
@@ -55,7 +55,7 @@ A _HiLL (human-in-the-loop lifecycle) checkpoint_ is a point where a skill stops
 and waits for your explicit approval before marking a phase complete. Projects
 created with `oat-project-new` have HiLL approvals on discovery and design **by
 default**: each skill stops after writing its artifact and waits for your
-explicit approval before marking it complete. Quick, lite, brief, and import
+explicit approval before marking it complete. Quick, lite, brief, goal, and import
 projects have no workflow-phase HiLL checkpoints. Configured exit gates (optional reviews
 or commands your repository runs before a skill marks its work complete) can
 also keep an artifact in progress. See [HiLL checkpoints](hill-checkpoints.md).
@@ -83,7 +83,7 @@ spec-driven project. The repository knowledge index must exist at
 `oat-repo-knowledge-index` first. The skill checks knowledge staleness and asks
 whether to refresh or continue when the index is stale.
 
-Quick, import, lite, and brief projects use their own next step instead. Mentioning a
+Quick, import, lite, brief, and goal projects use their own next step instead. Mentioning a
 new idea does not authorize automatic discovery invocation.
 
 **Example scenario:** The webhook-delivery project is active, but the team has
@@ -270,12 +270,14 @@ skill asks for a project name and sets it as the active project. The project
 must use spec-driven mode, with `design.md` recording `oat_status: complete` and
 `oat_ready_for: oat-project-plan`.
 
-Quick, import, lite, and brief projects never use this skill to author a plan. On a
+Quick, import, lite, brief, and goal projects never use this skill to author a plan. On a
 quick project, it resumes quick-start if the plan is not ready, and **starts
 `oat-project-implement` immediately** if the plan is ready. On an import project
 with a plan, it points you to `oat-project-implement`. On a lite project, it
 points you to `oat-project-lite`. On a brief project, it stops and points you
-to `oat-project-brief`, which owns the Project Brief. Do not invoke it on those projects unless you
+to `oat-project-brief`, which owns the Project Brief. On a goal project, it
+stops and points you to `oat-project-goal`, which owns the brief, its
+milestones, and its amendments. Do not invoke it on those projects unless you
 intend that handoff.
 
 **Example scenario:** The webhook design now defines persistence, retries, and
@@ -339,11 +341,11 @@ Promote the active cache-refresh project, keeping its imported plan and complete
 skill asks for a project name and sets it as the active project. The active
 project's `state.md` must record quick or import workflow mode. A spec-driven
 project is already promoted, so the skill reports a no-op unless you request
-artifact refresh. Lite and brief projects must promote to quick first through
+artifact refresh. Lite, brief, and goal projects must promote to quick first through
 the actual terminal command:
 
 ```bash
-oat project promote <lite-or-brief-project-path> --to quick
+oat project promote <lite-brief-or-goal-project-path> --to quick
 ```
 
 Use the reported project path, for example

package/assets/docs/workflows/projects/planning/starting-projects.md

@@ -7,8 +7,8 @@ description: 'Choose a project entry skill, import an existing plan, capture com
 
 Choose an entry path based on what you already know and what already exists.
 These skills do not require an existing active project. They create or import
-tracked work, although quick-start, lite, and brief resume an active project of
-their own mode, and import writes into whichever project is active.
+tracked work, although quick-start, lite, brief, and goal resume an active
+project of their own mode, and import writes into whichever project is active.
 
 | Your situation                                                       | Entry skill               | Result                                                                            |
 | -------------------------------------------------------------------- | ------------------------- | --------------------------------------------------------------------------------- |
@@ -16,6 +16,7 @@ their own mode, and import writes into whichever project is active.
 | The outcome is bounded, with optional design decisions to resolve.   | `oat-project-quick-start` | Discovery and an executable plan, with lightweight design when needed.            |
 | The change fits one implementation sitting.                          | `oat-project-lite`        | One approved plan with requirements and validation criteria.                      |
 | One delivery whose outcome and design you can agree in conversation. | `oat-project-brief`       | One reviewed, approved Project Brief whose phases carry intent and exit evidence. |
+| An outcome that needs several deliveries over time.                  | `oat-project-goal`        | One approved Project Brief with milestones, delivered and re-aligned in turn.     |
 | You already have a Markdown plan.                                    | `oat-project-import-plan` | The original source preserved beside a normalized OAT plan.                       |
 | Implementation happened without project tracking.                    | `oat-project-capture`     | Retroactive discovery and implementation records from the session and commits.    |
 | A confirmed scope contains several coordinated projects.             | `oat-project-split`       | A coordination parent and children that resume at discovery.                      |
@@ -69,15 +70,15 @@ in a fresh repository.
    overrides the setting for one shell.
 
 3. **Only `oat-project-new` takes a scope.** It accepts `--scope shared|local|synced`.
-   Quick-start, lite, brief, import, capture, and split have no scope argument.
-   Quick-start, lite, brief, import, and capture always create projects in the
+   Quick-start, lite, brief, goal, import, capture, and split have no scope argument.
+   Quick-start, lite, brief, goal, import, and capture always create projects in the
    default scope. Split uses the active project's scope, or `shared` when no
    project is active. Set the default first if you do not want `synced`.
 
 4. **Build the knowledge index before spec-driven discovery.** `oat-project-discover`
    refuses to start until `.oat/repo/knowledge/project-index.md` exists. Run
    `/oat-repo-knowledge-index` once before your first spec-driven project.
-   Quick-start, lite, brief, import, and capture do not check for it.
+   Quick-start, lite, brief, goal, import, and capture do not check for it.
 
 5. **Know what happens when a project is already active.** Check with
    `oat config get activeProject` before you start:
@@ -110,14 +111,14 @@ Project creation normally activates the new project in `.oat/config.local.json`.
 Check the reported project path before continuing, especially when another
 project is already active.
 
-The new, quick-start, lite, brief, and import skills check inherited Git changes before
+The new, quick-start, lite, brief, goal, and import skills check inherited Git changes before
 scaffolding. Unrelated changes require an explicit disposition in interactive
 runs. One exception: if the only change is `.oat/sync/manifest.json`, it is
 committed automatically as `chore: run sync`. Capture does not run this check.
 Do not assume starting a project also authorizes implementation or a PR.
 
 **Dispatch policy.** Before a plan is marked ready, quick-start, lite, brief,
-and import ask you to choose a _dispatch policy_: the highest tier of models and
+goal, and import ask you to choose a _dispatch policy_: the highest tier of models and
 effort OAT may use when it dispatches implementation and review agents. The
 choices come from `oat project dispatch-ceiling choices`. If your configuration
 has no complete dispatch ladder (the list of models for each tier), the skill
@@ -129,10 +130,11 @@ deliberately. The plan stays not ready until this resolves. See
 **Approval checkpoints.** A _HiLL (human-in-the-loop lifecycle) checkpoint_ is
 a point where a skill stops and waits for your explicit approval before it marks
 a phase complete. Projects created by `oat-project-new` have checkpoints on
-discovery and design by default. Quick, lite, brief, import, and captured
-projects have no workflow-phase checkpoints before implementation. Lite still
-asks you to approve its plan once, and brief asks you to approve its reviewed
-brief once. See [HiLL checkpoints](hill-checkpoints.md).
+discovery and design by default. Quick, lite, brief, goal, import, and
+captured projects have no workflow-phase checkpoints before implementation.
+Lite still asks you to approve its plan once, brief asks you to approve its
+reviewed brief once, and goal asks for that approval and then one per later
+milestone. See [HiLL checkpoints](hill-checkpoints.md).
 
 Several skills also run a configured _exit gate_, an optional review or command
 your repository configures to run before a skill marks its work complete. When
@@ -371,6 +373,50 @@ the scaffold and start `oat-project-quick-start` instead. See
 
 **Next step:** Run `oat-project-implement` after the brief is approved.
 
+## oat-project-goal
+
+Use goal when an outcome needs several deliveries over time. Goal writes one
+reviewed Project Brief like brief does, and adds a `## Milestones` table that
+groups its phases into milestones. Each milestone is implemented, reviewed,
+delivered as its own pull request, and followed by a short re-alignment before
+the next one starts.
+
+**Invocation:** Provide the slug and the intended outcome.
+
+```text
+/oat-project-goal audit-exports "Give administrators audit exports in CSV first, then scheduled delivery."
+```
+
+**Prerequisites:** No active project is needed. If the active project is a
+goal project, goal resumes it at the step its state calls for: authoring,
+milestone activation, re-alignment, or the terminal declaration.
+
+**Example scenario:** Administrators need audit exports now and scheduled
+delivery later. Goal interviews you once for the whole outcome, splits it into
+milestone m01 (CSV export) and m02 (scheduled delivery), and activates m01.
+When m01's pull request is delivered, goal asks what changed, amends the brief
+with m02's phases, takes the amendment through review and approval, and
+activates m02 once m01 reaches the endpoint you agreed, such as merged.
+
+**Expected output:** One Project Brief in `plan.md` with
+`oat_plan_source: goal`, a canonical `| Milestone | Phases |` table in which
+every phase belongs to exactly one milestone, and the first milestone approved
+and activated. Each milestone's approval is recorded as its `plan` gate carrier
+in `state.md`; deliveries are recorded in the `oat_deliveries` registry by the
+delivery skills.
+
+**What it does without asking:** It creates the project through
+`oat project new --mode goal`, commits the brief before review, runs the
+artifact review and any configured `oat-project-goal` gate, refreshes delivery
+observations with `oat project delivery refresh`, and appends one project-log
+entry at each activation and re-alignment. It asks before: proceeding with a
+dirty working tree, the interview decisions and milestone split, each approval,
+the re-alignment questions, and declaring the goal met.
+
+**Next step:** Run `oat-project-implement` after the first milestone is
+activated. Between milestones, `oat-project-goal` re-aligns and activates the
+next milestone once the previous delivery reaches its agreed endpoint.
+
 ## oat-project-import-plan
 
 Use import when the plan already exists, including one produced in a provider's

package/assets/docs/workflows/projects/reviews/index.md

@@ -176,7 +176,7 @@ This feature is opt-in and disabled by default (missing or `enabled: false`). Fo
 
 Generated planning and analysis artifacts have a separate review loop from code/phase reviews.
 
-For plans, `oat-project-plan`, `oat-project-quick-start`, `oat-project-lite`, `oat-project-brief`, and `oat-project-import-plan` run a bounded `plan.md` artifact review before marking the plan ready for implementation. The loop dispatches `oat-reviewer` in structured-output artifact mode with `scope: plan`, applies unambiguous Critical and High artifact-local fixes, offers Medium and Low fixes, and re-runs until clean or the retry bound is exhausted. A clean result records the `plan` row in the plan's `## Reviews` table as `passed`.
+For plans, `oat-project-plan`, `oat-project-quick-start`, `oat-project-lite`, `oat-project-brief`, `oat-project-goal` (for the brief and each milestone amendment), and `oat-project-import-plan` run a bounded `plan.md` artifact review before marking the plan ready for implementation. The loop dispatches `oat-reviewer` in structured-output artifact mode with `scope: plan`, applies unambiguous Critical and High artifact-local fixes, offers Medium and Low fixes, and re-runs until clean or the retry bound is exhausted. A clean result records the `plan` row in the plan's `## Reviews` table as `passed`.
 
 For analysis artifacts, `oat-docs-analyze` and `oat-agent-instructions-analyze` run a bounded accuracy review after writing their severity-rated artifacts. The reviewer checks cited evidence, severity, and recommendations before the matching apply workflow consumes the artifact. The analysis loop updates tracking metadata to mark the artifact verified.
 
@@ -232,12 +232,33 @@ or contradictory anchors stop the review and route to `oat-project-reconcile`.
 A brief `final` review also audits every numbered Outcome against the
 journal's evidence.
 
+In a goal project, per-phase reviews (`pNN`, `p-revN`) use the brief anchors.
+A milestone's integrated review names the milestone or delivery and its exact
+ordered phase set, for example `code m01: p01, p02, p-rev1` or
+`code m01/d01: p01, p02, p-rev1`; a `pNN-pMM` or `final` token is refused for
+it, and membership is never expanded from first to last phase. The set must
+match the milestone's `## Milestones` row, a pending `oat_goal_recovery`
+record, or a registered delivery's frozen scope. Before dispatch, the
+milestone's exit carrier must be allowed and fresh; otherwise the review stops
+and routes to implement's milestone closeout. The range runs from the first
+member's base to the last member's head, and phases of other milestones inside
+it are listed under `Intervening changes:` and judged only as context. The
+artifact records `oat_review_requested_scope: mNN` (or `mNN/dNN`) and
+`oat_review_phase_ids` with the exact set, and a narrowed re-review keeps the
+full set. The `## Reviews` Scope cell is the milestone ID (`m01`) or, for a
+registered delivery, the delivery ID (`d01`). The review is recorded as
+`received`; `oat-project-review-receive` moves the milestone to `delivering`
+on a clean receive.
+
 Final review `passed` gate requires:
 
 - No unresolved Critical/High/Medium findings.
 - Deferred Medium findings resurfaced and explicitly dispositioned.
 - Low findings explicitly dispositioned (after plain-language explanation).
 
+A goal milestone delivery is gated by its passed, fresh integrated review and
+exit carrier rather than by a `final` row.
+
 ## Complexity review at budget exhaustion
 
 When a review or gate budget runs out, another round of the same review is

package/assets/docs/workflows/projects/reviews/review-flavors.md

@@ -120,7 +120,7 @@ different things can happen, and only two of them stop the workflow:
   out without writing a review, or wrote a review OAT could not validate or
   match to this run. Nothing was reviewed. `oat-project-implement` and
   `oat-project-lite` keep these failures blocked whatever `onFailure` says,
-  and so does `oat-project-brief`.
+  and so do `oat-project-brief` and `oat-project-goal`.
   The planning skills handle them differently; see
   [When the gate finds blocking problems](../../advanced/workflow-gates.md#when-the-gate-finds-blocking-problems).
 - **Reviewer selection falls back.** By default (`--avoid same-family`) the gate
@@ -458,9 +458,11 @@ request.
 **Prerequisites:** An initialized project must resolve from the active pointer
 or an explicitly supplied project/review target. Its core artifacts must be
 committed before review. Code review needs completed implementation work and
-the mode-appropriate requirements sources; lite and brief reviews do not
+the mode-appropriate requirements sources; lite, brief, and goal reviews do not
 require absent discovery, spec or design artifacts. A brief code review takes
-its range from the journal's phase anchors. Code reviews and plan artifact reviews
+its range from the journal's phase anchors. A goal integrated review names its
+milestone or delivery and its exact ordered phase set; see
+[Phase and final review](index.md#phase-and-final-review). Code reviews and plan artifact reviews
 also need a resolved dispatch policy (`oat_dispatch_policy` in `state.md` or
 `workflow.dispatchPolicy.*` in config); without one the review stops before
 launching a reviewer. Discovery, spec and design artifact reviews run without

package/assets/public-package-versions.json

@@ -1,6 +1,6 @@
 {
-  "cli": "0.3.19",
-  "docs-config": "0.3.19",
-  "docs-theme": "0.3.19",
-  "docs-transforms": "0.3.19"
+  "cli": "0.3.21",
+  "docs-config": "0.3.21",
+  "docs-theme": "0.3.21",
+  "docs-transforms": "0.3.21"
 }

package/assets/skills/oat-brainstorm/SKILL.md

@@ -5,7 +5,7 @@ disable-model-invocation: false
 user-invocable: true
 allowed-tools: Read, Write, Bash, Glob, Grep, AskUserQuestion
 metadata:
-  version: 1.3.9
+  version: 1.3.10
 ---
 
 # Brainstorm
@@ -238,7 +238,7 @@ ACTIVE_PROJECT_PR_STATUS=""
 if [ -n "$ACTIVE_PROJECT" ] && [ -f "$ACTIVE_PROJECT/state.md" ]; then
   ACTIVE_PROJECT_VALID="true"
   # Read state.md frontmatter — extract:
-  #   oat_workflow_mode → ACTIVE_PROJECT_MODE        (e.g., "spec-driven", "quick", "import", "lite", "brief")
+  #   oat_workflow_mode → ACTIVE_PROJECT_MODE        (e.g., "spec-driven", "quick", "import", "lite", "brief", "goal")
   #   oat_phase         → ACTIVE_PROJECT_PHASE       (e.g., "discovery", "design", "plan", "implement")
   #   oat_pr_status     → ACTIVE_PROJECT_PR_STATUS   (e.g., "none", "open", "closed")
 fi
@@ -401,8 +401,8 @@ The payload is staged in memory only — it is not persisted between conversatio
   - Capture as new idea → confirm slug.
   - Extend existing idea → confirm which idea (slug or path).
   - Doc-to-path → confirm path.
-  - Promote to new project → confirm slug + workflow mode (`lite`, `brief`, `quick`, or `spec-driven`, with skill proposing a default based on the chosen direction and scope signals).
-  - Active-project fold-back → for lite and brief confirm `plan.md`; for import confirm `design.md` or `discovery.md` when present, else `plan.md`; otherwise confirm which artifact (`design.md` if exists, else `discovery.md`; user signal can override toward `discovery.md` for foundational changes).
+  - Promote to new project → confirm slug + workflow mode (`lite`, `brief`, `goal`, `quick`, or `spec-driven`, with skill proposing a default based on the chosen direction and scope signals; propose `goal` when the direction needs several deliveries over time).
+  - Active-project fold-back → for lite, brief, and goal confirm `plan.md`; for import confirm `design.md` or `discovery.md` when present, else `plan.md`; otherwise confirm which artifact (`design.md` if exists, else `discovery.md`; user signal can override toward `discovery.md` for foundational changes).
   - Active-project reference file → confirm filename (default `YYYY-MM-DD-<topic>.md`).
 
 - **`none`** (currently `Inline only` and `Summarize idea directly`): no per-field confirmation at this layer. For `Inline only`, write the closing summary directly. For `Summarize idea directly`, hand off — the downstream `oat-idea-summarize` surfaces its own summary for accept/refine review.
@@ -510,7 +510,7 @@ End mode assertion when the backlog-add hands control back.
 
 #### 9g — Promote to new OAT project
 
-The slug and workflow mode (`lite`, `brief`, `quick`, or `spec-driven`) were confirmed at
+The slug and workflow mode (`lite`, `brief`, `goal`, `quick`, or `spec-driven`) were confirmed at
 step 8. Run:
 
 ```bash
@@ -562,6 +562,15 @@ reading that research first. Do not create `discovery.md` or `design.md`.
 Leave the project state at plan/in-progress, print the `oat-project-brief`
 handoff, and stop.
 
+**Goal branch:** When mode is `goal`, arrive exactly as the brief branch does:
+the goal scaffold holds the same files (its `plan.md` carries
+`oat_plan_source: goal` and the canonical Milestones table header). Write the
+synthesized payload to `<project>/references/research/brainstorm-YYYY-MM-DD.md`,
+leave `plan.md` as scaffolded for `oat-project-goal` to author through its
+interview (including the milestone split), do not create `discovery.md` or
+`design.md`, leave the project state at plan/in-progress, print the
+`oat-project-goal` handoff, and stop.
+
 **Quick/spec-driven branch:** Only for those two modes, continue with the
 discovery flow below.
 
@@ -608,12 +617,13 @@ The 3-way router fires once per session. After convergence resumes (e.g., the us
 
 #### 9i — Active project: fold-back to upstream artifact
 
-Uniform across spec-driven, quick, import, lite, and brief modes. Differs only in which plan-authoring skill the handoff prompt addresses (resolved by `ACTIVE_PROJECT_MODE` and `ACTIVE_PROJECT_PR_STATUS`).
+Uniform across spec-driven, quick, import, lite, brief, and goal modes. Differs only in which plan-authoring skill the handoff prompt addresses (resolved by `ACTIVE_PROJECT_MODE` and `ACTIVE_PROJECT_PR_STATUS`).
 
 **Step 1 — Pick upstream artifact.** Prefer the most-specific existing one:
 
 - For lite, always select `<ACTIVE_PROJECT>/plan.md`. Append `## Brainstorming Update` immediately above `## Phase 1`; lite has no discovery or design artifact.
 - For brief, always select `<ACTIVE_PROJECT>/plan.md` (the Project Brief). Append `## Brainstorming Update` immediately above the first `## Phase` heading; brief has no discovery or design artifact, and the receiving skill folds the update into the brief's sections.
+- For goal, select `<ACTIVE_PROJECT>/plan.md` exactly as for brief; the update never edits the `## Milestones` table, which the receiving skill amends.
 - For import, use `design.md` or `discovery.md` when present (the rules below); otherwise `<ACTIVE_PROJECT>/plan.md`, because the import scaffold has neither.
 - `<ACTIVE_PROJECT>/design.md` if it exists (any mode — quick lightweight design counts).
 - Otherwise `<ACTIVE_PROJECT>/discovery.md`.
@@ -686,7 +696,7 @@ beside another dirty project file must take Step 4.
 
    For non-synced projects, use the explicit `--` filename form. **Never `git add -A`. Never directory globs.** Other working-tree paths are not touched by this commit. For synced projects, `FOLD_BACK_COMMIT_SHA` comes from the push JSON rather than the parent branch.
 
-3. `<artifact-basename>` is `plan.md` for lite and brief (and for import when it has no `design.md` or `discovery.md`), otherwise `design.md` or `discovery.md` depending on which was chosen. `<project-name>` is the active project's slug.
+3. `<artifact-basename>` is `plan.md` for lite, brief, and goal (and for import when it has no `design.md` or `discovery.md`), otherwise `design.md` or `discovery.md` depending on which was chosen. `<project-name>` is the active project's slug.
 
 4. If the guarded persistence succeeded → proceed to step 5 (handoff prompt).
 
@@ -763,6 +773,7 @@ Resolve the handoff target by `ACTIVE_PROJECT_MODE` and `ACTIVE_PROJECT_PR_STATU
 | lite        | none / closed                | `oat-project-lite`        |
 | import      | none / closed                | `oat-project-import-plan` |
 | brief       | none / closed                | `oat-project-brief`       |
+| goal        | none / closed                | `oat-project-goal`        |
 | any mode    | open (`oat_pr_status: open`) | `oat-project-revise`      |
 
 For brief, `oat-project-brief` is the target while the brief is still in
@@ -775,6 +786,20 @@ prompt's last two sentences read "Integrate the new content into the brief as
 new or amended phases. Don't refresh the brief — preserve the review table and
 the journal." instead.
 
+For goal, `oat-project-goal` is the target: it folds the update into the
+brief as an amendment through its review ladder, during authoring or at the
+next re-alignment (`delivered`). While a milestone is active, an update that
+stays inside that milestone's approved Outcomes and Approach goes to
+`oat-project-implement` instead, which adds the new phases to the active
+milestone's `## Milestones` row; anything else waits for re-alignment. The
+prompt's last two sentences read as for brief.
+
+With an open PR in goal mode the open PR is a registered delivery, and
+`oat-project-revise` requires an explicit target. Name it in the prompt: add
+"Target: <mNN>/<dNN> (the open delivery)." after its first sentence, with the
+milestone and delivery IDs read from the `oat_deliveries` entry whose member
+URL is `oat_pr_url`.
+
 Print the handoff prompt template, substituting `<skill-name>`, `<artifact>`, `<hash>`, and `<subject>` from the actual branch commit or synced push receipt:
 
 ```
@@ -846,9 +871,9 @@ End mode assertion when the split handoff completes or reports its own blocker.
 - ✅ The terminal-state picker conditionally includes `Promote to N projects` only when `oat project split evaluate-signals` reports `triggered: true`; small-scope convergence keeps the option hidden.
 - ✅ Synthesis payload is built per the design Data Models `SynthesizedPayload` schema: `title`, `summary`, `motivation`, `vision`, `approachesConsidered[]`, `chosenDirection`, `openQuestions[]`, `nextSteps[]`, `transcriptSessionNote`.
 - ✅ Confirmation pattern matches `references/destinations.md`: `full` for scoped backlog item (field-by-field with example wording), `minimal` for slug/path/artifact destinations, `none` for inline-only and summarize-idea-directly.
-- ✅ Each handoff branch (9a-9k) reads the correct downstream `SKILL.md` path and enters at the documented step. Project promotion writes `discovery.md` for quick/spec-driven, `plan.md` for lite, and a `references/research/` note for brief — never `design.md` — and does not auto-chain into the next phase.
+- ✅ Each handoff branch (9a-9k) reads the correct downstream `SKILL.md` path and enters at the documented step. Project promotion writes `discovery.md` for quick/spec-driven, `plan.md` for lite, and a `references/research/` note for brief and goal — never `design.md` — and does not auto-chain into the next phase.
 - ✅ Doc-to-path validation handles all four cases: path-is-directory, parent-missing (with explicit out-of-repo confirmation), file-already-exists (overwrite or rename), unwritable (surface OS error).
 - ✅ Fold-back persistence safety contract honored: preflight `git status --porcelain -- "$ARTIFACT_PATH"` runs before any artifact mutation; clean → append + exact-path branch commit for shared/local or validated `oat project push --json` for synced; dirty → three-option picker (persist-prior-first / mix / abort-to-reference-file); handoff prompt prints only after the scope-appropriate receipt succeeds.
-- ✅ Handoff target for fold-back resolves correctly per `oat_workflow_mode` + `oat_pr_status`: `oat-project-plan` (spec-driven, no/closed PR) / `oat-project-quick-start` (quick, no/closed PR) / `oat-project-lite` (lite, no/closed PR) / `oat-project-import-plan` (import, no/closed PR) / `oat-project-brief` or `oat-project-implement` (brief, no/closed PR, by phase) / `oat-project-revise` (any mode, open PR).
+- ✅ Handoff target for fold-back resolves correctly per `oat_workflow_mode` + `oat_pr_status`: `oat-project-plan` (spec-driven, no/closed PR) / `oat-project-quick-start` (quick, no/closed PR) / `oat-project-lite` (lite, no/closed PR) / `oat-project-import-plan` (import, no/closed PR) / `oat-project-brief` or `oat-project-implement` (brief, no/closed PR, by phase) / `oat-project-goal` or `oat-project-implement` (goal, no/closed PR, by milestone state) / `oat-project-revise` (any mode, open PR; goal names the target delivery).
 - ✅ Active-project 3-way router (related / independent / supplementary) fires before the standard pack-filtered picker when both `WORKFLOWS_INSTALLED == "true"` and `ACTIVE_PROJECT_VALID == "true"`.
 - ✅ Skill validates cleanly under `pnpm oat:validate-skills` (frontmatter contract, allowed-tools, mode-assertion structure).

package/assets/skills/oat-brainstorm/references/destinations.md

@@ -122,8 +122,8 @@ Confirm to write this to a new backlog item file, or tell me what to change.
 **Required template fields:** `title`, `summary` (Initial Request), `approachesConsidered` (Solution Space), `chosenDirection` (Chosen Direction), key decisions, `openQuestions`. Template: `.oat/templates/discovery.md` (consumed via `oat project new`).
 **Optional template fields:** `motivation`, `vision`, `nextSteps`.
 **Confirmation pattern:** `minimal` (slug + workflow mode)
-Skill proposes `lite`, `brief`, `quick`, or `spec-driven` mode based on `chosenDirection` and scope signals from the conversation. User picks; skill confirms slug.
-**Handoff target:** Run `oat project new <slug> --mode <mode>` to scaffold. Write field-filled `discovery.md` only (Initial Request, Solution Space with approaches, Chosen Direction, Key Decisions, Open Questions). Mark `oat_status: complete`, `oat_ready_for: oat-project-quick-start` (for quick mode) or `oat-project-design` (for spec-driven). Update project `state.md` (phase=discovery, status=complete). Print pointer to next skill. **Stop — do NOT inline-execute the next phase.** Project promotion writes `discovery.md` only, never `design.md`. For `brief` mode there is no `discovery.md`: write the synthesized payload to `references/research/brainstorm-YYYY-MM-DD.md`, leave the scaffolded `plan.md` (the Project Brief) for `oat-project-brief` to author through its interview, keep state at plan/in-progress, and point to `oat-project-brief`. For `lite` mode, fill `plan.md` as `oat-brainstorm` step 9g describes and point to `oat-project-lite`.
+Skill proposes `lite`, `brief`, `goal`, `quick`, or `spec-driven` mode based on `chosenDirection` and scope signals from the conversation (`goal` when the direction needs several deliveries over time). User picks; skill confirms slug.
+**Handoff target:** Run `oat project new <slug> --mode <mode>` to scaffold. Write field-filled `discovery.md` only (Initial Request, Solution Space with approaches, Chosen Direction, Key Decisions, Open Questions). Mark `oat_status: complete`, `oat_ready_for: oat-project-quick-start` (for quick mode) or `oat-project-design` (for spec-driven). Update project `state.md` (phase=discovery, status=complete). Print pointer to next skill. **Stop — do NOT inline-execute the next phase.** Project promotion writes `discovery.md` only, never `design.md`. For `brief` mode there is no `discovery.md`: write the synthesized payload to `references/research/brainstorm-YYYY-MM-DD.md`, leave the scaffolded `plan.md` (the Project Brief) for `oat-project-brief` to author through its interview, keep state at plan/in-progress, and point to `oat-project-brief`. `goal` mode arrives the same way and points to `oat-project-goal`, which authors the brief and its milestone split. For `lite` mode, fill `plan.md` as `oat-brainstorm` step 9g describes and point to `oat-project-lite`.
 **If user wants to keep brainstorming after this is offered:** return to flow with destination = promote-to-new-project. Skill probes for missing chosen direction, key decisions, and explicit open questions — these become artifact fields that read poorly when shallow.
 
 ---
@@ -132,7 +132,7 @@ Skill proposes `lite`, `brief`, `quick`, or `spec-driven` mode based on `chosenD
 
 **Pack required:** `workflows` AND an active project pointer is set (`oat config get activeProject`) AND its `state.md` is readable.
 **Trigger phrases:** "fold this into the active project", "this is feedback for the active project", "integrate this into design", "add this to discovery", explicit "for the active project" mention. Also offered as the first option when the active-project 3-way router fires after convergence (related → fold-back).
-**Required template fields:** which artifact (`plan.md` for lite and brief; for import `design.md` or `discovery.md` when present, else `plan.md`; otherwise `design.md` if exists, else `discovery.md`; user signal can override), the synthesized payload's `chosenDirection`, key decisions, `transcriptSessionNote` (transcript appendix). Template: appended in-place using `## Brainstorming Update: YYYY-MM-DD — <topic>` heading.
+**Required template fields:** which artifact (`plan.md` for lite, brief, and goal; for import `design.md` or `discovery.md` when present, else `plan.md`; otherwise `design.md` if exists, else `discovery.md`; user signal can override), the synthesized payload's `chosenDirection`, key decisions, `transcriptSessionNote` (transcript appendix). Template: appended in-place using `## Brainstorming Update: YYYY-MM-DD — <topic>` heading.
 **Optional template fields:** `openQuestions`, `nextSteps` — appended if surfaced during convergence.
 **Confirmation pattern:** `minimal` (which artifact + dirty-tree handling)
 
@@ -167,10 +167,13 @@ Skill name resolved per workflow mode + PR status (read from `state.md` frontmat
 | lite        | none / closed                | `oat-project-lite`        |
 | import      | none / closed                | `oat-project-import-plan` |
 | brief       | none / closed                | `oat-project-brief`       |
+| goal        | none / closed                | `oat-project-goal`        |
 | any mode    | open (`oat_pr_status: open`) | `oat-project-revise`      |
 
 For brief, `oat-project-brief` is the target while the brief is still in planning (`oat_phase: plan`) and `oat-project-implement` once implementation has started; the handoff prompt asks for new or amended phases instead of tasks.
 
+For goal, `oat-project-goal` is the target (an amendment during authoring or at re-alignment), or `oat-project-implement` for an update inside the active milestone's approved Outcomes and Approach. With an open PR, the goal handoff to `oat-project-revise` names the target milestone and delivery (`<mNN>/<dNN>`, from the `oat_deliveries` entry whose member URL is `oat_pr_url`), because revise requires an explicit target in goal mode.
+
 After printing the prompt, the skill stops. The user runs the plan-authoring skill at their own pace. The brainstorming skill never auto-chains into plan authoring — the deliberate transition is the point.
 
 **If user wants to keep brainstorming after this is offered:** return to flow with destination = fold-back. Skill probes for richer chosen direction or key decisions, since these become the appended section and read poorly when shallow. Re-run preflight `git status` when convergence resumes — the working tree may have changed mid-conversation.

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

@@ -5,7 +5,7 @@ disable-model-invocation: true
 user-invocable: false
 allowed-tools: Read
 metadata:
-  version: 1.2.12
+  version: 1.2.13
 ---
 
 # Dispatching OAT Subagents

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

@@ -283,6 +283,12 @@ so the loaded root is that home's `.agents`: expect `tier: loaded`,
 `canonicalPath: <user>/agents/<role>.md`. Another layout yields different but
 equally valid tier labels.
 
+Under a capped managed policy the reviewer targets the policy's cap cell
+(here `high`, so the Opus 5.5 high variant). In a repository whose policy caps at another tier the
+selected variant differs, and `dispatch record` rejects a `payload.variant`
+that is not the resolver's. Take `payload.variant` from the live resolution's
+`providers.claude.dispatchArgs.variant`, never from this example.
+
 ## Recon Wave
 
 ```yaml

package/assets/skills/oat-docs/SKILL.md

@@ -6,7 +6,7 @@ disable-model-invocation: false
 user-invocable: true
 allowed-tools: Read, Glob, Grep, AskUserQuestion
 metadata:
-  version: 1.0.5
+  version: 1.0.6
 ---
 
 # OAT Docs
@@ -146,7 +146,7 @@ Based on the docs, here's how OAT project workflows work: [answer]
 You can read more in `workflows/projects/lifecycle.md`.
 
 Would you like me to:
-- Start a new project? (I'd invoke oat-project-lite for single-sitting work, oat-project-brief for one delivery planned as a Project Brief, or oat-project-quick-start for a larger quick workflow)
+- Start a new project? (I'd invoke oat-project-lite for single-sitting work, oat-project-brief for one delivery planned as a Project Brief, oat-project-goal for an outcome delivered over several milestones, or oat-project-quick-start for a larger quick workflow)
 - Check your current project status? (I'd read your active project's state.md)
 ```
 
@@ -174,9 +174,13 @@ Brief mode is a fourth option for one delivery whose design you can agree in
 conversation:
    oat-project-brief <project-name> "project description"
 
+Goal mode is a fifth option for an outcome delivered over several milestones:
+   oat-project-goal <project-name> "project description"
+
 Lite combines the interview and requirements contract in one plan for a
 single sitting. Brief writes one reviewed Project Brief whose phases carry
-intent and exit evidence instead of tasks. Quick mode goes straight from
+intent and exit evidence instead of tasks; goal groups those phases into
+milestones that are delivered and re-aligned in turn. Quick mode goes straight from
 discovery to plan. Spec-driven mode adds formal spec and design phases. If you invoke quick mode with only a
 project name, it should ask you for the missing project description
 before discovery starts.

package/assets/skills/oat-pjm-review-backlog/SKILL.md

@@ -6,7 +6,7 @@ disable-model-invocation: true
 allowed-tools: Read, Write, Glob, Grep, Bash(git:*), AskUserQuestion, Task
 user-invocable: true
 metadata:
-  version: 1.6.4
+  version: 1.6.5
 ---
 
 # Review Backlog
@@ -256,7 +256,7 @@ This step mirrors the **Project Kickoff Handoffs** section of the pjm instructio
 **For each item in the agreed kickoff stack**, write or refresh `.oat/repo/pjm/handoffs/<BL-id>.md` with:
 
 - the backlog item reference — its ID **and** human-readable title **and** path (never a bare ID);
-- the recommended project mode (`oat-project-lite` for single-sitting work, `oat-project-brief` for one delivery planned as a Project Brief, `oat-project-quick-start` for quick work, or `oat-project-new` for spec-driven work), including which artifacts (spec/design/plan) to pre-populate from existing research when it exists;
+- the recommended project mode (`oat-project-lite` for single-sitting work, `oat-project-brief` for one delivery planned as a Project Brief, `oat-project-goal` for an outcome delivered over several milestones, `oat-project-quick-start` for quick work, or `oat-project-new` for spec-driven work), including which artifacts (spec/design/plan) to pre-populate from existing research when it exists;
 - authoritative input pointers (research directories, decision records, code paths);
 - repo conventions and verification gates the item file does not restate;
 - a close-out section requiring (a) the **Backlog Lifecycle** — `oat backlog archive <id> --summary "outcome" --json` — in the same PR that ships the item, and (b) filesystem deletion of its owned handoff. Consume the complete returned `affectedPaths`, append the tracked handoff deletion, format existing text with the repository command, and commit the exact list via `oat internal commit-paths` with a unique retained identity and enabled hooks; stop if unavailable or blocked/failed. Include both old/new item names, ledger, index and rewritten references; preserve unrelated staged/unstaged work.

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

@@ -6,7 +6,7 @@ disable-model-invocation: true
 user-invocable: true
 allowed-tools: Read, Write, Bash, Glob, Grep, AskUserQuestion, Task
 metadata:
-  version: 1.0.20
+  version: 1.0.21
 ---
 
 # Autonomous OAT Project
@@ -227,6 +227,7 @@ Select the earliest incomplete lifecycle owner:
 | No project yet                                            | Continue to Step 2, then invoke the selected creation skill |
 | Lite plan incomplete                                      | `oat-project-lite`                                          |
 | Brief not yet reviewed and approved                       | `oat-project-brief`                                         |
+| Existing goal project (`oat_workflow_mode: goal`)         | Stop at a product-judgment boundary: goal is not autonomous |
 | Quick-mode discovery, optional design, or plan incomplete | `oat-project-quick-start`                                   |
 | Spec-driven discovery incomplete                          | `oat-project-discover`                                      |
 | Spec-driven design/spec incomplete                        | `oat-project-design`                                        |
@@ -303,8 +304,13 @@ For a new goal, choose mode as a rigor selector:
   sequential implementation phase.
 - **Brief:** use when the goal is one delivery whose outcome and design can be
   settled from evidence and recorded in one reviewed Project Brief, with
-  phases of intent and exit evidence instead of a pre-approved task plan. Goal
-  mode is excluded until it is registered.
+  phases of intent and exit evidence instead of a pre-approved task plan.
+- **Goal is excluded.** Never select `goal` for a new project, even when the
+  outcome needs several deliveries: each milestone's approval, re-alignment
+  and the terminal declaration need the user (`GOAL-11` through `GOAL-13` in
+  the autonomy contract), so an autonomous run cannot carry a goal end to end.
+  Choose brief for the first delivery, or stop at a product-judgment boundary
+  when one delivery cannot honestly represent the outcome.
 
 Base the choice on uncertainty, integration risk, architecture decisions,
 reversibility, and review needs—not task count. Record the chosen mode and