soloforge 1.1.46 → 1.1.48

package/templates/build//351/233/267/345/214/272/345/217/215/346/250/241/345/274/217.md

@@ -1,135 +0,0 @@
----
-id: 雷区反模式
-kind: guidance
-title: 雷区反模式
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 雷区清单
-  - 反模式
-  - 性能陷阱
-  - 安全风险
-  - 架构隐患
-  - minefield
-  - antipattern
-extra:
-  name: minefield-antipattern-list
-  type: constraint
-  scope:
-    - '*'
-  domain: build
-  lifecycle_status: active
-  version: 1.2.0
-  last_reviewed: '2026-06-04'
-  products:
-    - '*'
-  verification_layer: L2
-  stage: build
-  owner_mechanism: mc-existing-system-review
----
-
-# 雷区反模式清单
-
-## MINE-DB-01: 无索引大表查询
-  id: MINE-DB-01
-  name: 无索引大表查询
-  severity: error
-  check_type: deterministic
-  check_hint: 超过 10 万行的表缺少合理索引
-  description: 大表（超过 10 万行）缺少合理索引会导致全表扫描，严重影响查询性能。须在改造时补充索引。
-
-## MINE-DB-02: 循环查库
-  id: MINE-DB-02
-  name: 循环查库
-  severity: error
-  check_type: deterministic
-  check_hint: 在循环体内执行数据库查询（N+1 问题）
-  description: 在循环体内执行数据库查询是典型的 N+1 问题，会导致数据库压力剧增。应改为批量查询或 JOIN。
-
-## MINE-DB-03: 全表扫描
-  id: MINE-DB-03
-  name: 全表扫描
-  severity: warning
-  check_type: deterministic
-  check_hint: WHERE 条件未命中索引导致全表扫描
-  description: WHERE 条件未命中索引或使用函数包裹索引列导致全表扫描。应优化查询条件或补充合适的索引。
-
-## MINE-DB-04: 缺事务
-  id: MINE-DB-04
-  name: 缺事务
-  severity: error
-  check_type: deterministic
-  check_hint: 多表写操作未使用事务保护
-  description: 涉及多表写入的操作未使用事务保护，可能导致数据不一致。必须补充事务注解或编程式事务。
-
-## MINE-CODE-01: 硬编码配置
-  id: MINE-CODE-01
-  name: 硬编码配置
-  severity: error
-  check_type: deterministic
-  check_hint: 数据库连接、API 地址等硬编码在代码中
-  description: 数据库连接字符串、API 地址、文件路径等配置项硬编码在源码中，应提取到配置文件或环境变量。
-
-## MINE-CODE-02: 硬编码密钥
-  id: MINE-CODE-02
-  name: 硬编码密钥
-  severity: error
-  check_type: deterministic
-  check_hint: 密码、Token、密钥等直接写在源码中
-  description: 密码、Token、密钥、证书等敏感信息直接写在源码中是严重安全风险。必须使用密钥管理服务或加密配置。
-
-## MINE-CODE-03: 大函数
-  id: MINE-CODE-03
-  name: 大函数
-  severity: warning
-  check_type: deterministic
-  check_hint: 单个函数超过 80 行或单个类超过 1000 行
-  description: 单个函数超过 80 行说明职责过多，应拆分为更小的函数。单个类超过 1000 行应考虑拆分为更小的类。
-
-## MINE-CODE-04: 循环调接口
-  id: MINE-CODE-04
-  name: 循环调接口
-  severity: error
-  check_type: deterministic
-  check_hint: 在循环体内调用 HTTP/RPC 接口
-  description: 在循环体内调用 HTTP/RPC 接口会导致大量网络请求，严重影响性能。应改为批量接口调用或异步处理。
-
-## MINE-CODE-05: 吞异常
-  id: MINE-CODE-05
-  name: 吞异常
-  severity: error
-  check_type: deterministic
-  check_hint: catch 块为空或只打印日志不处理
-  description: catch 块为空或仅打印日志不进行处理，会隐藏错误导致问题难以定位。必须至少记录日志并向上传播或标记为降级。
-
-## MINE-ARCH-01: 循环依赖
-  id: MINE-ARCH-01
-  name: 循环依赖
-  severity: error
-  check_type: deterministic
-  check_hint: 模块间存在循环引用
-  description: 模块间存在 A→B→A 的循环依赖，导致无法独立部署和测试。应引入接口层或事件机制解耦。
-
-## MINE-ARCH-02: 共享数据库
-  id: MINE-ARCH-02
-  name: 共享数据库
-  severity: warning
-  check_type: semantic
-  check_hint: 多个服务直接操作同一个数据库表
-  description: 多个服务直接操作同一个数据库表（非只读），会导致数据一致性问题。应通过 API 或事件机制协调。
-
-## MINE-ARCH-03: 缺降级
-  id: MINE-ARCH-03
-  name: 缺降级
-  severity: error
-  check_type: semantic
-  check_hint: 外部依赖无降级/兜底策略
-  description: 关键外部依赖（支付、通知、数据同步）无降级/兜底策略，一旦外部服务不可用会导致核心功能中断。
-
-## MINE-ARCH-04: 同步阻塞
-  id: MINE-ARCH-04
-  name: 同步阻塞
-  severity: warning
-  check_type: semantic
-  check_hint: 高延迟操作使用同步调用
-  description: 高延迟操作（文件处理、大数据量计算、跨系统同步）使用同步调用会阻塞线程，影响系统吞吐量。应考虑异步处理。

package/templates/build//351/252/214/346/224/266/346/240/207/345/207/206/345/256/241/346/237/245.md

@@ -1,64 +0,0 @@
----
-id: ka-review-rule-验收标准审查规则
-kind: guidance
-title: 验收标准审查
-sync_policy: copy_to_project
-status: active
-triggers:
-  - verify
-  - 验收标准
-  - acceptance review
-extra:
-  name: acceptance-criteria-review
-  type: constraint
-  scope:
-    - backend
-    - frontend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.3.0
-  last_reviewed: '2026-06-04'
-  domain: build
-  verification_layer: L2
-  stage: build
-  owner_mechanism: mc-local-acceptance
----
-
-# 验收标准审查规则
-
-## ACC-01: 验收场景覆盖三路径
-
-check_hint: 验收场景必须覆盖正常路径、边界条件和异常路径
-severity: error
-check_type: semantic
-evidence_required: ["测试计划中 P0 条目的覆盖策略分布"]
-scope: [backend, frontend]
-description: 验收测试至少包含：正常业务流程（happy path）、边界值输入（最大/最小/空值）、异常处理（错误输入、网络超时、权限不足）
-
-## ACC-02: 验收证据含截图或日志
-
-check_hint: 每个验收场景必须有执行证据
-severity: error
-check_type: deterministic
-evidence_required: ["每个 P0 测试条目的 evidence 文件路径"]
-scope: [backend, frontend]
-description: 验收证据可以是：UI 截图、API 响应日志、测试输出报告；纯文字描述不构成有效证据
-
-## ACC-03: 用户确认记录
-
-check_hint: 验收结果必须经用户确认
-severity: error
-check_type: deterministic
-evidence_required: ["sf_gate 返回的用户确认记录"]
-scope: [backend, frontend]
-description: sf_gate 返回的验收结果必须有用户确认的记录；AI 不得自行标记验收通过
-
-## ACC-04: 回归验证
-
-check_hint: 验收必须包含回归验证
-severity: error
-check_type: deterministic
-evidence_required: ["回归测试执行结果"]
-scope: [backend, frontend]
-description: 变更代码的验收必须运行全量回归测试，确认变更未破坏已有功能

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

@@ -1,75 +0,0 @@
----
-id: ka-procedure-验收测试规划
-kind: guidance
-title: 验收测试规划
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 验收测试
-  - 验收规划
-  - 验收标准
-  - acceptance test
-  - 验收计划
-  - 测试用例设计
-  - 验证计划
-  - 测试计划
-  - 验证策略
-  - verification plan
-  - 测试规划
-  - 集成测试计划
-extra:
-  name: acceptance-test-planning
-  type: procedure
-  scope:
-    - backend
-    - frontend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.2.0
-  last_reviewed: '2026-06-04'
-  domain:
-    - build
-    - verify
-  verification_layer: L2
-  stage: build
-  owner_mechanism: mc-delivery-gate
----
-
-## 适用场景
-基于任务卡片规划验收测试范围、优先级和覆盖策略，确保 P0/P1 功能有明确验收标准。
-
-## 步骤
-1. 确认任务卡片和交付蓝图已冻结
-2. 识别所有功能点的测试覆盖需求
-3. 创建测试条目，每条追溯到任务卡和需求基线
-4. P0/P1 测试必须覆盖：正常路径 + 至少一个错误路径
-5. L0 紧急修复可使用简化测试但不得完全跳过
-6. 测试框架由技术栈决定
-7. 明确验收标准和验收场景（基于需求文档和验收清单）
-8. 准备测试数据（覆盖正常流、异常流、边界值、权限场景）
-9. 执行验收测试并记录结果（通过/失败/阻塞），失败项关联缺陷
-10. 回归测试：修复缺陷后重新验证相关场景
-10a. repair_reverify 循环（失败项修复后）：
-   1. 重新执行失败的测试场景
-   2. 重新执行受影响的回归测试范围
-   3. 最多重试 max_attempts 次（默认 3）
-   4. 超过 max_attempts 仍失败 → 上报用户决策（降级/延期/重构）
-11. 输出验收报告（测试覆盖率、通过率、遗留风险），作为上线依据
-
-## 检查点
-- [ ] 所有 P0 任务卡有至少 1 个测试条目
-- [ ] 所有 P1 任务卡有至少 1 个测试条目
-- [ ] 覆盖策略包含正常路径、边界场景、错误路径
-- [ ] 测试条目追溯到任务卡和需求基线
-- [ ] 验收场景覆盖所有需求点
-- [ ] 测试数据准备完毕
-- [ ] 验收报告输出并评审
-
-## 注意事项
-- 测试必须在实现前生成（先失败后实现）
-- 每个测试至少 1 个断言
-- 纯文档/配置变更不适用本流程
-- 验收测试必须在类生产环境执行，禁止在开发环境验收
-- 验收发现的 P0/P1 问题必须在上线前修复
-- 性能验收必须模拟真实数据量和并发量

package/templates/design/API/350/256/276/350/256/241.md

@@ -1,47 +0,0 @@
----
-id: ka-pattern-api-design
-kind: knowledge
-title: API设计
-sync_policy: copy_to_project
-status: active
-extra:
-  name: api-design
-  scope:
-    - backend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.1.0
-  last_reviewed: '2026-06-01'
-  type: knowledge
-  domain:
-    - build
-    - design
-  verification_layer: L2
-  stage: design
-  owner_mechanism: mc-backend-pattern
----
-
-## 决策规则
-- 业务输入参数超过 3 个必须封装为 Request 对象，禁止平铺离散 query/path/body 参数
-- 业务输出超过 1 个返回值必须封装为 Response 对象，禁止多个并列标量字段或 Map 作为正式契约
-- 列表查询必须定义：过滤条件、分页参数、排序规则、默认排序
-- 批量接口必须定义：每批上限、部分成功策略、失败详情返回格式
-- 删除操作必须明确声明：软删除/硬删除/级联删除/逻辑失效、可恢复性、前置校验、关联数据影响
-- 需要幂等或去重的接口必须显式定义幂等键或去重规则
-- 导出复用列表筛选条件时必须显式声明，列表和导出不得使用不同筛选语义
-- API 必须包含版本号路径前缀（如 /api/v1/），破坏性变更递增主版本号
-- 写接口必须有幂等设计（使用 Idempotency-Key 或业务唯一键），防止重复提交
-- API 必须实现限流保护（Rate Limiting），响应头包含剩余配额信息
-- 接口文档必须使用 OpenAPI/Swagger 自动生成，禁止手工维护独立文档
-- 批量操作接口必须限制单次数量（如 ≤ 100），防止超时和资源耗尽
-
-## 验收项
-- [AC-01] 多参数接口使用 Request/Response 对象封装
-- [AC-02] 列表接口有分页和排序定义
-- [AC-03] 批量接口有上限和部分成功策略
-- [AC-04] 删除接口声明了删除语义和可恢复性
-- [AC-05] API 有版本号前缀
-- [AC-06] 写接口幂等设计
-- [AC-07] 有限流保护
-- [AC-08] 文档自动生成

package/templates/design/N/345/212/2401/346/237/245/350/257/242.md

@@ -1,48 +0,0 @@
----
-id: ka-pattern-n-plus-one-query
-kind: knowledge
-title: N加1查询
-sync_policy: copy_to_project
-status: active
-extra:
-  name: n-plus-one-query
-  scope:
-    - backend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.1.0
-  last_reviewed: '2026-06-01'
-  type: knowledge
-  domain:
-    - build
-    - design
-  verification_layer: L2
-  stage: design
-  owner_mechanism: mc-backend-pattern
----
-
-## 决策规则
-- 禁止在循环中执行数据库查询（N+1 反模式），必须改为批量查询或 JOIN
-- 列表页面展示关联数据必须使用 JOIN 或批量 IN 查询，禁止逐条查询关联实体
-- MyBatis 关联查询优先使用 `<collection>` 和 `<association>` 做批量映射，禁止 N+1 嵌套 select
-- 分页查询必须使用数据库 LIMIT，禁止内存分页（先查全量再 subList）
-- 列表查询字段禁止 SELECT *，只查展示所需字段
-- 慢查询（> 500ms）必须有索引支撑或查询计划分析
-- 批量 IN 查询参数数量建议不超过 500，超过时分批执行
-- 大数据量统计查询必须走汇总表或缓存，禁止实时 COUNT/SUM 全表扫描
-- 必须使用 JPA @EntityGraph 或 JOIN FETCH 显式指定关联查询策略
-- 批量查询替代循环查询必须使用 IN 子句（WHERE id IN (...)），单次 IN 数量 ≤ 500
-- MyBatis 必须使用 <collection> 或 <association> 做关联映射，禁止分段查询
-- 列表页面需要关联数据时，先查主表 ID 列表再批量查关联表（两步查询模式）
-- 必须在开发和测试环境开启 SQL 日志（hibernate.show_sql），便于发现 N+1 问题
-
-## 验收项
-- [AC-01] 无循环内数据库查询
-- [AC-02] 列表关联数据使用 JOIN 或批量查询
-- [AC-03] 分页使用数据库 LIMIT
-- [AC-04] 查询字段非 SELECT *
-- [AC-05] 慢查询有索引支撑
-- [AC-06] 关联查询使用 JOIN FETCH / @EntityGraph
-- [AC-07] 批量查询使用 IN 子句
-- [AC-08] 开发环境开启 SQL 日志

package/templates/design/OOD/350/256/276/350/256/241.md

@@ -1,72 +0,0 @@
----
-id: ka-procedure-OOD设计工作流
-kind: guidance
-title: OOD设计
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 面向对象设计
-  - SOLID
-  - 领域服务
-  - 业务规则实现
-  - 重构
-extra:
-  name: ood-design-workflow
-  type: procedure
-  scope:
-    - backend
-    - frontend
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.2.0
-  last_reviewed: '2026-06-04'
-  domain: design
-  verification_layer: L2
-  stage: design
-  owner_mechanism: mc-ood-solid-contract
----
-
-## 适用性判定（前置门控）
-
-| 判定条件 | 适用 | 不适用 |
-|---------|------|--------|
-| 复杂对象边界（多对象协作、继承/组合关系） | ✅ | |
-| 变化点（多策略/多实现/扩展点） | ✅ | |
-| 领域服务或业务规则封装 | ✅ | |
-| 简单 CRUD 或单表操作 | | ✅ |
-| 纯 UI/样式调整 | | ✅ |
-
-不适用时：记录"不适用理由"一句话，跳过本工作流。
-
-## 步骤
-
-### Step 1: 列出对象职责与依赖
-- **属性**: LLM 推理
-- **输入**: 架构设计文档中的模块/实体定义
-- **输出**: 对象职责清单 + 依赖方向图 + 主要协作流程
-
-### Step 2: SOLID 逐项分析
-- **属性**: LLM 推理
-- **输入**: Step 1 对象职责清单
-- **输出**: SOLID 风险与取舍分析
-- **Agent 行为**: 对 S/O/L/I/D 逐项分析，每项标注风险（高/中/低）+ 取舍说明
-
-### Step 3: 修正硬失败
-- **属性**: LLM 推理 + 确定性校验混合
-- **输入**: Step 2 SOLID 分析
-- **输出**: 修正后设计 + 验证证据
-- **Agent 行为**: 高风险项必须修正；修正后重新分析对应项；最多 3 轮；低风险项可标注"已知取舍"
-
-## 输出摘要
-
-| 对象/模块 | 单一职责 | 依赖接口 | 变化点 | SOLID 风险等级 | 修正状态 | 验证证据 |
-|---|---|---|---|---|---|---|
-
-## 输出消费方式
-- 数据库设计（E-01 Step 2）和 API 设计（E-01 Step 3）引用本工作流的对象职责清单和 SOLID 分析
-- 编码后的 SOLID 审查由编码阶段代码审查流程负责，不在此工作流中
-
-## 注意事项
-- 本工作流仅在详细设计阶段执行，不跨阶段
-- 输出摘要表必须填写完整，不得留空行

package/templates/design//344/270/200/350/207/264/346/200/247/346/240/241/351/252/214.md

@@ -1,109 +0,0 @@
----
-id: 一致性校验
-kind: guidance
-title: 一致性校验
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 一致性
-  - 校验
-  - 设计产物
-extra:
-  name: consistency-check
-  type: constraint
-  scope:
-    - '*'
-  products:
-    - '*'
-  lifecycle_status: active
-  domain: design
-  version: 1.3.0
-  last_reviewed: '2026-06-04'
-  verification_layer: L2
-  stage: design
-  owner_mechanism: mc-generic-review
----
-
-# 设计产物一致性校验规则
-
-## 详细设计阶段校验（本阶段执行）
-
-### CON-DD-01: 实体覆盖完整性
-  check_hint: 数据库设计中每张表必须对应架构设计中的实体，且无遗漏实体
-  severity: error
-  description: 架构文档所有 ARCH-* 实体必须在数据库设计中有对应表。遗漏实体必须补充或标注"本次迭代不涉及"。
-  check_focus: 覆盖完整性——提取架构文档所有 ARCH-* 实体，逐一在 DD-T* 中查找
-
-### CON-DD-02: API 模块覆盖完整性
-  check_hint: API 接口规格中每个模块的所有 CRUD 操作必须完整定义
-  severity: error
-  description: 架构文档所有 ARCH-* 模块必须在 API 规格中有对应接口。遗漏操作必须补充或标注"本次迭代不涉及"。
-
-### CON-DD-03: DB-API 字段映射
-  check_hint: API 接口规格中每个字段必须在数据库设计中有对应字段
-  severity: error
-  description: API 请求/响应字段必须精确追溯到数据库表.字段。例外：计算字段/缓存字段/外部服务字段需标注来源。
-
-### CON-DD-04: 约束一致性
-  check_hint: API 字段约束必须与数据库字段约束一致
-  severity: warning
-  description: API 层约束不得弱于数据库层。允许 API 层更严格。不一致处须在设计文档中明确标注。
-
-## 任务规划阶段校验（本文件定义规范，任务规划阶段执行）
-
-### CON-TP-01: 任务-接口关联
-  check_hint: 每个任务必须关联到详细设计中的 DD-* 编号
-  severity: error
-
-### CON-TP-02: 文件路径一致性
-  check_hint: 任务涉及的文件路径必须在详细设计文档中有对应模块描述
-  severity: error
-
-### CON-TP-03: 接口调用一致性
-  check_hint: 任务中的接口调用必须与 API 接口规格文档完全一致
-  severity: error
-
-### CON-TP-04: 数据操作覆盖
-  check_hint: 数据库设计中每张表必须在切片任务中有对应操作覆盖
-  severity: warning
-
-## 跨阶段验证（任务规划门禁触发）
-
-### CON-CROSS-01: 切片-设计路径一致
-  check_hint: 切片计划的涉及文件与详细设计描述的模块路径必须一致
-  severity: error
-
-## 编码阶段校验（编码与单元测试阶段执行）
-
-### CON-TS-01: 切片任务关联设计接口
-  check_hint: 每个切片任务必须关联到 API 接口规格中定义的接口端点
-  severity: error
-  check_type: deterministic
-  description: 切片计划中每个 SLC 的上游引用必须包含 API 接口规格中的接口编号。未关联接口的切片不得进入编码。
-
-### CON-TS-02: 切片覆盖设计全部模块
-  check_hint: 所有设计文档中定义的模块必须被切片任务覆盖
-  severity: error
-  check_type: semantic
-  description: 详细设计中定义的所有模块（DD-*）必须在切片计划中有对应的 SLC 覆盖。遗漏模块须补充切片或标注"本次迭代不涉及"。
-
-### CON-TS-03: 接口规格与切片一致
-  check_hint: 切片涉及的接口签名必须与 API 接口规格完全一致
-  severity: error
-  check_type: deterministic
-  description: 编码时实现的接口签名（HTTP 方法、路径、参数、响应）必须与 API 接口规格文档精确匹配。偏差须更新设计文档并重新评审。
-
-### CON-TS-04: 数据库操作覆盖
-  check_hint: 切片涉及的数据库操作必须在数据库设计文档中有定义
-  severity: error
-  check_type: deterministic
-  description: 切片中涉及的表操作（INSERT/UPDATE/DELETE/SELECT）必须在数据库设计文档中有对应的表定义和约束。未定义的操作须补充设计。
-
-## 校验时机
-1. 详细设计完成后、任务规划前：执行 CON-DD-01~04
-2. 任务规划完成后、编码前：执行 CON-TP-01~04 + CON-CROSS-01
-3. 编码阶段：执行 CON-TS-01~04
-
-## COMP-* 本阶段执行范围（兼容性检查规则在架构阶段定义）
-  **详细设计阶段执行**：COMP-01（字段删除过渡期）、COMP-03（新增必填字段默认值）、COMP-04（枚举值向后兼容）、COMP-05（外键数据完整性）、COMP-07（API 调用方不受影响）
-  **后续阶段执行**：COMP-02（API 版本化→编码阶段）、COMP-06（行为不变量→编码阶段）、COMP-08（配置迁移→部署阶段）、COMP-09（定时任务→部署阶段）、COMP-10（数据迁移语义→联调阶段）、COMP-11（跨阶段一致性→持续）

package/templates/design//344/270/215/347/241/256/345/256/232/346/227/266/345/244/264/350/204/221/351/243/216/346/232/264.md

@@ -1,105 +0,0 @@
----
-id: ka-procedure-不确定时头脑风暴流程
-kind: guidance
-title: 不确定时头脑风暴
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 头脑风暴
-  - brainstorm
-  - 不确定
-  - 你看着办
-  - 都行
-extra:
-  name: brainstorm-when-uncertain
-  type: procedure
-  scope:
-    - '*'
-  domain:
-    - build
-    - design
-  lifecycle_status: active
-  version: 1.0.0
-  last_reviewed: '2026-06-04'
-  verification_layer: L2
-  stage: design
-  owner_mechanism: mc-generic-review
----
-
-# 不确定时头脑风暴流程
-
-## 适用场景
-
-当用户表达不确定、需求不明确、技术选型开放、或 AI 自检不确定时，触发本流程辅助决策。本流程为全局流程，不属于特定能力域。
-
-## 不确定类型分类
-
-| 类型 | 触发关键词/信号 | 典型场景 |
-|------|---------------|---------|
-| 用户不确定 | "你看着办"/"都行"/"不确定"/"都可以" | 用户对方案选择无偏好 |
-| 需求不明确 | 需求描述矛盾/遗漏/模糊 | 需求文档存在冲突 |
-| 技术选型开放 | 多种技术方案均可/无明确约束 | 架构设计（design 域）技术选型 |
-| AI 自检不确定 | 置信度低/多种解释均合理 | AI 无法确定用户真实意图 |
-
-## 流程步骤
-
-### 步骤 1：识别不确定类型
-区分四类不确定，确定进入头脑风暴的原因。
-
-### 步骤 2：列举候选方案（≥ 3 个）
-每个候选方案须包含：
-- 描述：方案概述
-- 优势：该方案的优点
-- 劣势：该方案的缺点
-- 适用场景：最适合的情况
-
-**检查点**：方案间有本质区别（非假多样性）。若 3 个方案本质相同（仅措辞不同），须重新思考。
-
-**若 fundamental_need 为空 → 必须先触发 FP-01**（第一性原理推理规则），补充根本目标后再继续。
-
-### 步骤 3：标注 AI 偏好
-对每个方案标注 AI 偏好：推荐/可选/不推荐 + 理由。AI 偏好基于：
-- 与 fundamental_need 的契合度
-- 技术复杂度和风险
-- 项目约束条件
-- 维护成本
-
-### 步骤 4：呈现给用户
-以对比表格呈现，突出关键差异维度。表格至少包含：方案/优势/劣势/AI偏好/推荐理由。
-
-### 步骤 5：用户选择
-用户明确选择一个方案。用户回复须为明确的方案选择（非"都可以"/"你定"）。
-
-**未通过** → 进入用户模糊降级策略。
-
-### 步骤 6：记录决策
-将用户选择写入对应阶段产物：
-- 需求分析 → 更新需求分析文档
-- 架构设计 → 更新架构决策记录
-- 详细设计 → 更新设计文档
-- 编码阶段 → 更新技术决策注释
-
-## 用户模糊降级策略
-
-当用户回复仍为模糊/不确定时，按 3 级降级处理：
-
-| 级别 | 降级策略 | 条件 |
-|------|---------|------|
-| 1 级 | 重新引导 | 用户首次模糊 → 重新解释差异，追问偏好维度 |
-| 2 级 | 标注偏好 + 可推翻 | 用户二次模糊 → AI 标注推荐方案，告知用户可推翻 |
-| 3 级 | 直接采纳 | 用户三次模糊 → AI 采纳推荐方案，记录"用户未明确选择" |
-
-## 互触发关系
-
-| 触发条件 | 触发动作 |
-|---------|---------|
-| 头脑风暴步骤 2 中 fundamental_need 为空 | → 触发 FP-01（第一性原理推理规则） |
-| FP-03 检测到表面修复（同类问题 ≥ 3 次） | → 建议触发第一性原理推理 |
-| FP-01 和头脑风暴同时需要时 | → FP-01 优先（先确定根本目标，再做方案选择） |
-
-## 禁止行为
-
-1. **禁止直接选唯一方案**：不得在未列举 ≥ 3 个方案的情况下直接推荐唯一方案
-2. **禁止用"建议"替代对比**：不得仅说"建议方案 A"而不提供方案对比
-3. **禁止跳过枚举**：不得跳过候选方案列举步骤直接进入用户选择
-4. **禁止 3 方案本质相同**：候选方案间须有本质区别，不得通过假多样性绕过