newbee-sdd 1.0.0

package/lib/verifier.js

@@ -0,0 +1,197 @@
+const fs = require('fs');
+const path = require('path');
+
+const FUZZY_WORDS = ['快速', '适当地', '必要时', '尽量', '合理地', '等等', '及时', '高效', '适当', '合理'];
+
+/**
+ * 寻找项目中的 specs 目录或 spec.md 文件
+ */
+function findSpecsDir(baseDir) {
+  // 1. 检查 .newbee-specs-path 指针
+  const pointerFile = path.join(baseDir, '.newbee-specs-path');
+  if (fs.existsSync(pointerFile)) {
+    const raw = fs.readFileSync(pointerFile, 'utf8').trim();
+    if (raw && fs.existsSync(raw)) {
+      return raw;
+    }
+  }
+
+  // 2. 候选目录列表
+  const candidates = [
+    path.join(baseDir, 'newbee-specs'),
+    path.join(baseDir, 'specs'),
+    path.join(baseDir, 'docs', 'sdd'),
+    path.join(baseDir, 'spec')
+  ];
+
+  for (const cand of candidates) {
+    if (fs.existsSync(cand) && fs.statSync(cand).isDirectory()) {
+      return cand;
+    }
+  }
+
+  // 3. 根目录单文件 spec.md
+  const singleSpec = path.join(baseDir, 'spec.md');
+  if (fs.existsSync(singleSpec)) {
+    return singleSpec;
+  }
+
+  return null;
+}
+
+/**
+ * 递归读取所有 markdown 文件
+ */
+function getMarkdownFiles(targetPath) {
+  if (!fs.existsSync(targetPath)) return [];
+  if (fs.statSync(targetPath).isFile()) {
+    return [targetPath];
+  }
+
+  const results = [];
+  const entries = fs.readdirSync(targetPath, { withFileTypes: true });
+  for (const entry of entries) {
+    const fullPath = path.join(targetPath, entry.name);
+    if (entry.isDirectory()) {
+      // 排除 node_modules 和 .git
+      if (entry.name !== 'node_modules' && entry.name !== '.git') {
+        results.push(...getMarkdownFiles(fullPath));
+      }
+    } else if (entry.isFile() && entry.name.endsWith('.md')) {
+      results.push(fullPath);
+    }
+  }
+  return results;
+}
+
+/**
+ * 核心校验逻辑
+ */
+function verify(projectDir = process.cwd()) {
+  const specsTarget = findSpecsDir(projectDir);
+  console.log(`\n🔍 [newbee-sdd] 正在扫描工程规格...`);
+  console.log(`📁 基准目录: ${projectDir}`);
+
+  if (!specsTarget) {
+    console.log(`⚠️  未发现任何 specs 目录或 spec.md (已扫描 newbee-specs/, specs/, docs/sdd/, spec.md)`);
+    console.log(`💡 提示: 可运行 \`npx newbee-sdd init\` 初始化规格目录。\n`);
+    return { ok: false, message: '未找到规格文件' };
+  }
+
+  console.log(`📄 锁定规格路径: ${specsTarget}\n`);
+
+  const files = getMarkdownFiles(specsTarget);
+  if (files.length === 0) {
+    console.log(`⚠️  规格路径下没有发现 .md 文件。\n`);
+    return { ok: false, message: '空规格目录' };
+  }
+
+  const reqs = new Set();
+  const rules = new Set();
+  const tcs = new Set();
+  const tasks = new Set();
+  const tcCoveredReqs = new Set();
+  const tcCoveredRules = new Set();
+  const untrackedItems = [];
+  const fuzzyHits = [];
+
+  const reqRegex = /\b(REQ-[A-Z0-9_-]+)\b/g;
+  const ruleRegex = /\b(RULE-[A-Z0-9_-]+)\b/g;
+  const tcRegex = /\b(TC-[A-Z0-9_-]+)\b/g;
+  const taskRegex = /\b(TASK-[A-Z0-9_-]+)\b/g;
+
+  for (const file of files) {
+    const content = fs.readFileSync(file, 'utf8');
+    const relFile = path.relative(projectDir, file);
+    const lines = content.split('\n');
+
+    lines.forEach((line, idx) => {
+      const lineNum = idx + 1;
+
+      // 检查 [untracked]
+      if (line.includes('[untracked]')) {
+        untrackedItems.push({ file: relFile, line: lineNum, text: line.trim() });
+      }
+
+      // 检查模糊词
+      for (const word of FUZZY_WORDS) {
+        if (line.includes(word) && !line.startsWith('#') && !line.includes('FUZZY_WORDS')) {
+          fuzzyHits.push({ file: relFile, line: lineNum, word, text: line.trim() });
+        }
+      }
+
+      // 收集定义与引用
+      let m;
+      while ((m = reqRegex.exec(line)) !== null) reqs.add(m[1]);
+      while ((m = ruleRegex.exec(line)) !== null) rules.add(m[1]);
+      while ((m = tcRegex.exec(line)) !== null) tcs.add(m[1]);
+      while ((m = taskRegex.exec(line)) !== null) tasks.add(m[1]);
+
+      // 简单关联捕获：同行内同时出现 TC 与 REQ/RULE
+      const lineTcs = line.match(tcRegex);
+      if (lineTcs) {
+        const lineReqs = line.match(reqRegex);
+        const lineRules = line.match(ruleRegex);
+        if (lineReqs) lineReqs.forEach(r => tcCoveredReqs.add(r));
+        if (lineRules) lineRules.forEach(r => tcCoveredRules.add(r));
+      }
+    });
+  }
+
+  console.log(`📊 【ID 统计清单】`);
+  console.log(`  • REQ  (需求项):   ${reqs.size} 个`);
+  console.log(`  • RULE (业务规则): ${rules.size} 个`);
+  console.log(`  • TC   (测试用例): ${tcs.size} 个`);
+  console.log(`  • TASK (拆解任务): ${tasks.size} 个`);
+  console.log('────────────────────────────────────────');
+
+  let hasErrors = false;
+
+  // 1. 检查 untracked
+  if (untrackedItems.length > 0) {
+    console.log(`\n❌ [FAIL] 发现 ${untrackedItems.length} 处未追溯项 [untracked]：`);
+    untrackedItems.forEach(item => {
+      console.log(`   - ${item.file}:${item.line} -> ${item.text.slice(0, 80)}`);
+    });
+    hasErrors = true;
+  } else {
+    console.log(`✅ 追溯标签检查: 无孤立 [untracked] 标记`);
+  }
+
+  // 2. 检查模糊词
+  if (fuzzyHits.length > 0) {
+    console.log(`\n⚠️  [WARN] 发现 ${fuzzyHits.length} 处可能引发歧义的模糊词：`);
+    fuzzyHits.slice(0, 10).forEach(hit => {
+      console.log(`   - [${hit.word}] ${hit.file}:${hit.line} -> ${hit.text.slice(0, 60)}`);
+    });
+    if (fuzzyHits.length > 10) {
+      console.log(`   ... 以及其余 ${fuzzyHits.length - 10} 处`);
+    }
+  } else {
+    console.log(`✅ 规格严谨度: 未发现常见模糊词汇`);
+  }
+
+  // 3. 检查覆盖闭环
+  const uncoveredReqs = [...reqs].filter(r => !tcCoveredReqs.has(r));
+  if (reqs.size > 0 && tcs.size > 0 && uncoveredReqs.length > 0) {
+    console.log(`\n⚠️  [WARN] 以下 REQ 未在行内显式关联 TC 映射 (需确认是否有单独 RTM 矩阵覆盖)：`);
+    uncoveredReqs.slice(0, 5).forEach(r => console.log(`   - ${r}`));
+    if (uncoveredReqs.length > 5) console.log(`   ... 等共 ${uncoveredReqs.length} 个需求`);
+  } else if (reqs.size > 0 && tcs.size > 0) {
+    console.log(`✅ 闭环追溯: 所有 REQ 均已有关联 TC`);
+  }
+
+  console.log('\n════════════════════════════════════════');
+  if (hasErrors) {
+    console.log(`🚫 校验未通过，请修复上述问题后再次执行。\n`);
+    return { ok: false };
+  } else {
+    console.log(`🎉 [PASS] SDD 规格追溯检查全部通过！\n`);
+    return { ok: true };
+  }
+}
+
+module.exports = {
+  verify,
+  findSpecsDir
+};

package/package.json

@@ -0,0 +1,39 @@
+{
+  "name": "newbee-sdd",
+  "version": "1.0.0",
+  "description": "规格驱动开发（SDD）工作流与多工具适配套件 - 支持 dsh, OpenCode, Claude Code, Cursor, Codex",
+  "main": "lib/index.js",
+  "bin": {
+    "newbee-sdd": "bin/newbee-sdd.js"
+  },
+  "files": [
+    "bin",
+    "lib",
+    "SKILL.md",
+    "references",
+    "templates",
+    "scripts",
+    "upgrade.md",
+    "README.md"
+  ],
+  "scripts": {
+    "test": "node bin/newbee-sdd.js --help"
+  },
+  "keywords": [
+    "sdd",
+    "spec-driven-development",
+    "opencode",
+    "claude-code",
+    "cursor",
+    "deepseek-harness",
+    "dsh",
+    "codex",
+    "agent-skills",
+    "prompt-engineering"
+  ],
+  "author": "qieb",
+  "license": "MIT",
+  "engines": {
+    "node": ">=16.0.0"
+  }
+}

package/references/architecture-guide.md

@@ -0,0 +1,45 @@
+# 架构设计与防御性工程指南（architecture-guide）
+
+> 本文件为 L 轨深度技术方案（`plan.md`）的核心设计指引，融合 C4 模型、单一职责模块切分与外部集成失败模式设计。
+
+---
+
+## 1. C4 架构分层设计原则
+
+在 `plan.md` 中画系统架构图时，采用 C4 模型的自顶向下视角：
+
+1. **Context（系统上下文图）**：明确本系统与外部用户、第三方系统之间的边界与核心数据流。
+2. **Container（容器与进程图）**：展示服务、前端单页、API 网关、数据库、消息队列之间的通信协议（HTTP/gRPC/Kafka）。
+3. **Component（组件/模块图）**：将业务拆解为具有单一职责的逻辑模块（MOD-###）。
+
+---
+
+## 2. 模块切分规范（MOD-###）
+
+- **单一职责原则**：每个模块只负责一个清晰的业务域（如 `MOD-010 订单状态机`、`MOD-020 库存预扣器`）。
+- **无环依赖铁律**：模块间的依赖关系必须保持严格的单向流动，禁止任何双向循环依赖（A 依赖 B，B 依赖 A）。
+- **REQ 承载映射**：每一个在 `spec.md` 中定义的 Must REQ，在技术方案中必须能明确找到至少一个承载它的 MOD 模块。
+
+---
+
+## 3. 外部依赖集成与失败模式设计（必填项）
+
+对于任何外部系统依赖（第三方 API、外部数据库、外部 RPC），在技术方案中**必须显式提供以下 5 项防御性设计**：
+
+| 防御维度 | 设计标准与要求 | 示例 |
+|---|---|---|
+| **超时机制 (Timeout)** | 显式定义连接超时与读取超时，杜绝线程挂起与级联雪崩 | `ConnectTimeout: 1000ms`, `ReadTimeout: 3000ms` |
+| **重试策略 (Retry)** | 必须采用指数退避（Exponential Backoff）与抖动（Jitter），且仅对幂等操作重试 | 重试 3 次，间隔 `100ms, 200ms, 400ms` |
+| **幂等性保证 (Idempotency)** | 写入与扣减操作必须带业务唯一流水号或幂等 Token | 请求头带 `X-Idempotency-Key: UUID`，数据库唯一索引兜底 |
+| **熔断与降级 (Fallback)** | 当失败率超过阈值时触发熔断，并提供确定性降级返回值 | 熔断后返回本地二级缓存数据或友好降级提示 |
+| **数据补偿机制 (Compensation)** | 出现网络分区或最终不一致时的对账与补偿手段 | 发送异步重试消息队列，人工核对工作流 |
+
+---
+
+## 4. NFR（非功能需求）架构建模映射
+
+任何一条 NFR 需求不得凭空悬挂，必须在架构方案中找到对应的实现手段：
+
+* **性能 NFR**（如响应时间 P99 ≤ 200ms）→ 必须映射为：索引优化、Redis 缓存穿透防范、批量批处理拉取。
+* **高可用 NFR**（如可用性 99.9%）→ 必须映射为：主从多可用区容灾、健康检查探针、优雅停机（Graceful Shutdown）。
+* **安全 NFR**（如防 SQL 注入、合规脱敏）→ 必须映射为：ORM 参数化绑定、敏感日志掩码拦截器。

package/references/checklists.md

@@ -0,0 +1,75 @@
+# 审查清单（checklists）
+
+> Fresh-Context 复审指南：在支持 Subagent 的宿主中，将对应阶段的审查清单连同工件文件路径一同输入给独立子代理；审者逐项给出 PASS / FAIL / N.A. 结论与 FIND 清单，不省略任何检查项。
+
+---
+
+## 1. 规格审查（spec 五项）
+
+| # | 检查维度 | FAIL 判定标准 |
+|---|---|---|
+| 1 | **需求完整性** | 用户已确认的澄清结论未被 spec 吸纳；需求歧义被模型私自静默拍板 |
+| 2 | **可验证性** | REQ 缺少 Given/When/Then 验收条件；NFR 缺少可量化数值或量测方式；出现模糊词（快速/适当地/必要时/尽量/合理地/等等） |
+| 3 | **覆盖率闭环** | TC 未 100% 覆盖 REQ 与 RULE（以机器校验脚本输出为准）；存在孤儿 RULE（无 REQ 引用或无 TC 对应） |
+| 4 | **契约一致性** | 接口/数据契约与需求描述中的字段、类型、必填性产生冲突；需求前后矛盾或职责重叠 |
+| 5 | **全链路追溯性** | 存在未标记来源的孤立内容（[untracked]）；DEC 决策缺少上下文与后果说明（Context/Consequences） |
+
+---
+
+## 2. 方案与架构审查（plan & architecture 六项）
+
+| # | 检查维度 | FAIL 判定标准 |
+|---|---|---|
+| 1 | **选型依据** | 架构选型结论未回链到具体 NFR-### 或 DEC-###；以“我比较熟”或“业界流行”作为唯一技术选型理由 |
+| 2 | **Scope 对齐** | 方案涉及了 spec 之外的未经批准的端点或数据实体（范围蔓延 scope creep），或遗漏了 spec 内已声明的范围 |
+| 3 | **C4 模块单一职责** | MOD-### 模块职责模糊、存在循环依赖（依赖图有环）；Must REQ 未能 100% 映射到承载模块 |
+| 4 | **失败模式防御** | 新增的外部系统依赖缺少超时、重试、幂等、熔断/降级、补偿机制中的任何一项 |
+| 5 | **接口契约一致** | 模块对外接口或 API 定义与数据模型字段类型、必填项、错误码不一致 |
+| 6 | **技术假设验证** | 存在高风险的关键技术假设但未制定 PoC / Spike 探针验证任务 |
+
+---
+
+## 3. 代码审查（code 四维）
+
+| 审查维度 | 检查重点与判定标准 |
+|---|---|
+| **Bug 与正确性** | 逻辑错误、边界条件越界、并发安全与死锁、异常捕获缺失、连接与文件资源泄露 |
+| **性能表现** | N+1 查询、大结果集未分页、不必要的全局同步锁、重复序列化与计算（对照 NFR 目标核查） |
+| **系统安全** | SQL/代码注入漏洞、越权访问、敏感信息/秘钥打印到日志、输入参数未校验 |
+| **代码可维护性** | 命名晦涩、大段重复代码、违反单一职责原则、缺少单元测试、硬编码魔法值 |
+
+> **规格符合性附加项**：逐条核对代码是否严格遵循对应 TASK 所指派的 REQ/RULE 业务验收条件，任何偏离均记录为 Blocker 或 Major FIND。
+
+---
+
+## 4. 任务与 RTM 审查（tasks & RTM 三项）
+
+| # | 检查维度 | FAIL 判定标准 |
+|---|---|---|
+| 1 | **任务粒度** | 单个任务工作量超过 2 天，或职责不单一无法独立验证 |
+| 2 | **RTM 全覆盖** | 存在 Must REQ 未被任何 TASK 承接；存在 TC 未被测试任务覆盖 |
+| 3 | **无环依赖** | 任务拓扑排序存在死锁循环依赖（A 依赖 B，B 依赖 A） |
+
+---
+
+## 5. 收尾与发布审查（release 四项）
+
+| # | 检查维度 | FAIL 判定标准 |
+|---|---|---|
+| 1 | **RTM 状态真实性** | 存在“代码已实现（done）但关联 TC 未实际运行/未通过”的条目被计入完成 |
+| 2 | **核心需求达成率** | Must REQ 完成率未达到 100%（且缺口未逐项取得书面豁免） |
+| 3 | **遗留缺陷闭环** | 存在未处理的开放 FIND，未转为后续跟踪 ID 也未取得负责人书面豁免 |
+| 4 | **版本与索引一致** | `INDEX.md` 全局索引表中的状态与功能夹层 spec.md 的 frontmatter 状态不一致 |
+
+---
+
+## 统一 FIND 报告标准输出格式
+
+复审者输出统一采用结构化格式：
+
+```text
+FIND-### | 严重级别（Blocker/Major/Minor）| 位置（文件:行号 或 章节名）| 缺陷描述 | 建议修复方案 | 处置结论（转正为 DEC-/TASK-###，或豁免：理由+决策人）
+
+审查裁定：APPROVE / REQUEST-CHANGES
+（存在任何一条 Blocker 级别问题时，结论一律强制判定为 REQUEST-CHANGES）
+```

package/references/schemes.md

@@ -0,0 +1,54 @@
+# 方案识别与共存（schemes）
+
+> Stage 0 阶段的识别字典。newbee-sdd 与其他 SDD 方案共存的原则：**一仓一案、物理隔离、身份行判别、保护存量**。
+
+---
+
+## 1. 识别特征表
+
+| 方案类别 | 默认正本路径 | 核心识别特征 | 状态枚举 |
+|---|---|---|---|
+| **newbee-sdd** | `newbee-specs/`（或 `.newbee-specs-path` 覆盖处） | 工件头部 `scheme: newbee-sdd v1`；夹层 `NNN-name/`；`INDEX.md` | draft / approved / implementing / done / blocked / deprecated |
+| **原 SDD Pack (gen2)** | `docs/sdd/` | 固定文件名组（`clarification.md`、`review-report.md` 等七件套）；Verdict 判定行 | PASS / PASS-WITH-FIXES / FAIL |
+| **Spec Kit 风格 (gen3)**| `specs/` | `constitution.md` + `NNN-feature/`；frontmatter 含 id/status/owner | draft / in-review / approved / implementing / done / deprecated |
+| **轻量/未知方案** | 根目录 `spec.md` 或任意 | 存在规格文档但无统一约束标记 | — |
+
+---
+
+## 2. 优先级链（规则冲突时自顶向下生效）
+
+1. **项目既有流程与资产**：项目已有工单系统、CI 质量门禁、已有的自有 SDD 正本、既有 Code Review 流程 —— 具有最高权威，永不暴力覆盖。
+2. **`newbee-specs/CONVENTIONS.md`**：项目针对 newbee-sdd 声明的定制规则（可附加、可加严）。
+3. **newbee-sdd 核心默认值**：兜底规则。
+
+---
+
+## 3. 共存与保护决策（检测到存量工件时）
+
+| 检测场景 | newbee-sdd 处理策略 |
+|---|---|
+| **项目已有自有 SDD 方案，且用户未显式点名 newbee** | **主动礼让**：输出提示「检测到项目存在自有规格正本，newbee-sdd 待命并让位」，不擅自创建新结构。 |
+| **用户明确点名启用 newbee（房客模式）** | 工件收敛在 `newbee-specs/` 中，绝不破坏原有正本文件；工件中通过超链接引用原项目既有规范。 |
+| **存量旧版工件（如已有 `docs/sdd/` 或 `specs/`）需要继续演进** | **向后兼容模式**：直接读取现存的 `requirements.md`、`plan.md` 等文件并继承上下文，在已有 ID 体系上继续扩展，无需推倒重来。 |
+| **用户明确要求将旧方案工件统一迁移到 newbee** | 执行平滑迁移：为旧工件补充 `scheme: newbee-sdd v1` 头，并按照状态映射表对齐状态，旧正本原地保留或归档。 |
+| **无法归类的未知工程规范** | 停下向用户确认意图，绝不擅自猜测覆盖。 |
+
+---
+
+## 4. 状态映射与向下兼容
+
+| 存量来源状态 | newbee-sdd 对齐状态 |
+|---|---|
+| draft | draft |
+| in-review / approved | approved |
+| in-progress / implementing | implementing |
+| implemented / done | done |
+| archived / deprecated | deprecated |
+| blocked | blocked |
+
+---
+
+## 5. ID 标号向前兼容性
+
+- 迁入或继承的旧工件中，现有的 `REQ-###`、`RULE-###`、`TC-###` **完全保留原编号**（遵循 ID 终身不可变更的铁律）。
+- 在头部加上 `scheme: newbee-sdd v1` 后，全链路机器校验脚本（`npx newbee-sdd verify`）即可无缝完成追溯链对账。

package/references/stages.md

@@ -0,0 +1,75 @@
+# 阶段细则（stages）
+
+> 各阶段的输入、输出与验证细则。入口流程与闸门见 SKILL.md，本文展开工程细节。
+
+## Stage 0 — 方案地图（任何写入之前必做）
+
+| 检查项 | 规则与行为 |
+|---|---|
+| **扫描点** | 项目根：`newbee-specs/`、`.newbee-specs-path`、`specs/`、`spec/`、`docs/sdd/`、`constitution.md`；项目 AGENTS.md 中的方案声明 |
+| **产出报告** | 三行报告：自有正本（不碰）／`CONVENTIONS.md` 定制（按它执行）／newbee 默认值（其余） |
+| **工件根解析** | `.newbee-specs-path` 存在 → 只认绝对路径，指向不存在/为空 → **报错停下**；无声明 → `<项目根>\newbee-specs\`（或项目既有 specs 目录） |
+| **续跑机制** | 已有夹层 → 编号 = 现有最大 NNN + 1（建夹层前扫描，防并行撞号）；孤儿工件按 `scheme:` 行领地认领 |
+| **脚本执行** | 运行 `npx newbee-sdd verify` 或本地脚本进行机器对账 |
+
+## Stage 1 — 澄清 + 规格（spec.md 一档闭环）
+
+**输入**：用户原始描述（口语即可）、现有代码/schema（可选）。
+
+**流程**：
+1. **需求澄清**：区分「已明确」与「有歧义」；歧义逐条向用户提问（一次最多 5 题、按风险高低排序），绝不静默替用户拍板。
+2. **编写规格**：按 `templates/spec.md` 撰写：REQ（GWT 验收条件）→ RULE（来源 REQ）→ DEC（取舍即记录）→ TC（100% 覆盖 REQ 与 RULE）。
+3. **自检规范**：比对 `references/checklists.md` 中的 spec 五项；运行 `npx newbee-sdd verify`。
+4. **Fresh-Context 复审**：在支持 Subagent 的宿主中（如 OpenCode/Claude Code），启动全新子会话进行独立复审；不支持时进行结构化自查。
+
+**验证指标**：常见模糊词零命中；TC 100% 覆盖 REQ 与 RULE；每条 NFR 均有定量数值与量测方式；无未决 `[untracked]`。
+
+## Stage 2 — 人审冻结
+
+- 向用户呈现 spec 摘要（REQ 数量、RULE 数量、TC 数量、复审发现与处置），请求用户批准。
+- 用户批准后 → frontmatter 状态更新为 `status: approved`（需求正式冻结）。此后的任何改动走变更管理铁律。
+
+## Stage 3 — 技术方案与架构设计（plan.md，仅 L 轨）
+
+**输入**：已冻结的 spec.md（特别是 NFR 与优先级）、现有技术栈/团队/运维约束。
+
+**产出**（`templates/plan.md`）：
+1. **约束与技术调研**：候选方案与依据（引用官方文档，不凭印象）。
+2. **评分矩阵**：维度 × 权重 × 候选打分 → 结论回链 NFR-### 与 DEC-###。
+3. **架构设计**：C4 架构组件划分图、模块职责清单（MOD-###）、关键流程时序图。
+4. **防御性设计**：每个外部依赖必填失败模式（超时、重试、幂等、熔断/降级、补偿）。
+
+**验证指标**：每个技术选择必须回链 NFR-### 或 DEC-###；“我比较熟”不得作为选型理由；关键技术假设附 PoC/spike 安排。
+
+## Stage 4 — 任务拆解（tasks.md）
+
+**产出**（`templates/tasks.md`）：
+- **Part 1 任务清单**：`TASK-### | 标题 | 来源（REQ-/RULE-/DEC-/MOD-）| 类型（code/test/infra/doc/spike）| 依赖 | 验收条件`。任务粒度保持在 0.5~2 天，职责单一、可独立验收。
+- **Part 2 需求追溯矩阵（RTM）**：`REQ → RULE → DEC → TC → TASK → Implementation(待回填) → Release(状态)`；如有外部工单系统挂接 External ID。
+- **Part 3 [untracked] 清单**：无明确来源的任务绝不静默保留，由用户裁决转正补 ID 或直接废弃。
+
+**验证指标**：100% Must REQ 映射至少 1 个任务；100% TC 映射至少 1 个测试任务；依赖无环。
+
+## Stage 5 — 实施与代码审查
+
+- 严格按照 tasks.md 拆解的依赖顺序实施开发。
+- 任务完成后进行代码审查（四维：Bug、性能、安全、可维护性 + 规格符合性），审查通过后方可回填 RTM 中的 Implementation（commit/PR）。
+- 审查者不得建议违反规格的修改；若发现规格缺陷，记录 Minor FIND 指向规格层。
+
+## Stage 6 — 收尾对账与发布
+
+- **RTM 全链路对账**：杜绝“实现代码已合并但 TC 未执行通过”的情况；Must REQ 完成率达到 100%。
+- **豁免项闭环**：所有豁免均有一行书面理由与决策人。
+- **状态归档**：更新 frontmatter `status: done`；更新 `INDEX.md` 索引表。
+
+## FIND 闭环机制（所有阶段审查通用）
+
+审查中发现的每条问题（FIND-###）必须二选一闭环，严禁口头承诺：
+1. **转正 ID**：修改规格的转为 DEC 或规格修订；修改代码的转为 TASK。
+2. **显式豁免**：记录一行明确理由 + 决策人。
+
+## 变更管理铁律（approved 之后的修改）
+
+- REQ/RULE/TC 编号不可变更、不可复用；废弃条目标注 `superseded by REQ-###`，绝不直接物理删行。
+- `approved` 之后修改 spec：必须在文档内变更记录（change-log）中记录一行（日期/原因/影响范围），受影响的任务在 RTM 中标明回归影响。
+- 状态机旁路：`blocked`（阻断，标明原因）、`deprecated`（废弃，保留历史记录）。