soloforge 1.1.38 → 1.1.40

package/templates/procedures//351/203/250/347/275/262/345/217/221/345/270/203/346/265/201/347/250/213.md

@@ -1,33 +1,28 @@
 ---
 name: deploy-release
 type: procedure
-when: '发布, 上线, 部署, release, 发版, 版本发布, 灰度, 发布上线, 生产部署'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-部署发布流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-delivery-gate
-primary_triggers:
-  - 部署发布流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-delivery-gate
+companion_gates: ["gate-交付.yaml", "gate-发布后观察.yaml"]
 emits:
   - release_record
   - deployment_verification
 required_evidence:
   - execution_evidence
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 stages: ["联调验证"]
+triggers: ["发布","上线","部署","release","发版","版本发布","灰度","发布上线","生产部署"]
 ---
 
 ## 适用场景
@@ -67,3 +62,34 @@ stages: ["联调验证"]
 - 发布窗口应选择业务低峰期（通常 22:00-06:00）
 - 数据库迁移脚本必须向前兼容，回滚时不执行 DDL 回退
 - 发布后必须通知相关团队（运营、客服），提前告知已识别的影响范围和观察窗口
+
+## AI Agent 权限边界
+
+| 权限层级 | 允许 | 禁止 |
+|---------|------|------|
+| data-plane | 执行构建、运行测试、执行 migration、冒烟测试、收集监控数据 | 自主决定是否回滚 |
+| control-plane | 建议 risk score、提供回滚建议 | 自主修改部署策略/灰度比例/跳过审批门禁 |
+
+回滚决策必须经人类审批（control-plane），AI 可建议但不可自主执行回滚。
+
+## 自动回滚触发器
+
+| 信号源 | 触发条件 | 冷却期 |
+|--------|---------|--------|
+| 错误率 | 5xx 率 > 2× 基线 | 5 分钟 |
+| 延迟 | P99 > 1.5× 基线 | 5 分钟 |
+| 内存 | 分配速率 > 3× 基线（10 分钟内） | 5 分钟 |
+| 新错误模式 | 日志中出现部署前不存在的错误 | 3 分钟 |
+| 健康检查 | Pod 重启 / OOMKill / 探针失败 | 立即 |
+
+**防级联回滚**：
+- 最大自动回滚频率：1 次/15 分钟
+- 连续 2 次回滚后升级为人工处理
+- 所有 AI 触发的回滚操作须记录审计日志
+
+## AI 部署特有风险
+
+- AI 可从测试覆盖率缺口获得假性信心 → 部署验证须包含测试未覆盖的关键路径
+- 历史成功不保证未来安全 → 新类型变更须额外审查
+- AI 缺乏业务上下文（营销活动/冻结窗口/基础设施变更）→ 部署窗口须人工确认
+- AI 可静默退化质量（优化可观测指标但损害长期可维护性）→ 部署后审查须检查代码可维护性

package/templates/procedures//351/207/215/346/236/204/346/265/201/346/260/264/347/272/277.md

@@ -1,23 +1,16 @@
 ---
 name: refactor-pipeline
 type: pipeline_procedure
-when: '代码重构, 模块拆分, 模式优化, 提取公共方法, 重构, refactor, 代码改善, 结构优化'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-重构流水线
-asset_kind: pipeline_procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-task-context-lifecycle
-primary_triggers:
-  - 重构流水线
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-task-context-lifecycle
 emits:
@@ -29,24 +22,25 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["代码重构","模块拆分","模式优化","提取公共方法","重构","refactor","代码改善","结构优化"]
 ---
 
 # 重构管线
 
-### 第1步：现状分析
+## 第1步：现状分析
 识别当前代码的坏味道和重构目标。量化现状（圈复杂度、方法行数、类职责数）。确定重构类型（提取方法/提取类/内联/重命名/搬移/模式替换）。
 模版：重构方案模版.md
 产出保存到：.soloforge/output/01-重构分析.md
 工具：sf_command, sf_analyze
 
-### 第2步：方案设计
+## 第2步：方案设计
 定义重构目标和 Before/After 对比。评估影响范围（哪些模块/接口/测试受影响）。识别风险点（破坏性变更风险等级、回归风险）。制定分步执行计划（每步可独立验证）。
 产出保存到：.soloforge/output/02-重构方案.md
 
-### 第3步：分步实施
+## 第3步：分步实施
 按计划逐步执行重构，每步完成后运行测试确认无回归。禁止一次改多步再验证。保持测试始终可通过（绿色），如需修改测试先确认测试本身正确。
 工具：sf_stage_execute
 
-### 第4步：验证验收
+## 第4步：验证验收
 执行全量构建和测试。代码审查重点关注：行为等价性（重构不改变外部行为）、接口兼容性、性能影响。学习记录（重构模式、发现的设计问题）。
 工具：sf_gate_check, sf_review, sf_stage_advance

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

@@ -1,23 +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
-primary_triggers:
-  - 集成验证流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-verifier
 emits:
@@ -25,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"]
 ---
 
 ## 适用场景
@@ -38,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,33 +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-command-router
-primary_triggers:
-  - 需求澄清流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - 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","需求评审"]
 ---
 
 ## 适用场景
@@ -38,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,23 +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
-primary_triggers:
-  - 验收测试规划
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-delivery-gate
 emits:
@@ -25,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","测试规划","集成测试计划"]
 ---
 
 ## 适用场景
@@ -44,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,34 +1,77 @@
 ---
 name: compatibility-check
 type: review_rule
-asset_kind: review_rule
-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,36 +1,73 @@
 ---
 name: coupling-detection
 type: review_rule
-asset_kind: review_rule
-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,41 +1,65 @@
 ---
 name: trial-run-circuit-breaker
 type: review_rule
-asset_kind: review_rule
-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. 回退到编码阶段修复