@aibyzero/byz 0.1.1 → 0.1.2

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

@@ -0,0 +1,29 @@
+# /cm-plugin:idea — 点子 → PRD（流程上游入口，非 N1–N8 步骤）
+
+**用法**：`/cm-plugin:idea 一句话点子`（如 `/cm-plugin:idea 我想做个自动整理浏览器标签页的插件`）
+
+把模糊想法聊成成熟 PRD 的产品访谈搭档。**本命令只做一件事**：加载 `~/.claude/skills/idea-to-prd/SKILL.md` 并严格按其规则执行——本文件不复制不改写技能规则，技能文件是唯一事实源。
+
+## 执行
+
+1. 读取 `~/.claude/skills/idea-to-prd/SKILL.md`，未安装则提示重装最新包后中止
+2. 把 `$ARGUMENTS` 作为用户点子，进入技能的访谈流程（判定产品类型 → 一次一题 → L1 骨架 → 按用户节奏加深；涉及交易/Web3 自动加载 `references/domains/trading.md` 领域包）
+3. 全程遵守技能自身纪律（一次一题、防诱导选项、狠收敛、纯对话不联网）
+
+## 与 cm 流程的衔接（只提示，不自动执行）
+
+PRD 聊到用户满意收尾时，**追加一段提示**（这是本命令相对裸技能唯一的增量）：
+
+```text
+📄 PRD 已保存: {路径}(成熟度 {L1/L2/L3},「待明确的问题」剩 {N} 条(口径:只数 PRD 第 7 节的条目,正文散落的待补标记不计;路径用绝对路径)——带着未决问题交棒,prd 的产品角色会重新追问;想少被问就先在这里加深)
+下一步(需要你手动执行,本命令不代跑):
+  1. 建 specs 文件夹,把这份 PRD 放进 docs/
+  2. /cm-plugin:prd {specs路径}   ← 拆成规格三件套
+  3. 人审摘要卡后 /cm-plugin:ai 开始开发
+```
+
+## 边界
+
+- 不写代码、不拆任务、不调 /cm-plugin:prd——想法阶段结束就交棒
+- 已有现成需求文档的项目不需要本命令，直接 `/cm-plugin:prd`
+- 触发词自然唤起（"我有个点子…"）与本命令等效，习惯哪个用哪个

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

@@ -0,0 +1,145 @@
+# /cm-plugin:init — 项目 .claude 初始化
+
+你是一个项目配置初始化助手。你的任务是在当前项目目录中创建 `.claude/` 文件夹及其完整配置结构。
+
+## 空目录检测（前置）
+
+当前目录为空（无项目描述文件且无源码）→ **本命令不适用，不自行搭脚手架**。提示用户：
+
+> "这是空目录——/cm-plugin:init 服务于已有项目。全新插件请走 0→1 分支：建 specs 文件夹放入需求文档后运行 `/cm-plugin:prd {specs路径}`，那里会基于需求推荐扩展脚手架（WXT / Plasmo / CRXJS 等），脚手架与规范生成都由 bootstrap 任务完成。"
+
+## 执行步骤
+
+### 1. 分析项目
+
+在生成任何文件之前，先全面分析当前项目：
+
+- 读取 `package.json`、`Cargo.toml`、`go.mod`、`pyproject.toml`、`pom.xml` 等项目描述文件，判断语言和框架
+- 扫描目录结构（重点关注 `src/`、`app/`、`lib/`、`tests/`、`migrations/` 等）
+- 读取现有的 README、CI 配置、lint 配置、tsconfig 等，提取构建/测试/运行命令
+- **识别扩展形态**：定位 manifest（源文件或 wxt.config / plasmo 约定生成），记录 manifest 版本、脚手架（WXT / Plasmo / CRXJS / 原生）、已用的表面（service worker / content_scripts / popup / options / side_panel）与权限清单
+- 识别项目是否附带配套后端 API、共享包等模块
+- **检测版本控制状态**（结果写入 CLAUDE.md 的「版本控制」字段，全流程据此降级）：
+  - 有 git 且有 remote → `remote`；有 git 无 remote → `local`（不询问，直接记录）
+  - **无 git → 询问用户一次**："初始化本地 git？（推荐——每任务提交与审计链依赖它）/ 不使用版本控制"
+  - 用户拒绝 → 记 `none`：不生成 git-workflow.md、后续 N5 跳过提交、doc-syncer 用文件扫描、hook 不适用、审计链降级为 METRICS + tasks 勾选
+
+### 1.5 代码库参考文档（自动判断，不询问）
+
+**前置**：`~/.claude/skills/codebase-context/` 未安装 → 跳过本步并提示"codebase-context skill 未安装(旧版包),业务地图功能不可用,建议用最新包重装"——不阻塞 init 其余步骤。
+
+按下列条件**自动决策**是否执行 `codebase-context` scan，不问用户，执行后在输出中汇报判断依据（形态判断优先于文件数）：
+
+- 项目**无任何项目描述文件**（package.json/Cargo.toml/go.mod/pyproject.toml/pom.xml 等）**且无 src/ 类源码结构**（如纯 prompt/文档资产库、纯配置仓库）→ **跳过**——scan 的七轮抓取目标（api/types/components/store）在此类形态下均不存在，产出多为空章节（v0.9.24 实跑教训：60 个 md 的 prompt 仓库按文件数会误判全量扫）
+- 源码文件 > 30 个 且 `{项目根}/docs/codebase-context/` **不存在** → 自动执行**全量 scan**（存量项目首扫，生成业务地图）
+- 参考文档目录**已存在** → 自动执行**增量 scan**（顺手保鲜，成本极低）
+- 源码文件 ≤ 30 个 且 无参考文档 → **跳过**（小项目直接读代码更快，建地图不划算）
+
+输出格式（四选一）：`📚 业务地图: 已全量生成(源码{N}个) / 已增量刷新(变更{N}个) / 跳过(小项目,源码仅{N}个) / 跳过(形态不适用,无项目描述文件)`
+
+**判定结果落盘**：把同一行写入**代码项目根**（即 scan 的 PROJECT_ROOT，多层仓库下不是仓库根）的 CLAUDE.md「业务地图」字段；该处无 CLAUDE.md → 写入地图 `00-index.md` 头部并在输出中说明落点——/cm-plugin:prd 据此直接行动，不重复判断、不重复建议（实测教训：25 文件的临界项目，init 说跳过、prd 又建议 scan，两处判断打架）。
+
+### 2. 生成文件结构
+
+根据分析结果，生成以下结构（只创建与项目相关的文件）：
+
+```
+.claude/
+├── CLAUDE.md                    # 项目门面，≤150 行
+├── rules/
+│   ├── coding-style.md          # 命名/缩进/import/注释规范
+│   ├── testing.md               # 测试约定、覆盖率要求
+│   ├── security.md              # 禁止事项、密钥处理
+│   ├── git-workflow.md          # 分支/commit/PR 规范
+│   ├── chrome-extension.md      # 扩展铁律：权限最小化/MV3 约束/禁远程代码（插件项目必建）
+│   ├── frontend.md              # (如有 UI 表面) popup/options/side panel 的组件规范
+│   └── backend-api.md           # (如有配套后端) paths: server/**, api/**
+```
+
+### 3. CLAUDE.md 模板
+
+CLAUDE.md 必须包含以下部分，控制在 150 行以内：
+
+```markdown
+# {项目名}
+
+{一句话简介}
+
+## 技术栈
+
+- 语言: {lang}
+- 框架: {framework}
+- 包管理: {pkg manager}
+- 版本控制: {remote | local | none}   # /cm-plugin:ai 各节点据此执行或降级 git 操作，不再重复询问
+- 交付形态: Chrome 扩展 (MV3) · {表面组合,如 side panel+content script} · {目标浏览器}   # 架构第一分叉，涉表面/浏览器的需求变更必须过人工确认
+- 扩展脚手架: {WXT | Plasmo | CRXJS+Vite | 原生}
+- 业务地图: {已全量生成 {日期} | 跳过(小项目,{N}文件) | 未初始化}   # codebase-context 判定结果，/cm-plugin:prd 据此行动不再重复询问
+
+## 常用命令
+
+- 安装依赖: `{install cmd}`
+- 开发运行: `{dev cmd}`
+- 构建: `{build cmd}`
+- 测试: `{test cmd}`
+- Lint: `{lint cmd}`
+
+## 目录结构
+
+{树形结构速览，只列关键目录，不超过 20 行}
+
+## 规则
+
+@rules/coding-style.md
+@rules/testing.md
+@rules/security.md
+@rules/git-workflow.md
+@rules/chrome-extension.md
+{以下按需引入}
+@rules/frontend.md
+@rules/backend-api.md
+```
+
+### 3.5 生成即核验(机械,写入前执行)
+
+生成的 CLAUDE.md 与 rules 中**所有可执行断言逐条实证**,核验不过的条目不许静默写入(修正或显式标注「未验证」):
+
+- 命令类(install/dev/test/lint/build):验证脚本真实存在(读 manifest scripts / Makefile),可安全 dry 的实跑一次
+- globs 类:实测匹配非空——匹配零文件的 glob 是死规则
+- 文件引用类(@rules/xxx、路径):存在性检查
+
+> 依据:实跑事故——init 生成的 testing.md 写了 Node 24 下已失效的 `node --test tests/`,带病上岗直到任务踩上去才发现。能机械验的绝不靠嘴(凭证卡点同款基因)。
+
+### 4. rules 文件格式
+
+每个 rules 文件使用以下格式：
+
+```markdown
+---
+description: { 规则一句话描述 }
+globs: { 可选，如 "src/web/**" }
+---
+
+# {规则标题}
+
+{具体规则内容，从项目实际配置中推断，简洁明了}
+```
+
+### 5. 规则内容指引
+
+**生成方式**：每个 rules 文件优先以 `~/.claude/templates/cm-plugin-rules/{名称}.md` 的模板骨架为基础——遵守模板头部的四原则（可执行 / Bad-Good 对比 / 量化 / 现代实践），将所有 `{占位符}` 替换为从项目实际推断的内容，删除不适用章节。模板不存在时按下方各条目描述自行生成（老安装降级路径）。
+
+- **coding-style.md**: 从 eslint/prettier/editorconfig/rustfmt 等配置推断命名风格、缩进、import 排序、注释规范。如无配置则根据语言社区惯例设定。
+- **testing.md**: 从测试框架配置和现有测试推断测试规范、文件命名、覆盖率要求。
+- **security.md**: 列出禁止硬编码密钥、环境变量处理、敏感文件 .gitignore 规则等。
+- **git-workflow.md**: 从 git 历史推断 commit 风格（conventional commits?），分支命名规范，PR 流程。**按版本控制字段裁剪**：`none` → 不生成本文件；`local` → 裁掉 PR/远程/保护分支章节，只留 commit 规范。
+- **chrome-extension.md**: 扩展开发铁律——权限最小化与申请理由留档、MV3 约束（service worker 无 DOM 且会休眠、禁 eval/远程代码）、上下文间消息契约集中管理、manifest 变更单独提交（插件项目必建，以模板为骨架 + 项目实际权限清单填充）。
+- **frontend.md**: popup/options/side panel 的组件规范、状态管理、样式约定；content script UI 的宿主页样式隔离（shadow DOM / CSS 前缀）（仅当项目有 UI 表面时创建）。
+- **backend-api.md**: API 设计规范、错误处理、中间件约定、扩展侧调用的 CORS 与鉴权约定等（仅当项目有配套后端时创建）。
+
+## 重要约束
+
+- 如果 `.claude/` 已存在，先告知用户并询问是否覆盖
+- 所有规则内容必须基于项目实际情况推断，不要生成空洞的通用规则
+- CLAUDE.md 严格控制在 150 行以内
+- 只创建与项目实际相关的 rules 文件，不要创建不适用的文件
+- 生成完成后，列出所有创建的文件并给出简要说明

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

@@ -0,0 +1,403 @@
+# /cm-plugin:prd — 需求文档 → 开发规格生成
+
+支持两种模式：新建需求和需求变更。
+
+## 输入参数
+
+`$ARGUMENTS` 格式：
+
+- **新建模式**：`/cm-plugin:prd {项目文件夹路径}`
+- **变更模式**：`/cm-plugin:prd --change {N}.{feature-name} 变更内容描述`
+
+用户提供一个项目文件夹路径，文件夹结构约定：
+
+```text
+{项目文件夹}/
+├── docs/           ← 需求文档（必须存在，PRD 从这里读取）
+├── 1.xxx/          ← 已有的 specs（如有）
+├── 2.xxx/          ← 本次生成的 specs
+└── ...
+```
+
+## 模式判断
+
+如果 `$ARGUMENTS` 以 `--change` 开头 → **读取 `~/.claude/commands/cm-plugin-prd-modes/change-mode.md`** 执行变更模式（C1–C8）
+否则 → 进入新建模式
+
+---
+
+## 新建模式
+
+### Step 1: 解析输入，读取需求文档
+
+从 `$ARGUMENTS` 提取项目文件夹路径，记为 `SPECS_DIR`。
+
+读取 `{SPECS_DIR}/docs/` 下的所有文件作为需求源：
+
+- 支持 `.md`、`.txt`、`.pdf`、`.html` 等文档格式
+- **HTML 交互原型（可点击 PRD）→ 执行交互遍历协议，禁止只做静态截图**。可交互原型是一份可执行的需求文档，必须用无头浏览器（Playwright / Chrome DevTools）**主动遍历**：
+
+  1. **枚举**每个页面的全部可交互元素（按钮/链接/tab/表单/开关/列表项…）
+  2. **逐个操作**并记录三元组：`元素 → 动作 → 结果`（跳转到哪/弹了什么/状态怎么变/无响应）
+  3. 产出**功能点清单**：每个有响应的交互 → 对应一条 [F-xxx]；**点了没反应的 → 列为"原型死区"进开放问题**（问用户：是原型没做完，还是本就不需要？不许静默丢弃）
+  4. **覆盖率自检**：可交互元素总数 = 功能需求数 + 死区数，对不上不得进入 Step 6
+  5. 遍历过程中逐状态截图（Step 8.5 的候选基准）；三元组记录直接生成**交互流 AC 与 E2E 走查清单**
+
+  原型首先是需求，其次才是视觉候选。注意原型通病：只画理想态——异常态/空态/边界值靠 Step 5.5 歧义五问补齐
+- 如果 docs/ 下有多个文件，全部读取并综合分析
+- 如果 docs/ 不存在或为空，报错提示用户先在 docs/ 下放入需求文档
+
+### Step 2: 获取项目名称
+
+- 从当前目录的 `package.json` name 字段、`Cargo.toml`、`go.mod` 等提取项目名
+- 如无法提取，使用当前目录名
+- 转为 kebab-case，记为 `PROJECT_NAME`
+
+### Step 3: 探测项目架构类型
+
+**代码项目根的确定（防在错误目录生成脏规格）**：`$ARGUMENTS` 中显式给了代码项目路径（如 `代码在~/code/app`）→ 以其为准；未给 → 用当前工作目录（约定:在代码项目内运行本命令），但**必须先自检**——当前目录含项目描述文件或源码、且其内容与需求文档所述业务相符；明显不符（如当前目录是另一个项目/工具仓库）→ **停下询问代码项目路径**，不得静默把错误目录当项目上下文（空目录检测只兜全空 case，兜不住"错但有效"的目录）。
+
+扫描项目根目录、配置文件、目录结构、依赖声明，自行判断架构类型（纯扩展单仓 / 扩展+后端 monorepo / 多仓库等）。记录 `ARCH_TYPE`。
+
+**空项目检测**：代码项目不存在、或为空目录（无 package.json / Cargo.toml / go.mod 等项目描述文件，且无源码目录）→ **先问用户确认空目录的含义，不得自行假设**：
+
+> "代码目录为空——这是【全新项目】（走 0→1 分支，我来推荐架构和脚手架），还是【存量项目还没 clone】（请先 clone 到该目录，再重新运行 /cm-plugin:prd）？"
+
+- 确认全新项目 → 标记 `GREENFIELD=true`，**读取 `~/.claude/commands/cm-plugin-prd-modes/greenfield.md`** 叠加 G1–G4 规则，Step 4 跳过
+- 确认未 clone → **中止本次执行**，提示 clone 完成后重跑（在不存在的项目上下文上生成 design.md 是有毒规格）
+
+### Step 4: 读取项目上下文（存量项目 = 二开模式，叠加 B 规则）
+
+- 读取各仓库的 `.claude/CLAUDE.md` 了解技术栈
+- 读取 `.claude/rules/` 下所有规则文件
+- 扫描目录结构，了解现有模块划分
+- **B1 加载代码库参考文档**：**先读代码项目根 CLAUDE.md 的「业务地图」字段**（多层仓库下以代码项目根为准，仓库根 CLAUDE.md 无此字段再看地图 00-index 头部；init 已判定过，不重复判断）：字段=已生成/已刷新 或 `docs/codebase-context/` 存在 → 按 `codebase-context` skill dev 模式加载 10 份文档（后续步骤查重与波及面分析的数据源）；字段=跳过(小项目) → **不建议 scan，直接读代码**（小项目全量读的成本本来就低）；字段缺失且文档不存在 → 建议先执行 `/codebase-context scan`；**skill 本身未安装** → 提示重装最新包，本次降级为直接读代码，波及面分析降级为 grep 推断（照常可跑，只是更贵更粗）
+
+**二开模式追加规则**（GREENFIELD=false 且本次需求会修改存量代码时生效）→ **读取 `~/.claude/commands/cm-plugin-prd-modes/brownfield.md`** 执行 B2 波及面 / B3 防护网基线 / B4 增量 specs / B5 拆分锚定地图。
+
+
+### Step 5: 分析需求
+
+**调用 `cm-plugin-product-manager` skill 执行本步和 Step 5.5**——用户故事、编号功能需求、验收标准的编写方法和歧义五问以该 skill 为准。
+
+需求涉及**新增权限 / 收集用户数据 / 注入第三方网站 / 加载远程内容**时，在本步同时做**商店合规预扫**（检查方法以 `cm-plugin-qa-engineer` skill 的商店合规检查单为准）：每项权限给出用途理由、标记单一用途政策风险点、列出需要隐私政策披露的数据项——发现的问题作为合规开放问题并入 Step 5.5 一并确认，确认结果写入 requirements.md 非功能需求节与 design.md 安全考虑节。**权限问题在规格期确认的成本是一句话，上架被拒后的成本是整轮返工。**
+
+从文档中提取功能目标、用户故事、验收标准、约束条件、依赖。
+
+### Step 5.5: 开放问题确认
+
+分析需求后，如果存在以下情况，**必须暂停并与用户对话确认**，不要自行假设：
+
+- 需求描述模糊或有歧义的功能点
+- 多种技术实现方案且差异较大
+- 缺少关键信息（如目标平台、兼容性要求、第三方服务选型）
+- 业务逻辑有矛盾或不完整
+- 涉及权限、支付、敏感操作等需要明确确认的功能
+
+格式：
+
+```
+❓ 需要确认以下问题：
+
+1. {问题描述} — {为什么需要确认}
+2. {问题描述} — {为什么需要确认}
+
+请逐一回复后继续生成 specs
+```
+
+所有问题确认完毕后再进入 Step 6。
+
+### Step 6: 推断 feature 名称
+
+根据需求内容生成一个简洁的 kebab-case 英文名称。
+
+### Step 7: 生成 specs 目录
+
+检查 `{SPECS_DIR}/` 下已有的编号目录（如 `1.xxx/`、`2.xxx/`），取最大编号 +1。
+
+```text
+{SPECS_DIR}/
+├── docs/                        ← 需求文档（输入）
+├── 1.比如这是一个已有的标题/     ← 已有 specs
+└── 2.{feature-name}/            ← 本次新建
+    ├── requirements.md
+    ├── design.md
+    └── tasks.md
+```
+
+### Step 8: 生成 requirements.md
+
+```markdown
+# {Feature 名称} — 需求规格
+
+## 概述
+
+{一句话描述}
+
+## 项目信息
+
+- 项目名: {PROJECT_NAME}
+- 架构类型: {ARCH_TYPE}
+
+## 需求版本
+
+| 日期         | 版本 | 说明     |
+| ------------ | ---- | -------- |
+| {YYYY-MM-DD} | v1   | 初始需求 |
+
+## 用户故事
+
+- 作为 {角色}，我想要 {功能}，以便 {价值}
+
+## 功能需求
+
+1. [F-001] {需求描述}
+2. [F-002] {需求描述}
+
+## 非功能需求
+
+- 性能: {要求}
+- 安全: {要求}
+- 兼容性: {要求}
+
+## 验收标准
+
+- [ ] [AC-001] {标准描述}
+
+## 依赖
+
+- {外部服务/库}
+
+## 开放问题
+
+- {待确认事项}
+```
+
+### Step 8.5: UI 设计基准（涉及 UI 的 feature）
+
+feature 涉及页面/界面时，在生成 design.md 前确定设计基准：
+
+- **有 Figma/设计稿** → 通过 MCP 导出截图 + token 提取物，落盘 `{SPECS_DIR}/{N}.{feature-name}/design-baseline/`（防链接失效与云端改版导致基准漂移）
+- **有 Stitch 项目** → 通过 Stitch MCP 拉取设计并导出 HTML/CSS 落盘 design-baseline/；导出的 HTML **按 Step 1 交互遍历协议处理**（多屏/流转设计可直接提取交互流与功能点）——Stitch 导出物默认按像素基准对待（它就是设计本体，不是示意）
+- **有 HTML 交互原型**（Step 1 已截图）→ **必须人工三选一确认基准档位**（中性提问不带引导；高保真原型建议像素档，线框灰稿建议结构档）：
+  - **① 像素基准**：UI 与交互 **1:1 还原**——截图落盘 design-baseline/ 作 BackstopJS 基准（≤1%），且**交互流提取为 E2E 走查清单**（每个跳转/状态切换/反馈逐条断言，交互不 1:1 视为验收失败）
+  - **② 结构基准**（多数原型的合理档）：页面结构、信息层级、**交互流程必须一致**，视觉样式可再设计——验收为逐页元素清单核对 + 流程走查
+  - **③ 纯参考**：仅辅助理解需求，无对照验收——选此档即明确接受 UI 由 AI 自行发挥（历史事故：原型被降为参考后，产出与原型完全不符）
+  档位写入 design.md「设计基准」节；**无论哪档，原型的页面清单与跳转流程都已是需求的一部分（Step 1 规则），流程不允许自由发挥**
+- **无设计稿且环境已安装 `huashu-design` skill** → 调用其生成高保真原型（**要求包含 hover/空态/错误态等交互态**），落盘同上；**人审规格时一并确认设计方向**（复用既有强制卡点，执行期零设计决策）
+- **两者皆无** → 不建基准、**不生成 UI 还原任务**，该 feature 的 UI 由扩展工程师任务按 design.md 自行实现；可提示用户 `npx skills add alchaincyf/huashu-design`
+
+有基准时，design.md 记录基准路径，且「接口契约」节须包含**组件契约**（组件名 / props / 事件）。
+
+### Step 9: 生成 design.md
+
+**必须先读取项目 `.claude/CLAUDE.md` 和 `.claude/rules/` 下所有规范文件**，设计方案必须遵循项目已有的技术规范和约定。
+
+按功能模块设计，每个模块说明涉及哪些层（service worker / content script / popup / options / side panel / 配套后端等），具体分层根据项目实际架构决定，不做硬编码限制。**涉及多个扩展上下文的模块必须写清消息通信方向与消息格式**（谁发起、经过谁、`chrome.runtime.sendMessage` 还是 port 长连接）——上下文间通信契约是扩展开发的头号返工源。
+
+```markdown
+# {Feature 名称} — 技术设计
+
+## 设计版本
+
+| 日期         | 版本 | 说明     |
+| ------------ | ---- | -------- |
+| {YYYY-MM-DD} | v1   | 初始设计 |
+
+## 项目架构
+
+- 架构类型: {ARCH_TYPE}
+- 涉及层: {根据项目实际情况列出}
+
+## 功能模块设计
+
+### 模块 1: {模块名}
+
+{技术方案，遵循 .claude/rules/ 中的规范}
+
+**涉及层及关键设计:**
+
+{根据项目实际分层描述，如数据模型、API 接口、组件设计、合约接口等}
+
+### 模块 2: {模块名}
+
+...
+
+## 接口契约
+
+{扩展内消息契约（message type / payload / 响应）、配套后端 API 等 — 根据项目类型决定}
+
+## 数据模型
+
+{chrome.storage 分区(local/sync/session)与 schema、IndexedDB、后端数据表 — 根据项目类型决定}
+
+## 安全考虑
+
+{基于 .claude/rules/security.md 和项目特有的安全规范}
+
+## 技术决策
+
+| 决策 | 选项 | 理由 |
+| ---- | ---- | ---- |
+```
+
+### Step 9.5: 方案对抗审查（最贵的决策补上第二双眼睛）
+
+design.md 生成后，满足任一触发条件 → 交**第二模型对抗审查一轮**（Codex 主通道；不可用按 N4 降级链用对抗子代理）：
+
+- GREENFIELD 的 ADR（架构选型是最贵决策）
+- 二开且修改存量模块（方案错误会伤及老功能）
+- design 含新模块、依赖方向变化或跨模块数据流
+- 功能点 F ≥ 5 的大 feature
+
+**投喂内容**:requirements.md + design.md 全文 + 项目 `.claude/rules/` 相关规范 +(二开)「波及面」段与被改存量模块现状代码——只给 design 不给上下文,审查质量减半(10.6 有投喂清单本步没有,内部不一致,此处补齐)。
+提示词要义："**这是隔壁同事做的方案，详细审查一下**"——重点查架构隔离、模块边界、与现有管线的耦合、数据流缺口；只报告有具体失败场景的问题，零发现明说（审查产出纪律同 N4）。**仅 1 轮**：采纳项修正 design.md 后进 Step 10；分歧项写入摘要卡「风险点」交人裁决。小 feature 不触发，零额外负担。
+**凭证落盘**:审查原文 tee 到 `{SPECS_DIR}/.reviews/prd-{feature}-design-r1.md`——摘要卡「方案对抗审查」行必须与凭证对得上,无凭证的数字是自报(凭证教义全框架一体,规格期不豁免)。
+
+> 依据：代码有 N4 对抗、规格有 10.5 自检，唯独技术方案此前无第二模型把关——而方案错误是最贵的错误（行业重度实践的最大单笔收益正是方案期拦截架构缺陷）。
+
+### Step 10: 生成 tasks.md
+
+**按功能拆任务。** AI 执行时根据 design.md 自动判断每个任务涉及哪些层。
+
+```markdown
+# {Feature 名称} — 任务清单
+
+## 任务版本
+
+| 日期         | 版本 | 说明     |
+| ------------ | ---- | -------- |
+| {YYYY-MM-DD} | v1   | 初始任务 |
+
+## 项目信息
+
+- 项目名: {PROJECT_NAME}
+- 架构类型: {ARCH_TYPE}
+- specs 路径: {SPECS_DIR}/{N}.{feature-name}/
+
+## 任务列表
+
+### UI 还原（仅当存在 design-baseline 时生成本节）
+
+- [ ] T-001: 还原 {页面/组件} ~30min（基准: design-baseline/；本 feature 的扩展功能任务依赖本任务）
+
+### 功能 1: {功能名}
+
+- [ ] T-002: {任务描述} ~{预估时间}
+- [ ] T-003: {任务描述} ~{预估时间}
+
+### 功能 2: {功能名}
+
+- [ ] T-003: {任务描述} ~{预估时间}
+
+### 集成与测试
+
+- [ ] T-010: 联调测试 ~{预估时间}
+- [ ] T-011: E2E 测试 ~{预估时间}
+- [ ] T-012: 部署 staging 并冒烟验证 ~15min（依赖本 feature 全部开发与测试任务）
+
+> 部署任务前提：项目存在部署形态（Dockerfile / CI 配置 / 部署脚本，或 0→1 项目——bootstrap 已建 CI 骨架）才生成 T-012；**纯本地工具、库等无部署形态的项目不生成**，避免执行期反复触发"无 staging 环境"上报。
+
+## 依赖关系
+
+- T-002 依赖 T-001
+
+## 风险点
+
+- {可能遇到的问题及应对}
+```
+
+**任务拆解原则：**
+
+- 按功能拆，AI 执行时读 design.md 自动识别涉及哪些层；**二开项目按 B5 锚定业务地图**（feature 沿 07 线路、任务尽量单模块）
+- 原子性，可独立完成和验证
+- **同一组件/同一文件内的行为不拆分为多个任务**（如"渲染列表项"和"列表项的删除确认"归一个任务）——拆开会导致执行时自然合并、任务标记与提交失配（实跑验证的教训）
+- 预估完成时间（5min / 15min / 30min / 1h）
+- **粒度控制**：每个子 specs（feature 目录）不宜过大，单个 tasks.md 控制在 **10-15 个任务以内**。如果需求过大，应在 Step 6 之前拆成多个独立的 feature 目录（如 `2.user-auth-login`、`3.user-auth-register`），每个 feature 有自己的 requirements/design/tasks 三件套。这样 cm-plugin:ai 执行时上下文可控，不会因为 specs 太大导致丢失关键信息。
+
+### Step 10.5: 规格自检（机器项，AI 自查自修，人不参与）
+
+输出摘要卡之前，先对刚生成的三件套跑一遍机器可查项——**机器项 AI 自己清干净，人审只留业务意图**：
+
+**通用自检项（所有项目）：**
+
+- [ ] 任务依赖无环；单 feature ≤15 个任务；同一文件/组件的行为未拆散到多任务
+- [ ] 每条 AC 都能回答"怎么验证"（验证方式不明的 AC 视为不过）
+- [ ] 任务产物查重：不与项目已有资产重复造（有地图查 04/05/06，无地图 Grep 核实）
+
+**二开附加项（存在业务地图时）：**
+
+- [ ] **引用真实性（治引用幻觉）**：specs 中提到的每个存量文件/函数/组件名，用 Grep 逐个核实真实存在——二开 spec 引用不存在的存量代码，人审查不出来、执行期才炸
+- [ ] **B5 合规**：feature 未跨多条 07 业务线路；跨模块任务已在描述中列模块清单
+- [ ] **B3 合规**：修改存量模块的 feature，第一个任务是防护网基线
+- [ ] **B2 完整**：design.md 含「波及面」段，且所列模块在地图/代码中真实存在
+
+**处置规则**：有不过项 → AI 自行修正 specs 后重跑自检，**最多 2 轮**；2 轮后仍不过的项不许静默放行，写入摘要卡「风险点」交人裁决。自检结果一行附在摘要卡底部。
+
+### Step 10.6: Codex 规格审查（装了就用，未装才跳过）
+
+10.5 自检是机器项，查不出"**拆得对不对**"。自检通过后，把拆分结果交 Codex 过第二模型（触发口径同 N4：`codex` 可用即触发，未安装/不可用才跳过）：
+
+- **投喂内容**：requirements.md 功能点清单 + tasks.md 全文 + design.md「波及面」段（二开）——喂拆分结果，不喂三件套全文
+- **提示词要义**："这是隔壁同事拆的开发任务单，审查拆分质量：①任务边界有无重叠/遗漏 ②依赖顺序会不会卡死 ③粒度是否适合单任务交付验证 ④二开：波及面清单有没有漏掉会被牵连的模块。只报有具体后果的问题，没有问题就明说。"
+- **处置**：采纳项修正 specs 后重跑一次 10.5 自检；分歧项写入摘要卡「风险点」交人裁决。**仅 1 轮**，不与 Codex 拉扯
+- **凭证落盘**:审查原文 tee 到 `{SPECS_DIR}/.reviews/prd-{feature}-split-r1.md`,摘要卡「Codex 规格审查」行与之对应
+- **不设降级链**：Codex 未装 → 直接跳过并在摘要卡标注（规格审查是增益层；代码审查 N4 才是强制层）
+- 调用失败处理同 N4 纪律：失败原文记录，超时重试 1 次，仍失败按未装处理
+
+> 依据：拆分质量是二开乱改的最后闸门——10.5 只能查机器项（引用真实性、依赖环），"这个任务拆得会不会漏改关联模块"需要第二模型的判断力。
+
+### Step 11: 输出总结（附规格摘要卡 + 审查清单）
+
+**先输出规格摘要卡**——人审的第一入口是这张一屏卡片，不是三个长文件（实跑教训：直接丢长文件，人审会退化成扫一眼就"通过"）：
+
+```text
+┌─ 📋 规格摘要卡 ────────────────────────────
+│ 交付形态: {扩展表面组合,如 side panel+content script}   ← 第一分叉,看错全错
+│ 目标浏览器: {Chrome / Chrome+Edge / 含 Firefox}
+│ 权限清单: {permissions + host_permissions,逐项带用途}   ← 商店审核与用户信任的焦点
+│ Feature: {N 个}: {名称列表}
+│ 功能点: {N} 个 | AC: {N} 条 | 任务: {N} 个(预估 {x}h)
+│ 开放问题: {已答 N / 共 N}——{逐条一行: 问题→答案}
+│ 风险点: {商店合规/权限扩张/破坏性操作等敏感项,无则"无"}
+│ UI 基准: {像素级/结构级/纯参考/无}
+│ 🔎 规格自检: {N}/{N} 通过{（未过项已列入风险点）}
+│ 🧠 方案对抗审查: {通过 / {N}条已修 / 跳过(未触发)}
+│ 🤖 Codex 规格审查: {通过 / {N}条已修 / 跳过(未装)}
+└────────────────────────────────────────────
+有疑问的行,点开对应文件细看;摘要卡没问题再走下面的审查清单。
+```
+
+完成后报告：
+
+- Feature 名称和序号、Specs 路径、涉及的技术层、总任务数和预估总时间
+
+并输出**规格审查清单**——人审规格不是"看一眼"，按此逐项检查：
+
+```text
+📋 规格审查清单（人审时逐项勾选）
+- [ ] 任务跨 feature 查重：同一产物（文件/模块）未出现在多个任务中（实跑教训：bootstrap 底座与 feature 数据层重复）
+- [ ] 依赖关系完整：每个任务的前置依赖已声明，无环
+- [ ] AC 可测试：每条验收标准都能回答"怎么验证"
+- [ ] 粒度合规：同一组件/文件的行为未拆成多任务；单 feature ≤15 个任务
+- [ ] 开放问题已全部回答，敏感决策（法域/支付/权限）有人工确认记录
+- [ ] **交付形态与需求意图一致**（要 App 别画成网页），且已写入 ADR 与 CLAUDE.md 字段
+- [ ] **原型功能点覆盖 100%**（有交互原型时）：遍历记录中每个可交互元素都有对应 [F-xxx] 或死区标注，无静默丢弃
+```
+
+**规格审批位落盘**：报告输出后，写入 `{SPECS_DIR}/.cm-specs-status` 单行 JSON：
+`{"status":"awaiting_review","at":"{时间}","features":["1.xxx",...]}`
+
+**硬停车（不可违反）**：本命令的终点就是摘要卡与审查清单——**任何情况下不得在本会话顺势启动开发**，对话里的"继续"不构成开发授权。提示用户：**逐项审查通过后，运行 `/cm-plugin:ai` 开始开发**（N1 有入口闸：未审批的 specs 会先要求确认摘要卡）
+
+---
+
+---
+
+## 模式文件（按需读取,勿全量加载）
+
+- 0→1 全新项目: `cm-plugin-prd-modes/greenfield.md`（G1 选型/G2 bootstrap/G3 业务生成/G4 架构变更处置）
+- 存量二开: `cm-plugin-prd-modes/brownfield.md`（B2–B5）
+- 需求变更: `cm-plugin-prd-modes/change-mode.md`（C1–C8）
+
+> 拆分目的: 主文件只承载通用流程,执行器按分支加载对应规则——注意力预算优先(v0.9.11 机械拆分,语义零变更)。