soloforge 1.1.37 → 1.1.40

package/templates/rules/shared//346/236/266/346/236/204/350/256/276/350/256/241/345/256/241/346/237/245/350/247/204/345/210/231.md

@@ -0,0 +1,102 @@
+---
+name: architecture-design-review
+type: review_rule
+scope: ['*']
+products: ['*']
+priority: P1
+stages: ["架构设计"]
+lifecycle_status: active
+owner_mechanism_id: mc-command-router
+triggers: ["架构审查","架构设计审查","architecture review"]
+---
+
+# 架构设计审查规则
+
+## ARCH-R01: 架构目标与需求对齐
+- severity: P0
+- check_type: deterministic
+- pattern: Ch2 架构目标中引用的 REQ-ID 覆盖率 ≥ 100%
+- evidence_required: "Ch2 架构目标表 + Ch3.2 功能需求引用表"
+- failure_message: "架构目标未覆盖 REQ-{ID}，或引用了不存在的 REQ-ID"
+
+## ARCH-R02: ADR 完整性
+- severity: P0
+- check_type: deterministic
+- pattern: MADR 必填字段完整（标题/状态/上下文/决策/候选方案/理由/后果）
+- evidence_required: "ADR 文件"
+- failure_message: "ADR 缺少必填字段"
+
+## ARCH-R03: 约束条件覆盖
+- severity: P1
+- check_type: deterministic
+- pattern: Ch3a 技术约束/组织约束/法规约束/预算约束各 ≥1 条
+- evidence_required: "架构设计文档 Ch3a"
+- failure_message: "约束条件未覆盖全部 4 类"
+
+## ARCH-R04: 模块边界清晰性
+- severity: P1
+- check_type: semantic
+- pattern: 模块单一职责，无过度耦合
+- evidence_required: "架构设计文档 Ch5"
+
+## ARCH-R05: 接口契约完备性
+- severity: P1
+- check_type: deterministic
+- pattern: 请求/响应/错误码完整
+- evidence_required: "架构设计文档 Ch8"
+
+## ARCH-R06: 数据模型一致性
+- severity: P1
+- check_type: deterministic
+- pattern: 实体关系完整/字段类型明确
+- evidence_required: "架构设计文档 Ch7"
+
+## ARCH-R07: NFR 量化可行性
+- severity: P2
+- check_type: semantic
+- pattern: 目标值可测量
+- evidence_required: "架构设计文档 Ch10.1"
+
+## ARCH-R08: 安全架构覆盖
+- severity: P1
+- check_type: deterministic
+- pattern: Ch6.4 包含认证方案 + 授权方案 + 数据加密策略
+- evidence_required: "架构设计文档 Ch6.4"
+
+## ARCH-R09: 部署方案可行性
+- severity: P2
+- check_type: semantic
+- pattern: 环境规划/CI/CD 方案完整
+- evidence_required: "架构设计文档 Ch6.5"
+
+## ARCH-R10: 风险应对充分性
+- severity: P1
+- check_type: semantic
+- pattern: Ch10.2 风险登记覆盖度充分
+- evidence_required: "架构设计文档 Ch10.2"
+
+## ARCH-R11: 跨横切关注点覆盖
+- severity: P2
+- check_type: deterministic
+- pattern: Ch13 日志/错误/缓存/配置 4 项至少各 1 条
+- evidence_required: "架构设计文档 Ch13"
+
+## ARCH-R12: 子产物一致性
+- severity: P1
+- check_type: deterministic
+- pattern: 数据库/接口文档引用在主产物中存在
+- evidence_required: "全产物交叉检查"
+
+## ARCH-R13: 改造影响范围完整性（老系统）
+- severity: P1
+- check_type: deterministic
+- pattern: 改造影响评估中每个受影响模块都有验证方式
+- evidence_required: "改造影响范围评估 §2 + §3"
+- system_scope: existing-system
+
+## ARCH-R14: 隔离适配器向后兼容（老系统）
+- severity: P0
+- check_type: deterministic
+- pattern: 隔离适配器方案中 API 语义差异行均有兼容策略
+- evidence_required: "隔离适配器方案 §2.4"
+- system_scope: existing-system

package/templates/rules/shared//346/236/266/346/236/204/350/256/276/350/256/241/350/247/204/345/210/231.md

@@ -0,0 +1,64 @@
+---
+name: architecture-design
+type: governance_rule
+scope: ['*']
+products: ['*']
+priority: P1
+stages: ["架构设计"]
+lifecycle_status: active
+owner_mechanism_id: mc-command-router
+triggers: ["架构设计规则","架构规则","architecture rule"]
+---
+
+# 架构设计规则
+
+## 架构决策要求
+
+- 每个架构决策必须有 ADR（Architecture Decision Record）引用
+- ADR 必须包含：决策背景、候选方案、选择理由、影响范围
+- 重大架构变更（涉及 ≥3 个模块）必须经过决策研讨阶段确认
+
+## 技术选型要求
+
+- 技术选型必须列出至少 2 个候选方案
+- 每个候选方案必须列出优势和劣势
+- 最终选择必须有明确的理由说明（性能/成本/团队熟悉度/生态成熟度等）
+- 禁止仅凭"业界主流"作为选型理由
+- ARCH-MOD-04: 技术选型须有 NFR 量化对比
+  格式：{候选技术} {NFR维度} {量化指标} {数据来源}
+  示例：Redis vs Memcached 缓存命中率 >99.9% 基准测试报告
+
+## 技术选型格式要求
+
+- ARCH-TECH-01: 技术选型决策必须包含以下字段
+  - 候选方案（≥2 个）
+  - 评估维度（性能/成熟度/团队熟悉度/社区活跃度/许可证）
+  - 评分矩阵（每维度 1-5 分）
+  - 最终选择 + 理由
+  - 关联 ADR-ID
+
+## 架构图要求
+
+- Mermaid 图必须反映实际模块关系，不得省略关键依赖
+- 每个模块的职责边界必须明确标注
+- 跨模块调用必须标注调用方向和数据流
+- 部署架构图必须包含所有基础设施组件
+
+## 模块依赖方向
+
+- ARCH-DEP-01: 模块间依赖必须遵循分层架构方向（上层→下层，禁止反向依赖）
+  检查方式：AST 依赖图分析
+  例外：通过依赖注入/事件解耦的反向调用不计入
+- ARCH-DEP-02: 循环依赖禁止（A→B→C→A）
+  检查方式：依赖图环检测
+  例外：无
+- ARCH-DEP-03: 跨层直接访问禁止（表现层不得直接访问数据层）
+  检查方式：import/require 链分析
+  例外：工具函数/类型定义可跨层引用
+
+## Mermaid 图类型约束
+
+- ARCH-MER-01: 系统上下文必须使用 C4Context 或 deploymentDiagram
+- ARCH-MER-02: 模块交互必须使用 graph (flowchart) 或 componentDiagram
+- ARCH-MER-03: 时序交互必须使用 sequenceDiagram
+- ARCH-MER-04: 状态流转必须使用 stateDiagram-v2

package/templates/rules/shared//347/213/254/347/253/213/345/256/241/346/237/245/350/247/204/345/210/231.md

@@ -0,0 +1,33 @@
+---
+name: independent-review
+type: governance_rule
+scope:
+  - '*'
+stages: ["编码与单元测试"]
+lifecycle_status: active
+owner_mechanism_id: mc-command-router
+---
+
+# 独立审查规则
+
+## 审查测试要求
+
+- 每个任务完成后，独立审查必须新增 ≥9 个测试场景
+- 测试描述和场景必须与编码阶段的实施测试不同（不同角度、不同数据）
+- 审查测试必须覆盖：
+  - 全部公开接口（每个接口至少 2 个场景）
+  - 全部核心逻辑路径（正向 + 反向）
+  - 全部错误处理分支
+
+## 审查覆盖范围
+
+- 接口覆盖：每个公开方法/函数必须有审查测试
+- 逻辑路径覆盖：每个 if/switch 分支必须有测试用例
+- 边界值覆盖：数值边界、空值、超长输入
+- 并发/竞态覆盖（如适用）：多线程/异步场景
+
+## 审查独立性
+
+- 审查测试不得复制实施测试的代码和断言
+- 审查测试必须独立设计测试数据和场景
+- 审查发现的问题必须记录，不得直接修改代码绕过

package/templates/rules/shared//347/254/254/344/270/200/346/200/247/345/216/237/347/220/206/346/216/250/347/220/206/350/247/204/345/210/231.md

@@ -0,0 +1,171 @@
+---
+name: 第一性原理推理规则
+type: review_rule
+scope: ['*']
+stages: ["需求分析", "架构设计", "详细设计", "编码与单元测试"]
+lifecycle_status: active
+owner_mechanism_id: mc-generic-review
+id: ka-review-rule-第一性原理推理规则
+authority: canonical
+priority: P0
+version: 1.0.0
+last_reviewed: '2026-06-04'
+triggers: ["first_principles", "第一性原理", "fundamental_need", "根因分析", "表面修复"]
+---
+
+# 第一性原理推理规则
+
+## FP-01: fundamental_need 声明
+- id: FP-01
+- name: fundamental_need 声明
+- severity: error
+- check_type: semantic
+- evidence_required: 需求分析模版第 1 章 `fundamental_need` 字段存在且非空
+- evidence_producer: AI Agent 推导 + 用户确认
+- 首次触发点: 需求分析阶段
+- rule: 需求描述不得以解决方案开头，必须以用户目标开头。需求分析模版 §1.3 的 fundamental_need 字段必须存在且非空，且不得包含技术方案描述（如"做一个XX页面"），必须描述用户目标（如"用户需要在一次会话中完成XX"）。
+
+## FP-02: 推理链完整性
+- id: FP-02
+- name: 推理链完整性
+- severity: error
+- check_type: semantic
+- evidence_required: 原型说明模版第 1 章有推理依据字段，或架构决策研讨记录含推理链
+- evidence_producer: AI Agent 逐步填写 + 用户确认
+- rule: 从 fundamental_need 到最终方案的推理链至少 3 步（目标→约束→可选方案→选定方案），每步必须有明确依据。推理链断裂（跳跃式推导）即标记为 error。
+
+## FP-03: 表面修复检测
+- id: FP-03
+- name: 表面修复检测
+- severity: warning
+- check_type: semantic
+- evidence_required: 历史修复记录中同类问题出现次数 ≥ 3
+- detection_source:
+  1. 当前会话中同一模块的修复次数
+  2. git log 中 fix 提交的同类问题计数
+  3. issue tracker 中同一模块的问题计数
+- rule: 同一模块同类问题 ≥ 3 次 → 提示进行第一性原理推理，识别根因而非继续表面修复。检测到时建议触发 FP-01 重新审视 fundamental_need。
+
+## FP-04: 关键词替代语义检测
+- id: FP-04
+- name: 关键词替代语义检测
+- severity: warning
+- check_type: semantic
+- evidence_required: 新旧方案关键字段对比，语义对齐确认记录
+- rule: 新旧方案对比——术语变更后逻辑是否与新术语语义一致。当方案中使用新术语替换旧术语时，须确认替换后的逻辑仍与新术语的语义一致，而非仅替换关键词但保留旧语义。
+
+## 5. 高影响任务判定标准
+
+以下情况属于高影响任务，须优先执行 FP-01~04 检查：
+
+1. **涉及 3 个以上模块的变更**：跨模块变更影响面广，推理链断裂风险高
+2. **涉及外部系统集成的变更**：外部接口的 fundamental_need 可能被忽视
+3. **涉及数据模型变更**：数据模型变更的根因可能是需求理解偏差
+4. **涉及安全/支付/金额相关逻辑**：高风险领域不容表面修复
+5. **涉及状态机/流程引擎的变更**：状态变更的根因分析须从 fundamental_need 出发
+
+## 6. 阻断恢复机制
+
+- FP 规则检查失败时，最多重试 3 次：
+  1. 第 1 次：提示用户补充信息
+  2. 第 2 次：AI 尝试从上下文推断并呈现给用户确认
+  3. 第 3 次：列举已知约束请求用户决策
+- 3 次重试仍失败 → 降级为 warning（非阻断），记录未确认项到产物中
+- 降级后继续执行当前阶段，但未确认项须在下一阶段门禁前解决
+
+## 7. 规则引擎接口
+
+```typescript
+interface FPRuleResult {
+  rule_id: "FP-01" | "FP-02" | "FP-03" | "FP-04";
+  passed: boolean;
+  severity: "error" | "warning";
+  message: string;
+  evidence: string;
+  retry_count: number;
+  degraded: boolean;
+}
+
+interface FPCheckContext {
+  stage: string;
+  fundamental_need?: string;
+  reasoning_chain?: string[];
+  fix_history?: Array<{ module: string; description: string; timestamp: string }>;
+  old_terms?: Record<string, string>;
+  new_terms?: Record<string, string>;
+}
+
+function checkFirstPrinciples(ctx: FPCheckContext): FPRuleResult[] {
+  const results: FPRuleResult[] = [];
+
+  // FP-01: fundamental_need 检查
+  if (!ctx.fundamental_need || ctx.fundamental_need.trim() === "") {
+    results.push({
+      rule_id: "FP-01",
+      passed: false,
+      severity: "error",
+      message: "fundamental_need 未声明或为空",
+      evidence: "需求分析模版 §1.3",
+      retry_count: 0,
+      degraded: false,
+    });
+  }
+
+  // FP-02: 推理链完整性
+  if (!ctx.reasoning_chain || ctx.reasoning_chain.length < 3) {
+    results.push({
+      rule_id: "FP-02",
+      passed: false,
+      severity: "error",
+      message: `推理链不足 3 步（当前 ${ctx.reasoning_chain?.length ?? 0} 步）`,
+      evidence: "推理链步骤",
+      retry_count: 0,
+      degraded: false,
+    });
+  }
+
+  // FP-03: 表面修复检测
+  if (ctx.fix_history) {
+    const moduleCounts: Record<string, number> = {};
+    for (const fix of ctx.fix_history) {
+      moduleCounts[fix.module] = (moduleCounts[fix.module] ?? 0) + 1;
+    }
+    for (const [module, count] of Object.entries(moduleCounts)) {
+      if (count >= 3) {
+        results.push({
+          rule_id: "FP-03",
+          passed: false,
+          severity: "warning",
+          message: `模块 ${module} 同类修复 ${count} 次，建议进行根因分析`,
+          evidence: `修复记录: ${count} 次`,
+          retry_count: 0,
+          degraded: false,
+        });
+      }
+    }
+  }
+
+  // FP-04: 关键词替代语义检测
+  if (ctx.old_terms && ctx.new_terms) {
+    const mismatched: string[] = [];
+    for (const [key, oldTerm] of Object.entries(ctx.old_terms)) {
+      if (ctx.new_terms[key] && ctx.new_terms[key] !== oldTerm) {
+        mismatched.push(`${oldTerm} → ${ctx.new_terms[key]}`);
+      }
+    }
+    if (mismatched.length > 0) {
+      results.push({
+        rule_id: "FP-04",
+        passed: false,
+        severity: "warning",
+        message: `术语替换须确认语义一致: ${mismatched.join(", ")}`,
+        evidence: `新旧术语对比`,
+        retry_count: 0,
+        degraded: false,
+      });
+    }
+  }
+
+  return results;
+}
+```

package/templates/rules/shared//347/274/226/347/240/201/345/260/261/347/273/252/345/256/241/346/237/245/350/247/204/345/210/231.md

@@ -1,30 +1,20 @@
 ---
 name: coding-readiness-review
 type: review_rule
-when: '编码准备, 编码就绪, coding readiness'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-review-rule-编码就绪审查规则
-asset_kind: review_rule
 lifecycle_status: active
 owner_mechanism_id: mc-coding-readiness
 authority: supporting
-routes:
-  - code_change
-primary_triggers:
-  - 编码就绪审查规则
-secondary_triggers:
-  - 编码准备
-  - 就绪检查
-negative_triggers: []
 priority: P1
-specificity: 5
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 stages: ["编码与单元测试"]
+triggers: ["编码准备","编码就绪","coding readiness"]
 ---
 
 # 编码就绪审查规则
@@ -32,7 +22,8 @@ stages: ["编码与单元测试"]
 ## READY-01: CodingReadiness 非空
 
 pattern: 编码前必须确认 CodingReadiness 检查已通过
-severity: warning
+severity: error
+check_type: deterministic
 scope: [backend, frontend]
 description: CodingReadiness 报告必须存在且 status 非 blocked；blocked 状态必须先解决前置问题
 
@@ -40,13 +31,15 @@ description: CodingReadiness 报告必须存在且 status 非 blocked；blocked
 
 pattern: OOD 设计摘要必须包含类定义、方法签名和协作关系
 severity: warning
+check_type: deterministic
 scope: [backend, frontend]
 description: OOD 摘要至少包含：核心类名、公开方法签名、类间协作关系图；缺少任一项必须补充后再编码
 
 ## READY-03: 前置产物已确认
 
 pattern: 编码依赖的设计产物必须全部就绪
-severity: warning
+severity: error
+check_type: deterministic
 scope: [backend, frontend]
 description: API 接口规格、数据库设计文档、切片计划等编码依赖产物必须已生成且无 hard_fail
 
@@ -54,5 +47,6 @@ description: API 接口规格、数据库设计文档、切片计划等编码依
 
 pattern: 编码前必须确认使用的技术栈和框架版本
 severity: warning
+check_type: deterministic
 scope: [backend, frontend]
 description: 语言版本、框架版本、关键依赖版本必须在编码前明确，避免编码过程中变更技术栈

package/templates/rules/shared//350/201/224/350/260/203/351/252/214/350/257/201/346/270/205/345/215/225.md

@@ -1,32 +1,76 @@
 ---
 name: integration-verification-list
 type: review_rule
-asset_kind: review_rule
-routes:
-  - code_change
-primary_triggers:
-  - 联调验证
-  - 验证清单
 scope: ['*']
-stages: ["联调验证"]
+id: ka-review-rule-联调验证清单
 lifecycle_status: active
+authority: canonical
 owner_mechanism_id: mc-generic-review
+priority: P1
+version: 1.2.0
+last_reviewed: '2026-06-04'
+stages: ["联调验证"]
+triggers: ["联调验证","集成验证","端到端验证","E2E","联调测试"]
 ---
 
 # 联调验证清单
 
-## 端到端验证
-- [ ] 所有切片的代码已集成
-- [ ] 主链路接口调用链路通畅
-- [ ] 数据库读写正常
-- [ ] 构建通过（编译无错误）
+## IV-E2E-01: 所有切片代码已集成
+- id: IV-E2E-01
+- name: 所有切片代码已集成
+- severity: error
+- check_type: deterministic
+- evidence_required: 切片计划中所有 SLC 的代码提交记录
+- rule: 切片计划中所有 SLC 编号对应的代码必须已合并到集成分支，无遗漏切片
+
+## IV-E2E-02: 主链路接口调用链路通畅
+- id: IV-E2E-02
+- name: 主链路接口调用链路通畅
+- severity: error
+- check_type: deterministic
+- evidence_required: 主链路接口调用日志（请求+响应状态码）
+- rule: 主链路涉及的全部接口必须可正常调用，无 500/超时/参数不匹配
+
+## IV-E2E-03: 数据库读写正常
+- id: IV-E2E-03
+- name: 数据库读写正常
+- severity: error
+- check_type: deterministic
+- evidence_required: 数据库连接验证日志 + CRUD 操作测试输出
+- rule: 数据库连接正常，所有涉及的表 CRUD 操作均可正常执行
+
+## IV-E2E-04: 构建通过
+- id: IV-E2E-04
+- name: 构建通过
+- severity: error
+- check_type: deterministic
+- evidence_required: 构建输出日志（0 errors）+ 产物时间戳
+- rule: 项目构建必须无错误通过（编译 0 errors），产物时间戳为本次构建
+
+## IV-WEB-01: 本地服务启动成功
+- id: IV-WEB-01
+- name: 本地服务启动成功
+- severity: error
+- check_type: deterministic
+- evidence_required: 服务启动日志 + 健康检查端点响应
+- rule: 本地服务必须可正常启动，健康检查端点返回 200
+
+## IV-WEB-02: 浏览器可访问核心页面
+- id: IV-WEB-02
+- name: 浏览器可访问核心页面
+- severity: warning
+- check_type: deterministic
+- evidence_required: 核心页面浏览器截图
+- rule: 核心业务页面在浏览器中可正常加载和渲染，无白屏/JS 错误
 
-## Web 服务验证（如适用）
-- [ ] 本地服务启动成功
-- [ ] 浏览器可访问核心页面
-- [ ] 核心交互流程可走通
-- [ ] 接口返回格式符合 openapi.yaml 定义
+## IV-WEB-03: 接口返回格式符合 OpenAPI 定义
+- id: IV-WEB-03
+- name: 接口返回格式符合 OpenAPI 定义
+- severity: error
+- check_type: deterministic
+- evidence_required: 接口实际响应与 OpenAPI Schema 比对结果
+- rule: 所有接口返回的 HTTP 状态码、响应体结构、字段类型必须与 OpenAPI 定义完全一致
 
 ## 严重设计缺陷判定
 
-> 详见 `rules/new-system/联调设计缺陷判定规则.md`
+> 详见 `rules/new-system/联调设计缺陷判定规则.md`（结构化规则见 DEF-01~04）

package/templates/rules/shared//350/246/206/347/233/226/347/216/207/346/240/207/345/207/206.md

@@ -1,16 +1,14 @@
 ---
 name: coverage-standard
 type: review_rule
-when: 测试覆盖率校验
 scope: ['*']
 products: ['*']
 lifecycle_status: active
-asset_kind: review_rule
 owner_mechanism_id: mc-generic-review
-routes: ['code_change', 'review']
-primary_triggers: [覆盖率, 测试, 覆盖]
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["覆盖率","测试","覆盖"]
 ---
+
 # 覆盖率标准
 
 ## 新系统

package/templates/rules/shared//350/257/246/347/273/206/350/256/276/350/256/241/345/256/241/346/237/245/350/247/204/345/210/231.md

@@ -0,0 +1,82 @@
+---
+name: detail-design-review
+type: review_rule
+scope: ['*']
+products: ['*']
+priority: P1
+stages: ["详细设计"]
+lifecycle_status: active
+owner_mechanism_id: mc-command-router
+version: 1.2.0
+last_reviewed: '2026-06-04'
+triggers: ["详细设计审查","设计审查","DD-REV","detail design review"]
+---
+
+
+# 详细设计审查规则
+
+> **DD-REV vs CON-DD 职责划分**：
+> - **DD-REV** 检查**引用格式**（"每个模块是否有 ARCH-* 引用"）
+> - **CON-DD** 检查**覆盖完整性**（"架构文档中所有实体是否无遗漏"）
+> - 两者互补：DD-REV 确保引用正确，CON-DD 确保没有遗漏
+
+## 对照架构设计交叉验证
+
+### DD-REV-01: 模块引用格式
+- pattern: 详细设计中的每个模块必须引用架构设计文档中的 ARCH-* 编号
+- severity: error
+- description: 禁止无 ARCH-* 引用的模块设计。每个模块必须在架构设计文档中有明确对应。
+- evidence: 模块定义行包含 [ARCH-XX] 引用标记。
+- check_focus: 引用格式——检查"是否有引用"，不检查覆盖完整性（覆盖由 CON-DD-01 负责）
+
+### DD-REV-02: 实体引用格式
+- pattern: 数据库设计中每张表必须标注来源 ARCH-* 编号
+- severity: error
+- description: 数据库设计文档中的每张表必须标注来源 ARCH-* 编号。
+- evidence: 表定义行包含 [ARCH-XX] 引用标记。
+- check_focus: 引用格式——不检查实体是否遗漏（遗漏由 CON-DD-01 负责）
+
+### DD-REV-03: API 引用格式
+- pattern: API 接口规格中的每个 endpoint 必须标注来源 ARCH-* 编号
+- severity: error
+- description: 每个 endpoint 必须引用架构设计中的模块定义。
+- evidence: endpoint 定义行包含 [ARCH-XX] 引用标记。
+
+### DD-REV-04: 无未定义扩展
+- pattern: 详细设计不得引入架构文档未定义的新模块/层次/实体
+- severity: error
+- description: 所有新增模块必须先更新架构设计文档获得 ARCH-* 编号。发现未定义扩展时回退到架构设计阶段。
+
+## 接口规格一致性
+
+### DD-REV-05: OpenAPI 同步
+- pattern: openapi.yaml 必须与详细设计中的接口规格完全一致
+- severity: error
+- description: 路径、方法、参数、返回值逐一匹配。以详细设计为准同步 openapi。
+- evidence: 逐一比对结果记录（endpoint_id + 一致性状态）。
+
+### DD-REV-06: 字段级匹配
+- pattern: 接口规格文档中每个字段必须在 openapi.yaml 中有对应定义
+- severity: error
+- description: 字段名、类型、约束、枚举值必须完全一致。允许 openapi 更详细但不允许不一致。
+- evidence: 字段级比对清单。
+
+## 字段级追踪矩阵
+
+### DD-REV-07: 数据库字段追溯
+- pattern: 数据库设计文档中每个字段必须追溯到 REQ-* 或 ARCH-*
+- severity: error
+- description: 追踪链：表→ARCH-XX→REQ-XX。计算字段标注"系统生成"即可。
+- evidence: 追踪矩阵无空缺项。
+
+### DD-REV-08: API 参数追溯
+- pattern: API 接口规格中每个参数必须追溯到业务流程中的使用场景
+- severity: warning
+- description: 每个参数标注调用场景。无法追溯的标注"预留"并附理由。
+- evidence: API 参数表无空缺项。
+
+### DD-REV-09: 追踪矩阵完整性
+- pattern: 追踪矩阵必须完整覆盖所有设计元素
+- severity: error
+- description: 覆盖模块↔ARCH-*/表↔ARCH-*/字段↔REQ-*/API endpoint↔ARCH-*/API字段↔DD-*。所有空缺项必须在未决项中说明。
+- evidence: 追踪矩阵 100% 覆盖或有未决项说明。