soloforge 1.1.42 → 1.1.44

package/templates/build//346/265/213/350/257/225/344/274/230/345/205/210/347/274/226/347/240/201.md

@@ -0,0 +1,99 @@
+---
+id: ka-procedure-测试优先编码工作流
+kind: guidance
+title: 测试优先编码
+sync_policy: copy_to_project
+status: active
+triggers:
+  - 实现需求
+  - 编码
+  - 开发功能
+  - 写代码
+  - coding
+  - test first
+  - 测试优先
+  - 先写测试
+extra:
+  name: test-first-coding-workflow
+  type: procedure
+  scope:
+    - backend
+    - frontend
+  products:
+    - '*'
+  consumed_contracts:
+    - coding_readiness_contract_entry
+    - existing_system_analysis_contract_entry
+    - architecture_design_contract_entry
+    - detail_discipline_contract
+    - first_principles_contract
+  required_sections:
+    - 编码准备门
+    - 测试优先计划
+    - 约束消费报告
+    - 主线消费检查
+    - 编码完成审查
+  hard_rules:
+    - coding workflow 不得直接进入实现
+    - 必须先生成 CodingReadinessGate
+    - 必须先生成 TestFirstPlan 或合法 not_applicable_with_reason
+    - 有测试框架且行为可断言时，必须先写失败测试或回归测试
+    - readiness_status=blocked/manual_required 时不得写实现代码
+    - 现有项目新需求必须消费 ExistingSystemAnalysis 和 RequirementGapAnalysis
+    - 根据架构设计编码时必须消费 ArchitectureDesignContract
+    - 测试失败不得删除测试、降低断言、skip 后声称通过
+    - 每个切片至少覆盖 ≥9 个测试场景（≥3 正常路径 + ≥3 边界条件 + ≥3 异常路径）
+    - 模式 B 不得用于支付/状态流转/权限/跨系统同步逻辑
+  acceptance_checks:
+    - CodingReadinessGate status 非 blocked
+    - TestFirstPlan 已创建且 status 为 written 或 expected_failure_recorded
+    - 约束消费报告无 blocking_missing_constraints
+    - 主线消费检查无 orphan_findings
+    - 编码完成审查 review.passed 为 true
+  lifecycle_status: active
+  version: 1.2.0
+  last_reviewed: '2026-06-04'
+  domain: build
+  verification_layer: L2
+  stage: build
+  owner_mechanism: mc-coding-readiness
+---
+
+## 适用场景
+任何编码实现前必须先通过编码准备门和测试优先计划。适用于有测试框架和可断言业务逻辑的项目。
+
+## 步骤
+1. **编码准备门**:
+   - 检查是否有验证计划 (verification_plan_ref)
+   - 检查前置条件（现有项目需差距分析，架构设计需 ArchitectureDesignContract）
+   - 检查约束消费
+2. **测试优先计划**:
+   - 有测试框架且行为可断言 → test_first（先写失败测试）
+   - 不能自动测试 → verification_case_first 或 manual_acceptance_first
+   - TestFirstPlan 绑定需求、主链路入口和验收标准
+2a. **头脑风暴触发**：若实现方案选择存在不确定性（模式 A/B 不确定、模块间依赖不清晰、反复修复同一逻辑）：
+   → 进入「不确定时头脑风暴流程」（templates/procedures/不确定时头脑风暴.md）
+   → 若 fundamental_need 为空 → 先触发 FP-01
+3. **编码实现**: 按 TestFirstPlan 选择模式：
+   - **模式 A**：严格测试先行（red→green→refactor）——推荐核心逻辑
+     1. 编写失败测试（red）
+     2. 编写最小实现使测试通过（green）
+     3. 重构优化（refactor）
+   - **模式 B**：红绿合并（同时编写测试和实现）——适用简单逻辑/CRUD
+     - 约束：不降低覆盖率（≥9 场景）；不适用于支付/状态流转/权限/跨系统同步
+   - **模式 B 约束**：不降低覆盖率（≥9 场景）；禁止用于支付/状态流转/权限/跨系统同步逻辑
+4. **主线消费检查**: 新增文件、组件、API、service 被真实消费
+5. **编码完成审查**: reviewCodingCompletion 验证所有硬规则
+
+## 检查点
+- [ ] CodingReadinessGate allowed
+- [ ] TestFirstPlan status 为 written
+- [ ] 约束消费无 blocking_missing
+- [ ] 主线消费无 orphan
+- [ ] 编码完成审查 passed
+
+## 禁止退化
+- 缺验证计划不得编码
+- blocked/manual_required 不得写实现代码
+- 测试失败不得删测试或降断言
+- 未消费前置条件不得编码

package/templates/build//346/265/213/350/257/225/350/256/241/345/210/222.md

@@ -0,0 +1,69 @@
+---
+id: ka-artifact_template-测试计划模版
+kind: artifact
+title: 测试计划
+sync_policy: copy_to_project
+status: active
+extra:
+  name: test-plan
+  scope:
+    - backend
+    - frontend
+  products:
+    - '*'
+  lifecycle_status: active
+  version: 1.3.0
+  last_reviewed: '2026-06-04'
+  type: artifact
+  domain: build
+  stage: build
+  owner_mechanism: mc-generic-artifact
+---
+
+# 测试计划
+
+## 1. 测试范围
+- 关联任务卡片：
+- 测试目标（验证哪些功能点）：
+- 不在测试范围内的事项：
+
+## 2. 测试条目
+| 编号 | 功能点 | 测试类型 | 覆盖策略 | 关联需求基线 | 关联切片 | 关联任务卡 | test_phase | 优先级 | Evidence 级别 |
+|------|--------|---------|---------|-------------|-----------|-----------|-----------|--------|--------------|
+| T-01 | 正常流程 | 集成测试 | 正常路径 | REQ-NNN | SLC-{模块}-{序号} | TASK-NNN | red→green | P0 | E1 |
+| T-02 | 参数缺失 | 单元测试 | 错误路径 | REQ-NNN | SLC-{模块}-{序号} | TASK-NNN | red→green | P0 | E1 |
+| T-03 | 权限不足 | 集成测试 | 错误路径 | REQ-NNN | SLC-{模块}-{序号} | TASK-NNN | red→green | P0 | E2 |
+| T-04 | 边界值 | 单元测试 | 边界场景 | REQ-NNN | SLC-{模块}-{序号} | TASK-NNN | combined_red_green | P1 | E1 |
+
+> **Evidence 级别说明**：E0（不可接受：无运行时证据）、E1（最低要求：测试输出/API 响应日志）、E2（推荐：端到端浏览器验证截图 + API 响应 + 数据库状态验证）。P0 核心业务流程推荐 E2。
+
+## 3. 环境与数据
+- 测试环境：
+- 数据准备方式（业务API/页面操作/SQL初始化脚本）：
+- 前置依赖（DDL迁移/配置项/第三方Mock）：
+
+## 4. 执行顺序
+1. DDL 迁移验证
+2. 单元测试
+3. 集成测试
+4. 端到端测试
+
+## 5. 验收标准
+- [ ] 所有 P0 测试条目通过
+- [ ] 所有 P1 测试条目通过
+- [ ] 高风险变更有运行时验证
+- [ ] DDL 变更有回滚验证
+
+## 6. Agent 行为测试（如适用）
+
+| 编号 | Agent 行为 | 测试方式 | 预期结果 | Evidence |
+|------|-----------|---------|---------|---------|
+| AT-01 | 工具调用正确性 | 集成测试 | Agent 调用正确的工具和参数 | 调用日志 |
+| AT-02 | 规划循环收敛性 | 超时检测 | Agent 在 max_steps 内收敛 | 步骤计数 |
+| AT-03 | 错误恢复路径 | 异常注入 | Agent 遇到错误后能重试或降级 | 恢复日志 |
+
+## 7. Evidence 级别声明
+
+- E0: 无运行时证据（仅静态分析/AI 摘要）— 不可接受
+- E1: 运行时证据（测试输出/截图/API 响应日志）— 最低要求
+- E2: 完整运行时 + 端到端浏览器验证 — 推荐用于 P0 项

package/templates/build//346/265/213/350/257/225/350/264/250/351/207/217.md

@@ -0,0 +1,45 @@
+---
+id: ka-pattern-testing-quality
+kind: knowledge
+title: 测试质量
+sync_policy: copy_to_project
+status: active
+extra:
+  name: testing-quality
+  scope:
+    - backend
+    - frontend
+  products:
+    - '*'
+  lifecycle_status: active
+  version: 1.1.0
+  last_reviewed: '2026-06-01'
+  type: knowledge
+  domain: build
+  verification_layer: L2
+  stage: build
+  owner_mechanism: mc-general-pattern
+---
+
+## 决策规则
+- 每个接口至少覆盖：正常流程、参数缺失、权限不足、业务异常、边界值
+- 端到端业务测试必须从浏览器页面模拟真实用户操作，直接 API 调用只能补充不能替代
+- 测试失败必须在源逻辑修复，禁止修改测试来适配 Bug
+- 测试数据准备必须走业务 API 或页面操作，禁止直接 SQL INSERT 业务数据
+- 禁止在测试脚本中硬编码凭据，必须从环境变量或配置文件读取
+- Docker 部署必须从全新镜像构建，禁止 docker commit 和热补丁
+- 单元测试覆盖率核心逻辑必须 ≥ 80%，关键路径（支付/权限）必须 100%
+- 测试方法命名必须清晰表达测试场景（如 shouldReturn401WhenTokenExpired）
+- 测试数据必须使用工厂方法或 Builder 构建，禁止硬编码 magic values
+- 集成测试必须使用测试容器（Testcontainers）或内存数据库，禁止依赖外部环境
+- 每个修复的 bug 必须有对应的回归测试，防止问题复现
+
+## 验收项
+- [AC-01] 接口测试覆盖正常+异常+边界
+- [AC-02] E2E 测试从浏览器模拟用户操作
+- [AC-03] 测试失败修复源逻辑而非改测试
+- [AC-04] 测试数据走业务 API 非 SQL 直写
+- [AC-05] 核心逻辑覆盖率 ≥ 80%
+- [AC-06] 测试方法名清晰表达场景
+- [AC-07] 测试数据工厂构建
+- [AC-08] Bug 修复有回归测试

package/templates/build//347/206/224/346/226/255/351/231/215/347/272/247.md

@@ -0,0 +1,49 @@
+---
+id: ka-pattern-circuit-breaker
+kind: knowledge
+title: 熔断降级
+sync_policy: copy_to_project
+status: active
+extra:
+  name: circuit-breaker
+  scope:
+    - backend
+  products:
+    - '*'
+  lifecycle_status: active
+  version: 1.1.0
+  last_reviewed: '2026-06-01'
+  type: knowledge
+  domain:
+    - build
+    - verify
+  verification_layer: L2
+  stage: build
+  owner_mechanism: mc-backend-pattern
+---
+
+## 决策规则
+- 外部依赖（第三方 API、中间件、其他微服务）必须配置超时时间，禁止无限等待
+- 核心链路的外部调用必须配置熔断器：失败率阈值（建议 50%）、熔断时长（建议 30s）、半开探测数（建议 5）
+- 熔断触发后必须有降级策略：返回缓存数据/默认值/友好提示，禁止直接抛异常给用户
+- 接口必须有限流保护（令牌桶/漏桶），防止突发流量击穿服务
+- 降级方案必须提前定义：降级行为、用户提示文案、数据一致性保障、恢复条件
+- 重试必须满足幂等性，重试间隔必须使用指数退避（initial 100ms, multiplier 2, max 3 次）
+- 线程池隔离：不同外部依赖使用独立线程池，防止一个慢服务拖垮所有请求
+- 必须有服务健康检查端点（/actuator/health），包含依赖组件状态（DB/Redis/MQ）
+- 熔断器必须配置 half-open 状态的探测请求量（如允许 5 个请求通过测试），成功后才恢复
+- 降级 fallback 必须返回有意义的默认值或缓存数据，禁止返回 null 或空对象
+- 熔断/降级事件必须触发监控告警，不能静默降级
+- 外部调用必须设置独立的超时时间（不依赖全局超时），与熔断器配合使用
+- 熔断器状态变化必须有日志记录（closed → open → half-open → closed）
+
+## 验收项
+- [AC-01] 外部调用有超时和熔断配置
+- [AC-02] 熔断后有降级策略和用户提示
+- [AC-03] 重试有指数退避和幂等保障
+- [AC-04] 有限流保护
+- [AC-05] 健康检查端点包含依赖状态
+- [AC-06] half-open 探测机制配置
+- [AC-07] fallback 返回有意义的值
+- [AC-08] 熔断事件有监控告警
+- [AC-09] 外部调用有独立超时

package/templates/build//347/212/266/346/200/201/346/265/201/350/275/254.md

@@ -0,0 +1,43 @@
+---
+id: ka-pattern-state-transition
+kind: knowledge
+title: 状态流转
+sync_policy: copy_to_project
+status: active
+extra:
+  name: state-transition
+  scope:
+    - backend
+  products:
+    - '*'
+  lifecycle_status: active
+  version: 1.1.0
+  last_reviewed: '2026-06-01'
+  type: knowledge
+  domain: build
+  verification_layer: L2
+  stage: build
+  owner_mechanism: mc-backend-pattern
+---
+
+## 决策规则
+- 仅列出状态列表不够，每个状态转换必须定义：触发条件、守卫条件、失败/回滚动作
+- 金额、库存、配额、计数器等并发敏感节点默认需要并发控制
+- 并发敏感操作必须显式声明：并发控制方式（乐观锁/悲观锁/幂等键/去重表）、重试策略、重复提交处理、用户可见失败反馈
+- 跨模块或跨服务状态变更必须显式声明最终一致性和补偿策略
+- 集成测试必须覆盖：至少一次成功转换、一次守卫失败、一次失败恢复或升级路径
+- 状态流转必须通过状态机框架（如 Spring Statemachine）或显式流转表校验，禁止硬编码 if-else
+- 每次状态变更必须记录流转日志（原状态→新状态、操作人、时间、原因）
+- 并发状态变更必须使用乐观锁或分布式锁，防止状态覆盖
+- 状态流转失败必须返回明确的错误原因，告知用户当前状态和允许的下一步操作
+- 状态定义必须包含初始状态和终态，禁止出现无法流转的"悬挂状态"
+
+## 验收项
+- [AC-01] 状态转换有触发条件、守卫条件、回滚动作
+- [AC-02] 并发敏感操作有显式并发控制声明
+- [AC-03] 跨服务状态变更有补偿策略
+- [AC-04] 集成测试覆盖成功和失败路径
+- [AC-05] 状态机校验（非硬编码）
+- [AC-06] 状态变更审计日志
+- [AC-07] 并发状态变更防护
+- [AC-08] 无悬挂状态

package/templates/build//347/213/254/347/253/213/345/256/241/346/237/245.md

@@ -0,0 +1,45 @@
+---
+id: 独立审查
+kind: guidance
+title: 独立审查
+triggers:
+  - 代码审查
+  - review
+  - 独立检查
+sync_policy: copy_to_project
+status: active
+extra:
+  name: independent-review
+  type: constraint
+  scope:
+    - '*'
+  domain: build
+  lifecycle_status: active
+  verification_layer: L2
+  stage: build
+  owner_mechanism: mc-command-router
+---
+
+# 独立审查规则
+
+## 审查测试要求
+
+- 每个任务完成后，独立审查必须新增 ≥9 个测试场景
+- 测试描述和场景必须与编码阶段的实施测试不同（不同角度、不同数据）
+- 审查测试必须覆盖：
+  - 全部公开接口（每个接口至少 2 个场景）
+  - 全部核心逻辑路径（正向 + 反向）
+  - 全部错误处理分支
+
+## 审查覆盖范围
+
+- 接口覆盖：每个公开方法/函数必须有审查测试
+- 逻辑路径覆盖：每个 if/switch 分支必须有测试用例
+- 边界值覆盖：数值边界、空值、超长输入
+- 并发/竞态覆盖（如适用）：多线程/异步场景
+
+## 审查独立性
+
+- 审查测试不得复制实施测试的代码和断言
+- 审查测试必须独立设计测试数据和场景
+- 审查发现的问题必须记录，不得直接修改代码绕过

package/templates/build//347/272/246/346/235/237/345/256/236/347/216/260.md

@@ -0,0 +1,47 @@
+---
+id: ka-pattern-constrained-implementation
+kind: knowledge
+title: 约束实现
+sync_policy: copy_to_project
+status: active
+extra:
+  name: constrained-implementation
+  scope:
+    - backend
+    - frontend
+  products:
+    - '*'
+  lifecycle_status: active
+  version: 1.1.0
+  last_reviewed: '2026-06-01'
+  type: knowledge
+  domain: build
+  verification_layer: L2
+  stage: build
+  owner_mechanism: mc-general-pattern
+---
+
+## 决策规则
+- 必须在修改代码前定位根因，解释根因、修改边界和验证方式后再编码
+- 只修改任务卡/补丁计划/白名单明确范围内的文件
+- 禁止补丁叠补丁或试错式堆叠修复
+- 禁止删除断言、放宽测试、增加 sleep、让测试适应错误行为
+- 禁止顺手重构或范围外的"清理"
+- 每个代码变更必须追溯到任务卡、补丁计划或阻塞性缺陷
+- 范围超出白名单或需要变更接口/DDL/权限/菜单时，立即上报而非自行决定
+- 必须完成本地验证并产出结构化证据后再结束
+- 唯一约束必须同时在数据库和应用层校验，防止并发场景下的重复数据
+- 外键约束在微服务架构中不建议使用物理外键，应通过应用层保证数据一致性
+- 乐观锁必须使用 version 字段而非 update_time（后者可能因精度问题失效）
+- 软删除数据必须排除在唯一约束之外（如添加 is_deleted 条件索引）
+- 数据库约束的校验失败必须返回用户友好的错误消息，而非数据库原始报错
+
+## 验收项
+- [AC-01] 变更范围与白名单完全匹配
+- [AC-02] 根因已确认再编码（非先改再试）
+- [AC-03] 无顺手重构或范围外变更
+- [AC-04] 本地验证执行完毕有结果
+- [AC-05] 超范围变更已上报
+- [AC-06] 唯一约束双层校验
+- [AC-07] 乐观锁用 version 字段
+- [AC-08] 软删除与唯一约束兼容

package/templates/build//347/274/226/347/240/201/345/260/261/347/273/252/345/256/241/346/237/245.md

@@ -0,0 +1,60 @@
+---
+id: ka-review-rule-编码就绪审查规则
+kind: guidance
+title: 编码就绪审查
+sync_policy: copy_to_project
+status: active
+triggers:
+  - build
+  - 编码就绪
+  - coding readiness
+extra:
+  name: coding-readiness-review
+  type: constraint
+  scope:
+    - backend
+    - frontend
+  products:
+    - '*'
+  lifecycle_status: active
+  version: 1.2.0
+  last_reviewed: '2026-06-04'
+  domain: build
+  verification_layer: L2
+  stage: build
+  owner_mechanism: mc-coding-readiness
+---
+
+# 编码就绪审查规则
+
+## READY-01: CodingReadiness 非空
+
+check_hint: 编码前必须确认 CodingReadiness 检查已通过
+severity: error
+check_type: deterministic
+scope: [backend, frontend]
+description: CodingReadiness 报告必须存在且 status 非 blocked；blocked 状态必须先解决前置问题
+
+## READY-02: OOD 摘要完整
+
+check_hint: OOD 设计摘要必须包含类定义、方法签名和协作关系
+severity: warning
+check_type: deterministic
+scope: [backend, frontend]
+description: OOD 摘要至少包含：核心类名、公开方法签名、类间协作关系图；缺少任一项必须补充后再编码
+
+## READY-03: 前置产物已确认
+
+check_hint: 编码依赖的设计产物必须全部就绪
+severity: error
+check_type: deterministic
+scope: [backend, frontend]
+description: API 接口规格、数据库设计文档、切片计划等编码依赖产物必须已生成且无 hard_fail
+
+## READY-04: 技术栈明确
+
+check_hint: 编码前必须确认使用的技术栈和框架版本
+severity: warning
+check_type: deterministic
+scope: [backend, frontend]
+description: 语言版本、框架版本、关键依赖版本必须在编码前明确，避免编码过程中变更技术栈

package/templates/build//347/274/226/347/240/201/350/201/232/345/220/210/346/243/200/346/237/245.md

@@ -0,0 +1,22 @@
+---
+id: build-aggregate-checks
+kind: guidance
+title: 编码聚合检查
+triggers:
+  - 编码
+  - 规范
+  - 命名
+  - 注释
+sync_policy: engine_only
+status: active
+extra:
+  type: constraint
+  scope:
+    - '*'
+  stage: build
+  owner_mechanism: mc-stage-gate-engine
+---
+
+# build 阶段聚合检查
+
+收容无单一资产归属的 stage 级 check（如编译/测试/部署证据等）。

package/templates/build//347/274/226/347/240/201/350/264/250/351/207/217.md

@@ -0,0 +1,46 @@
+---
+id: ka-pattern-coding-quality
+kind: knowledge
+title: 编码质量
+sync_policy: copy_to_project
+status: active
+extra:
+  name: coding-quality
+  scope:
+    - backend
+    - frontend
+  products:
+    - '*'
+  lifecycle_status: active
+  version: 1.1.0
+  last_reviewed: '2026-06-01'
+  type: knowledge
+  domain: build
+  verification_layer: L2
+  stage: build
+  owner_mechanism: mc-general-pattern
+---
+
+## 决策规则
+- 50 行能解决的问题禁止写 200 行；禁止为单次使用场景过度设计
+- 每行代码变更必须可追溯到任务卡片中的显式需求，禁止"顺手"重构相邻代码
+- 实现记录必须显式声明业务入口集成状态（菜单/路由/权限）
+- Bug 修复必须针对根因，禁止在破损代码上叠加 workaround
+- 方法必须按业务步骤拆分为单一职责的私有方法
+- 新增/修改类必须文档化业务职责、边界和关键协作者
+- 仅在"非显而易见"的关键行添加注释说明 why，禁止对简单赋值加噪声注释
+- 方法长度不超过 80 行，超过时拆分为子方法
+- 方法参数不超过 5 个，超过时封装为请求对象
+- 单个类职责单一（SRP），超过 500 行的类应考虑拆分
+- 条件嵌套不超过 3 层，超过时使用卫语句、策略模式或 Optional 链重构
+- 禁止使用魔法数字，必须提取为命名常量或枚举
+
+## 验收项
+- [AC-01] 代码变更可追溯到任务需求
+- [AC-02] 业务入口集成状态已声明
+- [AC-03] Bug 修复针对根因而非 workaround
+- [AC-04] 无过度设计（50行能解决的不写200行）
+- [AC-05] 方法不超过 80 行
+- [AC-06] 参数不超过 5 个
+- [AC-07] 嵌套不超过 3 层
+- [AC-08] 无魔法数字

package/templates/build//347/274/226/347/240/201/351/230/266/346/256/265/346/211/247/350/241/214.md

@@ -0,0 +1,105 @@
+---
+id: 编码阶段执行
+kind: guidance
+title: 编码阶段执行
+sync_policy: copy_to_project
+status: active
+triggers:
+  - 编码执行
+  - 编码阶段
+  - coding stage
+  - 开始编码
+extra:
+  name: coding-stage-execution-workflow
+  type: procedure
+  scope:
+    - backend
+    - frontend
+  products:
+    - '*'
+  domain: build
+  version: 1.0.0
+  last_reviewed: '2026-06-04'
+  lifecycle_status: active
+  verification_layer: L2
+  stage: build
+  owner_mechanism: mc-core-engineering-principles
+---
+
+# 编码阶段执行工作流
+
+## 适用场景
+编码与单元测试阶段的完整 Agent 执行工作流。从读取上游产物到推进至下一阶段的全流程编排。
+
+## 步骤
+
+### 1. [读取] 加载上游产物
+- 加载数据库设计文档（docs/design/01-数据库设计文档.md）
+- 加载 API 接口规格文档（docs/design/02-API接口规格文档.md）
+- 加载 openapi.yaml（若存在）
+- 确认所有设计产物无 hard_fail 状态
+
+### 2. [触发] 调用 sf_work action=act
+- 获取当前 scope 和 forbidden_tools
+- 确认 stage 为"build"
+- 确认 forbidden_tools 不影响编码核心流程
+
+### 3. [任务规划] 执行任务拆解流程（E-01）
+- 执行任务拆解流程 → 选择分解策略 → 生成切片计划 → 生成依赖图
+- 运行 G-01 build-gate（8 项检查）
+- gate 未通过 → 修复后重新执行步骤 3
+
+### 4. [编码准备] 执行编码前澄清流程（E-02）
+- 不确定性分级 → 澄清问题 → 输入完备报告
+- 运行 G-02 build-gate（3 项检查）
+- status=blocked → 阻断，等待用户解决
+- status=allowed → 进入步骤 5
+
+4a. **头脑风暴触发**：若实现方案存在多种选择且无明确最优，或反复修复同一模块 ≥ 3 次：
+   → 进入「不确定时头脑风暴流程」（templates/procedures/不确定时头脑风暴.md）
+   → 若 fundamental_need 为空 → 先触发 FP-01
+
+### 5. [切片循环] 对每个切片执行
+- **5a.** 执行 E-03 测试优先编码工作流
+  - 模式 A（核心逻辑）：red→green→refactor
+  - 模式 B（简单 CRUD）：红绿合并
+- **5b.** 运行 G-03 build-gate（3 项检查）
+- **5c.** 运行 G-06 slice-gate（3 项检查）
+- **5d.** 老系统切片：执行新老逻辑比对（100% 一致率）
+- **5e.** 切片验证点（E-04 步骤 7）：运行测试 → 检查覆盖率 → 确认涉及文件 → 更新测试状态
+- **5f.** 运行 G-05 build-gate（2 项检查）
+- **5g.** 若触发重规划（E-06 动态重规划）：
+  - 局部重规划 → 回到 5a
+  - 结构重规划 → 回到步骤 3
+  - 回退 → 阻断并通知用户
+
+### 6. [编码验证] 运行 G-04 build-gate
+- 构建通过（0 error）
+- 测试通过（passed/failed/total）
+- 覆盖率达标（增量行覆盖率≥阈值）
+- gate 未通过 → 修复后重新运行
+
+### 7. [切片审查] 运行 G-07 slice-gate
+- 独立审查测试充分性
+- 无 hard_fail（代码质量检查）
+- 无遗留问题
+- gate 未通过 → 修复后重新审查
+
+### 8. [推进] 调用 sf_work action=verify
+- 所有 gate 通过后推进至下一阶段
+- 生成编码阶段完成报告
+
+## 检查点
+- [ ] 上游产物已全部加载且无 hard_fail
+- [ ] 任务规划 gate 通过（G-01）
+- [ ] 编码准备 gate 通过（G-02）
+- [ ] 每个切片：编码实现→切片执行→编码与单元测试 gate 全部通过
+- [ ] 编码验证 gate 通过（G-04）
+- [ ] 切片审查 gate 通过（G-07）
+- [ ] 编码阶段完成报告已生成
+
+## 禁止退化
+- 跳过任何 gate 直接推进
+- gate 失败后不修复直接重试
+- 切片循环中跳过老系统比对
+- 重规划时降低验收标准

package/templates/build//347/274/272/351/231/267/347/256/241/347/220/206.md

@@ -0,0 +1,47 @@
+---
+id: ka-pattern-defect-management
+kind: knowledge
+title: 缺陷管理
+sync_policy: copy_to_project
+status: active
+extra:
+  name: defect-management
+  scope:
+    - backend
+    - frontend
+  products:
+    - '*'
+  lifecycle_status: active
+  version: 1.1.0
+  last_reviewed: '2026-06-01'
+  type: knowledge
+  domain:
+    - build
+    - verify
+  verification_layer: L2
+  stage: build
+  owner_mechanism: mc-general-pattern
+---
+
+## 决策规则
+- 每个缺陷必须归因到最小责任阶段（需求/设计/任务拆解/实现/测试/门禁）
+- 修复必须附带证据，"理论上修好了"不可接受
+- 有复现价值的缺陷必须产出至少一项回填动作：规则、模版、检查项或知识条目
+- 同一缺陷若在案例库中已出现过，自动升级为深层缺陷（方法论级别）
+- 报告必须在修复之前编写，禁止先改规则后写报告
+- 缺陷结论必须区分：已完成 / 未完成 / 未验证 / 未知，无真实证据不得标记为已完成
+- 缺陷必须包含完整的复现步骤、预期结果、实际结果和环境信息
+- 每个缺陷必须有优先级（P0-P4）和严重程度（S1-S4）分类
+- 修复缺陷必须包含根因分析，禁止只修表面症状
+- P0/P1 缺陷修复后必须经过回归测试，不能直接上线
+- 缺陷关闭必须由提单人确认，修复人不能自行关闭
+
+## 验收项
+- [AC-01] 缺陷有归因阶段
+- [AC-02] 修复附带执行证据
+- [AC-03] 有复现价值的缺陷有回填动作
+- [AC-04] 结论区分已完成/未完成/未验证/未知
+- [AC-05] 缺陷有完整复现信息
+- [AC-06] 有优先级和严重程度
+- [AC-07] 修复包含根因分析
+- [AC-08] 高优先级缺陷有回归测试