soloforge 1.1.1 → 1.1.30

package/templates/procedures//350/257/246/347/273/206/350/256/276/350/256/241/346/265/201/347/250/213.md

@@ -0,0 +1,69 @@
+---
+name: detailed-design
+type: procedure
+when: '详细设计, 接口设计, 数据库设计, DDL设计, 类设计, 详细方案, detailed design'
+scope:
+  - backend
+  - frontend
+products:
+  - '*'
+id: ka-procedure-详细设计流程
+asset_kind: procedure
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-architecture-design
+routes:
+  - code_change
+primary_triggers:
+  - 详细设计流程
+secondary_triggers: []
+negative_triggers: []
+priority: P1
+specificity: 5
+consumes:
+  - mc-intent-router
+emits:
+  - execution_result
+  - evidence
+required_evidence:
+  - execution_evidence
+version: 1.0.0
+last_reviewed: '2026-05-22'
+migration_note: 知识资产标准化迁移
+status: active
+---
+
+## 适用场景
+从架构设计产出实现锚点（数据结构、接口定义、状态机）、DDL 和映射矩阵。适用于编码前的设计阶段。
+
+详细设计的正式必需产出不是固定的 `04-详细设计文档.md` 单文件。默认产出为：
+
+- `docs/architecture/02-数据库设计文档.md`：承载 `DD-T*`、表字段、索引、审计、租户、安全和生命周期。
+- `docs/architecture/03-API接口规格文档.md`：承载 `DD-A*`、端点、字段、错误、副作用和验收场景。
+- `docs/api/openapi.yaml`：API 路径、操作和 schema 权威资产。
+- SQL/migration 文件：数据库物理结构权威资产。
+
+`docs/architecture/04-详细设计文档.md` 仅作为复杂模块或旧项目迁移的可选补充；如果数据库设计和 API 规格已完整承载详细设计，门禁不得强制要求该文件。
+
+## 步骤
+1. 确认架构设计已冻结，并在详细设计中引用 `ARCH-*`。
+2. 产出数据库详细设计，声明 `DD-T*`，并同步 SQL/migration 权威资产。
+3. 产出 API 详细设计，声明 `DD-A*`，并同步 `docs/api/openapi.yaml`。
+4. 维护追踪矩阵，把 `REQ/PROTO/ARCH/DD` 关系写入 `docs/traceability/01-需求原型设计实现追踪矩阵.md`。
+5. 进入切片规划前，确保后续切片能引用 `DD-*` 或 `ARCH-*` 并生成 `SLICE-*` 与 `AC-*`。
+
+## 检查点
+- [ ] DDL 命名/注释/审计字段/主键完备
+- [ ] DDL 有兼容窗口和回滚策略
+- [ ] 数据库设计声明 `DD-T*` 并引用 `ARCH-*`
+- [ ] API 规格声明 `DD-A*` 并引用 `ARCH-*`
+- [ ] OpenAPI 与 API 文档路径和字段一致
+- [ ] SQL/migration 权威资产存在
+- [ ] 页面映射/字段变更/菜单权限/状态机可追溯到 UI 交互设计
+- [ ] 新增/修改菜单的角色授权和权限标识已文档化
+- [ ] 实现锚点可供任务拆解直接消费
+
+## 注意事项
+- 禁止先写说明文字再补实现锚点（锚点优先）
+- 禁止只写 `04-详细设计文档.md` 而缺少数据库设计、API 规格、OpenAPI 或 SQL/migration 权威资产
+- DDL 必须指定关联策略和审计策略

package/templates/procedures//350/260/203/350/257/225/346/216/222/346/237/245/346/265/201/347/250/213.md

@@ -0,0 +1,70 @@
+---
+name: debug-investigation
+type: procedure
+when: '调试, 排障, 排查问题, bug定位, 问题排查, 线上排查, 异常排查, 错误定位, 日志排查, 缺陷修复, Bug修复, 问题修复, 异常修复, 错误修复, bug fix, 缺陷处理'
+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-intent-router
+emits:
+  - execution_result
+  - evidence
+required_evidence:
+  - execution_evidence
+version: 1.0.0
+last_reviewed: '2026-05-22'
+migration_note: 知识资产标准化迁移
+status: active
+---
+
+## 适用场景
+功能异常、性能问题、线上报错等需要定位根因的场景。遵循「先观察后假设再验证」的原则。
+
+## 四阶段调试法
+1. **观察阶段**：获取具体操作步骤、输入数据、环境信息，确认可复现
+2. **假设阶段**：根据观察提出一个假设，不要同时提出多个假设
+3. **验证阶段**：设计最小实验验证假设，记录结果（包括被否定的假设）
+4. **修复阶段**：确认根因后编写最小修复 + 回归测试
+
+## 步骤
+1. 复现问题：获取具体操作步骤、输入数据、环境信息
+2. 确定影响范围：是全部用户还是特定条件？是偶发还是必现？
+3. 查看日志：根据时间窗口搜索 traceId，查看完整请求链路日志
+4. 查看监控：接口响应时间、错误率、资源使用（CPU/内存/磁盘）
+5. 定位代码：根据日志中的异常堆栈定位到具体文件和方法
+6. 分析根因：区分是代码 Bug、配置错误、数据异常还是环境问题
+7. 验证假设：在本地或测试环境复现并验证根因（一次只验证一个假设）
+8. 编写最小修复：修复范围只覆盖确认的根因，禁止顺手改其他代码
+9. 使用 RED-GREEN 验证：回退修复 → 确认失败 → 恢复修复 → 确认通过
+10. 添加回归测试（防止同类问题再发生）
+
+## 检查点
+- [ ] 问题可稳定复现（或记录了偶现条件）
+- [ ] 日志中有 traceId 可追踪完整链路
+- [ ] 调试过程有假设-验证记录
+- [ ] 根因已确认而非停留在表象
+- [ ] 修复范围仅限确认的根因
+- [ ] 修复包含回归测试
+
+## 注意事项
+- 不要在没有复现的情况下直接修改代码
+- 日志排查优先使用 traceId，避免大海捞针
+- 性能问题优先看慢查询日志和接口耗时
+- 同一现象修复失败 3 次后停止猜测，重新审视假设，考虑是否为架构问题
+- 禁止通过删除断言、增加 sleep、降低覆盖率、增加 mock 来制造通过

package/templates/procedures//350/277/201/347/247/273/346/265/201/346/260/264/347/272/277.md

@@ -0,0 +1,54 @@
+---
+name: migration-pipeline
+type: pipeline_procedure
+when: '技术迁移, 框架升级, 技术栈迁移, 版本升级, 迁移, migration, 系统迁移, 组件替换'
+scope:
+  - backend
+  - frontend
+products:
+  - '*'
+id: ka-procedure-迁移流水线
+asset_kind: procedure
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-knowledge-asset-governance
+routes:
+  - code_change
+primary_triggers:
+  - 迁移流水线
+secondary_triggers: []
+negative_triggers: []
+priority: P1
+specificity: 5
+consumes:
+  - mc-intent-router
+emits:
+  - execution_result
+  - evidence
+required_evidence:
+  - execution_evidence
+version: 1.0.0
+last_reviewed: '2026-05-22'
+migration_note: 知识资产标准化迁移
+status: active
+---
+
+# 技术迁移管线
+
+### 第1步：迁移评估
+评估迁移范围和影响（模块数、代码量、依赖链）。评估迁移路径（渐进式/一次性）。评估兼容性风险（API 变更、行为差异、性能差异）。制定回滚方案。
+模板：迁移评估模版.md
+产出保存到：.soloforge/output/01-迁移评估.md
+工具：sf_classify, sf_analyze
+
+### 第2步：方案设计
+制定分阶段迁移计划（每阶段可独立验证和回滚）。识别兼容层需求（适配器/Shim/Feature Flag）。定义每个阶段的完成标准和验证方式。
+产出保存到：.soloforge/output/02-迁移方案.md
+
+### 第3步：渐进迁移
+按计划逐步迁移，每阶段完成后全量测试。保持双写/双读过渡期（如需要）。记录每阶段发现的行为差异和兼容性问题。
+工具：sf_expand, sf_verify
+
+### 第4步：清理验证
+移除兼容层和废弃代码。全量功能验证。性能对比确认无退化。更新文档和依赖配置。
+工具：sf_verify, sf_review, sf_deliver, sf_learn

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

@@ -0,0 +1,72 @@
+---
+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
+routes:
+  - code_change
+primary_triggers:
+  - 部署发布流程
+secondary_triggers: []
+negative_triggers: []
+priority: P1
+specificity: 5
+consumes:
+  - mc-intent-router
+emits:
+  - execution_result
+  - evidence
+required_evidence:
+  - execution_evidence
+version: 1.0.0
+last_reviewed: '2026-05-22'
+migration_note: 知识资产标准化迁移
+status: active
+---
+
+## 适用场景
+新功能上线、Bug 修复发版、生产环境部署。适用于经过测试验证后的正式发布流程。
+
+## 步骤
+1. 确认所有测试通过（单元测试 + 集成测试），检查 CI 绿灯
+2. 更新版本号（package.json / pom.xml），生成 CHANGELOG
+3. 合并代码到 release/main 分支，打 Git tag（v{version}）
+4. 触发 CI/CD 构建，确认构建产物生成成功
+5. 在预发环境（staging）验证核心功能流程
+6. 执行数据库迁移（如有 DDL 变更，先备份再执行）
+7. 部署到生产环境（滚动更新或蓝绿部署）
+8. 验证生产环境：健康检查、核心接口冒烟测试
+9. 监控告警观察 30 分钟，确认无异常
+10. 通知团队发布完成，更新发布记录
+11. 部署前确认回滚方案（回滚命令、数据库回滚脚本、配置回滚点）
+12. 灰度/金丝雀发布：先部署到 10% 实例，观察 5 分钟监控指标
+13. 确认监控指标正常后，逐步扩大到 50% → 100%
+14. 部署完成后验证关键业务流程（冒烟测试），确认功能正常
+15. 部署后观察 30 分钟监控（错误率、响应时间、资源使用），异常则触发回滚
+
+## 检查点
+- [ ] CI 全部通过，无跳过的测试
+- [ ] 预发环境验证通过
+- [ ] 数据库变更已执行且可回滚
+- [ ] 生产健康检查通过
+- [ ] 回滚方案已确认
+- [ ] 灰度发布监控指标正常
+- [ ] 冒烟测试通过
+- [ ] 部署后 30 分钟监控正常
+
+## 注意事项
+- DDL 变更必须向前兼容（新列可为空或有默认值）
+- 发布后保留回滚方案至少 24 小时
+- 避免周五下午发布（无人在岗处理问题）
+- 发布窗口应选择业务低峰期（通常 22:00-06:00）
+- 数据库迁移脚本必须向前兼容，回滚时不执行 DDL 回退
+- 发布后必须通知相关团队（运营、客服），提前告知已识别的影响范围和观察窗口

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

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

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

@@ -0,0 +1,63 @@
+---
+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-intent-router
+emits:
+  - execution_result
+  - evidence
+required_evidence:
+  - execution_evidence
+version: 1.0.0
+last_reviewed: '2026-05-22'
+migration_note: 知识资产标准化迁移
+status: active
+---
+
+## 适用场景
+跨 API、页面交互和业务流的增量集成测试，要求真实运行时证据。适用于部署后的端到端验证。
+
+## 步骤
+1. 分析变更影响：哪些接口、页面、DDL、菜单受影响
+2. 发现服务依赖和启动顺序
+3. 构建部署最新代码，验证构建产物新鲜度
+4. 收集运行时证据：API 动态验证、页面快照、控制台、网络请求
+5. 端到端流程验证：从浏览器页面出发，不绕过前端直接调后端
+6. DDL 迁移必须在浏览器/API 测试前应用到运行数据库
+7. 发现缺陷时：先诊断再修复，修复后重新构建再验证
+8. 构建覆盖矩阵：接口 × 页面交互 × 业务流三维覆盖
+9. 产出偏差报告：每个缺口映射到返回阶段
+
+## 检查点
+- [ ] 变更影响分析仅覆盖本次变更范围
+- [ ] 构建产物新鲜度已验证
+- [ ] API 动态验证和浏览器运行时验证均完成
+- [ ] 端到端流程从浏览器页面出发完成
+- [ ] 菜单变更验证了角色可见性、路由可达、API 可调
+- [ ] 覆盖矩阵达标，偏差报告指定返回阶段
+
+## 注意事项
+- 禁止绕过前端直接调后端 API 做业务流测试
+- 禁止用 SQL 直接写业务测试数据（使用页面操作或业务 API）
+- 禁止在过期构建上测试（新鲜度检查失败必须重新构建）
+- 禁止硬编码测试凭据
+- 禁止接受 dry-run/静态分析/AI 摘要作为通过证据

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

@@ -0,0 +1,59 @@
+---
+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: []
+priority: P1
+specificity: 5
+consumes:
+  - mc-intent-router
+emits:
+  - execution_result
+  - evidence
+required_evidence:
+  - execution_evidence
+version: 1.0.0
+last_reviewed: '2026-05-22'
+migration_note: 知识资产标准化迁移
+status: active
+---
+
+## 适用场景
+从原始需求中提取结构化事实、识别冲突和缺口、产出可追溯的需求基线。适用于编码前的需求理解阶段。
+
+## 步骤
+1. 提取需求事实：从需求文档/用户描述中提取功能点、页面交互、业务规则
+2. 分离事实与决策：需求事实和架构决策分列记录，禁止将 AI 推论伪装为需求事实
+3. 运行术语一致性检查：识别同一概念不同命名，统一术语
+4. 标记未确认项：无法确认的需求标记为「待确认」，禁止猜测或跳过
+5. 标注冲突和越界项：明确来源和处理方式（冲突标注来源，越界标注排除原因）
+6. 绑定菜单权限：菜单需求必须关联角色、页面、操作权限
+7. 声明写操作的失败反馈：每个用户可见写操作必须有提示文案、重试建议、是否可恢复
+8. 冻结需求基线：按需求 ID 冻结验收信号和重新打开条件
+
+## 检查点
+- [ ] 术语一致，无同义混用
+- [ ] 每个来源项映射到唯一目标，无孤立页面交互
+- [ ] 菜单需求绑定角色/权限，无悬空项
+- [ ] 用户可见写操作有失败反馈、删除语义、审计要求
+- [ ] 需求基线按 ID 冻结
+
+## 注意事项
+- 禁止将 AI 推论冒充为需求事实
+- 原型缺失不阻塞需求分析
+- 未确认需求必须显式标记，禁止静默跳过

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

@@ -0,0 +1,67 @@
+---
+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-verifier
+routes:
+  - code_change
+primary_triggers:
+  - 验收测试规划
+secondary_triggers: []
+negative_triggers: []
+priority: P1
+specificity: 5
+consumes:
+  - mc-intent-router
+emits:
+  - execution_result
+  - evidence
+required_evidence:
+  - execution_evidence
+version: 1.0.0
+last_reviewed: '2026-05-22'
+migration_note: 知识资产标准化迁移
+status: active
+---
+
+## 适用场景
+基于任务卡片规划验收测试范围、优先级和覆盖策略，确保 P0/P1 功能有明确验收标准。
+
+## 步骤
+1. 确认任务卡片和交付蓝图已冻结
+2. 识别所有功能点的测试覆盖需求
+3. 创建测试条目，每条追溯到任务卡和需求基线
+4. P0/P1 测试必须覆盖：正常路径 + 至少一个错误路径
+5. L0 紧急修复可使用简化测试但不得完全跳过
+6. 测试框架由技术栈决定
+7. 明确验收标准和验收场景（基于需求文档和验收清单）
+8. 准备测试数据（覆盖正常流、异常流、边界值、权限场景）
+9. 执行验收测试并记录结果（通过/失败/阻塞），失败项关联缺陷
+10. 回归测试：修复缺陷后重新验证相关场景
+11. 输出验收报告（测试覆盖率、通过率、遗留风险），作为上线依据
+
+## 检查点
+- [ ] 所有 P0 任务卡有至少 1 个测试条目
+- [ ] 所有 P1 任务卡有至少 1 个测试条目
+- [ ] 覆盖策略包含正常路径、边界场景、错误路径
+- [ ] 测试条目追溯到任务卡和需求基线
+- [ ] 验收场景覆盖所有需求点
+- [ ] 测试数据准备完毕
+- [ ] 验收报告输出并评审
+
+## 注意事项
+- 测试必须在实现前生成（先失败后实现）
+- 每个测试至少 1 个断言
+- 纯文档/配置变更不适用本流程
+- 验收测试必须在类生产环境执行，禁止在开发环境验收
+- 验收发现的 P0/P1 问题必须在上线前修复
+- 性能验收必须模拟真实数据量和并发量

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

@@ -0,0 +1,33 @@
+---
+name: 兼容性检查规则
+type: review_rule
+asset_kind: pipeline_rule
+routes:
+  - code_change
+  - analysis
+primary_triggers:
+  - 兼容性
+  - 向后兼容
+  - 接口兼容
+scope: [existing-system]
+---
+
+# 向后兼容性检查规则
+
+## 接口兼容性
+- 老接口参数不得被删除
+- 老接口参数类型不得变更（窄化转换）
+- 老接口返回结构不得删除已有字段
+- 新增字段必须有默认值
+- 废弃接口必须标记 @Deprecated 并提供替代方案
+
+## 数据库兼容性
+- 老表不得删除列
+- 老列类型变更必须兼容（拓宽可以，窄化不可以）
+- 新增列必须有默认值或允许 NULL
+- 数据迁移必须可回滚
+
+## 行为兼容性
+- 老逻辑的输出不能被新逻辑改变
+- 新老逻辑可以共存时，通过开关切换
+- 开关关闭时行为必须与老版本一致

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

@@ -0,0 +1,35 @@
+---
+name: 耦合检测规则
+type: review_rule
+asset_kind: pipeline_rule
+routes:
+  - code_change
+  - analysis
+primary_triggers:
+  - 耦合
+  - 耦合检测
+  - 依赖
+scope: [existing-system]
+---
+
+# 老代码耦合检测规则
+
+## 检测时机
+- 编码阶段尝试写单元测试时
+- 编码阶段尝试修改老代码时
+
+## 触发回退到架构设计的条件
+
+### 无法单独测试
+- 老代码使用静态方法/单例导致无法 mock
+- 老代码直接 new 依赖对象，未使用依赖注入
+- 老代码与框架深度绑定（如直接依赖 Request/Response 对象）
+
+### 无法单独修改
+- 修改一个函数需要同步修改 5 个以上关联文件
+- 老代码存在循环依赖无法单独抽取
+- 老代码的数据结构被多处硬编码引用
+
+### 检测规则
+- 尝试写单测 3 次仍无法 mock 隔离 → 触发回退
+- 修改影响范围超过预期的 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

@@ -0,0 +1,39 @@
+---
+name: 试运行熔断规则
+type: review_rule
+asset_kind: pipeline_rule
+routes:
+  - code_change
+primary_triggers:
+  - 试运行
+  - 熔断
+  - canary
+scope: [existing-system]
+---
+
+# 试运行熔断判定规则
+
+## 熔断触发条件（满足任一即触发）
+
+### 错误率
+- 接口错误率超过 5%（5 分钟窗口）
+- 错误率相比老逻辑增加超过 2 倍
+
+### 延迟
+- P99 延迟超过老逻辑的 3 倍
+- P99 延迟超过 5 秒
+
+### 业务指标
+- 核心业务流程成功率低于 95%
+- 数据一致性校验失败次数 > 0
+
+### 系统
+- 内存使用超过 90%
+- CPU 使用超过 80%（持续 5 分钟）
+- 数据库连接池耗尽
+
+## 熔断动作
+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

@@ -0,0 +1,35 @@
+---
+name: 防御性编码规则
+type: review_rule
+asset_kind: pipeline_rule
+routes:
+  - code_change
+primary_triggers:
+  - 防御性编码
+  - 防御编程
+  - 老系统编码
+scope: [existing-system]
+---
+
+# 防御性编码规则
+
+## 老系统接口调用
+- 必须对老系统接口调用添加降级/兜底/重试
+- 降级策略：返回兜底数据或走老逻辑
+- 重试策略：最多 3 次，指数退避
+- 超时设置：必须设置合理的超时时间
+
+## 外部依赖
+- 所有外部服务调用必须有 try-catch
+- 所有外部服务调用必须设置超时
+- 不可控的外部依赖必须有降级方案
+
+## 数据操作
+- 写操作必须使用事务
+- 批量操作必须有分页/分批处理
+- 数据校验在写入前完成
+
+## 错误处理
+- 不允许空 catch 块
+- 错误日志必须包含上下文信息
+- 非预期错误必须向上传播