@open-agent-toolkit/cli 0.3.18 → 0.3.20

package/assets/skills/oat-project-implement/references/docs/gate-approval-record.md

@@ -58,6 +58,19 @@ replaces the record.
   record is current.
 - **`oat_quick_start_gate`** (`oat-project-quick-start`, Gate Execution) carries
   exactly the core.
+- **`oat_brief_gate`** (`oat-project-brief`, Gate Execution) carries exactly the
+  core, written and read under the same rules as `oat_quick_start_gate`. It is
+  absent when no gate is configured, and nothing routes on it: it is provenance
+  only.
+- **`oat_milestone_gates[mNN].plan` and `.exit`** (goal mode;
+  `oat-project-goal` writes `plan` after each milestone's approval, and
+  `oat-project-implement`'s milestone closeout writes `exit`) carry the core
+  plus `resolution` (`configured`, `no_gate`, or `project_disabled`), a
+  `subject` binding (`plan` or `code` and the milestone's ordered phase set),
+  and derived `freshness` with `freshness_reason`. `reviewed_head` is `null`
+  for `no_gate` and `project_disabled`, and `no_gate` is written rather than
+  omitted because routing reads these carriers. `oat-project-brief`'s
+  `references/brief-contract.md` section 12.4 is their contract.
 
 ## Reading a quick-start record
 

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

@@ -15,6 +15,139 @@ optional bounded child for beneficial recon, isolated fanout, or specialist
 work under the shared dispatch contract. The phase implementer remains
 responsible for file boundaries, verification, and task commits.
 
+#### Brief-Mode Phase Execution
+
+When `oat_workflow_mode` is `brief` or `goal`, each phase is one phase-unit
+with Intent and Exit evidence instead of planned tasks; goal also scopes every
+run to a milestone, recovery or terminal phase set (`plan-and-resume.md`, Goal
+Projects). Every rule in this route still
+applies except where this subsection replaces it, and
+`oat-project-brief/references/brief-contract.md` (sections 3, 6, 7, and 10) is
+authoritative where the two differ. The subsection is inert for every other
+workflow mode.
+
+**Requirement source.** The phase's `**Intent:**` and `**Exit evidence:**`
+lines plus the brief's Outcomes, Constraints and Out of Scope, and Decisions
+sections. There is no planned task list, file list, or commit message to
+extract. A provisional phase is never dispatched; `plan-and-resume.md` Step 2.2
+makes it concrete first.
+
+**Execution precedence.** Select exactly one execution shape per phase, in this
+order, and record it in the phase-start record:
+
+1. **Declared parallel group.** A ready group of concrete phases in
+   `oat_plan_parallel_groups` runs through Parallel Group Execution below: one
+   worktree and one phase implementer per phase, merged back in document order.
+2. **Root fan-out.** For a phase outside any group, the root fans out bounded
+   slices when at least two slices pass the independence test. The root is
+   then the committing owner for that phase, and each worker is a nested
+   worker.
+3. **One phase implementer.** Otherwise resolve and dispatch one phase
+   implementer through the flow below.
+4. **Inline exception.** The root works inline only through an exception
+   written into the journal before editing that holds for the whole phase: no
+   new surface, no unresolved design, no consequential change, and one existing
+   proof command. File count alone is not a predicate. Reclassify, and leave the
+   inline shape, as soon as the scope grows past any of those conditions.
+
+**Independence test**, for phases and slices alike: no shared files, state,
+generated files, lockfiles, formatter or build output, fixtures, or services,
+and no sequential dependency. A parallel phase is also a coherent deliverable on
+its own. Slices that fail the test stay with one executor.
+
+There is exactly one committing owner per worktree: the root for a root fan-out
+or inline exception, the phase implementer for its phase or phase worktree.
+Nested workers return edits on owned paths and never commit.
+
+**Phase-start record.** Before phase work starts, capture
+`PHASE_ANCHOR_BASE=$(git rev-parse HEAD)` on a clean tree. The root writes these
+exact lines directly under the phase's `## Phase pNN:` heading in
+`implementation.md`, replacing `**Status:** pending`:
+
+```markdown
+**Status:** in_progress
+**Base:** {PHASE_ANCHOR_BASE as a full 40-character SHA}
+**Executor:** {root | phase-implementer:<request_id> | inline:<exception-ref>}
+```
+
+followed by prose naming the worktree, the committing owner, and the
+parallelism assessment: the precedence rung selected and why each higher rung
+did not apply. Commit it through Step 7a's scope-resolving bookkeeping branch
+with the message `chore(oat): start {pNN}`, then record `PHASE_BASE_HEAD` (the
+dispatch base the implementer verifies) after that commit. The phase-start
+commit sits inside `PHASE_ANCHOR_BASE..Head`, which is allowed. For a parallel
+group the root writes every member's start record, without `**Base:**`, in one
+`chore(oat): start {group}` commit, then captures `EXPECTED_HEAD` as the group's
+fork commit; each member's `**Base:**` is that fork commit, written at fan-in
+(see Parallel Group Execution). The Late-fix rule below forbids a later phase
+from taking a `**Base:**` while an earlier phase still expects a head-advancing
+fix.
+
+**Execution records.** Tasks are execution records, never a plan. Whoever
+executes creates the record: the committing owner opens
+`### Task pNN-tNN: <name>` under the phase's journal section when the work
+starts, with `**Status:** in_progress`, `**Executor:**`, intent, files, proof
+command, and the live handle while in flight. Record IDs take the next free
+ordinal in the phase (`prevN-tNN` in a revision phase) and are never reused. The
+record's one implementation commit carries `(pNN-tNN)` in its message and
+excludes the journal. After it lands, the owner closes the record with
+`**Status:** completed` and `**Commit:** <full SHA>`, or with a terminal
+`failed`, `cancelled`, or `no-change` status and no fabricated commit, and
+commits the journal separately as `chore(oat): record {pNN-tNN}`. Lookahead is
+allowed: the owner may open several independent records before dispatching
+them together. A request for a maintained up-front task plan is an offer to
+promote the brief to quick, never lookahead. Records are coherent units tied to
+one commit, not one per command or edit, and they never change phase totals.
+
+**Phase head.** When the executor's work is done and phase-wide verification
+passes, the committing owner writes `**Head:** <full SHA>`, the candidate head,
+which is the last implementation or record commit of the phase, plus a short
+verification summary, and commits the journal as `chore(oat): record {pNN}
+head`. A phase without a `**Head:**` line never reaches review or the
+completion line.
+
+**Fresh reviewer on anchors.** Per-Phase Review dispatches a fresh reviewer for
+every phase: never the phase implementer, never a reviewer handle from an
+earlier phase. For a sequential phase, before dispatch verify that both anchors
+exist and that `**Base:**` is an ancestor of `**Head:**`; a failed check routes
+to `oat-project-reconcile` and is never narrowed. For a parallel-group member,
+step 3's check that the worktree head descends from `EXPECTED_HEAD` stands in
+for that pre-check, because the member has no journal anchors until fan-in. The
+per-phase Review Scope range is `Base..Head` for a sequential phase and
+`EXPECTED_HEAD..<worktree head from the phase report>` for a parallel-group
+member, whose `oat_review_base_sha` is `EXPECTED_HEAD`; the fan-in
+`**Base:**`/`**Head:**` written afterwards govern `pNN-pMM` and `final` scopes.
+In both cases the in-scope IDs are the phase's execution-record IDs, and the
+scope carries the artifact record fields `oat_review_requested_scope: pNN`,
+`oat_review_phase_ids: [pNN]`, `oat_review_base_sha`, and
+`oat_review_scope_source: anchors` for the reviewer to copy into its artifact.
+
+**Late-fix rule.** A review-fix commit may advance the phase's `**Head:**`, base
+unchanged, only while no later phase in document order has a `**Base:**`. Once
+a later phase has started, a correction becomes an appended revision phase
+`## Phase p-revN:` with its own anchors and `**Corrects:** pNN`, recorded in both
+`plan.md` and the journal; the corrected phase keeps its anchors. Under this
+route the next phase's start record is written only after the current phase's
+review and fix loop settles, so ordinary fix-mode commits advance the head.
+
+**Acceptance.** The root alone writes `**Status:** completed` under the phase
+heading, in the Step 7b (or later) bookkeeping commit that observes every
+review disposition settled and every selected phase gate passed. That line is
+what makes the phase-unit accepted. Step 7a keeps `**Status:** in_progress`.
+
+**Journal ownership in parallel worktrees.** A phase implementer in a parallel
+group writes its execution records into its own phase section of the
+worktree's journal and lists them in its report, but writes no anchors. At
+fan-in the root reconciles those phase-local records into `implementation.md`:
+it keeps each phase's own section from its worktree when resolving a journal
+merge, writes every member's `**Base:**` as the group's fork commit and its
+`**Head:**` as that phase's integration head on the project branch (its merge
+commit, or its last cherry-picked commit when step 7 integrates by
+cherry-pick), and lists integration and conflict-resolution commits to the
+reviewer as integration commits. The review-provide resolver checks only the
+shared fork base and that member heads advance in document order; it does not
+require a head to be a merge commit.
+
 #### Required Manual or Visual Proof Boundary
 
 Before committing a task that declares required manual or visual proof, the
@@ -69,7 +202,7 @@ Before each phase:
      spec: {PROJECT_PATH}/spec.md
      implementation: {PROJECT_PATH}/implementation.md
      discovery: {PROJECT_PATH}/discovery.md
-   workflow_mode: {spec-driven|quick|import|lite} # lite is always a single phase
+   workflow_mode: {spec-driven|quick|import|lite|brief|goal} # lite is always a single phase; brief and goal phases carry Intent and Exit evidence, not tasks
    active_provider: {codex|claude|cursor|other}
    phase_base_head: {PHASE_BASE_HEAD}
    worktree: {assigned checkout}
@@ -118,6 +251,12 @@ must not use route escalation, route-level advancement, model/provider
 replacement, or `oat_orchestration_retry_limit`. It remains pinned to the exact
 accepted implementation target.
 
+In brief modes the Phase Scope keeps every field above. `design`, `spec`, and
+`discovery` are absent by design (set them to `null`), `commit_convention`
+names the `(pNN-tNN)` record convention, and the scope adds the phase-start
+record's `parallelism_assessment` and `committing_owner`, plus
+`anchor_base: {PHASE_ANCHOR_BASE}` for a sequential phase.
+
 Tier 2 inline execution is allowed only under the existing verified-equivalent
 controls or documented inherit/default exception. Inline mode executes the
 phase-implementer contract directly; it does not reintroduce mandatory
@@ -720,6 +859,10 @@ commit range, task IDs and boundaries, artifacts, verification evidence,
 configured axes, selection reason, and candidates. Require a timestamped review
 artifact under the project's `reviews/` directory.
 
+In brief modes the phase commit range, the in-scope execution-record IDs, and
+the artifact record fields come from the phase anchors as Brief-Mode Phase
+Execution describes; validate the anchors before launch.
+
 The Review Scope names review-outcome bookkeeping as out of scope: this
 review's `## Reviews` row and its disposition, the Orchestration Run entry for
 this review's outcome, the deferred phase-outcome and review-orchestration
@@ -907,6 +1050,15 @@ Head`, `Invocation`, and `Gate Target`) to the header and separator, then pad
 
 For a multi-phase schedule entry:
 
+In brief modes, step 6 merges passing phases in document order, and step 10's
+bookkeeping writes every member's anchors and phase-local records as the
+Brief-Mode Phase Execution subsection describes. Step 5's per-phase review
+still runs before the merge: For a parallel-group member the per-phase Review Scope range is
+`EXPECTED_HEAD..<worktree head from the phase report>` with
+`oat_review_base_sha: EXPECTED_HEAD` and `oat_review_scope_source: anchors`;
+the fan-in `**Base:**`/`**Head:**` written afterwards govern `pNN-pMM` and
+`final` scopes.
+
 1. Capture `EXPECTED_HEAD=$(git rev-parse HEAD)`.
 2. Bootstrap one worktree per phase through `oat-worktree-bootstrap-auto` with
    explicit base `EXPECTED_HEAD`. Never substitute host-native worktree
@@ -957,6 +1109,12 @@ reviewer. Write the phase's task ledger:
 - remove legacy `oat_execution_mode: subagent-driven`; and
 - preserve any configured retry override.
 
+In brief modes the task ledger is the phase's journal section: validate that
+the execution records and `**Head:**` the executor committed are present,
+update the phase's Progress Overview row, keep `**Status:** in_progress`, and
+point both resume pointers at the phase ID. A missing `**Head:**` stops before
+review.
+
 The task rows, resume pointer, and recovery settlement do not depend on the
 review outcome, which is why they can move ahead of the review; the recovery
 settlement is validated from the phase report, not from the review. A
@@ -1028,6 +1186,13 @@ commit observes that last condition: this Step 7b commit when nothing is
 queued and no gate is selected, otherwise the commit that records the final
 review-fix task or the passing gate.
 
+In brief modes the row is the phase's journal section and `complete` is the
+exact line `**Status:** completed` under its heading, written only by the root
+under that same rule; the brief's `pNN` code row in `## Reviews` records the
+review event, and the phase summary prose records the reviewer's disposition
+and gate results. A review-fix commit that advances the phase head updates
+`**Head:**` under the Late-fix rule.
+
 Bookkeeping is mandatory:
 
 ```bash
@@ -1052,6 +1217,13 @@ when it exists; logging can be disabled.
 At every phase boundary, verify `implementation.md`, task pointers, phase
 summary, and design/plan deviations. `oat_plan_hill_phases` lists phases after
 which execution pauses; an empty list means every phase.
+In brief modes an empty list means none (`plan-and-resume.md` Step 2.5), and a
+phase boundary is reached only when the phase-unit is accepted.
+In goal mode the last accepted phase of a milestone or recovery scope leads to
+Goal Milestone Closeout (`completion-and-closeout.md`), not to the final
+review: the milestone's integrated review is requested with its explicit
+`code mNN: <ordered phase ids>` scope after the exit carrier is allowed and
+fresh, and `code final` belongs to terminal closeout only.
 
 Before a configured non-final HiLL pause, run auto-review when enabled. Scope
 starts after the last passed whole-phase review and ends at the current phase.

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

@@ -5,6 +5,51 @@ This reference preserves the route-specific implementation contract. Load it onl
 Step 0 of the entry skill has already pulled and materialized any discoverable
 synced project before this route validates or reads its artifacts.
 
+### Brief-Family Projects
+
+When `state.md` records `oat_workflow_mode: brief`, `plan.md` is a Project
+Brief. Its `## Phase pNN:` blocks carry `**Intent:**`, `**Exit evidence:**`,
+and `**Provisional:**` lines instead of tasks, and each phase is one
+**phase-unit**, accepted only by the exact `**Status:** completed` line under
+its heading in `implementation.md`. Read
+`oat-project-brief/references/brief-contract.md` from the same installed skills
+root as this skill once, before Step 1. It owns the phase grammar, journal
+markers, execution records, pointer interpretation, and anchor rules, and it
+wins where this route restates them. The brief branches in this route, in
+`phase-execution.md`, and in `completion-and-closeout.md` are inert for every
+other workflow mode.
+
+The entry skill's rule against changing plan structure does not cover the
+logged brief edits Step 2.2 allows (adding, splitting, reordering, or making
+phases concrete within the approved outcomes); those are part of brief
+execution, not scope expansion.
+
+### Goal Projects
+
+When `state.md` records `oat_workflow_mode: goal`, every brief-family rule
+above applies, and `oat-project-brief/references/brief-contract.md` section 12
+wins where this route restates it. Goal adds a scope to each run:
+
+- **Active scope.** Read the router's context (`oat project status --json`,
+  `recommendation.context`): `scope mNN: <ordered phase ids>` is the active
+  milestone's ordered phase set from the shared Milestones reader;
+  `scope mNN/dNN: …` or a pending `oat_goal_recovery` record is a recovery
+  scope (its `phase_ids`); `scope terminal: …` is the terminal execution scope
+  after a declaration, which excludes audited `deferred` and `retired`
+  phases; `closeout mNN: …` or `closeout mNN/dNN: …` runs the scoped milestone
+  closeout in `completion-and-closeout.md` (Goal Milestone Closeout) without
+  dispatching a phase. Never widen a scope to phases of another milestone.
+- **Ownership.** Implement never writes `oat_milestone`, never activates a
+  milestone, never registers a delivery, and never writes `declared_met`: it
+  consumes the declaration. It writes only the milestone status and recovery
+  stage transitions that Goal Milestone Closeout names.
+- **Recovery isolation.** Executing a recovery scope for an older delivery
+  leaves `oat_milestone`, `oat_milestone_status`, `oat_current_task_id`, and
+  `oat_current_task` unchanged; progress is recorded in the journal and the
+  recovery record.
+- **Invalid membership.** A `Active milestone membership invalid` reason stops
+  before dispatch and routes to `oat-project-goal`.
+
 ### Step 1: Check Plan Complete
 
 ```bash
@@ -59,6 +104,15 @@ If `{PROJECT_PATH}/implementation.md` already contains orchestration run entries
 
 6. Once resume target is identified, continue from that phase with the normal per-phase flow.
 
+**Brief modes:** before any redispatch, reconcile every open execution record
+(a `### Task pNN-tNN:` record in the journal without a terminal status) against
+`git log` commits carrying `(pNN-tNN)` and against live handles, as brief
+contract section 7 requires. A record whose implementation commit landed closes
+with that SHA; a record whose handle is still live is continued through that
+handle and never redispatched; a record with neither stays open for its phase's
+next executor. Records never change phase totals, so this reconciliation never
+writes a phase's `**Status:** completed`.
+
 **On first-ever invocation** (no prior run entries), skip resumption detection and proceed to Step 2.
 
 ### Step 2: Read Plan Document
@@ -70,6 +124,15 @@ Read `"$PROJECT_PATH/plan.md"` completely to understand:
 - Verification commands
 - Commit messages
 
+**Brief modes:** read the whole brief: Goal, Outcomes, Approach, Constraints and
+Out of Scope, Decisions, Known Unknowns, Delivery endpoint and authority, the
+phase blocks, Parallelism, and Reviews. There are no planned tasks, file lists,
+or commit messages to extract. Each phase's Intent and Exit evidence are its
+requirement and proof source, and execution records are opened only when work
+starts (`phase-execution.md`, Brief-Mode Phase Execution). `oat project
+validate-plan` in Step 2.1 applies the brief profile from the recorded workflow
+mode.
+
 ### Step 2.1: Validate Parallelism Metadata
 
 Invoke the CLI validator to check plan.md parallelism metadata:
@@ -108,14 +171,31 @@ Example:
 - `oat_plan_parallel_groups: [["p02", "p03"], ["p04", "p05"]]`
 - Schedule: `[p01]` → `[p02, p03]` (group) → `[p04, p05]` (group)
 
+**Brief modes** build the schedule from the brief's phase-units in document
+order, which governs execution even when numeric order differs. Extracted units
+are excluded. A provisional phase stays in the schedule but is never
+dispatched: before its schedule entry starts, the root makes it concrete in
+`plan.md` (writes its Intent and Exit evidence and sets `**Provisional:** no`)
+within the approved outcomes, constraints, authority, and evidence, logs the
+change (in `project-log.md` when the project log is enabled, otherwise in the
+journal), re-runs Step 2.1, and commits the brief before dispatch. A change that
+alters an Outcome, a Constraint, the authority, the endpoint, a Decision, or the
+agreed Approach stops for the focused realignment in brief contract section 4.
+Within those bounds the root may also add, split, or reorder phases and declare
+parallel groups whenever their phases become concrete, with the same logging and
+re-validation, and adds one `code` row per new phase to the brief's
+`## Reviews` table.
+
 ### Step 2.5: Confirm Plan HiLL Checkpoints
 
 #### Lite checkpoint bypass
 
 Resolve `oat_workflow_mode` from project state before any generic checkpoint
 field read. When `oat_workflow_mode` is `lite`, resolve checkpoint state as
-`none` without reading or interpreting `oat_plan_hill_phases`; for other modes,
-an empty list means every phase and therefore cannot represent lite's policy.
+`none` without reading or interpreting `oat_plan_hill_phases`; for the task modes
+(spec-driven, quick, import) an empty list means every phase and therefore
+cannot represent lite's policy; brief modes read it as none (Brief checkpoint
+resolution below).
 Write this plan frontmatter value:
 
 ```yaml
@@ -127,7 +207,8 @@ auto-review preference prompt in both interactive and autonomous runs. Continue
 directly to Step 2.6. The standard root-owned per-phase review and final review
 remain required; only HiLL approval pauses are absent.
 
-For every other workflow mode, read `oat_plan_hill_phases` from
+For every workflow mode other than lite and the brief modes (see Brief
+checkpoint resolution below), read `oat_plan_hill_phases` from
 `"$PROJECT_PATH/plan.md"` frontmatter when present and validate it.
 
 - **Valid format:** JSON-like array of phase IDs (e.g., `["p01","p03"]`)
@@ -139,6 +220,22 @@ Determine whether this is a first implementation run:
 - If `"$PROJECT_PATH/implementation.md"` does not exist, treat as first run.
 - If it exists but still has template placeholders and no completed task evidence, treat as first run.
 
+#### Brief checkpoint resolution
+
+Brief modes read `oat_plan_hill_phases` with the brief meaning, not the generic
+one: `[]` and an absent field both mean **none**, and an explicit phase array
+means exactly those phases, an opt-in the user recorded. Never reinterpret a
+brief's `[]` as every phase. With none, write
+`oat_auto_review_at_hill_checkpoints: false # brief: no checkpoints` when that
+key is absent, skip the workflow preference check, the first-run checkpoint
+question, Touchpoint A, and the autonomous checkpoint resolution below in both
+interactive and autonomous runs, and continue directly to Step 2.6. With an
+explicit array, validate it with the normal format rules and keep it as the
+recorded value without re-asking; resolve Touchpoint A below (under
+`OAT_AUTONOMOUS=1`, the autonomous checkpoint resolution, which preserves the
+array) and continue to Step 2.6. The per-phase reviews and the final review run
+either way.
+
 #### Autonomous checkpoint resolution
 
 If `OAT_AUTONOMOUS=1`, resolve checkpoint state before the workflow preference
@@ -313,6 +410,19 @@ cat "$PROJECT_PATH/implementation.md" 2>/dev/null | head -20
   - If `oat_current_task_id` points at a task already marked `completed` in the body, advance to the **next incomplete** task (first `pending` / `in_progress` / `blocked` entry).
   - If all tasks are completed, skip ahead to finalization (Step 11+).
 - **Always resume** from the resolved task. Print `Resuming from {task_id}.` Do not prompt.
+- **Brief modes:** `oat_current_task_id` may hold a phase ID or an execution
+  record ID (brief contract section 8). Resolve a record ID to its phase and a
+  phase ID to itself; `null`, an unknown ID, or an accepted or extracted unit
+  resolves to the first incomplete phase-unit in document order within the
+  active scope, which is every phase in brief and the Goal Projects scope in
+  goal. Phase-units come from the brief's
+  `## Phase` headings, never from task headings, and a provisional phase is
+  incomplete. Print `Resuming from {phase_id}.` and apply the Step 2.2
+  provisional rule before dispatching it. When every phase-unit in the active
+  scope is accepted, skip ahead to finalization (Step 11+). Finalization starts
+  only then, never because every execution record is closed. The stale-state
+  reconciliation below resolves the next phase-unit the same way instead of a
+  next task.
 - **Fresh start is an explicit override only.** If the user invoked the skill with `fresh=true` (argument), warn `Starting fresh — this will overwrite implementation.md. Any draft logs will be lost.` and proceed with fresh initialization. Do not offer fresh start interactively; it is a rare edge case reserved for corrupt state or deliberate plan rewrites.
 
 **Stale-state reconciliation (approval required):**
@@ -332,6 +442,9 @@ cat "$PROJECT_PATH/implementation.md" 2>/dev/null | head -20
 
 - Initialize from template (Step 4)
 
+In brief modes `oat-project-brief` already initialized the journal; Step 4 runs
+only when it is missing.
+
 **Important:** Never overwrite an existing `implementation.md` without explicit user confirmation (and warn that draft logs will be lost).
 
 ### Step 4: Initialize Implementation Document
@@ -357,3 +470,11 @@ Initialize project state so other skills (e.g., `oat-project-progress`) reflect
   - `oat_phase_status: in_progress`
   - `oat_current_task: p01-t01`
   - `oat_project_state_updated: "{ISO 8601 UTC timestamp}"`
+
+**Brief modes:** resolve the journal with
+`oat template resolve implementation-brief --output "$PROJECT_PATH/implementation.md"`
+instead, write one Progress Overview row and one `## Phase pNN: <name>` section
+holding only `**Status:** pending` per brief phase, and set both resume pointers
+(`oat_current_task_id` here and `oat_current_task` in `state.md`) to the first
+incomplete phase ID, such as `p01`, rather than a task ID. Anchors and execution
+records are written only when work starts.

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

@@ -7,7 +7,7 @@ disable-model-invocation: true
 user-invocable: true
 allowed-tools: Read, Write, Bash, Glob, Grep, AskUserQuestion
 metadata:
-  version: 1.4.20
+  version: 1.4.21
 ---
 
 # Import External Plan
@@ -274,6 +274,10 @@ commands or manual checks. Preserve the external source at
 all `oat_import_*` fields; accepting lite changes execution mode, not import
 provenance.
 
+Import never converts a plan to brief mode: an imported plan already carries
+tasks, while a brief carries phases without tasks. To author a brief, start
+`oat-project-brief` instead.
+
 ### Step 4: Update Plan Metadata
 
 Set frontmatter in `"$PROJECT_PATH/plan.md"`:

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

@@ -7,7 +7,7 @@ disable-model-invocation: true
 user-invocable: true
 allowed-tools: Read, Write, Bash, Glob, Grep, AskUserQuestion
 metadata:
-  version: 1.1.8
+  version: 1.1.10
 ---
 
 # Lite Project
@@ -67,6 +67,9 @@ the row. Never persist either autonomy environment signal.
 
 - If the work cannot fit one sitting, promote the authored plan to quick mode.
 - If a design decision is not safely resolvable, promote rather than invent it.
+- Lite never converts to brief. Work that needs several phases with a design
+  agreed in conversation belongs in `oat-project-brief`; lite promotion still
+  targets quick.
 - If implementation code is about to change, stop and hand off to
   `oat-project-implement`.