soloforge 1.1.38 → 1.1.40

package/templates/procedures//344/273/273/345/212/241/350/247/204/345/210/222/345/267/245/344/275/234/346/265/201.md

@@ -0,0 +1,83 @@
+---
+name: task-planning-workflow
+type: procedure
+scope:
+  - '*'
+system_scope: existing-system
+products:
+  - '*'
+id: ka-procedure-任务规划工作流
+lifecycle_status: active
+authority: supporting
+owner_mechanism_id: mc-existing-system-artifact
+priority: P1
+consumes:
+  - mc-existing-system-artifact
+emits:
+  - structured_slice_plan
+  - historical_data_cleanup_script
+required_evidence:
+  - 切片计划文件路径
+  - 清洗脚本文件路径
+version: 1.0.0
+last_reviewed: '2026-06-04'
+stages: ["任务规划"]
+triggers: ["任务规划工作流","老系统任务规划","切片缓冲规划","清洗脚本产出","任务规划流程"]
+---
+
+# 任务规划工作流（老系统专属）
+
+> 适用范围：老系统管线阶段 5（任务规划）
+> 输入：详细设计文档 + 一键开关配置 + 回滚手册 + 改造影响范围评估
+> 输出：带缓冲切片计划 + 历史数据清洗脚本
+
+## 步骤 1：读取阶段输入
+
+1. 读取详细设计文档
+2. 读取一键开关配置
+3. 读取紧急回滚手册
+4. 读取改造影响范围评估
+5. **检查点**：所有输入产物存在且可读
+6. 在切片计划 §1.5 阶段输入声明中，逐项标注 ☑ 已读取
+
+## 步骤 2：按切片规划规则拆分切片
+
+1. 使用 shared 切片规划规则（与新系统相同）
+2. 产出切片列表，每个切片标注：DD-* 编号、模块、影响范围
+3. **检查点**：每个切片均有 DD-* 或 ARCH-* 上游引用
+
+## 步骤 3：计算排查缓冲（老系统专属）
+
+1. 对每个切片按特征匹配缓冲比例（见切片计划 §3 判定标准）
+2. 产出结构化缓冲表格（见切片计划 §2 排查缓冲字段）
+3. **检查点**：涉及 DB 迁移的切片缓冲 ≥ 35%
+
+## 步骤 4：产出历史数据清洗脚本
+
+1. 识别涉及数据迁移的切片（缓冲比例 ≥ 35%）
+2. 按清洗脚本模版产出：清洗 SQL + 备份 SQL + 回滚 SQL
+3. 在切片计划 §5 中建立脚本与切片的关联
+4. **检查点**：涉及 DB 迁移的切片均有对应清洗脚本
+
+## 步骤 5：自检
+
+1. 切片与详细设计 DD-* 编号对齐
+2. 排查缓冲表格每项活动有预估时间
+3. 阶段输入声明中所有产物已标注"已读取"
+4. §5 中涉及 DB 迁移的切片均有清洗脚本关联
+
+## 步骤 6：gate-任务规划 校验
+
+1. 运行 gate-任务规划（shared 检查 + 老系统扩展检查）
+2. 通过 → 进入编码阶段
+3. 失败 → 返回对应步骤修正
+
+### 失败回退映射
+
+| gate 检查失败项 | 回退步骤 |
+|---------------|---------|
+| 切片计划完备 | 步骤 2 |
+| 切片与接口/数据库一致性 | 步骤 2 |
+| 排查缓冲完整性（老系统） | 步骤 3 |
+| 阶段输入声明完整性（老系统） | 步骤 1 |
+| 清洗脚本关联完整性（老系统） | 步骤 4 |

package/templates/procedures//344/274/232/350/257/235/346/201/242/345/244/215/346/265/201/347/250/213.md

@@ -1,24 +1,15 @@
 ---
 name: session-resume
 type: procedure
-when: '会话启动, 恢复, resume, 继续开发'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-会话恢复流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
-primary_triggers:
-  - 会话恢复流程
-secondary_triggers:
-  - 恢复上下文
-  - 继续上次工作
-negative_triggers: []
 priority: P1
-specificity: 5
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["需求分析", "架构设计", "详细设计", "任务规划", "编码与单元测试", "代码审查", "联调验证"]
@@ -31,6 +22,7 @@ emits:
   - task_context_snapshot
 required_evidence:
   - session_resume_report
+triggers: ["会话启动","恢复","resume","继续开发"]
 ---
 
 # 会话恢复流程
@@ -48,7 +40,7 @@ required_evidence:
 
 ### 步骤 1: 检查工作区状态
 
-1. 读取 `.soloforge/config.yaml` 获取项目配置
+1. 通过 `resolveProjectConfig()` 恢复项目配置（优先读取 intent.yaml，回退到项目文件探测）
 2. 检查 `tasks/` 目录中是否存在未完成的任务
 3. 检查 git 工作区是否有未提交的变更
 

package/templates/procedures//345/205/250/347/224/237/345/221/275/345/221/250/346/234/237/345/267/245/344/275/234/346/265/201/345/257/274/350/210/252.md

@@ -1,27 +1,16 @@
 ---
 name: full-lifecycle-navigation
 type: procedure
-when: '下一步, 继续, 现在能写代码吗, 工作流导航, navigation, 阶段判断, 工作包生成'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-全生命周期工作流导航
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-workflow-navigation-contract
-primary_triggers:
-  - 全生命周期工作流导航
-secondary_triggers:
-  - 下一步
-  - 继续
-  - 现在能写代码吗
-  - 阶段导航
-negative_triggers: []
 priority: P0
-specificity: 5
 consumes:
   - mc-workflow-navigation-contract
   - current_task_context
@@ -38,6 +27,7 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["需求分析", "架构设计", "详细设计", "任务规划", "编码与单元测试", "代码审查", "联调验证"]
+triggers: ["下一步","继续","现在能写代码吗","工作流导航","navigation","阶段判断","工作包生成"]
 ---
 
 # 全生命周期工作流导航
@@ -48,9 +38,9 @@ stages: ["需求分析", "架构设计", "详细设计", "任务规划", "编码
 
 | 阶段 | 判断条件 | 下一步 |
 |------|----------|--------|
-| 未初始化 | .soloforge/ 不存在或无 config.yaml | 运行 soloforge init |
-| 配置待确认 | config.yaml 存在但字段未确认 | 先区分自动修复项和业务确认项；机械类型/evidence 问题运行 soloforge config repair，业务口径再运行 soloforge config confirm |
-| 知识就绪 | 配置已确认、知识库已索引 | 提交开发意图开始新任务 |
+| 未初始化 | .soloforge/ 不存在或无 intent.yaml | 运行 soloforge init |
+| 配置不完整 | resolveConfig 返回 missing 字段 | 通过 `soloforge config set` 或 `sf_config_update` 补充不可探测偏好（产品类型、交付设置等）；技术栈和构建命令由项目文件自动探测 |
+| 知识就绪 | 配置完整（tech_stack + build_commands 已就绪）、知识库已索引 | 提交开发意图开始新任务 |
 | 设计进行中 | 设计产物存在但未通过审计 | 完成设计并通过审计 |
 | 实现就绪 | 设计产物已通过审计 | 制定开发切片计划 |
 | 开发进行中 | 有任务在编码/验证阶段 | 继续编码和验证 |
@@ -67,8 +57,9 @@ stages: ["需求分析", "架构设计", "详细设计", "任务规划", "编码
 ## 导航决策流程
 
 1. 调用 `sf_navigation` 或 `soloforge next` 获取当前状态
-2. 检查是否有陈旧任务需要处理
-3. 读取 `confirmation_decisions`
+2. 检查配置完整性：resolveConfig 返回 missing 时，优先补充不可探测字段
+3. 检查是否有陈旧任务需要处理
+4. 读取 `confirmation_decisions`
    - `must_confirm` 非空时，先让用户选择，不得继续执行会被阻断的动作
    - `should_confirm` 非空时，明确说明建议确认的收益，但允许继续只读或低风险准备
    - `auto_resolvable` 非空时，按推荐命令修复或复验，不把它伪装成业务确认
@@ -100,6 +91,7 @@ stages: ["需求分析", "架构设计", "详细设计", "任务规划", "编码
 当 Edit、Write、Bash 或 MCP 工具被 SoloForge 阻断时：
 
 - 先读取阻断输出中的 `recovery_command`、`template_path` 和 `confirmation_decisions`
+- 配置不完整时，按 `soloforge config set` 补充缺失字段后重试
 - 自动修复项按命令修复后重试对应工具
 - 业务确认项列出具体必须确认内容后等待用户确认
 - 不得取消任务后直接写代码

package/templates/procedures//345/212/237/350/203/275/345/274/200/345/217/221/346/265/201/347/250/213.md

@@ -1,23 +1,16 @@
 ---
 name: feature-development
 type: procedure
-when: '新功能开发, 需求实现, feature, 新增功能, 需求开发, 功能实现, 新建功能'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-功能开发流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-task-context-lifecycle
-primary_triggers:
-  - 功能开发流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-task-context-lifecycle
 emits:
@@ -25,9 +18,10 @@ emits:
   - api_contract_alignment
 required_evidence:
   - execution_evidence
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["新功能开发","需求实现","feature","新增功能","需求开发","功能实现","新建功能"]
 ---
 
 ## 适用场景
@@ -38,13 +32,13 @@ stages: ["编码与单元测试", "联调验证"]
 2. 技术方案设计：确定接口契约（API 定义）、数据模型、技术选型
 3. 自主技术选型（若涉及架构级选型）：调用 sf_explore 检索行业基准 → 四维矩阵 → 证伪循环 → A/B 决策诱导 → 等待人类选择
 4. 前后端对齐：API 文档/接口契约评审，确认字段和状态流转
-4. 后端开发：按 crud-operation / api-pagination 等模式实现，先写接口再写逻辑
-5. 前端开发：按 react-component / react-api-integration 等模式实现页面和接口对接
-6. 单元测试：Service 层核心逻辑 + 前端关键组件
-7. 联调测试：前后端联调，验证完整流程
-8. 代码审查：使用 sf_review 检查质量/安全/性能
-9. 提测：部署到测试环境，执行验收标准
-10. 修复反馈问题后准备发布
+5. 后端开发：按 crud-operation / api-pagination 等模式实现，先写接口再写逻辑
+6. 前端开发：按 react-component / react-api-integration 等模式实现页面和接口对接
+7. **切片验证**：运行当前切片的单元测试 → 检查覆盖率（≥9 场景）→ 确认变更在涉及文件范围内 → 更新切片测试状态（pending→red→green→refactored）
+8. 联调测试：前后端联调，验证完整流程
+9. 代码审查：使用 sf_review 检查质量/安全/性能
+10. 提测：部署到测试环境，执行验收标准
+11. 修复反馈问题后准备发布
 
 ## 检查点
 - [ ] API 接口契约已对齐并文档化
@@ -53,6 +47,7 @@ stages: ["编码与单元测试", "联调验证"]
 - [ ] 前后端联调通过
 - [ ] 涉及技术选型时已通过 sf_explore 完成行业基准对齐
 - [ ] 交付物末尾已签署终局宣言
+- [ ] 切片验证点已执行（步骤 7）
 
 ## 注意事项
 - 接口契约先于实现（避免前端等后端）

package/templates/procedures//345/220/216/347/253/257/346/216/245/345/217/243/345/256/236/347/216/260/345/267/245/344/275/234/346/265/201.md

@@ -1,23 +1,15 @@
 ---
 name: backend-api-implementation
 type: procedure
-when: '后端接口, Controller, DTO, API实现, 数据写入'
 scope:
   - backend
 products:
   - '*'
 id: ka-procedure-后端接口实现工作流
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-backend-implementation-contract
-primary_triggers:
-  - 后端接口实现工作流
-secondary_triggers:
-  - REST API
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-backend-implementation-contract
 emits:
@@ -28,6 +20,7 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["编码与单元测试"]
+triggers: ["后端接口","Controller","DTO","API实现","数据写入"]
 ---
 
 ## 步骤

package/templates/procedures//345/221/275/344/273/244/346/211/247/350/241/214/346/265/201/347/250/213.md

@@ -5,16 +5,10 @@ scope:
 products:
   - '*'
 id: ka-procedure-命令执行流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-command-execution
-primary_triggers:
-  - 命令执行流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-tool-invocation-contract
 emits:
@@ -26,9 +20,10 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 type: procedure
-when: 命令执行流程
 stages: ["任务规划", "编码与单元测试"]
+triggers: ["命令执行流程"]
 ---
+
 # 命令执行流程
 
 ## 步骤

package/templates/procedures//345/221/275/344/273/244/350/267/257/347/224/261/346/265/201/347/250/213.md

@@ -6,16 +6,10 @@ products:
   - '*'
 id: ka-procedure-命令路由流程
 type: procedure
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-command-router
-primary_triggers:
-  - 命令路由流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 stages: ["任务规划", "编码与单元测试"]
 version: 1.0.0
 last_reviewed: '2026-06-02'

package/templates/procedures//345/256/211/345/205/250/345/212/240/345/233/272/346/265/201/346/260/264/347/272/277.md

@@ -1,23 +1,16 @@
 ---
 name: security-hardening-pipeline
 type: pipeline_procedure
-when: '安全加固, 安全审计, 安全修复, 漏洞修复, 合规整改, 安全检查, 安全增强'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-安全加固流水线
-asset_kind: pipeline_procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-privacy-boundary
-primary_triggers:
-  - 安全加固流水线
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-privacy-boundary
 emits:
@@ -29,29 +22,30 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["安全加固","安全审计","安全修复","漏洞修复","合规整改","安全检查","安全增强"]
 ---
 
 # 安全加固管线
 
-### 第1步：安全审计
+## 第1步：安全审计
 扫描现有代码和配置的安全漏洞（OWASP Top 10 维度）。检查认证授权机制的完整性。检查数据加密和脱敏策略。检查第三方依赖的已知漏洞。
 模版：安全审计模版.md
 产出保存到：.soloforge/output/01-安全审计.md
 工具：sf_command, sf_analyze
 
-### 第2步：方案设计
+## 第2步：方案设计
 按风险等级（Critical/High/Medium/Low）排序修复优先级。针对每个漏洞设计修复方案。评估修复对现有功能的影响。确定合规要求（数据加密/审计日志/访问控制）。
 产出保存到：.soloforge/output/02-修复方案.md
 
-### 第3步：安全修复
+## 第3步：安全修复
 按优先级逐个修复安全漏洞。每个修复后回归验证功能无影响。禁止降级安全等级来通过测试。
 工具：sf_stage_execute
 
-### 第4步：验证验收
+## 第4步：验证验收
 重新扫描确认漏洞已修复。代码审查专注安全维度。学习记录（漏洞类型、修复模式、预防规则）。
 工具：sf_gate_check, sf_review, sf_stage_advance
 
-### 第5步：深度安全扫描
+## 第5步：深度安全扫描
 运行依赖漏洞扫描（npm audit / OWASP Dependency-Check），高危漏洞阻断构建。运行容器镜像扫描（Trivy / Snyk），检测基础镜像已知漏洞。检查生产环境配置（禁用 debug 模式、关闭 actuator 暴露端点、验证 HTTPS 强制）。
 
 ## 检查点

package/templates/procedures//345/267/245/345/205/267/350/260/203/347/224/250/346/265/201/347/250/213.md

@@ -5,16 +5,10 @@ scope:
 products:
   - '*'
 id: ka-procedure-工具调用流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-tool-invocation-contract
-primary_triggers:
-  - 工具调用流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-workflow-contract
 emits:
@@ -26,9 +20,10 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 type: procedure
-when: 工具调用流程
 stages: ["任务规划", "编码与单元测试"]
+triggers: ["工具调用流程"]
 ---
+
 # 工具调用流程
 
 ## 步骤

package/templates/procedures//346/200/247/350/203/275/346/265/201/346/260/264/347/272/277.md

@@ -1,23 +1,16 @@
 ---
 name: performance-pipeline
 type: pipeline_procedure
-when: '性能优化, 慢查询, 内存泄漏, 首屏优化, 性能问题, 响应慢, 超时优化, 性能调优'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-性能流水线
-asset_kind: pipeline_procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-metric-governance
-primary_triggers:
-  - 性能流水线
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-metric-governance
 emits:
@@ -29,24 +22,25 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["性能优化","慢查询","内存泄漏","首屏优化","性能问题","响应慢","超时优化","性能调优"]
 ---
 
 # 性能优化管线
 
-### 第1步：性能定位
+## 第1步：性能定位
 量化性能指标（当前值/目标值）。定位瓶颈（慢查询/内存/CPU/网络/前端渲染）。收集证据（APM/慢查询日志/浏览器 DevTools/压测数据）。确定优化优先级（收益/成本排序）。
 模版：性能分析模版.md
 产出保存到：.soloforge/output/01-性能分析.md
 工具：sf_command, sf_analyze
 
-### 第2步：方案设计
+## 第2步：方案设计
 针对瓶颈设计优化方案（索引优化/SQL 重写/缓存/连接池/异步/分页/懒加载）。评估方案影响范围和风险。确定可衡量的优化目标。
 产出保存到：.soloforge/output/02-优化方案.md
 
-### 第3步：优化实施
+## 第3步：优化实施
 按优先级逐步实施，每步优化后重新测量性能指标。禁止一次改多处再测量。保持优化前后功能行为一致。
 工具：sf_stage_execute
 
-### 第4步：效果验证
+## 第4步：效果验证
 对比优化前后的性能指标。全量测试确认无功能回归。代码审查关注：优化是否引入新问题、缓存一致性、并发安全。
 工具：sf_gate_check, sf_review, sf_stage_advance

package/templates/procedures//346/204/217/345/233/276/350/267/257/347/224/261/346/265/201/347/250/213.md

@@ -1,22 +1,16 @@
 ---
 deprecated: true
-deprecated_note: 此模板已由 mc-command-router (命令路由) 替代。保留仅为向后兼容。
+deprecated_note: 此模版已由 mc-command-router (命令路由) 替代。保留仅为向后兼容。
 name: intent-routing-workflow
 scope:
   - '*'
 products:
   - '*'
 id: ka-procedure-意图路由流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-command-router
-primary_triggers:
-  - 意图路由流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-classifier
 emits:
@@ -27,9 +21,10 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 type: procedure
-when: 意图路由流程
 stages: ["任务规划", "编码与单元测试"]
+triggers: ["意图路由流程"]
 ---
+
 # 意图路由流程
 
 ## 步骤

package/templates/procedures//346/216/245/345/217/243/351/233/206/346/210/220/346/265/201/346/260/264/347/272/277.md

@@ -1,23 +1,16 @@
 ---
 name: api-integration-pipeline
 type: pipeline_procedure
-when: '第三方接口对接, 外部服务集成, API集成, 接口联调, 服务对接, 第三方API'
 scope:
   - backend
   - frontend
 products:
   - '*'
 id: ka-procedure-接口集成流水线
-asset_kind: pipeline_procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-artifact-contract
-primary_triggers:
-  - 接口集成流水线
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-artifact-contract
 emits:
@@ -26,33 +19,40 @@ emits:
   - integration_test_result
 required_evidence:
   - execution_evidence
-version: 1.1.0
-last_reviewed: '2026-06-01'
+version: 1.2.0
+last_reviewed: '2026-06-04'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["第三方接口对接","外部服务集成","API集成","接口联调","服务对接","第三方API"]
 ---
 
 # 接口对接管线
 
-### 第1步：契约分析
+## 第1步：契约分析
 梳理第三方 API 能力清单（认证方式、请求/响应格式、错误码、限流配额、沙箱环境）。识别核心交互场景和数据映射关系。
 模版：接口对接方案模版.md
 产出保存到：.soloforge/output/01-接口对接方案.md
 工具：sf_command
 
-### 第2步：适配层实现
+## 第2步：适配层实现
 实现统一的 API 客户端封装（超时、重试、熔断、日志）。定义请求/响应 DTO 映射。配置 Mock 方案（沙箱/本地 Mock）支持独立开发。错误码映射为业务异常。
 工具：sf_stage_execute, sf_scaffold
 
-### 第3步：联调测试
+## 第3步：联调测试
 使用 Mock 环境验证基本流程。切换到沙箱环境验证真实交互。覆盖：正常流程、网络超时、服务端错误、限流响应、数据格式异常。
 模版：测试计划模版.md
 工具：sf_gate_check
 
-### 第4步：验收上线
+## 第3a步：沙箱→生产差异记录
+
+| 差异项 | 沙箱行为 | 生产预期 | 风险评估 | 验证计划 |
+|--------|---------|---------|---------|---------|
+| | | | | |
+
+## 第4步：验收上线
 代码审查重点：超时配置、错误处理、敏感信息、日志脱敏。生产配置确认（URL、密钥、限流参数）。监控告警配置（调用成功率、响应时间）。
 工具：sf_review, sf_gate_check, sf_stage_advance
 
-### 第5步：契约管理与监控增强
+## 第5步：契约管理与监控增强
 定义接口契约（OpenAPI/Swagger），明确请求/响应格式、错误码、版本号。编写接口 Mock 服务，前后端并行开发。接口变更必须更新文档并通知消费方，给予充足迁移时间。集成测试覆盖正常流 + 异常流（超时、错误响应、边界值）。接口上线后配置监控告警（响应时间 P99、错误率、调用量）。
 
 ## 检查点

package/templates/procedures//346/225/260/346/215/256/345/272/223/350/277/201/347/247/273/346/265/201/347/250/213.md

@@ -1,22 +1,15 @@
 ---
 name: database-migration
 type: procedure
-when: '数据库变更, 表结构修改, migration, DDL, 加字段, 建表, 索引, 数据迁移, 表结构变更'
 scope:
   - backend
 products:
   - '*'
 id: ka-procedure-数据库迁移流程
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
 owner_mechanism_id: mc-knowledge-asset-governance
-primary_triggers:
-  - 数据库迁移流程
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-knowledge-asset-governance
 emits:
@@ -28,6 +21,7 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["编码与单元测试", "联调验证"]
+triggers: ["数据库变更","表结构修改","migration","DDL","加字段","建表","索引","数据迁移","表结构变更"]
 ---
 
 ## 适用场景

package/templates/procedures//346/234/254/345/234/260/346/265/217/350/247/210/345/231/250/351/252/214/346/224/266/345/267/245/344/275/234/346/265/201.md

@@ -1,7 +1,6 @@
 ---
 name: local-browser-acceptance-workflow
 type: procedure
-when: '本地验收, 浏览器验收, Docker 验收, 本地测试, local acceptance, browser test, docker compose'
 scope:
   - backend
   - frontend
@@ -36,15 +35,9 @@ acceptance_checks:
   - FinalLocalReviewAccess 包含 frontend_urls/backend_urls/docs_or_swagger_urls
   - validateFinalAccess passed
 id: ka-procedure-本地浏览器验收工作流
-asset_kind: procedure
 lifecycle_status: active
 authority: supporting
-primary_triggers:
-  - 本地浏览器验收工作流
-secondary_triggers: []
-negative_triggers: []
 priority: P1
-specificity: 5
 consumes:
   - mc-local-acceptance
 emits:
@@ -56,6 +49,7 @@ required_evidence:
 version: 1.1.0
 last_reviewed: '2026-06-01'
 stages: ["联调验证"]
+triggers: ["本地验收","浏览器验收","Docker 验收","本地测试","local acceptance","browser test","docker compose"]
 ---
 
 ## 适用场景