soloforge 1.1.2 → 1.1.30

package/templates/knowledge/procedures//350/207/252/344/270/273/351/200/211/345/236/213/346/265/201/347/250/213.md

@@ -1,34 +0,0 @@
----
-name: autonomous-tech-selection
-type: procedure
-when: 技术选型, 不知道用什么, 选型, 方案对比, 架构选型, 方案选择, 技术方案
-scope: [backend, frontend]
-products: ["*"]
----
-
-## 适用场景
-当人类陷入"不知道用什么方案"的迷茫状态，或任务涉及需要技术选型的架构决策点。
-
-## 步骤
-1. 触发条件检测: 分类结果中 task_type 为 feature/refactor/optimize 且涉及架构级变更
-2. 调用 sf_explore: 传入领域关键词（如: 分布式锁、缓存策略、认证鉴权）
-3. 审查行业基准: 确认检索到至少 3 个有据可查的标准方案
-4. 评估四维矩阵: 开发成本/运行性能/扩展上限/维护复杂度，排除总分 < 10/20 的方案
-5. 执行方案证伪: 对每个方案提出"在什么极端场景下它会失效"
-6. 输出方案边界声明: 如实告知推荐方案的天花板，不做糖衣炮弹
-7. A/B 决策诱导: 输出两个精确选项，禁止提问"你想怎么做"
-8. 等待人类决策: 输入"选 A"或"选 B"后进入自动编码模式
-9. 基于选定方案继续 sf_expand 流程
-
-## 检查点
-- [ ] 至少 3 个行业标准方案已检索
-- [ ] 四维权重矩阵已完成
-- [ ] 证伪报告已生成
-- [ ] 方案边界声明已输出
-- [ ] A/B 选项已呈现并等待决策
-
-## 注意事项
-- 禁止凭空捏造方案，所有推荐必须有行业来源（内置基准库/知识库/明确标注启发式）
-- 禁止模糊脑暴，每个方案必须给出致命缺点和适用场景
-- 禁止回避缺陷，方案边界声明必须包含"天花板"描述
-- 决策后立即进入编码流程，不再二次犹豫

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

@@ -1,29 +0,0 @@
----
-name: detailed-design
-type: procedure
-when: 详细设计, 接口设计, 数据库设计, DDL设计, 类设计, 详细方案, detailed design
-scope: [backend, frontend]
-products: ["*"]
----
-
-## 适用场景
-从架构设计产出实现锚点（数据结构、接口定义、状态机）、DDL 和映射矩阵。适用于编码前的设计阶段。
-
-## 步骤
-1. 确认架构设计已冻结
-2. 先产出实现锚点（表结构、映射矩阵、菜单/权限映射、自测钩子），再加说明文字
-3. DDL 设计：命名、注释、审计字段、主键、关联策略、兼容窗口、回滚策略
-4. 前后端适配矩阵：关联回 UI 交互设计和接口契约
-5. 接口字段级别的细节留给 API 契约阶段，本阶段不展开
-
-## 检查点
-- [ ] DDL 命名/注释/审计字段/主键完备
-- [ ] DDL 有兼容窗口和回滚策略
-- [ ] 页面映射/字段变更/菜单权限/状态机可追溯到 UI 交互设计
-- [ ] 新增/修改菜单的角色授权和权限标识已文档化
-- [ ] 实现锚点可供任务拆解直接消费
-
-## 注意事项
-- 禁止先写说明文字再补实现锚点（锚点优先）
-- 禁止在本阶段展开接口字段级定义（属于 API 契约阶段）
-- DDL 必须指定关联策略和审计策略

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

@@ -1,43 +0,0 @@
----
-name: debug-investigation
-type: procedure
-when: 调试, 排障, 排查问题, bug定位, 问题排查, 线上排查, 异常排查, 错误定位, 日志排查
-scope: [backend, frontend]
-products: ["*"]
----
-
-## 适用场景
-功能异常、性能问题、线上报错等需要定位根因的场景。遵循「先观察后假设再验证」的原则。
-
-## 四阶段调试法
-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/knowledge/procedures//350/277/201/347/247/273/346/265/201/346/260/264/347/272/277.md

@@ -1,27 +0,0 @@
----
-name: migration-pipeline
-type: pipeline_procedure
-when: "技术迁移, 框架升级, 技术栈迁移, 版本升级, 迁移, migration, 系统迁移, 组件替换"
-scope: [backend, frontend]
-products: ["*"]
----
-
-# 技术迁移管线
-
-### 第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/knowledge/procedures//351/203/250/347/275/262/345/217/221/345/270/203/346/265/201/347/250/213.md

@@ -1,45 +0,0 @@
----
-name: deploy-release
-type: procedure
-when: 发布, 上线, 部署, release, 发版, 版本发布, 灰度, 发布上线, 生产部署
-scope: [backend, frontend]
-products: ["*"]
----
-
-## 适用场景
-新功能上线、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/knowledge/procedures//351/207/215/346/236/204/346/265/201/346/260/264/347/272/277.md

@@ -1,27 +0,0 @@
----
-name: refactor-pipeline
-type: pipeline_procedure
-when: "代码重构, 模块拆分, 模式优化, 提取公共方法, 重构, refactor, 代码改善, 结构优化"
-scope: [backend, frontend]
-products: ["*"]
----
-
-# 重构管线
-
-### 第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/knowledge/procedures//351/233/206/346/210/220/351/252/214/350/257/201/346/265/201/347/250/213.md

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

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

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

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

@@ -1,40 +0,0 @@
----
-name: acceptance-test-planning
-type: procedure
-when: 验收测试, 验收规划, 验收标准, acceptance test, 验收计划, 测试用例设计
-scope: [backend, frontend]
-products: ["*"]
----
-
-## 适用场景
-基于任务卡片规划验收测试范围、优先级和覆盖策略，确保 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/knowledge/procedures//351/252/214/350/257/201/350/256/241/345/210/222/346/265/201/347/250/213.md

@@ -1,32 +0,0 @@
----
-name: verification-plan
-type: procedure
-when: 验证计划, 测试计划, 验证策略, verification plan, 测试规划, 集成测试计划
-scope: [backend, frontend]
-products: ["*"]
----
-
-## 适用场景
-基于任务卡片和交付蓝图规划验证范围、优先级和覆盖策略。适用于编码完成后的验证准备阶段。
-
-## 步骤
-1. 确认任务卡片和交付蓝图已冻结
-2. 读取任务卡片识别所有需要测试覆盖的功能点
-3. 创建测试条目：追溯到任务卡片和需求基线
-4. 定义覆盖策略：正常路径 + 边界场景 + 错误路径
-5. 分配优先级：P0/P1 每个至少有 1 个测试条目
-6. 高风险变更必须有运行时验证步骤
-7. DDL 变更必须有回滚验证步骤
-8. 明确环境要求、数据准备和执行顺序
-
-## 检查点
-- [ ] 所有 P0/P1 任务卡有至少 1 个测试条目
-- [ ] 测试覆盖正常路径 + 边界场景 + 错误路径
-- [ ] 高风险变更有运行时验证步骤
-- [ ] DDL 变更有回滚验证步骤
-- [ ] 环境要求、数据准备和执行顺序已明确
-
-## 注意事项
-- L0 紧急 hotfix 可使用简化测试（最小复现测试或构建前验证命令），但不得完全跳过
-- 纯文档/配置变更不适用本流程
-- 测试条目必须追溯到任务卡和需求基线

package/templates/knowledge/review_rules//344/272/244/344/273/230/345/256/214/345/244/207/346/200/247/345/256/241/346/237/245/350/247/204/345/210/231.md

@@ -1,66 +0,0 @@
----
-name: delivery-completeness
-type: review_rule
-when: 代码审查, review, 交付检查, 上线前检查, 提交检查, 终局宣言
-scope: [backend, frontend]
-products: ["*"]
----
-
-## DEL-01: 交付物缺少终局宣言签名
-pattern: /SoloForge Audit: PASS/
-severity: critical
-scope: [backend, frontend]
-description: 所有交付物末尾必须包含 [SoloForge Audit: PASS - 已通过三重深度推演，确认无潜在隐患]。缺少此签名的交付视为无效
-
-## DEL-02: 验收项缺少边界值覆盖
-pattern: //
-severity: warning
-scope: [backend, frontend]
-check: boundary_coverage
-description: 验收项应覆盖空值(null/undefined)、极端值(MAX_VALUE/空字符串)、异常输入场景，而非仅 happy path
-
-## DEL-03: 涉及外部调用但无异常处理验收
-pattern: /(?:feign|http|restTemplate|webClient|fetch|axios)\s*\(/i
-severity: warning
-scope: [backend, frontend]
-description: 涉及外部 HTTP 调用的代码必须有超时、异常格式、降级场景的验收覆盖
-
-## DEL-04: 涉及状态变更但无事务/幂等验收
-pattern: /(?:@Transactional|save\(|insert\(|update\(|delete\()/i
-severity: warning
-scope: backend
-description: 涉及数据库状态变更的代码必须有事务一致性、幂等性验收覆盖
-
-## DEL-05: 测试断言精度不足（疑似自己证明自己）
-pattern: /(?:toBeTruthy|toBeFalsy|toBeDefined|toBeUndefined|toBeDefined)\s*\(/
-severity: info
-scope: [backend, frontend]
-description: 大量使用模糊断言(toBeTruthy等)可能意味着测试无效。建议增加精确断言(toBe/toEqual/toThrow)
-
-## SEL-01: 技术选型无行业基准支撑
-pattern: //
-severity: critical
-scope: [backend, frontend]
-check: selection_benchmark
-description: 技术选型必须通过 sf_explore 检索至少 3 个行业标准方案。禁止凭空推荐方案
-
-## SEL-02: 推荐方案未说明致命缺点规避策略
-pattern: //
-severity: warning
-scope: [backend, frontend]
-check: selection_mitigation
-description: 最优解宣誓必须明确说明如何规避其他方案的致命缺点。无规避说明视为不完整选型
-
-## TRA-01: 审查发现未按信任分级路由
-pattern: //
-severity: info
-scope: [backend, frontend]
-check: trust_classification
-description: sf_review 结果应按白盒(可跳过)/灰盒(建议审查)/黑盒(强制审查)三级分类展示，禁止平铺所有发现
-
-## TRA-02: 审查报告缺少认知透明度标注
-pattern: //
-severity: info
-scope: [backend, frontend]
-check: transparency_label
-description: 审查结果应标注熔断触发状态、变异检测结果、漂移检测结果，确保人类能看到系统内部决策

package/templates/knowledge/review_rules//345/256/211/345/205/250/345/256/241/346/237/245/350/247/204/345/210/231.md

@@ -1,79 +0,0 @@
----
-name: security-rules
-type: review_rule
-when: 代码审查, review, 安全部署, 安全检查, 安全审计
-scope: [backend, frontend]
-products: ["*"]
----
-
-## SEC-01: SQL 字符串拼接导致注入风险
-pattern: /(SELECT|INSERT|UPDATE|DELETE)\b.*[\+${]/
-severity: critical
-scope: backend
-description: 禁止使用字符串拼接构造 SQL，必须使用参数化查询（PreparedStatement / MyBatis #{}）
-
-## SEC-02: innerHTML 赋值存在 XSS 风险
-pattern: /\.innerHTML\s*=/
-severity: critical
-scope: frontend
-description: 禁止使用 innerHTML 直接插入用户内容，必须使用 textContent 或 DOMPurify 净化
-
-## SEC-03: eval 或 Function 构造器执行动态代码
-pattern: /\beval\s*\(|new\s+Function\s*\(/
-severity: critical
-scope: [backend, frontend]
-description: 禁止使用 eval() 和 new Function()，存在任意代码执行风险
-
-## SEC-04: 硬编码的密码/密钥/token
-pattern: /password\s*=\s*["'][^"']+["']|secret[_-]?key\s*=\s*["'][^"']+["']|api[_-]?key\s*=\s*["'][^"']+["']/i
-severity: critical
-scope: [backend, frontend]
-description: 敏感凭证禁止硬编码在源码中，必须使用环境变量或密钥管理服务
-
-## SEC-05: 日志中打印敏感信息
-pattern: /log\.\w+\(.*(?:password|token|secret|身份证|idcard)/i
-severity: critical
-scope: backend
-description: 禁止在日志中输出密码、token、身份证号等敏感字段，必须脱敏处理
-
-## SEC-06: 未验证的外部重定向
-pattern: /redirect\s*\(\s*(?:req|request|ctx)\.\w+/
-severity: warning
-scope: backend
-description: 重定向目标必须校验白名单域名，防止开放重定向攻击
-
-## SEC-07: 路径遍历风险
-pattern: /\.\.\/|\.\.\\/
-severity: warning
-scope: [backend, frontend]
-description: 文件路径操作必须校验和规范化，防止通过 ../ 遍历到非授权目录
-
-## SEC-08: 不安全的反序列化
-pattern: /ObjectInputStream|unserialize|pickle\.load/
-severity: critical
-scope: backend
-description: 禁止直接反序列化不可信数据，必须使用白名单校验或 JSON 替代方案
-
-## SEC-09: SSRF 服务端请求伪造
-pattern: /(?:HttpClient|RestTemplate|WebClient|OkHttp|URLConnection)\s*\(\s*(?:req|request|ctx|param)\./
-severity: critical
-scope: backend
-description: 外部 URL 请求禁止直接使用用户输入，必须校验 IP/域名白名单，防止 SSRF 攻击
-
-## SEC-10: CORS 配置过于宽松
-pattern: /allowedOrigins\s*\(\s*"\*"\s*\)|Access-Control-Allow-Origin.*\*/
-severity: warning
-scope: backend
-description: CORS 配置禁止使用通配符 *，必须指定具体域名白名单
-
-## SEC-11: 未启用 HTTPS 的 Cookie
-pattern: /cookie.*(?:secure\s*:\s*false|httpOnly\s*:\s*false)/i
-severity: warning
-scope: [backend, frontend]
-description: 敏感 Cookie 必须设置 Secure 和 HttpOnly 标志
-
-## SEC-12: JWT 未校验签名算法
-pattern: /JWT|jwt.*verify|jwt.*decode/
-severity: critical
-scope: backend
-description: JWT 必须显式指定签名算法（如 HS256/RS256），禁止接受 none 算法

package/templates/knowledge/review_rules//345/271/266/345/217/221/345/256/241/346/237/245/350/247/204/345/210/231.md

@@ -1,67 +0,0 @@
----
-name: concurrency-rules
-type: review_rule
-when: 代码审查, review, 并发检查, 线程安全检查, 锁检查
-scope: [backend]
-products: ["*"]
----
-
-## CON-01: 共享可变状态无并发保护
-pattern: "synchronized|ReentrantLock|AtomicInteger|volatile"
-severity: warning
-scope: backend
-description: 涉及金额、库存、计数器的操作必须显式声明并发控制策略。若未使用任何并发控制原语，标记为需人工确认
-
-## CON-02: 分布式环境使用 JVM 级锁
-pattern: "synchronized\\s*\\(|ReentrantLock"
-severity: warning
-scope: backend
-description: 多实例部署场景下 synchronized/ReentrantLock 无法跨 JVM，必须使用分布式锁（Redis/Redisson）
-
-## CON-03: 先查后改未用原子操作
-pattern: "SELECT.*stock|SELECT.*count|SELECT.*amount.*WHERE"
-severity: warning
-scope: backend
-description: 库存/余额/计数器等场景禁止先 SELECT 再 UPDATE，必须使用原子操作（UPDATE SET x = x - 1 WHERE x >= 1）
-
-## CON-04: @Transactional 同类内部调用
-pattern: "this\\.|@Transactional"
-severity: warning
-scope: backend
-description: @Transactional 方法被同类内部 this.xxx() 调用时 AOP 代理失效，事务不生效
-
-## CON-05: 事务内执行外部调用
-pattern: "RestTemplate|FeignClient|HttpClient|WebClient"
-severity: info
-scope: backend
-description: 事务方法中执行外部 HTTP 调用会延长事务持有时间，建议移到事务外或使用 REQUIRES_NEW 隔离
-
-## CON-06: SimpleDateFormat 非线程安全
-pattern: "SimpleDateFormat"
-severity: warning
-scope: backend
-description: SimpleDateFormat 非线程安全，多线程共享会导致日期解析错误，使用 DateTimeFormatter 或 ThreadLocal
-
-## CON-07: ThreadLocal 未清理导致内存泄漏
-pattern: /ThreadLocal\s*<|new\s+ThreadLocal/
-severity: warning
-scope: backend
-description: ThreadLocal 必须在请求结束时 remove()，否则线程池复用会导致内存泄漏和数据串线
-
-## CON-08: 非线程安全的集合用作类成员变量
-pattern: /private\s+(?:static\s+)?(?:final\s+)?(?:HashMap|ArrayList|LinkedList|HashSet)\s*</
-severity: warning
-scope: backend
-description: 类级别的共享集合必须使用 ConcurrentHashMap/CopyOnWriteArrayList 等线程安全实现
-
-## CON-09: CompletableFuture 未处理异常
-pattern: /CompletableFuture.*(?:thenApply|thenAccept|thenCompose)\s*\(/
-severity: warning
-scope: backend
-description: CompletableFuture 链必须以 exceptionally() 或 handle() 结尾，防止异常被静默吞掉
-
-## CON-10: 线程池未正确配置拒绝策略
-pattern: /new\s+ThreadPoolExecutor\s*\(/
-severity: warning
-scope: backend
-description: 线程池必须显式配置拒绝策略（CallerRunsPolicy/自定义），禁止使用默认 AbortPolicy

package/templates/knowledge/review_rules//346/200/247/350/203/275/345/256/241/346/237/245/350/247/204/345/210/231.md

@@ -1,61 +0,0 @@
----
-name: performance-rules
-type: review_rule
-when: 代码审查, review, 性能检查, 性能优化
-scope: [backend, frontend]
-products: ["*"]
----
-
-## PER-01: 循环内逐条数据库调用（N+1 问题）
-pattern: /(?:for|while)\s*\(.*\)[\s\S]*?\.(?:save|insert|update|delete|query|select|findBy)\s*\(/
-severity: warning
-scope: backend
-description: 循环内禁止逐条数据库操作，必须使用批量 SQL 或 IN 查询
-
-## PER-02: SELECT * 查询未指定字段
-pattern: /SELECT\s+\*\s+FROM/i
-severity: info
-scope: backend
-description: 查询应明确指定所需字段，避免传输不必要的数据
-
-## PER-03: 未使用分页的大列表查询
-pattern: /findAll\s*\(\s*\)|\.toList\(\)\s*;|find\s*\(\s*\{\s*\}\s*\)/
-severity: warning
-scope: backend
-description: 列表查询必须分页，禁止一次加载全量数据
-
-## PER-04: 大循环内创建对象或字符串拼接
-pattern: /(?:for|while)\s*\(.*\)[\s\S]*?new\s+(?:ArrayList|HashMap|StringBuilder)/
-severity: info
-scope: backend
-description: 大循环内避免重复创建对象，应提前初始化或使用对象池
-
-## PER-05: 前端组件不必要的重渲染
-pattern: /onClick=\{\(\).*=>|style=\{\{/
-severity: info
-scope: frontend
-description: 内联函数和对象作为 props 会导致子组件不必要的重渲染，应使用 useCallback/useMemo
-
-## PER-06: 未使用 useMemo/useCallback 的高开销计算
-pattern: /(?:\.sort|\.filter|\.map|\.reduce)\s*\(.*=>.*(?:\.sort|\.filter|\.map)/
-severity: info
-scope: frontend
-description: 链式数组操作或高开销计算应使用 useMemo 缓存结果，避免每次渲染重复计算
-
-## PER-07: 未使用连接池的数据库连接
-pattern: /DriverManager\.getConnection/
-severity: warning
-scope: backend
-description: 禁止使用 DriverManager 直接创建连接，必须使用连接池（HikariCP/Druid）
-
-## PER-08: 大事务包含非必要操作
-pattern: /@Transactional[\s\S]*?(?:log\.|email|send|notify|http)/
-severity: warning
-scope: backend
-description: @Transactional 方法内禁止包含发送邮件、HTTP 调用、MQ 发送等非必要操作，避免长事务
-
-## PER-09: 前端图片未压缩或懒加载
-pattern: /<img\s+src=/
-severity: info
-scope: frontend
-description: 图片资源必须使用压缩/懒加载/响应式加载，禁止原始大图直接展示