@siming-org/cli 0.6.2 → 0.6.3

package/dist/index.js

@@ -4751,7 +4751,7 @@ async function fetchManifest(pkgSpec, registry) {
       { maxBuffer: 16 * 1024 * 1024 }
     );
     const packInfo = JSON.parse(stdout);
-    const filename = packInfo[0]?.filename;
+    const filename = (Array.isArray(packInfo) ? packInfo[0] : Object.values(packInfo ?? {})[0])?.filename;
     if (filename === void 0) {
       cleanup();
       return fail({

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@siming-org/cli",
-  "version": "0.6.2",
+  "version": "0.6.3",
   "license": "MIT",
   "author": "Wuchao",
   "engines": {
@@ -27,8 +27,8 @@
     "picocolors": "^1.1.1",
     "yaml": "^2.6.0",
     "zod": "^4.4.3",
-    "@siming-org/core": "0.6.2",
-    "@siming-org/server": "0.6.2"
+    "@siming-org/core": "0.6.3",
+    "@siming-org/server": "0.6.3"
   },
   "devDependencies": {
     "tsup": "^8.3.5",

package/templates/builtin/full_workflow.bundle.json

@@ -1,6 +1,6 @@
 {
   "exportFormatVersion": "1.0",
-  "exportedAt": "2026-09-09T15:57:17.939Z",
+  "exportedAt": "2026-09-10T09:29:55.505Z",
   "warnings": [],
   "template": {
     "name": "full_workflow",
@@ -49,7 +49,7 @@
         "label": "技术方案",
         "phase": "entry",
         "track": "all",
-        "prompt": "# 技术方案\n\n## 节点职责\n\n将已确认的产品需求转化为可直接指导实现和验证的技术方案，并通过需求对齐审查、架构评审和用户确认建立实现基线。本节点只产出设计，不编写生产代码或测试代码。\n\n## 依赖信息\n\n检查当前任务上下文、需求与验收标准、非目标、PRD、前序节点产物、项目提示词和相关架构资料；已有信息直接复用，缺失时再加载。\n\n按名称加载：\n\n- `tech-design` Skill：技术方案设计方法及文档模板；\n- `workflow-discipline` Skill：执行、审查和暂停点纪律。\n\n方案完成后，依次调用：\n\n1. `alignment-reviewer` Agent：检查方案与需求的对齐关系；\n2. `arch-reviewer` Agent：检查方案的架构质量。\n\n## 正向执行流程\n\n1. 确认需求范围和后端、前端或混合轨道，并读取相关项目约束与现有架构。\n2. 使用 `tech-design` Skill 设计方案，并读取其 `references/template.md` 生成技术方案文档。\n3. 项目有文档目录时按项目声明保存方案文件；登记任务产物时必须携带方案全文（`record-artifact-add` 用 `file` 或 `content`），纯路径引用仅用于超过 200k 字符快照上限的文件，且须说明理由。\n4. 调用 `alignment-reviewer`。存在需求偏差时先修订方案，直至总体 `PASS`。\n5. 调用 `arch-reviewer`。处理 BLOCKER 和 HIGH；MEDIUM、LOW 逐项修订或记录保留理由，直至总体 `PASS`。\n6. 向用户呈现方案摘要、关键取舍、两道审查结论和即将进入的实现轨道。\n7. 用户明确确认并记录原文后，通过暂停点进入实现阶段，并按项目分支规则创建任务分支。\n\n## 产出检查\n\n推进前确认：\n\n- 技术方案全文可读取、已保存，登记值携带全文（超限时为路径引用且已说明理由）；\n- 文档符合 `tech-design` 模板使用规则，最低必备信息完整；\n- 需求、验收标准和非目标均有对应设计；\n- 按需设计已完成，或在“不适用项”中写明具体对象和理由；\n- `alignment-reviewer` 总体为 `PASS`；\n- `arch-reviewer` 总体为 `PASS`，其余 Finding 已处理或记录保留理由；\n- 用户已明确确认当前方案，确认原文已经记录。\n\n## 任务差异处理\n\n没有独立 PRD 时，以任务需求、验收标准和非目标作为对齐基线。\n\n方案出现需要用户决定的产品方向、破坏性变更、新依赖或重大架构取舍时，先呈现选项、影响和建议。\n\n任一道审查处于 `BLOCKED` 或 `FAIL`，项目约束与方案无法同时满足，或用户尚未确认时，保留在本节点继续处理。\n\n## 节点记录与推进\n\n记录技术方案产物、方案摘要、关键决策与取舍、完成检查、两道审查的结论与轮次、Finding 处理结果、不适用项及理由，以及用户确认原文。\n\n全部产出检查满足后再推进；创建任务分支后，记录任务与分支的关联。",
+        "prompt": "# 技术方案\n\n## 节点职责\n\n将已确认的产品需求转化为可直接指导实现和验证的技术方案，并通过需求对齐审查、架构评审和用户确认建立实现基线。本节点只产出设计，不编写生产代码或测试代码。\n\n## 依赖信息\n\n检查当前任务上下文、需求与验收标准、非目标、PRD、前序节点产物、项目提示词和相关架构资料；已有信息直接复用，缺失时再加载。\n\n按名称加载：\n\n- `tech-design` Skill：技术方案设计方法及文档模板；\n- `workflow-discipline` Skill：执行、审查和暂停点纪律。\n\n方案完成后，依次调用：\n\n1. `alignment-reviewer` Agent：检查方案与需求的对齐关系；\n2. `arch-reviewer` Agent：检查方案的架构质量。\n\n## 正向执行流程\n\n1. 确认需求范围和后端、前端或混合轨道，并读取相关项目约束与现有架构。\n2. 使用 `tech-design` Skill 设计方案，并读取其 `references/template.md` 生成技术方案文档；方案默认包含架构图与核心功能流程图——用可渲染的图形语法表达（项目未约定时用 Mermaid），不使用文字罗列代替，且图中模块、步骤、分支在正文均有对应说明。\n3. 项目有文档目录时按项目声明保存方案文件；登记任务产物时必须携带方案全文（`record-artifact-add` 用 `file` 或 `content`），纯路径引用仅用于超过 200k 字符快照上限的文件，且须说明理由。\n4. 调用 `alignment-reviewer`。存在需求偏差时先修订方案，直至总体 `PASS`。\n5. 调用 `arch-reviewer`。处理 BLOCKER 和 HIGH；MEDIUM、LOW 逐项修订或记录保留理由，直至总体 `PASS`。\n6. 向用户呈现已保存的方案文档及其可读位置，以及方案摘要、关键取舍、两道审查结论和即将进入的实现轨道——用户在确认前必须能打开完整方案。\n7. 用户明确确认并记录原文后，通过暂停点进入实现阶段，并按项目分支规则创建任务分支。\n\n## 产出检查\n\n推进前确认：\n\n- 技术方案全文可读取、已保存，登记值携带全文（超限时为路径引用且已说明理由）；\n- 文档符合 `tech-design` 模板使用规则，最低必备信息完整；\n- 方案默认包含架构图与核心功能流程图，以可渲染的图形呈现且与正文一致；确实不适用时已在“不适用项”写明具体对象和理由；\n- 需求、验收标准和非目标均有对应设计；\n- 按需设计已完成，或在“不适用项”中写明具体对象和理由；\n- `alignment-reviewer` 总体为 `PASS`；\n- `arch-reviewer` 总体为 `PASS`，其余 Finding 已处理或记录保留理由；\n- 用户已明确确认当前方案，确认原文已经记录；\n- 呈现给用户的方案文档可独立打开阅读，且与当前方案版本一致。\n\n## 任务差异处理\n\n没有独立 PRD 时，以任务需求、验收标准和非目标作为对齐基线。\n\n方案出现需要用户决定的产品方向、破坏性变更、新依赖或重大架构取舍时，先呈现选项、影响和建议。\n\n任一道审查处于 `BLOCKED` 或 `FAIL`，项目约束与方案无法同时满足，或用户尚未确认时，保留在本节点继续处理。\n\n## 节点记录与推进\n\n记录技术方案产物、方案摘要、关键决策与取舍、完成检查、两道审查的结论与轮次、Finding 处理结果、不适用项及理由，以及用户确认原文。\n\n全部产出检查满足后再推进；创建任务分支后，记录任务与分支的关联。",
         "skills": [
           "tech-design",
           "workflow-discipline"
@@ -60,8 +60,8 @@
         ],
         "sourcePreset": {
           "code": "design-tech",
-          "version": "1.4.0",
-          "contentHash": "a1dd3ef23dad18b3",
+          "version": "1.5.0",
+          "contentHash": "3366c9c3336fbc9f",
           "agents": [
             "alignment-reviewer",
             "arch-reviewer"
@@ -204,7 +204,7 @@
         "label": "端到端测试开发",
         "phase": "test",
         "track": "backend",
-        "prompt": "# 端到端测试开发\n\n## 节点职责\n\n依据已确认的 E2E 设计实现并验证跨真实系统边界的测试场景；设计结论为 N/A 时复核依据并记录结果。测试代码和必要的生产代码修复由当前执行者完成；测试命令交给独立 `test-executor` 执行，最终代码交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、技术方案、生产代码、E2E 设计、单元测试结果、前序决策，以及项目和所属模块的测试约束。加载 `coding-standards`、`workflow-discipline`；测试失败且根因不明确时，再加载 `bugfix-root-cause-verification`。调用 `test-executor` 执行测试，调用 `code-reviewer` 审查代码变更。\n\n读取项目的 E2E 目录、配置、执行入口、邻近用例和环境规则。缺少关键信息时先从仓库现状补齐，不擅自引入项目未定义的测试体系。\n\n## 执行流程\n\n1. 读取 E2E 适用性结论并建立“设计场景 → 测试实现或已有用例”的逐项映射。\n2. 设计结论为 N/A 时，复核项目仍未定义适用的 E2E 体系；依据成立则记录 N/A，发现依据不成立则返回设计范围判断，不直接越过设计补写测试。\n3. 适用时，按项目现有框架和唯一执行入口实现测试，落实前置条件、操作步骤、观察点、预期结果、数据隔离和清理。测试必须经过项目定义的真实边界，并验证最终可观察结果。\n4. 完成一个场景或紧密相关的一组场景后，将明确的命令、范围和通过标准交给 `test-executor` 执行。\n5. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按需加载 `bugfix-root-cause-verification`，确认根因后再修改测试、生产代码或环境。\n6. 修复后重新执行原失败场景及受影响回归。不得通过删除有效测试、skip/only、绕开真实边界、缩小应执行范围、放宽正确断言、吞异常或硬编码结果制造通过。\n7. 全部场景实现后，根据测试和生产代码改动确定 E2E 回归范围；无法可靠判断时扩大到项目 E2E 全量。生产代码发生修复时，同时确定并执行受影响的低层测试。\n8. 检查设计映射、测试删除、skip/only、断言有效性、真实边界、数据隔离、清理和环境可重复性。\n9. 将需求、E2E 设计、项目约束和全部代码变更位置交给 `code-reviewer`，不提供实现者结论或预期结果。修复 BLOCKER、HIGH Findings 后重新执行受影响测试并复审，直至测试通过且评审为 PASS；MEDIUM、LOW 逐项处理或记录保留理由。\n\n## 产出与检查\n\n推进前确认：\n\n- N/A 结论已有复核证据，或每个适用设计场景都有对应实现或明确的已有测试；\n- 测试遵循项目现有 E2E 体系并经过真实系统边界；\n- 观察点、数据隔离、清理和环境准备符合项目约束；\n- 所有失败均在根因明确后修复，没有制造假绿；\n- `test-executor` 报告适用 E2E 和必要的低层回归全部通过，失败为 0，未授权跳过为 0；\n- 完整性检查通过，日志和报告可追溯；\n- `code-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明；\n- 测试代码、必要的生产修复和执行报告已形成可引用产物。\n\n## 任务差异处理\n\n项目没有适用的 E2E 体系时不新建框架、目录或执行入口。根据项目能力和设计范围选择测试、环境和回归方式，不套用固定浏览器、协议、命令或覆盖指标。失败修复涉及破坏性契约、新依赖或真实范围扩张时先说明影响并暂停；同一问题多轮仍不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将 E2E 适用性复核、设计到实现的映射、测试代码变更、真实边界、数据与清理、实际执行命令和范围、通过/失败/跳过统计、低层回归、日志与报告引用、根因和修复、完整性结论、`code-reviewer` 结论与 Findings 处理情况写入当前节点记录。完成上述检查后推进下一节点。",
+        "prompt": "# 端到端测试开发\n\n## 节点职责\n\n依据已确认的 E2E 设计实现并验证跨真实系统边界的测试场景；设计结论为 N/A 时复核依据并记录结果。测试代码和必要的生产代码修复由当前执行者完成；测试命令交给独立 `test-executor` 执行，最终代码交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、技术方案、生产代码、E2E 设计、单元测试结果、前序决策，以及项目和所属模块的测试约束。加载 `coding-standards`、`workflow-discipline`；测试失败且根因不明确时，再加载 `bugfix-root-cause-verification`。调用 `test-executor` 执行测试，调用 `code-reviewer` 审查代码变更。\n\n读取项目的 E2E 目录、配置、执行入口、邻近用例和环境规则。缺少关键信息时先从仓库现状补齐，不擅自引入项目未定义的测试体系。\n\n## 执行流程\n\n1. 读取 E2E 适用性结论并建立“设计场景 → 测试实现或已有用例”的逐项映射。\n2. 设计结论为 N/A 时，复核项目仍未定义适用的 E2E 体系；依据成立则记录 N/A，发现依据不成立则返回设计范围判断，不直接越过设计补写测试。\n3. 适用时，按项目现有框架和唯一执行入口实现测试，落实前置条件、操作步骤、观察点、预期结果、数据隔离和清理。测试必须经过项目定义的真实边界，并验证最终可观察结果。\n4. 完成一个场景或紧密相关的一组场景后，将明确的命令、范围和通过标准交给 `test-executor` 执行。\n5. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按需加载 `bugfix-root-cause-verification`，确认根因后再修改测试、生产代码或环境。\n6. 修复后重新执行原失败场景及受影响回归。不得通过删除有效测试、skip/only、绕开真实边界、缩小应执行范围、放宽正确断言、吞异常或硬编码结果制造通过。\n7. 全部场景实现后，以证据链确定 E2E 回归范围：列出本节点的测试与生产代码变更，映射到受影响场景（同一入口、同一链路、共享前置数据的用例），逐项给出执行或排除的依据。E2E 全量是须举证的主动决策而非兜底——仅当证据表明改动横切多个入口或共享基础设施时执行；未完成受影响分析就宣称无法判断、或以「保险起见」直接全量，均判定为范围决策失败。生产代码发生修复时，同样按证据链确定并执行受影响的低层测试。\n8. 检查设计映射、测试删除、skip/only、断言有效性、真实边界、数据隔离、清理和环境可重复性。\n9. 将需求、E2E 设计、项目约束和全部代码变更位置交给 `code-reviewer`，不提供实现者结论或预期结果。修复 BLOCKER、HIGH Findings 后重新执行受影响测试并复审，直至测试通过且评审为 PASS；MEDIUM、LOW 逐项处理或记录保留理由。\n\n## 产出与检查\n\n推进前确认：\n\n- N/A 结论已有复核证据，或每个适用设计场景都有对应实现或明确的已有测试；\n- 测试遵循项目现有 E2E 体系并经过真实系统边界；\n- 观察点、数据隔离、清理和环境准备符合项目约束；\n- 所有失败均在根因明确后修复，没有制造假绿；\n- `test-executor` 报告适用 E2E 和必要的低层回归全部通过，失败为 0，未授权跳过为 0；\n- 完整性检查通过，日志和报告可追溯；\n- `code-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明；\n- 测试代码、必要的生产修复和执行报告已形成可引用产物。\n\n## 任务差异处理\n\n项目没有适用的 E2E 体系时不新建框架、目录或执行入口。根据项目能力和设计范围选择测试、环境和回归方式，不套用固定浏览器、协议、命令或覆盖指标。失败修复涉及破坏性契约、新依赖或真实范围扩张时先说明影响并暂停；同一问题多轮仍不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将 E2E 适用性复核、设计到实现的映射、测试代码变更、真实边界、数据与清理、实际执行命令、范围及判断依据、通过/失败/跳过统计、低层回归、日志与报告引用、根因和修复、完整性结论、`code-reviewer` 结论与 Findings 处理情况写入当前节点记录。完成上述检查后推进下一节点。",
         "skills": [
           "coding-standards",
           "workflow-discipline"
@@ -215,8 +215,8 @@
         ],
         "sourcePreset": {
           "code": "test-e2e-implement",
-          "version": "1.3.0",
-          "contentHash": "55d0e8c282c8eb61",
+          "version": "1.3.1",
+          "contentHash": "4c0b71a785fe001a",
           "agents": [
             "test-executor",
             "code-reviewer"
@@ -228,7 +228,7 @@
         "label": "集成验证",
         "phase": "test",
         "track": "all",
-        "prompt": "# 集成验证\n\n## 节点职责\n\n将远程主线最新状态整合到任务分支，并在最终集成态执行适用回归，形成绑定明确版本的验证结论。版本控制与范围判断由当前执行者负责，测试命令交给独立 `test-executor` 执行；若产生代码修复，再交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、技术方案、实现与测试记录、`align-branch` 的基础分支与合并记录，以及项目的分支策略、测试体系和所属模块提示词。加载 `workflow-discipline`，调用 `test-executor` 执行回归；发生代码修复时调用 `code-reviewer`。测试失败且根因不明确时，再加载 `bugfix-root-cause-verification`。\n\n优先使用 `align-branch` 已记录的基础分支；记录缺失时，按与该节点相同的规则从任务上下文或项目提示词解析，例如 `main`、`master` 或 `dev`。仍无法解析时询问用户是否需要合并某个分支的远程代码，不根据版本历史猜测基础分支。\n\n## 执行流程\n\n1. 获取远程状态，优先读取 `align-branch` 记录的基础分支；记录缺失时从任务上下文或项目提示词解析，仍无法解析则询问用户。记录当前任务版本、基础分支、远程版本及判断依据。\n2. 用户明确表示无需合并时记录该决定；否则按项目策略整合基础分支的远程最新代码。发生冲突时理解双方意图后逐项融合并验证结果，不盲目选择任一侧；无法可靠解决时说明冲突与缺失决策并暂停。\n3. 汇总任务改动和主线整合改动，读取项目测试目录、配置、脚本与现有用例，列出适用的测试层级和执行入口；项目未定义的层级记录 N/A。\n4. 根据代码差异、模块依赖和测试映射确定回归范围。无法可靠判断某一层级的受影响范围时，将该层级扩大到全量。\n5. 将明确的命令、顺序、范围和通过标准交给 `test-executor` 执行，依据事实报告核对各层级统计、失败、跳过和日志。\n6. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按需加载 `bugfix-root-cause-verification`，确认根因后再修改代码、测试或环境。\n7. 每次修复后重新执行原失败范围和受影响回归。不得通过删除有效测试、skip/only、缩小应执行范围、放宽正确断言、吞异常或硬编码结果制造通过。\n8. 检查新增 skip/only、测试删除、未执行的适用层级、范围遗漏和统计对账。发生代码修复时，将客观约束与变更位置交给 `code-reviewer`；修复 BLOCKER、HIGH Findings 后重跑受影响测试并复审，直至测试通过且评审为 PASS。\n9. 记录最终同步状态、实际回归范围、测试结果和已验证的提交或等价版本标识，确保后续能够判断证据是否仍有效。\n\n## 产出与检查\n\n推进前确认：\n\n- 基础分支沿用 `align-branch` 记录，或已按相同规则重新解析并留痕；\n- 基础分支的远程状态已获取并完成整合，或用户已明确表示无需合并；\n- 所有冲突均已理解并正确融合；\n- 项目适用测试层级与执行入口已识别，N/A 有具体依据；\n- 回归范围有代码差异、依赖或测试映射依据，无法判断的层级已扩大到全量；\n- `test-executor` 报告所有适用回归通过，失败为 0，未授权跳过为 0；\n- 所有失败均在根因明确后修复，没有制造假绿；\n- 发生代码修复时，`code-reviewer` 最终结论为 PASS；\n- 集成结论绑定明确版本，日志和报告可追溯。\n\n## 任务差异处理\n\n基础分支没有新提交时无需制造合并提交，但回归验证仍须执行。用户明确表示无需合并时保留决定并继续验证当前版本。根据项目实际体系选择测试层级和命令，不擅自引入未定义的测试类型。远程状态不可获取、冲突无法可靠解决，或修复涉及破坏性契约、新依赖和真实范围扩张时，说明证据与影响并暂停；同一问题多轮不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将基础分支来源、同步策略与结果、任务和远程版本、冲突处理、适用测试层级、回归范围及依据、实际命令与统计、失败根因和修复、完整性检查、代码评审结果、日志与报告引用、最终已验证版本写入当前节点记录。完成上述检查后推进下一节点。",
+        "prompt": "# 集成验证\n\n## 节点职责\n\n将远程主线最新状态整合到任务分支，并在最终集成态执行适用回归，形成绑定明确版本的验证结论。版本控制与范围判断由当前执行者负责——范围判断是严肃决策，跑与不跑都必须有证据支撑，全量是须举证的选项而非默认值。测试命令交给独立 `test-executor` 执行；若产生代码修复，再交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、技术方案、实现与测试记录、`align-branch` 的基础分支与合并记录，以及项目的分支策略、测试体系和所属模块提示词。加载 `workflow-discipline`，调用 `test-executor` 执行回归；发生代码修复时调用 `code-reviewer`。测试失败且根因不明确时，再加载 `bugfix-root-cause-verification`。\n\n优先使用 `align-branch` 已记录的基础分支；记录缺失时，按与该节点相同的规则从任务上下文或项目提示词解析，例如 `main`、`master` 或 `dev`。仍无法解析时询问用户是否需要合并某个分支的远程代码，不根据版本历史猜测基础分支。\n\n## 执行流程\n\n1. 获取远程状态，优先读取 `align-branch` 记录的基础分支；记录缺失时从任务上下文或项目提示词解析，仍无法解析则询问用户。记录当前任务版本、基础分支、远程版本及判断依据。\n2. 用户明确表示无需合并时记录该决定；否则按项目策略整合基础分支的远程最新代码。发生冲突时理解双方意图后逐项融合并验证结果，不盲目选择任一侧；无法可靠解决时说明冲突与缺失决策并暂停。\n3. 汇总任务改动和主线整合改动，读取项目测试目录、配置、脚本与现有用例，列出适用的测试层级和执行入口；项目未定义的层级记录 N/A。\n4. 回归执行决策由「是否执行」与「执行什么」两半构成，每一半都必须由证据支撑，禁止无分析的保守回退：\n   - 零差异不重跑：某层级相对既有已验证版本（绑定明确版本标识、全绿证据在案）覆盖面差异为空时，该层级禁止重复执行，记录绑定证据替代重跑；\n   - 有差异走判断链：a) 变更清单——汇总任务改动、主线整合改动与集成期修复，落到具体文件和对外可见的符号、契约、配置；b) 依赖分析——逐变更点查明引用方与波及面（导入、调用、共享契约、构建配置），得出受影响模块清单；c) 测试映射——把受影响模块映射到具体用例（既有用例位置、任务新增或修改的用例、所属层级与执行入口）；d) 最小充分决策——按定向用例、受影响模块、整层级的顺序逐级扩大，每次扩大都指出上一级不充分的具体证据；\n   - 全量须举证：仅当判断链证据表明影响面确实覆盖整个层级（如横切基础设施、共享契约、构建配置变更）才执行全量。宣称「无法判断影响范围」前必须已完成 a)–c) 分析；分析后仍存在的盲区逐条列明（哪个变更点、查了什么、缺什么信息），把盲区对应的补充用例并入执行范围并留痕。未做分析就宣称无法判断、或以「保险起见」跳过判断直接全量，均判定为范围决策失败。\n5. 将明确的命令、顺序、范围和通过标准交给 `test-executor` 执行——委派命令的覆盖范围必须与第 4 条判断链结论一致，判了定向就执行定向入口，不得委派时顺手扩大。依据事实报告核对各层级统计、失败、跳过和日志。\n6. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按需加载 `bugfix-root-cause-verification`，确认根因后再修改代码、测试或环境。\n7. 每次修复后重新执行原失败范围和受影响回归。不得通过删除有效测试、skip/only、缩小应执行范围、放宽正确断言、吞异常或硬编码结果制造通过。\n8. 检查新增 skip/only、测试删除、未执行的适用层级、范围遗漏和统计对账。发生代码修复时，将客观约束与变更位置交给 `code-reviewer`；修复 BLOCKER、HIGH Findings 后重跑受影响测试并复审，直至测试通过且评审为 PASS。\n9. 记录最终同步状态、实际回归范围、测试结果和已验证的提交或等价版本标识，确保后续能够判断证据是否仍有效。\n\n## 产出与检查\n\n推进前确认：\n\n- 基础分支沿用 `align-branch` 记录，或已按相同规则重新解析并留痕；\n- 基础分支的远程状态已获取并完成整合，或用户已明确表示无需合并；\n- 所有冲突均已理解并正确融合；\n- 项目适用测试层级与执行入口已识别，N/A 有具体依据；\n- 回归范围由完整判断链支撑（变更清单 → 依赖分析 → 测试映射 → 逐级扩大决策），每个执行范围都能指认其覆盖的变更点；零差异层级以绑定证据替代重跑；全量执行附有影响面覆盖整个层级的具体证据；不存在无分析的全量兜底；\n- `test-executor` 报告所有适用回归通过，失败为 0，未授权跳过为 0；\n- 所有失败均在根因明确后修复，没有制造假绿；\n- 发生代码修复时，`code-reviewer` 最终结论为 PASS；\n- 集成结论绑定明确版本，日志和报告可追溯。\n\n## 任务差异处理\n\n基础分支没有新提交时无需制造合并提交；回归是否执行、执行什么，一律按第 4 条的零差异判定与判断链决定——集成态与已验证版本一致且证据在案时以证据绑定替代重跑，集成态有新增内容时按判断链定范围。用户明确表示无需合并时保留决定，验证决策同样按第 4 条执行。根据项目实际体系选择测试层级和命令，不擅自引入未定义的测试类型。远程状态不可获取、冲突无法可靠解决，或修复涉及破坏性契约、新依赖和真实范围扩张时，说明证据与影响并暂停；同一问题多轮不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将基础分支来源、同步策略与结果、任务和远程版本、冲突处理、适用测试层级、回归范围判断链（变更清单、依赖分析、测试映射、逐级扩大证据、零差异证据绑定）及结论、实际命令与统计、失败根因和修复、完整性检查、代码评审结果、日志与报告引用、最终已验证版本写入当前节点记录。完成上述检查后推进下一节点。\n",
         "skills": [
           "workflow-discipline"
         ],
@@ -238,8 +238,8 @@
         ],
         "sourcePreset": {
           "code": "test-integrate",
-          "version": "1.3.0",
-          "contentHash": "a29435e9ed9bbc68",
+          "version": "1.4.0",
+          "contentHash": "2a6c9a9bbc3452ce",
           "agents": [
             "test-executor",
             "code-reviewer"
@@ -423,7 +423,7 @@
       }
     },
     "isDefault": false,
-    "version": "3.4.2"
+    "version": "3.4.4"
   },
   "dependencies": {
     "skills": [
@@ -439,13 +439,13 @@
       {
         "name": "tech-design",
         "description": "将产品需求转化为可实现、可验证的技术设计",
-        "content": "# 技术方案设计\n\n将已确认的产品需求转化为可以直接指导实现和验证的技术设计。\n\n## 工作原则\n\n- 先理解需求、项目约束和现有架构，再选择技术方案。\n- 设计必须覆盖需求，但不扩张产品范围。\n- 关键决策说明备选方案、最终选择及取舍理由。\n- 设计到足以消除实现歧义为止，不编写生产代码或完整测试代码。\n- 根据任务范围调整设计深度，避免为简单任务堆叠无关内容。\n\n## 执行方法\n\n1. 建立需求、验收标准与设计内容的对应关系。\n2. 识别模块边界、核心流程及适用的数据和接口契约。\n3. 根据实际影响设计异常处理、安全、兼容迁移、发布回退和验证方式。\n4. 检查设计是否足以支持实现、测试和验收。\n5. 读取 `references/template.md` 形成技术方案；可以增加任务特有章节，但必须保留最低必备信息。\n\n## 模板使用规则\n\n所有技术方案必须包含：\n\n- 目标与范围；\n- 现状与约束；\n- 方案总览；\n- 需求与设计对应；\n- 关键决策；\n- 详细设计；\n- 验证方案；\n- 风险与开放问题。\n\n以下内容按任务实际影响填写：\n\n- 数据设计；\n- 接口与交互契约；\n- 安全与可靠性；\n- 发布、迁移与回退。\n\n按需章节不适用时，可以省略正文，但必须在“不适用项”中记录具体对象和理由。不得保留空章节，也不得只写“无影响”而不说明判断依据。\n\n## 设计边界\n\n允许使用字段表、接口 schema、状态机、时序图、决策表和测试矩阵表达设计。\n\n不写完整方法体、可直接执行的生产代码、完整测试代码或完整配置文件；这些内容属于后续实现节点。",
+        "content": "# 技术方案设计\n\n将已确认的产品需求转化为可以直接指导实现和验证的技术设计。\n\n## 工作原则\n\n- 先理解需求、项目约束和现有架构，再选择技术方案。\n- 默认以图形表达结构与流程：架构图（模块或组件划分及相互关系）与核心功能流程图（主要功能的执行步骤与关键分支）。\n- 设计必须覆盖需求，但不扩张产品范围。\n- 关键决策说明备选方案、最终选择及取舍理由。\n- 设计到足以消除实现歧义为止，不编写生产代码或完整测试代码。\n- 根据任务范围调整设计深度，避免为简单任务堆叠无关内容。\n\n## 执行方法\n\n1. 建立需求、验收标准与设计内容的对应关系。\n2. 识别模块边界、核心流程及适用的数据和接口契约，并据此形成架构图与核心功能流程图。\n3. 根据实际影响设计异常处理、安全、兼容迁移、发布回退和验证方式。\n4. 检查设计是否足以支持实现、测试和验收。\n5. 读取 `references/template.md` 形成技术方案；可以增加任务特有章节，但必须保留最低必备信息。\n\n## 模板使用规则\n\n所有技术方案必须包含：\n\n- 目标与范围；\n- 现状与约束；\n- 方案总览；\n- 需求与设计对应；\n- 关键决策；\n- 详细设计；\n- 验证方案；\n- 风险与开放问题。\n\n所有技术方案默认包含两张图，无需用户额外要求：\n\n- **架构图**：呈现系统或模块的划分及其相互关系；\n- **核心功能流程图**：呈现主要功能的执行步骤与关键分支。\n\n图使用项目约定的图形表达方式；项目未约定时使用可渲染的图形语法（如 Mermaid），不使用纯文字罗列或代码片段代替。示意级别即可，不追求专业绘图工具的精细度。图中出现的模块、步骤和分支必须在正文有对应说明，正文描述的结构与流程也必须在图中出现。两张图不因任务规模小、改动简单或用户未要求而省略；确实不存在可表达的结构或流程时，按“不适用项”规则写明具体对象和理由。\n\n以下内容按任务实际影响填写：\n\n- 数据设计；\n- 接口与交互契约；\n- 安全与可靠性；\n- 发布、迁移与回退。\n\n按需章节不适用时，可以省略正文，但必须在“不适用项”中记录具体对象和理由。不得保留空章节，也不得只写“无影响”而不说明判断依据。\n\n## 设计边界\n\n允许使用字段表、接口 schema、状态机、时序图、架构图、流程图、决策表和测试矩阵表达设计。\n\n不写完整方法体、可直接执行的生产代码、完整测试代码或完整配置文件；这些内容属于后续实现节点。",
         "category": "process",
-        "version": "1.0.0",
+        "version": "1.1.0",
         "references": [
           {
             "path": "references/template.md",
-            "content": "# <任务标题>技术方案\n\n> 输入需求：<PRD 或任务需求引用>\n> 状态：<草稿/已确认>\n> 版本：<版本>\n\n## 1. 目标与范围【必备】\n\n- 解决的问题：\n- 本次覆盖：\n- 明确不做：\n- 成功判定：\n\n## 2. 现状与约束【必备】\n\n说明现有架构、相关模块、项目规则、兼容要求和已知限制。\n\n## 3. 方案总览【必备】\n\n### 3.1 整体设计\n\n使用文字或图表说明模块关系、核心流程和数据流。\n\n### 3.2 需求与设计对应【必备】\n\n| 需求或验收项 | 对应设计章节 | 覆盖说明 |\n|---|---|---|\n\n### 3.3 关键决策【必备】\n\n| 决策点 | 备选方案 | 最终选择 | 取舍理由 |\n|---|---|---|---|\n\n## 4. 详细设计【必备】\n\n按功能或模块组织；每项说明：\n\n- 职责与边界；\n- 输入、输出和依赖；\n- 正常流程；\n- 异常与边界流程；\n- 数据或状态变化；\n- 与其他模块的交互；\n- 兼容与迁移影响。\n\n## 5. 数据设计【按需】\n\n说明数据结构、字段、约束、关系、索引、生命周期和存量数据处理。\n\n## 6. 接口与交互契约【按需】\n\n说明调用方、输入输出、错误响应、权限、幂等和兼容策略。\n\n## 7. 安全与可靠性【按需】\n\n说明权限边界、输入安全、敏感信息、一致性、部分失败、重试、恢复和回滚。\n\n## 8. 验证方案【必备】\n\n| 验证对象 | 验证层级 | 场景 | 预期结果 |\n|---|---|---|---|\n\n说明单元测试、集成测试、端到端测试和人工验证的边界。\n\n## 9. 发布、迁移与回退【按需】\n\n说明部署顺序、配置变化、数据迁移、兼容窗口、可观测信号、回退条件和回退步骤。\n\n## 10. 风险与开放问题【必备】\n\n| 风险或问题 | 影响 | 应对方式 | 状态 |\n|---|---|---|---|\n\n## 11. 不适用项【必备】\n\n列出模板中不适用于当前任务的内容及理由；没有时写“无”。"
+            "content": "# <任务标题>技术方案\n\n> 输入需求：<PRD 或任务需求引用>\n> 状态：<草稿/已确认>\n> 版本：<版本>\n\n## 1. 目标与范围【必备】\n\n- 解决的问题：\n- 本次覆盖：\n- 明确不做：\n- 成功判定：\n\n## 2. 现状与约束【必备】\n\n说明现有架构、相关模块、项目规则、兼容要求和已知限制。\n\n## 3. 方案总览【必备】\n\n### 3.1 整体设计\n\n默认必须包含以下两张图（示意级别，使用可渲染的图形语法，如 Mermaid；项目已约定图形表达方式时从其约定），并配合正文说明：\n\n- **架构图**：系统或模块的划分及其相互关系；\n- **核心功能流程图**：主要功能的执行步骤与关键分支。\n\n图中的模块、步骤和分支必须在正文有对应说明；正文描述的结构与流程必须在图中出现。\n\n### 3.2 需求与设计对应【必备】\n\n| 需求或验收项 | 对应设计章节 | 覆盖说明 |\n|---|---|---|\n\n### 3.3 关键决策【必备】\n\n| 决策点 | 备选方案 | 最终选择 | 取舍理由 |\n|---|---|---|---|\n\n## 4. 详细设计【必备】\n\n按功能或模块组织；每项说明：\n\n- 职责与边界；\n- 输入、输出和依赖；\n- 正常流程；\n- 异常与边界流程；\n- 数据或状态变化；\n- 与其他模块的交互；\n- 兼容与迁移影响。\n\n## 5. 数据设计【按需】\n\n说明数据结构、字段、约束、关系、索引、生命周期和存量数据处理。\n\n## 6. 接口与交互契约【按需】\n\n说明调用方、输入输出、错误响应、权限、幂等和兼容策略。\n\n## 7. 安全与可靠性【按需】\n\n说明权限边界、输入安全、敏感信息、一致性、部分失败、重试、恢复和回滚。\n\n## 8. 验证方案【必备】\n\n| 验证对象 | 验证层级 | 场景 | 预期结果 |\n|---|---|---|---|\n\n说明单元测试、集成测试、端到端测试和人工验证的边界。\n\n## 9. 发布、迁移与回退【按需】\n\n说明部署顺序、配置变化、数据迁移、兼容窗口、可观测信号、回退条件和回退步骤。\n\n## 10. 风险与开放问题【必备】\n\n| 风险或问题 | 影响 | 应对方式 | 状态 |\n|---|---|---|---|\n\n## 11. 不适用项【必备】\n\n列出模板中不适用于当前任务的内容及理由；没有时写“无”。"
           }
         ],
         "scope": "global"

package/templates/builtin/quick_workflow.bundle.json

@@ -1,6 +1,6 @@
 {
   "exportFormatVersion": "1.0",
-  "exportedAt": "2026-09-09T15:57:17.950Z",
+  "exportedAt": "2026-09-10T09:29:55.517Z",
   "warnings": [],
   "template": {
     "name": "quick_workflow",
@@ -28,7 +28,7 @@
         "label": "快速设计",
         "phase": "entry",
         "track": "all",
-        "prompt": "# 快速设计\n\n## 节点职责\n\n将用户描述的小型改动直接整理为最小技术方案——改动点、影响面、验证方式——经一次独立 AI 评审和用户人工确认后进入编码。本流程不设独立需求节点：用户描述与任务上下文就是需求源头。本节点只产出方案，不编写生产代码或测试代码。\n\n## 依赖信息\n\n先检查当前任务上下文：用户需求描述、验收标准、非目标、已有决策，以及项目和所属模块的提示词。加载 `workflow-discipline`；调用独立 `arch-reviewer` 完成方案评审。\n\n直接阅读相关代码和文档，确认真实改动位置、调用关系、依赖方与影响。缺少会改变方案的关键信息时先从仓库现状补齐；仍存在歧义时集中向用户说明并确认，不凭猜测设计。\n\n## 正向执行流程\n\n1. 从用户描述提炼目标行为、保持不变的行为和非目标，整理为可核对的改动点清单。\n2. 逐项定位改动点涉及的模块、调用关系与依赖方，说明对接口、数据、配置、兼容性和用户行为的影响。\n3. 形成最小技术方案，必含：背景与目标、改动点清单（位置+目标行为）、影响面、验证方式、非目标、必要决策；验证方式须能对应验收标准。\n4. 检查复杂度红线：跨多个边界模块、新增公开接口或数据契约、数据迁移、新依赖、破坏性变更、需要多路线取舍。命中时说明快速流程为何不足，建议改走完整流程；用户明确接受风险坚持快速路径时，记录确认原文。\n5. 将方案全文与客观约束（用户描述、验收标准、参照代码位置）交给 `arch-reviewer` 单轮独立评审，不提供主会话的设计结论。存在 BLOCKER 或 HIGH 时修复后重新发起评审；MEDIUM、LOW 逐项处理或记录保留理由，直至评审 PASS。\n6. 评审通过后向用户呈现方案：改动点清单、影响面、验证方式、AI 评审结论与红线判断，等待人工确认。\n7. 用户确认后：方案全文按项目文档约定保存并登记任务产物（携带全文；超限时路径引用须说明理由）；按项目分支策略创建任务分支并记录关联。若预判改动可能无可自动验证行为，在方案中显式声明——该声明进入编码节点测试范围判定与本次确认范围。\n\n## 产出与检查\n\n推进前确认：每个改动点有位置、目标行为与影响说明；验证方式对应验收标准；复杂度红线已检查，命中项已升级或取得用户风险确认；`arch-reviewer` 最终 PASS 且 Findings 处理留痕；用户明确确认且原文已记录；方案全文已保存登记；任务分支已就绪。\n\n## 任务差异处理\n\n纯文档、配置类改动可裁剪方案章节，但改动点、影响面、验证方式、非目标不得缺失。信息不足以形成方案时保留在本节点补齐，不推进。\n\n## 节点记录与推进\n\n将方案要点、改动点、影响面、验证方式、红线判断、AI 评审结论与轮次、用户确认原文、方案产物与分支信息写入节点记录，推进编码节点。",
+        "prompt": "# 快速设计\n\n## 节点职责\n\n将用户描述的小型改动直接整理为最小技术方案——改动点、影响面、验证方式——经一次独立 AI 评审和用户人工确认后进入编码。本流程不设独立需求节点：用户描述与任务上下文就是需求源头。本节点只产出方案，不编写生产代码或测试代码。\n\n## 依赖信息\n\n先检查当前任务上下文：用户需求描述、验收标准、非目标、已有决策，以及项目和所属模块的提示词。加载 `workflow-discipline`；调用独立 `arch-reviewer` 完成方案评审。\n\n直接阅读相关代码和文档，确认真实改动位置、调用关系、依赖方与影响。缺少会改变方案的关键信息时先从仓库现状补齐；仍存在歧义时集中向用户说明并确认，不凭猜测设计。\n\n## 正向执行流程\n\n1. 从用户描述提炼目标行为、保持不变的行为和非目标，整理为可核对的改动点清单。\n2. 逐项定位改动点涉及的模块、调用关系与依赖方，说明对接口、数据、配置、兼容性和用户行为的影响。\n3. 形成最小技术方案，必含：背景与目标、改动点清单（位置+目标行为）、影响面、架构图与核心功能流程图、验证方式、非目标、必要决策；验证方式须能对应验收标准。两张图用可渲染的图形语法表达（项目未约定时用 Mermaid），示意级别即可，不使用文字罗列代替；图中模块、步骤、分支与正文互相有对应说明。\n4. 检查复杂度红线：跨多个边界模块、新增公开接口或数据契约、数据迁移、新依赖、破坏性变更、需要多路线取舍。命中时说明快速流程为何不足，建议改走完整流程；用户明确接受风险坚持快速路径时，记录确认原文。\n5. 将方案全文与客观约束（用户描述、验收标准、参照代码位置）交给 `arch-reviewer` 单轮独立评审，不提供主会话的设计结论。存在 BLOCKER 或 HIGH 时修复后重新发起评审；MEDIUM、LOW 逐项处理或记录保留理由，直至评审 PASS。\n6. 评审通过后先把方案全文落盘为可独立阅读的文档（项目正式文档路径；尚未确定时写临时草稿并注明），再向用户呈现该文档的可读位置、改动点清单、影响面、验证方式、AI 评审结论与红线判断，等待人工确认——确认前用户必须能打开完整方案。\n7. 用户确认后：把已呈现的方案文档按项目文档约定保存为正式文档并登记任务产物（携带全文；超限时路径引用须说明理由），已落盘的草稿直接转为正式文档，不重写内容；按项目分支策略创建任务分支并记录关联。若预判改动可能无可自动验证行为，在方案中显式声明——该声明进入编码节点测试范围判定与本次确认范围。\n\n## 产出与检查\n\n推进前确认：每个改动点有位置、目标行为与影响说明；验证方式对应验收标准；方案含架构图与核心功能流程图，以可渲染的图形呈现且与正文一致（确实不适用时已写明对象与理由）；复杂度红线已检查，命中项已升级或取得用户风险确认；`arch-reviewer` 最终 PASS 且 Findings 处理留痕；用户明确确认且原文已记录；方案全文已保存登记；任务分支已就绪；呈现给用户的方案文档可独立打开阅读，且与确认的版本一致。\n\n## 任务差异处理\n\n纯文档、配置类改动可裁剪方案章节，但改动点、影响面、架构图与核心功能流程图、验证方式、非目标不得缺失。信息不足以形成方案时保留在本节点补齐，不推进。\n\n## 节点记录与推进\n\n将方案要点、改动点、影响面、验证方式、红线判断、AI 评审结论与轮次、用户确认原文、方案产物与分支信息写入节点记录，推进编码节点。",
         "skills": [
           "workflow-discipline"
         ],
@@ -37,8 +37,8 @@
         ],
         "sourcePreset": {
           "code": "quick-design",
-          "version": "1.0.0",
-          "contentHash": "accec735ad0791af",
+          "version": "1.1.0",
+          "contentHash": "98b00192cc580305",
           "agents": [
             "arch-reviewer"
           ]
@@ -99,7 +99,7 @@
         "label": "集成验证",
         "phase": "test",
         "track": "all",
-        "prompt": "# 集成验证\n\n## 节点职责\n\n将远程主线最新状态整合到任务分支，并在最终集成态执行适用回归，形成绑定明确版本的验证结论。版本控制与范围判断由当前执行者负责，测试命令交给独立 `test-executor` 执行；若产生代码修复，再交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、技术方案、实现与测试记录、`align-branch` 的基础分支与合并记录，以及项目的分支策略、测试体系和所属模块提示词。加载 `workflow-discipline`，调用 `test-executor` 执行回归；发生代码修复时调用 `code-reviewer`。测试失败且根因不明确时，再加载 `bugfix-root-cause-verification`。\n\n优先使用 `align-branch` 已记录的基础分支；记录缺失时，按与该节点相同的规则从任务上下文或项目提示词解析，例如 `main`、`master` 或 `dev`。仍无法解析时询问用户是否需要合并某个分支的远程代码，不根据版本历史猜测基础分支。\n\n## 执行流程\n\n1. 获取远程状态，优先读取 `align-branch` 记录的基础分支；记录缺失时从任务上下文或项目提示词解析，仍无法解析则询问用户。记录当前任务版本、基础分支、远程版本及判断依据。\n2. 用户明确表示无需合并时记录该决定；否则按项目策略整合基础分支的远程最新代码。发生冲突时理解双方意图后逐项融合并验证结果，不盲目选择任一侧；无法可靠解决时说明冲突与缺失决策并暂停。\n3. 汇总任务改动和主线整合改动，读取项目测试目录、配置、脚本与现有用例，列出适用的测试层级和执行入口；项目未定义的层级记录 N/A。\n4. 根据代码差异、模块依赖和测试映射确定回归范围。无法可靠判断某一层级的受影响范围时，将该层级扩大到全量。\n5. 将明确的命令、顺序、范围和通过标准交给 `test-executor` 执行，依据事实报告核对各层级统计、失败、跳过和日志。\n6. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按需加载 `bugfix-root-cause-verification`，确认根因后再修改代码、测试或环境。\n7. 每次修复后重新执行原失败范围和受影响回归。不得通过删除有效测试、skip/only、缩小应执行范围、放宽正确断言、吞异常或硬编码结果制造通过。\n8. 检查新增 skip/only、测试删除、未执行的适用层级、范围遗漏和统计对账。发生代码修复时，将客观约束与变更位置交给 `code-reviewer`；修复 BLOCKER、HIGH Findings 后重跑受影响测试并复审，直至测试通过且评审为 PASS。\n9. 记录最终同步状态、实际回归范围、测试结果和已验证的提交或等价版本标识，确保后续能够判断证据是否仍有效。\n\n## 产出与检查\n\n推进前确认：\n\n- 基础分支沿用 `align-branch` 记录，或已按相同规则重新解析并留痕；\n- 基础分支的远程状态已获取并完成整合，或用户已明确表示无需合并；\n- 所有冲突均已理解并正确融合；\n- 项目适用测试层级与执行入口已识别，N/A 有具体依据；\n- 回归范围有代码差异、依赖或测试映射依据，无法判断的层级已扩大到全量；\n- `test-executor` 报告所有适用回归通过，失败为 0，未授权跳过为 0；\n- 所有失败均在根因明确后修复，没有制造假绿；\n- 发生代码修复时，`code-reviewer` 最终结论为 PASS；\n- 集成结论绑定明确版本，日志和报告可追溯。\n\n## 任务差异处理\n\n基础分支没有新提交时无需制造合并提交，但回归验证仍须执行。用户明确表示无需合并时保留决定并继续验证当前版本。根据项目实际体系选择测试层级和命令，不擅自引入未定义的测试类型。远程状态不可获取、冲突无法可靠解决，或修复涉及破坏性契约、新依赖和真实范围扩张时，说明证据与影响并暂停；同一问题多轮不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将基础分支来源、同步策略与结果、任务和远程版本、冲突处理、适用测试层级、回归范围及依据、实际命令与统计、失败根因和修复、完整性检查、代码评审结果、日志与报告引用、最终已验证版本写入当前节点记录。完成上述检查后推进下一节点。",
+        "prompt": "# 集成验证\n\n## 节点职责\n\n将远程主线最新状态整合到任务分支，并在最终集成态执行适用回归，形成绑定明确版本的验证结论。版本控制与范围判断由当前执行者负责——范围判断是严肃决策，跑与不跑都必须有证据支撑，全量是须举证的选项而非默认值。测试命令交给独立 `test-executor` 执行；若产生代码修复，再交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、技术方案、实现与测试记录、`align-branch` 的基础分支与合并记录，以及项目的分支策略、测试体系和所属模块提示词。加载 `workflow-discipline`，调用 `test-executor` 执行回归；发生代码修复时调用 `code-reviewer`。测试失败且根因不明确时，再加载 `bugfix-root-cause-verification`。\n\n优先使用 `align-branch` 已记录的基础分支；记录缺失时，按与该节点相同的规则从任务上下文或项目提示词解析，例如 `main`、`master` 或 `dev`。仍无法解析时询问用户是否需要合并某个分支的远程代码，不根据版本历史猜测基础分支。\n\n## 执行流程\n\n1. 获取远程状态，优先读取 `align-branch` 记录的基础分支；记录缺失时从任务上下文或项目提示词解析，仍无法解析则询问用户。记录当前任务版本、基础分支、远程版本及判断依据。\n2. 用户明确表示无需合并时记录该决定；否则按项目策略整合基础分支的远程最新代码。发生冲突时理解双方意图后逐项融合并验证结果，不盲目选择任一侧；无法可靠解决时说明冲突与缺失决策并暂停。\n3. 汇总任务改动和主线整合改动，读取项目测试目录、配置、脚本与现有用例，列出适用的测试层级和执行入口；项目未定义的层级记录 N/A。\n4. 回归执行决策由「是否执行」与「执行什么」两半构成，每一半都必须由证据支撑，禁止无分析的保守回退：\n   - 零差异不重跑：某层级相对既有已验证版本（绑定明确版本标识、全绿证据在案）覆盖面差异为空时，该层级禁止重复执行，记录绑定证据替代重跑；\n   - 有差异走判断链：a) 变更清单——汇总任务改动、主线整合改动与集成期修复，落到具体文件和对外可见的符号、契约、配置；b) 依赖分析——逐变更点查明引用方与波及面（导入、调用、共享契约、构建配置），得出受影响模块清单；c) 测试映射——把受影响模块映射到具体用例（既有用例位置、任务新增或修改的用例、所属层级与执行入口）；d) 最小充分决策——按定向用例、受影响模块、整层级的顺序逐级扩大，每次扩大都指出上一级不充分的具体证据；\n   - 全量须举证：仅当判断链证据表明影响面确实覆盖整个层级（如横切基础设施、共享契约、构建配置变更）才执行全量。宣称「无法判断影响范围」前必须已完成 a)–c) 分析；分析后仍存在的盲区逐条列明（哪个变更点、查了什么、缺什么信息），把盲区对应的补充用例并入执行范围并留痕。未做分析就宣称无法判断、或以「保险起见」跳过判断直接全量，均判定为范围决策失败。\n5. 将明确的命令、顺序、范围和通过标准交给 `test-executor` 执行——委派命令的覆盖范围必须与第 4 条判断链结论一致，判了定向就执行定向入口，不得委派时顺手扩大。依据事实报告核对各层级统计、失败、跳过和日志。\n6. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按需加载 `bugfix-root-cause-verification`，确认根因后再修改代码、测试或环境。\n7. 每次修复后重新执行原失败范围和受影响回归。不得通过删除有效测试、skip/only、缩小应执行范围、放宽正确断言、吞异常或硬编码结果制造通过。\n8. 检查新增 skip/only、测试删除、未执行的适用层级、范围遗漏和统计对账。发生代码修复时，将客观约束与变更位置交给 `code-reviewer`；修复 BLOCKER、HIGH Findings 后重跑受影响测试并复审，直至测试通过且评审为 PASS。\n9. 记录最终同步状态、实际回归范围、测试结果和已验证的提交或等价版本标识，确保后续能够判断证据是否仍有效。\n\n## 产出与检查\n\n推进前确认：\n\n- 基础分支沿用 `align-branch` 记录，或已按相同规则重新解析并留痕；\n- 基础分支的远程状态已获取并完成整合，或用户已明确表示无需合并；\n- 所有冲突均已理解并正确融合；\n- 项目适用测试层级与执行入口已识别，N/A 有具体依据；\n- 回归范围由完整判断链支撑（变更清单 → 依赖分析 → 测试映射 → 逐级扩大决策），每个执行范围都能指认其覆盖的变更点；零差异层级以绑定证据替代重跑；全量执行附有影响面覆盖整个层级的具体证据；不存在无分析的全量兜底；\n- `test-executor` 报告所有适用回归通过，失败为 0，未授权跳过为 0；\n- 所有失败均在根因明确后修复，没有制造假绿；\n- 发生代码修复时，`code-reviewer` 最终结论为 PASS；\n- 集成结论绑定明确版本，日志和报告可追溯。\n\n## 任务差异处理\n\n基础分支没有新提交时无需制造合并提交；回归是否执行、执行什么，一律按第 4 条的零差异判定与判断链决定——集成态与已验证版本一致且证据在案时以证据绑定替代重跑，集成态有新增内容时按判断链定范围。用户明确表示无需合并时保留决定，验证决策同样按第 4 条执行。根据项目实际体系选择测试层级和命令，不擅自引入未定义的测试类型。远程状态不可获取、冲突无法可靠解决，或修复涉及破坏性契约、新依赖和真实范围扩张时，说明证据与影响并暂停；同一问题多轮不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将基础分支来源、同步策略与结果、任务和远程版本、冲突处理、适用测试层级、回归范围判断链（变更清单、依赖分析、测试映射、逐级扩大证据、零差异证据绑定）及结论、实际命令与统计、失败根因和修复、完整性检查、代码评审结果、日志与报告引用、最终已验证版本写入当前节点记录。完成上述检查后推进下一节点。\n",
         "skills": [
           "workflow-discipline"
         ],
@@ -109,8 +109,8 @@
         ],
         "sourcePreset": {
           "code": "test-integrate",
-          "version": "1.3.0",
-          "contentHash": "a29435e9ed9bbc68",
+          "version": "1.4.0",
+          "contentHash": "2a6c9a9bbc3452ce",
           "agents": [
             "test-executor",
             "code-reviewer"
@@ -176,7 +176,7 @@
       }
     ],
     "isDefault": false,
-    "version": "2.0.0"
+    "version": "2.0.2"
   },
   "dependencies": {
     "skills": [

package/templates/builtin/research_workflow.bundle.json

@@ -1,6 +1,6 @@
 {
   "exportFormatVersion": "1.0",
-  "exportedAt": "2026-09-09T15:57:17.946Z",
+  "exportedAt": "2026-09-10T09:29:55.513Z",
   "warnings": [],
   "template": {
     "name": "research_workflow",