universal-dev-standards 4.2.0 → 5.0.0-beta.10

package/bundled/locales/zh-CN/core/refactoring-standards.md

@@ -1,8 +1,8 @@
 ---
 source: ../../../core/refactoring-standards.md
-source_version: 2.0.0
-translation_version: 2.0.0
-last_synced: 2026-01-21
+source_version: 2.1.0
+translation_version: 2.1.0
+last_synced: 2026-02-10
 status: current
 ---
 

package/bundled/locales/zh-CN/core/reverse-engineering-standards.md

@@ -213,10 +213,10 @@ describe('Authentication', () => {
 
 ### 技能参考
 
-- [反向工程技能](../../../skills/claude-code/reverse-engineer/SKILL.md) - 详细工作流程实作
-- [规格驱动开发技能](../../../skills/claude-code/spec-driven-dev/SKILL.md) - SDD 整合
-- [BDD 助手技能](../../../skills/claude-code/bdd-assistant/SKILL.md) - Gherkin 撰写
-- [TDD 助手技能](../../../skills/claude-code/tdd-assistant/SKILL.md) - 测试覆盖分析
+- [反向工程技能](../../../skills/reverse-engineer/SKILL.md) - 详细工作流程实作
+- [规格驱动开发技能](../../../skills/spec-driven-dev/SKILL.md) - SDD 整合
+- [BDD 助手技能](../../../skills/bdd-assistant/SKILL.md) - Gherkin 撰写
+- [TDD 助手技能](../../../skills/tdd-assistant/SKILL.md) - 测试覆盖分析
 
 ---
 
@@ -224,9 +224,9 @@ describe('Authentication', () => {
 
 - [反幻觉指南](anti-hallucination.md) - 基于证据的分析要求
 - [规格驱动开发](spec-driven-development.md) - 规格工作流程
-- [行为驱动开发](behavior-driven-development.md) - Given-When-Then 情境
+- [行为驱动开发](../../../core/behavior-driven-development.md) - Given-When-Then 情境
 - [测试驱动开发](test-driven-development.md) - 红-绿-重构循环
-- [验收测试驱动开发](acceptance-test-driven-development.md) - 验收条件
+- [验收测试驱动开发](../../../core/acceptance-test-driven-development.md) - 验收条件
 - [程序码审查清单](code-review-checklist.md) - 审查指南
 
 ---

package/bundled/locales/zh-CN/core/spec-driven-development.md

@@ -1,29 +1,212 @@
 ---
 source: ../../../core/spec-driven-development.md
-source_version: 1.3.0
-translation_version: 1.3.0
-last_synced: 2026-01-19
+source_version: 2.1.0
+translation_version: 2.1.0
+last_synced: 2026-01-26
 status: current
 ---
 
 # 规格驱动开发 (SDD) 标准
 
-**版本**: 1.3.0
-**最后更新**: 2026-01-19
-**适用范围**: 所有采用规格驱动开发的专案
+**版本**: 2.1.0
+**最后更新**: 2026-01-26
+**适用范围**: 所有采用规格驱动开发的项目
+**范围**: universal
 
-> **语言**: [English](../../../core/spec-driven-development.md) | [繁体中文](../locales/zh-TW/core/spec-driven-development.md)
+> **语言**: [English](../../../core/spec-driven-development.md) | [繁體中文](../../zh-TW/core/spec-driven-development.md)
 
 ---
 
 ## 目的
 
-本标准定义规格驱动开发 (SDD) 的原则与工作流程，确保变更在实作前已经过规划、记录并透过规格核准。
+本标准定义规格驱动开发 (SDD) 的原则与工作流程，确保变更在实施前已经过规划、记录并透过规格核准。
 
-**主要效益**:
-- 减少利害关系人与开发者之间的沟通误解
+**关键效益**:
+- 减少利益相关者与开发者之间的沟通误解
 - 为所有变更提供清晰的审计轨迹
-- 新成员更容易上手
+- 新团队成员更容易上手
+
+---
+
+## SDD 作为独立方法论
+
+SDD (Spec-Driven Development, 2025) 是 AI 时代的方法论，区别于传统的 TDD/BDD/ATDD 家族。它源于 AI 辅助开发工具的日益普及和现代软件工程对规格优先方法的需求。
+
+### 历史背景
+
+| 方法论家族 | 时代 | 核心文献 | 关系 |
+|-----------|-----|---------|------|
+| **TDD/BDD/ATDD** | 1999-2011 | GOOS (Freeman & Pryce), Dan North, Gojko Adzic | 传统测试驱动开发家族 |
+| **SDD (2025)** | 2025+ | Thoughtworks, GitHub spec-kit, Martin Fowler | AI 时代新兴概念，独立于传统家族 |
+
+### 与测试方法论的关系
+
+SDD **不是** "ATDD → BDD → TDD" 序列的一部分。相反，它通过正向推导生成测试工件，但仍然是一个独立的方法论。
+
+| 方法论 | 起源 | 关注点 | SDD 集成 |
+|--------|------|-------|---------|
+| **TDD** | 1999, Kent Beck | 代码级测试 | 可在 SDD 实施阶段使用 |
+| **BDD** | 2006, Dan North | 行为场景 | 正向推导生成 .feature 文件 |
+| **ATDD** | 2003-2006, GOOS | 协作验收 | 可选的 AC 定义输入方法 |
+
+### 关键区别
+
+```
+┌─────────────────────────────────────────────────────────────────────────────┐
+│                    两个独立方法论系统                                   │
+├─────────────────────────────────────────────────────────────────────────────┤
+│                                                                             │
+│   ┌─────────────────────────────────────┐                                   │
+│   │     SDD (AI 时代方法论)           │                                  │
+│   │                                      │                                  │
+│   │   需求 → SPEC.md → 正向推导 → 测试 │                                  │
+│   │                                      │                                  │
+│   │   • 规格是权威来源                 │                                  │
+│   │   • AI 辅助代码生成                │                                  │
+│   │   • 正向推导生成测试结构            │                                  │
+│   └─────────────────────────────────────┘                                   │
+│                                                                             │
+│   ┌─────────────────────────────────────┐                                   │
+│   │  双循环 TDD (传统)                 │                                  │
+│   │                                      │                                  │
+│   │   BDD (外层循环) → TDD (内层循环)  │                                  │
+│   │                                      │                                  │
+│   │   • 测试驱动设计                   │                                  │
+│   │   • 手动开发                       │                                  │
+│   │   • ATDD 是可选协作输入，不是顺序步骤 │                                  │
+│   └─────────────────────────────────────┘                                   │
+│                                                                             │
+└─────────────────────────────────────────────────────────────────────────────┘
+```
+
+---
+
+## SDD 成熟度级别
+
+基于 Martin Fowler 对 SDD 工具的分析 (2025)，团队可以在不同的成熟度级别运作：
+
+| 级别 | 名称 | 描述 | 人类角色 |
+|-------|------|------|---------|
+| 1 | **规格优先** | 编写规格，完成后丢弃 | 编辑规格和代码 |
+| 2 | **规格锚定** | 在整个演进过程中维护规格 | 编辑规格，AI 协助代码 |
+| 3 | **规格即源** | 规格是唯一来源，代码自动生成 | 只编辑规格，从不接触代码 |
+
+### 级别特征
+
+**级别 1: 规格优先**
+- 在实施前编写规格
+- 规格可能在功能完成后丢弃
+- 代码仍然是权威来源
+- 2025 年最常见
+
+**级别 2: 规格锚定**
+- 在整个生命周期中维护规格
+- 规格用于演进和维护
+- AI 基于规格更新协助代码变更
+- 在企业环境中日益普及
+
+**级别 3: 规格即源**
+- 规格是唯一的事实来源
+- 代码标记为"已生成 - 请勿编辑"
+- 任何变更都需要先修改规格
+- 2025 年仍处于实验阶段
+
+### 参考资料
+
+- [Thoughtworks: Spec-Driven Development](https://www.thoughtworks.com/en-us/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices)
+- [Martin Fowler: SDD Tools (Kiro, spec-kit, Tessl)](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)
+- [GitHub spec-kit](https://github.com/github/spec-kit/blob/main/spec-driven.md)
+
+---
+
+## 常见陷阱
+
+采用 SDD 时避免这些常见陷阱：
+
+| 陷阱 | 问题 | 缓解措施 |
+|------|------|---------|
+| **过度形式化** | 像瀑布开发一样减缓反馈 | 保持迭代，使用短周期 |
+| **规格漂移** | 规格和代码变得不同步 | 持续验证，CI/CD 中的漂移检测 |
+| **AI 幻觉** | AI 生成不匹配规格的代码 | 强健验证，合约测试 |
+| **规模不匹配** | 为小错误使用重型工作流 | 基于复杂性选择适当流程 |
+| **过早优化** | 跳到规格即源 (级别 3) | 从规格优先开始，逐步演进 |
+
+### 何时不使用完整 SDD
+
+| 场景 | 建议 |
+|------|------|
+| 关键热修复 | 先修复，后记录文档 |
+| 错别字和格式 | 直接提交，无需规格 |
+| 探索性原型 | 跳过正式规格，快速迭代 |
+| 小错误修复 (< 30 分钟) | 仅轻量级跟踪 |
+
+---
+
+## 变更评估 (SDD 前评估)
+
+在开始 SDD 工作流程之前，评估变更的性质和范围。这可以防止过度工程化并确保变更被适当路由。
+
+### 评估决策树
+
+```
+新需求/变更
+    │
+    ▼
+┌─────────────────────────────────────────────────────────┐
+│ Q1: 这个变更的适用范围是什么？                         │
+├─────────────────────────────────────────────────────────┤
+│ A) 仅限项目特定内部使用                               │
+│    → 添加到 CLAUDE.md 或项目配置                      │
+│    → 无需核心标准                                    │
+│                                                      │
+│ B) 可重用于其他项目的规则                             │
+│    → 创建核心标准                                    │
+│    → 评估是否需要技能/命令                            │
+└─────────────────────────────────────────────────────────┘
+    │
+    ▼
+┌─────────────────────────────────────────────────────────┐
+│ Q2: 这个功能需要 AI 交互吗？                           │
+├─────────────────────────────────────────────────────────┤
+│ A) 需要交互式工作流                                 │
+│    → 创建技能                                        │
+│    → 评估是否需要斜线命令                            │
+│                                                      │
+│ B) 静态规则/背景知识                                 │
+│    → 仅核心标准                                      │
+│    → 在 CLAUDE.md 中引用                            │
+└─────────────────────────────────────────────────────────┘
+    │
+    ▼
+┌─────────────────────────────────────────────────────────┐
+│ Q3: 用户需要直接触发吗？                              │
+├─────────────────────────────────────────────────────────┤
+│ A) 需要 /command 触发                                │
+│    → 创建斜线命令                                    │
+│                                                      │
+│ B) AI 自动应用                                       │
+│    → 仅技能，无需命令                                │
+└─────────────────────────────────────────────────────────┘
+```
+
+### 评估结果
+
+| 评估结果 | 要创建的工件 |
+|----------|-------------|
+| 仅限项目特定 | 仅更新 CLAUDE.md |
+| 通用静态规则 | 核心标准 + CLAUDE.md 引用 |
+| 通用交互式 | 核心标准 + 技能 |
+| 用户触发工作流 | 核心标准 + 技能 + 命令 |
+
+### 范围分类标签
+
+在规格文档中使用这些标签指示范围：
+
+| 标签 | 含义 | 示例 |
+|------|------|------|
+| `[范围: 项目]` | 项目特定，不用于分发 | CI/CD 配置，团队约定 |
+| `[范围: 通用]` | 其他项目可重用 | 编码标准，测试模式 |
+| `[范围: 工具]` | 工具/生成器，无需核心标准 | docs-generator, code-formatter |
 
 ---
 
@@ -178,6 +361,55 @@ Refs: SPEC-001
 
 ---
 
+## 双向同步评估
+
+在处理规格及其实现时，始终评估需要同步的内容。变更可以源自任何工件，并应传播到相关工件。
+
+### 同步矩阵
+
+| 变更来源 | 评估同步到 |
+|----------|------------|
+| 核心标准 | → 技能、命令、AI YAML、翻译 |
+| 技能 | → 核心标准（如适用）、命令、翻译 |
+| 命令 | → 技能、核心标准（如适用）、翻译 |
+
+### 同步检查清单模板
+
+在规格文档中包含此检查清单：
+
+```markdown
+## 同步检查清单
+
+### 从核心标准开始
+- [ ] 创建/更新相应技能？（如交互式）
+- [ ] 创建/更新斜线命令？（如用户触发）
+- [ ] 更新翻译？（zh-TW、zh-CN 等）
+- [ ] 更新 AI YAML 版本？（如适用）
+
+### 从技能开始
+- [ ] 这个技能应该有核心标准吗？
+- [ ] 如果是工具技能（例如 docs-generator），标记为"[范围: 工具]"
+- [ ] 创建斜线命令？
+- [ ] 更新翻译？
+
+### 从命令开始
+- [ ] 这个命令属于哪个技能？
+- [ ] 更新技能文档？
+- [ ] 更新翻译？
+```
+
+### 同步标记
+
+在文档中使用这些标记指示同步状态：
+
+| 标记 | 含义 |
+|------|------|
+| `[已同步: ✓]` | 所有相关工件已同步 |
+| `[已同步: 待定]` | 需要同步但尚未完成 |
+| `[已同步: 不适用]` | 无相关工件同步（例如独立工具） |
+
+---
+
 ## 与反向工程集成
 
 ### 概述
@@ -247,12 +479,271 @@ Refs: SPEC-001
 
 ---
 
+## 与正向推导集成
+
+### 概述
+
+规格批准后，使用[正向推导标准](../../../core/forward-derivation-standards.md)自动从验收标准生成 BDD 场景、TDD 测试骨架和 ATDD 验收测试。
+
+### 正向推导 → SDD 流水线
+
+```
+┌─────────────────────────────────────────────────────────────────────────┐
+│                  已批准规格 → 正向推导流水线                          │
+├─────────────────────────────────────────────────────────────────────────┤
+│                                                                         │
+│   已批准的 SPEC-XXX.md                                                   │
+│        │                                                                │
+│        ▼                                                                │
+│   ┌────────────────────────────────────────────────────────────┐       │
+│   │ /derive-all specs/SPEC-XXX.md                               │       │
+│   │   • 解析验收标准                                      │       │
+│   │   • 转换 AC → Gherkin 场景 [已生成]                   │       │
+│   │   • 生成 TDD 测试骨架 [已生成]                        │       │
+│   │   • 创建 ATDD 验收表 [已生成]                         │       │
+│   └────────────────────────────────────────────────────────────┘       │
+│        │                                                                │
+│        ▼                                                                │
+│   输出文件                                                              │
+│   ├── features/SPEC-XXX.feature (BDD)                                  │
+│   ├── tests/SPEC-XXX.test.ts (TDD)                                     │
+│   └── acceptance/SPEC-XXX-acceptance.md (ATDD)                         │
+│        │                                                                │
+│        ▼                                                                │
+│   人工审查 → BDD/TDD 工作流程继续                                      │
+│                                                                         │
+└─────────────────────────────────────────────────────────────────────────┘
+```
+
+### 何时使用正向推导
+
+| 场景 | 方法 |
+|------|------|
+| 规格已批准，开始实施 | 使用 `/derive-all` 生成测试结构 |
+| 需要快速 BDD 场景 | 使用 `/derive-bdd` 生成 Gherkin |
+| 开始 TDD 工作流 | 使用 `/derive-tdd` 生成测试骨架 |
+| 手动验收测试 | 使用 `/derive-atdd` 生成测试表 |
+
+### 相关命令
+
+| 命令 | 输入 | 输出 | 用途 |
+|------|------|------|------|
+| `/derive-bdd` | SPEC-XXX.md | .feature | AC → Gherkin 场景 |
+| `/derive-tdd` | SPEC-XXX.md | .test.ts | AC → 测试骨架 |
+| `/derive-atdd` | SPEC-XXX.md | acceptance.md | AC → 测试表 |
+| `/derive-all` | SPEC-XXX.md | 全部以上 | 完整推导流水线 |
+| `/derive-contracts` | SPEC-XXX.md | contract.json, schema.json | AC → 合约验证 |
+
+---
+
+## 验证层
+
+SDD 需要强大的验证机制，以确保生成的代码与规格保持一致。验证层在整个开发生命周期中提供持续验证。
+
+### 理论基础
+
+| 理论 | 来源 | 在 SDD 中的应用 |
+|------|------|---------------|
+| **设计合约** | Bertrand Meyer, 1986 | AC 作为前置/后置条件 |
+| **形式化验证** | 计算机科学 | 规格 vs 实现 |
+| **示例规格化** | Gojko Adzic, 2011 | 可执行规格 |
+| **合约测试** | Pact, 2013+ | 服务合约验证 |
+
+### 验证机制
+
+| 机制 | 目的 | 工具 |
+|------|------|------|
+| **合约测试** | 验证实现遵守接口保证 | Pact, Spring Cloud Contract, Specmatic |
+| **模式验证** | 拒绝违反结构要求的负载 | JSON Schema, OpenAPI 验证器 |
+| **漂移检测** | 检测规格与行为之间的分歧 | CI/CD 集成, Specmatic |
+| **向后兼容性** | 将变更分类为添加/破坏 | OpenAPI 差异工具 |
+
+### SDD 验证流程
+
+```
+┌─────────────────────────────────────────────────────────────────────────────┐
+│                         SDD 验证层                                    │
+├─────────────────────────────────────────────────────────────────────────────┤
+│                                                                             │
+│   SPEC-XXX.md (已批准)                                                    │
+│        │                                                                    │
+│        ├──→ 正向推导                                                        │
+│        │         │                                                          │
+│        │         ├──→ 合约测试 (已生成)                                    │
+│        │         ├──→ 模式验证器 (已生成)                                   │
+│        │         ├──→ BDD 场景 (已生成)                                    │
+│        │         └──→ TDD 骨架 (已生成)                                    │
+│        │                                                                    │
+│        └──→ 实施 (AI 辅助)                                                 │
+│                  │                                                          │
+│                  ▼                                                          │
+│        ┌─────────────────────────────────────────────────────┐             │
+│        │              持续验证                              │             │
+│        │  ┌─────────────────────────────────────────────────┐│             │
+│        │  │ 合约测试              ✓/✗                   ││             │
+│        │  │ 模式验证              ✓/✗                   ││             │
+│        │  │ 漂移检测              ✓/✗                   ││             │
+│        │  │ BDD 场景              ✓/✗                   ││             │
+│        │  │ TDD 单元测试          ✓/✗                   ││             │
+│        │  └─────────────────────────────────────────────────┘│             │
+│        └─────────────────────────────────────────────────────┘             │
+│                  │                                                          │
+│                  ▼                                                          │
+│        验证报告 → 归档或迭代                                                │
+│                                                                             │
+└─────────────────────────────────────────────────────────────────────────────┘
+```
+
+### 生成的验证工件
+
+| 工件 | 目的 | 验证角色 |
+|------|------|----------|
+| `.feature` (BDD) | 行为场景 | 验收验证 |
+| `.test.ts` (TDD) | 单元测试骨架 | 实现验证 |
+| `acceptance.md` (ATDD) | 验收测试表 | 业务验证 |
+| `contract.json` | 合约定义 | 接口验证 |
+| `schema.json` | 模式定义 | 结构验证 |
+
+### SDD 中的 V&V
+
+- **验证** (正确构建): 合约测试通过，模式有效，代码匹配规格
+- **确认** (构建正确的事物): AC 已满足，利益相关者批准，业务价值已交付
+
+### 参考资料
+
+- [InfoQ: Spec-Driven Development - Validation Layer](https://www.infoq.com/articles/spec-driven-development/)
+- [Microsoft: Consumer-Driven Contract Testing](https://microsoft.github.io/code-with-engineering-playbook/automated-testing/cdc-testing/)
+- [维基百科: Formal Verification](https://en.wikipedia.org/wiki/Formal_verification)
+- [Specmatic: AI-powered API Contract Testing](https://specmatic.io/)
+
+---
+
+## SDD + 测试集成模型
+
+### 理论基础
+
+SDD 验证基于已建立的测试理论：
+
+```
+设计合约 (1986)        示例规格化 (2011)
+        │                              │
+        ▼                              ▼
+┌───────────────────────────────────────────────────────────────┐
+│               SDD 验证模型                                    │
+│                                                               │
+│   规格 (AC)  ←──→  合约测试  ←──→  实现                    │
+│       ↑                 ↑                      ↓              │
+│   前置/后置          验证机制            运行时            │
+│   条件                                        行为           │
+└───────────────────────────────────────────────────────────────┘
+```
+
+### 集成点
+
+| SDD 阶段 | 测试集成 | 理论 |
+|-----------|----------|------|
+| **规格编写** | AC = 前置/后置条件 | 设计合约 |
+| **正向推导** | 生成合约测试 | 可执行规格 |
+| **实施** | TDD (可选) | 测试驱动开发 |
+| **验证** | 合约测试 + 漂移检测 | 运行时验证 |
+| **归档** | 测试结果作为证据 | 可追溯性 |
+
+### 实用工作流程
+
+```
+┌─────────────────────────────────────────────────────────────────────────────┐
+│                    实用 SDD 工作流程                                   │
+├─────────────────────────────────────────────────────────────────────────────┤
+│                                                                             │
+│   【输入来源】(任选其一)                                                   │
+│   ├── 需求访谈 (最常见)                                                  │
+│   ├── 利益相关者邮件/文档                                                 │
+│   ├── 产品需求文档 (PRD)                                                   │
+│   └── ATDD 工作坊 (可选协作)                                              │
+│        ↓                                                                    │
+│   【SDD 提案编写】                                                        │
+│   SPEC-XXX.md 包括:                                                       │
+│   - 摘要、动机                                                            │
+│   - 详细设计                                                              │
+│   - 验收标准 (Given-When-Then)                                            │
+│   - 依赖关系、风险                                                        │
+│        ↓                                                                    │
+│   【审查与批准】                                                            │
+│        ↓                                                                    │
+│   【正向推导】                                                              │
+│   /derive-all → .feature, .test.ts, acceptance.md, contract.json            │
+│        ↓                                                                    │
+│   【实施】(TDD 可选)                                                       │
+│        ↓                                                                    │
+│   【验证】→ 【归档】                                                        │
+│                                                                             │
+└─────────────────────────────────────────────────────────────────────────────┘
+```
+
+### 与传统方法的关键调整
+
+1. **ATDD 工作坊是可选的**: 不是每个功能都需要正式工作坊
+2. **规格是起点**: 无论输入来源如何，都转换为 SPEC-XXX.md
+3. **Given-When-Then 嵌入**: AC 格式借鉴 BDD，但不需要正式 ATDD 流程
+4. **正向推导填补空白**: 自动生成测试结构，弥补缺少工作坊的不足
+
+---
+
+## 与正向/反向工程集成
+
+本标准与两个互补标准协同工作，形成完整的规格生态系统：
+
+```
+┌─────────────────────────────────────────────────────────────────────────┐
+│                    SDD 生态系统集成                                  │
+├─────────────────────────────────────────────────────────────────────────┤
+│                                                                         │
+│   遗留代码                    新功能                                 │
+│       │                              │                                  │
+│       ▼                              ▼                                  │
+│   ┌─────────────────┐        ┌─────────────────┐                        │
+│   │ 反向             │        │ SDD             │                        │
+│   │ 工程             │        │ (本标准)         │                        │
+│   │ 标准             │        │                 │                        │
+│   └────────┬────────┘        └────────┬────────┘                        │
+│            │                          │                                  │
+│            │  代码 → 规格             │  规格优先                        │
+│            │                          │                                  │
+│            ▼                          ▼                                  │
+│       ┌─────────────────────────────────────┐                           │
+│       │          SPEC-XXX.md                │                           │
+│       │    (已批准规格)                   │                           │
+│       └──────────────────┬──────────────────┘                           │
+│                          │                                               │
+│                          ▼                                               │
+│   ┌─────────────────────────────────────────────────────┐               │
+│   │          正向推导标准                                 │               │
+│   │                                                      │               │
+│   │   规格 → BDD (.feature)                              │               │
+│   │   规格 → TDD (.test.ts)                              │               │
+│   │   规格 → ATDD (acceptance.md)                        │               │
+│   └─────────────────────────────────────────────────────┘               │
+│                                                                         │
+└─────────────────────────────────────────────────────────────────────────┘
+```
+
+**何时使用每种方法**：
+
+| 场景 | 起点 | 使用的标准 |
+|------|------|-----------|
+| 新功能开发 | 不存在任何东西 | SDD → 正向推导 |
+| 记录现有代码 | 代码存在，无规格 | 反向工程 → SDD |
+| 向现有代码添加测试 | 规格存在 | 正向推导 |
+| 重大重构 | 代码存在，行为不明确 | 反向工程 → SDD → 正向推导 |
+
+---
+
 ## 相关标准
 
 - [反向工程标准](reverse-engineering-standards.md) - 程序码转规格转换
 - [测试驱动开发](test-driven-development.md) - TDD 工作流程与 SDD 集成
-- [行为驱动开发](behavior-driven-development.md) - BDD 工作流程与 Given-When-Then 情境
-- [验收测试驱动开发](acceptance-test-driven-development.md) - ATDD 工作流程与商业验收
+- [行为驱动开发](../../../core/behavior-driven-development.md) - BDD 工作流程与 Given-When-Then 情境
+- [验收测试驱动开发](../../../core/acceptance-test-driven-development.md) - ATDD 工作流程与商业验收
 - [测试标准](testing-standards.md) - 测试框架与最佳实践（或使用 `/testing-guide` 技能）
 - [测试完整性维度](test-completeness-dimensions.md) - 7 维度测试覆盖
 - [Commit 讯息指南](../../../core/commit-message-guide.md) - Commit 讯息规范
@@ -266,8 +757,11 @@ Refs: SPEC-001
 
 | 版本 | 日期 | 变更内容 |
 |------|------|----------|
+| 2.1.0 | 2026-01-26 | 新增：变更评估 (SDD 前评估) 章节，包含决策树、双向同步评估章节，包含同步矩阵和检查清单 |
+| 2.0.0 | 2026-01-25 | **重大重构**: 新增 SDD 作为独立方法论章节（将 SDD 与 TDD/BDD/ATDD 家族分离）、成熟度级别（Martin Fowler 2025）、常见陷阱、包含理论基础的验证层、SDD + 测试集成模型、/derive-contracts 命令 |
+| 1.4.0 | 2026-01-19 | 新增：与正向推导集成章节、推导命令 |
 | 1.3.0 | 2026-01-19 | 新增：与反向工程集成章节、相关命令 |
-| 1.2.0 | 2026-01-05 | 新增：IEEE 830-1998 和 SWEBOK v4.0 第 1 章（软体需求）至参考资料 |
+| 1.2.0 | 2026-01-05 | 新增：IEEE 830-1998 和 SWEBOK v4.0 第 1 章（软件需求）至参考资料 |
 | 1.1.0 | 2025-12-24 | 新增：工作流程图、规格范本、集成指南、最佳实践、相关标准、授权 |
 | 1.0.0 | 2025-12-23 | 初始 SDD 标准定义 |
 
@@ -281,6 +775,14 @@ Refs: SPEC-001
 - [IEEE 830-1998 - 软体需求规格](https://standards.ieee.org/ieee/830/1222/) - 需求文件标准
 - [SWEBOK v4.0 - 第 1 章：软体需求](https://www.computer.org/education/bodies-of-knowledge/software-engineering) - IEEE Computer Society
 
+### 验证理论
+
+- [Design by Contract - Bertrand Meyer, 1986](https://en.wikipedia.org/wiki/Design_by_contract) - 前置/后置条件理论
+- [维基百科: Formal Verification](https://en.wikipedia.org/wiki/Formal_verification) - 形式化验证理论
+- [Microsoft: Consumer-Driven Contract Testing](https://microsoft.github.io/code-with-engineering-playbook/automated-testing/cdc-testing/) - 合约测试框架
+- [Specmatic: AI-powered API Contract Testing](https://specmatic.io/) - 现代合约测试工具
+- [Gojko Adzic: Specification by Example](https://gojko.net/books/specification-by-example/) - 可执行规格 (2011)
+
 ---
 
 ## 授权