soloforge 1.1.2 → 1.1.31

package/templates/procedures//346/246/202/345/277/265/351/252/214/350/257/201/346/265/201/346/260/264/347/272/277.md

@@ -0,0 +1,51 @@
+---
+name: poc-pipeline
+type: pipeline_procedure
+when: '技术验证, POC, 可行性验证, 技术选型, 技术调研, 原型验证, spike'
+scope:
+  - backend
+  - frontend
+products:
+  - '*'
+id: ka-procedure-概念验证流水线
+asset_kind: procedure
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-brainstorm-contract
+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步：调研分析
+明确验证目标和成功标准。调研候选方案的生态成熟度、社区活跃度、性能基准、与现有技术栈兼容性。列出关键评估维度和权重。
+产出保存到：.soloforge/output/01-调研报告.md
+工具：sf_classify
+
+### 第2步：原型实现
+选择 1-2 个最有前景的方案实现最小原型。原型聚焦核心验证点，不追求完整功能。记录实现过程中的关键发现（坑、限制、惊喜）。
+工具：sf_expand, sf_scaffold
+
+### 第3步：评估结论
+对比各方案在关键维度的表现（附量化数据）。给出推荐方案和理由。列出遗留风险和后续关注点。明确结论：推荐采用/需进一步验证/不建议采用。
+模板：POC结论模版.md
+产出保存到：.soloforge/output/03-POC结论.md
+工具：sf_verify, sf_learn

package/templates/procedures//346/265/213/350/257/225/344/274/230/345/205/210/347/274/226/347/240/201/345/267/245/344/275/234/346/265/201.md

@@ -0,0 +1,91 @@
+---
+name: test-first-coding-workflow
+type: procedure
+when: '实现需求, 编码, 开发功能, 写代码, coding, test first, 测试优先, 先写测试'
+scope:
+  - backend
+  - frontend
+products:
+  - '*'
+owner_mechanism_id: mc-coding-readiness
+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 后声称通过
+acceptance_checks:
+  - CodingReadinessGate status 非 blocked
+  - TestFirstPlan 已创建且 status 为 written 或 expected_failure_recorded
+  - 约束消费报告无 blocking_missing_constraints
+  - 主线消费检查无 orphan_findings
+  - 编码完成审查 review.passed 为 true
+id: ka-procedure-测试优先编码工作流
+asset_kind: procedure
+lifecycle_status: active
+authority: supporting
+routes:
+  - code_change
+primary_triggers:
+  - 测试优先编码工作流
+secondary_triggers: []
+negative_triggers: []
+priority: P1
+specificity: 5
+consumes:
+  - mc-intent-router
+emits:
+  - execution_result
+  - evidence
+required_evidence:
+  - workflow_id
+  - required_mechanisms
+version: 1.0.0
+last_reviewed: '2026-05-22'
+migration_note: 知识资产标准化迁移
+status: active
+---
+
+## 适用场景
+任何编码实现前必须先通过编码准备门和测试优先计划。适用于有测试框架和可断言业务逻辑的项目。
+
+## 步骤
+1. **编码准备门**:
+   - 检查是否有验证计划 (verification_plan_ref)
+   - 检查前置条件（现有项目需差距分析，架构设计需 ArchitectureDesignContract）
+   - 检查约束消费
+2. **测试优先计划**:
+   - 有测试框架且行为可断言 → test_first（先写失败测试）
+   - 不能自动测试 → verification_case_first 或 manual_acceptance_first
+   - TestFirstPlan 绑定需求、主链路入口和验收标准
+3. **编码实现**: 按 TestFirstPlan 先写测试、再写实现
+4. **主线消费检查**: 新增文件、组件、API、service 被真实消费
+5. **编码完成审查**: reviewCodingCompletion 验证所有硬规则
+
+## 检查点
+- [ ] CodingReadinessGate allowed
+- [ ] TestFirstPlan status 为 written
+- [ ] 约束消费无 blocking_missing
+- [ ] 主线消费无 orphan
+- [ ] 编码完成审查 passed
+
+## 禁止退化
+- 缺验证计划不得编码
+- blocked/manual_required 不得写实现代码
+- 测试失败不得删测试或降断言
+- 未消费前置条件不得编码

package/templates/procedures//346/272/220/347/240/201/345/216/237/345/236/213/344/272/244/344/273/230/346/265/201/347/250/213.md

@@ -0,0 +1,65 @@
+---
+name: source-prototype-to-delivery
+type: pipeline_procedure
+when: 用户提供需求文档、原型源码
+scope:
+  - backend
+  - frontend
+products:
+  - '*'
+id: ka-procedure-源码原型交付流程
+asset_kind: procedure
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-artifact-contract
+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步：原型抓取
+只能从导出的源码包（如 React/Vite zip）或已解压源码目录提取原型信息：路由、页面组件、布局结构、状态变量、事件处理、弹窗/导航/表单交互、样式令牌和导入的业务说明。禁止使用 Figma MCP、浏览器运行态、figma.site 或截图作为补充来源。若未提供源码包或源码目录，停止原型抓取并要求补充源码输入。对每个端或页面独立输出原型说明。
+模板：原型说明模版.md
+产出保存到：.soloforge/output/01-原型说明.md
+工具：source
+
+### 第2步：架构设计
+根据原型说明和需求文档，设计系统模块划分、数据流向、技术选型与依据、风险点与应对方案。
+产出保存到：.soloforge/output/02-架构设计.md
+
+### 第3步：详细设计
+根据架构设计产出，把数据结构和接口契约落到正式设计载体。
+默认产出：
+- docs/architecture/02-数据库设计文档.md
+- docs/architecture/03-API接口规格文档.md
+- docs/api/openapi.yaml
+- db/migration 或 db/migrations 下的 SQL/migration 权威资产
+
+### 第4步：接口设计
+设计 API 路径、请求/响应结构、错误码、鉴权方案。接口契约必须写入 `docs/architecture/03-API接口规格文档.md` 并与 `docs/api/openapi.yaml` 对齐。
+
+### 第5步：编码实现
+根据切片计划和追踪矩阵绑定的 `SLICE-*`、`DD-*`、`AC-*` 进行前后端编码实现。可使用脚手架生成骨架代码。
+工具：sf_scaffold, sf_expand
+
+### 第6步：测试与审查验收
+执行自动验证（构建 + 测试）、代码审查（质量/安全/性能/架构/技术债务五维度）、学习记录。
+工具：sf_verify, sf_review, sf_learn

package/templates/procedures//347/216/260/346/234/211/347/263/273/347/273/237/345/267/256/350/267/235/345/210/206/346/236/220/345/267/245/344/275/234/346/265/201.md

@@ -0,0 +1,97 @@
+---
+name: existing-system-gap-analysis-workflow
+type: procedure
+when: '现有项目, 新需求, 已有系统, 现有系统, 差距分析, gap analysis, existing system, 现有源码'
+scope:
+  - backend
+  - frontend
+  - infrastructure
+products:
+  - '*'
+owner_mechanism_id: mc-existing-system-analysis
+consumed_contracts:
+  - existing_system_analysis_contract_entry
+  - architecture_design_contract_entry
+  - technology_decision_contract
+  - brainstorm_contract
+  - detail_discipline_contract
+  - first_principles_contract
+required_sections:
+  - 项目上下文检测
+  - 现有系统分析
+  - 需求差距分析
+  - 主线集成计划
+  - 验证计划
+hard_rules:
+  - >-
+    existing_system + new_requirement 必须先生成 ExistingSystemAnalysisContract 和
+    RequirementGapAnalysis
+  - new_system / empty_project 不得强制执行 ExistingSystemAnalysis
+  - unknown 必须 manual_required，不能猜测继续
+  - 现有系统分析必须读取真实代码和相关文档，不能只读需求文档
+  - >-
+    分析结论必须区分 fact / inference / assumption / unknown，并带 confidence 和
+    evidence_refs
+  - 差距分析必须列出现有能力、缺失能力、复用模块、required_changes、兼容/数据/权限/集成风险
+  - 实现前必须有 MainlineIntegrationPlan
+  - VerificationPlan 必须从 RequirementGapAnalysis 生成
+acceptance_checks:
+  - project_context_type 已检测且非 unknown
+  - ExistingSystemAnalysisContract 已创建
+  - RequirementGapAnalysis 已创建
+  - 现有项目已有技术栈和项目约定优先于 SoloForge 默认
+  - 分析结论包含 fact/inference/assumption/unknown 分类
+id: ka-procedure-现有系统差距分析工作流
+asset_kind: procedure
+lifecycle_status: active
+authority: supporting
+routes:
+  - code_change
+primary_triggers:
+  - 现有系统差距分析工作流
+secondary_triggers: []
+negative_triggers: []
+priority: P1
+specificity: 5
+consumes:
+  - mc-intent-router
+emits:
+  - execution_result
+  - evidence
+required_evidence:
+  - workflow_id
+  - required_mechanisms
+version: 1.0.0
+last_reviewed: '2026-05-22'
+migration_note: 知识资产标准化迁移
+status: active
+---
+
+## 适用场景
+已有源码、路由、API、前端页面、权限模型和测试脚本的项目中开发新需求。必须先分析现有系统、再做差距分析、最后才进入设计或编码。
+
+## 步骤
+1. **项目上下文检测**: detectProjectContext 判断 project_context_type
+2. **现有系统分析**:
+   - 读取真实代码和相关文档
+   - 识别技术栈、路由、API、前端页面、权限模型、测试脚本
+   - 区分 fact / inference / assumption / unknown
+3. **需求差距分析**:
+   - 列出现有能力、缺失能力、复用模块
+   - 列出 required_changes、optional_changes、out_of_scope
+   - 列出兼容/数据/权限/集成风险、前后端影响、测试回归范围
+4. **主线集成计划**: 新增文件、组件、API、service、DTO/model、配置必须被真实消费
+5. **验证计划**: VerificationPlan 从 RequirementGapAnalysis 生成
+
+## 检查点
+- [ ] project_context_type 已检测
+- [ ] 现有系统分析读取了真实代码
+- [ ] 差距分析包含完整风险列表
+- [ ] MainlineIntegrationPlan 已创建
+- [ ] VerificationPlan 已从差距分析生成
+
+## 禁止退化
+- existing_system 未分析不得进入设计或编码
+- unknown 类型不得猜测继续，必须 manual_required
+- 不能只读需求文档，必须读代码
+- 缺差距分析不得 coding

package/templates/procedures//347/237/245/350/257/206/347/273/264/346/212/244/346/265/201/346/260/264/347/272/277.md

@@ -0,0 +1,67 @@
+---
+name: knowledge-maintenance-pipeline
+type: pipeline_procedure
+when: '知识维护, 知识更新, 知识审计, 新增知识, 知识库维护, SoloForge维护'
+scope:
+  - backend
+  - frontend
+products:
+  - '*'
+id: ka-procedure-知识维护流水线
+asset_kind: procedure
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-knowledge-injection-boundary
+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步：知识审计
+扫描现有知识库，识别过时条目（长期未被匹配/引用）、重复条目、缺失覆盖的领域。检查知识文件格式一致性。对比设计文档与实际实现的偏差。
+工具：sf_knowledge_audit
+
+### 第2步：知识新增
+根据审计结果和 sf_learn 积累的高频问题，生成新知识条目草稿。草稿保存到 .soloforge/knowledge/drafts/ 目录，人工 review 后移入正式目录。
+工具：sf_knowledge_add
+
+### 第3步：知识更新
+更新已有条目的决策边界、when 触发词、验收项。同步更新设计文档中对应的描述。标记废弃条目（不删除，标记 deprecated）。
+工具：sf_knowledge_update
+
+### 第4步：一致性验证
+重新构建知识索引，验证新增/更新条目可被正确匹配。运行全量测试确认无功能影响。更新设计文档中的知识规模统计。
+工具：sf_verify, sf_learn
+
+### 第5步：定期审计与质量控制
+定期审计知识库（每月），检查过期/重复/不准确的条目。新增知识条目必须经过 review 后才发布（草稿 → 审核 → 正式）。知识条目使用统计数据纳入监控，低使用率条目评估是否保留。知识条目格式必须符合规约（字段顺序、body 标题、when 风格），使用 sf_knowledge_audit 检查。
+
+## 检查点
+- [ ] 知识库审计执行完毕
+- [ ] 新增/更新条目索引验证通过
+- [ ] 新条目经过 review
+- [ ] 低使用率条目已评估
+- [ ] 格式规约检查通过
+
+## 注意事项
+- 废弃条目标记为 deprecated 而非直接删除，保留历史参考
+- 知识条目应保持精简（决策规则 ≤ 20 条），过长难以匹配和阅读
+- 知识条目变更应记录变更历史（更新原因、时间）

package/templates/procedures//347/264/247/346/200/245/344/277/256/345/244/215/346/265/201/346/260/264/347/272/277.md

@@ -0,0 +1,72 @@
+---
+name: hotfix-pipeline
+type: pipeline_procedure
+when: '紧急修复管线, 紧急修复, 生产事故处理管线, P0管线, 热修复管线, hotfix pipeline, hotfix, 线上故障管线, 线上问题修复, 线上报错, 紧急上线, P0, P1, 事故修复, 止血'
+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
+---
+
+# 紧急修复管线
+
+### 第1步：故障定位
+确认问题影响范围和严重程度，通知相关干系人。评估止血方案（配置回滚/功能开关关闭/服务降级/版本回滚），执行止血操作。
+产出保存到：.soloforge/output/01-故障定位.md
+工具：sf_classify, sf_analyze
+
+### 第2步：最小修复
+从 main/release 分支拉取 hotfix 分支。编写最小修复代码（仅修复问题，不重构不优化），快速验证修复场景 + 回归核心功能。
+工具：sf_expand, sf_verify
+
+### 第3步：验证部署
+合并到 main 和 release 分支，打 hotfix tag。部署到生产环境，验证修复效果，监控 30 分钟。
+工具：sf_verify, sf_deliver
+
+### 第4步：故障复盘
+编写事故复盘（根因、影响范围、修复过程、暴露的监控盲区、后续改进项）。与 sf_learn 配合形成闭环。
+模板：故障复盘模版.md
+产出保存到：.soloforge/output/04-故障复盘.md
+工具：sf_learn
+
+### 第5步：验证与闭环
+确认修复影响范围，评估是否需要数据修复脚本。修复代码必须包含回归测试，防止相同问题复现。修复后执行冒烟测试验证关键路径。修复上线后持续观察 1 小时监控，确认无副作用。修复完成后编写故障复盘（根因、影响、修复、预防措施）。
+
+## 检查点
+- [ ] 故障已止血，影响范围已控制
+- [ ] 修复代码已合并并部署
+- [ ] 影响范围已评估
+- [ ] 修复包含回归测试
+- [ ] 冒烟测试通过
+- [ ] 故障复盘已编写
+
+## 注意事项
+- 止血优先于根因修复，先恢复服务再排查问题
+- 紧急修复可以简化流程但不能跳过测试
+- 修复后必须补齐完整测试用例和文档
+- 同一问题重复出现必须升级处理（架构级修复）

package/templates/procedures//347/274/226/347/240/201/345/211/215/346/276/204/346/270/205/346/265/201/347/250/213.md

@@ -0,0 +1,86 @@
+---
+name: 编码前澄清流程
+scope:
+  - '*'
+products:
+  - '*'
+id: ka-procedure-编码前澄清流程
+asset_kind: procedure
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-coding-readiness
+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: 知识资产标准化迁移
+type: pipeline_procedure
+when: 编码前澄清流程
+status: active
+---
+# 编码前澄清流程
+
+## 适用场景
+
+- 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 级不确定

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

@@ -0,0 +1,61 @@
+---
+name: autonomous-tech-selection
+type: procedure
+when: '技术选型, 不知道用什么, 选型, 方案对比, 架构选型, 方案选择, 技术方案'
+scope:
+  - backend
+  - frontend
+products:
+  - '*'
+id: ka-procedure-自主选型流程
+asset_kind: procedure
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-decision-sovereignty
+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. 触发条件检测: 分类结果中 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/procedures//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/345/267/245/344/275/234/346/265/201.md

@@ -0,0 +1,45 @@
+---
+name: design-artifact-pack-workflow
+type: procedure
+when: '架构设计文档, 数据库设计文档, API接口规格文档, 设计文档升级'
+scope:
+  - backend
+  - frontend
+  - infrastructure
+products:
+  - '*'
+owner_mechanism_id: mc-design-artifact-pack
+id: ka-procedure-design-artifact-pack
+asset_kind: procedure
+lifecycle_status: active
+authority: canonical
+routes:
+  - artifact_generation
+primary_triggers:
+  - 设计产物包
+priority: P0
+specificity: 5
+version: 1.0.0
+last_reviewed: '2026-05-25'
+required_evidence:
+  - design_artifact_pack
+  - consistency_verification
+consumes:
+  - architecture_decision_workshop
+  - docs/architecture/00-架构决策记录.md
+  - existing_design_artifacts
+emits:
+  - design_artifact_pack
+  - docs/architecture/99-设计一致性验收报告.md
+  - implementation_ready
+status: active
+---
+
+# 设计产物生成与复验工作流
+
+1. 消费已经用户确认的架构决策记录。
+2. 新项目生成架构、数据库、API、OpenAPI、SQL/migration 及一致性报告。
+3. 现有文档先标记为需要复验，输出差距和待确认变化，不静默覆盖。
+4. 用户确认后归档旧版本并写入修订产物。
+5. 读取真实文件验证 API 字段、SQL 可执行性和跨文档追踪一致性。
+6. 全部通过后才标记为 `implementation_ready`，供后续编码和交付消费。