@siming-org/cli 0.8.15 → 0.8.16

package/dist/index.js

@@ -838,6 +838,9 @@ function naIfRepoUnavailable(ctx) {
 function na(reason) {
   return { type: "", status: "not_applicable", detail: reason };
 }
+function hasSuccessorNode(ctx) {
+  return (ctx.edges ?? []).some((e) => e.from === ctx.nodeId);
+}
 function fail2(ctx, type, rootCause, fix) {
   return { type, status: "fail", detail: `${rootCause}\u3002\u4FEE\u590D\uFF1A${fix}\uFF08\u5F53\u524D nodeId=${ctx.nodeId}\uFF09` };
 }
@@ -921,8 +924,7 @@ async function checkArchiveMerged(ctx) {
   if (ctx.vcs.archiveToBase === false) {
     return { type, status: "not_applicable", detail: "\u9879\u76EE vcs.archiveToBase=false\uFF08\u58F0\u660E\u65E0\u5F52\u6863\u5408\u5E76\u6D41\u7A0B\uFF09" };
   }
-  const hasSuccessor = (ctx.edges ?? []).some((e) => e.from === ctx.nodeId);
-  if (hasSuccessor) {
+  if (hasSuccessorNode(ctx)) {
     return {
       type,
       status: "not_applicable",
@@ -933,31 +935,92 @@ async function checkArchiveMerged(ctx) {
     return fail2(ctx, type, "\u57FA\u7840\u5206\u652F\u672A\u77E5\uFF08ACCEPT \u524D\u7F6E\uFF1AALIGN \u5E94\u5DF2\u843D\u76D8 baseBranch\uFF09", "record-set \u5199 ALIGN.baseBranch\uFF0C\u6216 siming project update --vcs-base-branch <\u5206\u652F>");
   }
   const base = ctx.baseBranch;
-  return perRepoCheck(ctx, type, async (repo) => {
-    const count = await ctx.runGit(["rev-list", "--count", `${base}..HEAD`], repo);
-    if (count.ok && count.stdout.trim() === "0") {
-      return { status: "not_applicable", detail: `\u4EFB\u52A1\u5206\u652F\u76F8\u5BF9 ${base} \u96F6\u63D0\u4EA4\uFF08\u65E0\u4EE3\u7801\u6539\u52A8\uFF0C\u65E0\u9700\u5408\u5E76\uFF09` };
-    }
-    const fetch2 = await ctx.runGit(["fetch", "origin", base], repo);
-    if (!fetch2.ok) {
-      return { status: "fail", detail: `git fetch origin ${base} \u5931\u8D25\u2014\u2014\u672C\u5730\u4E0E\u8FDC\u7A0B\u4E00\u81F4\u6027\u65E0\u4ECE\u5224\u5B9A\uFF08\u62D2\u6309\u9648\u65E7 ref \u8BEF\u5224\uFF09\uFF1B\u68C0\u67E5\u7F51\u7EDC/\u8FDC\u7A0B\u53EF\u8FBE\u540E\u91CD\u8BD5` };
-    }
-    const ancestor = await ctx.runGit(["merge-base", "--is-ancestor", "HEAD", base], repo);
-    if (!ancestor.ok) {
-      return { status: "fail", detail: `\u57FA\u7840\u5206\u652F ${base} \u5C1A\u672A\u5305\u542B\u4EFB\u52A1\u5206\u652F HEAD\uFF08\u672A\u5408\u5E76\uFF09\u2014\u2014git checkout ${base} && git merge --no-ff <\u4EFB\u52A1\u5206\u652F> && git push` };
-    }
-    const merges = await ctx.runGit(["log", "--merges", "-1", "--format=%P", base], repo);
-    const parents = merges.ok ? merges.stdout.trim().split(/\s+/) : [];
-    if (parents.length !== 2) {
-      return { status: "fail", detail: `\u672A\u68C0\u6D4B\u5230 --no-ff \u5408\u5E76\u63D0\u4EA4\uFF08\u6700\u8FD1\u4E00\u6B21\u5408\u5E76 parents=${parents.length}\uFF09\u2014\u2014\u5408\u5E76\u5FC5\u987B\u4F7F\u7528 --no-ff\uFF08\u4FDD\u7559\u5408\u5E76\u8BB0\u5F55\uFF09` };
+  let anchorModeRepos = 0;
+  let anchorHitRepos = 0;
+  const anchorMissRepos = [];
+  const outcome = await perRepoCheck(ctx, type, async (repo) => {
+    const branch = await currentBranch(ctx, repo);
+    if (branch === null) {
+      return { status: "fail", detail: "\u65E0\u6CD5\u8BFB\u53D6\u5F53\u524D\u5206\u652F\uFF08git rev-parse --abbrev-ref HEAD \u5931\u8D25\u2014\u2014\u7591\u4F3C\u635F\u574F\u4ED3\uFF09\u2014\u2014\u786E\u8BA4\u4ED3\u5E93\u72B6\u6001\u540E\u91CD\u8BD5" };
     }
-    const localBase = await ctx.runGit(["rev-parse", base], repo);
-    const remoteBase = await ctx.runGit(["rev-parse", `origin/${base}`], repo);
-    if (!localBase.ok || !remoteBase.ok || localBase.stdout.trim() !== remoteBase.stdout.trim()) {
-      return { status: "fail", detail: `\u672C\u5730 ${base} \u4E0E origin/${base} \u4E0D\u4E00\u81F4\uFF08\u5408\u5E76\u7ED3\u679C\u672A\u63A8\u9001\u6216\u672A\u62C9\u53D6\uFF09\u2014\u2014git push origin ${base}\uFF08\u6216\u5148 pull \u5BF9\u9F50\uFF09` };
+    if (branch === base) {
+      anchorModeRepos += 1;
+      const judged = await judgeArchiveByAnchor(ctx, repo, base);
+      if (judged.status !== "not_applicable") anchorHitRepos += 1;
+      else anchorMissRepos.push(repo);
+      return judged;
     }
-    return { status: "pass", detail: `\u5DF2 --no-ff \u5408\u5165 ${base} \u4E14\u4E0E\u8FDC\u7A0B\u4E00\u81F4` };
+    return judgeArchiveByHead(ctx, repo, base);
   });
+  if (outcome.status === "not_applicable" && anchorModeRepos === ctx.repos.length && anchorHitRepos === 0) {
+    const anchor = ctx.nodeRecords["INTEGRATE"]?.verifiedCommit ?? "";
+    return fail2(
+      ctx,
+      type,
+      `\u9A8C\u8BC1\u7248\u672C ${anchor} \u4E0D\u5728\u4EFB\u4F55\u951A\u70B9\u6A21\u5F0F\u4ED3\uFF08${anchorMissRepos.join(", ")}\uFF1B\u5F52\u6863\u5408\u5E76\u65E0\u4ECE\u590D\u6838\uFF0C\u62D2\u7EDD\u6574\u4F53\u514D\u68C0\uFF09`,
+      "\u786E\u8BA4 INTEGRATE.verifiedCommit \u4E0E\u4EFB\u52A1\u4ED3\u96C6\u5408\u5339\u914D\uFF1B\u591A\u4ED3\u5DE5\u4F5C\u76EE\u5F55\u987B\u4ECE\u6839\u76EE\u5F55\u542F\u52A8\u4EE5\u5B8C\u6574\u626B\u63CF"
+    );
+  }
+  return outcome;
+}
+async function judgeArchiveByHead(ctx, repo, base) {
+  const count = await ctx.runGit(["rev-list", "--count", `${base}..HEAD`], repo);
+  if (count.ok && count.stdout.trim() === "0") {
+    return { status: "not_applicable", detail: `\u4EFB\u52A1\u5206\u652F\u76F8\u5BF9 ${base} \u96F6\u63D0\u4EA4\uFF08\u65E0\u4EE3\u7801\u6539\u52A8\uFF0C\u65E0\u9700\u5408\u5E76\uFF09` };
+  }
+  const ancestor = await ctx.runGit(["merge-base", "--is-ancestor", "HEAD", base], repo);
+  if (!ancestor.ok) {
+    return { status: "fail", detail: `\u57FA\u7840\u5206\u652F ${base} \u5C1A\u672A\u5305\u542B\u4EFB\u52A1\u5206\u652F HEAD\uFF08\u672A\u5408\u5E76\uFF09\u2014\u2014git checkout ${base} && git merge --no-ff <\u4EFB\u52A1\u5206\u652F> && git push` };
+  }
+  const merges = await ctx.runGit(["log", "--merges", "-1", "--format=%P", base], repo);
+  const parents = merges.ok ? merges.stdout.trim().split(/\s+/) : [];
+  if (parents.length !== 2) {
+    return { status: "fail", detail: `\u672A\u68C0\u6D4B\u5230 --no-ff \u5408\u5E76\u63D0\u4EA4\uFF08\u6700\u8FD1\u4E00\u6B21\u5408\u5E76 parents=${parents.length}\uFF09\u2014\u2014\u5408\u5E76\u5FC5\u987B\u4F7F\u7528 --no-ff\uFF08\u4FDD\u7559\u5408\u5E76\u8BB0\u5F55\uFF09` };
+  }
+  const pushFailure = await judgePushConsistent(ctx, repo, base);
+  if (pushFailure !== null) return pushFailure;
+  return { status: "pass", detail: `\u5DF2 --no-ff \u5408\u5165 ${base} \u4E14\u4E0E\u8FDC\u7A0B\u4E00\u81F4` };
+}
+async function judgeArchiveByAnchor(ctx, repo, base) {
+  const anchor = ctx.nodeRecords["INTEGRATE"]?.verifiedCommit;
+  if (!anchor) {
+    return { status: "fail", detail: "INTEGRATE \u8BB0\u5F55\u7F3A verifiedCommit\uFF08\u5F52\u6863\u951A\u70B9\u7F3A\u5931\uFF0C\u65E0\u6CD5\u786E\u8BA4\u9A8C\u8BC1\u7248\u672C\u5DF2\u5408\u5165\uFF09\u2014\u2014\u56DE\u8865 INTEGRATE record-set verifiedCommit \u540E\u91CD\u8BD5" };
+  }
+  const probe = await ctx.runGit(["cat-file", "-e", anchor], repo);
+  if (!probe.ok) {
+    return { status: "not_applicable", detail: `\u4E0D\u542B\u951A\u70B9\u63D0\u4EA4 ${anchor}\uFF08\u975E\u672C\u4EFB\u52A1\u4ED3\uFF0C\u514D\u68C0\uFF09` };
+  }
+  const ancestor = await ctx.runGit(["merge-base", "--is-ancestor", anchor, base], repo);
+  if (!ancestor.ok) {
+    return { status: "fail", detail: `\u57FA\u7840\u5206\u652F ${base} \u5C1A\u672A\u5305\u542B\u9A8C\u8BC1\u7248\u672C ${anchor}\uFF08\u4EFB\u52A1\u5206\u652F\u672A\u5408\u5E76\uFF09\u2014\u2014git checkout ${base} && git merge --no-ff <\u4EFB\u52A1\u5206\u652F> && git push` };
+  }
+  const merges = await ctx.runGit(["rev-list", "--merges", "--ancestry-path", `${anchor}..${base}`], repo);
+  if (!merges.ok) {
+    return { status: "fail", detail: `git rev-list --merges \u5931\u8D25\uFF1A${firstLine(merges.stderr)}\u2014\u2014\u68C0\u67E5\u4ED3\u5E93\u53EF\u7528\u6027` };
+  }
+  const mergeList = merges.stdout.split("\n").map((l) => l.trim()).filter((l) => l !== "");
+  const earliest = mergeList[mergeList.length - 1];
+  if (earliest === void 0) {
+    return {
+      status: "fail",
+      detail: `\u672A\u68C0\u6D4B\u5230 --no-ff \u5408\u5E76\u63D0\u4EA4\uFF08${anchor} \u81F3 ${base} \u4E4B\u95F4\u65E0\u5408\u5E76\u8BB0\u5F55\uFF09\u2014\u2014\u82E5\u4EFB\u52A1\u5206\u652F\u66FE\u4EE5 fast-forward / squash / rebase \u5408\u5165\uFF0C\u56DE\u9000\u5E76\u6309 --no-ff \u91CD\u5EFA\u5408\u5E76\u63D0\u4EA4\uFF1B\u82E5\u4EFB\u52A1\u5206\u652F\u81EA\u521B\u5EFA\u4EE5\u6765\u96F6\u63D0\u4EA4\uFF08\u65E0\u4EE3\u7801\u5F52\u6863\uFF09\uFF0C\u7ECF\u7528\u6237\u660E\u793A\u540E\u53EF force \u63A8\u8FDB\u5E76\u7559\u75D5`
+    };
+  }
+  const pushFailure = await judgePushConsistent(ctx, repo, base);
+  if (pushFailure !== null) return pushFailure;
+  return { status: "pass", detail: `\u5DF2 --no-ff \u5408\u5165 ${base}\uFF08\u951A\u70B9 ${anchor}\uFF0C\u5408\u5E76\u63D0\u4EA4 ${earliest}\uFF09\u4E14\u4E0E\u8FDC\u7A0B\u4E00\u81F4` };
+}
+async function judgePushConsistent(ctx, repo, base) {
+  const fetch2 = await ctx.runGit(["fetch", "origin", base], repo);
+  if (!fetch2.ok) {
+    return { status: "fail", detail: `git fetch origin ${base} \u5931\u8D25\u2014\u2014\u672C\u5730\u4E0E\u8FDC\u7A0B\u4E00\u81F4\u6027\u65E0\u4ECE\u5224\u5B9A\uFF08\u62D2\u6309\u9648\u65E7 ref \u8BEF\u5224\uFF09\uFF1B\u68C0\u67E5\u7F51\u7EDC/\u8FDC\u7A0B\u53EF\u8FBE\u540E\u91CD\u8BD5` };
+  }
+  const localBase = await ctx.runGit(["rev-parse", base], repo);
+  const remoteBase = await ctx.runGit(["rev-parse", `origin/${base}`], repo);
+  if (!localBase.ok || !remoteBase.ok || localBase.stdout.trim() !== remoteBase.stdout.trim()) {
+    return { status: "fail", detail: `\u672C\u5730 ${base} \u4E0E origin/${base} \u4E0D\u4E00\u81F4\uFF08\u5408\u5E76\u7ED3\u679C\u672A\u63A8\u9001\u6216\u672A\u62C9\u53D6\uFF09\u2014\u2014git push origin ${base}\uFF08\u6216\u5148 pull \u5BF9\u9F50\uFF09` };
+  }
+  return null;
 }
 async function checkStayOnBase(ctx) {
   const type = "git-stay-on-base";
@@ -1193,12 +1256,22 @@ function collectPredecessors(edges, nodeId) {
 }
 async function checkVersionConsistent(ctx) {
   const type = "record-version-consistent";
+  const guard = naIfRepoUnavailable(ctx);
+  if (guard) return { ...guard, type };
+  if (ctx.vcs.archiveToBase === false) {
+    return { type, status: "not_applicable", detail: "\u9879\u76EE vcs.archiveToBase=false\uFF08\u58F0\u660E\u65E0\u5F52\u6863\u5408\u5E76\u6D41\u7A0B\uFF09" };
+  }
+  if (hasSuccessorNode(ctx)) {
+    return {
+      type,
+      status: "not_applicable",
+      detail: "\u975E\u7EC8\u6001\u5F62\u6001\uFF08\u5B58\u5728\u540E\u7EE7\u8282\u70B9\uFF09\uFF1A\u4EE3\u7801\u5F52\u6863\u7531\u5BA1\u6279\u901A\u8FC7\u540E\u7684\u5F52\u6863\u5F85\u529E\u627F\u8F7D\uFF0Cadvance \u65F6\u5F52\u6863\u5C1A\u672A\u53D1\u751F\uFF1B\u7248\u672C\u4E00\u81F4\u6027\u7531\u5F52\u6863\u5B8C\u6210\u540E\u7684\u5F52\u6863\u8282\u70B9\u590D\u6838"
+    };
+  }
   const sha = ctx.nodeRecords["INTEGRATE"]?.verifiedCommit;
   if (!sha) {
     return fail3(type, "INTEGRATE \u8BB0\u5F55\u7F3A verifiedCommit\uFF08\u7248\u672C\u4E00\u81F4\u6027\u65E0\u4ECE\u5224\u5B9A\uFF09", "\u56DE\u8865 INTEGRATE record-set verifiedCommit \u540E\u91CD\u8BD5");
   }
-  const guard = naIfRepoUnavailable(ctx);
-  if (guard) return { ...guard, type };
   if (ctx.baseBranch === null) {
     return fail3(type, "\u57FA\u7840\u5206\u652F\u672A\u77E5\uFF08ALIGN.baseBranch \u672A\u843D\u76D8\u4E14\u9879\u76EE\u672A\u914D\u7F6E\uFF09", "record-set \u5199 ALIGN.baseBranch\uFF0C\u6216 siming project update --vcs-base-branch <\u5206\u652F>");
   }

package/package.json

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

package/templates/builtin/full_workflow.bundle.json

@@ -1,6 +1,6 @@
 {
   "exportFormatVersion": "1.0",
-  "exportedAt": "2026-10-21T04:04:04.654Z",
+  "exportedAt": "2026-10-23T09:51:30.283Z",
   "warnings": [],
   "template": {
     "name": "full_workflow",
@@ -431,7 +431,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；存量跳过如实记录不阻断，本任务新增未授权 skip 为 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\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；存量跳过如实记录不阻断，本任务新增未授权 skip 为 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"
         ],
@@ -441,8 +441,8 @@
         ],
         "sourcePreset": {
           "code": "test-integrate",
-          "version": "1.5.1",
-          "contentHash": "74d8abe52c25adfd",
+          "version": "1.5.2",
+          "contentHash": "32678fd8653c6d78",
           "agents": [
             "test-executor",
             "code-reviewer"
@@ -480,15 +480,15 @@
         "label": "发布验收",
         "phase": "exit",
         "track": "all",
-        "prompt": "# 发布验收\n\n## 节点职责\n\n核对最终集成验证证据与当前版本是否一致，向用户呈现可独立理解的验收摘要，并按本节点在流程中的位置承载确认与代码归档：存在后继审批边时，用户确认由流转边暂停点承载，本节点不重复确认；本节点为任务终点时，节点内确认是任务收尾唯一授权门。本节点不重复执行测试、代码评审或回归分析。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、已激活节点的完成记录、`test-integrate` 的测试范围与结果、日志以及已验证版本标识，并读取项目分支与归档策略。加载 `workflow-discipline`。\n\n缺少集成验证证据、版本标识或前序完成记录时，先从任务上下文补齐；证据仍不完整或无法对应当前版本时停止验收，不推断通过。\n\n## 执行流程\n\n1. 确认所有已激活的前序节点均已完成，不写死某一模板路径下的节点清单。\n2. 比较当前生产代码与 `test-integrate` 绑定的已验证版本。存在新的生产代码变化时，退回集成验证重新判断范围并回归；纯文档或记录变化说明为何不影响证据。\n3. 逐条核对验收标准对应的实现位置和前序验证证据，并确认非目标未被误实现、范围变化已说明、所有 reviewer 的阻塞问题已解决。\n4. 汇总集成测试范围与统计、本任务新增未授权跳过（存量跳过不阻断）、实现与验收标准对应关系、范围变化、已知问题和风险，形成简洁且不依赖任务内部术语的验收摘要。\n5. 判定本节点位置：读取任务上下文中的任务结构（DAG 节点集与各节点状态）——本节点是任务最后一个节点（如快速流程形态，已完成数加一等于节点总数）即为终态形态；存在后继节点（如架构归档节点）即为非终态形态。advance 响应的 nextNode 资料包可作交叉印证。两种形态的确认与归档时序不同，按后续步骤分支执行，判定结果写入节点记录。\n6. **终态形态（本节点为任务终点，无后继审批边）**：向用户呈现验收摘要并在节点内取得明确决定。只有明确的通过、确认归档或等价肯定表达构成确认；提问、条件句、部分认同、沉默或模糊表态不构成确认。确认后逐字记录确认原文，并按项目声明完成提交、合并、推送或其他代码归档动作。无项目策略时采用保留历史且可回退的常规方式，并记录采用的默认。\n7. **非终态形态（存在后继审批边）**：向用户呈现验收摘要（作为暂停点审批材料）；推进前在节点记录写入显式「归档待办」条目（归档动作清单：目标分支、合并方式、推送范围）；然后推进进入暂停点等待用户审批——审批通过即验收确认，确认原文以审批记录留痕（须逐字引用用户确认表态，不得转述失真），本节点不重复确认。审批通过后、开始下一节点工作前，先完成归档待办中的代码归档动作（提交/合并/推送），完成后回写归档结果闭环该待办；归档待办在归档完成前不得闭环。\n8. 归档过程中遇到冲突或失败时先检查实际版本控制状态并自主诊断；无法可靠解决时说明当前状态和卡点，不猜测操作结果。\n\n## 产出与检查\n\n推进前确认：\n\n- 所有已激活前序节点已完成；\n- 集成验证证据完整，所有适用测试通过，失败为 0；本任务新增未授权跳过为 0（存量跳过不阻断）；\n- 当前生产代码与已验证版本一致；\n- 每条验收标准都有实现和验证证据，非目标、范围变化与已知问题已说明；\n- 没有未解决的 BLOCKER、HIGH 或其他流程定义的阻塞问题；\n- 终态形态：用户已明确确认，确认原文已逐字记录，代码已按项目策略归档；\n- 非终态形态：验收摘要已呈现，归档待办已写入且动作清单明确（归档动作待审批通过后执行，不在本节点提前归档）；\n- 最终提交、分支和远程状态可追溯。\n\n## 任务差异处理\n\n任务没有代码或项目没有分支归档流程时，执行适用的验收确认并说明不适用项。用户要求附条件通过或接受具体风险时，终态形态在节点内记录条件、风险和确认原文；非终态形态该表态在暂停点审批中给出，审批记录即留痕。未被明确接受的阻塞问题不得归档。证据过期、验收标准缺失或代码归档失败时，按实际问题返回相应节点处理，不在本节点重新执行其职责。\n\n## 节点记录与推进\n\n推进前将验收摘要、证据时效、验收标准对照、范围变化、已知问题和位置判定结果写入当前节点记录；非终态形态同时写入归档待办，并在归档完成前保持其未闭环。终态形态在用户确认后追加确认原文与归档结果；非终态形态在暂停点审批通过并完成归档后，追加审批引用、归档策略与结果、最终提交和远程状态，闭环归档待办。完成推进前检查后推进下一节点——终态形态的推进必须带收尾确认参数（CLI `--finalize` / MCP `finalize=true`），终节点缺省 advance 会被拒绝并提示；非终态形态不带该参数（携带也会被忽略）；批后追加动作发生在推进之后，不阻塞推进。\n",
+        "prompt": "# 发布验收\n\n## 节点职责\n\n核对最终集成验证证据与当前版本是否一致，向用户呈现可独立理解的验收摘要，并按本节点在流程中的位置承载确认与代码归档：存在后继审批边时，用户确认由流转边暂停点承载，本节点不重复确认；本节点为任务终点时，节点内确认是任务收尾唯一授权门。本节点不重复执行测试、代码评审或回归分析。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、已激活节点的完成记录、`test-integrate` 的测试范围与结果、日志以及已验证版本标识，并读取项目分支与归档策略。加载 `workflow-discipline`。\n\n缺少集成验证证据、版本标识或前序完成记录时，先从任务上下文补齐；证据仍不完整或无法对应当前版本时停止验收，不推断通过。\n\n## 执行流程\n\n1. 确认所有已激活的前序节点均已完成，不写死某一模板路径下的节点清单。\n2. 比较当前生产代码与 `test-integrate` 绑定的已验证版本。存在新的生产代码变化时，退回集成验证重新判断范围并回归；纯文档或记录变化说明为何不影响证据。\n3. 逐条核对验收标准对应的实现位置和前序验证证据，并确认非目标未被误实现、范围变化已说明、所有 reviewer 的阻塞问题已解决。\n4. 汇总集成测试范围与统计、本任务新增未授权跳过（存量跳过不阻断）、实现与验收标准对应关系、范围变化、已知问题和风险，形成简洁且不依赖任务内部术语的验收摘要。\n5. 判定本节点位置：读取任务上下文中的任务结构（DAG 节点集与各节点状态）——本节点是任务最后一个节点（如快速流程形态，已完成数加一等于节点总数）即为终态形态；存在后继节点（如架构归档节点）即为非终态形态。advance 响应的 nextNode 资料包可作交叉印证。两种形态的确认与归档时序不同，按后续步骤分支执行，判定结果写入节点记录。\n6. **终态形态（本节点为任务终点，无后继审批边）**：向用户呈现验收摘要并在节点内取得明确决定。只有明确的通过、确认归档或等价肯定表达构成确认；提问、条件句、部分认同、沉默或模糊表态不构成确认。确认后逐字记录确认原文，并按项目声明完成提交、合并、推送或其他代码归档动作。无项目策略时采用保留历史且可回退的常规方式，并记录采用的默认。\n7. **非终态形态（存在后继审批边）**：向用户呈现验收摘要（作为暂停点审批材料）；推进前在节点记录写入显式「归档待办」条目（归档动作清单：目标分支、合并方式、推送范围）；然后推进进入暂停点等待用户审批——审批通过即验收确认，确认原文以审批记录留痕（须逐字引用用户确认表态，不得转述失真），本节点不重复确认。审批通过后、开始下一节点工作前，先完成归档待办中的代码归档动作（提交/合并/推送），完成后回写归档结果闭环该待办；归档待办在归档完成前不得闭环。\n8. 归档过程中遇到冲突或失败时先检查实际版本控制状态并自主诊断；无法可靠解决时说明当前状态和卡点，不猜测操作结果。\n\n## 产出与检查\n\n推进前确认：\n\n- 所有已激活前序节点已完成；\n- 集成验证证据完整，所有适用测试通过，失败为 0；本任务新增未授权跳过为 0（存量跳过不阻断）；\n- 当前生产代码与已验证版本一致；\n- 每条验收标准都有实现和验证证据，非目标、范围变化与已知问题已说明；\n- 没有未解决的 BLOCKER、HIGH 或其他流程定义的阻塞问题；\n- 终态形态：用户已明确确认，确认原文已逐字记录，代码已按项目策略归档；\n- 非终态形态：验收摘要已呈现，归档待办已写入且动作清单明确（归档动作待审批通过后执行，不在本节点提前归档）；\n- 最终提交、分支和远程状态可追溯。\n\n## 任务差异处理\n\n任务没有代码或项目没有分支归档流程时，执行适用的验收确认并说明不适用项。用户要求附条件通过或接受具体风险时，终态形态在节点内记录条件、风险和确认原文；非终态形态该表态在暂停点审批中给出，审批记录即留痕。未被明确接受的阻塞问题不得归档。证据过期、验收标准缺失或代码归档失败时，按实际问题返回相应节点处理，不在本节点重新执行其职责。\n\n## 节点记录与推进\n\n推进前将验收摘要、证据时效、验收标准对照、范围变化、已知问题和位置判定结果写入当前节点记录；非终态形态同时写入归档待办，并在归档完成前保持其未闭环。终态形态在用户确认后追加确认原文与归档结果；非终态形态在暂停点审批通过并完成归档后，追加审批引用、归档策略与结果、最终提交和远程状态，闭环归档待办。完成推进前检查后推进下一节点——终态形态的推进必须带收尾确认参数（CLI `--finalize` / MCP `finalize=true`），终节点缺省 advance 会被拒绝并提示；非终态形态不带该参数（携带也会被忽略）；批后追加动作发生在推进之后，不阻塞推进。",
         "skills": [
           "workflow-discipline"
         ],
         "agents": [],
         "sourcePreset": {
           "code": "release-accept",
-          "version": "1.5.2",
-          "contentHash": "4aecd37f039273bf",
+          "version": "1.5.3",
+          "contentHash": "2d9dadaf80732cfa",
           "agents": []
         },
         "toolChecks": [
@@ -727,7 +727,7 @@
       }
     },
     "isDefault": false,
-    "version": "3.7.7"
+    "version": "3.7.8"
   },
   "dependencies": {
     "skills": [

package/templates/builtin/quick_workflow.bundle.json

@@ -1,10 +1,10 @@
 {
   "exportFormatVersion": "1.0",
-  "exportedAt": "2026-10-21T04:04:04.663Z",
+  "exportedAt": "2026-10-23T09:51:30.295Z",
   "warnings": [],
   "template": {
     "name": "quick_workflow",
-    "description": "通用快速开发流程：分支对齐、快速设计（AI 评审 + 人工确认）、后端或前端实现与测试一体（自动测试全绿 + 代码评审 + 视觉验证）、集成验证与发布验收。适用于范围明确的小型改动；命中复杂度红线时建议改走完整流程。混合任务先完成后端实现，再进入前端实现。",
+    "description": "通用快速开发流程：分支对齐、快速设计（AI 评审 + 人工确认）、后端或前端实现与测试一体（自动测试全绿 + 代码评审 + 视觉验证）、E2E 增量验证（增量用例设计 + 实现 + 执行）、集成验证与发布验收。适用于范围明确的小型改动；命中复杂度红线时建议改走完整流程。混合任务先完成后端实现，再进入前端实现。",
     "nodes": [
       {
         "id": "ALIGN",
@@ -108,12 +108,54 @@
           ]
         }
       },
+      {
+        "id": "E2E_QUICK",
+        "label": "E2E增量验证",
+        "phase": "test",
+        "track": "all",
+        "prompt": "# E2E增量验证\n\n## 节点职责\n\n在单一节点内完成本任务增量的端到端测试闭环：只为本次改动新增或变化的行为设计 E2E 用例，实现并执行这些用例取得全绿结果。设计与执行都以增量为边界——不重新覆盖既有流程，不执行全量 E2E 回归（存量回归由集成验证节点的判断链决定）。\n\n## 依赖信息\n\n先检查当前任务上下文：需求、验收标准、快速设计的改动点清单与影响面、编码节点的实现与测试记录。加载 `workflow-discipline`；调用 `test-reviewer` 评审用例设计、`test-executor` 执行测试；失败根因不明时加载 `bugfix-root-cause-verification`；发生生产代码修复时调用 `code-reviewer`。\n\n识别项目声明的 E2E 测试体系与执行入口（目录、配置、脚本、运行方式），以项目声明为准；不假设具体路径或命令，不擅自引入项目未定义的测试设施。\n\n## 正向执行流程\n\n1. 从改动点清单与编码记录提取增量：新增行为、行为变化、变化的接口或数据契约。逐项判定端到端可见性——是否构成用户可感知的完整链路（如界面操作→服务→数据或等价路径）；判定为否的项记录理由，不设计用例。\n2. 项目未定义 E2E 体系，或增量中无端到端可见行为时，写入 N/A 判定与理由后推进——不为快速任务从零搭建 E2E 基础设施；确需搭建时说明影响并建议改走完整流程。\n3. 为每个端到端可见的增量项设计最小用例集：前置与数据、操作序列、对准验收标准的关键断言、清理复位。只覆盖增量，不连带既有流程。\n4. 将增量清单、逐项判定与用例设计交给 `test-reviewer` 单轮独立评审，不提供主会话结论；BLOCKER、HIGH 修复后重审，MEDIUM、LOW 逐项处理或记录保留理由，直至 PASS。\n5. 按项目 E2E 体系实现用例代码，沿用既有用例的组织与定位器惯例；原则上不为用例修改生产代码，确需可测性调整时说明并保持最小。\n6. 存量 E2E 用例因本任务行为变化而断言失效时，同步修正并纳入本次执行范围（属增量波及，非全量回归）；除此之外不执行任何存量用例。\n7. 将本节点产出用例的执行命令、范围与通过标准交给 `test-executor` 执行。执行范围默认为新增及修正用例——目的是控制耗时，存量回归由集成验证节点按其判断链决定，本节点不重复。执行中判断需要超出默认范围的用例或执行时，按价值决策，产物保留并在节点记录写明补充理由。失败时先完成根因调查再做最小正确修复并重跑原失败用例；确属生产代码缺陷时，修复交 `code-reviewer` 评审至 PASS。\n8. 记录新增用例清单（位置、覆盖的增量项）、修正的存量用例、执行统计与证据，绑定明确版本标识，供集成验证节点的回归判断链消费。\n\n## 产出与检查\n\n推进前确认：增量提取与端到端可见判定逐项留痕（含 N/A 项与理由）；有增量用例时 `test-reviewer` 最终 PASS 且 Findings 处理留痕；`test-executor` 报告执行范围内用例全绿、失败 0，本任务新增未授权 skip/only 为 0；执行统计与用例清单对应（超出默认范围的部分有理由留痕）；发生生产代码修复时 `code-reviewer` PASS；用例清单与版本绑定已写入记录。\n\n## 任务差异处理\n\n项目无 E2E 体系、增量无端到端可见行为、或本节点被任务剪枝时，写明判定与理由后推进，不静默跳过。执行环境无法满足 E2E 运行前置（服务、数据、环境）时，说明卡点并暂停上升用户，不降级伪造执行结果。\n\n## 节点记录与推进\n\n将增量清单与判定、用例设计要点、评审结论与 Findings 处理、新增用例位置与覆盖对应、修正的存量用例、执行命令与统计、失败根因与修复（如有）、评审结论（如有）、绑定版本写入当前节点记录，推进集成验证节点。",
+        "skills": [
+          "workflow-discipline"
+        ],
+        "agents": [
+          "test-reviewer",
+          "test-executor",
+          "code-reviewer"
+        ],
+        "sourcePreset": {
+          "code": "quick-e2e-verify",
+          "version": "1.0.0",
+          "contentHash": "54b99f388b874c01",
+          "agents": [
+            "test-reviewer",
+            "test-executor",
+            "code-reviewer"
+          ]
+        },
+        "toolChecks": [
+          {
+            "type": "record-test-report"
+          },
+          {
+            "type": "record-no-fake-green"
+          },
+          {
+            "type": "git-worktree-clean"
+          }
+        ],
+        "aiChecks": [
+          {
+            "id": "e2eq-delta-mapping",
+            "item": "增量提取与端到端可见判定逐项留痕（含 N/A 项与理由）；新增用例与增量项的覆盖对应关系已写入节点记录"
+          }
+        ]
+      },
       {
         "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；存量跳过如实记录不阻断，本任务新增未授权 skip 为 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\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；存量跳过如实记录不阻断，本任务新增未授权 skip 为 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"
         ],
@@ -123,8 +165,8 @@
         ],
         "sourcePreset": {
           "code": "test-integrate",
-          "version": "1.5.1",
-          "contentHash": "74d8abe52c25adfd",
+          "version": "1.5.2",
+          "contentHash": "32678fd8653c6d78",
           "agents": [
             "test-executor",
             "code-reviewer"
@@ -162,15 +204,15 @@
         "label": "发布验收",
         "phase": "exit",
         "track": "all",
-        "prompt": "# 发布验收\n\n## 节点职责\n\n核对最终集成验证证据与当前版本是否一致，向用户呈现可独立理解的验收摘要，并按本节点在流程中的位置承载确认与代码归档：存在后继审批边时，用户确认由流转边暂停点承载，本节点不重复确认；本节点为任务终点时，节点内确认是任务收尾唯一授权门。本节点不重复执行测试、代码评审或回归分析。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、已激活节点的完成记录、`test-integrate` 的测试范围与结果、日志以及已验证版本标识，并读取项目分支与归档策略。加载 `workflow-discipline`。\n\n缺少集成验证证据、版本标识或前序完成记录时，先从任务上下文补齐；证据仍不完整或无法对应当前版本时停止验收，不推断通过。\n\n## 执行流程\n\n1. 确认所有已激活的前序节点均已完成，不写死某一模板路径下的节点清单。\n2. 比较当前生产代码与 `test-integrate` 绑定的已验证版本。存在新的生产代码变化时，退回集成验证重新判断范围并回归；纯文档或记录变化说明为何不影响证据。\n3. 逐条核对验收标准对应的实现位置和前序验证证据，并确认非目标未被误实现、范围变化已说明、所有 reviewer 的阻塞问题已解决。\n4. 汇总集成测试范围与统计、本任务新增未授权跳过（存量跳过不阻断）、实现与验收标准对应关系、范围变化、已知问题和风险，形成简洁且不依赖任务内部术语的验收摘要。\n5. 判定本节点位置：读取任务上下文中的任务结构（DAG 节点集与各节点状态）——本节点是任务最后一个节点（如快速流程形态，已完成数加一等于节点总数）即为终态形态；存在后继节点（如架构归档节点）即为非终态形态。advance 响应的 nextNode 资料包可作交叉印证。两种形态的确认与归档时序不同，按后续步骤分支执行，判定结果写入节点记录。\n6. **终态形态（本节点为任务终点，无后继审批边）**：向用户呈现验收摘要并在节点内取得明确决定。只有明确的通过、确认归档或等价肯定表达构成确认；提问、条件句、部分认同、沉默或模糊表态不构成确认。确认后逐字记录确认原文，并按项目声明完成提交、合并、推送或其他代码归档动作。无项目策略时采用保留历史且可回退的常规方式，并记录采用的默认。\n7. **非终态形态（存在后继审批边）**：向用户呈现验收摘要（作为暂停点审批材料）；推进前在节点记录写入显式「归档待办」条目（归档动作清单：目标分支、合并方式、推送范围）；然后推进进入暂停点等待用户审批——审批通过即验收确认，确认原文以审批记录留痕（须逐字引用用户确认表态，不得转述失真），本节点不重复确认。审批通过后、开始下一节点工作前，先完成归档待办中的代码归档动作（提交/合并/推送），完成后回写归档结果闭环该待办；归档待办在归档完成前不得闭环。\n8. 归档过程中遇到冲突或失败时先检查实际版本控制状态并自主诊断；无法可靠解决时说明当前状态和卡点，不猜测操作结果。\n\n## 产出与检查\n\n推进前确认：\n\n- 所有已激活前序节点已完成；\n- 集成验证证据完整，所有适用测试通过，失败为 0；本任务新增未授权跳过为 0（存量跳过不阻断）；\n- 当前生产代码与已验证版本一致；\n- 每条验收标准都有实现和验证证据，非目标、范围变化与已知问题已说明；\n- 没有未解决的 BLOCKER、HIGH 或其他流程定义的阻塞问题；\n- 终态形态：用户已明确确认，确认原文已逐字记录，代码已按项目策略归档；\n- 非终态形态：验收摘要已呈现，归档待办已写入且动作清单明确（归档动作待审批通过后执行，不在本节点提前归档）；\n- 最终提交、分支和远程状态可追溯。\n\n## 任务差异处理\n\n任务没有代码或项目没有分支归档流程时，执行适用的验收确认并说明不适用项。用户要求附条件通过或接受具体风险时，终态形态在节点内记录条件、风险和确认原文；非终态形态该表态在暂停点审批中给出，审批记录即留痕。未被明确接受的阻塞问题不得归档。证据过期、验收标准缺失或代码归档失败时，按实际问题返回相应节点处理，不在本节点重新执行其职责。\n\n## 节点记录与推进\n\n推进前将验收摘要、证据时效、验收标准对照、范围变化、已知问题和位置判定结果写入当前节点记录；非终态形态同时写入归档待办，并在归档完成前保持其未闭环。终态形态在用户确认后追加确认原文与归档结果；非终态形态在暂停点审批通过并完成归档后，追加审批引用、归档策略与结果、最终提交和远程状态，闭环归档待办。完成推进前检查后推进下一节点——终态形态的推进必须带收尾确认参数（CLI `--finalize` / MCP `finalize=true`），终节点缺省 advance 会被拒绝并提示；非终态形态不带该参数（携带也会被忽略）；批后追加动作发生在推进之后，不阻塞推进。\n",
+        "prompt": "# 发布验收\n\n## 节点职责\n\n核对最终集成验证证据与当前版本是否一致，向用户呈现可独立理解的验收摘要，并按本节点在流程中的位置承载确认与代码归档：存在后继审批边时，用户确认由流转边暂停点承载，本节点不重复确认；本节点为任务终点时，节点内确认是任务收尾唯一授权门。本节点不重复执行测试、代码评审或回归分析。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、已激活节点的完成记录、`test-integrate` 的测试范围与结果、日志以及已验证版本标识，并读取项目分支与归档策略。加载 `workflow-discipline`。\n\n缺少集成验证证据、版本标识或前序完成记录时，先从任务上下文补齐；证据仍不完整或无法对应当前版本时停止验收，不推断通过。\n\n## 执行流程\n\n1. 确认所有已激活的前序节点均已完成，不写死某一模板路径下的节点清单。\n2. 比较当前生产代码与 `test-integrate` 绑定的已验证版本。存在新的生产代码变化时，退回集成验证重新判断范围并回归；纯文档或记录变化说明为何不影响证据。\n3. 逐条核对验收标准对应的实现位置和前序验证证据，并确认非目标未被误实现、范围变化已说明、所有 reviewer 的阻塞问题已解决。\n4. 汇总集成测试范围与统计、本任务新增未授权跳过（存量跳过不阻断）、实现与验收标准对应关系、范围变化、已知问题和风险，形成简洁且不依赖任务内部术语的验收摘要。\n5. 判定本节点位置：读取任务上下文中的任务结构（DAG 节点集与各节点状态）——本节点是任务最后一个节点（如快速流程形态，已完成数加一等于节点总数）即为终态形态；存在后继节点（如架构归档节点）即为非终态形态。advance 响应的 nextNode 资料包可作交叉印证。两种形态的确认与归档时序不同，按后续步骤分支执行，判定结果写入节点记录。\n6. **终态形态（本节点为任务终点，无后继审批边）**：向用户呈现验收摘要并在节点内取得明确决定。只有明确的通过、确认归档或等价肯定表达构成确认；提问、条件句、部分认同、沉默或模糊表态不构成确认。确认后逐字记录确认原文，并按项目声明完成提交、合并、推送或其他代码归档动作。无项目策略时采用保留历史且可回退的常规方式，并记录采用的默认。\n7. **非终态形态（存在后继审批边）**：向用户呈现验收摘要（作为暂停点审批材料）；推进前在节点记录写入显式「归档待办」条目（归档动作清单：目标分支、合并方式、推送范围）；然后推进进入暂停点等待用户审批——审批通过即验收确认，确认原文以审批记录留痕（须逐字引用用户确认表态，不得转述失真），本节点不重复确认。审批通过后、开始下一节点工作前，先完成归档待办中的代码归档动作（提交/合并/推送），完成后回写归档结果闭环该待办；归档待办在归档完成前不得闭环。\n8. 归档过程中遇到冲突或失败时先检查实际版本控制状态并自主诊断；无法可靠解决时说明当前状态和卡点，不猜测操作结果。\n\n## 产出与检查\n\n推进前确认：\n\n- 所有已激活前序节点已完成；\n- 集成验证证据完整，所有适用测试通过，失败为 0；本任务新增未授权跳过为 0（存量跳过不阻断）；\n- 当前生产代码与已验证版本一致；\n- 每条验收标准都有实现和验证证据，非目标、范围变化与已知问题已说明；\n- 没有未解决的 BLOCKER、HIGH 或其他流程定义的阻塞问题；\n- 终态形态：用户已明确确认，确认原文已逐字记录，代码已按项目策略归档；\n- 非终态形态：验收摘要已呈现，归档待办已写入且动作清单明确（归档动作待审批通过后执行，不在本节点提前归档）；\n- 最终提交、分支和远程状态可追溯。\n\n## 任务差异处理\n\n任务没有代码或项目没有分支归档流程时，执行适用的验收确认并说明不适用项。用户要求附条件通过或接受具体风险时，终态形态在节点内记录条件、风险和确认原文；非终态形态该表态在暂停点审批中给出，审批记录即留痕。未被明确接受的阻塞问题不得归档。证据过期、验收标准缺失或代码归档失败时，按实际问题返回相应节点处理，不在本节点重新执行其职责。\n\n## 节点记录与推进\n\n推进前将验收摘要、证据时效、验收标准对照、范围变化、已知问题和位置判定结果写入当前节点记录；非终态形态同时写入归档待办，并在归档完成前保持其未闭环。终态形态在用户确认后追加确认原文与归档结果；非终态形态在暂停点审批通过并完成归档后，追加审批引用、归档策略与结果、最终提交和远程状态，闭环归档待办。完成推进前检查后推进下一节点——终态形态的推进必须带收尾确认参数（CLI `--finalize` / MCP `finalize=true`），终节点缺省 advance 会被拒绝并提示；非终态形态不带该参数（携带也会被忽略）；批后追加动作发生在推进之后，不阻塞推进。",
         "skills": [
           "workflow-discipline"
         ],
         "agents": [],
         "sourcePreset": {
           "code": "release-accept",
-          "version": "1.5.2",
-          "contentHash": "4aecd37f039273bf",
+          "version": "1.5.3",
+          "contentHash": "2d9dadaf80732cfa",
           "agents": []
         },
         "toolChecks": [
@@ -224,10 +266,14 @@
       },
       {
         "from": "CODE_BACKEND",
-        "to": "INTEGRATE"
+        "to": "E2E_QUICK"
       },
       {
         "from": "CODE_UI",
+        "to": "E2E_QUICK"
+      },
+      {
+        "from": "E2E_QUICK",
         "to": "INTEGRATE"
       },
       {
@@ -235,8 +281,9 @@
         "to": "ACCEPT"
       }
     ],
+    "layout": {},
     "isDefault": false,
-    "version": "2.0.9"
+    "version": "2.1.0"
   },
   "dependencies": {
     "skills": [
@@ -331,6 +378,19 @@
         "scope": "global",
         "function": "reviewer"
       },
+      {
+        "name": "test-reviewer",
+        "description": "单元测试与端到端测试设计评审",
+        "systemPrompt": "你是测试设计的独立只读评审者，负责判断测试设计能否有效验证需求和实现中的关键行为，并发现覆盖缺口与不可执行设计。\n\n只评审测试设计，不修改文档或代码、不执行测试、不委派其他 Agent，也不接管修订和多轮协调。完成报告后立即结束。\n\n## 评审输入与信任规则\n\n- **待评审设计文档**：全文必读，这是评审对象本体。\n- **契约材料**（委派方内联的项目测试约束节选）：直接作为评审依据，不重新检索全仓验证。\n- **材料路标**（需求、技术方案、生产代码、现有测试的位置指针）：按需定点读取——评审到哪一项就打开哪一项，禁止为了「确认无遗漏」做全仓递归遍历。\n- **上轮已验锚点清单**（位置+结论，非首轮时随材料提供）：直接信任，不重新打开核对；本轮发现清单中任何一处错误时，该来源全部锚点降级为待核并逐项重验。\n- 缺少判断覆盖度或可执行性所必需的输入时，输出 `总体：BLOCKED` 并列出缺失项，不自行扩展检索补齐。\n\n## 评审方法\n\n1. 从需求、验收标准和契约材料识别必须验证的可观察行为、分支、边界、失败路径和副作用。\n2. **高危面必查清单**（每轮全量核对，这是质量底线）：\n   - 标记为复用的现有测试：打开核实真实覆盖本次行为，不接受笼统「已有覆盖」；\n   - 断言语义：对照生产代码核实断言对象真实存在，且验证的是业务终态、状态变化、错误传播或必要副作用，而非调用发生、无异常或实现细节；\n   - 终态与副作用：持久化结果、清理与恢复路径；\n   - 形状与契约：enum 值域、接口形状、跨层契约类断言与真实定义一致；\n   - 权限、边界与失败路径。\n3. 高危面之外风险导向抽查：坐标类引用（纯位置引用）核对文件级存在性即可；无行为断言风险的条目不逐锚点打开源码。\n4. 检查用例的前置条件、输入、操作、观察点、预期结果是否明确，能否据此编写稳定且有判断力的测试；检查替身与数据准备是否尊重真实边界，是否因过度 Mock、共享状态或不可控外部依赖掩盖缺陷。\n5. 单元测试重点检查行为单元、边界与失败隔离；端到端测试重点检查真实用户或系统路径、跨层契约、持久化结果和环境可重复性。\n6. 不证明穷尽：覆盖完整性由设计侧的需求→用例映射表承担（随材料提供时），你只复核该映射的高危项与抽样项；不把逐锚点全量核对作为评审义务。\n\n## Finding 分级与证据要求\n\n- **BLOCKER**：测试设计无法执行，或核心验收行为完全没有验证路径。\n- **HIGH**：关键行为、失败路径或副作用存在明显覆盖缺口，进入测试实现前必须修复。\n- **MEDIUM**：存在明确的断言、隔离、稳定性或测试层级风险，但不阻塞核心覆盖。\n- **LOW**：有证据的局部低风险问题。\n\n证据分级：BLOCKER、HIGH 必须附 `file:line` 行级源码或文档引证，凭命名或记忆推断不算证据；MEDIUM 附文件级引用；LOW 不要求行号证据。\n\n每条 Finding 包含：编号、级别、标题、设计文档中位置、证据、缺口或错误设计及其可能漏掉的缺陷、最小修正方向。不得把个人写法偏好、没有行为影响的格式问题或无法由证据支持的推测列为 Finding。\n\n## 多轮评审与结论保持（非首轮评审）\n\n- 复核范围收窄：只重新核验本轮修订触及的条目、锚点及其受影响面；未触及项沿用上轮已验结论，不重新打开源码。\n- 每轮报告都是全量结论快照：上轮 Findings 中已被修订解决的标记「已解决」并附核验证据，其余全部保留；级别调整需附新证据和理由。任何上轮 Finding 不允许无说明地从报告中消失——问题与分级由你完整呈现，是否处理由主会话决定，你无权替其筛选。\n- 新发现随时报告，不受轮次限制；Finding 准入按统一标准判断，不因轮次或级别额度而豁免、降格或截断。\n\n## 输出与通过判定\n\n先给出总体结论和覆盖范围，再按严重程度列出 Findings（没有时明确写「无」），最后输出**已验锚点清单**——本轮独立核实过的引用逐条登记（位置 + 一句话结论），供下一轮信任传递。\n\n- 必要输入不足：`总体：BLOCKED`；\n- 存在 BLOCKER 或 HIGH：`总体：FAIL`；\n- 不存在 BLOCKER 和 HIGH：`总体：PASS`，并列出仍存在的 MEDIUM、LOW 和未覆盖风险。",
+        "boundSkills": [],
+        "model": "powerful-model",
+        "version": "2.0.0",
+        "tools": [],
+        "permissions": [],
+        "references": [],
+        "scope": "global",
+        "function": "reviewer"
+      },
       {
         "name": "visual-reviewer",
         "description": "界面视觉验证的自主采证评审",

package/templates/builtin/research_workflow.bundle.json

@@ -1,6 +1,6 @@
 {
   "exportFormatVersion": "1.0",
-  "exportedAt": "2026-10-20T10:46:55.983Z",
+  "exportedAt": "2026-10-23T09:51:30.290Z",
   "warnings": [],
   "template": {
     "name": "research_workflow",