@haiyangbg/buildbeat 2.0.2 → 3.0.0

package/bin/buildbeat.js

@@ -1,5 +1,17 @@
 #!/usr/bin/env node
 
-import { run } from "../src/cli.js";
+// BuildBeat runtime CLI entry.
+//
+// Guard before loading any module: the kernel uses Node>=20 syntax, and on a
+// machine whose default node drifted older the raw SyntaxError stack hides
+// the actual problem (real incident: default node v14 during the meta pilot).
+const major = Number(process.versions.node.split(".")[0]);
+if (major < 20) {
+  console.error(
+    `buildbeat needs Node >= 20; this shell resolved v${process.versions.node}.\n` +
+      "Check `which node` / nvm default, then rerun (e.g. `nvm use 23`).",
+  );
+  process.exit(1);
+}
 
-process.exitCode = await run(process.argv.slice(2));
+import("../src/v2/cli/run.js");

package/docs/CAPABILITY-MATRIX.md

@@ -1,51 +1,20 @@
 # BuildBeat 能力矩阵 / Capability Matrix
 
-> 状态：BuildBeat `@haiyangbg/buildbeat@2.0.2`（dist-tag `latest`，2026-09-09；2.0.0 于 2026-09-05 首次把 v2 发到 `latest`）。本页按**产品层次**区分四个可用面：Skill-only 手工路径、v1 生命周期 CLI（`buildbeat`）、v2 运行时（`buildbeat-v2`）、Claude Code 插件；并保留 v1.21 分发合同的原始条目与 legacy npm v0 的边界。源码、registry artifact 与真实项目证据仍分别核验。
+> 状态：BuildBeat `@haiyangbg/buildbeat`（dist-tag `latest`；发布证据按版本归档在本目录的 `*-RELEASE-EVIDENCE-*.md`）。本页按**产品层次**区分三个可用面：Skill-only 手工路径、运行时 `buildbeat`、Claude Code 插件。源码、registry artifact 与真实项目证据仍分别核验。
 
-## 0. 四个可用面
+## 0. 三个可用面
 
 | 层 | 是什么 | 装在哪 | 权威文档 | 已验证到什么程度 |
 |---|---|---|---|---|
-| **Skill-only 手工路径** | 工件协议（Work 目录、intent/plan、决策台账、证据分级）由 AI 会话按 `SKILL.md` 手工维护 | Skill 本身（仓库 `SKILL.md` / 插件） | `SKILL.md` | 协议完整可用；**没有**自动闭环、隔离 worktree、digest 绑定批准校验、预算与恢复（`tests/skill-only.test.sh` 证明去掉 CLI 后 v1 文件总线仍可维护） |
-| **v1 生命周期 CLI `buildbeat`** | `doctor / init / adopt / upgrade / version`：v1 文件总线骨架的只读体检、受控写入与 schema 2 机械升级 | `@haiyangbg/buildbeat@latest`（2.0.0 起与 v2 同包；骨架版本仍 v1.21） | [`CLI.md`](CLI.md) | 1.21 发布证据 + 真实版本增量试点（§5）；2.0.0 未改其命令与边界 |
-| **v2 运行时 `buildbeat-v2`** | 隔离 worktree 内 Build→Verify→Review→Fix 自动闭环，停在人的合并决定；`accept / start / resume / status / inbox / overview / approve / reject / findings / doctor / preflight / gc / metrics / observe / watch` | 同上 | [`v2/guide/`](v2/guide/README.md)、RFC-0001/2/3、SPEC-0001 | 单元与 CLI 端到端测试（`tests/v2-*.test.js`，含脚本 worker 的模板首跑）；真实 AI worker 试点见 `docs/v2/M4-*`、迭代记录（`codex exec` 实证；其他工具"可通过命令接入"，未逐一验证） |
+| **Skill-only 手工路径** | 工件协议（Work 目录、intent/plan、决策台账、证据分级）由 AI 会话按 `SKILL.md` 手工维护 | Skill 本身（仓库 `SKILL.md` / 插件） | `SKILL.md` | 协议完整可用；**没有**自动闭环、隔离 worktree、digest 绑定批准校验、预算与恢复 |
+| **运行时 `buildbeat`** | 隔离 worktree 内 Build→Verify→Review→Fix 自动闭环，停在人的合并决定；`accept / start / resume / status / inbox / overview / approve / reject / findings / doctor / preflight / gc / metrics / observe / watch` | `npm install --global @haiyangbg/buildbeat@latest` | [`v2/guide/`](v2/guide/README.md)、RFC-0001/2/3、SPEC-0001 | 单元与 CLI 端到端测试（`tests/v2-*.test.js`，含脚本 worker 的模板首跑）与打包首跑（`tests/pack-firstrun.test.sh`）；真实 AI worker 试点见 `docs/v2/M4-*`、迭代记录（`codex exec` 实证；其他工具"可通过命令接入"，未逐一验证） |
 | **Claude Code 插件** | 把 Skill、模板、文档、lessons 装进 Claude Code；**不含**任何 CLI `bin/` | `claude plugin marketplace add HaiYangBG1/BuildBeat` + `claude plugin install buildbeat@buildbeat-plugins` | [`plugins/buildbeat/README.md`](../plugins/buildbeat/README.md) | `tests/plugin-marketplace.test.sh`（manifest 校验、隔离安装、缓存自包含）；装了插件不等于装了运行时，两者分别检查 |
 
-一句话：Skill 是入口（会话读它决定调什么），CLI 是引擎（`buildbeat-v2` 跑 Run、`buildbeat` 管 v1 骨架），项目文件是事实（Git 面 `delivery/` 与 `.buildbeat/`），插件只是把入口送进 Claude Code。
+一句话：Skill 是入口（会话读它决定调什么），`buildbeat` 是引擎（跑 Run、回读事实），项目文件是事实（Git 面 `delivery/` 与本机 `.buildbeat/`），插件只是把入口送进 Claude Code。
 
-## 1. 三组生命周期入口
+## 1. 运行时面：`buildbeat`
 
-WP4.2 所说的“CLI 三命令”按职责分成三组，不是把 `version` 或兼容别名算成新生命周期能力：
-
-| 组 | canonical 命令 | 机械责任 | 不承担 |
-|---|---|---|---|
-| 检查 | `buildbeat doctor` | 只读识别安装/布局/版本、关键文件、占位符、Hook 与本地依赖降级 | 不复制 `bus-check`，不判断业务正确、Gate 或线上健康 |
-| 建骨架 | `buildbeat init` / `buildbeat adopt` | 规划或受控写入默认/紧凑布局，填确定项，manifest 最后写 | 不猜项目语义，不安装 Hook，不初始化 Git，不跨人工 Gate |
-| 机械升级 | `buildbeat upgrade` | 对真实 schema 2 基线按 policy/hash 替换未改文件，冲突时 fail-closed | 不三方合并，不覆盖 project-owned，不猜 legacy 所有权，不自动删文件 |
-
-`buildbeat version` 是纯信息工具。`diff` 与 `uninstall` 仍只是返回 `command_not_available` 的保留名；`check/status/gate/adr/standards` 属于 Skill 与项目脚本，不进 CLI。`solobaton` 是 legacy 可执行兼容别名，不是第四组能力。
-
-## 2. v1 生命周期面：Skill-only / legacy v0 / `buildbeat`
-
-本节是 v1.21 分发合同的原始条目，2.0.0 未改变其中任何一行；v2 运行时的能力见 §2.5。
-
-| 能力 | Skill-only / 手工路径 | legacy `solobaton@1.16.3` | v1 生命周期 CLI（BuildBeat `@haiyangbg/buildbeat@1.21.0` 起，2.0.0 包内不变） | 权威与边界 |
-|---|---|---|---|---|
-| 理解新/存量项目，只问剩余问题 | 完整；读代码/配置后做 Bootstrap/Adopt | 不提供语义判断 | 不提供语义判断，只输出有界事实/问题 | Skill 与当前 AI 会话承担语义，CLI 不内置模型 |
-| 安装与能力体检 | 读文件并运行项目脚本 | `doctor` 只读可用 | `doctor` 只读可用 | `doctor` 是 CLI 体检；同步检查唯一权威仍是项目 `bus-check` |
-| 新项目 Bootstrap | 一屏确认后手动复制/渲染，完整可用 | `init --dry-run` 只规划；去掉 dry-run 拒绝写入 | `init --dry-run` 预览；无 blocker + 确认后受控 apply | 项目事实与剩余占位符必须回到 Skill 渲染 |
-| 存量项目 Adopt | 先摸底/划新旧边界/补最小验证，完整可用 | `adopt --dry-run` 只规划 | `adopt --dry-run` 预览；默认紧凑布局，确认后受控 apply | CLI 不决定绞杀者边界、危险区或 L3 充分性 |
-| 项目语义渲染 | 完整；填契约、看板、验证、部署与风险事实 | 不提供 | 只填项目名/日期/版本/布局等确定项 | CLI 的 `pendingPlaceholders` 是交接清单，不是完成声明 |
-| Gate、status、evidence、standards、ADR | 完整；由 Skill + 项目文件/脚本维护 | 不提供工作流命令 | 不提供工作流命令 | 人工 Gate 不能被 CLI/reviewer/绿测试代批 |
-| 同步/Gate/证据/多仓/STACK 检查 | 项目内 `bus-check --format=json --strict` 可独立运行 | 不复制脚本 finding | 不复制脚本 finding | `docs/CHECKS.md` + 项目脚本是唯一同步检查权威；覆盖不完必须显示 unverified |
-| schema 2 生命周期基线 | Skill-only 不需 manifest，也不手写伪造 | 只读识别历史 manifest | `init/adopt` 成功交易最后写入 | manifest 只是所有权/hash 基线，不是项目事实数据库 |
-| 拷出/legacy 项目升级 | 按 CHANGELOG 和 policy 手工语义合并 | `upgrade` 未开放 | 无真实 schema 2 基线必须 blocked | 不手写/复制/改名 manifest；见 `LEGACY-V1.16-MIGRATION.md` |
-| schema 2 机械升级 | Skill 处理机械冲突后的语义合并 | 未开放 | 已实现；同 major 按 hash，跨 major 需 `--major`，`--force` 不碰 project-owned | 真实版本增量试点与发布证据分别归档，不以模板测试代替 |
-| Git 初始化、Hook、commit/push/deploy/publish | 经明确授权后人/会话按项目边界执行 | 不执行 | 不执行 | 生命周期 CLI 不扩张任何外部权限；发布另走 `RELEASING.md` |
-
-## 2.5 v2 运行时面：`buildbeat-v2`（2.0.0）
-
-| 能力 | Skill-only / 手工路径 | v2 运行时 `buildbeat-v2` | 权威与边界 |
+| 能力 | Skill-only / 手工路径 | 运行时 `buildbeat` | 权威与边界 |
 |---|---|---|---|
 | 工件接受 | 会话记一行到 `decisions.jsonl` | `accept --artifact intent\|plan\|spec`：digest 绑定；改过即 `stale`，`doctor` / `overview` 报出 | 接受不是开工；policy 按 riskPreset 决定 build 前要求哪些工件已接受 |
 | 自动闭环 | 无 | `start --config <run-config> [--attempt new]`：隔离 worktree、builder→verify→review→fix 自动路由、停 `WAITING_HUMAN` | 一仓同时只有一个活动 Run；worker 是配置的任意命令，内核不内置模型 |
@@ -58,24 +27,13 @@ WP4.2 所说的“CLI 三命令”按职责分成三组，不是把 `version`
 | 生产体检 | 无 | `observe run / status / triage`：探针 → 分层 → Intent 草稿入队 | 草稿绝不自动执行 |
 | 通知 | 无 | `.buildbeat/notify.yaml`（钉钉 / webhook，URL 只能来自环境变量） | 通知不是审批通道 |
 | 环境合同 | 无 | `requires:`（command / probe）启动前 fail-closed；worker env 白名单，`env:` 点名注入，`inheritEnv` 显式打开 | 见 [安全边界](v2/guide/09-security-boundaries.md)：内核检测与移除的边界 vs 宿主沙箱 |
-| 首跑验证 | — | `tests/v2-templates-firstrun.test.js`：脚本 worker 从模板走到合并决定（含 verify 失败→fixer） | 证明路径与合同连得上，不证明真实模型能完成任务 |
-
-## 3. 双向互操作结论
-
-| 转换 | 结论 | 已验证 | 不可外推 |
-|---|---|---|---|
-| Skill-only → CLI `doctor` | 可保守识别；无 manifest 显式 `manifest.missing`，不猜所有权 | `tests/skill-only.test.sh` 自动回归 | 不因 doctor 可读就获得机械 upgrade |
-| CLI `init/adopt` → Skill-only | 项目仍是普通 Git 文件/脚本；屏蔽 Node/CLI 后可继续维护并 strict 检查 | 自动互操作回归 + WP2.8 本地真实目录试点 | 不证明业务测试、Gate 或线上状态 |
-| CLI `upgrade` → Skill-only | 升级后仍使用同一文件协议；冲突交给 Skill 语义合并 | disposable 升级沙箱 + BuildBeat 1.20 真实版本增量试点 | 不证明未观测的业务、线上或生产状态 |
-| legacy v1.16 → schema 2 | 默认继续手工维护；经批准才在专用分支重建基线 | 指南和静态契约已闭合 | 没有执行真实 legacy 迁移 |
+| 首跑验证 | — | `tests/v2-templates-firstrun.test.js`：脚本 worker 从模板走到合并决定（含 verify 失败→fixer）；`tests/pack-firstrun.test.sh` 从安装后的包再走一遍 | 证明路径与合同连得上，不证明真实模型能完成任务 |
 
-## 4. Distribution status / 分发状态
+## 2. Distribution status / 分发状态
 
-- **Skill-only:** first-class and complete for protocol semantics; it does not need a lifecycle manifest or a runtime CLI.
-- **Legacy npm v0:** `solobaton@latest` is frozen on `doctor`, `init/adopt --dry-run`, and version inspection, then deprecated toward the scoped package. Project writes and `upgrade` remain unavailable there.
-- **BuildBeat 2.0.x (current `latest` = 2.0.2):** since `@haiyangbg/buildbeat@2.0.0` (evidence: [`V2.0.0-RELEASE-EVIDENCE-2026-09-05.md`](V2.0.0-RELEASE-EVIDENCE-2026-09-05.md)) one package ships the unchanged v1 lifecycle CLI `buildbeat` and the v2 runtime `buildbeat-v2`; 2.0.1 fixed run-config `env:` passthrough and added `templates/v2/` (evidence: [`V2.0.1-RELEASE-EVIDENCE-2026-09-06.md`](V2.0.1-RELEASE-EVIDENCE-2026-09-06.md)); 2.0.2 only trims historical documents from the tarball. The managed v1 scaffold stays at `v1.21`.
-- **BuildBeat 1.21 (previous stable, 2026-08-25 → 2026-09-05):** `@haiyangbg/buildbeat@1.21.0` was the independently verified canonical scoped distribution before 2.0.0. It keeps the bounded `init/adopt` and schema-2-only mechanical `upgrade` surface established in 1.20, and adds the standard domain-response contract to Skill/scaffold handoffs. Registry availability, provenance, signatures, and exact artifact identity are archived in [`V1.21-RELEASE-EVIDENCE-2026-08-25.md`](V1.21-RELEASE-EVIDENCE-2026-08-25.md) and remain live-recheck requirements for future releases.
+- **Skill-only:** first-class and complete for protocol semantics; it does not need the runtime.
+- **Runtime:** `@haiyangbg/buildbeat@latest` ships one executable, `buildbeat`, with zero third-party runtime dependencies. Each published version is independently read back (registry identity, provenance, signatures, isolated install, packaged first run) before the tag moves; the dated evidence files in this directory are the record, [`RELEASING.md`](RELEASING.md) is the procedure.
 - **Claude Code plugin:** the local marketplace candidate distributes the canonical Skill/templates/docs, not the top-level npm CLI `bin/`; installation evidence does not authorize project writes or npm publication.
-- **Project runtime:** after scaffolding, the Git files and project-local scripts remain independently usable. BuildBeat has no account service, telemetry, remote project database, or hosted agents; the v2 runtime is a local process that orchestrates the commands you configure and never carries a model of its own.
+- **Project runtime:** the Git files remain independently usable without the runtime. BuildBeat has no account service, telemetry, remote project database, or hosted agents; the runtime is a local process that orchestrates the commands you configure and never carries a model of its own.
 
-The real version-increment and multi-repository evidence remains archived in [`PHASE4-V1.20-PILOT-2026-08-25.md`](PHASE4-V1.20-PILOT-2026-08-25.md); release readiness is tracked in [`PHASE4-STABILITY-AUDIT-2026-08-25.md`](PHASE4-STABILITY-AUDIT-2026-08-25.md), the first scoped publication in [`WP4.3-RELEASE-EVIDENCE-2026-08-25.md`](WP4.3-RELEASE-EVIDENCE-2026-08-25.md), and the current v1.21 distribution in [`V1.21-RELEASE-EVIDENCE-2026-08-25.md`](V1.21-RELEASE-EVIDENCE-2026-08-25.md). v1 lifecycle command details remain authoritative in [`CLI.md`](CLI.md); the v2 command surface is documented in [`v2/guide/`](v2/guide/README.md) with RFC-0003 as the workflow authority; legacy migration uses [`LEGACY-V1.16-MIGRATION.md`](LEGACY-V1.16-MIGRATION.md); moving a v1 file-bus project onto v2 uses [`v2/guide/08-migration-v1.md`](v2/guide/08-migration-v1.md).
+The command surface is documented in [`v2/guide/`](v2/guide/README.md) with RFC-0003 as the workflow authority. Removed generations (the file bus, its lifecycle CLI, and the pre-3.0 executable names) live only in the dated history under this directory and in [`CHANGELOG-v1.md`](../CHANGELOG-v1.md).

package/docs/README.md

@@ -1,26 +1,23 @@
 # docs/ 总入口
 
-> 这一页只回答"我该读哪份"。文件按**现行**与**历史**分开：现行文档描述今天的包（`@haiyangbg/buildbeat@latest`，v2 系列）并受 `tests/check_docs.py` 的时效检查约束；历史文档保存当时的事实与数字，只加状态说明、不改原文。
+> 这一页只回答"我该读哪份"。文件按**现行**与**历史**分开：现行文档描述今天的包（`@haiyangbg/buildbeat@latest`）并受 `tests/check_docs.py` 的时效检查约束；历史文档保存当时的事实与数字，只加状态说明、不改原文。
 
 ## 现行：用户读
 
 | 你要做什么 | 读 |
 |---|---|
-| 第一次用 v2，在 AI 会话里 | [`v2/guide/00-how-to-talk.md`](v2/guide/00-how-to-talk.md) → 会话读 [`SKILL.md`](../SKILL.md) §0.5 |
-| 第一次用 v2，自己敲命令核对 | [`v2/guide/01-quickstart.md`](v2/guide/01-quickstart.md) |
-| 十件套指南（日常 / 配置 / 迁移） | [`v2/guide/README.md`](v2/guide/README.md) |
+| 第一次用，在 AI 会话里 | [`v2/guide/00-how-to-talk.md`](v2/guide/00-how-to-talk.md) → 会话读 [`SKILL.md`](../SKILL.md) §0.5 |
+| 第一次用，自己敲命令核对 | [`v2/guide/01-quickstart.md`](v2/guide/01-quickstart.md) |
+| 指南索引（日常 / 配置） | [`v2/guide/README.md`](v2/guide/README.md) |
 | 关闭旧会话后继续，或由其他成员/工具接手 | [`跨会话接续`](v2/guide/11-session-handoff.md) · [English](v2/guide/11-session-handoff.en.md) |
-| 四个可用面各能做什么（Skill-only / v1 CLI / v2 运行时 / 插件） | [`CAPABILITY-MATRIX.md`](CAPABILITY-MATRIX.md) |
-| v1 生命周期 CLI（`buildbeat doctor/init/adopt/upgrade`） | [`CLI.md`](CLI.md)、[`CHECKS.md`](CHECKS.md) |
-| 从 v1 文件总线迁到 v2 | [`v2/guide/08-migration-v1.md`](v2/guide/08-migration-v1.md) |
-| v1.16 拷出项目重建 schema 2 基线 | [`LEGACY-V1.16-MIGRATION.md`](LEGACY-V1.16-MIGRATION.md) |
+| 三个可用面各能做什么（Skill-only / 运行时 / 插件） | [`CAPABILITY-MATRIX.md`](CAPABILITY-MATRIX.md) |
 | 项目装载入口与信封模板 | [`../templates/v2/`](../templates/v2/AGENTS.md) |
 
 ## 现行：规范与维护
 
 | 内容 | 读 |
 |---|---|
-| v2 产品定位 / 域模型 / workflow 与 policy / 事件 schema | [`v2/RFC-0001`](v2/RFC-0001-product-definition.md) / [`RFC-0002`](v2/RFC-0002-domain-model.md) / [`RFC-0003`](v2/RFC-0003-workflow-policy.md) / [`SPEC-0001`](v2/SPEC-0001-events-v1.md)（`FINAL`；带日期的生效修订写在正文顶部） |
+| 产品定位 / 域模型 / workflow 与 policy / 事件 schema | [`v2/RFC-0001`](v2/RFC-0001-product-definition.md) / [`RFC-0002`](v2/RFC-0002-domain-model.md) / [`RFC-0003`](v2/RFC-0003-workflow-policy.md) / [`SPEC-0001`](v2/SPEC-0001-events-v1.md)（`FINAL`；带日期的生效修订写在正文顶部） |
 | 发布手册、通道、发布后同步清单 | [`RELEASING.md`](RELEASING.md) |
 | 分支策略、测试分层、文档权威分层 | [`../CONTRIBUTING.md`](../CONTRIBUTING.md)、[`../tests/README.md`](../tests/README.md) |
 | 每条机制背后的真实事故 | [`../lessons.md`](../lessons.md) |
@@ -29,11 +26,12 @@
 
 | 类别 | 文件 |
 |---|---|
-| 发布证据 | `V2.0.1-RELEASE-EVIDENCE-2026-09-06.md`（当前 `latest`）、`V2.0.0-RELEASE-EVIDENCE-2026-09-05.md`、`V2.0.0-BETA.1～5-RELEASE-EVIDENCE-*.md`、`V1.21-RELEASE-EVIDENCE-2026-08-25.md`、`WP4.3-RELEASE-EVIDENCE-2026-08-25.md` |
-| v2 规划与决策 | [`V2-PLAN.md`](V2-PLAN.md)（执行基线，已交付）、[`V2-PROPOSAL.md`](V2-PROPOSAL.md)、[`V2-DECISIONS.md`](V2-DECISIONS.md)、[`V2-D2-DECISION-CARD.md`](V2-D2-DECISION-CARD.md)、[《BuildBeat v2：AI 原生软件交付控制平面》](BuildBeat%20v2%EF%BC%9AAI%20%E5%8E%9F%E7%94%9F%E8%BD%AF%E4%BB%B6%E4%BA%A4%E4%BB%98%E6%8E%A7%E5%88%B6%E5%B9%B3%E9%9D%A2.md) |
-| v2 迭代与里程碑记录 | `V2-ITERATION-01～08.md`、[`v2/`](v2/) 下的 M1/M2/M4 验收与试点记录 |
-| v1 路线与阶段试点 | [`ROADMAP.md`](ROADMAP.md)、[`EXECUTION-PLAN.md`](EXECUTION-PLAN.md)、`PHASE1/2/4-*.md`、[`CLI-STRATEGY-2026-08.md`](CLI-STRATEGY-2026-08.md)、[`CLI-PILOT-2026-08-23.md`](CLI-PILOT-2026-08-23.md)、[`PHASE4-STABILITY-AUDIT-2026-08-25.md`](PHASE4-STABILITY-AUDIT-2026-08-25.md) |
+| 发布证据 | `V2.0.2-RELEASE-EVIDENCE-2026-09-09.md`（当前 `latest`）、`V2.0.1-RELEASE-EVIDENCE-2026-09-06.md`、`V2.0.0-RELEASE-EVIDENCE-2026-09-05.md`、`V2.0.0-BETA.1～5-RELEASE-EVIDENCE-*.md`、`V1.21-RELEASE-EVIDENCE-2026-08-25.md`、`WP4.3-RELEASE-EVIDENCE-2026-08-25.md` |
+| 规划与决策（2026-08） | [`V2-PLAN.md`](V2-PLAN.md)（执行基线，已交付）、[`V2-PROPOSAL.md`](V2-PROPOSAL.md)、[`V2-DECISIONS.md`](V2-DECISIONS.md)、[`V2-D2-DECISION-CARD.md`](V2-D2-DECISION-CARD.md)、[《BuildBeat v2：AI 原生软件交付控制平面》](BuildBeat%20v2%EF%BC%9AAI%20%E5%8E%9F%E7%94%9F%E8%BD%AF%E4%BB%B6%E4%BA%A4%E4%BB%98%E6%8E%A7%E5%88%B6%E5%B9%B3%E9%9D%A2.md) |
+| 迭代与里程碑记录 | `V2-ITERATION-01～08.md`、[`v2/`](v2/) 下的 M1/M2/M4 验收与试点记录 |
+| 早期版本史 | [`../CHANGELOG-v1.md`](../CHANGELOG-v1.md)（2026-06 ～ 2026-08 的条目原文；当前条目在根 [`CHANGELOG.md`](../CHANGELOG.md)） |
+| 早期路线与阶段试点（2026-08，已移除的文件总线时代） | [`ROADMAP.md`](ROADMAP.md)、[`EXECUTION-PLAN.md`](EXECUTION-PLAN.md)、`PHASE1/2/4-*.md`、[`CLI-STRATEGY-2026-08.md`](CLI-STRATEGY-2026-08.md)、[`CLI-PILOT-2026-08-23.md`](CLI-PILOT-2026-08-23.md)、[`PHASE4-STABILITY-AUDIT-2026-08-25.md`](PHASE4-STABILITY-AUDIT-2026-08-25.md) |
 
-历史文件里的版本号、通道与测试数字是它们日期当天的事实，出现"`latest` 留 v1"之类的旧策略是正常的；判断现状只看现行文档与 registry 回读（`npm view @haiyangbg/buildbeat dist-tags`）。
+历史文件里的版本号、通道与测试数字是它们日期当天的事实，出现已被移除的旧机制和旧通道策略是正常的；判断现状只看现行文档与 registry 回读（`npm view @haiyangbg/buildbeat dist-tags`）。
 
 历史文件只保存在 GitHub 仓库里，不随 npm 包分发（`package.json` 的 `files` 显式排除）；从安装目录点开现行文档里指向历史文件的链接会落空，到 [`HaiYangBG1/BuildBeat`](https://github.com/HaiYangBG1/BuildBeat/tree/main/docs) 看即可。现行文档全部随包分发，`tests/pack-firstrun.test.sh` 守着这两条边界。

package/docs/RELEASING.md

@@ -1,8 +1,8 @@
 # BuildBeat CLI package release runbook
 
-This runbook governs BuildBeat's public npm distribution. The canonical package is `@haiyangbg/buildbeat` in `HaiYangBG1/BuildBeat`; the canonical executable is `buildbeat`, while `solobaton` remains an executable alias. The old `solobaton` npm package is a frozen legacy distribution ID and must not receive the scoped write/upgrade command surface.
+This runbook governs BuildBeat's public npm distribution. The canonical package is `@haiyangbg/buildbeat` in `HaiYangBG1/BuildBeat`; the only executable is `buildbeat`. No other package name or executable alias receives publications.
 
-Release evidence at source package version `@haiyangbg/buildbeat@2.0.2`; latest independently verified BuildBeat npm distribution `@haiyangbg/buildbeat@2.0.1` (dist-tag `latest`; `next` stays `2.0.0-beta.5`), anchored by annotated tag `v2.0.1` at commit `4b2362f`, workflow run [34032278315](https://github.com/HaiYangBG1/BuildBeat/actions/runs/34032278315), and archived in [`V2.0.1-RELEASE-EVIDENCE-2026-09-06.md`](V2.0.1-RELEASE-EVIDENCE-2026-09-06.md). The 2.0.0 chain (`latest` from 2026-09-05 until 2.0.1 took over on 2026-09-06) stays archived in [`V2.0.0-RELEASE-EVIDENCE-2026-09-05.md`](V2.0.0-RELEASE-EVIDENCE-2026-09-05.md). The beta.5 chain stays archived in [`V2.0.0-BETA.5-RELEASE-EVIDENCE-2026-09-05.md`](V2.0.0-BETA.5-RELEASE-EVIDENCE-2026-09-05.md). The beta.4 chain stays archived in [`V2.0.0-BETA.4-RELEASE-EVIDENCE-2026-09-03.md`](V2.0.0-BETA.4-RELEASE-EVIDENCE-2026-09-03.md); the beta.3 chain in [`V2.0.0-BETA.3-RELEASE-EVIDENCE-2026-09-01.md`](V2.0.0-BETA.3-RELEASE-EVIDENCE-2026-09-01.md). The beta.2 chain stays archived in [`V2.0.0-BETA.2-RELEASE-EVIDENCE-2026-08-28.md`](V2.0.0-BETA.2-RELEASE-EVIDENCE-2026-08-28.md); the beta.1 chain stays archived in [`V2.0.0-BETA.1-RELEASE-EVIDENCE-2026-08-28.md`](V2.0.0-BETA.1-RELEASE-EVIDENCE-2026-08-28.md). The previous stable distribution, `@haiyangbg/buildbeat@1.21.0` (`latest` from 2026-08-25 until 2.0.0 took over on 2026-09-05), stays anchored by annotated tag `v1.21.0` at commit `ce69a05`, workflow run [32864438692](https://github.com/HaiYangBG1/BuildBeat/actions/runs/32864438692), and the matching [GitHub Release](https://github.com/HaiYangBG1/BuildBeat/releases/tag/v1.21.0). Its exact registry identity, provenance, signatures, isolated-install readback, Environment approval, and immutable-artifact boundary are archived in [`V1.21-RELEASE-EVIDENCE-2026-08-25.md`](V1.21-RELEASE-EVIDENCE-2026-08-25.md). First-scoped-release bootstrap behavior and legacy deprecation remain archived in [`WP4.3-RELEASE-EVIDENCE-2026-08-25.md`](WP4.3-RELEASE-EVIDENCE-2026-08-25.md). The legacy distribution remains `solobaton@1.16.3`; all three published legacy versions are retained and deprecated toward the scoped package.
+Release evidence at source package version `@haiyangbg/buildbeat@3.0.0`; latest independently verified BuildBeat npm distribution `@haiyangbg/buildbeat@2.0.2` (dist-tag `latest`; `next` stays `2.0.0-beta.5`), anchored by annotated tag `v2.0.2` at commit `a077367`, workflow run [34351668694](https://github.com/HaiYangBG1/BuildBeat/actions/runs/34351668694), and archived in [`V2.0.2-RELEASE-EVIDENCE-2026-09-09.md`](V2.0.2-RELEASE-EVIDENCE-2026-09-09.md). The 2.0.1 chain (`latest` from 2026-09-06 until 2.0.2 took over on 2026-09-09) stays archived in [`V2.0.1-RELEASE-EVIDENCE-2026-09-06.md`](V2.0.1-RELEASE-EVIDENCE-2026-09-06.md). The 2.0.0 chain (`latest` from 2026-09-05 until 2.0.1 took over on 2026-09-06) stays archived in [`V2.0.0-RELEASE-EVIDENCE-2026-09-05.md`](V2.0.0-RELEASE-EVIDENCE-2026-09-05.md). The beta.5 chain stays archived in [`V2.0.0-BETA.5-RELEASE-EVIDENCE-2026-09-05.md`](V2.0.0-BETA.5-RELEASE-EVIDENCE-2026-09-05.md). The beta.4 chain stays archived in [`V2.0.0-BETA.4-RELEASE-EVIDENCE-2026-09-03.md`](V2.0.0-BETA.4-RELEASE-EVIDENCE-2026-09-03.md); the beta.3 chain in [`V2.0.0-BETA.3-RELEASE-EVIDENCE-2026-09-01.md`](V2.0.0-BETA.3-RELEASE-EVIDENCE-2026-09-01.md). The beta.2 chain stays archived in [`V2.0.0-BETA.2-RELEASE-EVIDENCE-2026-08-28.md`](V2.0.0-BETA.2-RELEASE-EVIDENCE-2026-08-28.md); the beta.1 chain stays archived in [`V2.0.0-BETA.1-RELEASE-EVIDENCE-2026-08-28.md`](V2.0.0-BETA.1-RELEASE-EVIDENCE-2026-08-28.md). Earlier distributions and the retired legacy package name are archived in the dated evidence files under `docs/`.
 
 ## Channels and branches
 
@@ -16,7 +16,7 @@ Release evidence at source package version `@haiyangbg/buildbeat@2.0.2`; latest
 ## Release invariants
 
 1. One npm version maps to one immutable annotated Git tag and one exact source commit. Never move a published version's tag.
-2. `CLI_VERSION` comes from `package.json`; the scaffold version is the pinned `SCAFFOLD_VERSION` literal in `src/constants.js` and tracks the frozen v1 scaffold content bundle, not the CLI. Since the v2 package line it stays at `v1.21` until the scaffold surface itself changes — a package release never invents a scaffold upgrade.
+2. The runtime version comes from `package.json` (`buildbeat --version`). Project templates under `templates/v2/` are copied into projects by hand; a package release never rewrites a project's files.
 3. Publish only from a clean worktree whose `HEAD`, tag target, tested commit, and packed artifact all match.
 4. `publishConfig.registry` stays pinned to `https://registry.npmjs.org/`; a developer's mirror configuration must not redirect a public release.
 5. A successful `npm publish` response is not enough. Registry metadata, tarball contents, an isolated install, the executable version, and a read-only command must be checked independently.
@@ -24,7 +24,7 @@ Release evidence at source package version `@haiyangbg/buildbeat@2.0.2`; latest
 7. After a version is published, later `main` documentation changes carrying that same `package.json` version do not redefine its artifact and are not releasable candidates. The next publication requires a new package version, Changelog heading, and annotated tag.
 8. Canonical examples use `@haiyangbg/buildbeat@latest`, not a hard-coded release number. Reproducible consumers first resolve `npm view @haiyangbg/buildbeat@latest version`, record that exact version, and substitute it for `@latest`; exact release evidence remains in this runbook and the matching GitHub Release. One-off commands use `npx --yes --package=@haiyangbg/buildbeat@latest buildbeat ...`.
 9. The active repository ruleset `Protect release tags` must match `refs/tags/v*`, forbid tag updates and deletions, and grant no bypass actor. It deliberately does not forbid creation, so a reviewed new release tag can still be created once.
-10. The write-enabled first-screen command `npx --yes --package=@haiyangbg/buildbeat@latest buildbeat init my-project` is active because every scoped artifact that has held `latest` (1.21.0 on 2026-08-25, 2.0.0 on 2026-09-05) passed registry/provenance/signature/isolated-install/README readback before the tag moved. The old-name WP2.7 pilots remain historical compatibility evidence and do not redefine the scoped artifact.
+10. The README install line `npm install --global @haiyangbg/buildbeat@latest` is safe to advertise because every artifact that has held `latest` passed registry/provenance/signature/isolated-install/README readback before the tag moved.
 
 ## Candidate checks
 
@@ -85,11 +85,10 @@ release_probe="$(mktemp -d)"
 npm install --prefix "$release_probe" "@haiyangbg/buildbeat@$release_version" \
   --registry=https://registry.npmjs.org/ --ignore-scripts --no-audit --no-fund
 node "$release_probe/node_modules/@haiyangbg/buildbeat/bin/buildbeat.js" --version
-node "$release_probe/node_modules/@haiyangbg/buildbeat/bin/solobaton.js" --version
-node "$release_probe/node_modules/@haiyangbg/buildbeat/bin/buildbeat.js" doctor . --json
+node "$release_probe/node_modules/@haiyangbg/buildbeat/bin/buildbeat.js" >/dev/null
 ```
 
-The expected version is exact. `doctor` may correctly return exit 1 for a directory without an installed scaffold; the acceptance condition is valid bounded JSON and zero project writes, not a forced green diagnosis.
+The expected version is exact. The bare invocation prints usage and exits 0 without touching the current directory; the acceptance condition is zero project writes, not a forced green diagnosis.
 
 Only after this readback should the matching GitHub Release be published and documentation treat the npm version as independently verified.
 
@@ -123,7 +122,7 @@ The workflow waits for exact registry-version readback, requires `dist.attestati
 
 Trusted Publishing removes the long-lived write token and automatically emits provenance for supported public GitHub repositories. Configure the exact owner, repository, workflow filename, allowed `npm publish` action, and the exact `npm-publish` environment on npmjs.com. A GitHub Environment without the matching npm-side environment binding is not sufficient evidence. See npm's [Trusted Publishing](https://docs.npmjs.com/trusted-publishers/) and [provenance](https://docs.npmjs.com/generating-provenance-statements/) documentation.
 
-The bootstrap `0.0.0` package is not retroactively provenance-backed and must remain on the non-default `bootstrap` tag. The existence of the workflow and trusted-publisher binding is configuration evidence only; npm validates the binding during the real publish. After the first OIDC release succeeds, set `npm access set mfa=publish @haiyangbg/buildbeat` and independently read back npm's most restrictive Publishing access option, currently labeled `Require two-factor authentication and disallow bypass 2fa tokens (recommended)`, while preserving the Trusted Publisher. Then deprecate every legacy `solobaton` version with a concise migration pointer to `@haiyangbg/buildbeat`; do not unpublish it, because existing read-only installations and redirects remain useful compatibility paths. Because package access, trust, tags, and deprecation are mutable registry state, future release operators must recheck them live.
+The bootstrap `0.0.0` package is not retroactively provenance-backed and must remain on the non-default `bootstrap` tag. The existence of the workflow and trusted-publisher binding is configuration evidence only; npm validates the binding during the real publish. After the first OIDC release succeeds, set `npm access set mfa=publish @haiyangbg/buildbeat` and independently read back npm's most restrictive Publishing access option, currently labeled `Require two-factor authentication and disallow bypass 2fa tokens (recommended)`, while preserving the Trusted Publisher. Because package access, trust, tags, and deprecation are mutable registry state, future release operators must recheck them live.
 
 ## Post-release synchronization checklist
 
@@ -132,7 +131,7 @@ Publishing the artifact is one surface. These are the others; each has drifted a
 - [ ] `CHANGELOG.md`: `## Unreleased` renamed to the version with date and the publication paragraph (run id, dist-tag, readback).
 - [ ] `docs/<VERSION>-RELEASE-EVIDENCE-<date>.md` archived; the current-state paragraph at the top of this runbook names the new version and the previous stable moves to a dated past tense — never two "current" versions in one runbook.
 - [ ] `README.md` / `README.en.md`: version and channel claims (`@latest` is what it says it is), no `@next` install line unless a pre-release is being announced as such.
-- [ ] `SKILL.md` §0.5 install line and `docs/v2/guide/01-quickstart.md` / `08-migration-v1.md` install lines: stable channel.
+- [ ] `SKILL.md` §0.5 install line and `docs/v2/guide/01-quickstart.md` install line: stable channel.
 - [ ] `docs/CLI.md` status line, `docs/CAPABILITY-MATRIX.md` status line and distribution section.
 - [ ] Active RFC / plan documents whose channel policy the release changed get a dated "生效修订" note; history keeps its original text.
 - [ ] GitHub repository About (description, topics, homepage) still describes the product that was just released — cannot be checked from the repository, do it by hand.

package/docs/v2/RFC-0001-product-definition.md

@@ -50,6 +50,8 @@ v1 的"Skill-only 完整等价"拆成两个承诺（[`V2-PLAN.md`](../V2-PLAN.md
 
 ## 6. v1 的地位
 
+> **生效修订（2026-09-09）**：3.0.0 起 v1 文件总线、生命周期命令（`buildbeat doctor/init/adopt/upgrade`）、`solobaton` 与 `buildbeat-v2` 可执行文件全部移除，`buildbeat` 即运行时；`v1-maintenance` 维护线结束，最后一个带 v1 的版本是 2.0.2。本节原文保留为决策记录。
+>
 > **生效修订（2026-09-05）**：下段"`latest` 留 v1"是 beta 期策略，已按计划结束——`@haiyangbg/buildbeat@2.0.0` 于 2026-09-05 发布到 `latest`（[`CHANGELOG.md`](../../CHANGELOG.md)、[发布证据](../V2.0.0-RELEASE-EVIDENCE-2026-09-05.md)）。此后 `latest` = v2 系列，`next` 仅用于后续预发布；v1 生命周期命令随同一个包分发，v1 骨架版本仍是 v1.21。原文保留为决策记录。
 
 v1 进入 `v1-maintenance` 维护线，只修安全与严重缺陷；npm `latest` 留 v1，`next` 发 v2 预发布；Beta 前 `latest` 不指向 v2。v1 迁移采用半天手工 runbook（装机量 N=1），`migrate-v1` importer 已裁掉（收尾修正三）。旧概念的保留/转换/删除逐项见 [`RFC-0002`](RFC-0002-domain-model.md) §8。

package/docs/v2/RFC-0003-workflow-policy.md

@@ -159,6 +159,8 @@ review 修复轮次：2
 | `controlled` | Intent、Plan、Merge、Release |
 | `legacy-four-gates` | v1 四 Gate 完整形态（迁移用） |
 
+> **生效修订（2026-09-09）**：`legacy-four-gates` 预设随 v1 于 3.0.0 移除；上行保留为原文。
+
 ## 8. observe 预设与 bands schema（随本 RFC 冻结，实现 M5）
 
 裁决 #6：**接口现在冻结，实现推后**。冻结内容为以下 schema 形状与语义；M5 前不实现，但 M1 起任何内核设计不得与之冲突（尤其：Evidence Provider 产出的记录必须能进入同一 Evidence Contract 与事件台账）。

package/docs/v2/guide/00-how-to-talk.md

@@ -1,6 +1,6 @@
 # 怎么和装了 BuildBeat 的会话说话（按项目阶段）
 
-> 这是给**用户**看的一页。你在任意一个 AI 编程会话里工作（哪家工具都可以，一个会话就够），会话装载了 BuildBeat Skill；你说人话，它去调 `buildbeat-v2`、读输出、按「已做 → 未做 → 下一步」回你。**你不需要记任何命令**。下面的例句就是平时的说法，照抄即可；同一格里的几句话意思相同，挑顺口的。
+> 这是给**用户**看的一页。你在任意一个 AI 编程会话里工作（哪家工具都可以，一个会话就够），会话装载了 BuildBeat Skill；你说人话，它去调 `buildbeat`、读输出、按「已做 → 未做 → 下一步」回你。**你不需要记任何命令**。下面的例句就是平时的说法，照抄即可；同一格里的几句话意思相同，挑顺口的。
 > 会话侧的对应规则在 `SKILL.md` §0.5；项目专属的路由与红线在各项目根的 `AGENTS.md`。
 
 准备换会话时说「把关键上下文落盘,我要关闭旧会话」;新会话说「读取项目入口,核对进度与待批,继续这个工作」。交给同事时说「同步项目记录与候选,让接手成员核对当前范围和原 Run 所在环境」。详细步骤与活动 Run 的保留范围见 [跨会话与团队接续](11-session-handoff.md)。
@@ -10,7 +10,7 @@
 | 阶段 | 你想干什么 | 你就这么说 | 会话背后做什么 | 你会得到什么 / 注意 |
 |---|---|---|---|---|
 | **0. 未开始** | 判断值不值得上 BuildBeat | 「这个项目适合用 BuildBeat 吗」 | 看仓库规模、周期、仓/部署单元/会话数 | 一句判断：多期迭代 / 多仓 / 多会话才值得；一周收尾的小活直接干 |
-| | 新项目搭骨架 | 「帮我用 BuildBeat 搭一下这个项目」「初始化协作骨架」 | 自查代码 → 少量提问（栈、仓、部署单元、有没有 UI）→ 一屏确认 → 生成 `AGENTS.md`（v2 模板）、`delivery/`、`.buildbeat/observe.yaml`、`.buildbeat/notify.yaml`、`scripts/bus-check.sh`、pre-commit | 一屏确认单，你说「可以」它才写；生成后给文件清单 |
+| | 新项目搭骨架 | 「帮我用 BuildBeat 搭一下这个项目」「初始化协作骨架」 | 自查代码 → 少量提问（栈、仓、部署单元、有没有 UI）→ 一屏确认 → 生成 `AGENTS.md`、`delivery/`（含信封）、`.buildbeat/observe.yaml`、`.buildbeat/notify.yaml`、gitleaks pre-commit | 一屏确认单，你说「可以」它才写；生成后给文件清单 |
 | | 接管老项目 | 「给这个老项目套上 BuildBeat」「接管这个仓」 | 摸底（测试、契约、部署事实）→ 划绞杀边界（新地盘 / 老地盘 / 只读）→ 第 0 期补最小验证 | 摸底报告 + 边界草案，你拍板边界；历史不回改 |
 | | 装上通知 | 「Run 停下来时通知我」 | 写 `.buildbeat/notify.yaml`（钉钉 / webhook） | 它告诉你要建什么机器人、`export` 哪个环境变量；URL 永远不进 Git |
 | **1. 立项 · 定方案** | 立一件事 | 「开个 Work：〔一句话目标〕」「把当前目标收成一个 Work」 | 写 `delivery/work/<ID>/intent.md`（为什么做、做到什么算完）+ `plan.md`（怎么做、分几步）+ `run-config.yaml` | 摘要 + 「看完说接受」；你说「接受」才 digest 绑定生效 |
@@ -31,7 +31,7 @@
 | | 停下来 | 「这次再不成功就停」「先停下来」 | 封顶轮数；`stop --reason` 记账，候选与证据保留 | 已做 / 未做 / 下一步，带 hash；之后由你决定改方案、手工修还是关掉 Work |
 | **4. 验收 · 合并** | 验收 | 「验收」「验 RUN-X 候选」 | 测试视角对精确 candidate 独立核验，报告落 Work 目录 | 通过 / 不通过 + 证据；写者的话不算证据 |
 | | 合并 | 「merge 吧」「授权 push」 | 人类动作由会话代执行（在 `AGENTS.md` 红线内），回读远端 | 报合并后 hash；`overview` 显示 MERGED |
-| **5. 上线** | 上线 | 「上线」「准备 Gate4」 | `release-readback` 预设 + `riskPreset: release`：先回读 → 停下来 | 「回读全绿，现在轮到你做〔动作〕；做完说一声」 |
+| **5. 上线** | 上线 | 「上线」「准备上线」 | `release-readback` 预设 + `riskPreset: release`：先回读 → 停下来 | 「回读全绿，现在轮到你做〔动作〕；做完说一声」 |
 | | 我做完了 | 「做完了」「做到一半了，你核一下」 | 批准 apply-readback → 回读 + 观察 → 停关窗 | 差什么逐条说；任一步失败即停 |
 | | 拍上线卡 | 「批准上线」「先不上线」 | 按决策卡执行 / 不执行 | 生产动作永远是你的；它只回读和记账 |
 | | 生产报警 | 「生产有报警」「体检一下」 | `observe run` → 草稿入队 | 草稿一句 + 「fix_now / schedule / dismiss 你选」 |

package/docs/v2/guide/01-quickstart.md

@@ -8,10 +8,10 @@
 
 ```bash
 npm install --global @haiyangbg/buildbeat@latest
-buildbeat-v2 | head -3    # 打印 "BuildBeat v2 runtime" 与用法即安装成功
+buildbeat | head -3    # 打印 "BuildBeat v2 runtime" 与用法即安装成功
 ```
 
-2.0.0 起 `@latest` 就是 v2；同一个包同时给出 `buildbeat`（v1 生命周期命令：doctor / init / adopt / upgrade）和 `buildbeat-v2`（本文用的运行时）。预发布才用 `@next`。要求 Node ≥ 20、Git、bash，零运行时依赖。
+稳定版走 `@latest`，可执行文件只有一个：`buildbeat`（本文用的运行时）。预发布才用 `@next`。要求 Node ≥ 20、Git、bash，零运行时依赖。
 
 > 下文用到的 `templates/v2/envelope/` 与 run 配置 `env:` 透传修复自 2.0.1 起随包分发。装好后确认 `$(npm root -g)/@haiyangbg/buildbeat/templates/v2/envelope/` 存在再继续；不存在说明装到的是 2.0.0，先 `npm install --global @haiyangbg/buildbeat@latest` 更新。
 
@@ -96,7 +96,7 @@ workers:
 `standard` 预设在 build 前要求 plan 是已接受工件（`controlled` 还要求 intent）。接受是 digest 绑定的：接受后改了 plan，接受自动过期，`doctor` 会报 `stale`。
 
 ```bash
-buildbeat-v2 accept --repo . --work WORK-DEMO-1 --artifact plan --by <你的名字>
+buildbeat accept --repo . --work WORK-DEMO-1 --artifact plan --by <你的名字>
 ```
 
 成功：打印 `accepted plan as A-WORK-DEMO-1-<n>` 与 `digest: sha256:…`。
@@ -104,7 +104,7 @@ buildbeat-v2 accept --repo . --work WORK-DEMO-1 --artifact plan --by <你的名
 ## 4. doctor：起跑前把 start 会读的事实读一遍
 
 ```bash
-buildbeat-v2 doctor --config delivery/work/WORK-DEMO-1/run-config.yaml
+buildbeat doctor --config delivery/work/WORK-DEMO-1/run-config.yaml
 ```
 
 逐段核对：`policies` 每条的 declared 与 actual 强制等级；`worker isolation` 每个 worker 是 `env allowlist` 还是 `WARNING inherit`；`push protection`；每步预算；`work artifacts` 里 intent / plan 是否存在、是否已接受、是否 stale，以及"start 会停在哪一步"的预告。有 `WARNING` 不代表不能跑，但要知道它意味着什么；退出码 0 不等于全部就绪。
@@ -112,7 +112,7 @@ buildbeat-v2 doctor --config delivery/work/WORK-DEMO-1/run-config.yaml
 ## 5. 起 Run，停在人批
 
 ```bash
-buildbeat-v2 start --config delivery/work/WORK-DEMO-1/run-config.yaml --attempt new
+buildbeat start --config delivery/work/WORK-DEMO-1/run-config.yaml --attempt new
 ```
 
 `--attempt new` 自动编号 `RUN-DEMO-01/02…`，并作废同一 Work 下仍在等人的旧 Run。Runner 会：开隔离 worktree（分支 `run/RUN-DEMO-01`，对配置 remote 的 push 已被封禁）→ builder 产出提交并固定 candidate → verifier 真实跑测试（退出码回读为证据）→ reviewer 只读出结构化 findings → 到达 `WAITING_HUMAN`。
@@ -124,15 +124,15 @@ buildbeat-v2 start --config delivery/work/WORK-DEMO-1/run-config.yaml --attempt
 ## 6. 看证据、拍板
 
 ```bash
-buildbeat-v2 overview --repo .                       # 每个 Work 走到哪、下一步该谁、花了多少
-buildbeat-v2 inbox --repo .                          # 等你批的 Run，每条附可复制的下一句命令
-buildbeat-v2 status --repo . --run RUN-DEMO-01       # 步、耗时、证据、findings、待批理由
+buildbeat overview --repo .                       # 每个 Work 走到哪、下一步该谁、花了多少
+buildbeat inbox --repo .                          # 等你批的 Run，每条附可复制的下一句命令
+buildbeat status --repo . --run RUN-DEMO-01       # 步、耗时、证据、findings、待批理由
 ```
 
 批之前先看：候选 SHA、verify 的退出码与日志、review 的每条 finding。然后按 `inbox` 给出的那一句执行，通常是：
 
 ```bash
-buildbeat-v2 approve --repo . --run RUN-DEMO-01 --transition enter-wait-merge --by <你的名字> --config delivery/work/WORK-DEMO-1/run-config.yaml
+buildbeat approve --repo . --run RUN-DEMO-01 --transition enter-wait-merge --by <你的名字> --config delivery/work/WORK-DEMO-1/run-config.yaml
 ```
 
 **批的是哪一步要分清**（[Approval 指南](07-approval-guide.md)）：`enter-wait-merge` 是合并决定，Run 进终态 `SUCCEEDED`，表示候选具备合并条件——真正的合并、push、发布永远是你在 Runner 之外的动作；`enter-fix` / `resume-<step>` 是非终态转换，批准后要 `resume --config …` 让它续跑。被 findings 阻断时会自动路由 fix→verify→review 重走，超预算或失败指纹重复则停下交还给你（[Recovery](10-recovery.md)）。
@@ -153,9 +153,9 @@ buildbeat-v2 approve --repo . --run RUN-DEMO-01 --transition enter-wait-merge --
 
 ```bash
 cp "$(npm root -g)/@haiyangbg/buildbeat/src/v2/presets/observe.yaml" .buildbeat/observe.yaml   # 改成项目真实探针
-buildbeat-v2 observe run --config .buildbeat/observe.yaml            # 一次=一个周期；周期化交给 cron
-buildbeat-v2 observe status --repo .
-buildbeat-v2 observe triage --repo . --intent delivery/observe/intents/INTENT-<fp>.md --action fix_now --by <你>
+buildbeat observe run --config .buildbeat/observe.yaml            # 一次=一个周期；周期化交给 cron
+buildbeat observe status --repo .
+buildbeat observe triage --repo . --intent delivery/observe/intents/INTENT-<fp>.md --action fix_now --by <你>
 ```
 
 探针失败/采不到 → 证据 `failed`/`unverified` → bands 分层（记录→只读诊断→Intent 草稿入队）。草稿**绝不自动执行**；`dismiss` 会回调阈值，同指纹在严重度升级前不再打扰。详见 [Evidence 指南](06-evidence-guide.md) §observe。

package/docs/v2/guide/03-policy-guide.md

@@ -50,4 +50,4 @@ rule:
 
 ## 接入
 
-run 配置 `policies:` 列表引用文件路径；risk 预设（`fast`/`standard`/`controlled`/`legacy-four-gates`）自带一组策略与停点，`riskPreset:` 一行即可启用，再叠加项目自定义策略。
+run 配置 `policies:` 列表引用文件路径；risk 预设（`fast`/`standard`/`controlled`/`release`）自带一组策略与停点，`riskPreset:` 一行即可启用，再叠加项目自定义策略。

package/docs/v2/guide/06-evidence-guide.md

@@ -14,7 +14,7 @@
 | `failed` | 非零退出 / 超时 / 信号 |
 | `unverified` | **采不到**：无法启动、数据缺失。永远不是"没问题" |
 
-`unverified` 不会被任何门当作通过（[Policy 指南](03-policy-guide.md) 三值逻辑）。这是 v1 fail-closed 文化的内核化。
+`unverified` 不会被任何门当作通过（[Policy 指南](03-policy-guide.md) 三值逻辑）。fail-closed 是内核语义，不是约定。
 
 ## 等级 L0–L4
 
@@ -24,7 +24,7 @@
 
 ## 预检 ≠ 证据
 
-`buildbeat-v2 preflight --config <run-config> --step <id>`：在主 checkout 直接干跑某步的 worker 命令——无 worktree、无台账、不落任何证据（输出自带 `PREFLIGHT (dry signal, never evidence)` 横幅，环境变量 `BUILDBEAT_PREFLIGHT=1`）。用途是分钟级循环打到首个失败边界再进 Run（战役里 harness 缺陷每个要烧一整轮 Run，预检模式一晚拆完）；**预检发现的任何东西必须由 Run 复现才算数**。
+`buildbeat preflight --config <run-config> --step <id>`：在主 checkout 直接干跑某步的 worker 命令——无 worktree、无台账、不落任何证据（输出自带 `PREFLIGHT (dry signal, never evidence)` 横幅，环境变量 `BUILDBEAT_PREFLIGHT=1`）。用途是分钟级循环打到首个失败边界再进 Run（战役里 harness 缺陷每个要烧一整轮 Run，预检模式一晚拆完）；**预检发现的任何东西必须由 Run 复现才算数**。
 
 ## 候选作用域
 
@@ -41,7 +41,7 @@
 
 ## 完整率
 
-`buildbeat-v2 metrics` 输出证据完整率（有证据的步/应有证据的步）；M4/M5 退出线 ≥95%，试点实测 100%。
+`buildbeat metrics` 输出证据完整率（有证据的步/应有证据的步）；M4/M5 退出线 ≥95%，试点实测 100%。
 
 ## 运行中的读数 ≠ 证据
 

package/docs/v2/guide/07-approval-guide.md

@@ -9,11 +9,11 @@
 ## 日常操作
 
 ```bash
-buildbeat-v2 inbox --repo .                 # 所有等人的 Run：transition、candidate、digest、理由
-buildbeat-v2 status --repo . --run RUN-X    # 单个 Run 的完整派生视图（步、证据、findings）
-buildbeat-v2 approve --repo . --run RUN-X --transition enter-wait-merge --by <名字> --config <run-config>
-buildbeat-v2 reject  --repo . --run RUN-X --reason "<为什么>" --by <名字>
-buildbeat-v2 accept  --repo . --work WORK-X --artifact plan --by <名字>   # 工件接受（digest 绑定）
+buildbeat inbox --repo .                 # 所有等人的 Run：transition、candidate、digest、理由
+buildbeat status --repo . --run RUN-X    # 单个 Run 的完整派生视图（步、证据、findings）
+buildbeat approve --repo . --run RUN-X --transition enter-wait-merge --by <名字> --config <run-config>
+buildbeat reject  --repo . --run RUN-X --reason "<为什么>" --by <名字>
+buildbeat accept  --repo . --work WORK-X --artifact plan --by <名字>   # 工件接受（digest 绑定）
 ```
 
 决定落 Git 面 `delivery/work/<id>/decisions.jsonl`，事件台账同步记 `DECISION_RECORDED`。
@@ -41,7 +41,7 @@ buildbeat-v2 accept  --repo . --work WORK-X --artifact plan --by <名字>   #
 
 ## 人批点由 Risk Preset 决定
 
-`fast` 仅 Merge；`standard` Plan+Merge；`controlled` Intent+Plan+Merge+Release；`legacy-four-gates` 为 v1 四 Gate 完整形态（迁移期用，见 [迁移指南](08-migration-v1.md)）。待批项强制携带 findings 摘要与理由——防"秒批"退化；人批等待时长进 `metrics`。
+`fast` 仅 Merge；`standard` Plan+Merge；`controlled` Intent+Plan+Merge+Release。待批项强制携带 findings 摘要与理由——防"秒批"退化；人批等待时长进 `metrics`。
 
 ## 发现分诊门与锚定审查
 
@@ -52,8 +52,8 @@ buildbeat-v2 accept  --repo . --work WORK-X --artifact plan --by <名字>   #
 2. **裁决台账**：finding 全部落 Git 面 `delivery/work/<id>/review-findings.jsonl`（指纹 = 严重度+正文规范化 hash）：
 
    ```bash
-   buildbeat-v2 findings list --repo . --work WORK-X
-   buildbeat-v2 findings adjudicate --repo . --work WORK-X --fingerprint <fp> --action dismiss --by <名字> --note "<为什么>"
+   buildbeat findings list --repo . --work WORK-X
+   buildbeat findings adjudicate --repo . --work WORK-X --fingerprint <fp> --action dismiss --by <名字> --note "<为什么>"
    ```
 
    `dismiss` 后同指纹不再阻断（重提会以 `RE-RAISED` 记账可见，但不重启循环）；**严重度升级=新指纹，自动重新阻断**——压噪不压真信号，与 observe 的 dismiss 回调同一原则。
@@ -90,7 +90,7 @@ buildbeat-v2 accept  --repo . --work WORK-X --artifact plan --by <名字>   #
 ## 从「等我批」到「到哪了」：overview
 
 > 自 2.0.0-beta.4（迭代 08）起。
-`inbox` 只知道哪个 Run 在等人；`buildbeat-v2 overview --repo .` 按 Work 回答「走到哪、下一步该谁」——intent/plan 是否被接受（接受后改过即 `stale`）、最新 Run 状态与候选、候选是否已合入当前分支、未裁决 P0/P1 数、是否有 `env-facts.md`，每行附下一句命令。运行时被删后由 Git 面 run-record 补足。会话开场先跑它，再回答用户「当前进度」。
+`inbox` 只知道哪个 Run 在等人；`buildbeat overview --repo .` 按 Work 回答「走到哪、下一步该谁」——intent/plan 是否被接受（接受后改过即 `stale`）、最新 Run 状态与候选、候选是否已合入当前分支、未裁决 P0/P1 数、是否有 `env-facts.md`，每行附下一句命令。运行时被删后由 Git 面 run-record 补足。会话开场先跑它，再回答用户「当前进度」。
 
 **阶段判定的真相修正（迭代 09）**：候选只要合入了当前分支，Work 就是 `MERGED`，哪怕最新 Run 是 CANCELLED（试点一条应用登录 Run 因预算问题被取消，候选却已在生产，overview 曾报 `STOPPED_CANCELLED` 并催重试）；`release-readback` 车道成功关窗的 Work 显示 `RELEASED`，不再说 "nothing to merge"；已合并 / 已发布 / 已关闭的 Work 不再提示未裁决 finding 数。`overview` 每个 Work 还多一行 `cost:`（见 [Workflow 指南](02-workflow-guide.md) 的 Work 级预算）。
 
@@ -100,7 +100,7 @@ buildbeat-v2 accept  --repo . --work WORK-X --artifact plan --by <名字>   #
 Run 停在 `enter-fix` / `resume-fix` 时，驾驶会话或人常常已经在 Run 的 worktree 里把问题修掉并提交了。此时再 `approve` 会派一个无事可做的 fixer，再多跑一次 verify（试点一条前端 Run 因此跑到 verify 第 5 次、fix 第 3 次）。改用：
 
 ```bash
-buildbeat-v2 resume --config <run-config.yaml> --adopt <sha> --by <名字>
+buildbeat resume --config <run-config.yaml> --adopt <sha> --by <名字>
 ```
 
 内核回读 worktree：树必须干净、HEAD 必须就是 `<sha>`（前缀 7 位起），否则拒绝；然后以人为 actor 落 `CANDIDATE_PINNED`（`adopted: true`）、以该提交为 subject 记 `DECISION_RECORDED`（`adopted`、`resumeAt`），并从 verify 继续（预设里 fix 成功后的下一步）。台账里看得出这一版候选是谁供的。合并决定处不接受 adopt。

package/docs/v2/guide/10-recovery.md

@@ -8,14 +8,14 @@
 
 `status`/`inbox` 出现 `LEDGER CORRUPTED after seq=N (<原因>)`：台账在最后一条合法事件处截断视图并**拒绝追加**——恢复是人的决定，不静默修复。
 
-1. `buildbeat-v2 events --repo . --run RUN-X` 看合法前缀；`replay` 校验归约；
+1. `buildbeat events --repo . --run RUN-X` 看合法前缀；`replay` 校验归约；
 2. 若坏的是在途 Run：通常直接废弃该 Run（worktree 里的候选仍在分支上可读），新起一个 Run；
 3. 若人为改过台账文件：从 Git 面事实重建判断，不要手补事件行。
 
 ### Run 进程被杀 / 机器重启
 
 ```bash
-buildbeat-v2 resume --config <run-config.yaml>
+buildbeat resume --config <run-config.yaml>
 ```
 
 在途步会以 `crashed` 关闭（事实落账），然后**重跑该步本身**（beta.3 改）：进程死掉不说明候选有问题，丢失的那次尝试照常计入该步预算，预算耗尽即停人工。此前的语义是把 crash 当步骤失败走 failure 边——真实事故（deploy-18）：宿主工具超时杀掉 verify worker，crash 被路由去 fix，fixer 面对零 verifier 证据白烧一轮。工作树脏了仍然先停人工。带批准恢复时会做 candidate/plan 新鲜度检查，变了即 `APPROVAL_STALE` 转人工。恢复不了就删 runtime 重跑——候选分支与 Git 面记录不丢。
@@ -27,7 +27,7 @@ buildbeat-v2 resume --config <run-config.yaml>
 上一个 Run 异常退出可能留下仓库锁：确认真的没有活动 Run 后
 
 ```bash
-buildbeat-v2 stop --repo . --run RUN-X --reason "crashed; releasing lock"
+buildbeat stop --repo . --run RUN-X --reason "crashed; releasing lock"
 ```
 
 `stop` 落终态与理由；单纯锁残留也可删 `.buildbeat/runtime/` 后重来。
@@ -55,12 +55,12 @@ rm -rf .buildbeat/runtime/
 
 ## 诊断入口
 
-`buildbeat-v2 doctor --config <run-config>`：配置可解析、workflow 无出口环、adapter env 姿态、digest 可算、supersede 与 stall 阈值、通知通道与环境变量是否就位。`events`/`replay`/`metrics` 全部只读，可随时跑。
+`buildbeat doctor --config <run-config>`：配置可解析、workflow 无出口环、adapter env 姿态、digest 可算、supersede 与 stall 阈值、通知通道与环境变量是否就位。`events`/`replay`/`metrics` 全部只读，可随时跑。
 
 ## "是不是卡住了"
 
 > 自 2.0.0-beta.4（迭代 08）起。
-先看 `buildbeat-v2 status --repo . --run <RUN>`：在飞步骤有已用时间、同仓历史中位数、worker 命令、最后一次输出距今多久与末三行输出。无输出超过阈值（默认 15 分钟，`--stall-after <分钟>` 或 run 配置 `stallAfterMs`）标 `STALLED`——**只标不杀**。判断口径：
+先看 `buildbeat status --repo . --run <RUN>`：在飞步骤有已用时间、同仓历史中位数、worker 命令、最后一次输出距今多久与末三行输出。无输出超过阈值（默认 15 分钟，`--stall-after <分钟>` 或 run 配置 `stallAfterMs`）标 `STALLED`——**只标不杀**。判断口径：
 
 - 有输出在持续 → 等（对照 `typical` 看是否已远超中位数）；
 - STALLED 且 worker 是 Agent CLI → 多半在长推理或等一个永远不来的交互，`stop --reason` 后按崩溃恢复重跑（中断的步重跑自身）；
@@ -71,7 +71,7 @@ rm -rf .buildbeat/runtime/
 ## 打扫卫生：gc
 
 > 自 2.0.0-beta.4（迭代 08）起。
-终态 Run 会留下工作树、`run/*` 分支和偶尔的锁。`buildbeat-v2 gc --repo .` 默认只出计划，`--apply true` 执行：
+终态 Run 会留下工作树、`run/*` 分支和偶尔的锁。`buildbeat gc --repo .` 默认只出计划，`--apply true` 执行：
 
 - 只动**终态且已压成 run-record** 的 Run（Git 面有账才动运行时面）；
 - 工作树可删（提交都在分支上）；脏工作树不带 `--force true` 不动；

package/docs/v2/guide/11-session-handoff.en.md

@@ -28,8 +28,8 @@ Open a fresh session in the **same project directory**. Load the BuildBeat Skill
 The session reads current facts first:
 
 ```bash
-buildbeat-v2 overview --repo .
-buildbeat-v2 inbox --repo .
+buildbeat overview --repo .
+buildbeat inbox --repo .
 ```
 
 It then reads the goal, plan, decisions, and configuration under the relevant `delivery/work/<ID>/`. For active Run details, use `status --repo . --run <RUN-ID>`. Read IDs from actual output rather than guessing from a conversation.

package/docs/v2/guide/11-session-handoff.md

@@ -28,8 +28,8 @@ BuildBeat 的接续依据是项目文件、Git 与运行台账。新会话读取
 会话先读当前事实：
 
 ```bash
-buildbeat-v2 overview --repo .
-buildbeat-v2 inbox --repo .
+buildbeat overview --repo .
+buildbeat inbox --repo .
 ```
 
 随后读取对应 `delivery/work/<ID>/` 的目标、计划、决定和配置；需要活动 Run 细节时运行 `status --repo . --run <RUN-ID>`。ID 从实际输出读取，不凭聊天猜。

package/docs/v2/guide/README.md

@@ -31,10 +31,4 @@
 | [Worker 合同](05-worker-contract.md) | 输入输出信封（`severity` + `summary`）、阻断语义、各角色纪律、包装脚本 |
 | [安全与权限边界](09-security-boundaries.md) | 内核实际做到的 vs 不能由此推出的；无人值守三层前置条件 |
 
-## 迁移
-
-| 文档 | 一句话 |
-|---|---|
-| [v1 迁移指南](08-migration-v1.md) | 升级 CLI 与迁移项目状态分开；手工 runbook，单向迁移不双写 |
-
 observe v0（探测→分层响应→Intent 草稿→人分诊）在 [快速开始 §9](01-quickstart.md) 与 [Evidence 指南](06-evidence-guide.md) 中覆盖；schema 冻结见 [`RFC-0003 §8`](../RFC-0003-workflow-policy.md)。