ultra-builder-pro-cli 0.10.0 → 0.12.1

package/skills/ultra-doctor/SKILL.md

@@ -1,98 +1,71 @@
 ---
 name: ultra-doctor
-description: "Inspect Ultra state, projection, session, incident, and active-change health; optionally run explicit backup-first mechanical recovery."
-user-invocable: true
-runtime: all
-mcp_tools_required:
-  - system.doctor
-cli_fallback: "system doctor"
+description: Diagnose Ultra state, projection, session, incident, change-artifact, and installed-plugin health with bounded recovery. Use when Ultra state appears missing, projections disagree, hooks fail, or MCP operations report degraded health.
 ---
 
-# ultra-doctor — Runtime Diagnostics and Recovery
+# Diagnose and recover the Ultra runtime
 
-Use this workflow when Ultra state appears empty, projections disagree with
-`state.db`, a hook reports a missing adapter, sessions are orphaned, a change
-artifact is missing, or MCP operations return degraded projection metadata.
+Default to read-only diagnosis. Repair only after the user explicitly authorizes it.
 
-## Default is read-only
+## Project-state diagnosis
 
-Call `system.doctor` with `{ "repair": false }` unless the user explicitly
-requests repair. Read-only diagnosis reports:
+Call `system.doctor` with `{ "repair": false }` and inspect:
 
 - SQLite integrity and required tables;
 - open structured incidents;
-- projection queue failures and event/projection cursor lag;
+- event and projection cursor lag;
+- failed or interrupted projection jobs;
 - orphan sessions;
 - missing active-change artifact roots;
-- the external ownership boundary for Memory and code graph.
+- missing, incomplete, or stale project baseline readiness and specification digests;
+- the boundary to separately installed memory and code-graph providers.
 
-Do not infer health from `tasks.json`. Do not mutate provider state, delete
-artifacts, rebuild a graph, or collect memory during diagnosis.
+Do not infer health from generated task JSON. Do not mutate external provider state,
+delete artifacts, or collect memory during diagnosis.
 
-## Interpret the report
+## Interpret failures
 
-| Check | Meaning | Next action |
-|---|---|---|
-| `state_db` fail | schema/integrity problem | stop ordinary workflow; preserve DB evidence |
-| `incidents` fail | a structured runtime failure remains open | report code, source, retryability, and evidence |
-| `projections` fail | state commit is ahead of generated views or a projector failed | explicit repair is appropriate when authorized |
-| `sessions` fail | an orphan execution lease exists | repair may mark/reconcile it; never kill unrelated processes blindly |
-| `change_artifacts` fail | DB points to a missing active packet | recover from version control/backup or recreate deliberately |
-| `external_providers` pass | ownership is correctly external | provider availability must be checked with its own plugin/tool |
+- State integrity failure blocks ordinary workflows and requires preserving database
+  evidence before recovery.
+- An open incident requires its code, source, retryability, and evidence.
+- Projection lag may be mechanically repairable when authority is healthy.
+- An orphan session may be reconciled; never kill unrelated processes blindly.
+- A missing change artifact requires version-control, backup, or deliberate recreation
+  evidence rather than silent regeneration.
+- Missing or incomplete baseline evidence routes to `ultra-init`. Doctor repair does
+  not approve a baseline, accept known-red verification, or invent adoption evidence.
+  Baseline readiness is an advisory workflow check, not state-database corruption and
+  not a reason for doctor repair.
 
-## Explicit repair mode
+## Explicit repair
 
-Only after the user asks for repair, call `system.doctor` with
-`{ "repair": true }`, or use the fallback:
+After authorization, call `system.doctor` with `{ "repair": true }` or use the
+installed `ultra-tools system doctor --repair` fallback. The runtime must create a
+timestamped state database backup before any mechanical repair.
 
-```bash
-ultra-tools system doctor --repair
-```
+Repair is limited to documented recovery operations such as reconciling orphan
+sessions, consuming staleness events, requeueing interrupted or failed projections,
+and regenerating projections from authoritative state. If backup fails, stop. Always
+inspect the post-repair report; a completed repair action does not imply healthy state.
 
-The runtime must create `.ultra/backups/state-<timestamp>.db` before any
-mechanical repair. Repair is bounded to:
+## Installed-plugin failures
 
-- boot recovery for orphan sessions;
-- durable consumption of spec-staleness events;
-- requeueing projection jobs left `running` beyond the interruption cutoff;
-- requeueing failed projection jobs;
-- regenerating projections from authoritative state.
+When a hook points to a missing installed file:
 
-If backup fails, repair must stop with `BACKUP_FAILED`. A repair result is not
-automatically healthy; inspect the returned post-repair report and keep any
-remaining incident unresolved.
+1. Capture the hook manifest path and missing target.
+2. Run the installer doctor for the actual host and install scope.
+3. Preserve provenance, asset-hash, and host-contract findings.
+4. Reinstall through the host adapter rather than patching a cache directory.
+5. Rerun installer doctor, `system.doctor`, and a host hook smoke test.
 
-## Hook/path failures
-
-For an installed hook that points to a missing cached file:
-
-1. capture the exact hook config path and missing target;
-2. run the separate read-only installer boundary check:
-   `npx ultra-builder-pro-cli --<runtime> --local --doctor --json` (or use
-   `--global` when that is the actual install scope);
-3. preserve its provenance, asset-hash, and host-contract findings;
-4. reinstall or regenerate the host-native plugin through the adapter;
-5. rerun both installer doctor and `system.doctor`, then a host hook smoke test.
-
-`system.doctor` diagnoses project `.ultra/state.db` and workflow recovery.
-Installer `ubp --doctor` diagnoses the installed plugin files and host wiring.
-Neither report substitutes for the other.
-
-Do not bypass a broken hook by changing application implementation, and do not
-treat a hook failure as project-code evidence.
+Project doctor covers `.ultra/state.db`; installer doctor covers packaged files and
+host wiring. Neither substitutes for the other.
 
 ## Output
 
-Lead with `healthy` or `degraded`, list only failing checks, and include:
-
-- incident ids/codes and sources;
-- event vs projected cursor;
-- whether repair ran;
-- backup path when repair ran;
-- unresolved actions and their owner (`Ultra`, host plugin, or external provider).
-
-## What this skill does not do
+Lead with `healthy` or `degraded`. List failing authority checks separately from
+baseline warnings, incident identifiers, cursor lag, whether repair ran, the backup
+path, and each unresolved action with its owner.
 
-- It does not fix project code or semantic specification conflicts.
-- It does not delete state, force-reset git, or close live healthy sessions.
-- It does not install, query, refresh, or repair external Memory/graph providers.
+Do not fix application code, delete state, reset Git, close healthy sessions, or
+install and repair external providers through this workflow.

package/skills/ultra-init/SKILL.md

@@ -1,151 +1,66 @@
 ---
 name: ultra-init
-description: "Initialize Ultra Builder Pro project: detect context, confirm with user, scaffold .ultra/ via task.init_project, set up git."
-user-invocable: true
-runtime: all
-mcp_tools_required:
-  - task.init_project
-cli_fallback: "task init-project"
+description: Initialize Ultra Builder Pro or resume greenfield and brownfield baseline adoption. Use when a repository lacks Ultra state or its project baseline is missing, draft, adopting, or blocked.
 ---
 
-# ultra-init — Phase 3.1
-
-把当前工作目录（或 `--target-dir`）初始化为一个 Ultra Builder Pro 项目：拉起
-`.ultra/` 骨架、初始化权威 `state.db`、建立持续变更目录、写入 `tasks.json`
-初始元数据，并按需配置 git。
-
-真实的目录搭建 + 模板拷贝 + tasks.json 注入统一由 **MCP tool `task.init_project`** 完成；
-MCP 不可达时回退 `ultra-tools task init-project`。
-
-## 设计要点（对比 pre-Phase-3 行为）
-
-- **无 Claude 独占依赖**：`task.init_project` + `ultra-tools init-project` 两条路径
-  都不调 Claude 原生工具，Claude Code、OpenCode、Codex 三个 runtime 都能走通。
-- **模板内置**：`.ultra/` 骨架来自仓内 `templates/.ultra/`；不再依赖 `~/.claude/.ultra-template/`。
-- **幂等**：二次 init 默认拒绝，`--overwrite` 才会备份旧 `.ultra/` 为
-  `.ultra.backup.<ts>` 后重建。
-
-## Workflow
-
-### Step 0: 状态检测（skill 调用方做）
-
-在调 `task.init_project` 之前，调用方（Claude / CLI / SDK）需要先判断：
-
-- `target_dir/.ultra/` 是否已存在 → 决定是否需要 `overwrite=true`
-- `target_dir/.git/` 是否已存在 → 影响 Step 3 的分支
-- 读 `package.json` / `Cargo.toml` / `pyproject.toml` / `go.mod` 推断项目类型和栈
-- 如果调用方是 Claude，可在此用 `TaskCreate` 跟踪 Step 0–4 的 session 内进度
-  （这是 runtime 的 session-local 跟踪，不走 MCP）
-
-### Step 1: 补全参数
-
-入参不足时补：
-
-| 字段 | 缺省 |
-|------|------|
-| `project_name` | 当前目录名（`path.basename(target_dir)`） |
-| `project_type` | Step 0 识别结果；多技术栈 → `fullstack` |
-| `stack` | Step 0 识别到的依赖（逗号分隔多值，如 `react,express,postgres`） |
-| `git_init` | `.git/` 不存在 → 询问用户 |
-
-### Step 1.5: 交互确认（仅当检测到模糊或重入）
-
-触发条件：
-- `target_dir/.ultra/` 已存在（重入）
-- 识别到多项目类型（Web + API）
-- 显式 `--interactive` 标志
-
-交互渠道：
-- **Claude runtime**：调 `AskUserQuestion`（原生）
-- **其他 runtime**：使用 Host 原生提问界面；若当前表面不支持交互，
-  要求用户通过显式命令行参数选择
-
-确认 4 个问题：
-1. 项目类型（可多选，`detected` 标签打在识别项）
-2. 技术栈（可多选）
-3. 已有 `.git/` → 保留 / 重置备份 / 不用 git
-4. 已有 `.ultra/` → 覆盖（备份） / 保留 / 取消
-
-### Step 2: 调 `task.init_project` 拉起骨架
-
-**MCP 主路径**：
-```jsonc
-// call: task.init_project
-{
-  "target_dir": "/abs/path/to/project",
-  "project_name": "my-app",
-  "project_type": "fullstack",
-  "stack": "react,express,postgres",
-  "overwrite": false
-}
-// response
-{
-  "created_path": "/abs/path/to/project/.ultra",
-  "status": "created",
-  "copied_files": [
-    "specs/discovery.md", "specs/product.md", "specs/architecture.md",
-    "tasks/tasks.json", "tasks/contexts/TEMPLATE.md",
-    "changes/active/.gitkeep", "changes/archive/.gitkeep",
-    "docs/research/README.md",
-    "test-report.json", "delivery-report.json"
-  ],
-  "state_db_path": "/abs/path/to/project/.ultra/state.db"
-}
-```
-
-**CLI 回退路径**（`UBP_MCP=off` 或 MCP 调用返回网络错）：
-```bash
-ultra-tools task init-project \
-  --target-dir "$TARGET" \
-  --project-name "$NAME" \
-  --project-type "$TYPE" \
-  --stack "$STACK" \
-  $([ "$OVERWRITE" = "1" ] && echo --overwrite)
-```
-CLI 最后一行是 `{ "ok": true, "data": { ... } }`（见 spec/cli-protocol.md §2）。
-
-**错误处理**：
-- `ULTRA_DIR_EXISTS` → Step 1.5 重新询问是否 overwrite
-- `TEMPLATE_MISSING` → 致命；提示检查 `templates/.ultra/` 是否被 gitignore 吞了
-- `TARGET_NOT_DIR` / `VALIDATION_ERROR` → 返回调用方，修参数
-- `IO_ERROR` → retriable=true；最多重试 2 次
-
-### Step 3: Git 集成
-
-根据 Step 1.5 结果：
-
-- **初始化新仓**：`git init` + 写 `.gitignore`（排除 `.ultra/backups/`、`node_modules/`、
-  敏感文件等项目通用规则）+ 写基础 `README.md`（若不存在）。
-- **保留现有 `.git/`**：仅追加 `.gitignore` 里的 `.ultra/backups/` 一行（若缺失）。
-- **不用 git**：跳过。
-
-提示建议第一个 commit：`git add . && git commit -m "feat: initialize Ultra Builder Pro"`，
-但不代为执行（commit 是用户决策）。
-
-### Step 4: 成功总结 + 下一步
-
-用中文输出：
-- ✅ `.ultra/` 骨架（specs / tasks / changes / docs / reports）
-- ✅ `.ultra/state.db` 已初始化为当前 schema，后续不再依赖第一次写操作懒创建
-- ✅ tasks.json 注入元数据（name / type / stack / created / updated）
-- ✅ git 状态（按选择）
-- ⚠️ **下一步**：跑 `/ultra-research` 做 17 步 discovery 填 spec；不要跳过直接 `/ultra-plan`
-
-## 调用方式（按 runtime）
-
-| Runtime | 调用形态 |
-|---------|----------|
-| Claude  | `/ultra-init [name] [type] [stack] [git]` — 命令薄壳拉起此 skill |
-| OpenCode | `/ultra-init …` 同上（agent frontmatter 小写化） |
-| Codex   | `codex exec "run /ultra-init …"`（Phase 4.4 adapter 接） |
-
-## 输出锚点
-
-- `target_dir/.ultra/tasks/tasks.json` — project.name / project.type / project.stack 已注入
-- `target_dir/.ultra/specs/{discovery,product,architecture}.md` — 带 `[NEEDS CLARIFICATION]` 标记
-- 若 `overwrite=true`：`target_dir/.ultra.backup.<ts>/` 保存旧骨架
-
-## 不做的事
-
-- **不**创建业务 task（业务 task 由 `/ultra-plan` 在 spec 填完后批量创建）
-- **不**调 web：离线可执行
+# Initialize or adopt a project
+
+Create project-local Ultra state, then route the repository according to its actual
+baseline status. Do not treat an existing codebase as a new product.
+
+## Preflight
+
+Use the current working directory unless the user names another target. Inspect the
+root, project manifests, Git state, and `.ultra/` without mutation.
+
+If `.ultra/` exists, call `baseline.get` and `system.doctor`:
+
+- a healthy `ready` baseline routes to `ultra-change` or `ultra-status`;
+- `draft`, `adopting`, or baseline-blocked state resumes this workflow;
+- state integrity or migration failure routes to `ultra-doctor`;
+- recreation requires explicit authorization and must preserve the returned backup.
+
+Never overwrite `.ultra/` merely because the repository is old or its documents are
+incomplete.
+
+## Bootstrap
+
+When `.ultra/` is absent, derive project name, type, and stack from repository evidence,
+then call `task.init_project` with `mode: "auto"`. Use an explicit `greenfield` or
+`brownfield` mode only when the user has made that classification authoritative.
+
+Verify the returned mode, baseline id and status, state database path, initial
+projection, and copied specification files.
+
+## Route by mode
+
+### Greenfield
+
+The new baseline begins as `draft`. Route unresolved product or architecture intent to
+`ultra-research`. That workflow records evidence and converges the baseline before
+planning. Do not create implementation tasks during initialization.
+
+### Brownfield
+
+Read `references/brownfield-adoption.md` completely. Adopt current behavior from the
+checkout, tests, maintained documentation, and runtime evidence. Use `baseline.record`
+for the bounded snapshot and `baseline.converge` only after the owner approves the
+captured baseline and any accepted known-red verification.
+
+## Failure handling
+
+- `ULTRA_DIR_EXISTS`: inspect and resume; do not retry with overwrite automatically.
+- `BASELINE_EXISTS`: keep the ready baseline unless explicit re-adoption is required.
+- `BASELINE_IN_PROGRESS`: resume the named baseline rather than creating another.
+- `TEMPLATE_MISSING`: report a package-integrity failure and route to installer doctor.
+- `TARGET_NOT_DIR`, `VALIDATION_ERROR`, or `IO_ERROR`: correct only the evidenced input;
+  preserve any backup and partial diagnostic.
+
+## Output
+
+Report target path, detected mode, baseline id/status/revision, state health, known-red
+verification, blocking unknowns, and one next action. `.ultra/state.db` is authoritative;
+JSON and Markdown projections do not create state.
+
+Do not browse by default, invent missing behavior, rewrite application code, create
+business tasks, stage files, or commit as part of initialization.

package/skills/ultra-init/references/brownfield-adoption.md

@@ -0,0 +1,65 @@
+# Brownfield adoption
+
+Use this procedure only after `task.init_project` selects `brownfield`, or when an
+existing baseline remains `adopting` or `blocked`.
+
+## Establish the snapshot boundary
+
+Bind the repository root, current Git HEAD when available, included paths, excluded
+generated or vendored paths, project manifests, and the user-visible or public seams.
+Use the revision returned by `baseline.record`; non-Git projects receive a deterministic
+workspace revision from the recorded evidence.
+
+## Read current behavior
+
+Inspect only the evidence needed to explain the maintained system:
+
+- entry points and consumers;
+- persisted state and its writers;
+- external interfaces, events, permissions, and failure paths;
+- tests and their live seams;
+- deployment, migration, and recovery paths when present;
+- maintained documents and their relationship to source.
+
+Classify every statement as observed, verified, decided, or unknown. Source and runtime
+evidence outrank stale prose. External memory and code-graph providers may supply
+references, but their content remains outside Ultra state.
+
+## Capture the baseline
+
+Update `.ultra/specs/product.md` with confirmed behavior, actors, entry points, failures,
+and acceptance. Update `.ultra/specs/architecture.md` with actual boundaries, authority,
+runtime paths, dependencies, permissions, and recovery. Use `discovery.md` only for
+evidence or decisions that affect scope.
+
+Do not redesign the project, normalize it to a preferred architecture, manufacture
+personas or alternatives, or convert every source file into documentation.
+
+Run the repository's existing verification commands. Record each result as `pass`,
+`known_red`, or `not_run`. A known-red item needs evidence and a rationale; a missing
+command is not a passing result. Mark an unknown blocking when it can change accepted
+behavior, authority, security, data integrity, or the next implementation plan.
+
+Call `baseline.record` with full replacement arrays for:
+
+- scope and repository revision;
+- product and architecture specification paths;
+- bounded source, documentation, runtime, test, deployment, or external references;
+- verification results;
+- blocking and non-blocking unknowns;
+- external provider metadata references, when supplied.
+
+The server computes specification digests. Do not send prompt, transcript, memory, or
+code-graph payloads.
+
+## Converge
+
+Present the observed behavior, known-red verification, blocking unknowns, and material
+decisions to the project owner. After explicit approval, call `baseline.converge` with
+the recorded revision, approver, approval note, and `accept_known_red` only when the
+owner accepted those failures.
+
+Resolve returned blockers through evidence or an owner decision, record the replacement
+snapshot, and retry. Adoption is complete only when `baseline.get` and `system.doctor`
+report the baseline ready and current. Route the first new outcome to `ultra-change`, or
+route planning of already accepted work to `ultra-plan`.

package/skills/ultra-plan/SKILL.md

@@ -1,109 +1,76 @@
 ---
 name: ultra-plan
-description: "Turn a validated baseline, active delta, or approved PRD into fresh-context vertical slices with public seams and exact verification contracts."
-user-invocable: true
-runtime: all
-mcp_tools_required:
-  - task.create
-  - task.parse_prd
-  - task.dependency_topo
-  - plan.export
-  - plan.get
-  - change.get
-  - change.context
-  - change.breadcrumb
+description: Convert a validated baseline, active delta, or approved PRD into dependency-valid vertical slices with bounded context and exact verification. Use when requirements are ready to become authoritative Ultra tasks.
 ---
 
-# ultra-plan — Fresh-Context Execution Planning
+# Plan fresh-context execution
 
-Produce a dependency-valid plan whose tasks can be executed in isolated contexts.
-`.ultra/state.db` is authoritative; the projector owns task JSON and context
-frontmatter.
+Produce a task graph whose slices can be completed independently and verified through
+live product seams. `.ultra/state.db` remains authoritative; task JSON and context
+Markdown are generated projections.
 
-## Failure boundary
+## Entry gate
 
-Start with a state-backed MCP read. On `LEGACY_STATE_MIGRATION_REQUIRED`, stop and
-instruct:
+Start with a state-backed MCP read. If state or schema health blocks access, stop and
+route to `ultra-doctor`. Never read or write `.ultra/tasks/tasks.json` as a fallback.
+Call `baseline.get`. Initial product planning is blocked until the baseline is
+`ready` and current; route its missing, adopting, blocked, or stale state to
+`ultra-init`. Planning an already active bounded change may continue with the
+baseline condition recorded as a warning. Convergence still requires approved
+adoption, and archive atomically reconciles and verifies revision/spec drift.
 
-```bash
-ultra-tools migrate --from=4.4 --to=4.5 --source-dir <project-root>
-```
+Choose one input:
 
-Never read or write `.ultra/tasks/tasks.json` as authority. If task MCP mutation is
-unavailable, stop; there is no task-creation CLI fallback.
+- validated baseline specifications;
+- one active change packet;
+- a raw PRD through the approval-gated mode below.
 
-## Inputs
-
-Choose exactly one:
-
-- validated baseline specs under `.ultra/specs/`;
-- one active change packet (`intent.md`, `delta/`, `plan.md`);
-- raw PRD using the approval-gated direct mode below.
-
-Ask only for a product or risk decision that cannot be derived from current evidence.
-Record assumptions explicitly; unresolved material assumptions block planning.
+Ask only for product, scope, cost, or risk decisions that cannot be derived from
+current evidence. A material unresolved assumption blocks persistence.
 
 ## Planning rules
 
-1. Trace acceptance through a live entry point, domain behavior, side effects, and a
-   user-observable/public seam.
-2. Prefer a walking skeleton / `tracer_bullet` before horizontal layers.
-3. Make each task completable in a fresh context: one outcome, bounded references,
-   explicit dependencies, and one deterministic verification command.
-4. Keep the default context packet at or below 12 files, 12k approximate tokens, and
-   40% of the fresh context budget.
-5. Use `expand_contract` only when a wider change is approved and cannot be split
-   without losing correctness.
-6. Create integration checkpoints at real seams, not after arbitrary task counts.
-7. Include error, recovery, documentation, and migration work in the task that owns
-   the behavior; do not create unreachable scaffolding tasks.
-
-## Task contract
-
-Every `task.create` must carry or be paired with:
-
-- outcome and acceptance assertions;
-- priority, complexity, dependencies, and ownership paths;
-- linked `change_id` when planning a delta;
-- `slice_kind`: `tracer_bullet`, `expand_contract`, or `integration_checkpoint`;
-- `public_seam`;
-- exact `verification_command`;
-- required context references and their reasons;
-- expected red/green signal for fixes and incidents;
-- documentation impact.
-
-After each task is persisted, compile `change.context` with `role=plan` and
-`gate=planning` when it belongs to a change. A blocked readiness result must be fixed
-before the task is called executable.
-
-## Spec mode / change mode
+1. Trace acceptance through an entry point, domain behavior, side effects, and a
+   user-observable or public seam.
+2. Prefer a walking skeleton or `tracer_bullet` before horizontal layers.
+3. Give each task one outcome, bounded ownership, explicit dependencies, required
+   references, and one deterministic verification command.
+4. Use the context budget as an attention signal. Prefer bounded excerpts, direct
+   reads, or a smaller slice, but keep necessary files when correctness requires them.
+   Budget overflow is a warning, never a reason to inflate a threshold or manufacture
+   a smaller but incomplete contract.
+5. Add integration checkpoints at actual boundaries, not after arbitrary task counts.
+6. Put validation, errors, recovery, documentation, and migrations in the task that
+   owns the behavior.
+7. Reject scaffolding with no reachable consumer.
+
+Every persisted task must include its slice kind, public seam, verification command,
+acceptance evidence, ownership, dependencies, documentation impact, and linked change
+id when applicable.
+
+## Baseline or change mode
 
 1. Read the smallest authoritative references that define acceptance.
-2. Build a task DAG in memory and check file-ownership conflicts.
-3. Present the outcome, order, cost/risk concentration, and walking-skeleton seam.
-4. Obtain approval when the plan materially changes scope or cost.
-5. Persist tasks through `task.create`.
-6. Call `task.dependency_topo`; cycles or missing dependencies are blocking.
-7. Call `plan.export`, then verify it with `plan.get` rather than reparsing the file.
-8. For an active change, call `change.breadcrumb` and report its one next action.
-
-## PRD direct mode
+2. Build the task DAG in memory and check dependency and ownership conflicts.
+3. Present the proposed outcome, execution order, risk concentration, and first live
+   seam. Obtain approval if scope, cost, or delivery semantics change materially.
+4. Persist approved tasks with `task.create`.
+5. For change-linked tasks, compile `change.context` with the planning role and gate.
+   Resolve every readiness blocker before calling a task executable.
+6. Call `task.dependency_topo`; cycles and missing dependencies block completion.
+7. Call `plan.export`, then verify the persisted result with `plan.get`.
+8. Call `change.breadcrumb` when a change is active and return one next action.
+
+## PRD mode
 
 1. Call `task.parse_prd` with `dry_run: true`.
-2. Show the proposed vertical slices, topology, conflict surface, and estimated cost.
-3. Require explicit approval. Rejection performs no state write.
-4. On approval, repeat the same parse with `dry_run: false`, then `plan.export`.
-5. Verify dry-run and persisted task ids match; mismatch is a deterministic failure.
-
-## Context body
-
-Human-readable task context may explain intent, acceptance, seam, red/green signal,
-and relevant references. It must not duplicate entire specs, provider memory, or a
-static codebase tour. The next worker should be able to begin from the manifest and
-verify the slice without recovering the planner's full conversation.
+2. Show the proposed slices, topology, conflict surface, and cost estimate.
+3. Require explicit approval; rejection performs no state write.
+4. On approval, repeat with `dry_run: false`, export the plan, and verify that the
+   dry-run and persisted task identities agree.
 
 ## Completion gate
 
-Planning is complete only when the DAG is valid, every task is reachable through a
-public seam, every command is executable, every change-linked task has a ready Context
-Manifest v2 snapshot, and no required documentation or decision is unknown.
+Planning is complete only when the DAG is valid, each task reaches a public seam, each
+verification command is executable, every change-linked context is ready, and no
+required documentation or decision remains unknown.