soloforge 1.1.45 → 1.1.47

package/templates/design//347/254/254/344/270/200/346/200/247/345/216/237/347/220/206/346/216/250/347/220/206.md

@@ -1,182 +0,0 @@
----
-id: ka-review-rule-第一性原理推理规则
-kind: guidance
-title: 第一性原理推理
-sync_policy: copy_to_project
-status: active
-triggers:
-  - first_principles
-  - 第一性原理
-  - fundamental_need
-  - 根因分析
-  - 表面修复
-extra:
-  name: 第一性原理推理规则
-  type: constraint
-  scope:
-    - '*'
-  domain: design
-  lifecycle_status: active
-  version: 1.0.0
-  last_reviewed: '2026-06-04'
-  verification_layer: L2
-  stage: design
-  owner_mechanism: mc-generic-review
----
-
-# 第一性原理推理规则
-
-## FP-01: fundamental_need 声明
-  id: FP-01
-  name: fundamental_need 声明
-  severity: error
-  check_type: semantic
-  evidence_required: 需求分析模版第 1 章 `fundamental_need` 字段存在且非空
-  evidence_producer: AI Agent 推导 + 用户确认
-  首次触发点: 需求分析阶段
-  rule: 需求描述不得以解决方案开头，必须以用户目标开头。需求分析模版 §1.3 的 fundamental_need 字段必须存在且非空，且不得包含技术方案描述（如"做一个XX页面"），必须描述用户目标（如"用户需要在一次会话中完成XX"）。
-
-## FP-02: 推理链完整性
-  id: FP-02
-  name: 推理链完整性
-  severity: error
-  check_type: semantic
-  evidence_required: 原型说明模版第 1 章有推理依据字段，或架构决策研讨记录含推理链
-  evidence_producer: AI Agent 逐步填写 + 用户确认
-  rule: 从 fundamental_need 到最终方案的推理链至少 3 步（目标→约束→可选方案→选定方案），每步必须有明确依据。推理链断裂（跳跃式推导）即标记为 error。
-
-## FP-03: 表面修复检测
-  id: FP-03
-  name: 表面修复检测
-  severity: warning
-  check_type: semantic
-  evidence_required: 历史修复记录中同类问题出现次数 ≥ 3
-  detection_source:
-  1. 当前会话中同一模块的修复次数
-  2. git log 中 fix 提交的同类问题计数
-  3. issue tracker 中同一模块的问题计数
-  rule: 同一模块同类问题 ≥ 3 次 → 提示进行第一性原理推理，识别根因而非继续表面修复。检测到时建议触发 FP-01 重新审视 fundamental_need。
-
-## FP-04: 关键词替代语义检测
-  id: FP-04
-  name: 关键词替代语义检测
-  severity: warning
-  check_type: semantic
-  evidence_required: 新旧方案关键字段对比，语义对齐确认记录
-  rule: 新旧方案对比——术语变更后逻辑是否与新术语语义一致。当方案中使用新术语替换旧术语时，须确认替换后的逻辑仍与新术语的语义一致，而非仅替换关键词但保留旧语义。
-
-## 5. 高影响任务判定标准
-
-以下情况属于高影响任务，须优先执行 FP-01~04 检查：
-
-1. **涉及 3 个以上模块的变更**：跨模块变更影响面广，推理链断裂风险高
-2. **涉及外部系统集成的变更**：外部接口的 fundamental_need 可能被忽视
-3. **涉及数据模型变更**：数据模型变更的根因可能是需求理解偏差
-4. **涉及安全/支付/金额相关逻辑**：高风险领域不容表面修复
-5. **涉及状态机/流程引擎的变更**：状态变更的根因分析须从 fundamental_need 出发
-
-## 6. 阻断恢复机制
-
-  FP 规则检查失败时，最多重试 3 次：
-  1. 第 1 次：提示用户补充信息
-  2. 第 2 次：AI 尝试从上下文推断并呈现给用户确认
-  3. 第 3 次：列举已知约束请求用户决策
-  3 次重试仍失败 → 降级为 warning（非阻断），记录未确认项到产物中
-  降级后继续执行当前阶段，但未确认项须在下一阶段门禁前解决
-
-## 7. 规则引擎接口
-
-```typescript
-interface FPRuleResult {
-  rule_id: "FP-01" | "FP-02" | "FP-03" | "FP-04";
-  passed: boolean;
-  severity: "error" | "warning";
-  message: string;
-  evidence: string;
-  retry_count: number;
-  degraded: boolean;
-}
-
-interface FPCheckContext {
-  stage: string;
-  fundamental_need?: string;
-  reasoning_chain?: string[];
-  fix_history?: Array<{ module: string; description: string; timestamp: string }>;
-  old_terms?: Record<string, string>;
-  new_terms?: Record<string, string>;
-}
-
-function checkFirstPrinciples(ctx: FPCheckContext): FPRuleResult[] {
-  const results: FPRuleResult[] = [];
-
-  // FP-01: fundamental_need 检查
-  if (!ctx.fundamental_need || ctx.fundamental_need.trim() === "") {
-    results.push({
-      rule_id: "FP-01",
-      passed: false,
-      severity: "error",
-      message: "fundamental_need 未声明或为空",
-      evidence: "需求分析模版 §1.3",
-      retry_count: 0,
-      degraded: false,
-    });
-  }
-
-  // FP-02: 推理链完整性
-  if (!ctx.reasoning_chain || ctx.reasoning_chain.length < 3) {
-    results.push({
-      rule_id: "FP-02",
-      passed: false,
-      severity: "error",
-      message: `推理链不足 3 步（当前 ${ctx.reasoning_chain?.length ?? 0} 步）`,
-      evidence: "推理链步骤",
-      retry_count: 0,
-      degraded: false,
-    });
-  }
-
-  // FP-03: 表面修复检测
-  if (ctx.fix_history) {
-    const moduleCounts: Record<string, number> = {};
-    for (const fix of ctx.fix_history) {
-      moduleCounts[fix.module] = (moduleCounts[fix.module] ?? 0) + 1;
-    }
-    for (const [module, count] of Object.entries(moduleCounts)) {
-      if (count >= 3) {
-        results.push({
-          rule_id: "FP-03",
-          passed: false,
-          severity: "warning",
-          message: `模块 ${module} 同类修复 ${count} 次，建议进行根因分析`,
-          evidence: `修复记录: ${count} 次`,
-          retry_count: 0,
-          degraded: false,
-        });
-      }
-    }
-  }
-
-  // FP-04: 关键词替代语义检测
-  if (ctx.old_terms && ctx.new_terms) {
-    const mismatched: string[] = [];
-    for (const [key, oldTerm] of Object.entries(ctx.old_terms)) {
-      if (ctx.new_terms[key] && ctx.new_terms[key] !== oldTerm) {
-        mismatched.push(`${oldTerm} → ${ctx.new_terms[key]}`);
-      }
-    }
-    if (mismatched.length > 0) {
-      results.push({
-        rule_id: "FP-04",
-        passed: false,
-        severity: "warning",
-        message: `术语替换须确认语义一致: ${mismatched.join(", ")}`,
-        evidence: `新旧术语对比`,
-        retry_count: 0,
-        degraded: false,
-      });
-    }
-  }
-
-  return results;
-}
-```

package/templates/design//347/264/247/346/200/245/345/233/236/346/273/232/346/211/213/345/206/214.md

@@ -1,77 +0,0 @@
----
-id: 紧急回滚手册
-kind: artifact
-title: 紧急回滚手册
-sync_policy: copy_to_project
-status: active
-extra:
-  name: emergency-rollback-manual
-  type: artifact
-  scope:
-    - '*'
-  domain: design
-  lifecycle_status: active
-  stage: design
-  owner_mechanism: mc-existing-system-artifact
----
-
-# 紧急回滚手册
-
-## 1. 回滚触发条件
-- 小流量试运行监控指标超过阈值
-- 核心功能不可用
-- 数据一致性问题
-
-## 2. 回滚步骤
-
-### 2.1 触发一键开关
-| 步骤 | 操作 | 命令/操作描述 | 验证 | Evidence |
-|------|------|-------------|------|---------|
-| 1 | 读取一键开关配置 | <!-- 命令 --> | 配置已切换 | 截图/日志 |
-| 2 | 确认切换目标版本 | <!-- 命令 --> | 版本号正确 | 版本号输出 |
-| 3 | 刷新 CDN/缓存（如适用） | <!-- 命令 --> | 缓存已清除 | 缓存命中率 |
-
-### 2.2 数据回滚
-| 步骤 | 操作 | 命令/操作描述 | 验证 | Evidence |
-|------|------|-------------|------|---------|
-| 1 | 执行回滚 SQL | <!-- U{version}__xxx.sql --> | 数据已恢复 | 数据行数校验 |
-| 2 | 验证数据一致性 | <!-- 校验查询 --> | 一致性通过 | 校验结果 |
-
-### 2.3 服务回滚
-| 步骤 | 操作 | 命令/操作描述 | 验证 | Evidence |
-|------|------|-------------|------|---------|
-| 1 | 部署回滚版本 | <!-- 部署命令 --> | 健康检查通过 | 健康检查输出 |
-| 2 | 验证老逻辑功能 | <!-- 冒烟测试 --> | 核心功能正常 | 测试结果 |
-
-## 2.4 回滚总时限
-- 全部回滚操作须在 5 分钟内完成
-- 超时时限未完成 → 执行升级步骤
-
-## 2.5 升级与通知
-| 场景 | 处理方式 |
-|------|---------|
-| 回滚超时 | 停止所有变更操作，保留现场，人工介入 |
-| 数据回滚失败 | 停止回滚，执行数据备份后人工修复 |
-| 服务回滚失败 | 回退到更早的已知稳定版本 |
-
-## 3. 回滚验证
-
-- [ ] 老逻辑功能正常 — Evidence: 冒烟测试结果
-- [ ] 数据一致性校验通过 — Evidence: 数据校验 SQL 结果
-- [ ] 监控指标恢复正常 — Evidence: 监控截图（错误率/P99 延迟）
-- [ ] 回滚总耗时 ≤ 5 分钟 — Evidence: 时间戳记录（开始→完成）
-
-## 4. 回滚后处理
-- 数据清理（临时表/备份表处理策略）
-- 日志记录（回滚原因/触发指标/执行步骤/耗时）
-- 团队通知（相关团队同步回滚信息）
-
-## 5. 回滚审计日志
-
-| 时间 | 操作 | 执行者 | 结果 | 备注 |
-|------|------|--------|------|------|
-| | 触发回滚 | AI建议/人工决定 | | |
-| | 执行步骤 2.1 | | | |
-| | 执行步骤 2.2 | | | |
-| | 执行步骤 2.3 | | | |
-| | 验证完成 | | | |

package/templates/design//347/274/226/347/240/201/345/211/215/346/276/204/346/270/205.md

@@ -1,85 +0,0 @@
----
-id: ka-procedure-编码前澄清流程
-kind: guidance
-title: 编码前澄清
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 编码前澄清
-  - 需求澄清
-  - 编码前确认
-  - 实现前确认
-extra:
-  name: pre-coding-clarification
-  scope:
-    - '*'
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.1.0
-  last_reviewed: '2026-06-01'
-  type: procedure
-  domain: design
-  verification_layer: L2
-  stage: design
-  owner_mechanism: mc-core-engineering-principles
----
-
-# 编码前澄清流程
-
-## 适用场景
-
-- code_execution / multi_stage_plan / single_artifact 路由
-- 写入 scope 涉及业务源码
-- 存在外部副作用
-
-## 流程
-
-### 1. 输入完整性检查
-
-执行前必须确认以下输入:
-- 用户目标是否明确（非模糊描述）
-- 写入 scope 是否确定
-- 是否涉及外部副作用（命令执行、网络请求、文件系统写入）
-- 是否涉及破坏性操作
-
-### 2. 不确定性分级
-
-对每个不确定项分级:
-- **blocking**: 不问不能继续 → 必须向用户提问
-- **material**: 可先推进但需记录假设 → 记录为 AssumptionRecord
-- **minor**: 可合理默认 → 在结果中说明
-- **non_blocking**: 不打断执行
-
-### 3. 澄清问题最小化
-
-- 只问阻塞项，不把非阻塞细节抛给用户
-- 每个问题必须有明确的 blocking 理由
-- 不能把 blocking 不确定伪装成 assumption
-
-### 4. 假设记录
-
-- material 级不确定必须记录为 AssumptionRecord
-- 记录内容: 假设内容、分级、依据、是否需要人工确认
-- blocking 级假设必须标记 needs_manual_confirm=true
-
-### 5. 输入完备报告
-
-完成澄清后生成 InputCompletenessReport:
-- 已明确的输入项
-- 已记录的假设
-- 剩余不确定项及其分级
-- 是否可以开始执行
-
-## 硬阻断
-
-以下情况必须阻断，不得继续:
-- 缺少必要输入
-- 写入 scope 不明确
-- 外部副作用未获授权
-- 存在未解决的 blocking 级不确定
-
-### 2.5 Blocking 超时约束
-- 用户未响应 >30 分钟 → 降级为 material，记录为 assumption_record
-- 同一 blocking 问题第 2 次未响应 → 自动记录假设，needs_manual_confirm=true
-- 超时降级不等于放行：假设须在编码完成后由用户确认

package/templates/design//350/200/201/347/263/273/347/273/237/345/210/207/347/211/207/350/247/204/345/210/222.md

@@ -1,48 +0,0 @@
----
-id: 老系统切片规划
-kind: guidance
-title: 老系统切片规划
-triggers:
-  - 老系统
-  - 遗留系统
-  - 切片
-  - 改造
-sync_policy: copy_to_project
-status: active
-extra:
-  name: old-system-slice-planning
-  type: constraint
-  scope:
-    - '*'
-  domain: design
-  lifecycle_status: active
-  verification_layer: L2
-  stage: design
-  owner_mechanism: 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/design//350/207/252/344/270/273/351/200/211/345/236/213.md

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

package/templates/design//350/256/276/350/256/241/344/270/200/350/207/264/346/200/247/351/252/214/346/224/266/346/212/245/345/221/212.md

@@ -1,34 +0,0 @@
----
-id: ka-artifact_template-design-consistency-report
-kind: artifact
-title: 设计一致性验收报告
-sync_policy: copy_to_project
-status: active
-extra:
-  name: design-consistency-report
-  lifecycle_status: active
-  scope:
-    - '*'
-  products:
-    - '*'
-  version: 1.1.0
-  last_reviewed: '2026-06-01'
-  type: artifact
-  domain: design
-  stage: design
-  owner_mechanism: mc-design-artifact-pack
----
-
-# 设计一致性验收报告
-
-## 产物清单与 Hash
-
-## 用户确认与决策引用
-
-## SQL / OpenAPI / 文档验证结果
-
-## 跨产物追踪与冲突处理
-
-## Implementation Readiness 结论
-
-## 残余风险与返工要求

package/templates/design//350/256/276/350/256/241/344/272/247/347/211/251/347/224/237/346/210/220/344/270/216/345/244/215/351/252/214.md

@@ -1,60 +0,0 @@
----
-id: ka-procedure-design-artifact-pack
-kind: guidance
-title: 设计产物生成与复验
-sync_policy: copy_to_project
-status: active
-triggers:
-  - 架构设计文档
-  - 数据库设计文档
-  - API接口规格文档
-  - 设计文档升级
-extra:
-  name: design-artifact-pack-workflow
-  type: procedure
-  scope:
-    - backend
-    - frontend
-    - infrastructure
-  products:
-    - '*'
-  lifecycle_status: active
-  version: 1.2.0
-  last_reviewed: '2026-06-04'
-  domain: design
-  verification_layer: L2
-  stage: design
-  owner_mechanism: mc-design-artifact-pack
----
-
-# 设计产物生成与复验工作流
-
-## 步骤
-
-1. **确定产物清单**
-     输入：需求分析产出 + 任务上下文阶段信息（domain + task_stage）
-     判断哪些子产物需要生成：
-     - 架构设计文档（必有）
-     - 数据库变更方案（若有数据库变更）
-     - 接口对接方案（若有第三方对接）
-     - 改造影响评估（老系统专属，若有改造范围）
-     - 隔离适配器方案（老系统专属，若有隔离需求）
-     输出：产物生成队列
-
-2. **逐产物增量验证**
-     对队列中每个产物：
-     - 生成产物
-     - 运行对应 Gate 检查项
-     - 通过 → 锁定产物，进入下一个
-     - 不通过 → 修复 → 重新检查（最多 3 次）
-     - 3 次不通过 → HOLD，通知用户决策
-
-3. **交叉一致性验证**
-     所有产物通过后：
-     - 数据库变更 ↔ 架构设计文档数据模型一致
-     - 接口对接方案 ↔ 架构设计文档接口设计一致
-     - 各子产物的设计决策交叉引用一致（由 cross_validation 校验）
-
-4. **用户最终确认**
-     - 展示产物清单 + Gate 结果 + 交叉验证结果
-     - 用户确认 → 阶段推进

package/templates/design//350/256/276/350/256/241/350/201/232/345/220/210/346/243/200/346/237/245.md

@@ -1,21 +0,0 @@
----
-id: design-aggregate-checks
-kind: guidance
-title: 设计聚合检查
-triggers:
-  - 架构决策
-  - ADR
-  - 设计
-sync_policy: engine_only
-status: active
-extra:
-  type: constraint
-  scope:
-    - '*'
-  stage: design
-  owner_mechanism: mc-stage-gate-engine
----
-
-# design 阶段聚合检查
-
-收容无单一资产归属的 stage 级 check（如编译/测试/部署证据等）。

package/templates/design//350/257/246/347/273/206/350/256/276/350/256/241-procedures.md

@@ -1,123 +0,0 @@
----
-id: ka-procedure-详细设计流程
-kind: guidance
-title: 详细设计
-sync_policy: copy_to_project
-status: active
-triggers:
-  - design
-  - 接口设计
-  - 数据库设计
-  - DDL设计
-  - 类设计
-  - 详细方案
-  - detailed design
-extra:
-  name: detailed-design
-  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-architecture-design
----
-
-## 适用场景
-从架构设计产出实现锚点（数据结构、接口定义、状态机）、DDL 和映射矩阵。适用于编码前的设计阶段。
-
-详细设计的正式必需产出不是固定的 `docs/design/03-详细设计文档.md` 单文件。默认产出为：
-
-- `docs/design/01-数据库设计文档.md`：承载 `DD-T*`、表字段、索引、审计、租户、安全和生命周期。
-- `docs/design/02-API接口规格文档.md`：承载 `DD-A*`、端点、字段、错误、副作用和验收场景。
-- `docs/api/openapi.yaml`：API 路径、操作和 schema 权威资产。
-- SQL/migration 文件：数据库物理结构权威资产。
-
-`docs/design/03-详细设计文档.md` 仅作为复杂模块或旧项目迁移的可选补充；如果数据库设计和 API 规格已完整承载详细设计，门禁不得强制要求该文件。
-
-## 步骤
-
-### Step 1: 确认架构设计冻结
-- **属性**: 确定性校验（纯函数，不经过 LLM 推理）
-- **输入**: 架构设计文档中所有 ARCH-* 编号
-- **输出**: 架构冻结确认 + ARCH-* 编号清单
-- **Agent 行为**: 校验是否有未决 ARCH-* 项，有则阻断回到架构阶段
-
-### Step 2: 产出数据库详细设计
-- **属性**: LLM 推理
-- **输入**: ARCH-* 编号清单 + 架构设计文档
-- **输出**: design/01-数据库设计文档.md + SQL/migration 文件
-- **产出 ID**: DD-T*
-- **依赖**: Step 1
-
-2a. **头脑风暴触发**：若数据模型方案存在多种设计选择且无明确最优，或 AI 自检不确定：
-   → 进入「不确定时头脑风暴流程」（templates/procedures/不确定时头脑风暴.md）
-   → 若 fundamental_need 为空 → 先触发 FP-01
-- **子流程**: 涉及复杂对象边界时先执行 OOD 工作流，获取摘要后再生成
-
-### Step 3: 产出 API 详细设计
-- **属性**: LLM 推理
-- **输入**: ARCH-* 编号清单 + DD-T* 数据库设计（Step 2 产出）
-- **输出**: design/02-API接口规格文档.md + openapi.yaml
-- **产出 ID**: DD-A*
-- **依赖**: Step 2（API 字段需追溯到 DD-T* 数据库字段）
-- **子流程**: 涉及复杂业务逻辑/状态机时先执行 OOD 工作流
-
-### Step 4: 编码准备确认
-- **属性**: 确定性校验（纯函数）
-- **输入**: 所有详细设计产出
-- **输出**: 编码准备就绪确认 + DD-* 编号索引
-- **依赖**: Step 3
-
-## 验证闭环
-
-1. **error 级失败**（DD-REV-01~07, CON-DD-01~03）：
-   回到失败步骤重做，retry_hint 标注具体规则 ID
-   例：DD-REV-02（实体覆盖）失败 → 回到 Step 2 补充遗漏表
-2. **warning 级失败**（DD-REV-08~09, CON-DD-04）：
-   在未决项中标注，允许继续但编码前必须解决
-3. **修正后重验**：最多 3 次，超过请求用户介入
-
-## 检查点
-
-- [ ] [error] DDL 命名/注释/审计字段/主键完备
-- [ ] [error] DDL 有兼容窗口和回滚策略
-- [ ] [error] 数据库设计声明 DD-T* 并引用 ARCH-*
-- [ ] [error] API 规格声明 DD-A* 并引用 ARCH-*
-- [ ] [error] OpenAPI 与 API 文档路径和字段一致
-- [ ] [error] SQL/migration 权威资产存在
-- [ ] [warning] 页面映射/字段变更/菜单权限/状态机可追溯到 UI 交互设计
-- [ ] [warning] 新增/修改菜单的角色授权和权限标识已文档化
-- [ ] [error] 实现锚点可供任务拆解直接消费
-
-## 注意事项
-- 禁止先写说明文字再补实现锚点（锚点优先）
-- 禁止只写 design/03-详细设计文档.md 而缺少数据库设计、API 规格、OpenAPI 或 SQL/migration
-- DDL 必须指定关联策略和审计策略
-- 复杂对象边界/变化点时必须先执行 OOD 工作流（Step 2/3 子流程）
-- 详细设计文档（design/03-详细设计文档.md）为条件产物，不强制生成
-
-## Agent 完整执行工作流（E-03）
-
-1. [读取] 加载上游产物（架构设计文档 + ADR + 数据库变更方案 + 接口对接方案）
-   老系统额外加载：隔离适配器方案 + 改造影响范围评估
-2. [触发] 调用 sf_work action=act，获取 scope 和 forbidden_tools
-3. [前置校验] Step 1: 确认架构设计冻结（确定性校验）
-4. [OOD 判定] 判断是否需要执行 OOD 工作流（前置门控）
-   - 需要 → 执行 E-02，获取 OOD 摘要
-   - 不需要 → 记录不适用理由
-5. [填充 DB] Step 2: 生成数据库详细设计（LLM 推理）
-6. [填充 API] Step 3: 生成 API 详细设计（LLM 推理）
-   - API 字段追溯到 DD-T* 数据库字段
-7. [准备确认] Step 4: 编码准备确认（确定性校验）
-8. [验证] 运行 Gate 检查（G-01 shared 15 项 + 老系统 G-02 3 项）
-   - error 失败 → 回到对应步骤重做（验证闭环）
-   - warning 失败 → 标注未决项
-9. [老系统] 生成一键开关配置 + 紧急回滚手册（若为老系统管线）
-10. [推进] 调用 sf_work action=verify