@siming-org/cli 0.8.1 → 0.8.2

package/dist/index.js

@@ -9038,7 +9038,7 @@ async function handleUpdateEnums(client, category, body) {
 // src/commands/settings/command.ts
 function createSettingsCommand() {
   const settings = new Command16("settings").description("Settings (enum registries)");
-  withCommonOpts(settings.command("enums [category]"), "fancy").description("Show enum registry (all 7 categories, or one category)").action(async (category, opts) => {
+  withCommonOpts(settings.command("enums [category]"), "fancy").description("Show enum registry (all categories, or one category)").action(async (category, opts) => {
     const client = createClient(opts.url);
     const catR = category ? EnumRegistryCategorySchema.safeParse(category) : null;
     if (category && !catR?.success) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@siming-org/cli",
-  "version": "0.8.1",
+  "version": "0.8.2",
   "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.8.1",
-    "@siming-org/server": "0.8.1"
+    "@siming-org/core": "0.8.2",
+    "@siming-org/server": "0.8.2"
   },
   "devDependencies": {
     "tsup": "^8.3.5",

package/templates/builtin/full_workflow.bundle.json

@@ -1,6 +1,6 @@
 {
   "exportFormatVersion": "1.0",
-  "exportedAt": "2026-09-23T10:30:51.111Z",
+  "exportedAt": "2026-09-26T15:30:41.833Z",
   "warnings": [],
   "template": {
     "name": "full_workflow",
@@ -32,17 +32,31 @@
         "label": "分支对齐",
         "phase": "entry",
         "track": "all",
-        "prompt": "# 分支对齐\n\n## 节点职责\n\n在后续工作开始前，确认是否需要合并基础分支的远程最新代码。\n\n## 依赖信息\n\n检查当前任务上下文和项目提示词，从中解析基础分支，例如 `main`、`master` 或 `dev`。按名称加载 `workflow-discipline` Skill。\n\n## 正向执行流程\n\n1. 能解析出基础分支时，获取并合并该分支的远程最新代码。\n2. 无法解析时，询问用户是否需要合并某个分支的远程代码。\n3. 用户指定分支后执行合并；用户明确表示不需要时，直接推进下一节点。\n\n## 产出检查\n\n推进前确认：基础分支的远程代码已成功合并，或者用户已明确表示不需要合并。\n\n## 任务差异处理\n\n没有远程仓库或用户不要求合并时，记录不执行的事实和理由。合并发生冲突且无法可靠解决时，保留在当前节点并向用户说明。\n\n## 节点记录与推进\n\n记录基础分支、合并结果，或不执行合并的理由，然后推进下一节点。",
+        "prompt": "# 分支对齐\n\n## 节点职责\n\n在后续工作开始前，确认是否需要合并基础分支的远程最新代码。\n\n## 依赖信息\n\n检查当前任务上下文和项目提示词，从中解析基础分支，例如 `main`、`master` 或 `dev`。按名称加载 `workflow-discipline` Skill。\n\n## 正向执行流程\n\n1. 能解析出基础分支时，获取并合并该分支的远程最新代码。\n2. 无法解析时，询问用户是否需要合并某个分支的远程代码。\n3. 用户指定分支后执行合并；用户明确表示不需要时，直接推进下一节点。\n\n## 产出检查\n\n推进前确认：基础分支的远程代码已成功合并，或者用户已明确表示不需要合并。\n\n## 任务差异处理\n\n没有远程仓库或用户不要求合并时，记录不执行的事实和理由。合并发生冲突且无法可靠解决时，保留在当前节点并向用户说明。\n\n## 节点记录与推进\n\n将基础分支经 record-set 结构化写入 baseBranch 字段（后续节点门禁的参数解析链依赖该值）；记录合并结果，或不执行合并的理由，然后推进下一节点。",
         "skills": [
           "workflow-discipline"
         ],
         "agents": [],
         "sourcePreset": {
           "code": "align-branch",
-          "version": "1.3.0",
-          "contentHash": "ffba197df7edb043",
+          "version": "1.4.0",
+          "contentHash": "1f0f21110ce062f9",
           "agents": []
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "git-base-recorded"
+          },
+          {
+            "type": "git-base-merged"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "align-merge-or-waive",
+            "item": "基础分支远程最新代码已合并入当前分支；用户明示不需合并时已写 decisions（topic=merge-waived）并附用户原话"
+          }
+        ]
       },
       {
         "id": "DESIGN",
@@ -60,13 +74,35 @@
         ],
         "sourcePreset": {
           "code": "design-tech",
-          "version": "1.6.0",
+          "version": "1.7.0",
           "contentHash": "5d62a31f3b2764f0",
           "agents": [
             "alignment-reviewer",
             "arch-reviewer"
           ]
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "git-branch-exists"
+          },
+          {
+            "type": "git-worktree-clean"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "design-artifact-complete",
+            "item": "技术方案全文已保存登记并符合 tech-design 模板最低必备信息，需求/验收标准/非目标均有对应设计"
+          },
+          {
+            "id": "design-reviews-settled",
+            "item": "alignment-reviewer 与 arch-reviewer 两道评审结论均已留痕，其余 Finding 已处置或记录保留理由"
+          },
+          {
+            "id": "design-user-confirmed",
+            "item": "审批材料（方案全文、摘要、关键取舍、两道审查结论、实现轨道）已完整呈现可支撑暂停点审批，呈现文档与当前方案版本一致；任务分支已创建并记录关联（确认原文由暂停点审批记录承载，不双写）"
+          }
+        ]
       },
       {
         "id": "INTERACTION",
@@ -104,12 +140,23 @@
         ],
         "sourcePreset": {
           "code": "code-backend",
-          "version": "1.4.0",
+          "version": "1.5.0",
           "contentHash": "53cebe02565babcc",
           "agents": [
             "code-reviewer"
           ]
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "git-worktree-clean"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "cb-review-settled",
+            "item": "code-reviewer 结论已写入节点记录，Findings 已全部处置或保留理由留痕；实现摘要与代码产物引用完整"
+          }
+        ]
       },
       {
         "id": "CODE_UI",
@@ -126,19 +173,30 @@
         ],
         "sourcePreset": {
           "code": "code-frontend",
-          "version": "1.4.0",
+          "version": "1.5.0",
           "contentHash": "6013913c24b5e6b7",
           "agents": [
             "code-reviewer"
           ]
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "git-worktree-clean"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "cf-review-settled",
+            "item": "code-reviewer 结论已写入节点记录，Findings 已全部处置或保留理由留痕；实现摘要与接口/界面边界处理完整"
+          }
+        ]
       },
       {
         "id": "UI_VISUAL",
         "label": "视觉验证",
         "phase": "track",
         "track": "ui",
-        "prompt": "# 视觉验证\n\n## 节点职责\n\n组织界面视觉验证的完整闭环：由独立 `visual-reviewer` 在单一 subagent 会话内自主完成「驱动界面 → 截图取证 → 分析判定」；本节点执行者（主会话）负责环境准备、锁定评估范围、消费报告与修复代码，不操作浏览器采证。本节点只建立**呈现断言**（页面是否按需求呈现：布局、还原度、色系、文案呈现、代表性视口观感、加载/空/错误等状态的视觉呈现）；功能结果、请求结果、字段语义、状态推导与持久化结果等**行为语义断言归端到端验证**，不在本节点建立。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、技术方案、前端实现记录，以及项目和所属模块的提示词。存在交互契约产物时，读取契约并将其自检清单与验收点作为呈现断言的锚点底座；无契约时以验收标准为底座。加载 `workflow-discipline`，委派独立 `visual-reviewer` 执行视觉验证。\n\n根据需求整理待验证页面与目标视觉状态。缺少运行方式、访问地址、认证或数据准备信息时，先从项目脚本、配置和现有环境中查找；仍无法运行当前实现时，说明缺失信息并暂停。\n\n## 执行流程\n\n1. 环境准备（主会话，不做浏览器操作）：按项目声明构建并启动当前实现及其依赖服务，确认页面对应本次代码，以命令行探活（curl 级）确认运行地址可访问；完成验证所需数据前置（种子数据、测试账号等）；记录运行地址、认证方式与数据前置说明。\n2. 产出场景清单：每条为“场景 × 呈现断言 × 锚点”三要素，锚点为交互契约条款（有契约时）或验收标准条款（无契约时）。**无锚点的呈现断言不得进入清单**；确有需求依据而契约缺条款时，登记契约缺口交回，不自行补写需求；既无锚点又无需求依据的呈现断言删除并记录原因。\n3. 委派 `visual-reviewer`：提供运行地址、认证方式（如有）、数据前置说明、场景清单、需求与设计规范、交互契约（如有）、证据落盘目录（工作区 temp/）；不提供实现者结论或预期缺陷。采证与分析策略由 `visual-reviewer` 自行决策，主会话不预备截图。\n4. 接收报告：逐条核对 Finding 与证据引用，证据文件留存 temp/ 供追溯；报告中标注的行为异常观察项按缺陷记录并交回处理，不在本节点沉淀为行为断言。\n5. 修复循环：呈现缺陷以及 BLOCKER、HIGH Findings 由主会话修复代码（不经 `visual-reviewer` 之手），受影响场景重新委派 `visual-reviewer` 重新驱动、重新采证、重新评审，直至视觉评审 PASS。MEDIUM、LOW 逐项处理或记录保留理由。\n6. 同一场景连续 2 轮评审 FAIL 即停止重跑，人工检查页面结构、运行轨迹与报告证据定位根因，禁止继续盲改重跑。\n7. 将本节点观察到的、应由端到端覆盖而设计未纳入的行为场景，通过节点记录交接给端到端设计/开发节点；该交接走节点记录，不进问题池。\n8. 清理本次创建的临时数据和运行资源，不删除非本次创建的数据。\n\n## 产出与检查\n\n推进前确认：\n\n- 场景清单每条含“场景 × 呈现断言 × 锚点”三要素，无锚点断言已按规则处置；\n- 运行地址探活通过、数据前置完成，页面已确认对应当前实现；\n- `visual-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明，行为异常观察项已交回；\n- 每条锚点在报告中有证据引用且证据文件存在于 temp/；\n- 主会话全程未操作浏览器采证；\n- 未在本节点建立行为语义断言，越界观察已记录并归回对应节点；\n- 同一场景未连续超过 2 轮盲改重跑，触发停手时已人工定位根因并记录结论；\n- 行为场景交接与临时数据、运行资源清理已完成。\n\n## 任务差异处理\n\n根据需求和页面能力选择目标状态与视口，不套用固定 CRUD 或截图数量。某项不适用时说明理由，不得静默跳过。运行地址无法就绪或 `visual-reviewer` 多轮（≥3）仍 FAIL 时暂停上升用户；修复需要改变已确认需求、设计方向、公开契约或引入新依赖时，说明影响并暂停；验证与修订轮次按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将场景清单、运行地址形态与数据前置、委派轮次、每轮结论与 Finding 处置、证据目录索引、越界观察与行为场景交接、未适用项及理由写入当前节点记录。完成上述检查后推进下一节点。",
+        "prompt": "# 视觉验证\n\n## 节点职责\n\n组织界面视觉验证的完整闭环：由独立 `visual-reviewer` 在单一 subagent 会话内自主完成「驱动界面 → 截图取证 → 分析判定」；本节点执行者（主会话）负责环境准备、锁定评估范围、消费报告与修复代码，不操作浏览器采证。本节点只建立**呈现断言**（页面是否按需求呈现：布局、还原度、色系、文案呈现、代表性视口观感、加载/空/错误等状态的视觉呈现）；功能结果、请求结果、字段语义、状态推导与持久化结果等**行为语义断言归端到端验证**，不在本节点建立。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、技术方案、前端实现记录，以及项目和所属模块的提示词。存在交互契约产物时，读取契约并将其自检清单与验收点作为呈现断言的锚点底座；无契约时以验收标准为底座。加载 `workflow-discipline`，委派独立 `visual-reviewer` 执行视觉验证。\n\n根据需求整理待验证页面与目标视觉状态。缺少运行方式、访问地址、认证或数据准备信息时，先从项目脚本、配置和现有环境中查找；仍无法运行当前实现时，说明缺失信息并暂停。\n\n## 执行流程\n\n1. 环境准备（主会话，不做浏览器操作）：按项目声明构建并启动当前实现及其依赖服务，确认页面对应本次代码，以命令行探活（curl 级）确认运行地址可访问；完成验证所需数据前置（种子数据、测试账号等）；记录运行地址、认证方式与数据前置说明。\n2. 产出场景清单：每条为“场景 × 呈现断言 × 锚点”三要素，锚点为交互契约条款（有契约时）或验收标准条款（无契约时）。**无锚点的呈现断言不得进入清单**；确有需求依据而契约缺条款时，登记契约缺口交回，不自行补写需求；既无锚点又无需求依据的呈现断言删除并记录原因。\n3. 委派 `visual-reviewer`：提供运行地址、认证方式（如有）、数据前置说明、场景清单、需求与设计规范、交互契约（如有）、证据落盘目录（工作区 temp/）；不提供实现者结论或预期缺陷。采证与分析策略由 `visual-reviewer` 自行决策，主会话不预备截图。\n4. 接收报告：逐条核对 Finding 与证据引用，证据文件留存 temp/ 供追溯；报告中标注的行为异常观察项按缺陷记录并交回处理，不在本节点沉淀为行为断言。\n5. 修复循环：呈现缺陷以及 BLOCKER、HIGH Findings 由主会话修复代码（不经 `visual-reviewer` 之手），受影响场景重新委派 `visual-reviewer` 重新驱动、重新采证、重新评审，直至视觉评审 PASS。MEDIUM、LOW 逐项处理或记录保留理由。\n6. 同一场景连续 2 轮评审 FAIL 即停止重跑，人工检查页面结构、运行轨迹与报告证据定位根因，禁止继续盲改重跑。\n7. 将本节点观察到的、应由端到端覆盖而设计未纳入的行为场景，通过节点记录交接给端到端设计/开发节点；该交接走节点记录，不进问题池。\n8. 清理本次创建的临时数据和运行资源，不删除非本次创建的数据。\n\n## 产出与检查\n\n推进前确认：\n\n- 场景清单每条含“场景 × 呈现断言 × 锚点”三要素，无锚点断言已按规则处置；\n- 运行地址探活通过、数据前置完成，页面已确认对应当前实现；\n- `visual-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明，行为异常观察项已交回；\n- 每条锚点在报告中有证据引用且证据文件存在于 temp/；\n- 主会话全程未操作浏览器采证；\n- 未在本节点建立行为语义断言，越界观察已记录并归回对应节点；\n- 同一场景未连续超过 2 轮盲改重跑，触发停手时已人工定位根因并记录结论；\n- 行为场景交接与临时数据、运行资源清理已完成。\n\n## 任务差异处理\n\n根据需求和页面能力选择目标状态与视口，不套用固定 CRUD 或截图数量。某项不适用时说明理由，不得静默跳过。运行地址无法就绪或 `visual-reviewer` 多轮（≥3）仍 FAIL 时暂停上升用户；修复需要改变已确认需求、设计方向、公开契约或引入新依赖时，说明影响并暂停；验证与修订轮次按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将场景清单、运行地址形态与数据前置、委派轮次、每轮结论与 Finding 处置、证据目录索引（经 record-set 结构化逐文件写入 evidenceFiles 字段）、越界观察与行为场景交接、未适用项及理由写入当前节点记录。完成上述检查后推进下一节点。",
         "skills": [
           "workflow-discipline"
         ],
@@ -147,12 +205,23 @@
         ],
         "sourcePreset": {
           "code": "verify-visual",
-          "version": "1.6.0",
-          "contentHash": "2fce493ca1bebbf8",
+          "version": "1.7.0",
+          "contentHash": "640a179f932ac0bf",
           "agents": [
             "visual-reviewer"
           ]
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "record-evidence-files"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "visual-evidence-indexed",
+            "item": "证据目录已生成并经 record-set 逐文件写入 evidenceFiles；每轮结论与 Finding 处置已写入节点记录"
+          }
+        ]
       },
       {
         "id": "UT_DESIGN",
@@ -180,7 +249,7 @@
         "label": "单元测试开发",
         "phase": "test",
         "track": "backend",
-        "prompt": "# 单元测试开发\n\n## 节点职责\n\n依据已确认的单元测试设计编写或调整测试代码，验证生产行为与需求一致。测试代码和必要的生产代码修复由当前执行者完成；测试命令交给独立 `test-executor` 执行，最终代码交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、技术方案、生产代码、单元测试设计、前序决策，以及项目和所属模块的测试约束。加载 `coding-standards`、`workflow-discipline`；出现测试失败且根因不明确时加载 `bugfix-root-cause-verification`。调用 `test-executor` 执行测试，调用 `code-reviewer` 审查代码变更。\n\n读取现有测试、配置和项目命令，确认框架、命名、替身、数据准备、覆盖目标和日志规则。缺少关键信息时先从仓库现状补齐；仍无法确定测试语义时说明缺失信息并暂停。\n\n## 执行流程\n\n1. 建立“测试设计用例 → 测试实现或已有用例”的逐项映射，明确新增、调整和复用范围。\n2. 按项目惯例实现测试，验证业务结果、状态变化、错误传播和必要副作用；替身只隔离单元边界，不掩盖被测行为。\n3. 完成一个测试文件或紧密相关的一组用例后，将明确的命令、范围和通过标准交给 `test-executor` 执行，并依据事实报告判断结果。\n4. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按 `bugfix-root-cause-verification` 复现、提出并验证假设，确认根因后再修改测试、生产代码或环境。\n5. 修复后重新执行原失败范围及受影响回归。不得通过删除有效测试、skip/only、缩小应执行范围、放宽正确断言、吞异常、修改数据避开问题或硬编码结果制造通过。\n6. 所有设计用例实现后，先根据生产代码改动和依赖关系判定回归范围，无法可靠判断时扩大范围；范围判定完成后必须调用 `test-executor` 执行该回归范围。\n7. 检查设计映射、测试删除、skip/only、无效观察点、隔离性和覆盖统计，确认测试变更完整。\n8. 将需求、测试设计、项目约束和全部代码变更位置交给 `code-reviewer`，不提供实现者结论或预期结果。修复 BLOCKER、HIGH Findings 后重新执行受影响测试并复审，直至测试通过且评审为 PASS；MEDIUM、LOW 逐项处理或记录保留理由。\n\n## 产出与检查\n\n推进前确认：\n\n- 每个适用的测试设计用例都有对应实现或明确的已有测试；\n- 测试具有有效观察点，替身、数据和隔离方式符合项目约束；\n- 所有测试失败均在根因明确后修复，没有制造假绿；\n- `test-executor` 报告适用范围全部通过，失败为 0，未授权跳过为 0，日志可追溯；\n- 完整性检查通过，没有删除有效测试或遗漏设计用例；\n- `code-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明；\n- 测试代码、必要的生产修复和执行报告已形成可引用产物。\n\n## 任务差异处理\n\n根据项目测试框架和变更范围选择实现与回归方式，不套用固定命令或覆盖率指标。测试设计中的用例确实不适用或已被等价测试覆盖时，说明具体依据。失败修复涉及破坏性契约、新依赖或真实范围扩张时先说明影响并暂停；同一问题多轮仍不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将设计到实现的映射、测试代码变更、实际执行命令与范围、通过/失败/跳过统计、日志与报告引用、根因和修复、完整性结论、未适用项及理由、`code-reviewer` 结论与 Findings 处理情况写入当前节点记录。完成上述检查后推进下一节点。",
+        "prompt": "# 单元测试开发\n\n## 节点职责\n\n依据已确认的单元测试设计编写或调整测试代码，验证生产行为与需求一致。测试代码和必要的生产代码修复由当前执行者完成；测试命令交给独立 `test-executor` 执行，最终代码交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、技术方案、生产代码、单元测试设计、前序决策，以及项目和所属模块的测试约束。加载 `coding-standards`、`workflow-discipline`；出现测试失败且根因不明确时加载 `bugfix-root-cause-verification`。调用 `test-executor` 执行测试，调用 `code-reviewer` 审查代码变更。\n\n读取现有测试、配置和项目命令，确认框架、命名、替身、数据准备、覆盖目标和日志规则。缺少关键信息时先从仓库现状补齐；仍无法确定测试语义时说明缺失信息并暂停。\n\n## 执行流程\n\n1. 建立“测试设计用例 → 测试实现或已有用例”的逐项映射，明确新增、调整和复用范围。\n2. 按项目惯例实现测试，验证业务结果、状态变化、错误传播和必要副作用；替身只隔离单元边界，不掩盖被测行为。\n3. 完成一个测试文件或紧密相关的一组用例后，将明确的命令、范围和通过标准交给 `test-executor` 执行，并依据事实报告判断结果。\n4. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按 `bugfix-root-cause-verification` 复现、提出并验证假设，确认根因后再修改测试、生产代码或环境。\n5. 修复后重新执行原失败范围及受影响回归。不得通过删除有效测试、skip/only、缩小应执行范围、放宽正确断言、吞异常、修改数据避开问题或硬编码结果制造通过。\n6. 所有设计用例实现后，先根据生产代码改动和依赖关系判定回归范围，无法可靠判断时扩大范围；范围判定完成后必须调用 `test-executor` 执行该回归范围。\n7. 检查设计映射、测试删除、skip/only、无效观察点、隔离性和覆盖统计，确认测试变更完整。\n8. 将需求、测试设计、项目约束和全部代码变更位置交给 `code-reviewer`，不提供实现者结论或预期结果。修复 BLOCKER、HIGH Findings 后重新执行受影响测试并复审，直至测试通过且评审为 PASS；MEDIUM、LOW 逐项处理或记录保留理由。\n\n## 产出与检查\n\n推进前确认：\n\n- 每个适用的测试设计用例都有对应实现或明确的已有测试；\n- 测试具有有效观察点，替身、数据和隔离方式符合项目约束；\n- 所有测试失败均在根因明确后修复，没有制造假绿；\n- `test-executor` 报告适用范围全部通过，失败为 0，未授权跳过为 0，日志可追溯；\n- 完整性检查通过，没有删除有效测试或遗漏设计用例；\n- `code-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明；\n- 测试代码、必要的生产修复和执行报告已形成可引用产物。\n\n## 任务差异处理\n\n根据项目测试框架和变更范围选择实现与回归方式，不套用固定命令或覆盖率指标。测试设计中的用例确实不适用或已被等价测试覆盖时，说明具体依据。失败修复涉及破坏性契约、新依赖或真实范围扩张时先说明影响并暂停；同一问题多轮仍不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将设计到实现的映射、测试代码变更、实际执行命令与范围、通过/失败/跳过统计（经 record-set 结构化写入 testReport 字段，含实际执行命令）、日志与报告引用、根因和修复、完整性结论、未适用项及理由、`code-reviewer` 结论与 Findings 处理情况写入当前节点记录。完成上述检查后推进下一节点。",
         "skills": [
           "coding-standards",
           "workflow-discipline"
@@ -191,13 +260,30 @@
         ],
         "sourcePreset": {
           "code": "test-unit-implement",
-          "version": "1.3.1",
-          "contentHash": "34c3ea09310475d5",
+          "version": "1.5.0",
+          "contentHash": "f56cdf18c1d855de",
           "agents": [
             "test-executor",
             "code-reviewer"
           ]
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "record-test-report"
+          },
+          {
+            "type": "record-no-fake-green"
+          },
+          {
+            "type": "git-worktree-clean"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "ut-completeness",
+            "item": "完整性检查已执行（设计到实现映射与范围核对）并写入节点记录；失败项根因与修复留痕"
+          }
+        ]
       },
       {
         "id": "UI_UT_DESIGN",
@@ -225,7 +311,7 @@
         "label": "前端单元测试开发",
         "phase": "test",
         "track": "ui",
-        "prompt": "# 前端单元测试开发\n\n## 节点职责\n\n依据已确认的前端单元测试设计编写或调整测试代码，验证界面呈现与交互行为符合需求。测试代码和必要的前端实现修复由当前执行者完成；测试命令交给独立 `test-executor` 执行，最终代码交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、技术方案、前端实现变更、前端单元测试设计、前序决策，以及项目和所属模块的前端测试约束（框架与命令、覆盖率门）。加载 `coding-standards`、`workflow-discipline`；出现测试失败且根因不明确时加载 `bugfix-root-cause-verification`。调用 `test-executor` 执行测试，调用 `code-reviewer` 审查代码变更。\n\n读取现有前端测试、配置与项目命令，确认框架、渲染方式、定位与断言惯例、替身与数据准备、覆盖率统计范围。缺少关键信息时先从仓库现状补齐；仍无法确定测试语义时说明缺失信息并暂停。\n\n## 执行流程\n\n1. 建立“测试设计用例 → 测试实现或已有用例”的逐项映射，明确新增、调整和复用范围。\n2. 按项目惯例实现测试：Arrange-Act-Assert 结构、描述性命名说明场景与预期、相关用例分组；断言渲染输出、用户可见状态与交互结果，不断言内部状态或私有实现。\n3. 定位界面元素使用用户可感知的方式（可访问角色、标签文本、可见文本），不使用样式类名或内部选择器绑死实现结构。\n4. 替身只隔离单元边界：网络请求、时钟、路由等外部依赖用替身，不替换被测行为本身；用例之间相互独立、可任意顺序执行，禁止真实计时等待与顺序依赖。\n5. 完成一个测试文件或紧密相关的一组用例后，将明确的命令、范围和通过标准交给 `test-executor` 执行，并依据事实报告判断结果。\n6. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按 `bugfix-root-cause-verification` 复现、提出并验证假设，确认根因后再修改测试、前端实现或环境。\n7. 修复后重新执行原失败范围及受影响回归。不得通过删除有效测试、skip/only、缩小应执行范围、放宽正确断言、吞异常、修改数据避开问题或硬编码结果制造通过；不得通过调整覆盖率阈值、排除文件、缩小统计范围或屏蔽统计使覆盖率门通过。\n8. 覆盖率门不满足时按缺口补充用例；确属无法覆盖的代码说明原因并写入节点记录。\n9. 所有设计用例实现后，先根据前端改动与依赖关系判定回归范围，无法可靠判断时扩大范围；范围判定完成后必须调用 `test-executor` 执行该回归范围（含项目声明的覆盖率命令）。\n10. 检查设计映射、测试删除、skip/only、无效观察点、隔离性、独立性与覆盖率统计，确认测试变更完整。\n11. 将需求、测试设计、项目约束和全部代码变更位置交给 `code-reviewer`，不提供实现者结论或预期结果。修复 BLOCKER、HIGH Findings 后重新执行受影响测试并复审，直至测试通过且评审为 PASS；MEDIUM、LOW 逐项处理或记录保留理由。\n\n## 产出与检查\n\n推进前确认：\n\n- 每个适用的测试设计用例都有对应实现或明确的已有测试；\n- 测试具有用户可感知的观察点，断言行为与呈现而非实现细节；\n- 用例相互独立、可任意顺序执行，替身与数据准备符合项目约束；\n- 所有测试失败均在根因明确后修复，没有制造假绿；\n- `test-executor` 报告适用范围全部通过，失败为 0，未授权跳过为 0，覆盖率门满足，日志可追溯；\n- 覆盖率缺口或无法覆盖项已说明，未调整阈值、排除文件、缩小统计范围或屏蔽统计；\n- 完整性检查通过，没有删除有效测试或遗漏设计用例；\n- `code-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明；\n- 测试代码、必要的前端修复和执行报告已形成可引用产物。\n\n## 任务差异处理\n\n根据项目前端测试框架和变更范围选择实现与回归方式，不套用固定命令或覆盖率指标。测试设计中的用例确实不适用或已被等价测试覆盖时，说明具体依据。失败修复涉及破坏性契约、新依赖或真实范围扩张时先说明影响并暂停；同一问题多轮仍不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将设计到实现的映射、测试代码变更、实际执行命令与范围、通过/失败/跳过统计与覆盖率结果、日志与报告引用、根因和修复、无法覆盖项及说明、完整性结论、未适用项及理由、`code-reviewer` 结论与 Findings 处理情况写入当前节点记录。完成上述检查后推进下一节点。",
+        "prompt": "# 前端单元测试开发\n\n## 节点职责\n\n依据已确认的前端单元测试设计编写或调整测试代码，验证界面呈现与交互行为符合需求。测试代码和必要的前端实现修复由当前执行者完成；测试命令交给独立 `test-executor` 执行，最终代码交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、技术方案、前端实现变更、前端单元测试设计、前序决策，以及项目和所属模块的前端测试约束（框架与命令、覆盖率门）。加载 `coding-standards`、`workflow-discipline`；出现测试失败且根因不明确时加载 `bugfix-root-cause-verification`。调用 `test-executor` 执行测试，调用 `code-reviewer` 审查代码变更。\n\n读取现有前端测试、配置与项目命令，确认框架、渲染方式、定位与断言惯例、替身与数据准备、覆盖率统计范围。缺少关键信息时先从仓库现状补齐；仍无法确定测试语义时说明缺失信息并暂停。\n\n## 执行流程\n\n1. 建立“测试设计用例 → 测试实现或已有用例”的逐项映射，明确新增、调整和复用范围。\n2. 按项目惯例实现测试：Arrange-Act-Assert 结构、描述性命名说明场景与预期、相关用例分组；断言渲染输出、用户可见状态与交互结果，不断言内部状态或私有实现。\n3. 定位界面元素使用用户可感知的方式（可访问角色、标签文本、可见文本），不使用样式类名或内部选择器绑死实现结构。\n4. 替身只隔离单元边界：网络请求、时钟、路由等外部依赖用替身，不替换被测行为本身；用例之间相互独立、可任意顺序执行，禁止真实计时等待与顺序依赖。\n5. 完成一个测试文件或紧密相关的一组用例后，将明确的命令、范围和通过标准交给 `test-executor` 执行，并依据事实报告判断结果。\n6. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按 `bugfix-root-cause-verification` 复现、提出并验证假设，确认根因后再修改测试、前端实现或环境。\n7. 修复后重新执行原失败范围及受影响回归。不得通过删除有效测试、skip/only、缩小应执行范围、放宽正确断言、吞异常、修改数据避开问题或硬编码结果制造通过；不得通过调整覆盖率阈值、排除文件、缩小统计范围或屏蔽统计使覆盖率门通过。\n8. 覆盖率门不满足时按缺口补充用例；确属无法覆盖的代码说明原因并写入节点记录。\n9. 所有设计用例实现后，先根据前端改动与依赖关系判定回归范围，无法可靠判断时扩大范围；范围判定完成后必须调用 `test-executor` 执行该回归范围（含项目声明的覆盖率命令）。\n10. 检查设计映射、测试删除、skip/only、无效观察点、隔离性、独立性与覆盖率统计，确认测试变更完整。\n11. 将需求、测试设计、项目约束和全部代码变更位置交给 `code-reviewer`，不提供实现者结论或预期结果。修复 BLOCKER、HIGH Findings 后重新执行受影响测试并复审，直至测试通过且评审为 PASS；MEDIUM、LOW 逐项处理或记录保留理由。\n\n## 产出与检查\n\n推进前确认：\n\n- 每个适用的测试设计用例都有对应实现或明确的已有测试；\n- 测试具有用户可感知的观察点，断言行为与呈现而非实现细节；\n- 用例相互独立、可任意顺序执行，替身与数据准备符合项目约束；\n- 所有测试失败均在根因明确后修复，没有制造假绿；\n- `test-executor` 报告适用范围全部通过，失败为 0，未授权跳过为 0，覆盖率门满足，日志可追溯；\n- 覆盖率缺口或无法覆盖项已说明，未调整阈值、排除文件、缩小统计范围或屏蔽统计；\n- 完整性检查通过，没有删除有效测试或遗漏设计用例；\n- `code-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明；\n- 测试代码、必要的前端修复和执行报告已形成可引用产物。\n\n## 任务差异处理\n\n根据项目前端测试框架和变更范围选择实现与回归方式，不套用固定命令或覆盖率指标。测试设计中的用例确实不适用或已被等价测试覆盖时，说明具体依据。失败修复涉及破坏性契约、新依赖或真实范围扩张时先说明影响并暂停；同一问题多轮仍不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将设计到实现的映射、测试代码变更、实际执行命令与范围、通过/失败/跳过统计（经 record-set 结构化写入 testReport 字段，含实际执行命令）与覆盖率结果、日志与报告引用、根因和修复、无法覆盖项及说明、完整性结论、未适用项及理由、`code-reviewer` 结论与 Findings 处理情况写入当前节点记录。完成上述检查后推进下一节点。",
         "skills": [
           "coding-standards",
           "workflow-discipline"
@@ -236,20 +322,37 @@
         ],
         "sourcePreset": {
           "code": "test-ui-unit-implement",
-          "version": "1.0.0",
-          "contentHash": "c8ceaf5f205a7574",
+          "version": "1.2.0",
+          "contentHash": "1d1108c7e33bbe59",
           "agents": [
             "test-executor",
             "code-reviewer"
           ]
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "record-test-report"
+          },
+          {
+            "type": "record-no-fake-green"
+          },
+          {
+            "type": "git-worktree-clean"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "uut-completeness",
+            "item": "完整性检查已执行（映射与覆盖率结果核对）并写入节点记录；无法覆盖项有说明"
+          }
+        ]
       },
       {
         "id": "E2E_DESIGN",
         "label": "端到端测试设计",
         "phase": "test",
         "track": "all",
-        "prompt": "# 端到端测试设计\n\n## 节点职责\n\n判断项目是否存在适用的端到端测试体系；适用时为本次变更设计跨真实系统边界的可执行场景，不适用时记录依据；本节点对后端、界面与混合三类任务均生效。设计环节判定某场景本期做不了时，必须把该场景落成问题池 issue，不允许只留在设计文档里。本节点只产出测试设计，不编写或执行测试代码，并通过独立 `test-reviewer` 评审设计质量。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、技术方案、生产代码与低层测试变更（后端单元测试与/或前端单元测试，按任务轨道）、前序决策与节点记录中的行为场景交接建议（如视觉验证环节发现应覆盖而设计未纳入的行为），以及项目和所属模块的测试约束。加载 `workflow-discipline`，调用独立 `test-reviewer` 评审测试设计或不适用判断。\n\n读取项目提示词、测试说明、E2E 目录、配置、执行入口和现有用例，确认项目是否定义了 E2E 对象、边界、框架、环境和数据规则。缺少信息时先从仓库现状补齐，不凭通用惯例新建测试体系。\n\n## 执行流程\n\n1. 记录已检索的项目声明、目录、配置和现有用例，判断项目是否存在可用的 E2E 体系。\n2. 项目未定义 E2E 时，说明检索范围、判断依据及不引入新体系的结论，形成 N/A 产物后进入独立评审。\n3. 项目已定义 E2E 时，从需求和变更中识别必须跨真实边界验证的用户或系统路径，结合前序节点交接的行为场景、风险、现有覆盖和低层测试确定纳入与排除范围。\n4. 为每个场景写明标识、目标、优先级、前置条件、步骤、观察点、预期结果、数据准备、隔离和清理要求。场景应验证最终可观察结果，不只验证请求成功或调用发生。\n5. 覆盖正常、失败、权限、恢复、状态或兼容场景中的适用部分，并说明哪些行为已由单元测试或其他低层测试可靠覆盖，避免重复和遗漏；形成跨边界行为→场景映射表（每条须跨边界验证的行为对应至少一个场景 ID）。\n6. 逐条判定场景本次是否可做：外部条件不具备、依赖未就绪或数据准备不可行时，把该场景落成一条问题池 issue——标题写明场景，描述写清需求依据与延期理由，登记到当前任务所属项目；节点记录中写明已登记的 issue 编号。禁止只在设计文档里写“延期”而不落库；该场景何时补、是否转任务由问题池既有机制决定，本节点不另设清偿环节。\n7. 形成最终设计，不包含测试函数、可执行 fixture、请求代码或浏览器操作代码；延期场景在设计文档中保留排除状态与其 issue 编号。\n8. 将测试设计连同映射表交给 `test-reviewer`，不提供设计者结论或预期结果。委派材料按「契约 + 路标 + 已验锚点」组装：项目 E2E 约束以节选直接置入委派 prompt；需求、生产变更、现有用例给路径路标；非首轮重审随附上轮已验锚点清单。N/A 判断评审时提供检索范围与证据路标。\n9. 适用时修复 BLOCKER、HIGH Findings 后重新评审：reviewer 只重验本轮修订触及的条目与受影响锚点，未触及项沿用上轮结论，但每轮报告保持全量 Findings 快照——已解决的标记关闭，不静默丢弃，是否处理由主会话决策；评审至多 3 轮，第 3 轮仍未 PASS 时保留在当前节点并请用户裁定，附双方分歧清单。MEDIUM、LOW 逐项处理或记录保留理由。Findings 处理记录写入节点记录，禁止回写被评审文档——测试设计文档只保留设计本体。\n\n## 产出与检查\n\n推进前确认：\n\n- 项目 E2E 体系的适用性已有仓库证据；\n- N/A 时已记录检索范围和判断依据，未擅自新建框架、目录或入口；\n- 适用时，覆盖范围与本次跨边界行为逐项对应，纳入和排除均有理由；跨边界行为→场景映射表完整；\n- 每个场景的前置条件、步骤、观察点、预期结果和数据清理可供后续实现；\n- 延期场景已落成问题池 issue（标题、需求依据、延期理由、归属当前任务所属项目齐备），节点记录含 issue 编号；确无延期场景时已说明判定依据；\n- 与其他测试层级的边界明确，设计不含可执行测试代码，也不含评审处理记录；\n- `test-reviewer` 最终结论为 PASS（或按 3 轮上界经用户裁定通过），所有 Findings 均已处理或说明；\n- E2E 设计或 N/A 结论已形成完整产物，登记值携带全文（超限时为路径引用且已说明理由）。\n\n## 任务差异处理\n\n不默认逐接口覆盖，也不默认只测关键旅程；根据项目现有 E2E 体系、需求风险与低层覆盖确定范围。项目未定义 E2E 时不把本节点变成测试基础设施建设；若任务明确要求新建 E2E 体系，应将其作为范围与技术决策单独确认。场景确实无法执行时按执行流程第 6 条落问题池，不得静默删除或只在设计文档标注延期。E2E 设计文档超过约 400 行时先按场景分组拆分再送审。执行障碍和评审修订按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将 E2E 适用性、检索范围与依据、覆盖范围、场景设计、测试层级边界、数据与清理策略、延期场景的 issue 编号、前序行为场景交接的处理结果、不适用项及理由、设计产物（登记携带全文，超限时为路径引用且已说明理由）、`test-reviewer` 结论与各轮 Findings 处理记录写入当前节点记录——处理记录只进节点记录，被评审文档保持设计本体。完成上述检查后推进下一节点。",
+        "prompt": "# 端到端测试设计\n\n## 节点职责\n\n判断项目是否存在适用的端到端测试体系；适用时为本次变更设计跨真实系统边界的可执行场景，不适用时记录依据；本节点对后端、界面与混合三类任务均生效。设计环节判定某场景本期做不了时，必须把该场景落成问题池 issue，不允许只留在设计文档里。本节点只产出测试设计，不编写或执行测试代码，并通过独立 `test-reviewer` 评审设计质量。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、技术方案、生产代码与低层测试变更（后端单元测试与/或前端单元测试，按任务轨道）、前序决策与节点记录中的行为场景交接建议（如视觉验证环节发现应覆盖而设计未纳入的行为），以及项目和所属模块的测试约束。加载 `workflow-discipline`，调用独立 `test-reviewer` 评审测试设计或不适用判断。\n\n读取项目提示词、测试说明、E2E 目录、配置、执行入口和现有用例，确认项目是否定义了 E2E 对象、边界、框架、环境和数据规则。缺少信息时先从仓库现状补齐，不凭通用惯例新建测试体系。\n\n## 执行流程\n\n1. 记录已检索的项目声明、目录、配置和现有用例，判断项目是否存在可用的 E2E 体系。\n2. 项目未定义 E2E 时，说明检索范围、判断依据及不引入新体系的结论，形成 N/A 产物后进入独立评审。\n3. 项目已定义 E2E 时，从需求和变更中识别必须跨真实边界验证的用户或系统路径，结合前序节点交接的行为场景、风险、现有覆盖和低层测试确定纳入与排除范围。\n4. 为每个场景写明标识、目标、优先级、前置条件、步骤、观察点、预期结果、数据准备、隔离和清理要求。场景应验证最终可观察结果，不只验证请求成功或调用发生。\n5. 覆盖正常、失败、权限、恢复、状态或兼容场景中的适用部分，并说明哪些行为已由单元测试或其他低层测试可靠覆盖，避免重复和遗漏；形成跨边界行为→场景映射表（每条须跨边界验证的行为对应至少一个场景 ID）。\n6. 逐条判定场景本次是否可做：外部条件不具备、依赖未就绪或数据准备不可行时，把该场景落成一条问题池 issue——标题写明场景，描述写清需求依据与延期理由，登记到当前任务所属项目；节点记录中写明已登记的 issue 编号。禁止只在设计文档里写“延期”而不落库；该场景何时补、是否转任务由问题池既有机制决定，本节点不另设清偿环节。\n7. 形成最终设计，不包含测试函数、可执行 fixture、请求代码或浏览器操作代码；延期场景在设计文档中保留排除状态与其 issue 编号。\n8. 将测试设计连同映射表交给 `test-reviewer`，不提供设计者结论或预期结果。委派材料按「契约 + 路标 + 已验锚点」组装：项目 E2E 约束以节选直接置入委派 prompt；需求、生产变更、现有用例给路径路标；非首轮重审随附上轮已验锚点清单。N/A 判断评审时提供检索范围与证据路标。\n9. 适用时修复 BLOCKER、HIGH Findings 后重新评审：reviewer 只重验本轮修订触及的条目与受影响锚点，未触及项沿用上轮结论，但每轮报告保持全量 Findings 快照——已解决的标记关闭，不静默丢弃，是否处理由主会话决策；评审至多 3 轮，第 3 轮仍未 PASS 时保留在当前节点并请用户裁定，附双方分歧清单。MEDIUM、LOW 逐项处理或记录保留理由。Findings 处理记录写入节点记录，禁止回写被评审文档——测试设计文档只保留设计本体。\n\n## 产出与检查\n\n推进前确认：\n\n- 项目 E2E 体系的适用性已有仓库证据；\n- N/A 时已记录检索范围和判断依据，未擅自新建框架、目录或入口；\n- 适用时，覆盖范围与本次跨边界行为逐项对应，纳入和排除均有理由；跨边界行为→场景映射表完整；\n- 每个场景的前置条件、步骤、观察点、预期结果和数据清理可供后续实现；\n- 延期场景已落成问题池 issue（标题、需求依据、延期理由、归属当前任务所属项目齐备），节点记录含 issue 编号；确无延期场景时已说明判定依据；\n- 与其他测试层级的边界明确，设计不含可执行测试代码，也不含评审处理记录；\n- `test-reviewer` 最终结论为 PASS（或按 3 轮上界经用户裁定通过），所有 Findings 均已处理或说明；\n- E2E 设计或 N/A 结论已形成完整产物，登记值携带全文（超限时为路径引用且已说明理由）。\n\n## 任务差异处理\n\n不默认逐接口覆盖，也不默认只测关键旅程；根据项目现有 E2E 体系、需求风险与低层覆盖确定范围。项目未定义 E2E 时不把本节点变成测试基础设施建设；若任务明确要求新建 E2E 体系，应将其作为范围与技术决策单独确认。场景确实无法执行时按执行流程第 6 条落问题池，不得静默删除或只在设计文档标注延期。E2E 设计文档超过约 400 行时先按场景分组拆分再送审。执行障碍和评审修订按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将 E2E 适用性、检索范围与依据、覆盖范围、场景设计、测试层级边界、数据与清理策略、延期场景的 issue 编号（经 record-set 结构化写入 deferredIssues 字段）、前序行为场景交接的处理结果、不适用项及理由、设计产物（登记携带全文，超限时为路径引用且已说明理由）、`test-reviewer` 结论与各轮 Findings 处理记录写入当前节点记录——处理记录只进节点记录，被评审文档保持设计本体。完成上述检查后推进下一节点。",
         "skills": [
           "workflow-discipline"
         ],
@@ -258,19 +361,30 @@
         ],
         "sourcePreset": {
           "code": "test-e2e-design",
-          "version": "1.6.0",
-          "contentHash": "8061e58e3641a86c",
+          "version": "1.7.0",
+          "contentHash": "9822221477442bc7",
           "agents": [
             "test-reviewer"
           ]
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "record-deferred-issues"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "e2ed-deferred-pooled",
+            "item": "延期场景已逐条入 issue 池并经 record-set 写入 deferredIssues；设计产物已登记且各轮 Findings 已处置"
+          }
+        ]
       },
       {
         "id": "E2E_DEV",
         "label": "端到端测试开发",
         "phase": "test",
         "track": "all",
-        "prompt": "# 端到端测试开发\n\n## 节点职责\n\n依据已确认的 E2E 设计实现并验证跨真实系统边界的测试场景；设计结论为 N/A 时复核依据并记录结果；本节点对后端、界面与混合三类任务均生效。实现环节发现某场景本期确实不可执行时，必须把该场景落成问题池 issue，不允许只留在记录里当作已完成。测试代码和必要的生产代码修复由当前执行者完成；测试命令交给独立 `test-executor` 执行，最终代码交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、技术方案、生产代码、E2E 设计（含延期场景的 issue 编号）、低层测试结果（后端单元测试与/或前端单元测试，按任务轨道）、前序决策与节点记录中的行为场景交接建议，以及项目和所属模块的测试约束。加载 `coding-standards`、`workflow-discipline`；测试失败且根因不明确时，再加载 `bugfix-root-cause-verification`。调用 `test-executor` 执行测试，调用 `code-reviewer` 审查代码变更。\n\n读取项目的 E2E 目录、配置、执行入口、邻近用例和环境规则。缺少关键信息时先从仓库现状补齐，不擅自引入项目未定义的测试体系。\n\n## 执行流程\n\n1. 读取 E2E 适用性结论并建立“设计场景 → 测试实现或已有用例”的逐项映射；设计中标为延期的场景按其 issue 编号核对，不重复实现或重复登记。\n2. 设计结论为 N/A 时，复核项目仍未定义适用的 E2E 体系；依据成立则记录 N/A，发现依据不成立则返回设计范围判断，不直接越过设计补写测试。\n3. 适用时，按项目现有框架和唯一执行入口实现测试，落实前置条件、操作步骤、观察点、预期结果、数据隔离和清理。测试必须经过项目定义的真实边界，并验证最终可观察结果。\n4. 实现中发现某场景本期确实不可执行时，把该场景落成一条问题池 issue——标题写明场景，描述写清需求依据与延期理由（本期不可执行原因），登记到当前任务所属项目，并将 issue 编号写入节点记录；不得通过删除测试、跳过标记或缩水断言代替登记。\n5. 完成一个场景或紧密相关的一组场景后，将明确的命令、范围和通过标准交给 `test-executor` 执行。\n6. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按需加载 `bugfix-root-cause-verification`，确认根因后再修改测试、生产代码或环境。\n7. 修复后重新执行原失败场景及受影响回归。不得通过删除有效测试、skip/only、绕开真实边界、缩小应执行范围、放宽正确断言、吞异常或硬编码结果制造通过。\n8. 全部场景实现后，以证据链确定 E2E 回归范围：列出本节点的测试与生产代码变更，映射到受影响场景（同一入口、同一链路、共享前置数据的用例），逐项给出执行或排除的依据。E2E 全量是须举证的主动决策而非兜底——仅当证据表明改动横切多个入口或共享基础设施时执行；未完成受影响分析就宣称无法判断、或以“保险起见”直接全量，均判定为范围决策失败。生产代码发生修复时，同样按证据链确定并执行受影响的低层测试（含前端单测，按任务轨道）。\n9. 检查设计映射（含延期场景的 issue 编号）、测试删除、skip/only、断言有效性、真实边界、数据隔离、清理和环境可重复性。\n10. 将需求、E2E 设计、项目约束和全部代码变更位置交给 `code-reviewer`，不提供实现者结论或预期结果。修复 BLOCKER、HIGH Findings 后重新执行受影响测试并复审，直至测试通过且评审为 PASS；MEDIUM、LOW 逐项处理或记录保留理由。\n\n## 产出与检查\n\n推进前确认：\n\n- N/A 结论已有复核证据，或每个适用设计场景都有对应实现、明确的已有测试，或已落问题池 issue 并在节点记录留有编号；\n- 测试遵循项目现有 E2E 体系并经过真实系统边界；\n- 观察点、数据隔离、清理和环境准备符合项目约束；\n- 所有失败均在根因明确后修复，没有制造假绿；\n- `test-executor` 报告适用 E2E 和必要的低层回归全部通过，失败为 0，未授权跳过为 0；\n- 延期登记未被删除测试、跳过标记或缩水断言替代；\n- 完整性检查通过，日志和报告可追溯；\n- `code-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明；\n- 测试代码、必要的生产修复和执行报告已形成可引用产物。\n\n## 任务差异处理\n\n项目没有适用的 E2E 体系时不新建框架、目录或执行入口。根据项目能力和设计范围选择测试、环境和回归方式，不套用固定浏览器、协议、命令或覆盖指标。失败修复涉及破坏性契约、新依赖或真实范围扩张时先说明影响并暂停；同一问题多轮仍不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将 E2E 适用性复核、设计到实现的映射、测试代码变更、真实边界、数据与清理、实际执行命令、范围及判断依据、通过/失败/跳过统计、延期场景的 issue 编号、低层回归（含前端单测，按任务轨道）、日志与报告引用、根因和修复、完整性结论、`code-reviewer` 结论与 Findings 处理情况写入当前节点记录。完成上述检查后推进下一节点。",
+        "prompt": "# 端到端测试开发\n\n## 节点职责\n\n依据已确认的 E2E 设计实现并验证跨真实系统边界的测试场景；设计结论为 N/A 时复核依据并记录结果；本节点对后端、界面与混合三类任务均生效。实现环节发现某场景本期确实不可执行时，必须把该场景落成问题池 issue，不允许只留在记录里当作已完成。测试代码和必要的生产代码修复由当前执行者完成；测试命令交给独立 `test-executor` 执行，最终代码交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、技术方案、生产代码、E2E 设计（含延期场景的 issue 编号）、低层测试结果（后端单元测试与/或前端单元测试，按任务轨道）、前序决策与节点记录中的行为场景交接建议，以及项目和所属模块的测试约束。加载 `coding-standards`、`workflow-discipline`；测试失败且根因不明确时，再加载 `bugfix-root-cause-verification`。调用 `test-executor` 执行测试，调用 `code-reviewer` 审查代码变更。\n\n读取项目的 E2E 目录、配置、执行入口、邻近用例和环境规则。缺少关键信息时先从仓库现状补齐，不擅自引入项目未定义的测试体系。\n\n## 执行流程\n\n1. 读取 E2E 适用性结论并建立“设计场景 → 测试实现或已有用例”的逐项映射；设计中标为延期的场景按其 issue 编号核对，不重复实现或重复登记。\n2. 设计结论为 N/A 时，复核项目仍未定义适用的 E2E 体系；依据成立则记录 N/A，发现依据不成立则返回设计范围判断，不直接越过设计补写测试。\n3. 适用时，按项目现有框架和唯一执行入口实现测试，落实前置条件、操作步骤、观察点、预期结果、数据隔离和清理。测试必须经过项目定义的真实边界，并验证最终可观察结果。\n4. 实现中发现某场景本期确实不可执行时，把该场景落成一条问题池 issue——标题写明场景，描述写清需求依据与延期理由（本期不可执行原因），登记到当前任务所属项目，并将 issue 编号写入节点记录；不得通过删除测试、跳过标记或缩水断言代替登记。\n5. 完成一个场景或紧密相关的一组场景后，将明确的命令、范围和通过标准交给 `test-executor` 执行。\n6. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按需加载 `bugfix-root-cause-verification`，确认根因后再修改测试、生产代码或环境。\n7. 修复后重新执行原失败场景及受影响回归。不得通过删除有效测试、skip/only、绕开真实边界、缩小应执行范围、放宽正确断言、吞异常或硬编码结果制造通过。\n8. 全部场景实现后，以证据链确定 E2E 回归范围：列出本节点的测试与生产代码变更，映射到受影响场景（同一入口、同一链路、共享前置数据的用例），逐项给出执行或排除的依据。E2E 全量是须举证的主动决策而非兜底——仅当证据表明改动横切多个入口或共享基础设施时执行；未完成受影响分析就宣称无法判断、或以“保险起见”直接全量，均判定为范围决策失败。生产代码发生修复时，同样按证据链确定并执行受影响的低层测试（含前端单测，按任务轨道）。\n9. 检查设计映射（含延期场景的 issue 编号）、测试删除、skip/only、断言有效性、真实边界、数据隔离、清理和环境可重复性。\n10. 将需求、E2E 设计、项目约束和全部代码变更位置交给 `code-reviewer`，不提供实现者结论或预期结果。修复 BLOCKER、HIGH Findings 后重新执行受影响测试并复审，直至测试通过且评审为 PASS；MEDIUM、LOW 逐项处理或记录保留理由。\n\n## 产出与检查\n\n推进前确认：\n\n- N/A 结论已有复核证据，或每个适用设计场景都有对应实现、明确的已有测试，或已落问题池 issue 并在节点记录留有编号；\n- 测试遵循项目现有 E2E 体系并经过真实系统边界；\n- 观察点、数据隔离、清理和环境准备符合项目约束；\n- 所有失败均在根因明确后修复，没有制造假绿；\n- `test-executor` 报告适用 E2E 和必要的低层回归全部通过，失败为 0，未授权跳过为 0；\n- 延期登记未被删除测试、跳过标记或缩水断言替代；\n- 完整性检查通过，日志和报告可追溯；\n- `code-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明；\n- 测试代码、必要的生产修复和执行报告已形成可引用产物。\n\n## 任务差异处理\n\n项目没有适用的 E2E 体系时不新建框架、目录或执行入口。根据项目能力和设计范围选择测试、环境和回归方式，不套用固定浏览器、协议、命令或覆盖指标。失败修复涉及破坏性契约、新依赖或真实范围扩张时先说明影响并暂停；同一问题多轮仍不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将 E2E 适用性复核、设计到实现的映射、测试代码变更、真实边界、数据与清理、实际执行命令、范围及判断依据、通过/失败/跳过统计（经 record-set 结构化写入 testReport 字段）、延期场景的 issue 编号（经 record-set 结构化写入 deferredIssues 字段）、低层回归（含前端单测，按任务轨道）、日志与报告引用、根因和修复、完整性结论、`code-reviewer` 结论与 Findings 处理情况写入当前节点记录。完成上述检查后推进下一节点。",
         "skills": [
           "coding-standards",
           "workflow-discipline"
@@ -281,20 +395,37 @@
         ],
         "sourcePreset": {
           "code": "test-e2e-implement",
-          "version": "1.4.0",
-          "contentHash": "8b98aa2366937442",
+          "version": "1.6.0",
+          "contentHash": "1791f958337db64a",
           "agents": [
             "test-executor",
             "code-reviewer"
           ]
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "record-test-report"
+          },
+          {
+            "type": "record-no-fake-green"
+          },
+          {
+            "type": "git-worktree-clean"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "e2ei-completeness",
+            "item": "完整性检查已执行并写入节点记录；延期场景 issue 编号留痕，失败项根因与修复留痕"
+          }
+        ]
       },
       {
         "id": "INTEGRATE",
         "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. 回归执行决策由「是否执行」与「执行什么」两半构成，每一半都必须由证据支撑，禁止无分析的保守回退：\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",
+        "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将基础分支来源、同步策略与结果、任务和远程版本、冲突处理、适用测试层级、回归范围判断链（变更清单、依赖分析、测试映射、逐级扩大证据、零差异证据绑定）及结论、实际命令与统计、失败根因和修复、完整性检查、代码评审结果、日志与报告引用、最终已验证版本（经 record-set 结构化写入 verifiedCommit 字段；本轮发生修复时经 record-set 写入 fixesApplied 次数）写入当前节点记录。完成上述检查后推进下一节点。\n",
         "skills": [
           "workflow-discipline"
         ],
@@ -304,13 +435,36 @@
         ],
         "sourcePreset": {
           "code": "test-integrate",
-          "version": "1.4.1",
-          "contentHash": "0f25ef16474fb990",
+          "version": "1.5.0",
+          "contentHash": "ab9d4711637b2fc3",
           "agents": [
             "test-executor",
             "code-reviewer"
           ]
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "git-worktree-clean"
+          },
+          {
+            "type": "record-base-re-merged"
+          },
+          {
+            "type": "record-test-report"
+          },
+          {
+            "type": "record-fix-review-pass"
+          },
+          {
+            "type": "record-verified-commit"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "integ-regression-chain",
+            "item": "回归范围判断链（变更清单/依赖分析/测试映射/逐级扩大或零差异证据）已写入节点记录；最终已验证版本经 record-set 写 verifiedCommit"
+          }
+        ]
       },
       {
         "id": "ACCEPT",
@@ -324,10 +478,30 @@
         "agents": [],
         "sourcePreset": {
           "code": "release-accept",
-          "version": "1.4.0",
+          "version": "1.5.0",
           "contentHash": "d9ef06ee6f469ce2",
           "agents": []
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "git-worktree-clean"
+          },
+          {
+            "type": "git-archive-merged"
+          },
+          {
+            "type": "record-prev-nodes-done"
+          },
+          {
+            "type": "record-version-consistent"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "accept-confirmation-archived",
+            "item": "位置判定结果已写入节点记录；终态形态用户确认原文与归档执行结果（merge --no-ff 回基础分支并推送）、最终提交与远程状态已留痕；非终态形态归档待办已写入且动作清单明确（归档由审批通过后执行并回写闭环）"
+          }
+        ]
       },
       {
         "id": "ARCHIVE",
@@ -343,12 +517,29 @@
         ],
         "sourcePreset": {
           "code": "archive-architecture",
-          "version": "1.4.0",
+          "version": "1.5.0",
           "contentHash": "a585464156b6179c",
           "agents": [
             "arch-info-reviewer"
           ]
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "git-worktree-clean"
+          },
+          {
+            "type": "git-stay-on-base"
+          },
+          {
+            "type": "record-final-converged"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "arch-converged",
+            "item": "架构候选过滤/独立评审结论/用户确认原文已写入节点记录；写入或不收录决定已执行并留文档引用"
+          }
+        ]
       }
     ],
     "edges": [
@@ -523,16 +714,16 @@
       }
     },
     "isDefault": false,
-    "version": "3.6.3"
+    "version": "3.6.4"
   },
   "dependencies": {
     "skills": [
       {
         "name": "workflow-discipline",
         "description": "DAG 节点执行、角色分离、授权、暂停点与任务边界纪律",
-        "content": "# workflow-discipline\n\n保证所有 DAG 节点以一致方式确定工作边界、分离执行与验证、处理授权与暂停点，并在完成判定满足后安全推进。\n\n## 铁律\n\n本 Skill 是保障 siming 流程正确执行的基础资产。执行会话加载本 Skill 后，任何上下文压缩操作一律不得压缩本 Skill 正文——它是后续所有节点判定与推进的准绳，必须完整留存在上下文中。\n\n执行会话只专注当前任务本身，不关注执行效率等其他因素；节点提示词、skill、委派 brief 中不得出现任何让 AI 转移任务注意力的描述。\n\n## 适用边界\n\n- 所有节点执行者都应用本 Skill；任务简单、用户催促或改动很小，不改变节点步骤、质量门和完成标准。\n- 本 Skill规定跨节点通用纪律，不替代当前节点提示词中的职责、产出、检查项和具体执行方法。\n- 当前节点提示词与本 Skill共同生效；发现冲突时不得自行忽略任一约束，应先按权限和任务边界判断，无法收敛再向用户呈现冲突。\n\n## 节点执行流程\n\n1. **确认当前边界**：读取任务上下文、当前节点职责、所需产出、完成判定、暂停点和项目约束。执行 git 操作前确认当前分支及项目声明的分支模型。\n2. **确定执行角色**：设计文档和编码由主会话完成；测试命令由 `test-executor` 执行；节点要求独立审查时，由不同 session 的只读 Verifier 执行。\n3. **完成节点工作**：只实施当前节点和已确认任务范围内的工作。发现死代码删留、顺手重构、范围扩张或其他范围外动作时，将其作为独立决策呈现给用户，不自行纳入。\n4. **执行独立验证**：Worker 与 Verifier 必须分离。Verifier 只接收评审目标与材料（评审对象路径、参照位置、已认定非问题的历史事项），不接收设计结论、决策理由或“用户已确认”等预设结论。\n5. **处理审查结果**：审查是否通过，以 Verifier 本次输出为准。逐条修复 finding，或记录不修复理由；修复阻塞问题后重新审查。交互式审查最多 3 轮，连续 3 轮仍未通过时，保留在当前节点并请用户决定。\n6. **检查并记录**：逐项核对当前节点的完成判定，记录实际产出、检查结果、评审结论与轮次、关键决定、不适用项及其理由。\n7. **提交节点成果**：完成判定全部满足后、推进节点前，检查工作树和 diff。存在本节点产生的应提交改动时，只纳入当前任务与当前节点范围内的代码、测试、文档等成果并创建 git commit；不得混入无关改动，也不得用空提交代替成果提交。提交失败或本节点应提交改动仍有遗漏时，留在当前节点处理。\n8. **推进节点**：确认完成判定全部满足，且本节点应提交成果已经提交后，才按节点规定推进或进入暂停点。没有应提交改动的纯审查、纯审批节点直接推进，不制造空提交。\n\n## 执行与质量边界\n\n- Track 编码节点只修改生产代码，不修改测试或其他验证代码；测试节点不得以“现有测试已经覆盖”代替逐项验证。\n- 本任务改动导致的测试失败必须完成根因调查并处理，不得标记为“既有问题”后拒绝处理，也不得通过删除测试、放宽断言或添加 skip 制造通过。\n- 预算或时间不足是暂停并上升决策的理由，不是降低质量门的理由。\n- 已知问题必须逐条判断是否影响功能完整性；影响验收的，在任务结束前处理。只有用户明确接受风险并留下原文记录，才可作为例外。\n- 增量测试或增量评审只能缩小经过证据证明的受影响范围，不得降低原有测试、审查和通过标准。\n\n## 委派纪律\n\n- Worker 与 Verifier 使用不同 session；Verifier 只读，不修改代码或文档，不接管主会话协调。\n- 增量复审聚焦本轮改动及其影响面，但沿用完整审查标准。\n- 委派 prompt 只提供评审目标与原始材料：目标 = 评什么、不评什么、主会话已认定不属于问题的历史事项；材料 = 原始需求、技术方案、代码等任务信息与信息地址（路径 / 命令 / 文档位置），怎么使用由 subagent 自行决策。目标必须精准——该评的项必须列全（不缺），不得把无关或大范围扫描类目标并入本次委派（不扩散）；评估范围由目标层锁定，评审不自行扩张到目标之外。\n- 执行策略全部由 subagent 自行决策——如何分析、如何组织报告、按什么步骤工作、何时结束，均不在 brief 中指定；主会话不设预算、轮次、时限，不给检索范围限制，不指定评估方式、不追加取证要求、不扩张评估范围；发现 agent 定义有缺陷时修正定义本身，不以委派限制替代。\n- 需要评估时按角色选择对应 reviewer，不以主会话自评替代独立评估；确无匹配 agent 时上升用户。\n- 主会话与 reviewer 结论出现明显问题或冲突时，上升人类决策；流程本身有问题时，通知人类调整流程。\n- subagent 完成指定产出后立即结束；审查修订、重新委派和多轮协调由主会话负责。\n\n## 授权与暂停点\n\n- **决策授权**只覆盖具体方案或风险选择，不自动跳过审查、复审、测试或其他流程步骤。\n- **流程授权**只覆盖用户明确指名跳过的步骤，不得扩展到其他质量门。\n- “跳过人工审批”只跳过对应的用户暂停点，不等于跳过自动审查或验证。\n- 暂停点只有用户明确肯定当前待确认内容时才算通过，并记录用户原文。用户的提问、评估、条件句或新诉求不是确认；应先回应并继续等待明确结论。\n\n## 任务完成边界\n\n- 当前节点全部完成判定满足，且本节点产生的应提交成果已经提交后，才能推进到下一节点；单项测试通过、核心代码完成、存在未提交成果或分支合并，都不能代替节点完成。没有应提交改动的节点不制造空提交。\n- 节点完成不等于任务完成。架构信息归档完成，或该步骤经用户明确授权跳过并留下记录后，任务才进入终态。\n- 任务终止前，不推荐、不询问、不切换到下一个任务；终止后再输出完整任务总结。",
+        "content": "# workflow-discipline\n\n保证所有 DAG 节点以一致方式确定工作边界、分离执行与验证、处理授权与暂停点，并在完成判定满足后安全推进。\n\n## 铁律\n\n本 Skill 是保障 siming 流程正确执行的基础资产。执行会话加载本 Skill 后，任何上下文压缩操作一律不得压缩本 Skill 正文——它是后续所有节点判定与推进的准绳，必须完整留存在上下文中。\n\n执行会话只专注当前任务本身，不关注执行效率等其他因素；节点提示词、skill、委派 brief 中不得出现任何让 AI 转移任务注意力的描述。\n\n## 适用边界\n\n- 所有节点执行者都应用本 Skill；任务简单、用户催促或改动很小，不改变节点步骤、质量门和完成标准。\n- 本 Skill规定跨节点通用纪律，不替代当前节点提示词中的职责、产出、检查项和具体执行方法。\n- 当前节点提示词与本 Skill共同生效；发现冲突时不得自行忽略任一约束，应先按权限和任务边界判断，无法收敛再向用户呈现冲突。\n\n## 节点执行流程\n\n1. **确认当前边界**：读取任务上下文、当前节点职责、所需产出、完成判定、暂停点和项目约束。执行 git 操作前确认当前分支及项目声明的分支模型。\n2. **确定执行角色**：设计文档和编码由主会话完成；测试命令由 `test-executor` 执行；节点要求独立审查时，由不同 session 的只读 Verifier 执行。\n3. **完成节点工作**：只实施当前节点和已确认任务范围内的工作。发现死代码删留、顺手重构、范围扩张或其他范围外动作时，将其作为独立决策呈现给用户，不自行纳入。\n4. **执行独立验证**：Worker 与 Verifier 必须分离。Verifier 只接收评审目标与材料（评审对象路径、参照位置、已认定非问题的历史事项），不接收设计结论、决策理由或“用户已确认”等预设结论。\n5. **处理审查结果**：审查是否通过，以 Verifier 本次输出为准。逐条修复 finding，或记录不修复理由；修复阻塞问题后重新审查。交互式审查最多 3 轮，连续 3 轮仍未通过时，保留在当前节点并请用户决定。\n6. **检查并记录**：逐项核对当前节点的完成判定，记录实际产出、检查结果、评审结论与轮次、关键决定、不适用项及其理由。\n7. **提交节点成果**：完成判定全部满足后、推进节点前，检查工作树和 diff。存在本节点产生的应提交改动时，只纳入当前任务与当前节点范围内的代码、测试、文档等成果并创建 git commit；不得混入无关改动，也不得用空提交代替成果提交。提交失败或本节点应提交改动仍有遗漏时，留在当前节点处理。\n8. **推进节点**：推进前先核对当前节点资料包的检查项——aiChecks 逐项自检并经 record-check-add 留痕（结论含核对对象与结果，不适用须记理由，refId 对应检查项 id）；随后执行 task advance，门禁打回时读失败原因与修复指引，处理完成后重推；仅用户明确指示时才可用 --force --force-reason（附用户原文），不得自行决定。没有应提交改动的纯审查、纯审批节点直接推进，不制造空提交。\n\n## 执行与质量边界\n\n- Track 编码节点只修改生产代码，不修改测试或其他验证代码；测试节点不得以“现有测试已经覆盖”代替逐项验证。\n- 本任务改动导致的测试失败必须完成根因调查并处理，不得标记为“既有问题”后拒绝处理，也不得通过删除测试、放宽断言或添加 skip 制造通过。\n- 预算或时间不足是暂停并上升决策的理由，不是降低质量门的理由。\n- 已知问题必须逐条判断是否影响功能完整性；影响验收的，在任务结束前处理。只有用户明确接受风险并留下原文记录，才可作为例外。\n- 增量测试或增量评审只能缩小经过证据证明的受影响范围，不得降低原有测试、审查和通过标准。\n\n## 委派纪律\n\n- Worker 与 Verifier 使用不同 session；Verifier 只读，不修改代码或文档，不接管主会话协调。\n- 增量复审聚焦本轮改动及其影响面，但沿用完整审查标准。\n- 委派 prompt 只提供评审目标与原始材料：目标 = 评什么、不评什么、主会话已认定不属于问题的历史事项；材料 = 原始需求、技术方案、代码等任务信息与信息地址（路径 / 命令 / 文档位置），怎么使用由 subagent 自行决策。目标必须精准——该评的项必须列全（不缺），不得把无关或大范围扫描类目标并入本次委派（不扩散）；评估范围由目标层锁定，评审不自行扩张到目标之外。\n- 执行策略全部由 subagent 自行决策——如何分析、如何组织报告、按什么步骤工作、何时结束，均不在 brief 中指定；主会话不设预算、轮次、时限，不给检索范围限制，不指定评估方式、不追加取证要求、不扩张评估范围；发现 agent 定义有缺陷时修正定义本身，不以委派限制替代。\n- 需要评估时按角色选择对应 reviewer，不以主会话自评替代独立评估；确无匹配 agent 时上升用户。\n- 主会话与 reviewer 结论出现明显问题或冲突时，上升人类决策；流程本身有问题时，通知人类调整流程。\n- subagent 完成指定产出后立即结束；审查修订、重新委派和多轮协调由主会话负责。\n\n## 授权与暂停点\n\n- **决策授权**只覆盖具体方案或风险选择，不自动跳过审查、复审、测试或其他流程步骤。\n- **流程授权**只覆盖用户明确指名跳过的步骤，不得扩展到其他质量门。\n- “跳过人工审批”只跳过对应的用户暂停点，不等于跳过自动审查或验证。\n- 暂停点只有用户明确肯定当前待确认内容时才算通过，并记录用户原文。用户的提问、评估、条件句或新诉求不是确认；应先回应并继续等待明确结论。\n\n## 任务完成边界\n\n- 当前节点全部完成判定满足，且本节点产生的应提交成果已经提交后，才能推进到下一节点；单项测试通过、核心代码完成、存在未提交成果或分支合并，都不能代替节点完成。没有应提交改动的节点不制造空提交。\n- 节点完成不等于任务完成。架构信息归档完成，或该步骤经用户明确授权跳过并留下记录后，任务才进入终态。\n- 任务终止前，不推荐、不询问、不切换到下一个任务；终止后再输出完整任务总结。",
         "category": "process",
-        "version": "1.3.0",
+        "version": "1.4.0",
         "references": [],
         "scope": "global"
       },

package/templates/builtin/quick_workflow.bundle.json

@@ -1,6 +1,6 @@
 {
   "exportFormatVersion": "1.0",
-  "exportedAt": "2026-09-23T10:30:51.118Z",
+  "exportedAt": "2026-09-26T15:30:41.841Z",
   "warnings": [],
   "template": {
     "name": "quick_workflow",
@@ -11,17 +11,31 @@
         "label": "分支对齐",
         "phase": "entry",
         "track": "all",
-        "prompt": "# 分支对齐\n\n## 节点职责\n\n在后续工作开始前，确认是否需要合并基础分支的远程最新代码。\n\n## 依赖信息\n\n检查当前任务上下文和项目提示词，从中解析基础分支，例如 `main`、`master` 或 `dev`。按名称加载 `workflow-discipline` Skill。\n\n## 正向执行流程\n\n1. 能解析出基础分支时，获取并合并该分支的远程最新代码。\n2. 无法解析时，询问用户是否需要合并某个分支的远程代码。\n3. 用户指定分支后执行合并；用户明确表示不需要时，直接推进下一节点。\n\n## 产出检查\n\n推进前确认：基础分支的远程代码已成功合并，或者用户已明确表示不需要合并。\n\n## 任务差异处理\n\n没有远程仓库或用户不要求合并时，记录不执行的事实和理由。合并发生冲突且无法可靠解决时，保留在当前节点并向用户说明。\n\n## 节点记录与推进\n\n记录基础分支、合并结果，或不执行合并的理由，然后推进下一节点。",
+        "prompt": "# 分支对齐\n\n## 节点职责\n\n在后续工作开始前，确认是否需要合并基础分支的远程最新代码。\n\n## 依赖信息\n\n检查当前任务上下文和项目提示词，从中解析基础分支，例如 `main`、`master` 或 `dev`。按名称加载 `workflow-discipline` Skill。\n\n## 正向执行流程\n\n1. 能解析出基础分支时，获取并合并该分支的远程最新代码。\n2. 无法解析时，询问用户是否需要合并某个分支的远程代码。\n3. 用户指定分支后执行合并；用户明确表示不需要时，直接推进下一节点。\n\n## 产出检查\n\n推进前确认：基础分支的远程代码已成功合并，或者用户已明确表示不需要合并。\n\n## 任务差异处理\n\n没有远程仓库或用户不要求合并时，记录不执行的事实和理由。合并发生冲突且无法可靠解决时，保留在当前节点并向用户说明。\n\n## 节点记录与推进\n\n将基础分支经 record-set 结构化写入 baseBranch 字段（后续节点门禁的参数解析链依赖该值）；记录合并结果，或不执行合并的理由，然后推进下一节点。",
         "skills": [
           "workflow-discipline"
         ],
         "agents": [],
         "sourcePreset": {
           "code": "align-branch",
-          "version": "1.3.0",
-          "contentHash": "ffba197df7edb043",
+          "version": "1.4.0",
+          "contentHash": "1f0f21110ce062f9",
           "agents": []
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "git-base-recorded"
+          },
+          {
+            "type": "git-base-merged"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "align-merge-or-waive",
+            "item": "基础分支远程最新代码已合并入当前分支；用户明示不需合并时已写 decisions（topic=merge-waived）并附用户原话"
+          }
+        ]
       },
       {
         "id": "DESIGN",
@@ -99,7 +113,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. 回归执行决策由「是否执行」与「执行什么」两半构成，每一半都必须由证据支撑，禁止无分析的保守回退：\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",
+        "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将基础分支来源、同步策略与结果、任务和远程版本、冲突处理、适用测试层级、回归范围判断链（变更清单、依赖分析、测试映射、逐级扩大证据、零差异证据绑定）及结论、实际命令与统计、失败根因和修复、完整性检查、代码评审结果、日志与报告引用、最终已验证版本（经 record-set 结构化写入 verifiedCommit 字段；本轮发生修复时经 record-set 写入 fixesApplied 次数）写入当前节点记录。完成上述检查后推进下一节点。\n",
         "skills": [
           "workflow-discipline"
         ],
@@ -109,13 +123,36 @@
         ],
         "sourcePreset": {
           "code": "test-integrate",
-          "version": "1.4.1",
-          "contentHash": "0f25ef16474fb990",
+          "version": "1.5.0",
+          "contentHash": "ab9d4711637b2fc3",
           "agents": [
             "test-executor",
             "code-reviewer"
           ]
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "git-worktree-clean"
+          },
+          {
+            "type": "record-base-re-merged"
+          },
+          {
+            "type": "record-test-report"
+          },
+          {
+            "type": "record-fix-review-pass"
+          },
+          {
+            "type": "record-verified-commit"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "integ-regression-chain",
+            "item": "回归范围判断链（变更清单/依赖分析/测试映射/逐级扩大或零差异证据）已写入节点记录；最终已验证版本经 record-set 写 verifiedCommit"
+          }
+        ]
       },
       {
         "id": "ACCEPT",
@@ -129,10 +166,30 @@
         "agents": [],
         "sourcePreset": {
           "code": "release-accept",
-          "version": "1.4.0",
+          "version": "1.5.0",
           "contentHash": "d9ef06ee6f469ce2",
           "agents": []
-        }
+        },
+        "toolChecks": [
+          {
+            "type": "git-worktree-clean"
+          },
+          {
+            "type": "git-archive-merged"
+          },
+          {
+            "type": "record-prev-nodes-done"
+          },
+          {
+            "type": "record-version-consistent"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "accept-confirmation-archived",
+            "item": "位置判定结果已写入节点记录；终态形态用户确认原文与归档执行结果（merge --no-ff 回基础分支并推送）、最终提交与远程状态已留痕；非终态形态归档待办已写入且动作清单明确（归档由审批通过后执行并回写闭环）"
+          }
+        ]
       }
     ],
     "edges": [
@@ -176,16 +233,16 @@
       }
     ],
     "isDefault": false,
-    "version": "2.0.5"
+    "version": "2.0.6"
   },
   "dependencies": {
     "skills": [
       {
         "name": "workflow-discipline",
         "description": "DAG 节点执行、角色分离、授权、暂停点与任务边界纪律",
-        "content": "# workflow-discipline\n\n保证所有 DAG 节点以一致方式确定工作边界、分离执行与验证、处理授权与暂停点，并在完成判定满足后安全推进。\n\n## 铁律\n\n本 Skill 是保障 siming 流程正确执行的基础资产。执行会话加载本 Skill 后，任何上下文压缩操作一律不得压缩本 Skill 正文——它是后续所有节点判定与推进的准绳，必须完整留存在上下文中。\n\n执行会话只专注当前任务本身，不关注执行效率等其他因素；节点提示词、skill、委派 brief 中不得出现任何让 AI 转移任务注意力的描述。\n\n## 适用边界\n\n- 所有节点执行者都应用本 Skill；任务简单、用户催促或改动很小，不改变节点步骤、质量门和完成标准。\n- 本 Skill规定跨节点通用纪律，不替代当前节点提示词中的职责、产出、检查项和具体执行方法。\n- 当前节点提示词与本 Skill共同生效；发现冲突时不得自行忽略任一约束，应先按权限和任务边界判断，无法收敛再向用户呈现冲突。\n\n## 节点执行流程\n\n1. **确认当前边界**：读取任务上下文、当前节点职责、所需产出、完成判定、暂停点和项目约束。执行 git 操作前确认当前分支及项目声明的分支模型。\n2. **确定执行角色**：设计文档和编码由主会话完成；测试命令由 `test-executor` 执行；节点要求独立审查时，由不同 session 的只读 Verifier 执行。\n3. **完成节点工作**：只实施当前节点和已确认任务范围内的工作。发现死代码删留、顺手重构、范围扩张或其他范围外动作时，将其作为独立决策呈现给用户，不自行纳入。\n4. **执行独立验证**：Worker 与 Verifier 必须分离。Verifier 只接收评审目标与材料（评审对象路径、参照位置、已认定非问题的历史事项），不接收设计结论、决策理由或“用户已确认”等预设结论。\n5. **处理审查结果**：审查是否通过，以 Verifier 本次输出为准。逐条修复 finding，或记录不修复理由；修复阻塞问题后重新审查。交互式审查最多 3 轮，连续 3 轮仍未通过时，保留在当前节点并请用户决定。\n6. **检查并记录**：逐项核对当前节点的完成判定，记录实际产出、检查结果、评审结论与轮次、关键决定、不适用项及其理由。\n7. **提交节点成果**：完成判定全部满足后、推进节点前，检查工作树和 diff。存在本节点产生的应提交改动时，只纳入当前任务与当前节点范围内的代码、测试、文档等成果并创建 git commit；不得混入无关改动，也不得用空提交代替成果提交。提交失败或本节点应提交改动仍有遗漏时，留在当前节点处理。\n8. **推进节点**：确认完成判定全部满足，且本节点应提交成果已经提交后，才按节点规定推进或进入暂停点。没有应提交改动的纯审查、纯审批节点直接推进，不制造空提交。\n\n## 执行与质量边界\n\n- Track 编码节点只修改生产代码，不修改测试或其他验证代码；测试节点不得以“现有测试已经覆盖”代替逐项验证。\n- 本任务改动导致的测试失败必须完成根因调查并处理，不得标记为“既有问题”后拒绝处理，也不得通过删除测试、放宽断言或添加 skip 制造通过。\n- 预算或时间不足是暂停并上升决策的理由，不是降低质量门的理由。\n- 已知问题必须逐条判断是否影响功能完整性；影响验收的，在任务结束前处理。只有用户明确接受风险并留下原文记录，才可作为例外。\n- 增量测试或增量评审只能缩小经过证据证明的受影响范围，不得降低原有测试、审查和通过标准。\n\n## 委派纪律\n\n- Worker 与 Verifier 使用不同 session；Verifier 只读，不修改代码或文档，不接管主会话协调。\n- 增量复审聚焦本轮改动及其影响面，但沿用完整审查标准。\n- 委派 prompt 只提供评审目标与原始材料：目标 = 评什么、不评什么、主会话已认定不属于问题的历史事项；材料 = 原始需求、技术方案、代码等任务信息与信息地址（路径 / 命令 / 文档位置），怎么使用由 subagent 自行决策。目标必须精准——该评的项必须列全（不缺），不得把无关或大范围扫描类目标并入本次委派（不扩散）；评估范围由目标层锁定，评审不自行扩张到目标之外。\n- 执行策略全部由 subagent 自行决策——如何分析、如何组织报告、按什么步骤工作、何时结束，均不在 brief 中指定；主会话不设预算、轮次、时限，不给检索范围限制，不指定评估方式、不追加取证要求、不扩张评估范围；发现 agent 定义有缺陷时修正定义本身，不以委派限制替代。\n- 需要评估时按角色选择对应 reviewer，不以主会话自评替代独立评估；确无匹配 agent 时上升用户。\n- 主会话与 reviewer 结论出现明显问题或冲突时，上升人类决策；流程本身有问题时，通知人类调整流程。\n- subagent 完成指定产出后立即结束；审查修订、重新委派和多轮协调由主会话负责。\n\n## 授权与暂停点\n\n- **决策授权**只覆盖具体方案或风险选择，不自动跳过审查、复审、测试或其他流程步骤。\n- **流程授权**只覆盖用户明确指名跳过的步骤，不得扩展到其他质量门。\n- “跳过人工审批”只跳过对应的用户暂停点，不等于跳过自动审查或验证。\n- 暂停点只有用户明确肯定当前待确认内容时才算通过，并记录用户原文。用户的提问、评估、条件句或新诉求不是确认；应先回应并继续等待明确结论。\n\n## 任务完成边界\n\n- 当前节点全部完成判定满足，且本节点产生的应提交成果已经提交后，才能推进到下一节点；单项测试通过、核心代码完成、存在未提交成果或分支合并，都不能代替节点完成。没有应提交改动的节点不制造空提交。\n- 节点完成不等于任务完成。架构信息归档完成，或该步骤经用户明确授权跳过并留下记录后，任务才进入终态。\n- 任务终止前，不推荐、不询问、不切换到下一个任务；终止后再输出完整任务总结。",
+        "content": "# workflow-discipline\n\n保证所有 DAG 节点以一致方式确定工作边界、分离执行与验证、处理授权与暂停点，并在完成判定满足后安全推进。\n\n## 铁律\n\n本 Skill 是保障 siming 流程正确执行的基础资产。执行会话加载本 Skill 后，任何上下文压缩操作一律不得压缩本 Skill 正文——它是后续所有节点判定与推进的准绳，必须完整留存在上下文中。\n\n执行会话只专注当前任务本身，不关注执行效率等其他因素；节点提示词、skill、委派 brief 中不得出现任何让 AI 转移任务注意力的描述。\n\n## 适用边界\n\n- 所有节点执行者都应用本 Skill；任务简单、用户催促或改动很小，不改变节点步骤、质量门和完成标准。\n- 本 Skill规定跨节点通用纪律，不替代当前节点提示词中的职责、产出、检查项和具体执行方法。\n- 当前节点提示词与本 Skill共同生效；发现冲突时不得自行忽略任一约束，应先按权限和任务边界判断，无法收敛再向用户呈现冲突。\n\n## 节点执行流程\n\n1. **确认当前边界**：读取任务上下文、当前节点职责、所需产出、完成判定、暂停点和项目约束。执行 git 操作前确认当前分支及项目声明的分支模型。\n2. **确定执行角色**：设计文档和编码由主会话完成；测试命令由 `test-executor` 执行；节点要求独立审查时，由不同 session 的只读 Verifier 执行。\n3. **完成节点工作**：只实施当前节点和已确认任务范围内的工作。发现死代码删留、顺手重构、范围扩张或其他范围外动作时，将其作为独立决策呈现给用户，不自行纳入。\n4. **执行独立验证**：Worker 与 Verifier 必须分离。Verifier 只接收评审目标与材料（评审对象路径、参照位置、已认定非问题的历史事项），不接收设计结论、决策理由或“用户已确认”等预设结论。\n5. **处理审查结果**：审查是否通过，以 Verifier 本次输出为准。逐条修复 finding，或记录不修复理由；修复阻塞问题后重新审查。交互式审查最多 3 轮，连续 3 轮仍未通过时，保留在当前节点并请用户决定。\n6. **检查并记录**：逐项核对当前节点的完成判定，记录实际产出、检查结果、评审结论与轮次、关键决定、不适用项及其理由。\n7. **提交节点成果**：完成判定全部满足后、推进节点前，检查工作树和 diff。存在本节点产生的应提交改动时，只纳入当前任务与当前节点范围内的代码、测试、文档等成果并创建 git commit；不得混入无关改动，也不得用空提交代替成果提交。提交失败或本节点应提交改动仍有遗漏时，留在当前节点处理。\n8. **推进节点**：推进前先核对当前节点资料包的检查项——aiChecks 逐项自检并经 record-check-add 留痕（结论含核对对象与结果，不适用须记理由，refId 对应检查项 id）；随后执行 task advance，门禁打回时读失败原因与修复指引，处理完成后重推；仅用户明确指示时才可用 --force --force-reason（附用户原文），不得自行决定。没有应提交改动的纯审查、纯审批节点直接推进，不制造空提交。\n\n## 执行与质量边界\n\n- Track 编码节点只修改生产代码，不修改测试或其他验证代码；测试节点不得以“现有测试已经覆盖”代替逐项验证。\n- 本任务改动导致的测试失败必须完成根因调查并处理，不得标记为“既有问题”后拒绝处理，也不得通过删除测试、放宽断言或添加 skip 制造通过。\n- 预算或时间不足是暂停并上升决策的理由，不是降低质量门的理由。\n- 已知问题必须逐条判断是否影响功能完整性；影响验收的，在任务结束前处理。只有用户明确接受风险并留下原文记录，才可作为例外。\n- 增量测试或增量评审只能缩小经过证据证明的受影响范围，不得降低原有测试、审查和通过标准。\n\n## 委派纪律\n\n- Worker 与 Verifier 使用不同 session；Verifier 只读，不修改代码或文档，不接管主会话协调。\n- 增量复审聚焦本轮改动及其影响面，但沿用完整审查标准。\n- 委派 prompt 只提供评审目标与原始材料：目标 = 评什么、不评什么、主会话已认定不属于问题的历史事项；材料 = 原始需求、技术方案、代码等任务信息与信息地址（路径 / 命令 / 文档位置），怎么使用由 subagent 自行决策。目标必须精准——该评的项必须列全（不缺），不得把无关或大范围扫描类目标并入本次委派（不扩散）；评估范围由目标层锁定，评审不自行扩张到目标之外。\n- 执行策略全部由 subagent 自行决策——如何分析、如何组织报告、按什么步骤工作、何时结束，均不在 brief 中指定；主会话不设预算、轮次、时限，不给检索范围限制，不指定评估方式、不追加取证要求、不扩张评估范围；发现 agent 定义有缺陷时修正定义本身，不以委派限制替代。\n- 需要评估时按角色选择对应 reviewer，不以主会话自评替代独立评估；确无匹配 agent 时上升用户。\n- 主会话与 reviewer 结论出现明显问题或冲突时，上升人类决策；流程本身有问题时，通知人类调整流程。\n- subagent 完成指定产出后立即结束；审查修订、重新委派和多轮协调由主会话负责。\n\n## 授权与暂停点\n\n- **决策授权**只覆盖具体方案或风险选择，不自动跳过审查、复审、测试或其他流程步骤。\n- **流程授权**只覆盖用户明确指名跳过的步骤，不得扩展到其他质量门。\n- “跳过人工审批”只跳过对应的用户暂停点，不等于跳过自动审查或验证。\n- 暂停点只有用户明确肯定当前待确认内容时才算通过，并记录用户原文。用户的提问、评估、条件句或新诉求不是确认；应先回应并继续等待明确结论。\n\n## 任务完成边界\n\n- 当前节点全部完成判定满足，且本节点产生的应提交成果已经提交后，才能推进到下一节点；单项测试通过、核心代码完成、存在未提交成果或分支合并，都不能代替节点完成。没有应提交改动的节点不制造空提交。\n- 节点完成不等于任务完成。架构信息归档完成，或该步骤经用户明确授权跳过并留下记录后，任务才进入终态。\n- 任务终止前，不推荐、不询问、不切换到下一个任务；终止后再输出完整任务总结。",
         "category": "process",
-        "version": "1.3.0",
+        "version": "1.4.0",
         "references": [],
         "scope": "global"
       },

package/templates/builtin/research_workflow.bundle.json

@@ -1,6 +1,6 @@
 {
   "exportFormatVersion": "1.0",
-  "exportedAt": "2026-09-23T10:30:51.116Z",
+  "exportedAt": "2026-09-26T15:30:41.838Z",
   "warnings": [],
   "template": {
     "name": "research_workflow",
@@ -95,9 +95,9 @@
       {
         "name": "workflow-discipline",
         "description": "DAG 节点执行、角色分离、授权、暂停点与任务边界纪律",
-        "content": "# workflow-discipline\n\n保证所有 DAG 节点以一致方式确定工作边界、分离执行与验证、处理授权与暂停点，并在完成判定满足后安全推进。\n\n## 铁律\n\n本 Skill 是保障 siming 流程正确执行的基础资产。执行会话加载本 Skill 后，任何上下文压缩操作一律不得压缩本 Skill 正文——它是后续所有节点判定与推进的准绳，必须完整留存在上下文中。\n\n执行会话只专注当前任务本身，不关注执行效率等其他因素；节点提示词、skill、委派 brief 中不得出现任何让 AI 转移任务注意力的描述。\n\n## 适用边界\n\n- 所有节点执行者都应用本 Skill；任务简单、用户催促或改动很小，不改变节点步骤、质量门和完成标准。\n- 本 Skill规定跨节点通用纪律，不替代当前节点提示词中的职责、产出、检查项和具体执行方法。\n- 当前节点提示词与本 Skill共同生效；发现冲突时不得自行忽略任一约束，应先按权限和任务边界判断，无法收敛再向用户呈现冲突。\n\n## 节点执行流程\n\n1. **确认当前边界**：读取任务上下文、当前节点职责、所需产出、完成判定、暂停点和项目约束。执行 git 操作前确认当前分支及项目声明的分支模型。\n2. **确定执行角色**：设计文档和编码由主会话完成；测试命令由 `test-executor` 执行；节点要求独立审查时，由不同 session 的只读 Verifier 执行。\n3. **完成节点工作**：只实施当前节点和已确认任务范围内的工作。发现死代码删留、顺手重构、范围扩张或其他范围外动作时，将其作为独立决策呈现给用户，不自行纳入。\n4. **执行独立验证**：Worker 与 Verifier 必须分离。Verifier 只接收评审目标与材料（评审对象路径、参照位置、已认定非问题的历史事项），不接收设计结论、决策理由或“用户已确认”等预设结论。\n5. **处理审查结果**：审查是否通过，以 Verifier 本次输出为准。逐条修复 finding，或记录不修复理由；修复阻塞问题后重新审查。交互式审查最多 3 轮，连续 3 轮仍未通过时，保留在当前节点并请用户决定。\n6. **检查并记录**：逐项核对当前节点的完成判定，记录实际产出、检查结果、评审结论与轮次、关键决定、不适用项及其理由。\n7. **提交节点成果**：完成判定全部满足后、推进节点前，检查工作树和 diff。存在本节点产生的应提交改动时，只纳入当前任务与当前节点范围内的代码、测试、文档等成果并创建 git commit；不得混入无关改动，也不得用空提交代替成果提交。提交失败或本节点应提交改动仍有遗漏时，留在当前节点处理。\n8. **推进节点**：确认完成判定全部满足，且本节点应提交成果已经提交后，才按节点规定推进或进入暂停点。没有应提交改动的纯审查、纯审批节点直接推进，不制造空提交。\n\n## 执行与质量边界\n\n- Track 编码节点只修改生产代码，不修改测试或其他验证代码；测试节点不得以“现有测试已经覆盖”代替逐项验证。\n- 本任务改动导致的测试失败必须完成根因调查并处理，不得标记为“既有问题”后拒绝处理，也不得通过删除测试、放宽断言或添加 skip 制造通过。\n- 预算或时间不足是暂停并上升决策的理由，不是降低质量门的理由。\n- 已知问题必须逐条判断是否影响功能完整性；影响验收的，在任务结束前处理。只有用户明确接受风险并留下原文记录，才可作为例外。\n- 增量测试或增量评审只能缩小经过证据证明的受影响范围，不得降低原有测试、审查和通过标准。\n\n## 委派纪律\n\n- Worker 与 Verifier 使用不同 session；Verifier 只读，不修改代码或文档，不接管主会话协调。\n- 增量复审聚焦本轮改动及其影响面，但沿用完整审查标准。\n- 委派 prompt 只提供评审目标与原始材料：目标 = 评什么、不评什么、主会话已认定不属于问题的历史事项；材料 = 原始需求、技术方案、代码等任务信息与信息地址（路径 / 命令 / 文档位置），怎么使用由 subagent 自行决策。目标必须精准——该评的项必须列全（不缺），不得把无关或大范围扫描类目标并入本次委派（不扩散）；评估范围由目标层锁定，评审不自行扩张到目标之外。\n- 执行策略全部由 subagent 自行决策——如何分析、如何组织报告、按什么步骤工作、何时结束，均不在 brief 中指定；主会话不设预算、轮次、时限，不给检索范围限制，不指定评估方式、不追加取证要求、不扩张评估范围；发现 agent 定义有缺陷时修正定义本身，不以委派限制替代。\n- 需要评估时按角色选择对应 reviewer，不以主会话自评替代独立评估；确无匹配 agent 时上升用户。\n- 主会话与 reviewer 结论出现明显问题或冲突时，上升人类决策；流程本身有问题时，通知人类调整流程。\n- subagent 完成指定产出后立即结束；审查修订、重新委派和多轮协调由主会话负责。\n\n## 授权与暂停点\n\n- **决策授权**只覆盖具体方案或风险选择，不自动跳过审查、复审、测试或其他流程步骤。\n- **流程授权**只覆盖用户明确指名跳过的步骤，不得扩展到其他质量门。\n- “跳过人工审批”只跳过对应的用户暂停点，不等于跳过自动审查或验证。\n- 暂停点只有用户明确肯定当前待确认内容时才算通过，并记录用户原文。用户的提问、评估、条件句或新诉求不是确认；应先回应并继续等待明确结论。\n\n## 任务完成边界\n\n- 当前节点全部完成判定满足，且本节点产生的应提交成果已经提交后，才能推进到下一节点；单项测试通过、核心代码完成、存在未提交成果或分支合并，都不能代替节点完成。没有应提交改动的节点不制造空提交。\n- 节点完成不等于任务完成。架构信息归档完成，或该步骤经用户明确授权跳过并留下记录后，任务才进入终态。\n- 任务终止前，不推荐、不询问、不切换到下一个任务；终止后再输出完整任务总结。",
+        "content": "# workflow-discipline\n\n保证所有 DAG 节点以一致方式确定工作边界、分离执行与验证、处理授权与暂停点，并在完成判定满足后安全推进。\n\n## 铁律\n\n本 Skill 是保障 siming 流程正确执行的基础资产。执行会话加载本 Skill 后，任何上下文压缩操作一律不得压缩本 Skill 正文——它是后续所有节点判定与推进的准绳，必须完整留存在上下文中。\n\n执行会话只专注当前任务本身，不关注执行效率等其他因素；节点提示词、skill、委派 brief 中不得出现任何让 AI 转移任务注意力的描述。\n\n## 适用边界\n\n- 所有节点执行者都应用本 Skill；任务简单、用户催促或改动很小，不改变节点步骤、质量门和完成标准。\n- 本 Skill规定跨节点通用纪律，不替代当前节点提示词中的职责、产出、检查项和具体执行方法。\n- 当前节点提示词与本 Skill共同生效；发现冲突时不得自行忽略任一约束，应先按权限和任务边界判断，无法收敛再向用户呈现冲突。\n\n## 节点执行流程\n\n1. **确认当前边界**：读取任务上下文、当前节点职责、所需产出、完成判定、暂停点和项目约束。执行 git 操作前确认当前分支及项目声明的分支模型。\n2. **确定执行角色**：设计文档和编码由主会话完成；测试命令由 `test-executor` 执行；节点要求独立审查时，由不同 session 的只读 Verifier 执行。\n3. **完成节点工作**：只实施当前节点和已确认任务范围内的工作。发现死代码删留、顺手重构、范围扩张或其他范围外动作时，将其作为独立决策呈现给用户，不自行纳入。\n4. **执行独立验证**：Worker 与 Verifier 必须分离。Verifier 只接收评审目标与材料（评审对象路径、参照位置、已认定非问题的历史事项），不接收设计结论、决策理由或“用户已确认”等预设结论。\n5. **处理审查结果**：审查是否通过，以 Verifier 本次输出为准。逐条修复 finding，或记录不修复理由；修复阻塞问题后重新审查。交互式审查最多 3 轮，连续 3 轮仍未通过时，保留在当前节点并请用户决定。\n6. **检查并记录**：逐项核对当前节点的完成判定，记录实际产出、检查结果、评审结论与轮次、关键决定、不适用项及其理由。\n7. **提交节点成果**：完成判定全部满足后、推进节点前，检查工作树和 diff。存在本节点产生的应提交改动时，只纳入当前任务与当前节点范围内的代码、测试、文档等成果并创建 git commit；不得混入无关改动，也不得用空提交代替成果提交。提交失败或本节点应提交改动仍有遗漏时，留在当前节点处理。\n8. **推进节点**：推进前先核对当前节点资料包的检查项——aiChecks 逐项自检并经 record-check-add 留痕（结论含核对对象与结果，不适用须记理由，refId 对应检查项 id）；随后执行 task advance，门禁打回时读失败原因与修复指引，处理完成后重推；仅用户明确指示时才可用 --force --force-reason（附用户原文），不得自行决定。没有应提交改动的纯审查、纯审批节点直接推进，不制造空提交。\n\n## 执行与质量边界\n\n- Track 编码节点只修改生产代码，不修改测试或其他验证代码；测试节点不得以“现有测试已经覆盖”代替逐项验证。\n- 本任务改动导致的测试失败必须完成根因调查并处理，不得标记为“既有问题”后拒绝处理，也不得通过删除测试、放宽断言或添加 skip 制造通过。\n- 预算或时间不足是暂停并上升决策的理由，不是降低质量门的理由。\n- 已知问题必须逐条判断是否影响功能完整性；影响验收的，在任务结束前处理。只有用户明确接受风险并留下原文记录，才可作为例外。\n- 增量测试或增量评审只能缩小经过证据证明的受影响范围，不得降低原有测试、审查和通过标准。\n\n## 委派纪律\n\n- Worker 与 Verifier 使用不同 session；Verifier 只读，不修改代码或文档，不接管主会话协调。\n- 增量复审聚焦本轮改动及其影响面，但沿用完整审查标准。\n- 委派 prompt 只提供评审目标与原始材料：目标 = 评什么、不评什么、主会话已认定不属于问题的历史事项；材料 = 原始需求、技术方案、代码等任务信息与信息地址（路径 / 命令 / 文档位置），怎么使用由 subagent 自行决策。目标必须精准——该评的项必须列全（不缺），不得把无关或大范围扫描类目标并入本次委派（不扩散）；评估范围由目标层锁定，评审不自行扩张到目标之外。\n- 执行策略全部由 subagent 自行决策——如何分析、如何组织报告、按什么步骤工作、何时结束，均不在 brief 中指定；主会话不设预算、轮次、时限，不给检索范围限制，不指定评估方式、不追加取证要求、不扩张评估范围；发现 agent 定义有缺陷时修正定义本身，不以委派限制替代。\n- 需要评估时按角色选择对应 reviewer，不以主会话自评替代独立评估；确无匹配 agent 时上升用户。\n- 主会话与 reviewer 结论出现明显问题或冲突时，上升人类决策；流程本身有问题时，通知人类调整流程。\n- subagent 完成指定产出后立即结束；审查修订、重新委派和多轮协调由主会话负责。\n\n## 授权与暂停点\n\n- **决策授权**只覆盖具体方案或风险选择，不自动跳过审查、复审、测试或其他流程步骤。\n- **流程授权**只覆盖用户明确指名跳过的步骤，不得扩展到其他质量门。\n- “跳过人工审批”只跳过对应的用户暂停点，不等于跳过自动审查或验证。\n- 暂停点只有用户明确肯定当前待确认内容时才算通过，并记录用户原文。用户的提问、评估、条件句或新诉求不是确认；应先回应并继续等待明确结论。\n\n## 任务完成边界\n\n- 当前节点全部完成判定满足，且本节点产生的应提交成果已经提交后，才能推进到下一节点；单项测试通过、核心代码完成、存在未提交成果或分支合并，都不能代替节点完成。没有应提交改动的节点不制造空提交。\n- 节点完成不等于任务完成。架构信息归档完成，或该步骤经用户明确授权跳过并留下记录后，任务才进入终态。\n- 任务终止前，不推荐、不询问、不切换到下一个任务；终止后再输出完整任务总结。",
         "category": "process",
-        "version": "1.3.0",
+        "version": "1.4.0",
         "references": [],
         "scope": "global"
       }