@aibyzero/byz 0.1.1 → 0.1.2

package/workflows/cm-plugin/commands/cm-plugin-ai-nodes/N6-qa-eval.md

@@ -0,0 +1,69 @@
+# N6: QA 评估
+
+AI 动态决策是否触发 `cm-plugin-qa-engineer`，不按固定间隔。
+
+## 评分（1-5 分，总分 ≥ 8 触发）
+
+| 维度     | 1 分                 | 5 分                  |
+| -------- | -------------------- | --------------------- |
+| 变更范围 | 单文件小改动         | 跨多模块/多项目       |
+| 风险等级 | 纯 UI 文案           | 权限/manifest/认证/支付 |
+| 累积变更 | 上次 QA 后 1 个 task | 上次 QA 后 5+ 个 task |
+| 功能边界 | 模块内部实现         | 完整用户可感知功能    |
+
+## 必须触发（无需打分）
+
+- 当前 feature 所有 task 完成
+- API 接口变更（**收尾合并豁免**：下一个任务就是本 feature 最后一个任务时，可合并至 feature 级 QA 一次执行——避免背靠背双跑全量；合并决策记运行日志 `decision` 事件。实跑教训：后端 feature 几乎每任务都改 API,逐任务触发 QA 成本失衡）
+- manifest.json 变更（permissions / host_permissions / content_scripts 匹配范围 / CSP）
+- 认证/授权/支付逻辑
+- 数据存储结构变更（chrome.storage schema、IndexedDB、后端 migration）
+- 连续 5 个 task 未触发过 QA
+
+## 跳过
+
+- 纯文档/注释/配置格式
+- 仅新增类型定义（未实现）
+- 上一个 task 刚触发过 QA 且当前变更极小
+
+**跳过也必须留痕**：无论触发还是跳过，每个任务的 N6 结论都写一条 `qa` 事件进运行日志（`触发:原因` / `跳过:评分{N}` / `合并至feature级`）——cm-plugin:ai 必记事件本就含 qa，此处重申是因为实跑失守：json-keeper 7 个任务 0 条 qa 事件，N6 被整场静默绕过，连"连续 5 个 task 未触发"的必触发条款命中了都无人知晓。**不可见的跳过等于没有 N6**
+
+## 触发格式
+
+```text
+🧪 触发 QA — 原因: {理由}
+   累积变更: {N} 个 task | 风险评估: {总分}
+```
+
+QA 通过 → 继续。发现问题 → 修复后重新 QA，最多 3 轮。
+
+**QA 新补的测试须变异自证**(机械,非审查轮):种 1-2 处行为变异必须变红,不红的测试修到红再入库——QA 测试是未来所有回归的安全网,安慰剂 QA 测试 = 永久性假安心(实跑先例:dogfood 中 QA agent 自发做过「5 个变异全被抓」,本条把自觉变成规则)。
+
+触发 QA 后，回填 METRICS.md 中对应任务行的 QA 列：`通过(覆盖率{x}%)` / `{N}轮通过(覆盖率{x}%)` / `失败上报`——覆盖率随列落盘，不留在会话里。
+
+## 形态确认卡点（仅 0.bootstrap 完成时，一次性）
+
+`0.bootstrap` 完成触发的 QA 中，**必须**执行形态确认：把构建产物**以解包扩展形式加载进真实浏览器**（`chrome://extensions` 开发者模式 Load unpacked，或 Playwright/Puppeteer 带 `--load-extension` 启动），截取扩展实际界面发给用户——
+
+```text
+📸 形态确认：这是插件当前的形态（{popup 弹窗 / side panel / options 页 / content script 注入效果}），与你要的交付形态一致吗？
+```
+
+**截图来源必须是浏览器里真实加载的扩展**（防"替代形态截图糊弄卡点"）：
+
+- popup/options/side panel → 扩展加载后打开对应界面截图；**dev server 里直接打开 popup.html 的浏览器标签页截图不作数**——脱离扩展上下文渲染的页面拿不到 `chrome.*` API，恰恰掩盖形态错配
+- content script → 打开一个匹配 `matches` 规则的真实页面，截注入效果
+- 构建产物加载报错（manifest 无效、service worker 注册失败）→ 这本身就是形态确认不通过
+
+浏览器环境不可用 → 如实上报，请用户在本机加载确认；**不得用非扩展上下文的截图过卡点**。
+
+**用户确认后才进入业务 feature**。成本是一张截图 + 3 秒确认；收益是架构错配的发现时点从"任务过半"提前到"零行业务代码"（历史事故：要 App 画成了 HTML，跑到一半才发现）。
+
+## 业务验收走查（feature 完成时）
+
+触发原因为「当前 feature 所有 task 完成」且 QA 通过后，调用 `cm-plugin-product-manager` skill 做**业务验收走查**（用户视角流程闭环 + AC 逐条对照，非技术测试）：
+
+- 小偏差 → 记录进走查报告，继续
+- 涉及需求本意的偏差 → 暂停问人，不自行认定"也可以"
+
+涉及**权限新增 / 用户数据收集 / 远程内容加载**的 feature，走查追加商店合规视角（由 `cm-plugin-qa-engineer` 的商店合规检查单执行：权限最小化、单一用途、隐私披露、禁远程代码）；**涉合规的偏差一律上报，不适用"小偏差放行"**——商店拒审的返工成本远高于一次确认。

package/workflows/cm-plugin/commands/cm-plugin-ai-nodes/N7-context.md

@@ -0,0 +1,23 @@
+# N7: 上下文管理
+
+## task 完成后
+
+**重读落盘文件即是"重载",不需要清上下文,更不需要停车**:
+
+- 当前 feature 的 specs(requirements.md、design.md、tasks.md)
+- `{SPECS_DIR}/LESSONS.md`
+- 代码项目的 `.claude/CLAUDE.md` + `.claude/rules/`
+
+重读完成后**直接继续下一个 task,不停车、不等用户、不以问句收尾**。
+
+> 历史版本此处要求"执行 /clear"——那是用户侧斜杠命令,AI 无法自行执行,写在这里的实际效果是每个任务结束都停下来等人敲命令,与本文件末行"全程自动继续"直接矛盾(实跑反馈:每个阶段都要人确认才走,根因即此)。现行 Claude Code 上下文过长会自动压缩,无需人工 /clear;**以磁盘为准重读 specs 才是防漂移的有效动作**——压缩摘要可能丢细节,落盘文件不会。
+
+## task 执行中
+
+察觉上下文被自动压缩过(前文变成摘要)→ 继续当前 task 前,重读本 feature 的 specs 与当前任务相关的 design 章节,以落盘文件校准记忆,不信摘要里的细节数字。
+
+## feature 完成后
+
+同上重读,直接进入下一个 feature。
+
+全程自动继续。**唯一合法停车点**:cm-plugin:ai 全局规则的灾难级清单 + 各节点显式卡点(入口闸/Codex 降级知情/形态确认/涉合规走查)——不在此列的停车都是违规。

package/workflows/cm-plugin/commands/cm-plugin-ai-nodes/N8-finish.md

@@ -0,0 +1,61 @@
+# N8: 完成
+
+所有 feature 的所有任务完成后：
+
+## 1. 调用 cm-plugin-doc-syncer
+
+调用 `cm-plugin-doc-syncer` skill 完成文档同步：
+
+- README 精炼更新（架构 + 业务 + 快速开始）
+- .claude/CLAUDE.md 和 rules/ 同步
+- specs CHANGELOG 按日期生成
+- 文档一致性验证
+
+## 1.5 代码库参考文档回写（存在时强制）
+
+`{项目根}/docs/codebase-context/` 存在时（skill 未安装但文档在 → 按 skill 文内的回写映射表手动执行，映射表就在文档同目录项目里；两者都无 → 跳过本步），按 `codebase-context` skill dev 模式步骤 3 的「变更类型 → 需更新文档」映射表，把本次全部 feature 的变更回写进参考文档（09-changelog 类型标 `dev回写`）——**地图必须跟着代码走，否则下次二开按过期地图改**。
+
+## 2. 生产发布待决清单
+
+**前置（与 cm-plugin:prd 的 T-012 生成条件同源）**：项目存在部署形态（Dockerfile / CI 配置 / 部署脚本，或 `{SPECS_DIR}/RELEASES.md` 已存在）才执行本步；**纯本地工具、库等无部署形态的项目 → 跳过**，总结中输出一行 `🚀 发布清单: 跳过(无部署形态)`——规格期没生成部署任务的项目，收尾也不该凭空编制发布清单（实跑教训：dogfood 中 RELEASES.md 不存在,数据源为空仍无条件调用）。
+
+调用 `cm-plugin-devops-engineer` skill **编制**（只编制，不执行生产发布）。**staging 验证状态的数据源是 `{SPECS_DIR}/RELEASES.md`**，不凭记忆：
+
+- 已通过 staging 验证的 feature 清单及版本（读 RELEASES.md）
+- 生产迁移清单与执行顺序（含备份点）
+- 新增环境变量清单（值由人在生产环境配置）
+- 回滚预案位置
+
+**生产发布由人决策触发**，不属于本流程的自动动作。
+
+## 3. 度量汇总
+
+读取 `{SPECS_DIR}/METRICS.md`，**只统计本次执行涉及的 feature 的行**（按 Feature 列过滤——防止历史批次数据混入本次门槛对照），全量历史另起一行标注"累计"。输出：
+
+```text
+📊 度量汇总
+任务: {N} 个 | 人工介入均值: {x} 次/任务 | 一次通过率(复审仅1轮): {x}%
+Codex 拦截: 共 {N} 条 | QA: 触发 {N} 次/通过 {N} | 总耗时: {x}
+💰 成本: 请运行 /cost 并把本次会话费用回填到下面度量汇总的成本行
+```
+
+**审查凭证对账**：tasks.md 全部 `[x]` 任务 ↔ `{SPECS_DIR}/.reviews/` 凭证一一对账，缺失项列入度量汇总（`⚠ 审查凭证缺失: T-xxx,...`，全齐则 `审查凭证: {N}/{N} 齐`）——中途漏网的审查，收尾必须暴露，不许无声混过。
+
+**运行日志收口**：追加 `done` 事件后，报告 `运行日志.jsonl` 的路径与行数（如 `📜 运行日志: {SPECS_DIR}/运行日志.jsonl · 共 {N} 行`）——提醒用户反馈工作流问题时连同 METRICS.md 一起带回。只报告，不清理不截断。
+
+**成本落盘（灰度门槛"单任务成本<人工工时"的数据源）**：输出汇总后提醒用户执行 `/cost`，将会话总费用与总耗时一起写入 `{SPECS_DIR}/度量汇总.md` 的成本行（`成本: ${x} / {N} 任务 ≈ ${x/N} 每任务`）。用户不回填则标注 `成本: 未采集`——宁可留空，不许编造。
+
+## 4. 输出总结
+
+```text
+🎉 全部完成
+
+📂 Features: {完成数}/{总数}
+📋 总任务: {完成数}/{总数}
+📝 文档同步: 已完成
+🚀 生产发布待决清单: 已编制，等待人工决策
+
+各 Feature 摘要:
+- 1.{name}: {N} 个任务 ✅ (staging 已验证)
+- 2.{name}: {N} 个任务 ✅ (staging 已验证)
+```

package/workflows/cm-plugin/commands/cm-plugin-prd-modes/brownfield.md

@@ -0,0 +1,13 @@
+# cm-plugin:prd 模式文件 — 二开模式（B2–B5）
+
+> 由 /cm-plugin:prd Step 4 判定「存量项目且本次需求会修改存量代码」时读取本文件。B1(加载参考文档)保留在主文件 Step 4。规则内容与主文件同源拆分,语义未变。
+
+**二开模式追加规则（GREENFIELD=false 且本次需求会修改存量代码时生效）**：
+
+- **B2 波及面分析**：对每个将被修改的存量模块，基于参考文档（03-architecture 模块关系 / 04-api-routes 调用方 / 07-business-logic 线路）+ Grep 核实，在 design.md 写「波及面」段：改哪里 → 谁调用它 → 哪些老功能可能受影响。**波及面是 QA 回归范围的数据源**
+- **B3 防护网任务**：凡 tasks.md 中包含"修改存量模块"的 feature，第一个任务固定为**防护网基线**。**项目已有测试资产**（jest/vitest 等且可运行）→ 基线 = 跑通存量全量测试并记录结果，**不重复造快照**（实跑验证：184 用例的成熟项目直接复用，前后各跑一次）；**无测试资产** → 才写现状快照测试锁住将被修改模块的当前行为（不判断对错，只锁现状）。开发后复跑基线，变红即为碰坏老行为的信号
+- **B4 specs 只覆盖增量**：不为整个存量系统补规格；只为本次改动涉及的模块建规格，存量行为"用到哪、记到哪"（记进参考文档 07，而不是 specs）
+- **B5 拆分锚定地图**：feature 与任务的边界对齐业务地图，不凭感觉切——
+  - **feature 沿业务线路拆**（07-business-logic 的线路）：需求同时触及多条线路（如"行情展示"+"导出"）→ 按线路切成多个 feature，一条线路一个 feature
+  - **任务尽量单模块**（03-architecture 的模块关系）：一个任务的改动落在一个模块内；确需跨模块的任务，描述中显式列出涉及模块清单（审查与波及面据此聚焦）
+  - **地图盲区检测**：需求涉及的逻辑在 07 中找不到对应线路 → 说明地图有盲区，先对该区域增量补扫（scan 只读相关目录）再拆分——拆错边界的成本远高于补扫

package/workflows/cm-plugin/commands/cm-plugin-prd-modes/change-mode.md

@@ -0,0 +1,130 @@
+# cm-plugin:prd 模式文件 — 变更模式
+
+> 由 /cm-plugin:prd 模式判断检测到 `--change` 时读取本文件。规则内容与主文件同源拆分,语义未变。
+
+## 变更模式
+
+当输入 `/cm-plugin:prd --change {N}.{feature-name} 变更内容` 时执行。
+
+### Step C1: 定位已有 specs
+
+在 `{SPECS_DIR}/` 中查找匹配的编号目录。
+
+如果只传了序号（如 `--change 1`），自动匹配 `1.*` 目录。
+
+找不到则报错提示。
+
+### Step C2: 读取现有 specs
+
+读取该目录下的：
+
+- `requirements.md` — 当前需求
+- `design.md` — 当前设计
+- `tasks.md` — 当前任务（注意哪些已完成 `[x]`）
+
+### Step C3: 解析变更内容
+
+变更内容可以是：
+
+- 纯文本描述变更
+- 文件路径（新的需求文档）
+- URL
+
+### Step C4: 对比分析
+
+**调用 `cm-plugin-product-manager` skill 的变更影响分析**：除识别增删改外，评估波及哪些已完成任务（返工风险）、哪些验收标准失效。
+
+变更内容涉及**新增权限 / 扩大 host_permissions / 新收集用户数据 / 加载远程内容**时，同时做商店合规预扫（检查方法以 `cm-plugin-qa-engineer` 的商店合规检查单为准）：新引入的权限逐项给用途理由，合规问题并入变更摘要供人审——权限扩张类变更提审时会触发商店重新审核，人必须知情。
+
+将变更内容与现有 requirements.md 对比，识别：
+
+- **新增**的功能需求
+- **修改**的功能需求
+- **删除**的功能需求
+- 对验收标准的影响
+
+### Step C5: 更新 requirements.md
+
+- 在「需求版本」表中追加新版本行：
+
+```markdown
+## 需求版本
+
+| 日期       | 版本 | 说明             |
+| ---------- | ---- | ---------------- |
+| 2026-04-11 | v1   | 初始需求         |
+| 2026-04-15 | v2   | 新增微信登录方式 |
+```
+
+- 在功能需求中标注变更：
+
+```markdown
+## 功能需求
+
+1. [F-001] 邮箱 + 密码登录
+2. [F-002] 手机号 + 验证码登录
+3. [F-003] Tab 切换登录方式
+4. [F-004] ~~短信验证码 5 分钟过期~~ `[v2 删除]`
+5. [F-005] 微信扫码登录 `[v2 新增]`
+6. [F-006] 表单验证 `[v2 修改: 新增微信回调校验]`
+```
+
+### Step C6: 更新 design.md
+
+- 追加设计版本
+- 新增/修改受影响的功能模块设计
+- 不动未受影响的模块
+- 标注变更原因
+
+### Step C7: 更新 tasks.md
+
+- 追加任务版本
+- 已完成的任务 `[x]` 保持不动
+- 受变更影响的未完成任务标记 `[CHANGED]` 并更新描述
+- 因变更作废的任务标记 `[DROPPED]`
+- 新增的任务标记 `[NEW]`
+
+```markdown
+## 任务列表
+
+### 功能 1: 登录表单
+
+- [x] T-001: 创建登录页面和 Tab 切换组件 ~30min
+- [x] T-002: 实现邮箱登录表单 ~30min
+- [ ] T-003: 实现手机号登录表单 ~30min `[CHANGED v2: 去掉倒计时]`
+- [ ] ~~T-004: 短信过期逻辑~~ `[DROPPED v2]`
+
+### 功能 2: 微信登录 `[NEW v2]`
+
+- [ ] T-008: [NEW] 微信 OAuth 回调处理 ~30min
+- [ ] T-009: [NEW] 微信登录按钮组件 ~15min
+```
+
+### Step C8: 输出变更摘要
+
+```
+📝 需求变更: 1.user-auth v1 → v2
+
+新增: 2 个功能需求, 2 个任务
+修改: 1 个功能需求, 1 个任务
+删除: 1 个功能需求, 1 个任务
+未受影响: 3 个已完成任务保持不动
+
+请产品审查变更后，运行 /cm-plugin:ai 继续开发（会跳过已完成任务）
+```
+
+---
+
+## 示例用法
+
+```bash
+# 新建需求 — 提供项目文件夹路径，docs/ 下放需求文档
+/cm-plugin:prd ~/projects/my-app-specs
+/cm-plugin:prd /path/to/project-specs
+
+# 需求变更 — 同样基于项目文件夹，指定要变更的 feature
+/cm-plugin:prd --change 1.user-auth 新增微信扫码登录方式
+/cm-plugin:prd --change 2 ~/projects/my-app-specs
+```
+
+**审批位重置**：变更落盘后，将 `{SPECS_DIR}/.cm-specs-status` 重置为 `awaiting_review`——改过的规格等于没审过，N1 入口闸将再次要求确认。

package/workflows/cm-plugin/commands/cm-plugin-prd-modes/greenfield.md

@@ -0,0 +1,82 @@
+# cm-plugin:prd 模式文件 — 0→1 空项目分支（GREENFIELD）
+
+> 由 /cm-plugin:prd Step 3 判定 GREENFIELD=true 时读取本文件。规则内容与主文件同源拆分,语义未变。
+
+## 0→1 空项目分支（GREENFIELD）
+
+Step 3 检测到 `GREENFIELD=true` 时叠加以下规则。核心思想：**架构决策也是需求的产物，走同一条 specs 流水线**——选型即设计，搭建即任务，享受同样的人审卡点、断点恢复和审计链。
+
+### G1: 技术选型确认（并入 Step 5.5）
+
+**先读完需求再谈选型，推荐必须从需求特征推导，不套通用默认。** 流程：
+
+0. **交付表面必问（第一问，不可默认）**：本工作流交付形态固定为**浏览器扩展（MV3）**，但表面组合是架构第一分叉：popup / options / side panel / content script / devtools 面板 / 新标签页接管 / 纯后台——需求没写就必须问，答案强制写入 ADR 和 CLAUDE.md 的「交付形态」字段（如 `Chrome 扩展 · side panel + content script`）。同时必问**目标浏览器**：仅 Chrome / Chrome+Edge / 含 Firefox（决定是否引入 webextension-polyfill 与双 manifest）。**需求方说"做个插件"时脑中的画面千差万别，表面组合看错全错**
+1. **联网校验当前最佳实践**：确认表面组合后，WebSearch 当年扩展脚手架生态（WXT / Plasmo / CRXJS 迭代和维护状态变化快，不可凭记忆推荐）；网络不可用 → 使用 `~/.claude/templates/cm-plugin-arch-reference.md` 基准表兜底，并向用户标注快照日期建议复核；联网发现基准表过时 → 顺手更新它
+2. **提取需求特征**并给出架构含义（展示推导过程，让人能审）：
+
+```text
+需求特征 → 架构含义（示例）
+- 改写/增强特定网站页面   → content script 为主,注意 isolated world 与宿主样式隔离
+- 常驻工具面板            → side panel(Chrome 114+) 优于 popup(点开即关)
+- 拦截/改写网络请求       → declarativeNetRequest(注意规则上限),MV3 已无 blocking webRequest
+- 需要账号/跨设备同步     → chrome.storage.sync 够小数据;大数据/多端 → 配套后端
+- 调用 AI/付费 API        → 密钥不得进扩展包,必须配套后端代理
+- 需要抓取/解析页面数据   → content script 提取 + service worker 汇总,注意宿主页 SPA 路由变化
+- 多浏览器发布            → webextension-polyfill + 构建期双 manifest
+- 团队约束/发布条件       → 一票否决项,压过所有技术偏好
+```
+
+3. 基于特征给出 **2-3 套定制方案**，每套包含：脚手架（WXT / Plasmo / CRXJS+Vite / 原生无框架）、UI 技术栈、取舍、**对应的脚手架命令**（如 `npx wxt@latest init`、`npm create plasmo`、`npm create vite@latest -- --template react-ts` + CRXJS），并标注推荐项及推导理由（含联网校验的来源）。**命令验证边界：只许 `--help` 核实参数、`--dry-run` 验证组合，不得实际生成项目**——生成是 T-001 的职责，G1 阶段生成会让 N1 撞上"目录非空 + T-001 未勾选"信号，凭空多一次人工确认（实测教训）
+4. 人做选择题，不做填空题；确认结果连同脚手架命令写入 ADR，bootstrap T-001 直接使用该命令。**写入 ADR 的必须是全参数命令**（含包管理器等全部选项）——缺参数的命令会在无人值守执行时停下来交互式提问；现代脚手架（如 better-t-stack）完成/dry-run 时会回显"可复现完整命令"，抄它进 ADR 是标准做法
+
+必须覆盖的提问维度：
+
+- 团队已熟悉的技术栈（这是约束，不是偏好）
+- 发布渠道（Chrome Web Store 公开上架 / unlisted / 企业内部分发 / 仅开发者模式自用——决定合规投入的量级）
+- 是否需要配套后端（账号体系、API 代理、数据同步；纯本地插件可以零后端）
+- 版本控制（默认本地 git init，写成"默认 X 如不符请指出"；用户明确不用 → bootstrap 的 CLAUDE.md 版本控制字段记 `none`，全链路降级）
+- 权限敏感度（目标用户对 host_permissions 范围的接受度；`<all_urls>` 会显著拉长商店审核并吓退用户）
+
+**选型未确认前不得进入 Step 6。**
+
+### G2: 生成 0.bootstrap feature（在业务 feature 之前）
+
+编号固定为 `0`，业务 feature 从 `1` 开始：
+
+```text
+{SPECS_DIR}/
+├── docs/
+├── 0.bootstrap/          ← 0→1 专属
+│   ├── requirements.md   # 非功能需求：团队约束、部署条件、性能要求、预算
+│   ├── design.md         # 即 ADR：候选方案对比表、最终选型、每项理由
+│   └── tasks.md          # 见下方任务模板
+└── 1.{business-feature}/
+```
+
+`design.md` 按 ADR（架构决策记录）写：候选方案对比表（方案 / 优势 / 代价 / 是否入选）+ 最终选型清单 + 每项决策的理由。**这份文件就是日后回答"当时为什么选 X"的唯一出处。**
+
+`tasks.md` 任务模板（按需裁剪）：
+
+```markdown
+- [ ] T-001: 用选定脚手架生成扩展骨架（{选定的 create 命令}），manifest 只声明本期确需的最小权限；脚手架未自带 git 时执行 git init ~15min
+- [ ] T-002: 生成 .claude/ 规范（等同 /cm-plugin:init 产出，基于已选型技术栈，必含 rules/chrome-extension.md） ~15min
+- [ ] T-003: CI 与构建骨架（lint/test/build 流水线 + 打包 zip 产物，环境变量模板） ~30min ——**计划迭代 ≥3 个 feature 的项目不得裁剪本任务**：测试是基建不是环节，第一周省下的半小时会在第五周连本带利还（实测两次 demo 裁剪 + 行业重度实践共同教训）
+- [ ] T-004: 公共底座（消息通信封装、chrome.storage 读写层、错误处理、各表面入口结构） ~30min
+- [ ] T-005: E2E 基座 ~30min ——**直接拷 `~/.claude/templates/cm-plugin-e2e/` 的久经考验底座**（`extension-harness.ts` + `smoke.spec.example.ts`），别自己写 launchPersistentContext/SW 获取（会重踩全套坑：系统 Chrome 屏蔽 --load-extension 须用 Chrome for Testing、SW 注册-停机竞态、headless:false 无头环境退化、SW idle 后 "Worker was closed"、CfT 跨架构路径——harness 里全封装好了）。换掉 `{扩展名}` 等占位后跑通"扩展能加载、SW 注册、popup 可开"。扩展的"能跑起来"只能真实浏览器验证，这条冒烟是 N6 形态确认卡点与 N5 运行观察闸的技术前提
+```
+
+### G3: 业务 feature 的生成规则
+
+业务 feature 的 design.md 基于 **G1 已确认的选型**生成（此时规范文件尚不存在，以选型结论为准）。执行时序由 /cm-plugin:ai 保证：`0.bootstrap` 最优先执行，完成后规范已落地，后续 feature 加载的就是真实的 CLAUDE.md 和 rules。
+
+### G4: 后续架构变更
+
+架构调整走已有变更模式：`/cm-plugin:prd --change 0.bootstrap 数据库从 SQLite 换 Postgres`——ADR 追加版本行，决策演进全程留痕。
+
+**执行中发现架构错配的标准处置**（如 /cm-plugin:ai 跑到一半发现交付形态/框架不对）：
+
+1. **干净停点**：当前任务走完 N5（标记+落盘）再停
+2. **形态确认与回收率评估**（先问清目标形态再动手）：换脚手架（如 Plasmo → WXT）≈80% 可回收（业务逻辑与 UI 组件可迁，入口与构建配置重写）/ 换表面（如 popup → side panel）≈90%（改入口与 manifest）/ 从扩展改成 Web 应用或反向 ≈30%（`chrome.*` 依赖层全部重写，只有纯逻辑与 specs 可复用）
+3. `/cm-plugin:prd --change 0.bootstrap 交付形态从 X 改为 Y` → ADR 记 v2，受影响任务标 `[DROPPED]`/`[NEW]`（含显式迁移任务），已完成可保留的不动
+4. **旧代码移入 `legacy/`**，可回收部分由迁移任务显式搬运；重跑 /cm-plugin:ai 时 N1 的目录信号会强制确认目录处置
+5. 断点恢复按新标记续跑

package/workflows/cm-plugin/commands/cm-plugin:ai.md

@@ -0,0 +1,75 @@
+# /cm-plugin:ai — 自动开发
+
+`$ARGUMENTS` — specs 文件夹路径 + 代码项目路径。
+
+```bash
+/cm-plugin:ai specs在~/projects/my-app-specs，代码在~/code/my-app
+/cm-plugin:ai ~/projects/specs 前端~/code/fe 后端~/code/api
+```
+
+## 流程图
+
+按此流程执行，到达每个节点时读取 `~/.claude/commands/cm-plugin-ai-nodes/` 下对应的节点文件获取详细规则。
+
+```text
+START
+  │
+  ▼
+[N1: 初始化] ── 解析输入、扫描 features、加载上下文
+  │
+  ▼
+┌─► [N2: 进入 Feature] ── 读取 specs、分析依赖、输出执行计划
+│     │
+│     ▼
+│   ┌─► [N3: 执行 Task] ── 检查 skill → 开发
+│   │     │
+│   │     ▼
+│   │   [N4: Review] ── AI 自审 → Codex Review
+│   │     │
+│   │     ▼
+│   │   [N5: 标记完成] ── tasks.md 标 [x]、写 LESSONS.md
+│   │     │
+│   │     ▼
+│   │   [N6: QA 评估] ── 评分决定是否触发 cm-plugin-qa-engineer
+│   │     │
+│   │     ▼
+│   │   [N7: 上下文管理] ── /clear → 重新加载 specs
+│   │     │
+│   │     ▼
+│   │   还有未完成 task? ──YES──┘
+│   │     │
+│   │    NO
+│   │     │
+│   │     ▼
+│   └── Feature 完成 → /clear
+│         │
+│         ▼
+│       还有下一个 Feature? ──YES──┘
+│         │
+│        NO
+│         │
+│         ▼
+      [N8: 完成] ── 调用 cm-plugin-doc-syncer → 输出总结
+        │
+        ▼
+       END
+```
+
+## 全局规则
+
+**暂停（仅灾难级）：** 不可逆破坏（删数据、动线上、不可回滚迁移）、资金/密钥/合规风险、交付形态级架构错向、环境阻塞到无法继续。
+**不暂停（多方案自主决策）：** 执行中出现多个可选方案时——技术选型、实现路径、库/工具选择、审查意见分歧——**自己分析利弊选最优解直接执行，不询问**。代价是留痕义务：把「选了什么 / 为什么 / 放弃了什么」写进任务汇报，方向性取舍追记 LESSONS.md——人可以事后翻案，但流程不为选择题停车。业务逻辑歧义按需求文档最合理解释执行并显式记录所做假设，仅当触及灾难级清单才暂停。
+**节点间不停车：** 除上述灾难级与各节点显式卡点（入口闸/降级知情/形态确认/涉合规走查）外，任何节点完成后**直接进入下一节点**——不得以"我将要…是否继续?"、"完成了 X,需要我继续吗?"这类问句收尾等待。阶段性汇报写在输出里照常可见,但回合不能停在等确认上（实跑反馈:执行器习惯性在节点末尾问一句,用户被迫每阶段点头,自动化名存实亡）。
+**度量：** 每次暂停问人，恢复后在当前任务的 METRICS.md 记录里人工介入计 1 次并注明原因（见 N5）。
+**状态落盘（供状态条/看板实时点亮节点）：** 每进入一个节点（N1–N8），覆盖写入 `{SPECS_DIR}/.cm-status.json` 单行 JSON：
+`{"node":"N4","feature":"1.xxx","task":"T-005","detail":"一句话当前动作","state":"running","at":"HH:MM:SS"}`
+——**detail 必须写大白话**，标准是"路过的非工程师扫一眼能懂"：写"正在开发数据接口"不写"cm-plugin-backend-engineer 执行 T-004"；写"第2轮代码审查"不写"对抗式子agent复审"；写"确认一下：原型里有3个按钮点了没反应,要做吗?"不写"原型死区待确认"。节点号/任务号由状态条自动放在行尾角标，detail 里不要再写。
+——暂停等人时 `state` 改为 `paused_for_human`（detail 写等什么），全部完成时 N8 写 `done`。N1 时**额外把 specs 绝对路径写入 `~/.claude/cm-plugin-current-specs`**（终端状态条据此定位）。每节点一次写入，成本可忽略，不得跳过。
+**运行日志（事后复盘与工作流优化的原始证据）：** 与状态落盘同节奏，把关键事件**追加**（不覆盖）到 `{SPECS_DIR}/运行日志.jsonl`，一行一个 JSON。**`at` 一律 ISO 8601 带时区偏移**（`date +%Y-%m-%dT%H:%M:%S%z` 风格，如 `2026-07-17T10:05:25+08:00`）——实跑发现三个项目分别用了无时区/`Z`/`+08:00` 三种格式，跨项目看板排序失真：
+`{"at":"2026-07-15T14:22:10","node":"N3","feature":"1.xxx","task":"T-005","event":"task_start","detail":"一句话大白话"}`
+**必记事件（event 取值固定）**：`node_enter`（每次进节点）、`task_start` / `task_done`（done 的 detail 记一次通过与否）、`review`（轮次+拦截数+通道: codex/子agent/自审）、`degrade`（降级及失败原文）、`pause` / `resume`（等什么、人答了什么）、`decision`（多方案自主决策: 选了什么/为什么/放弃了什么）、`error`（执行报错与重试）、`qa`（N6 结论）、`done`（N8 收尾）。
+写日志与写 .cm-status.json 同时机同成本，不得跳过；只追加不清理不截断。**反馈工作流问题时，把这份文件连同 METRICS.md 一起带回**——它是定位流程卡点、优化节点设计的第一手依据。
+
+**终端任务清单镜像：** 进入每个 feature（N2）时，把该 feature 的任务镜像到 Claude Code **内置任务清单**（TaskCreate/TodoWrite，一任务一条，含编号与标题）；N3 开始执行置 in_progress，N5 标记时同步置 completed——终端原生渲染勾选进度，无需任何外部工具。**断点恢复时**：已完成（`[x]`）任务直接以 completed 状态镜像或跳过，`[DROPPED]` 不镜像——不得重复创建条目。
+
+**执行策略：** AI 自主决策串行或并行（无依赖 + 不同项目 → 并行，否则串行）。

package/workflows/cm-plugin/commands/cm-plugin:check.md

@@ -0,0 +1,66 @@
+# /cm-plugin:check — 框架一致性自检
+
+校验 cm 工作流安装的完整性和引用一致性。**每次修改框架文件后运行一次**——历史上的缺陷（改名残留、匹配表缺项、死角色、失效命令引用）全属"引用断链"类，本命令将其机器化检查。
+
+## 检查项
+
+### 1. 角色文件存在性
+
+- `~/.claude/commands/cm-plugin-ai-nodes/N3-execute-task.md` 匹配表中引用的每个 `cm-plugin-*-engineer` / `cm-plugin-*-manager` → `~/.claude/skills/{名称}/SKILL.md` 必须存在
+- `N2-enter-feature.md` 预定义角色列表中的每个 `cm-plugin-*-agent` → `~/.claude/agents/{名称}.md` 必须存在
+- 反向检查：skills/ 与 agents/ 下存在、但 `~/.claude/commands/` 下**任何文件**（命令 + cm-plugin-ai-nodes/ 节点 + cm-plugin-prd-modes/ 模式文件）均未引用的角色 → 报告为"孤儿角色"（建了没接线）。范围不得收窄到 N2/N3——把关型 skill（cm-plugin-doc-syncer/cm-plugin-product-manager/cm-plugin-qa-engineer/cm-plugin-devops-engineer）按设计接在 cm-plugin:ai/N6/N8/cm-plugin:prd/模式文件上，只查派发路径会把它们误报成孤儿（v0.9.24 实跑教训：init 自举时靠人工甄别才排除三处假阳性）。**检查范围限定 `cm-plugin-` 前缀**——上游 cm-workflow 的 `cm-*` 角色（同机共存时存在）与非前缀独立工具（如 codebase-context）都不参与本检查的角色配对（实跑教训：v0.2.2 首次自测按 cm- 扫会把共存的上游角色误报为孤儿），但其被 cm-plugin:init/cm-plugin:prd/N8 的引用仍走第 3 组命令引用检查
+
+### 2. 命名一致性
+
+- 每个 `skills/*/SKILL.md` 的 frontmatter `name` 必须等于其目录名
+- 每个 `agents/*.md` 的 frontmatter `name` 必须等于其文件名（去 .md）
+- 全部文件中不得残留旧前缀（如 `yd-`、`yd:`、未改名的 `cm:` 命令引用）；**本条规则自身的示例文本不算残留**（实跑教训：v0.2.2 首次自测 grep 命中本文件的示例即误报）
+
+### 3. 命令间引用有效性
+
+- 所有文件中出现的 `/cm-plugin:{命令}` 引用 → `commands/cm-plugin:{命令}.md` 必须存在
+- 所有文件中出现的节点引用（N1–N8）→ `commands/cm-plugin-ai-nodes/` 下对应文件必须存在
+- cm-plugin:prd 引用的模式文件 → `commands/cm-plugin-prd-modes/{greenfield,brownfield,change-mode}.md` 三个必须齐全（v0.9.11 拆分产物,缺失即断链）
+- skill 之间的互相引用（如"→ cm-plugin-qa-engineer"）→ 目标必须存在
+
+### 4. 配套机制完整性
+
+- agent 与同工种 skill 成对：每个 `cm-X-agent` 必须有其加载的 skill
+- README 中的角色计数、目录树条目与实际文件一致
+- cm-plugin:prd 任务模板引用的产物（design-baseline、METRICS.md、RELEASES.md）在对应节点/skill 中有生成方
+- **rules 引用有生成方**：任何 skill/命令中引用的 `rules/{名称}.md`，必须在 cm-plugin:init 的「规则内容指引」（或 bootstrap 模板）中有对应生成条目——skill 读一个永远不会被生成的规则文件即为断链
+- **独立工具 skill 存在性**：cm-plugin:init/cm-plugin:prd/N8 引用了 `codebase-context` → `~/.claude/skills/codebase-context/SKILL.md` 必须存在；缺失报告为断链（旧包安装，提示重装）
+- **独立工具 skill 存在性（idea-to-prd）**：cm-plugin:idea 引用 `idea-to-prd` → `~/.claude/skills/idea-to-prd/SKILL.md` 必须存在；缺失同样报断链
+- **scout 凭证配对**：cm-plugin:scout 的 GO 对抗确认凭证（`scout-{名}-verdict-r1.md`）↔ 台账中结论为 GO 的行——台账有 GO 而报告目录无 verdict 凭证 → 报告为断链（GO 无对抗凭证 = 单模型自批）
+- **scout bakeoff 凭证配对**：cm-plugin:scout 模式 B 的对抗记录（`bakeoff-{YYYYMMDD}.md`）↔ 同目录 Codex 对抗凭证（`bakeoff-{YYYYMMDD}-verdict.md`）——有对抗记录而无 verdict 凭证 → 报告为断链（对抗结论无异源凭证 = 单模型自批）。此配对仅在选品报告目录存在时检查（该目录为用户产物区，非本仓库；本仓库内仅校验 cm-plugin:scout.md 对两文件名的引用一致）
+- **凭证/审批位链路配对**：N4 落盘的 `.reviews/` 凭证 ↔ N5 卡点与 N8 对账所引用的路径一致；cm-plugin:prd 写入的 `.cm-specs-status` ↔ N1 入口闸读取的文件名一致——四处引用两两配对（防单边改名断链）
+- **规则指引与模板配对**：cm-plugin:init「规则内容指引」中的每个条目 ↔ `~/.claude/templates/cm-plugin-rules/{名称}.md` 模板文件一一对应；缺模板报告为降级项（可运行但生成质量不稳定），多出的孤儿模板报告为未接线
+- **流程脚本配对**：命令中引用的每个 `~/.claude/templates/cm-plugin-scripts/{名称}.sh`（preflight/codex/log）↔ 实际脚本文件存在且可执行；缺失报告为降级项（命令会退化为手工执行）。当前引用点：N1 环境预检+Codex 封装、cm-plugin:rewrite R0、cm-plugin:scout 日志助手
+- **E2E harness 模板配对**：greenfield/skills 引用的 `~/.claude/templates/cm-plugin-e2e/{extension-harness.ts,smoke.spec.example.ts}` 存在；缺失报告为降级项（bootstrap T-005 会退化为 AI 手写 E2E，重踩 MV3 五坑）。引用点：greenfield bootstrap T-005、cm-plugin-qa-engineer/cm-plugin-extension-engineer skill
+
+### 5. 外部依赖可用性
+
+- **Codex（审查主通道）**：`codex --version` 探测。不可用报告为降级项并给出后果说明——N4 将落到对抗式子代理（次优），N1 开跑前还会再拦一次
+- 状态条已配置（settings.json 的 statusLine 指向 cm-plugin-statusline.sh）：未配置报告为提示项（不影响运行，仅少可视化）
+- 自动更新器（`~/.cm-plugin-workflow/cm-update.sh` 存在且 settings.json 的 SessionStart 挂载）：未配置报告为提示项（可选；配置后安装一致性由它每会话机械保障,本命令的版本检查退居兜底）
+- **安装版本**：读取 `~/.claude/templates/cm-plugin-VERSION` 并显示在结论首行。文件缺失 → 显示"版本: 未知（旧版安装，建议用最新包重装）"——版本混乱是实测踩过的坑，反馈问题必带版本号
+- **版本一致性（防混装/旧装）**：本命令文件自带基线号 → **框架版本基线: 0.5.0**（发包时与 VERSION 文件同步递增）。比对规则：
+  - 基线 = cm-plugin-VERSION → 一致，正常
+  - 基线 ≠ cm-plugin-VERSION 或 cm-plugin-VERSION 缺失 → **报"版本不一致/过旧"并建议重装**："命令文件 v{基线} / 安装标记 v{实际}——本机是混装或旧包，请用最新 zip 重跑 install.sh"（实测事故：公司机器旧包 + 家里新包，功能"消失"排查半天）
+
+## 输出格式
+
+```text
+🔍 cm-plugin:check 一致性自检  (安装版本: v{X.Y.Z} / 未知)
+
+角色存在性:   {N} 项检查 · {通过/断链清单}
+命名一致性:   {N} 项检查 · {通过/不一致清单}
+命令引用:     {N} 项检查 · {通过/失效清单}
+配套完整性:   {N} 项检查 · {通过/缺失清单}
+外部依赖:     {N} 项检查 · {Codex 可用/降级 · 状态条 已配/未配}
+版本一致性:   {一致 v{X.Y.Z} / ⚠ 不一致(命令 v{A} vs 安装标记 v{B}),请重装}
+
+结论: PASSED / {N} 处断链（逐条列出：文件:位置 → 期望 → 实际）
+```
+
+发现断链只报告不自动修——修复由人确认后执行。

package/workflows/cm-plugin/commands/cm-plugin:fix.md

@@ -0,0 +1,100 @@
+# /cm-plugin:fix — 缺陷修复小闭环
+
+**用法**：`/cm-plugin:fix {specs路径} {代码项目路径} 缺陷描述（现象/报错/截图均可）`
+
+修 bug 专用的**轻量闭环**——不走 N1–N8 全链（那是 feature 流程），也不许脱离工作流裸改（裸改没防护网没审查，修一个坏三个）。
+
+**多缺陷输入**：先对全部缺陷做第 1-2 步（复现+定位），**按根因聚类**——同根缺陷合并为一次修复（多个失败测试、一次改动、档案互链），修复顺序按严重度排,不按输入顺序。不聚类的代价：三个现象一个根因跑三个闭环,且第一个修复落地后,后两个的复现步骤可能已失效（第 1 步卡死）。
+
+**转交进场**（消费上游落盘物,不改上游流程）：缺陷描述可附上游档案引用——`/cm-plugin:refactor` 档案的未修缺陷清单、N6 业务走查报告的偏差项、观测闭环的半份档案（按 slug 在 `fixes/` 检索）。带引用进场的缺陷,第 1 步**采信上游已有证据**（位置/现象/日志原文）,仍须实际复现一次核实,但不从零摸排。
+
+**cm-plugin:ai 全局规则在本命令内同等生效**：灾难级才暂停、多方案自主决策留痕、状态落盘（node 写 `FIX`）、运行日志（事件照记）、Codex 纪律（装了就用）。
+
+## 闭环七步（每个缺陷）
+
+### 1. 复现（不能复现的 bug 不许修）
+
+- 按描述实际操作/运行一次，拿到**失败证据**（报错原文、错误截图、错误返回值）;**证据要用严格裁判**——宽容裁判会把坏产物蒙混成功（实跑:补丁类缺陷 GNU patch 的 fuzz 容错险些吞掉复现,换 git apply --check 才拿到硬证据）
+- 复现不了 → 不猜着修，走**观测闭环**（偶现 bug 专用，两段式）：
+  ① 在可疑路径加观测点（日志/埋点——观测点本身按最小改动+审查纪律入库，**观测点不是修复尝试**）
+  ② 缺陷档案先落半份，状态记 `观测中`，写清"等什么证据（哪个日志出现什么内容）"
+  ③ 本次命令正常收口退出，不挂着等——运行日志记 `done`,detail 写「观测中:等{什么证据}」;状态文件 state 复位,不留悬挂的 running
+  ④ 证据到手后再次运行 `/cm-plugin:fix` 附上证据，**按 slug 定位 `fixes/` 下的半份档案**,从第 2 步定位续跑,档案续写、状态改 `修复中`,运行日志记 `resume`(detail 注证据摘要)
+  ——**"我改了点东西你再试试"依然被禁止**
+
+### 2. 定位（先找根因，不是找改哪行能让现象消失）
+
+- 有业务地图（`docs/codebase-context/`）→ 先查 07 业务线路定位所在链路，08 修改影响映射表查波及面
+- 无地图 → 从失败点向上追调用链，找到**根因层**（现象在 UI，根因可能在数据层）
+- 输出一句话根因结论 + 波及面清单（本次修改会牵连哪些模块）——写进缺陷档案（第 7 步）
+
+### 2.5 根因与修法对抗确认（条件触发；根因错误是本流程最贵的错误,必须在防护网之前拦）
+
+任一**客观条件**命中才触发(简单缺陷零负担,判断依据同"门槛是客观项不是判断题"):波及面 ≥3 个模块 / 根因层与现象层不同层 / 观测闭环续跑的缺陷 / 拟走升级出口。
+
+- 把根因结论 + 复现证据 + 波及面清单 + **拟采用修法(含放弃的备选)** 交 Codex,提示词要义:"**假设这个根因判断是错的,找出更深层的解释;再审修法:治本还是治症?有没有更小的改动?会不会引入新耦合?**"——诊断和药方同轮审,零新增轮次(维护者要求:方案不能不审;简单缺陷由第 5 步事后审兜底)(Codex 未装走 N4 三级降级链,纪律同第 5 步)
+- **仅 1 轮**:推翻 → 回第 2 步重定位;分歧 → 交人裁决;通过 → 进第 3 步
+- 凭证落 `{SPECS_DIR}/.reviews/fix-{slug}-cause-r1.md`——**命名带 `cause` 是有意的**:不落入第 5 步 `fix-{slug}-r*.md` 的匹配域,两个卡点各自独立,根因凭证不会误满足 diff 审查卡点
+
+### 3. 防护网（先让 bug 有测试，再修）
+
+- **写一个能复现此 bug 的失败测试**（红）——它是"修好了"的客观定义，也是永久回归资产;**红的原始输出落进档案**(第 5 步审查要核对红证据,从未红过的测试转绿是空话)
+- 项目有存量测试 → 先跑一遍记录基线（修完对照，防止修 A 坏 B）
+- 写不了自动化测试的形态（如纯视觉）→ 截图/录屏留"修前"证据
+
+### 4. 修复（最小改动）
+
+- 只改根因层，**禁止顺手重构**（N3 同款纪律：看不惯的代码记 LESSONS 待触发备忘，事后走 `/cm-plugin:refactor`，不在修 bug 时动）
+- 修法有多个方案 → 自主决策选最优，`decision` 事件留痕
+- **升级出口**：定位发现是设计缺陷/需要跨模块大改 → **停止硬修**，报告根因并建议走 `/cm-plugin:prd --change` 变更模式立项——bug 命令不承接架构手术。**已建资产不弃**:第 3 步的失败测试保留入库（它是缺陷的客观复现,新方案转绿即验收）,档案状态记 `升级立项`,注明测试路径供立项后的流程直接接手
+
+### 5. 审查（Codex 纪律同 N4）
+
+- 失败测试转绿 + 存量基线不退化后，调 `codex:review` 审 diff（重点：根因是否真被修掉、有无只治了症状、波及面有无遗漏）
+- **防护网测试本身是审查对象**(实测最大问题类:测试是戏台):红的原因是否=该缺陷、断言测的是根因还是症状、有无安慰剂/前提共谋;**核对第 3 步落档的红证据**——没有红过的记录,测试可信度按不成立处理
+- 装了就用零豁免；未装/中途失效才走 N4 三级降级链；≤2 轮上限同样生效
+- **审查凭证落盘**：输出全文 tee 到 `{SPECS_DIR}/.reviews/fix-{slug}-r{轮次}.md`（纪律同 N4）——进第 6 步前**必须真跑** `ls {SPECS_DIR}/.reviews/fix-{slug}-r*.md`,命令无输出=审查未发生,退回补审;凭证文件名写进第 7 步收口输出（文字卡点拦不住是实测结论,机械命令才算数）
+
+### 6. 回归（按波及面，不是只看 bug 消失）
+
+- 跑第 3 步防护网测试（红→绿）+ 存量测试全量（对照基线）
+- 按第 2 步波及面清单逐项走一遍关键流（同 B2 口径：波及面=回归范围）
+- **回归失败的回路（显式分支,不许临场发挥）**：任何一项红 → 退回第 4 步重修,重修后**必须复审**且轮次并入第 5 步的 ≤2 轮总上限——上限耗尽仍打转 = 根因判断可疑,按升级出口处置,不许无限修-回归循环
+
+### 7. 落盘（审计链闭合）
+
+- **缺陷档案**：`{SPECS_DIR}/fixes/{YYYYMMDD}-{简短slug}.md`——现象 / 复现步骤 / 根因 / 修法（含放弃的方案）/ 波及面与回归结果 / 测试文件路径。这是缺陷知识库，同类 bug 再犯先查这里
+- **METRICS.md 追加一行**：Feature 列写 `fix`，任务列写档案文件名，其余列同口径（轮次/拦截数/人工介入）
+- 根因具普遍性（如"平台 API 返回结构变了"）→ 追记 LESSONS.md（[已结构化]/[仅记忆] 分级同 N5）
+- git commit：`fix: {一句话} (档案: fixes/xxx.md)`，审查摘要进 commit message（同 N4）
+- 运行日志事件：`task_start`/`review`/`task_done`/`done` 照记，node 字段写 `FIX`
+
+## 微缺陷快速通道（四个硬门槛全中才准走）
+
+**门槛是客观项不是判断题**——"感觉这个 bug 很小"不构成理由，四条全中才走，任一不中走完整七步：
+
+- [ ] 只改文案/样式/配置常量——**不新增、不修改任何条件分支与函数签名**
+- [ ] 单文件且 diff ≤ 10 行
+- [ ] 波及面为零（改动处无被其他模块引用的行为；有业务地图查 08 映射表核实）
+- [ ] 有截图/文案前后对照可作验收证据
+
+**快速通道可省**：第 3 步防护网测试、第 6 步全量回归（用前后对照截图代替）。
+**不可省**：Codex 审查（凭证照落）、缺陷档案（显式标注 `快速通道`）、METRICS 行（Feature 列写 `fix-lite`）。
+**快速通道的审查特化**:本道上 Codex 是唯一质量防线(防护网与全量回归都省了),审查**第一职责是复核四门槛**——diff 可直接验证项逐条验(行数 ≤10?单文件?零分支/签名变更?),波及面存疑即**打回走完整七步**。门槛是客观项,但自己量自己需要第二双眼睛。
+> fix-lite 的占比进运行日志——快速通道被滥用（占比异常高/出现分支改动混入）时收紧门槛，数据说了算。
+
+## 输出格式（每个缺陷收口时）
+
+```text
+🔧 缺陷闭环: {slug}
+根因: {一句话}
+修法: {一句话} | 放弃方案: {有则一句话,无则省}
+防护网: 新增 {测试文件}(红→绿) · 存量基线 {N} 项无退化
+审查: Codex {通过/N轮N条} | 回归: 波及面 {N} 项通过
+档案: fixes/{文件名}   METRICS 已记
+```
+
+## 边界
+
+- **不承接**：新功能（走 /cm-plugin:prd）、需求变更（走 /cm-plugin:prd --change）、架构级返工（升级出口交人立项）
+- specs 目录没有 fixes/ 子目录时自动创建；没有 specs 目录的裸项目也可用：档案落代码项目 `docs/fixes/`，**审查凭证落 `docs/fixes/.reviews/`**（第 5 步卡点同样生效），METRICS 跳过