soloforge 1.1.37 → 1.1.40

package/templates/procedures//351/233/206/346/210/220/351/252/214/350/257/201/346/265/201/347/250/213.md

@@ -1,25 +1,16 @@
 ---
 name: integration-verification
 type: procedure
-when: '集成测试, 集成验证, E2E测试, 端到端验证, 联调测试, integration test, E2E'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-集成验证流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-verifier
-routes:
-  - code_change
-primary_triggers:
-  - 集成验证流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-verifier
 emits:
@@ -27,9 +18,10 @@ emits:
   - deviation_report
 required_evidence:
   - execution_evidence
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["集成测试","集成验证","E2E测试","端到端验证","联调测试","integration test","E2E"]
 ---
 
 ## 适用场景
@@ -40,6 +32,12 @@ stages: ["编码与单元测试", "联调验证"]
 2. 发现服务依赖和启动顺序
 3. 构建部署最新代码，验证构建产物新鲜度
 4. 收集运行时证据：API 动态验证、页面快照、控制台、网络请求
+4a. Evidence 级别分类：
+      - E0（不可接受）：dry-run/静态分析/AI 摘要/无运行时证据
+      - E1（最低要求）：API 响应日志/测试输出报告/控制台日志
+      - E2（推荐）：端到端浏览器验证截图 + API 响应 + 数据库状态验证
+      端到端核心业务流程验证（步骤 5）必须达到 E2 级别。
+      API 动态验证（步骤 4）至少达到 E1 级别。
 5. 端到端流程验证：从浏览器页面出发，不绕过前端直接调后端
 6. DDL 迁移必须在浏览器/API 测试前应用到运行数据库
 7. 发现缺陷时：先诊断再修复，修复后重新构建再验证

package/templates/procedures//351/234/200/346/261/202/346/276/204/346/270/205/346/265/201/347/250/213.md

@@ -1,35 +1,30 @@
 ---
 name: requirement-clarify
 type: procedure
-when: '需求澄清, 需求分析, 需求梳理, 理解需求, 需求确认, requirement, 需求评审'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-需求澄清流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
-owner_mechanism_id: mc-intent-router
-routes:
-  - code_change
-primary_triggers:
-  - 需求澄清流程
-secondary_triggers: []
-negative_triggers: []
+owner_mechanism_id: mc-command-router
 priority: P1
-specificity: 5
 consumes:
-  - mc-intent-router
+  - mc-command-router
+  - 不确定时头脑风暴流程
+  - 第一性原理推理规则
 emits:
   - requirement_baseline
+  - prototype_specification
   - terminology_glossary
 required_evidence:
   - execution_evidence
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.3.0
+last_reviewed: '2026-06-04'
 stages: ["需求分析"]
+triggers: ["需求澄清","需求分析","需求梳理","理解需求","需求确认","requirement","需求评审"]
 ---
 
 ## 适用场景
@@ -40,17 +35,27 @@ stages: ["需求分析"]
 2. 分离事实与决策：需求事实和架构决策分列记录，禁止将 AI 推论伪装为需求事实
 3. 运行术语一致性检查：识别同一概念不同命名，统一术语
 4. 标记未确认项：无法确认的需求标记为「待确认」，禁止猜测或跳过
+4a. **头脑风暴触发**：若用户表达不确定（"你看着办"/"都行"/"不确定"），或需求本身有矛盾/遗漏：
+   → 进入「不确定时头脑风暴流程」（templates/procedures/不确定时头脑风暴流程.md）
+   → 若 fundamental_need 为空 → 先触发 FP-01（第一性原理推理规则）
 5. 标注冲突和越界项：明确来源和处理方式（冲突标注来源，越界标注排除原因）
-6. 绑定菜单权限：菜单需求必须关联角色、页面、操作权限
-7. 声明写操作的失败反馈：每个用户可见写操作必须有提示文案、重试建议、是否可恢复
-8. 冻结需求基线：按需求 ID 冻结验收信号和重新打开条件
+6. 定义用户角色（新增）：识别所有与系统交互的角色，明确每个角色的职责、关联功能、可见菜单和数据权限范围。角色名称必须在菜单权限（第 6 章）和功能点（第 2 章）中保持一致引用
+7. 绑定菜单权限：菜单需求必须关联角色、页面、操作权限（依赖步骤 6 的角色定义）
+8. 声明写操作的失败反馈：每个用户可见写操作必须有提示文案、重试建议、是否可恢复
+9. 启发非功能需求（新增）：对每个功能点追问性能、安全、可用性、兼容性、数据保留五个维度，每条 NFR 必须包含量化验收指标。若需求来源未提及 NFR，按项目默认 NFR 基线补齐
+10. 分析功能依赖（新增）：梳理功能点之间的前置依赖和关联关系，标注到功能点清单的"前置依赖"和"关联功能"列。依赖关系必须无循环
+11. 识别外部接口（新增）：梳理系统依赖的外部系统、第三方 API、消息队列等集成点。若系统无外部依赖，显式标注"本系统无外部接口依赖"
+12. 冻结需求基线：按需求 ID 冻结验收信号和重新打开条件（必须是人工确认点，Agent 不可自动冻结）
 
 ## 检查点
-- [ ] 术语一致，无同义混用
+- [ ] 术语一致，无同义混用（对应步骤 3）
 - [ ] 每个来源项映射到唯一目标，无孤立页面交互
-- [ ] 菜单需求绑定角色/权限，无悬空项
-- [ ] 用户可见写操作有失败反馈、删除语义、审计要求
-- [ ] 需求基线按 ID 冻结
+- [ ] 用户角色在菜单权限和功能点中引用一致，无悬空角色（对应步骤 6）
+- [ ] 菜单需求绑定角色/权限，无悬空项（对应步骤 7）
+- [ ] 用户可见写操作有失败反馈、删除语义、审计要求（对应步骤 8）
+- [ ] 非功能需求包含量化验收指标，无"高性能""安全"等模糊表述（对应步骤 9）
+- [ ] 每条功能点有唯一编号（REQ-NNN）且被追踪矩阵引用（对应步骤 10）
+- [ ] 需求基线按 ID 冻结（对应步骤 12）
 
 ## 注意事项
 - 禁止将 AI 推论冒充为需求事实

package/templates/procedures//351/252/214/346/224/266/346/265/213/350/257/225/350/247/204/345/210/222.md

@@ -1,25 +1,16 @@
 ---
 name: acceptance-test-planning
 type: procedure
-when: '验收测试, 验收规划, 验收标准, acceptance test, 验收计划, 测试用例设计, 验证计划, 测试计划, 验证策略, verification plan, 测试规划, 集成测试计划'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-验收测试规划
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-delivery-gate
-routes:
-  - code_change
-primary_triggers:
-  - 验收测试规划
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-delivery-gate
 emits:
@@ -27,9 +18,10 @@ emits:
   - acceptance_report
 required_evidence:
   - execution_evidence
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["验收测试","验收规划","验收标准","acceptance test","验收计划","测试用例设计","验证计划","测试计划","验证策略","verification plan","测试规划","集成测试计划"]
 ---
 
 ## 适用场景
@@ -46,6 +38,11 @@ stages: ["编码与单元测试", "联调验证"]
 8. 准备测试数据（覆盖正常流、异常流、边界值、权限场景）
 9. 执行验收测试并记录结果（通过/失败/阻塞），失败项关联缺陷
 10. 回归测试：修复缺陷后重新验证相关场景
+10a. repair_reverify 循环（失败项修复后）：
+   1. 重新执行失败的测试场景
+   2. 重新执行受影响的回归测试范围
+   3. 最多重试 max_attempts 次（默认 3）
+   4. 超过 max_attempts 仍失败 → 上报用户决策（降级/延期/重构）
 11. 输出验收报告（测试覆盖率、通过率、遗留风险），作为上线依据
 
 ## 检查点

package/templates/rules/existing-system//345/205/274/345/256/271/346/200/247/346/243/200/346/237/245/350/247/204/345/210/231.md

@@ -1,37 +1,77 @@
 ---
 name: compatibility-check
 type: review_rule
-asset_kind: review_rule
-routes:
-  - code_change
-  - analysis
-primary_triggers:
-  - 兼容性
-  - 向后兼容
-  - 接口兼容
 scope: ['*']
 system_scope: ['existing-system']
-stages: ["*"]
+stages: ["架构设计", "详细设计", "编码与单元测试"]
 lifecycle_status: active
 owner_mechanism_id: mc-existing-system-review
 ---
 
 # 向后兼容性检查规则
 
-## 接口兼容性
-- 老接口参数不得被删除
-- 老接口参数类型不得变更（窄化转换）
-- 老接口返回结构不得删除已有字段
-- 新增字段必须有默认值
-- 废弃接口必须标记 @Deprecated 并提供替代方案
-
-## 数据库兼容性
-- 老表不得删除列
-- 老列类型变更必须兼容（拓宽可以，窄化不可以）
-- 新增列必须有默认值或允许 NULL
-- 数据迁移必须可回滚
-
-## 行为兼容性
-- 老逻辑的输出不能被新逻辑改变
-- 新老逻辑可以共存时，通过开关切换
-- 开关关闭时行为必须与老版本一致
+## COMP-01: 字段删除过渡期
+- severity: P0
+- check_type: deterministic
+- pattern: 字段删除须有过渡期 ≥2 版本
+- evidence_required: "数据库变更方案 §2"
+
+## COMP-02: API 版本化
+- severity: P0
+- check_type: deterministic
+- pattern: API 破坏性变更须版本化（v1→v2）
+- evidence_required: "接口对接方案 §4"
+
+## COMP-03: 新增必填字段默认值
+- severity: P1
+- check_type: deterministic
+- pattern: 新增必填字段须有默认值
+- evidence_required: "数据库变更方案 §4"
+
+## COMP-04: 枚举值向后兼容
+- severity: P1
+- check_type: deterministic
+- pattern: 枚举值变更须向后兼容
+- evidence_required: "数据库变更方案 §2"
+
+## COMP-05: 外键数据完整性
+- severity: P1
+- check_type: deterministic
+- pattern: 外键变更须评估数据完整性
+- evidence_required: "数据库变更方案 §3"
+
+## COMP-06: 老系统行为不变量
+- severity: P2
+- check_type: semantic
+- pattern: 老系统行为不变量未被破坏
+- evidence_required: "改造影响评估 §2.5"
+
+## COMP-07: 老系统 API 调用方不受影响
+- severity: P0
+- check_type: deterministic
+- pattern: 老系统 API 调用方不受影响
+- evidence_required: "隔离适配器方案 §2.4"
+
+## COMP-08: 配置项迁移脚本
+- severity: P1
+- check_type: deterministic
+- pattern: 配置项变更须有迁移脚本
+- evidence_required: "配置迁移清单"
+
+## COMP-09: 定时任务安全
+- severity: P1
+- check_type: deterministic
+- pattern: 定时任务变更不影响正在执行的实例
+- evidence_required: "部署方案 §5"
+
+## COMP-10: 数据迁移语义一致
+- severity: P2
+- check_type: semantic
+- pattern: 数据迁移后业务语义一致
+- evidence_required: "数据库变更方案 §4"
+
+## COMP-11: 跨阶段检查一致性
+- severity: P1
+- check_type: deterministic
+- pattern: 跨架构/详细设计/编码阶段检查一致性
+- evidence_required: "追踪矩阵"

package/templates/rules/existing-system//350/200/201/347/263/273/347/273/237/345/210/207/347/211/207/350/247/204/345/210/222/350/247/204/345/210/231.md

@@ -0,0 +1,35 @@
+---
+name: old-system-slice-planning
+type: governance_rule
+scope: ['*']
+system_scope: ['existing-system']
+stages: ["任务规划"]
+lifecycle_status: active
+owner_mechanism_id: mc-existing-system-review
+---
+
+# 老系统切片规划规则
+
+## OLD-PLAN-01：涉及 DB 迁移的切片须有关联清洗脚本
+- **严重度**：error
+- **检查类型**：deterministic
+- **规则**：切片计划 §5 中，涉及数据库迁移的切片（缓冲比例 ≥ 35%）须至少关联一条清洗脚本记录
+- **所需证据**：切片计划 §5 中该切片行有非空的「脚本」和「回滚方案」字段
+
+## OLD-PLAN-02：排查缓冲表格每项活动有预估时间
+- **严重度**：warning
+- **检查类型**：deterministic
+- **规则**：切片计划 §2 每切片的排查缓冲表格中，所有缓冲活动的「预估时间」字段非空
+- **所需证据**：排查缓冲表格中无空白行
+
+## OLD-PLAN-03：阶段输入声明所有产物已读取
+- **严重度**：error
+- **检查类型**：deterministic
+- **规则**：切片计划 §1.5 阶段输入声明中，所有行的「检查」字段为 ☑ 已读取
+- **所需证据**：阶段输入声明表格无 □ 未勾选项
+
+## OLD-PLAN-04：清洗脚本产出时机正确
+- **严重度**：error
+- **检查类型**：semantic
+- **规则**：历史数据清洗脚本须在任务规划阶段产出，不得延迟到联调阶段
+- **所需证据**：清洗脚本文件的 git 提交时间在任务规划阶段内

package/templates/rules/existing-system//350/200/246/345/220/210/346/243/200/346/265/213/350/247/204/345/210/231.md

@@ -1,39 +1,73 @@
 ---
 name: coupling-detection
 type: review_rule
-asset_kind: review_rule
-routes:
-  - code_change
-  - analysis
-primary_triggers:
-  - 耦合
-  - 耦合检测
-  - 依赖
 scope: ['*']
 system_scope: ['existing-system']
 stages: ["编码与单元测试"]
 lifecycle_status: active
 owner_mechanism_id: mc-existing-system-review
+version: 1.2.0
+last_reviewed: '2026-06-04'
+products:
+  - '*'
+priority: P1
+triggers: ['耦合检测', 'mock失败', '循环依赖', '影响范围', '回退判定', 'coupling detection']
 ---
 
 # 老代码耦合检测规则
 
-## 检测时机
-- 编码阶段尝试写单元测试时
-- 编码阶段尝试修改老代码时
+## COUP-TEST-01: 静态方法依赖
+- id: COUP-TEST-01
+- name: 静态方法依赖
+- severity: warning
+- check_type: deterministic
+- pattern: 老代码使用静态方法/单例导致无法 mock
+- description: 老代码中使用静态方法或单例模式导致测试时无法 mock 隔离。发现此类耦合应评估是否需要引入适配器层。
 
-## 触发回退到架构设计的条件
+## COUP-TEST-02: 直接 new 对象
+- id: COUP-TEST-02
+- name: 直接 new 对象
+- severity: warning
+- check_type: deterministic
+- pattern: 老代码直接 new 依赖对象，未使用依赖注入
+- description: 老代码在业务逻辑中直接 new 依赖对象而非通过依赖注入，导致无法替换为 mock 进行测试。
 
-### 无法单独测试
-- 老代码使用静态方法/单例导致无法 mock
-- 老代码直接 new 依赖对象，未使用依赖注入
-- 老代码与框架深度绑定（如直接依赖 Request/Response 对象）
+## COUP-TEST-03: 框架绑定
+- id: COUP-TEST-03
+- name: 框架绑定
+- severity: warning
+- check_type: semantic
+- pattern: 老代码与框架深度绑定（如直接依赖 Request/Response 对象）
+- description: 老代码直接依赖框架特定对象（HttpServletRequest、ResponseEntity 等），无法在单元测试中独立运行。
 
-### 无法单独修改
-- 修改一个函数需要同步修改 5 个以上关联文件
-- 老代码存在循环依赖无法单独抽取
-- 老代码的数据结构被多处硬编码引用
+## COUP-MOD-01: 影响范围>3×
+- id: COUP-MOD-01
+- name: 影响范围>3×
+- severity: error
+- check_type: deterministic
+- pattern: 修改影响文件数超过涉及文件列表的 3 倍
+- description: 修改一个函数需要同步修改的关联文件数超过切片涉及文件列表的 3 倍，说明耦合度过高，应评估是否需要架构级重构。
 
-### 检测规则
-- 尝试写单测 3 次仍无法 mock 隔离 → 触发回退
-- 修改影响范围超过预期的 3 倍 → 触发回退
+## COUP-MOD-02: 循环依赖
+- id: COUP-MOD-02
+- name: 循环依赖
+- severity: error
+- check_type: deterministic
+- pattern: 老代码存在循环依赖无法单独抽取
+- description: 老代码中存在 A→B→A 的循环依赖，无法单独抽取和测试。发现循环依赖应评估是否需要引入接口层解耦。
+
+## COUP-ROLLBACK-01: 3 次 mock 失败触发回退
+- id: COUP-ROLLBACK-01
+- name: 3 次 mock 失败触发回退
+- severity: error
+- check_type: deterministic
+- pattern: 尝试写单测 3 次仍无法 mock 隔离 → 触发回退到架构设计
+- description: 编码阶段尝试为老代码编写单元测试，连续 3 次无法完成 mock 隔离时，触发回退到架构设计阶段重新评估改造方案。
+
+## COUP-ROLLBACK-02: 影响超 3 倍触发回退
+- id: COUP-ROLLBACK-02
+- name: 影响超 3 倍触发回退
+- severity: error
+- check_type: deterministic
+- pattern: 修改影响范围超过预期的 3 倍 → 触发回退到架构设计
+- description: 编码阶段修改老代码时，实际影响范围超过切片涉及文件列表的 3 倍，触发回退到架构设计阶段重新评估改造范围。

package/templates/rules/existing-system//350/257/225/350/277/220/350/241/214/347/206/224/346/226/255/350/247/204/345/210/231.md

@@ -1,43 +1,65 @@
 ---
 name: trial-run-circuit-breaker
 type: review_rule
-asset_kind: review_rule
-routes:
-  - code_change
-primary_triggers:
-  - 试运行
-  - 熔断
-  - canary
 scope: ['*']
 system_scope: ['existing-system']
-stages: ["编码与单元测试"]
+id: ka-review-rule-试运行熔断规则
 lifecycle_status: active
+authority: supporting
 owner_mechanism_id: mc-existing-system-review
+priority: P0
+version: 1.2.0
+last_reviewed: '2026-06-04'
+stages: ["联调验证"]
+triggers: ["试运行","熔断","circuit breaker","回退判定"]
 ---
 
 # 试运行熔断判定规则
 
-## 熔断触发条件（满足任一即触发）
+## CB-ERR-01: 接口错误率超阈值
+- id: CB-ERR-01
+- name: 接口错误率超阈值
+- severity: error
+- check_type: deterministic
+- evidence_required: 监控面板错误率截图（5 分钟窗口）
+- rule: 接口错误率超过 5%（5 分钟窗口）或错误率相比老逻辑增加超过 2 倍时触发熔断
 
-### 错误率
-- 接口错误率超过 5%（5 分钟窗口）
-- 错误率相比老逻辑增加超过 2 倍
+## CB-LAT-01: P99 延迟超阈值
+- id: CB-LAT-01
+- name: P99 延迟超阈值
+- severity: error
+- check_type: deterministic
+- evidence_required: 监控面板 P99 延迟趋势图
+- rule: P99 延迟超过老逻辑的 3 倍或 P99 延迟超过 5 秒时触发熔断
 
-### 延迟
-- P99 延迟超过老逻辑的 3 倍
-- P99 延迟超过 5 秒
+## CB-BIZ-01: 核心业务流程成功率不足
+- id: CB-BIZ-01
+- name: 核心业务流程成功率不足
+- severity: error
+- check_type: deterministic
+- evidence_required: 核心业务流程成功率统计报告
+- rule: 核心业务流程成功率低于 95% 时触发熔断
 
-### 业务指标
-- 核心业务流程成功率低于 95%
-- 数据一致性校验失败次数 > 0
+## CB-BIZ-02: 数据一致性校验失败
+- id: CB-BIZ-02
+- name: 数据一致性校验失败
+- severity: error
+- check_type: deterministic
+- evidence_required: 数据一致性校验结果（新老逻辑比对）
+- rule: 数据一致性校验失败次数 > 0（零容忍），立即触发熔断
 
-### 系统
-- 内存使用超过 90%
-- CPU 使用超过 80%（持续 5 分钟）
-- 数据库连接池耗尽
+## CB-SYS-01: 系统资源超限
+- id: CB-SYS-01
+- name: 系统资源超限
+- severity: warning
+- check_type: deterministic
+- evidence_required: 系统资源监控面板截图
+- rule: 内存使用超过 90%、CPU 使用超过 80%（持续 5 分钟）、或数据库连接池耗尽时发出告警
 
-## 熔断动作
-1. 读取一键开关配置
-2. 切换到回退目标（老逻辑）
-3. 记录熔断时间和触发指标
-4. 回退到编码阶段修复
+## CB-ACTION-01: 熔断动作执行
+- id: CB-ACTION-01
+- name: 熔断动作执行
+- severity: error
+- check_type: deterministic
+- evidence_required: 熔断执行日志（开关读取→切换→记录→回退时间线）
+- rule: 熔断触发后必须执行：1. 读取一键开关配置 → 2. 切换到回退目标（老逻辑）→ 3. 记录熔断时间和触发指标 → 4. 回退到编码阶段修复

package/templates/rules/existing-system//351/230/262/345/276/241/346/200/247/347/274/226/347/240/201/350/247/204/345/210/231.md

@@ -1,39 +1,81 @@
 ---
 name: defensive-coding
 type: review_rule
-asset_kind: review_rule
-routes:
-  - code_change
-primary_triggers:
-  - 防御性编码
-  - 防御编程
-  - 老系统编码
 scope: ['*']
 system_scope: ['existing-system']
 stages: ["编码与单元测试"]
 lifecycle_status: active
 owner_mechanism_id: mc-existing-system-review
+version: 1.2.0
+last_reviewed: '2026-06-04'
+products:
+  - '*'
+priority: P1
+triggers: ['防御性编码', '降级策略', '重试超时', '事务保护', '异常处理', 'defensive coding']
 ---
 
 # 防御性编码规则
 
-## 老系统接口调用
-- 必须对老系统接口调用添加降级/兜底/重试
-- 降级策略：返回兜底数据或走老逻辑
-- 重试策略：最多 3 次，指数退避
-- 超时设置：必须设置合理的超时时间
-
-## 外部依赖
-- 所有外部服务调用必须有 try-catch
-- 所有外部服务调用必须设置超时
-- 不可控的外部依赖必须有降级方案
-
-## 数据操作
-- 写操作必须使用事务
-- 批量操作必须有分页/分批处理
-- 数据校验在写入前完成
-
-## 错误处理
-- 不允许空 catch 块
-- 错误日志必须包含上下文信息
-- 非预期错误必须向上传播
+## DEF-OLD-01: 接口降级策略
+- id: DEF-OLD-01
+- name: 接口降级策略
+- severity: error
+- check_type: deterministic
+- pattern: 老系统接口调用必须有降级/兜底策略
+- description: 必须对老系统接口调用添加降级策略：返回兜底数据或走老逻辑。降级方案须在代码中有明确注释说明触发条件和兜底行为。
+
+## DEF-OLD-02: 重试与超时
+- id: DEF-OLD-02
+- name: 重试与超时
+- severity: error
+- check_type: deterministic
+- pattern: 重试次数≤3，超时时间必须明确设置
+- description: 老系统接口调用必须有重试策略：最多 3 次，指数退避。超时设置必须明确（不得使用无限超时或默认超时）。
+
+## DEF-EXT-01: try-catch 包裹
+- id: DEF-EXT-01
+- name: try-catch 包裹
+- severity: error
+- check_type: deterministic
+- pattern: 所有外部服务调用必须有 try-catch 包裹
+- description: 所有外部服务调用（HTTP/RPC/MQ/SDK）必须有 try-catch 包裹，不得将外部异常直接传播到业务逻辑层。
+
+## DEF-EXT-02: 降级方案
+- id: DEF-EXT-02
+- name: 降级方案
+- severity: warning
+- check_type: semantic
+- pattern: 不可控的外部依赖必须有降级方案
+- description: 不可控的外部依赖（第三方 API、共享服务）必须有降级方案：返回缓存数据、走备用通道、或标记为降级状态。
+
+## DEF-DATA-01: 事务保护
+- id: DEF-DATA-01
+- name: 事务保护
+- severity: error
+- check_type: deterministic
+- pattern: 写操作必须使用事务
+- description: 涉及多表写入、状态变更、金额操作等写操作必须使用事务保护。事务边界须明确，不得跨 HTTP 调用。
+
+## DEF-DATA-02: 分批处理
+- id: DEF-DATA-02
+- name: 分批处理
+- severity: warning
+- check_type: semantic
+- pattern: 批量操作必须有分页/分批处理
+- description: 批量操作（批量导入、批量更新、批量删除）必须有分页/分批处理机制，避免单次操作数据量过大导致内存溢出或锁等待。
+
+## DEF-ERR-01: 禁止空 catch
+- id: DEF-ERR-01
+- name: 禁止空 catch
+- severity: error
+- check_type: deterministic
+- pattern: grep -E 'catch\s*\([^)]*\)\s*\{\s*\}' 匹配 0
+- description: 不允许空 catch 块。catch 块中必须至少包含日志记录或明确的忽略注释。
+
+## DEF-ERR-02: 错误传播
+- id: DEF-ERR-02
+- name: 错误传播
+- severity: error
+- check_type: semantic
+- pattern: 非预期错误必须向上传播，不得吞异常
+- description: 错误日志必须包含上下文信息（traceId、请求参数、操作类型）。非预期错误必须向上传播，不得在中间层吞异常后返回默认值。