@siming-org/cli 0.8.4 → 0.8.5

package/dist/index.js

@@ -1844,7 +1844,9 @@ import { parse as parseYaml } from "yaml";
 import {
   BIZ_CODE_MESSAGES,
   bumpPatchOrPassthrough,
-  diffTemplateContent
+  diffTemplateContent,
+  findSameTrackForks,
+  simulateTrackChains
 } from "@siming-org/core";
 import {
   DagTemplateCreateSchema,
@@ -1897,6 +1899,17 @@ ${issues}`, httpStatus: 0 });
   }
   const input = parsed.data;
   const finalName = input.name;
+  const forkIssues = findSameTrackForks(input.nodes, input.edges);
+  if (forkIssues.length > 0) {
+    const detail = forkIssues.map((issue) => `\u8282\u70B9 ${issue.nodeId} \u6709 ${String(issue.count)} \u6761\u6307\u5411 ${issue.targetTrack} \u8F68\u8282\u70B9\u7684\u51FA\u8FB9`).join("\uFF1B");
+    return fail({
+      message: `${BIZ_CODE_MESSAGES.TEMPLATE_SAME_TRACK_FORK}\uFF08${detail}\uFF09`,
+      httpStatus: 0,
+      bizCode: "TEMPLATE_SAME_TRACK_FORK",
+      hint: "\u540C\u8F68\u51FA\u8FB9\u4EC5\u5141\u8BB8\u4E00\u6761\uFF1B\u8DF3\u8FC7\u53EF\u9009\u8282\u70B9\u7531\u526A\u679D\u6865\u63A5\u673A\u5236\u81EA\u52A8\u8865\u8FB9\uFF0C\u52FF\u624B\u5DE5\u6DFB\u52A0\u65C1\u8DEF\u76F4\u8FB9\uFF084 \u6761\u7ED3\u6784\u7EA6\u675F\u901F\u67E5\u89C1 siming flow compose \u8F93\u51FA\uFF09"
+    });
+  }
+  const trackChains = simulateTrackChains(input);
   const existingResult = await client.getJson(
     `/api/dag/templates?projectId=${encodeURIComponent(projectId)}&name=${encodeURIComponent(finalName)}&includeDisabled=true`
   );
@@ -1952,6 +1965,7 @@ ${issues}`, httpStatus: 0 });
     action,
     importVersion,
     resultVersion,
+    trackChains,
     ...existing?.id !== void 0 ? { targetId: existing.id } : {},
     ...existing?.version !== void 0 ? { serverVersion: existing.version } : {},
     ...existing?.enabled === false ? { enabled: false } : {},
@@ -2417,7 +2431,7 @@ var taskArgs = {
   // create / query
   templateId: z3.string().optional(),
   taskTitle: z3.string().optional(),
-  track: z3.string().optional(),
+  track: z3.union([z3.string(), z3.array(z3.string())]).optional(),
   type: hostNeutralEnum(z3.enum(TASK_TYPES)).optional(),
   skipNodes: z3.array(z3.string()).optional(),
   projectId: z3.string().optional(),
@@ -2666,7 +2680,7 @@ function createMcpServer() {
   const client = createClient(void 0, "mcp");
   server.tool(
     "siming_task",
-    "task \u8D44\u6E90\u57DF\u805A\u5408\u5DE5\u5177\uFF08\u4EFB\u52A1\u5168\u64CD\u4F5C\u7ECF\u672C\u5DE5\u5177 + action \u53C2\u6570\uFF09\u3002action \u5FC5\u586B\uFF1B\u8C03\u7528\u65B9\u5E94\u5728 fieldMask \u4E2D\u5217\u51FA\u672C\u6B21\u771F\u5B9E\u63D0\u4F9B\u7684\u53EF\u9009\u5B57\u6BB5\uFF0Cmask \u5916\u7531\u5BBF\u4E3B\u81EA\u52A8\u586B\u5145\u7684\u7A7A\u4E32\u3001\u7A7A\u6570\u7EC4\u3001false\u30010 \u5747\u5FFD\u7565\uFF0Cmask \u5185\u7A7A\u6570\u7EC4/false \u8868\u793A\u663E\u5F0F\u6E05\u7A7A\u6216\u5173\u95ED\uFF1B\u5404 action \u56FA\u5B9A\u5FC5\u586B\u5B57\u6BB5\u65E0\u9700\u5199\u5165 mask\u3002\u5176\u4F59\u53C2\u6570\u5168\u53EF\u9009\u3001\u6309 action \u8FD0\u884C\u65F6\u6821\u9A8C\u5FC5\u586B\uFF08\u7F3A\u5931\u8FD4\u56DE\u5931\u8D25\u4E09\u8981\u7D20\uFF1A\u5BF9\u8C61+\u6839\u56E0+\u4FEE\u590D\u6307\u5F15\uFF09\u3002projectId \u4E3A key|id \u53CC\u5F62\u6001\uFF0C\u901A\u9053\u5C42\u81EA\u52A8\u5F52\u4E00\u4E3A 24-hex id\uFF1B\u663E\u5F0F\u6307\u5B9A\u89E3\u6790\u5931\u8D25\u62A5\u9519\u4E0D\u515C\u5E95\uFF1B\u7F3A\u7701\u8BED\u4E49\u6309 action\uFF1Acreate \u843D\u9ED8\u8BA4\u9879\u76EE\u94FE\uFF08\u5DE5\u4F5C\u533A defaultProject \u5931\u6548\u62A5\u9519\uFF0C\u65E0\u914D\u7F6E\u4E0D\u4F20\u7531 server \u6309\u6A21\u677F\u5F52\u5C5E\u515C\u5E95\uFF09\uFF0Cquery \u4E0D\u8FC7\u6EE4\uFF08\u5168\u5C40\u67E5\u8BE2\uFF09\u3002\u5199\u64CD\u4F5C\uFF08create/doc-*/record-*/archnote-add/pause/resume/cancel\uFF09\u54CD\u5E94\u4E3A\u8F7B\u91CF\u56DE\u6267\uFF1A{taskId, updated(\u89E6\u53CA\u5B57\u6BB5\u8DEF\u5F84), entry(\u65B0\u6761\u76EE id+kind\uFF0C\u4F9B\u540E\u7EED patch \u5B9A\u4F4D), echo(\u5199\u5165\u5185\u5BB9\u56DE\u663E), updatedAt, task(\u4EFB\u52A1\u8FDB\u5EA6\u6458\u8981 progress: {completed,total})}\u2014\u2014\u4E0D\u8FD4\u56DE\u5B8C\u6574\u4EFB\u52A1\u5B9E\u4F53\u3002action \u6E05\u5355\uFF08\u62EC\u53F7\u5185\u4E3A\u8BE5 action \u5FC5\u586B\u53C2\u6570\uFF09\uFF1Acreate(templateId,taskTitle,track\uFF1B\u53EF\u9009 type=feature|bugfix|ui-tweak|research\u3001skipNodes\u3001projectId\uFF1BtemplateId \u652F\u6301 code|id \u53CC\u5F62\u6001\u2014\u2014code \u4E3A\u6A21\u677F\u4E1A\u52A1\u6807\u8BC6\uFF08\u9879\u76EE\u5185\u552F\u4E00\u3001kebab-case \u5FC5\u542B\u8FDE\u5B57\u7B26\uFF0C\u5982 full-workflow\uFF09\uFF0C\u63A8\u8350\u5F15\u7528\u5F62\u6001\uFF0C\u5BFB\u5740\u987B\u914D projectId \u6307\u5B9A\u9879\u76EE\u57DF\uFF1B24-hex \u6570\u636E\u5E93 id \u76F4\u67E5\u517C\u5BB9\uFF1Bcode \u5F62\u6001\u4E0D\u5B58\u5728\u65F6\u9519\u8BEF\u542B candidates \u76F8\u8FD1\u5019\u9009\u6E05\u5355\uFF08id/code/name \u22645 \u6761\uFF09\uFF1B\u54CD\u5E94 {task, firstNode}\u2014\u2014firstNode \u5373\u9996\u8282\u70B9\u5B8C\u6574\u8D44\u6599\u5305\uFF0C\u514D\u8C03 context)\uFF1Bquery(taskId \u8FD4\u56DE\u5355\u4EFB\u52A1\u8BE6\u60C5\uFF0C\u7F3A\u7701\u8FD4\u56DE\u5217\u8868\uFF0C\u53EF\u9009 status/track/projectId/page/limit)\uFF1Bcontext(taskId\uFF1B\u53EF\u9009 view=basic|full\u2014\u2014basic \u7F3A\u7701\u4E0D\u643A\u5E26 artifact \u5168\u6587\u5FEB\u7167\uFF0Cfull \u65AD\u70B9\u7EED\u8DD1\u9700\u5386\u53F2\u4EA7\u7269\u5168\u6587\u65F6\u7528\u3002\u26A0 \u514D\u91CD\u8BFB\uFF1Aadvance/approve \u6D41\u8F6C\u54CD\u5E94\u5DF2\u542B\u4E0B\u4E00\u8282\u70B9\u5B8C\u6574\u8D44\u6599\u5305\uFF0C\u540C\u4F1A\u8BDD\u5185\u6D41\u8F6C\u540E\u76F4\u63A5\u5F00\u5DE5\u3001\u65E0\u9700\u518D\u8C03 context\uFF1B\u4EC5\u65B0\u4F1A\u8BDD/\u65AD\u70B9\u7EED\u8DD1\u8C03\u7528)\uFF1Bnode(taskId,view=prompt|skills\uFF1BnodeId \u7F3A\u7701\u7528\u5F53\u524D\u8282\u70B9\uFF1B\u26A0 view \u503C\u968F action \u4E0D\u540C\uFF1Anode\u2192prompt|skills\uFF0Ccontext\u2192basic|full\uFF0C\u9519\u914D\u62A5\u9519)\uFF1Badvance(taskId\uFF1Bnote \u5199 history\u3001summary \u5199 nodeRecords\uFF0C\u4E24\u4F4D\u72EC\u7ACB\uFF1B\u54CD\u5E94\u5DF2\u542B\u4E0B\u4E00\u8282\u70B9\u8D44\u6599\u5305\uFF0C\u540C\u4F1A\u8BDD\u514D\u91CD\u8BFB context\u3002\u26A0 T202609230001 \u8282\u70B9\u95E8\u7981\uFF1A\u914D\u7F6E\u4E86 toolChecks/aiChecks \u7684\u8282\u70B9\u63A8\u8FDB\u524D\u81EA\u52A8\u6267\u884C\u68C0\u67E5\u2014\u2014fail \u4F1A\u88AB\u6253\u56DE\u5E76\u8FD4\u56DE\u9010\u9879\u4FEE\u590D\u6307\u5F15\uFF08\u7ED3\u679C\u5DF2\u5199 history checks_rejected\uFF09\uFF0C\u6309\u6307\u5F15\u4FEE\u590D\u6216\u83B7\u7528\u6237\u8C41\u514D\u7559\u75D5\u540E\u91CD\u63A8\uFF1B\u975E\u4EBA\u5DE5\u5BA1\u6279\u8282\u70B9\u7981\u6B62\u56E0\u95E8\u7981\u4E2D\u65AD\u4EFB\u52A1\uFF08\u6253\u56DE\u4FE1\u606F\u5373\u7EE7\u7EED\u4F9D\u636E\uFF09\u3002force+forceReason \u6210\u5BF9\u63D0\u4F9B\u65F6\u53EF\u8D8A\u8FC7 fail \u5F3A\u5236\u63A8\u8FDB\u2014\u2014\u4EC5\u51ED\u7528\u6237\u660E\u793A\u6307\u4EE4\uFF0CAI \u7981\u6B62\u81EA\u51B3\uFF0C\u7406\u7531\u539F\u6587\u843D history \u5BA1\u8BA1)\uFF1Bcheck(taskId\uFF1B\u95E8\u7981\u53EA\u8BFB\u9884\u68C0\u2014\u2014\u9010\u9879\u62A5\u544A\u4E0D\u5199\u4EFB\u4F55\u72B6\u6001\uFF0Cadvance \u524D\u81EA\u67E5\u7528)\uFF1Bapprove(taskId,decision=approved|rejected\uFF1B\u53EF\u9009 comment\uFF1B\u54CD\u5E94\u5DF2\u542B\u4E0B\u4E00\u8282\u70B9\u8D44\u6599\u5305\uFF0C\u540C\u4F1A\u8BDD\u514D\u91CD\u8BFB context)\uFF1Bpause(taskId\uFF1B\u53EF\u9009 reason)\uFF1Bresume(taskId\uFF1B\u53EF\u9009 resumeNote)\uFF1Bcancel(taskId\uFF1B\u53EF\u9009 reason 1-500 \u5B57\u7B26\uFF1B\u26A0 \u7EC8\u6001\u4E0D\u53EF\u9006\u2014\u2014active/paused \u53EF\u53D6\u6D88\uFF0Ccompleted/cancelled \u62D2\u7EDD\u5E76\u8FD4\u56DE TASK_TERMINATED\uFF1B\u53D6\u6D88\u540E\u7ECF\u672C\u5DE5\u5177\u7684\u6D41\u8F6C\u4E0E\u8BB0\u5F55\u5199\u64CD\u4F5C\u88AB\u62D2)\uFF1Bhistory(taskId)\uFF1Binstance(taskId\u2014\u2014\u67E5\u770B\u4EFB\u52A1 DAG \u5B9E\u4F8B\u5FEB\u7167\uFF1A\u521B\u5EFA\u4EFB\u52A1\u65F6\u51BB\u7ED3\u7684\u6A21\u677F\u5B9E\u4F8B\uFF0C\u6A21\u677F\u540E\u7EED\u53D8\u66F4\u4E0D\u56DE\u6EAF)\u3002\u8BB0\u5F55\u5199\u5165\uFF1Arecord-set(taskId,node\uFF1Bsummary \u4E0E\u516D\u4E2A\u7ED3\u6784\u5316\u5B57\u6BB5\uFF08baseBranch/verifiedCommit/fixesApplied/testReport/deferredIssues/evidenceFiles\uFF09\u81F3\u5C11\u5176\u4E00\u2014\u2014\u7ED3\u6784\u5316\u5B57\u6BB5\u6309\u8282\u70B9 prompt\u300C\u7ED3\u6784\u5316\u5B57\u6BB5\u5199\u5165\u8981\u6C42\u300D\u9010\u5B57\u6BB5\u843D\u5E93\uFF0CPATCH \u8BED\u4E49=\u4EC5\u66F4\u65B0\u63D0\u4F9B\u5B57\u6BB5)\uFF1Brecord-check-add(taskId,node,item\uFF1B\u53EF\u9009 passed \u7F3A\u7701 true\u3001refId=aiChecks \u81EA\u68C0\u7559\u75D5\u951A\uFF08\u5BA1\u8BA1\u8BA4 refId===aiCheck.id \u4E14 passed=true\uFF0C\u7F3A\u7559\u75D5\u7684\u5B8C\u6210\u5224\u5B9A\u5BA1\u8BA1 fail\uFF09\u3001source=self|tool \u672C\u7248\u5DE5\u5177\u7F3A\u7701\u4E0D\u5199\uFF1B\u6279\u91CF checkItems \u5143\u7D20\u540C\u6784\uFF1B\u56DE\u6267 entry.id \u4F9B record-check-patch \u5B9A\u4F4D)\uFF1Brecord-check-patch(taskId,node,checkId\uFF1B\u53EF\u9009 passed/item/refId/source\uFF0C\u4EC5\u66F4\u65B0\u63D0\u4F9B\u5B57\u6BB5)\uFF1Brecord-artifact-add(taskId,node,artifactType=prd|tech|code|test|doc|other\uFF1Bpath \u7EAF\u5F15\u7528 / file \u8BFB\u672C\u673A\u6587\u4EF6 / content \u76F4\u4F20\u5168\u6587\u2014\u2014file \u4E0E content\u3001file \u4E0E path \u4E92\u65A5\uFF0Ccontent \u53EF\u4E0E path \u6210\u5BF9\u6216\u5355\u72EC\uFF0C\u5355\u72EC\u65F6\u767B\u8BB0\u503C\u5408\u6210 mcp-inline/<type>\uFF1B\u53EF\u9009 note)\uFF1Brecord-confirm(taskId,node,quote\u2014\u2014\u6682\u505C\u70B9\u7528\u6237\u786E\u8BA4\u539F\u6587\u9010\u5B57)\uFF1Brecord-decision-add(taskId,node,topic,decisionText)\uFF1Brecord-review-set(taskId,node,verdict=pass|fail,rounds,critical)\u3002\u9700\u6C42\u6587\u6863\uFF1Adoc-set(taskId\uFF1Bwhat/why/trackNote \u81F3\u5C11\u4F20\u4E00)\uFF1Bdoc-acceptance-add(taskId,text)\uFF1Bdoc-non-goal-add(taskId,text)\u3002\u7D20\u6750\uFF1Aarchnote-add(taskId,text)\u3002\u6279\u91CF\u5F62\u6001\uFF08\u63A8\u8350\uFF0C\u516D\u7C7B\u540C\u6784\uFF09\uFF1Arecord-check-add \u4F20 checkItems=[{item,passed?}]\u3001record-artifact-add \u4F20 artifactEntries=[{artifactType,path?/file?/content?,note?}]\u3001record-decision-add \u4F20 decisionEntries=[{topic,decisionText}]\u3001doc-acceptance-add/doc-non-goal-add/archnote-add \u4F20 textItems=[string]\u2014\u2014\u6279\u91CF\u53C2\u6570\u4E0E\u5355\u6761\u53C2\u6570\u4E8C\u9009\u4E00\uFF0C\u4E00\u6B21\u8C03\u7528\u5199\u591A\u6761\uFF08\u4E0A\u9650 50 \u6761/\u6279\uFF0Cartifact \u5168\u6587\u5FEB\u7167\u603B\u91CF \u22642M \u5B57\u7B26/\u6279\uFF09\uFF1B\u90E8\u5206\u5931\u8D25\u4FDD\u7559\u6210\u529F\u6761\u76EE\u5E76\u9010\u6761\u62A5\u544A\uFF08failures[].index=\u539F\u59CB\u63D0\u4EA4\u5E8F\uFF0C\u53EA\u91CD\u8BD5\u5931\u8D25\u9879\uFF09\uFF0Capplied=0 \u6574\u4F53\u62A5\u5931\u8D25\u3002",
+    'task \u8D44\u6E90\u57DF\u805A\u5408\u5DE5\u5177\uFF08\u4EFB\u52A1\u5168\u64CD\u4F5C\u7ECF\u672C\u5DE5\u5177 + action \u53C2\u6570\uFF09\u3002action \u5FC5\u586B\uFF1B\u8C03\u7528\u65B9\u5E94\u5728 fieldMask \u4E2D\u5217\u51FA\u672C\u6B21\u771F\u5B9E\u63D0\u4F9B\u7684\u53EF\u9009\u5B57\u6BB5\uFF0Cmask \u5916\u7531\u5BBF\u4E3B\u81EA\u52A8\u586B\u5145\u7684\u7A7A\u4E32\u3001\u7A7A\u6570\u7EC4\u3001false\u30010 \u5747\u5FFD\u7565\uFF0Cmask \u5185\u7A7A\u6570\u7EC4/false \u8868\u793A\u663E\u5F0F\u6E05\u7A7A\u6216\u5173\u95ED\uFF1B\u5404 action \u56FA\u5B9A\u5FC5\u586B\u5B57\u6BB5\u65E0\u9700\u5199\u5165 mask\u3002\u5176\u4F59\u53C2\u6570\u5168\u53EF\u9009\u3001\u6309 action \u8FD0\u884C\u65F6\u6821\u9A8C\u5FC5\u586B\uFF08\u7F3A\u5931\u8FD4\u56DE\u5931\u8D25\u4E09\u8981\u7D20\uFF1A\u5BF9\u8C61+\u6839\u56E0+\u4FEE\u590D\u6307\u5F15\uFF09\u3002projectId \u4E3A key|id \u53CC\u5F62\u6001\uFF0C\u901A\u9053\u5C42\u81EA\u52A8\u5F52\u4E00\u4E3A 24-hex id\uFF1B\u663E\u5F0F\u6307\u5B9A\u89E3\u6790\u5931\u8D25\u62A5\u9519\u4E0D\u515C\u5E95\uFF1B\u7F3A\u7701\u8BED\u4E49\u6309 action\uFF1Acreate \u843D\u9ED8\u8BA4\u9879\u76EE\u94FE\uFF08\u5DE5\u4F5C\u533A defaultProject \u5931\u6548\u62A5\u9519\uFF0C\u65E0\u914D\u7F6E\u4E0D\u4F20\u7531 server \u6309\u6A21\u677F\u5F52\u5C5E\u515C\u5E95\uFF09\uFF0Cquery \u4E0D\u8FC7\u6EE4\uFF08\u5168\u5C40\u67E5\u8BE2\uFF09\u3002\u5199\u64CD\u4F5C\uFF08create/doc-*/record-*/archnote-add/pause/resume/cancel\uFF09\u54CD\u5E94\u4E3A\u8F7B\u91CF\u56DE\u6267\uFF1A{taskId, updated(\u89E6\u53CA\u5B57\u6BB5\u8DEF\u5F84), entry(\u65B0\u6761\u76EE id+kind\uFF0C\u4F9B\u540E\u7EED patch \u5B9A\u4F4D), echo(\u5199\u5165\u5185\u5BB9\u56DE\u663E), updatedAt, task(\u4EFB\u52A1\u8FDB\u5EA6\u6458\u8981 progress: {completed,total})}\u2014\u2014\u4E0D\u8FD4\u56DE\u5B8C\u6574\u4EFB\u52A1\u5B9E\u4F53\u3002action \u6E05\u5355\uFF08\u62EC\u53F7\u5185\u4E3A\u8BE5 action \u5FC5\u586B\u53C2\u6570\uFF09\uFF1Acreate(templateId,taskTitle,track\uFF1Btrack \u652F\u6301\u7EC4\u5408\u8F68\u9053\u2014\u2014\u6570\u7EC4\u5F62\u6001\uFF08\u5982 ["backend","godot"]\uFF0C\u6210\u5458=\u6CE8\u518C\u8868 active \u5355\u8F68\uFF09\u6216\u5355\u503C string\uFF1Ball \u4E3A\u4EFB\u52A1\u7EA7\u901A\u914D\uFF08\u6FC0\u6D3B\u521B\u5EFA\u65F6\u70B9\u5168\u90E8\u542F\u7528\u5355\u8F68\uFF0C\u5355\u503C\u4F7F\u7528\uFF09\uFF1B\u53EF\u9009 type=feature|bugfix|ui-tweak|research\u3001skipNodes\u3001projectId\uFF1BtemplateId \u652F\u6301 code|id \u53CC\u5F62\u6001\u2014\u2014code \u4E3A\u6A21\u677F\u4E1A\u52A1\u6807\u8BC6\uFF08\u9879\u76EE\u5185\u552F\u4E00\u3001kebab-case \u5FC5\u542B\u8FDE\u5B57\u7B26\uFF0C\u5982 full-workflow\uFF09\uFF0C\u63A8\u8350\u5F15\u7528\u5F62\u6001\uFF0C\u5BFB\u5740\u987B\u914D projectId \u6307\u5B9A\u9879\u76EE\u57DF\uFF1B24-hex \u6570\u636E\u5E93 id \u76F4\u67E5\u517C\u5BB9\uFF1Bcode \u5F62\u6001\u4E0D\u5B58\u5728\u65F6\u9519\u8BEF\u542B candidates \u76F8\u8FD1\u5019\u9009\u6E05\u5355\uFF08id/code/name \u22645 \u6761\uFF09\uFF1B\u54CD\u5E94 {task, firstNode}\u2014\u2014firstNode \u5373\u9996\u8282\u70B9\u5B8C\u6574\u8D44\u6599\u5305\uFF0C\u514D\u8C03 context)\uFF1Bquery(taskId \u8FD4\u56DE\u5355\u4EFB\u52A1\u8BE6\u60C5\uFF0C\u7F3A\u7701\u8FD4\u56DE\u5217\u8868\uFF0C\u53EF\u9009 status/track/projectId/page/limit)\uFF1Bcontext(taskId\uFF1B\u53EF\u9009 view=basic|full\u2014\u2014basic \u7F3A\u7701\u4E0D\u643A\u5E26 artifact \u5168\u6587\u5FEB\u7167\uFF0Cfull \u65AD\u70B9\u7EED\u8DD1\u9700\u5386\u53F2\u4EA7\u7269\u5168\u6587\u65F6\u7528\u3002\u26A0 \u514D\u91CD\u8BFB\uFF1Aadvance/approve \u6D41\u8F6C\u54CD\u5E94\u5DF2\u542B\u4E0B\u4E00\u8282\u70B9\u5B8C\u6574\u8D44\u6599\u5305\uFF0C\u540C\u4F1A\u8BDD\u5185\u6D41\u8F6C\u540E\u76F4\u63A5\u5F00\u5DE5\u3001\u65E0\u9700\u518D\u8C03 context\uFF1B\u4EC5\u65B0\u4F1A\u8BDD/\u65AD\u70B9\u7EED\u8DD1\u8C03\u7528)\uFF1Bnode(taskId,view=prompt|skills\uFF1BnodeId \u7F3A\u7701\u7528\u5F53\u524D\u8282\u70B9\uFF1B\u26A0 view \u503C\u968F action \u4E0D\u540C\uFF1Anode\u2192prompt|skills\uFF0Ccontext\u2192basic|full\uFF0C\u9519\u914D\u62A5\u9519)\uFF1Badvance(taskId\uFF1Bnote \u5199 history\u3001summary \u5199 nodeRecords\uFF0C\u4E24\u4F4D\u72EC\u7ACB\uFF1B\u54CD\u5E94\u5DF2\u542B\u4E0B\u4E00\u8282\u70B9\u8D44\u6599\u5305\uFF0C\u540C\u4F1A\u8BDD\u514D\u91CD\u8BFB context\u3002\u26A0 T202609230001 \u8282\u70B9\u95E8\u7981\uFF1A\u914D\u7F6E\u4E86 toolChecks/aiChecks \u7684\u8282\u70B9\u63A8\u8FDB\u524D\u81EA\u52A8\u6267\u884C\u68C0\u67E5\u2014\u2014fail \u4F1A\u88AB\u6253\u56DE\u5E76\u8FD4\u56DE\u9010\u9879\u4FEE\u590D\u6307\u5F15\uFF08\u7ED3\u679C\u5DF2\u5199 history checks_rejected\uFF09\uFF0C\u6309\u6307\u5F15\u4FEE\u590D\u6216\u83B7\u7528\u6237\u8C41\u514D\u7559\u75D5\u540E\u91CD\u63A8\uFF1B\u975E\u4EBA\u5DE5\u5BA1\u6279\u8282\u70B9\u7981\u6B62\u56E0\u95E8\u7981\u4E2D\u65AD\u4EFB\u52A1\uFF08\u6253\u56DE\u4FE1\u606F\u5373\u7EE7\u7EED\u4F9D\u636E\uFF09\u3002force+forceReason \u6210\u5BF9\u63D0\u4F9B\u65F6\u53EF\u8D8A\u8FC7 fail \u5F3A\u5236\u63A8\u8FDB\u2014\u2014\u4EC5\u51ED\u7528\u6237\u660E\u793A\u6307\u4EE4\uFF0CAI \u7981\u6B62\u81EA\u51B3\uFF0C\u7406\u7531\u539F\u6587\u843D history \u5BA1\u8BA1)\uFF1Bcheck(taskId\uFF1B\u95E8\u7981\u53EA\u8BFB\u9884\u68C0\u2014\u2014\u9010\u9879\u62A5\u544A\u4E0D\u5199\u4EFB\u4F55\u72B6\u6001\uFF0Cadvance \u524D\u81EA\u67E5\u7528)\uFF1Bapprove(taskId,decision=approved|rejected\uFF1B\u53EF\u9009 comment\uFF1B\u54CD\u5E94\u5DF2\u542B\u4E0B\u4E00\u8282\u70B9\u8D44\u6599\u5305\uFF0C\u540C\u4F1A\u8BDD\u514D\u91CD\u8BFB context)\uFF1Bpause(taskId\uFF1B\u53EF\u9009 reason)\uFF1Bresume(taskId\uFF1B\u53EF\u9009 resumeNote)\uFF1Bcancel(taskId\uFF1B\u53EF\u9009 reason 1-500 \u5B57\u7B26\uFF1B\u26A0 \u7EC8\u6001\u4E0D\u53EF\u9006\u2014\u2014active/paused \u53EF\u53D6\u6D88\uFF0Ccompleted/cancelled \u62D2\u7EDD\u5E76\u8FD4\u56DE TASK_TERMINATED\uFF1B\u53D6\u6D88\u540E\u7ECF\u672C\u5DE5\u5177\u7684\u6D41\u8F6C\u4E0E\u8BB0\u5F55\u5199\u64CD\u4F5C\u88AB\u62D2)\uFF1Bhistory(taskId)\uFF1Binstance(taskId\u2014\u2014\u67E5\u770B\u4EFB\u52A1 DAG \u5B9E\u4F8B\u5FEB\u7167\uFF1A\u521B\u5EFA\u4EFB\u52A1\u65F6\u51BB\u7ED3\u7684\u6A21\u677F\u5B9E\u4F8B\uFF0C\u6A21\u677F\u540E\u7EED\u53D8\u66F4\u4E0D\u56DE\u6EAF)\u3002\u8BB0\u5F55\u5199\u5165\uFF1Arecord-set(taskId,node\uFF1Bsummary \u4E0E\u516D\u4E2A\u7ED3\u6784\u5316\u5B57\u6BB5\uFF08baseBranch/verifiedCommit/fixesApplied/testReport/deferredIssues/evidenceFiles\uFF09\u81F3\u5C11\u5176\u4E00\u2014\u2014\u7ED3\u6784\u5316\u5B57\u6BB5\u6309\u8282\u70B9 prompt\u300C\u7ED3\u6784\u5316\u5B57\u6BB5\u5199\u5165\u8981\u6C42\u300D\u9010\u5B57\u6BB5\u843D\u5E93\uFF0CPATCH \u8BED\u4E49=\u4EC5\u66F4\u65B0\u63D0\u4F9B\u5B57\u6BB5)\uFF1Brecord-check-add(taskId,node,item\uFF1B\u53EF\u9009 passed \u7F3A\u7701 true\u3001refId=aiChecks \u81EA\u68C0\u7559\u75D5\u951A\uFF08\u5BA1\u8BA1\u8BA4 refId===aiCheck.id \u4E14 passed=true\uFF0C\u7F3A\u7559\u75D5\u7684\u5B8C\u6210\u5224\u5B9A\u5BA1\u8BA1 fail\uFF09\u3001source=self|tool \u672C\u7248\u5DE5\u5177\u7F3A\u7701\u4E0D\u5199\uFF1B\u6279\u91CF checkItems \u5143\u7D20\u540C\u6784\uFF1B\u56DE\u6267 entry.id \u4F9B record-check-patch \u5B9A\u4F4D)\uFF1Brecord-check-patch(taskId,node,checkId\uFF1B\u53EF\u9009 passed/item/refId/source\uFF0C\u4EC5\u66F4\u65B0\u63D0\u4F9B\u5B57\u6BB5)\uFF1Brecord-artifact-add(taskId,node,artifactType=prd|tech|code|test|doc|other\uFF1Bpath \u7EAF\u5F15\u7528 / file \u8BFB\u672C\u673A\u6587\u4EF6 / content \u76F4\u4F20\u5168\u6587\u2014\u2014file \u4E0E content\u3001file \u4E0E path \u4E92\u65A5\uFF0Ccontent \u53EF\u4E0E path \u6210\u5BF9\u6216\u5355\u72EC\uFF0C\u5355\u72EC\u65F6\u767B\u8BB0\u503C\u5408\u6210 mcp-inline/<type>\uFF1B\u53EF\u9009 note)\uFF1Brecord-confirm(taskId,node,quote\u2014\u2014\u6682\u505C\u70B9\u7528\u6237\u786E\u8BA4\u539F\u6587\u9010\u5B57)\uFF1Brecord-decision-add(taskId,node,topic,decisionText)\uFF1Brecord-review-set(taskId,node,verdict=pass|fail,rounds,critical)\u3002\u9700\u6C42\u6587\u6863\uFF1Adoc-set(taskId\uFF1Bwhat/why/trackNote \u81F3\u5C11\u4F20\u4E00)\uFF1Bdoc-acceptance-add(taskId,text)\uFF1Bdoc-non-goal-add(taskId,text)\u3002\u7D20\u6750\uFF1Aarchnote-add(taskId,text)\u3002\u6279\u91CF\u5F62\u6001\uFF08\u63A8\u8350\uFF0C\u516D\u7C7B\u540C\u6784\uFF09\uFF1Arecord-check-add \u4F20 checkItems=[{item,passed?}]\u3001record-artifact-add \u4F20 artifactEntries=[{artifactType,path?/file?/content?,note?}]\u3001record-decision-add \u4F20 decisionEntries=[{topic,decisionText}]\u3001doc-acceptance-add/doc-non-goal-add/archnote-add \u4F20 textItems=[string]\u2014\u2014\u6279\u91CF\u53C2\u6570\u4E0E\u5355\u6761\u53C2\u6570\u4E8C\u9009\u4E00\uFF0C\u4E00\u6B21\u8C03\u7528\u5199\u591A\u6761\uFF08\u4E0A\u9650 50 \u6761/\u6279\uFF0Cartifact \u5168\u6587\u5FEB\u7167\u603B\u91CF \u22642M \u5B57\u7B26/\u6279\uFF09\uFF1B\u90E8\u5206\u5931\u8D25\u4FDD\u7559\u6210\u529F\u6761\u76EE\u5E76\u9010\u6761\u62A5\u544A\uFF08failures[].index=\u539F\u59CB\u63D0\u4EA4\u5E8F\uFF0C\u53EA\u91CD\u8BD5\u5931\u8D25\u9879\uFF09\uFF0Capplied=0 \u6574\u4F53\u62A5\u5931\u8D25\u3002',
     taskArgs,
     async (rawArgs) => {
       const masked = applyFieldMask(rawArgs, TASK_FIELD_SPECS);
@@ -2709,7 +2723,9 @@ function createMcpServer() {
           return mcpContent(
             await handleListTasks(client, {
               ...args.status !== void 0 ? { status: args.status } : {},
-              ...args.track !== void 0 ? { track: args.track } : {},
+              // T202610120005：query 通道 track 收窄单值——列表按 trackAnchor 精确过滤；
+              // 数组形态（组合）收窄为 join('+') 规范串（=组合任务的 anchor 形态，语义等价）
+              ...args.track !== void 0 ? { track: Array.isArray(args.track) ? args.track.join("+") : args.track } : {},
               ...queryProjectId !== void 0 ? { projectId: queryProjectId } : {},
               ...args.page !== void 0 ? { page: args.page } : {},
               ...args.limit !== void 0 ? { limit: args.limit } : {}
@@ -3410,8 +3426,15 @@ function createTaskCommand() {
     const result = await handleQueryState(client, taskId);
     renderResult(opts.format, result, { fields: result.success ? taskFields(result.data) : [] });
   });
-  task.command("create").description("Create a task from a DAG template").option("--url <url>", "server base URL").requiredOption("--title <t>", "task title").requiredOption("--template <code|name|id>", "DAG template code (preferred), name, or 24-hex id (code/name resolved within project)").requiredOption("--track <t>", "task track (e.g. backend|ui|mixed|research \u2014 research \u4E3A\u8C03\u7814\u7C7B\u578B\u4E13\u7528\uFF0C\u987B\u914D --type research)").option("--type <t>", "task type (feature|bugfix|ui-tweak|research) \u2014 \u7C7B\u578B\u2192\u8DEF\u5F84\u6620\u5C04\u7531 task-create skill \u6301\u6709").option("--skip <ids>", "node ids to prune at creation (comma-separated, repeatable) \u2014 \u53EA\u5141\u8BB8\u6765\u81EA task-create skill \u7684\u6620\u5C04\u77E9\u9635", collectArgs, []).option("--project <key|id>", "projectId (key|id; defaults to workspace defaultProject then template projectId)").action(async (opts) => {
+  task.command("create").description("Create a task from a DAG template").option("--url <url>", "server base URL").requiredOption("--title <t>", "task title").requiredOption("--template <code|name|id>", "DAG template code (preferred), name, or 24-hex id (code/name resolved within project)").requiredOption("--track <t>", "task track \u2014 \u7EC4\u5408\u8F68\u9053\uFF1A\u53EF\u91CD\u590D flag \u6216\u9017\u53F7\u5206\u9694\uFF08\u5982 --track backend,godot\uFF09\uFF1B\u5355\u8F68/all \u901A\u914D\u4F20\u5355\u503C\uFF08all=\u6FC0\u6D3B\u5168\u90E8\u542F\u7528\u5355\u8F68\uFF1Bresearch \u987B\u914D --type research\uFF09", collectArgs, []).option("--type <t>", "task type (feature|bugfix|ui-tweak|research) \u2014 \u7C7B\u578B\u2192\u8DEF\u5F84\u6620\u5C04\u7531 task-create skill \u6301\u6709").option("--skip <ids>", "node ids to prune at creation (comma-separated, repeatable) \u2014 \u53EA\u5141\u8BB8\u6765\u81EA task-create skill \u7684\u6620\u5C04\u77E9\u9635", collectArgs, []).option("--project <key|id>", "projectId (key|id; defaults to workspace defaultProject then template projectId)").action(async (opts) => {
     const client = createClient(opts.url);
+    const rawTrack = typeof opts.track === "string" ? [opts.track] : opts.track ?? [];
+    const trackMembers = [...new Set(rawTrack.flatMap((s) => s.split(",")).map((s) => s.trim()).filter((s) => s.length > 0))];
+    if (trackMembers.length === 0) {
+      renderResult("json", { success: false, error: { message: "--track \u4E0D\u80FD\u4E3A\u7A7A\uFF08\u5355\u8F68/all \u901A\u914D\u5355\u503C\uFF1B\u7EC4\u5408\u8F68\u9053\u9017\u53F7\u5206\u9694\u6216\u91CD\u590D\u4F20 flag\uFF0C\u5982 --track backend,godot\uFF09", httpStatus: 0 } });
+      return;
+    }
+    const track = trackMembers.length === 1 ? trackMembers[0] : trackMembers;
     let type;
     if (opts.type !== void 0) {
       const r = parseEnum(opts.type, z5.enum(TASK_TYPES2), "--type");
@@ -3443,7 +3466,7 @@ function createTaskCommand() {
     }
     const result = await handleCreateTask(client, {
       title: opts.title,
-      track: opts.track,
+      track,
       dagTemplateId: templateRef,
       ...type !== void 0 ? { type } : {},
       ...skipNodes !== void 0 && skipNodes.length > 0 ? { skipNodes } : {},
@@ -5256,6 +5279,12 @@ function renderYamlImportOutcome(outcome, planOnly) {
     if (c.descriptionChanged) console.log("\u63CF\u8FF0\u6709\u53D8\u66F4");
     if (c.layoutChanged) console.log("\u5E03\u5C40\u6709\u53D8\u66F4");
   }
+  if (outcome.trackChains.length > 0) {
+    console.log("\u8F68\u9053\u94FE\u5E8F\uFF08\u6A21\u62DF\u526A\u679D\u6865\u63A5 + \u5F15\u64CE\u8DEF\u7531\uFF09:");
+    for (const tc of outcome.trackChains) {
+      console.log(`  ${tc.track}: ${tc.error !== void 0 ? `\u2717 ${tc.error}` : tc.chain.join(" \u2192 ")}`);
+    }
+  }
   if (outcome.id !== void 0) console.log(`\u6A21\u677F id: ${outcome.id}`);
   if (outcome.name !== void 0) console.log(`\u6A21\u677F\u540D: ${outcome.name}`);
 }
@@ -5801,7 +5830,8 @@ import { promisify as promisify2 } from "util";
 import { createInterface } from "readline/promises";
 import { Command as Command7 } from "commander";
 import {
-  SkillScopeSchema as SkillScopeSchema3
+  SkillScopeSchema as SkillScopeSchema3,
+  TEMPLATE_STRUCTURE_CONSTRAINTS
 } from "@siming-org/core";
 
 // src/commands/flow/manifest.ts
@@ -5812,7 +5842,8 @@ import {
   REFERENCE_LIMITS,
   SIMING_CODE_REGEX,
   SKILL_MAIN_DOC as SKILL_MAIN_DOC2,
-  createReferencesSchema as createReferencesSchema2
+  createReferencesSchema as createReferencesSchema2,
+  DagNodeTrackSchema
 } from "@siming-org/core";
 var FLOW_MANIFEST_FORMAT_VERSION = "1.2";
 var uniqueStrings = (values, ctx, label) => {
@@ -5846,7 +5877,8 @@ var nodePresetPayloadBaseSchema = z6.object({
   label: z6.string().min(1),
   nodeId: z6.string().regex(/^[A-Za-z0-9_-]+$/),
   phase: z6.string().min(1),
-  track: z6.string().min(1),
+  // T202610120005 R7：节点轨道 union（与 core DagNodeTrackSchema 同源）
+  track: DagNodeTrackSchema,
   prompt: z6.string().min(1),
   skills: capabilityRefsSchema,
   description: z6.string(),
@@ -6230,7 +6262,10 @@ ${conflicts.map((item) => `  ${item.kind}:${item.key} \u2014 ${item.reason ?? "\
       version: template.version,
       projectId: template.projectId,
       nodes: template.nodes.map((node) => ({ id: node.id, code: node.sourcePreset?.code ?? null })),
-      message: `\u7EC4\u5408 "${composition}" \u5DF2\u7EC4\u88C5\u4E3A\u6A21\u677F ${template.name}\uFF08${String(template.nodes.length)} \u8282\u70B9\uFF09`
+      message: `\u7EC4\u5408 "${composition}" \u5DF2\u7EC4\u88C5\u4E3A\u6A21\u677F ${template.name}\uFF08${String(template.nodes.length)} \u8282\u70B9\uFF09\u2014\u2014\u6A21\u677F\u7ED3\u6784\u7EA6\u675F\u901F\u67E5\uFF084 \u6761\u6B63\u53CD\u4F8B\uFF09\u89C1 structureConstraints \u5B57\u6BB5`,
+      // T202610120004 C3：结构约束速查（4 条正反例——配置者不读引擎源码也能写出单链轨道模板；
+      // 文案单源 core TEMPLATE_STRUCTURE_CONSTRAINTS，web 画布速查面板同源消费）
+      structureConstraints: TEMPLATE_STRUCTURE_CONSTRAINTS
     }));
   });
   return flow;
@@ -9123,7 +9158,7 @@ ${ROADMAP_TEXT}
   \u4E24\u5C42\u6982\u5FF5\u533A\u5206\uFF1A\u4EE5\u4E0A\u88C1\u526A\u662F\u6A21\u677F\u7EA7\u6C38\u4E45\u88C1\u526A\uFF08\u6539\u6A21\u677F\u5B9A\u4E49\uFF0C\u5F71\u54CD\u8BE5\u9879\u76EE
   \u6240\u6709\u540E\u7EED\u4EFB\u52A1\uFF09\uFF1B\u521B\u5EFA\u4EFB\u52A1\u65F6\u5F15\u64CE\u8FD8\u4F1A\u6309\u4EFB\u52A1\u8F68\u9053\u5BF9\u8282\u70B9 track \u81EA\u52A8\u526A\u679D
   \uFF08backend/ui/research \u53CA\u81EA\u5B9A\u4E49\u8F68\u9053\u4EFB\u52A1\u4FDD\u7559\u672C\u8F68\u9053+all \u8282\u70B9\uFF0C
-  mixed \u4EFB\u52A1\u4FDD\u7559\u53CC\u8F68\u5168\u94FE\uFF09\uFF0C\u8F68\u9053\u526A\u679D\u672C\u8EAB\u65E0\u9700\u624B\u52A8\u8DF3\u8FC7\u2014\u2014\u6A21\u677F\u5B58\u5728
+  \u7EC4\u5408\u4EFB\u52A1\u4FDD\u7559\u6210\u5458\u8F68\u5168\u94FE\uFF09\uFF0C\u8F68\u9053\u526A\u679D\u672C\u8EAB\u65E0\u9700\u624B\u52A8\u8DF3\u8FC7\u2014\u2014\u6A21\u677F\u5B58\u5728
   \u8F68\u9053\u526A\u679D\u540E\u4E0D\u88AB\u884C\u8D70\u7684\u5206\u652F\u65F6\uFF0C\u4ECD\u987B\u6309\u6A21\u677F\u5339\u914D\u89C4\u5219 skip \u989D\u5916\u88C1\u526A\uFF1B
   \u4EFB\u52A1\u7EA7\u8F68\u9053\u526A\u679D\u8BED\u4E49\u8BE6\u89C1 task-create \u5B9A\u5236\u9AA8\u67B6\u3002
 
@@ -9174,10 +9209,13 @@ ${MCP_TOOLING_TEXT}
 1. \u786E\u8BA4 server \u53EF\u8FBE\uFF1Asiming healthcheck\uFF08\u6216 siming doctor \u5168\u9762\u81EA\u68C0\uFF09\uFF1B
    \u5E76\u786E\u8BA4\u5BBF\u4E3B\u5DE5\u5177\u9762\u677F\u5DF2\u51FA\u73B0\u4E0A\u8FF0\u4E09\u4E2A siming MCP \u5DE5\u5177\u2014\u2014\u4EFB\u4E00\u7F3A\u5931\u65F6\uFF0C
    \u6309\u4E0A\u65B9\u300C\u5BBF\u4E3B\u517C\u5BB9\u6027\u81EA\u68C0\u4E0E\u9002\u914D\u300D\u5B8C\u6210\u590D\u5236\u6539\u5199\u4E0E\u843D\u70B9\u9002\u914D\uFF0C\u5BBF\u4E3B
-   \u4E0D\u652F\u6301 MCP \u65F6\u8D70 siming CLI \u515C\u5E95
+   \u4E0D\u652F\u6301 MCP \u65F6\u8D70 siming CLI \u515C\u5E95\u3002
+   opencode v2 \u5BBF\u4E3B\u63A5\u5165\u9996\u9009\u63D2\u4EF6\u5F62\u6001\uFF1Aopencode plugin add @siming-org/opencode-plugin
+   \u2014\u2014MCP \u4E09\u4EF6\u5DE5\u5177\u4E0E\u6280\u80FD/\u5B50\u4EE3\u7406\u7ECF\u63D2\u4EF6\u81EA\u52A8\u6CE8\u518C\u5E76\u968F server \u72B6\u6001\u4FDD\u6301\u65B0\u9C9C\uFF1B
+   .agents \u624B\u5DE5\u94FE\u8DEF\u4FDD\u7559\u4E3A\u65E0\u63D2\u4EF6\u73AF\u5883\u7684\u56DE\u9000\u8DEF\u5F84
 2. AI \u5BBF\u4E3B\u65B0\u4F1A\u8BDD\u52A0\u8F7D\u9879\u76EE\u7EA7 task-create\uFF0C\u6309\u5176\u5339\u914D\u89C4\u5219\u9009\u6A21\u677F\u4E0E\u526A\u679D
    \uFF08\u5224\u5B9A\u8F68\u9053\u540E\u5F15\u64CE\u6309\u8282\u70B9 track \u81EA\u52A8\u526A\u679D\uFF1A\u5355\u8F68\u4EFB\u52A1\u4FDD\u7559\u672C\u8F68\u9053+all \u8282\u70B9\uFF0C
-   mixed \u4EFB\u52A1\u4FDD\u7559\u53CC\u8F68\u5168\u94FE\uFF1Bskip \u4EC5\u7528\u4E8E\u8F68\u9053\u526A\u679D\u4E4B\u5916\u7684\u989D\u5916\u88C1\u526A\uFF0C
+   \u7EC4\u5408\u4EFB\u52A1\u4FDD\u7559\u6210\u5458\u8F68\u5168\u94FE\uFF1Bskip \u4EC5\u7528\u4E8E\u8F68\u9053\u526A\u679D\u4E4B\u5916\u7684\u989D\u5916\u88C1\u526A\uFF0C
    \u6A21\u677F\u5B58\u5728\u8F68\u9053\u526A\u679D\u540E\u4E0D\u88AB\u884C\u8D70\u7684\u5206\u652F\u65F6\u5FC5\u987B skip\uFF09
 3. \u521B\u5EFA\u9996\u4EFB\u52A1\uFF1A\u4EFB\u52A1\u5F15\u7528\u6A21\u677F\u4E00\u5F8B\u7528 code \u5F62\u6001\uFF08templateId \u4F20\u6A21\u677F code +
    projectId \u6307\u5B9A\u9879\u76EE\u57DF\uFF1B24 \u4F4D\u6570\u636E\u5E93 id \u517C\u5BB9\uFF09\u2014\u2014code \u7ECF
@@ -10085,8 +10123,17 @@ function createIssueCommand() {
     const result = await handleDoneIssue(client, issueId, opts.note);
     renderResult(opts.format ?? "fancy", result);
   });
-  withCommonOpts(issue.command("convert"), "fancy").requiredOption("--issue-ids <ids>", "comma-separated issue ids (or repeatable flag)", collectArgs, []).option("--declaration <mode>", "uniform declaration for all issues: all|partial (default all)").option("--declarations <map>", "per-issue declarations: id1:all,id2:partial (overrides --declaration)").requiredOption("--title <t>", "new task title").requiredOption("--template <code|name|id>", "DAG template code (preferred), name, or 24-hex id").requiredOption("--track <t>", "task track (backend|ui|mixed|research)").option("--type <t>", "task type (feature|bugfix|ui-tweak|research)").option("--skip <ids>", "node ids to prune (comma-separated, repeatable)", collectArgs, []).option("--project <key|id>", "projectId (key|id; issues and new task must belong to it)").description("Convert issues to a task (single group: N issues \u2192 1 task; split = multiple calls)").action(async (opts) => {
+  withCommonOpts(issue.command("convert"), "fancy").requiredOption("--issue-ids <ids>", "comma-separated issue ids (or repeatable flag)", collectArgs, []).option("--declaration <mode>", "uniform declaration for all issues: all|partial (default all)").option("--declarations <map>", "per-issue declarations: id1:all,id2:partial (overrides --declaration)").requiredOption("--title <t>", "new task title").requiredOption("--template <code|name|id>", "DAG template code (preferred), name, or 24-hex id").requiredOption("--track <t>", "task track \u2014 \u7EC4\u5408\u8F68\u9053\uFF1A\u53EF\u91CD\u590D flag \u6216\u9017\u53F7\u5206\u9694\uFF08\u5982 --track backend,godot\uFF09\uFF1B\u5355\u8F68/all \u901A\u914D\u4F20\u5355\u503C", collectArgs, []).option("--type <t>", "task type (feature|bugfix|ui-tweak|research)").option("--skip <ids>", "node ids to prune (comma-separated, repeatable)", collectArgs, []).option("--project <key|id>", "projectId (key|id; issues and new task must belong to it)").description("Convert issues to a task (single group: N issues \u2192 1 task; split = multiple calls)").action(async (opts) => {
     const client = createClient(opts.url);
+    const trackMembers = [...new Set((opts.track ?? []).flatMap((s) => s.split(",")).map((s) => s.trim()).filter((s) => s.length > 0))];
+    if (trackMembers.length === 0) {
+      renderResult("json", {
+        success: false,
+        error: { message: "--track \u4E0D\u80FD\u4E3A\u7A7A\uFF08\u5355\u8F68/all \u901A\u914D\u5355\u503C\uFF1B\u7EC4\u5408\u8F68\u9053\u9017\u53F7\u5206\u9694\u6216\u91CD\u590D\u4F20 flag\uFF09", httpStatus: 0 }
+      });
+      return;
+    }
+    const track = trackMembers.length === 1 ? trackMembers[0] : trackMembers;
     const issueIds = [
       ...new Set((opts.issueIds ?? []).flatMap((s) => s.split(",")).map((s) => s.trim()).filter((s) => s.length > 0))
     ];
@@ -10160,7 +10207,7 @@ function createIssueCommand() {
       issueIds,
       task: {
         title: opts.title,
-        track: opts.track,
+        track,
         dagTemplateId: templateRef,
         ...skipNodes !== void 0 && skipNodes.length > 0 ? { skipNodes } : {},
         ...type !== void 0 ? { type } : {}

package/package.json

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

package/templates/builtin/full_workflow.bundle.json

@@ -1,10 +1,10 @@
 {
   "exportFormatVersion": "1.0",
-  "exportedAt": "2026-09-26T15:30:41.833Z",
+  "exportedAt": "2026-10-12T09:03:35.947Z",
   "warnings": [],
   "template": {
     "name": "full_workflow",
-    "description": "通用软件开发全流程：PRD 设计与确认、分支对齐、完整技术方案双审，界面任务经交互设计节点产出可核对交互契约（含人工确认），按任务轨道进入后端或前端实现——后端轨完成单元测试、前端轨完成前端单元测试与界面呈现验证后汇合到端到端测试，经最终集成验证、发布验收与架构信息归档后收敛。feature 使用完整路径；bugfix 和界面微调可按任务配置跳过 PRD",
+    "description": "通用软件开发全流程：PRD 设计与确认、分支对齐，界面任务先经交互设计节点产出可核对交互契约（含人工确认，契约定案是技术方案的输入），再进入完整技术方案双审，按任务轨道进入后端或前端实现——后端轨完成单元测试、前端轨完成前端单元测试与界面呈现验证后汇合到端到端测试，经最终集成验证、发布验收与架构信息归档后收敛。feature 使用完整路径；bugfix 和界面微调可按任务配置跳过 PRD。本版修正节点顺序：INTERACTION 交互设计移至 ALIGN 与 DESIGN 之间（交互契约先于技术方案——契约定案是技术方案的输入；交互契约确认暂停点前置，DESIGN→CODE_BACKEND/CODE_UI 挂技术方案确认）",
     "nodes": [
       {
         "id": "PRD",
@@ -58,12 +58,33 @@
           }
         ]
       },
+      {
+        "id": "INTERACTION",
+        "label": "交互设计",
+        "phase": "entry",
+        "track": "ui",
+        "prompt": "# 交互设计\n\n## 节点职责\n\n把已确认需求中用户可见的交互意图，翻译为不依赖具体实现、可逐项核对的交互契约——界面结构与路径总览、状态矩阵、交互契约规则、键盘与焦点、反馈与播报、边界与内容策略、文案逐字稿、令牌绑定、自检清单——经独立对齐核验后，作为技术方案与编码节点的显式输入依赖、视觉验证的验收依据；用户确认由流程暂停点承载。本节点不编写生产代码、不做视觉审美裁定、不做技术选型、不产出可运行原型。\n\n## 依赖信息\n\n先检查当前任务上下文：PRD 或需求描述、验收标准、非目标、前序节点产物，以及项目和所属模块的提示词。加载 `workflow-discipline`；契约完成后调用 `alignment-reviewer` 核验契约与需求的回溯关系。\n\n本节点位于技术方案（DESIGN）之前：定案的交互契约是技术方案的直接输入——技术方案基于已确认的交互契约做实现设计，交互契约未经暂停点确认不得进入技术设计。\n\n形态层映射（Web/桌面/游戏引擎等）以 PRD/需求声明的产品形态与载体为准；载体未明确时先向用户澄清（澄清结论写入节点记录，供技术方案承接），不猜测。\n\n## 正向执行流程\n\n1. 从需求与交互澄清记录提取全部用户可见交互面：每个数据驱动视图、每个可触发元素、每条用户路径。任务无任何用户可见交互面时，判定本节点不适用，在节点记录写明判定与理由后推进。\n2. 逐项产出契约必备项，每项均可逐字核对、不依赖对话上下文：\n   - 界面结构与路径总览：布局用文本线框、状态流转用状态图、用户路径用流程图，以可渲染的图形语法内嵌契约文档（项目未约定时用 Mermaid），作为人工审阅的第一入口；\n   - 状态矩阵：每个数据驱动视图的 loading / empty / error / disabled 呈现定义与文案；\n   - 交互契约规则：触发元素、事件、效果元素、效果类型、效果位置、可逆性、目标状态；\n   - 键盘与焦点契约：Tab 顺序、初始焦点、Esc/Enter 语义、disabled 元素可聚焦策略；\n   - 反馈与播报机制：每个状态变更选用哪种机制（focus / role=status / live region 等）及理由；\n   - 边界与内容策略：最小支持宽度、320px 级重排、超长文本截断、大数据分页/滚动、空值文案；\n   - 文案逐字稿：含错误文案与空态文案，逐字给出，不留占位符；\n   - 令牌绑定：颜色、间距、圆角、字阶引用设计令牌，禁止裸值；\n   - 自检清单：实现者可逐项勾选的验收点清单，覆盖以上全部条款。\n3. 每条交互规则标注回溯来源（需求哪一条 / 澄清问答哪项结论）；无法回溯的条目视为新增需求，上升用户裁定后才可写入契约。\n4. 将契约全文保存为项目文档并登记任务产物（携带全文；超限时路径引用须说明理由），向用户呈现契约要点、自检清单核对结果与文档可读位置（作为暂停点审批材料）。\n5. 随后按通用层与形态层组织契约：通用层条款形态无关；形态层条款按已澄清的载体映射（HTML/CSS、UXML/USS、.tscn/Theme 等），映射关系写入契约。\n\n## 产出与检查\n\n推进前确认：\n\n- 全部必备产出（含界面结构与路径总览）齐全，不适用的单项已写明具体对象和理由；\n- 每条交互规则可回溯到需求或澄清记录，无发明需求；\n- 文案全部逐字给出，令牌引用无裸值；\n- 自检清单覆盖全部契约条款；\n- `alignment-reviewer` 对回溯关系的核验为 PASS，Findings 已处理或记录保留理由；\n- 审批材料（契约要点、自检清单核对结果、文档位置）已完整呈现，可支撑暂停点审批；\n- 契约文档已保存登记，呈现给用户的版本与确认版本一致。\n\n## 任务差异处理\n\n无用户可见交互面的任务：判定不适用并记录理由后推进，下游编码节点按「无契约」路径实现。信息不足以产出某项契约时，保留在本节点补齐或向用户澄清，不静默降级；确属可选项的增强（视觉基线、设计文件同步、动效规格）按需说明取舍，不默认纳入。\n\n可运行草图：默认不产出。用户点名要求审查辅助时，按当前版本契约生成静态草图到工作区 `temp/` 供用户在浏览器查看；草图是契约的派生视图而非第二设计来源——契约发生任何修订即作废重生成并重新呈现，草图页首声明「非契约正文，与契约不一致时以契约文档为准」，草图暴露的契约缺口只能回写契约修正，不在草图上直接改。草图不写入契约文档、不登记为任务产物，节点推进后即完成使命。\n\n## 节点记录与推进\n\n将契约文档产物与引用、必备产出核对结果、不适用判定及理由（如有）、草图辅助审查事实（如有，含生成路径与派生版本对应关系）、`alignment-reviewer` 结论与轮次、呈现给用户的审批材料索引写入当前节点记录（确认原文由暂停点审批记录承载，须逐字引用用户确认表态、不得转述失真；不双写），完成产出检查后推进下一节点。",
+        "skills": [
+          "workflow-discipline"
+        ],
+        "agents": [
+          "alignment-reviewer"
+        ],
+        "sourcePreset": {
+          "code": "interaction-design",
+          "version": "1.2.0",
+          "contentHash": "43263b2e99bd969a",
+          "agents": [
+            "alignment-reviewer"
+          ]
+        }
+      },
       {
         "id": "DESIGN",
         "label": "技术方案",
         "phase": "entry",
         "track": "all",
-        "prompt": "# 技术方案\n\n## 节点职责\n\n将已确认的产品需求转化为可直接指导实现和验证的技术方案，并通过需求对齐审查、架构评审建立实现基线；用户确认由流程暂停点承载。本节点只产出设计，不编写生产代码或测试代码。\n\n## 依赖信息\n\n检查当前任务上下文、需求与验收标准、非目标、PRD、前序节点产物、项目提示词和相关架构资料；已有信息直接复用，缺失时再加载。\n\n按名称加载：\n\n- `tech-design` Skill：技术方案设计方法及文档模板；\n- `workflow-discipline` Skill：执行、审查和暂停点纪律。\n\n方案完成后，依次调用：\n\n1. `alignment-reviewer` Agent：检查方案与需求的对齐关系；\n2. `arch-reviewer` Agent：检查方案的架构质量。\n\n## 正向执行流程\n\n1. 确认需求范围和后端、前端或混合轨道，并读取相关项目约束与现有架构。\n2. 使用 `tech-design` Skill 设计方案，并读取其 `references/template.md` 生成技术方案文档；方案默认包含架构图与核心功能流程图——用可渲染的图形语法表达（项目未约定时用 Mermaid），不使用文字罗列代替，且图中模块、步骤、分支在正文均有对应说明。\n3. 项目有文档目录时按项目声明保存方案文件；登记任务产物时必须携带方案全文（`record-artifact-add` 用 `file` 或 `content`），纯路径引用仅用于超过 200k 字符快照上限的文件，且须说明理由。\n4. 调用 `alignment-reviewer`。存在需求偏差时先修订方案，直至总体 `PASS`。\n5. 调用 `arch-reviewer`。处理 BLOCKER 和 HIGH；MEDIUM、LOW 逐项修订或记录保留理由，直至总体 `PASS`。\n6. 向用户呈现已保存的方案文档及其可读位置，以及方案摘要、关键取舍、两道审查结论和即将进入的实现轨道——用户在审批前必须能打开完整方案。\n7. 按项目分支规则创建任务分支；完成产出检查后推进，进入暂停点等待用户审批——审批通过即进入实现阶段，确认原文以审批记录留痕。\n\n## 产出检查\n\n推进前确认：\n\n- 技术方案全文可读取、已保存，登记值携带全文（超限时为路径引用且已说明理由）；\n- 文档符合 `tech-design` 模板使用规则，最低必备信息完整；\n- 方案默认包含架构图与核心功能流程图，以可渲染的图形呈现且与正文一致；确实不适用时已在“不适用项”写明具体对象和理由；\n- 需求、验收标准和非目标均有对应设计；\n- 按需设计已完成，或在“不适用项”中写明具体对象和理由；\n- `alignment-reviewer` 总体为 `PASS`；\n- `arch-reviewer` 总体为 `PASS`，其余 Finding 已处理或记录保留理由；\n- 审批材料（方案文档、摘要、关键取舍、审查结论、实现轨道）已完整呈现，可支撑暂停点审批；\n- 呈现给用户的方案文档可独立打开阅读，且与当前方案版本一致。\n\n## 任务差异处理\n\n没有独立 PRD 时，以任务需求、验收标准和非目标作为对齐基线。\n\n方案出现需要用户决定的产品方向、破坏性变更、新依赖或重大架构取舍时，先呈现选项、影响和建议。\n\n任一道审查处于 `BLOCKED` 或 `FAIL`，或项目约束与方案无法同时满足时，保留在本节点继续处理。\n\n## 节点记录与推进\n\n记录技术方案产物、方案摘要、关键决策与取舍、完成检查、两道审查的结论与轮次、Finding 处理结果、不适用项及理由，以及呈现给用户的审批材料索引（确认原文由暂停点审批记录承载，须逐字引用用户确认表态、不得转述失真；不双写）。\n\n全部产出检查满足后再推进；创建任务分支后，记录任务与分支的关联。",
+        "prompt": "# 技术方案\n\n## 节点职责\n\n将已确认的产品需求转化为可直接指导实现和验证的技术方案，并通过需求对齐审查、架构评审建立实现基线；用户确认由流程暂停点承载。本节点只产出设计，不编写生产代码或测试代码。\n\n## 依赖信息\n\n检查当前任务上下文、需求与验收标准、非目标、PRD、前序节点产物、项目提示词和相关架构资料；已有信息直接复用，缺失时再加载。\n\n存在交互契约产物时（ui 轨或组合任务含 ui 成员），以已确认的交互契约为技术方案的显式输入——实现设计须与契约定案一致。\n\n按名称加载：\n\n- `tech-design` Skill：技术方案设计方法及文档模板；\n- `workflow-discipline` Skill：执行、审查和暂停点纪律。\n\n方案完成后，依次调用：\n\n1. `alignment-reviewer` Agent：检查方案与需求的对齐关系；\n2. `arch-reviewer` Agent：检查方案的架构质量。\n\n## 正向执行流程\n\n1. 确认需求范围和后端、前端或混合轨道，并读取相关项目约束与现有架构。\n2. 使用 `tech-design` Skill 设计方案，并读取其 `references/template.md` 生成技术方案文档；方案默认包含架构图与核心功能流程图——用可渲染的图形语法表达（项目未约定时用 Mermaid），不使用文字罗列代替，且图中模块、步骤、分支在正文均有对应说明。\n3. 项目有文档目录时按项目声明保存方案文件；登记任务产物时必须携带方案全文（`record-artifact-add` 用 `file` 或 `content`），纯路径引用仅用于超过 200k 字符快照上限的文件，且须说明理由。\n4. 调用 `alignment-reviewer`。存在需求偏差时先修订方案，直至总体 `PASS`。\n5. 调用 `arch-reviewer`。处理 BLOCKER 和 HIGH；MEDIUM、LOW 逐项修订或记录保留理由，直至总体 `PASS`。\n6. 向用户呈现已保存的方案文档及其可读位置，以及方案摘要、关键取舍、两道审查结论和即将进入的实现轨道——用户在审批前必须能打开完整方案。\n7. 按项目分支规则创建任务分支；完成产出检查后推进，进入暂停点等待用户审批——审批通过即进入实现阶段，确认原文以审批记录留痕。\n\n## 产出检查\n\n推进前确认：\n\n- 技术方案全文可读取、已保存，登记值携带全文（超限时为路径引用且已说明理由）；\n- 文档符合 `tech-design` 模板使用规则，最低必备信息完整；\n- 方案默认包含架构图与核心功能流程图，以可渲染的图形呈现且与正文一致；确实不适用时已在“不适用项”写明具体对象和理由；\n- 需求、验收标准和非目标均有对应设计；\n- 按需设计已完成，或在“不适用项”中写明具体对象和理由；\n- `alignment-reviewer` 总体为 `PASS`；\n- `arch-reviewer` 总体为 `PASS`，其余 Finding 已处理或记录保留理由；\n- 审批材料（方案文档、摘要、关键取舍、审查结论、实现轨道）已完整呈现，可支撑暂停点审批；\n- 呈现给用户的方案文档可独立打开阅读，且与当前方案版本一致。\n\n## 任务差异处理\n\n没有独立 PRD 时，以任务需求、验收标准和非目标作为对齐基线。\n\n方案出现需要用户决定的产品方向、破坏性变更、新依赖或重大架构取舍时，先呈现选项、影响和建议。\n\n任一道审查处于 `BLOCKED` 或 `FAIL`，或项目约束与方案无法同时满足时，保留在本节点继续处理。\n\n## 节点记录与推进\n\n记录技术方案产物、方案摘要、关键决策与取舍、完成检查、两道审查的结论与轮次、Finding 处理结果、不适用项及理由，以及呈现给用户的审批材料索引（确认原文由暂停点审批记录承载，须逐字引用用户确认表态、不得转述失真；不双写）。\n\n全部产出检查满足后再推进；创建任务分支后，记录任务与分支的关联。",
         "skills": [
           "tech-design",
           "workflow-discipline"
@@ -74,8 +95,8 @@
         ],
         "sourcePreset": {
           "code": "design-tech",
-          "version": "1.7.0",
-          "contentHash": "5d62a31f3b2764f0",
+          "version": "1.8.0",
+          "contentHash": "c304f4b00638f9c0",
           "agents": [
             "alignment-reviewer",
             "arch-reviewer"
@@ -104,33 +125,12 @@
           }
         ]
       },
-      {
-        "id": "INTERACTION",
-        "label": "交互设计",
-        "phase": "entry",
-        "track": "ui",
-        "prompt": "# 交互设计\n\n## 节点职责\n\n把已确认的需求与技术方案中用户可见的交互意图，翻译为不依赖具体实现、可逐项核对的交互契约——界面结构与路径总览、状态矩阵、交互契约规则、键盘与焦点、反馈与播报、边界与内容策略、文案逐字稿、令牌绑定、自检清单——经独立对齐核验后，作为编码节点的显式输入依赖与视觉验证的验收依据；用户确认由流程暂停点承载。本节点不编写生产代码、不做视觉审美裁定、不做技术选型、不产出可运行原型。\n\n## 依赖信息\n\n先检查当前任务上下文：PRD 或需求描述、验收标准、非目标、技术方案（含形态与载体决策）、前序节点产物，以及项目和所属模块的提示词。加载 `workflow-discipline`；契约完成后调用 `alignment-reviewer` 核验契约与需求的回溯关系。\n\n形态层映射（Web/桌面/游戏引擎等）以技术方案的载体决策为准；技术方案未明确载体时先向用户澄清，不猜测。\n\n## 正向执行流程\n\n1. 从需求与技术方案提取全部用户可见交互面：每个数据驱动视图、每个可触发元素、每条用户路径。任务无任何用户可见交互面时，判定本节点不适用，在节点记录写明判定与理由后推进。\n2. 逐项产出契约必备项，每项均可逐字核对、不依赖对话上下文：\n   - 界面结构与路径总览：布局用文本线框、状态流转用状态图、用户路径用流程图，以可渲染的图形语法内嵌契约文档（项目未约定时用 Mermaid），作为人工审阅的第一入口；\n   - 状态矩阵：每个数据驱动视图的 loading / empty / error / disabled 呈现定义与文案；\n   - 交互契约规则：触发元素、事件、效果元素、效果类型、效果位置、可逆性、目标状态；\n   - 键盘与焦点契约：Tab 顺序、初始焦点、Esc/Enter 语义、disabled 元素可聚焦策略；\n   - 反馈与播报机制：每个状态变更选用哪种机制（focus / role=status / live region 等）及理由；\n   - 边界与内容策略：最小支持宽度、320px 级重排、超长文本截断、大数据分页/滚动、空值文案；\n   - 文案逐字稿：含错误文案与空态文案，逐字给出，不留占位符；\n   - 令牌绑定：颜色、间距、圆角、字阶引用设计令牌，禁止裸值；\n   - 自检清单：实现者可逐项勾选的验收点清单，覆盖以上全部条款。\n3. 每条交互规则标注回溯来源（需求哪一条 / 技术方案哪项决策）；无法回溯的条目视为新增需求，上升用户裁定后才可写入契约。\n4. 将契约全文保存为项目文档并登记任务产物（携带全文；超限时路径引用须说明理由），向用户呈现契约要点、自检清单核对结果与文档可读位置（作为暂停点审批材料）。\n5. 随后按通用层与形态层组织契约：通用层条款形态无关；形态层条款按技术方案载体映射（HTML/CSS、UXML/USS、.tscn/Theme 等），映射关系写入契约。\n\n## 产出与检查\n\n推进前确认：\n\n- 全部必备产出（含界面结构与路径总览）齐全，不适用的单项已写明具体对象和理由；\n- 每条交互规则可回溯到需求或技术方案，无发明需求；\n- 文案全部逐字给出，令牌引用无裸值；\n- 自检清单覆盖全部契约条款；\n- `alignment-reviewer` 对回溯关系的核验为 PASS，Findings 已处理或记录保留理由；\n- 审批材料（契约要点、自检清单核对结果、文档位置）已完整呈现，可支撑暂停点审批；\n- 契约文档已保存登记，呈现给用户的版本与确认版本一致。\n\n## 任务差异处理\n\n无用户可见交互面的任务：判定不适用并记录理由后推进，下游编码节点按「无契约」路径实现。信息不足以产出某项契约时，保留在本节点补齐或向用户澄清，不静默降级；确属可选项的增强（视觉基线、设计文件同步、动效规格）按需说明取舍，不默认纳入。\n\n可运行草图：默认不产出。用户点名要求审查辅助时，按当前版本契约生成静态草图到工作区 `temp/` 供用户在浏览器查看；草图是契约的派生视图而非第二设计来源——契约发生任何修订即作废重生成并重新呈现，草图页首声明「非契约正文，与契约不一致时以契约文档为准」，草图暴露的契约缺口只能回写契约修正，不在草图上直接改。草图不写入契约文档、不登记为任务产物，节点推进后即完成使命。\n\n## 节点记录与推进\n\n将契约文档产物与引用、必备产出核对结果、不适用判定及理由（如有）、草图辅助审查事实（如有，含生成路径与派生版本对应关系）、`alignment-reviewer` 结论与轮次、呈现给用户的审批材料索引写入当前节点记录（确认原文由暂停点审批记录承载，须逐字引用用户确认表态、不得转述失真；不双写），完成产出检查后推进下一节点。",
-        "skills": [
-          "workflow-discipline"
-        ],
-        "agents": [
-          "alignment-reviewer"
-        ],
-        "sourcePreset": {
-          "code": "interaction-design",
-          "version": "1.1.0",
-          "contentHash": "2e3855953b0a1bbd",
-          "agents": [
-            "alignment-reviewer"
-          ]
-        }
-      },
       {
         "id": "CODE_BACKEND",
         "label": "后端编码",
         "phase": "track",
         "track": "backend",
-        "prompt": "# 后端编码\n\n## 节点职责\n\n依据已确认的需求和技术方案完成后端生产代码，并通过项目静态检查和独立代码评审。测试设计、测试代码与测试执行由后续节点负责。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、技术方案、既有决策以及项目和所属模块的提示词。任务含界面交付（mixed 轨或交互设计节点已产出契约）时，读取已确认的交互契约，以契约定型 API 形态、字段语义与反馈行为，不自行猜测交互形态；确与后端约束冲突时说明冲突点并暂停上升，不单方面改约。加载 `coding-standards`、`workflow-discipline`，并按实际技术栈读取 `coding-standards` 对应 reference；调用独立 `code-reviewer` 评审实现。\n\n缺少实现所必需的需求、设计或项目约束时，先从任务上下文和仓库现状补齐；仍无法确定关键行为时，说明缺失信息并暂停，不猜测实现。\n\n## 执行流程\n\n1. 将需求、验收标准和技术方案整理为可核对的实现项，明确行为边界、错误处理、状态变化和副作用。\n2. 调查相关入口、调用链、数据模型、持久化、配置和既有接口，确认真实代码契约与项目惯例。\n3. 按最小充分范围实现生产代码，遵循项目分层和编码规范；只修改与本任务有关的生产代码，不修改测试、fixture 或其他验证代码，不清除无关注释。\n4. 处理配置、存储、兼容性、权限、并发和资源生命周期影响；不涉及的项目无需制造改动。\n5. 按项目声明执行适用的类型检查、编译、构建和静态分析，并保留可追溯结果。测试命令留给后续测试节点。\n6. 将需求、技术方案、项目约束和代码变更位置交给 `code-reviewer` 独立评审，不提供主会话结论或预期结果。修复 BLOCKER 和 HIGH Findings 后重新评审，直至获得 PASS；MEDIUM、LOW 逐项处理或记录保留理由。\n\n## 产出与检查\n\n推进前确认：\n\n- 需求、设计与生产实现可以逐项对应；\n- 生产代码完成，未修改验证代码，未清除无关注释；\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依据已确认的需求和技术方案完成后端生产代码，并通过项目静态检查和独立代码评审。测试设计、测试代码与测试执行由后续节点负责。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、技术方案、既有决策以及项目和所属模块的提示词。任务含界面交付（组合任务含 ui 成员或交互设计节点已产出契约）时，读取已确认的交互契约，以契约定型 API 形态、字段语义与反馈行为，不自行猜测交互形态；确与后端约束冲突时说明冲突点并暂停上升，不单方面改约。加载 `coding-standards`、`workflow-discipline`，并按实际技术栈读取 `coding-standards` 对应 reference；调用独立 `code-reviewer` 评审实现。\n\n缺少实现所必需的需求、设计或项目约束时，先从任务上下文和仓库现状补齐；仍无法确定关键行为时，说明缺失信息并暂停，不猜测实现。\n\n## 执行流程\n\n1. 将需求、验收标准和技术方案整理为可核对的实现项，明确行为边界、错误处理、状态变化和副作用。\n2. 调查相关入口、调用链、数据模型、持久化、配置和既有接口，确认真实代码契约与项目惯例。\n3. 按最小充分范围实现生产代码，遵循项目分层和编码规范；只修改与本任务有关的生产代码，不修改测试、fixture 或其他验证代码，不清除无关注释。\n4. 处理配置、存储、兼容性、权限、并发和资源生命周期影响；不涉及的项目无需制造改动。\n5. 按项目声明执行适用的类型检查、编译、构建和静态分析，并保留可追溯结果。测试命令留给后续测试节点。\n6. 将需求、技术方案、项目约束和代码变更位置交给 `code-reviewer` 独立评审，不提供主会话结论或预期结果。修复 BLOCKER 和 HIGH Findings 后重新评审，直至获得 PASS；MEDIUM、LOW 逐项处理或记录保留理由。\n\n## 产出与检查\n\n推进前确认：\n\n- 需求、设计与生产实现可以逐项对应；\n- 生产代码完成，未修改验证代码，未清除无关注释；\n- 配置、存储、兼容性和其他副作用已正确处理；\n- 适用的静态检查通过并留有结果；\n- `code-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明；\n- 生产代码和必要说明已形成可引用产物。\n\n## 任务差异处理\n\n新增依赖、破坏性变更、数据迁移、公开契约变化或真实范围扩张需要用户决定时，先呈现必要性和影响再暂停。某项检查因技术栈或任务性质不适用时，说明理由，不得静默跳过；执行障碍和评审修订按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将实现摘要、主要变更、静态检查结果、代码产物引用、关键决策、未适用项及理由、`code-reviewer` 结论与 Findings 处理情况写入当前节点记录。完成上述检查后推进下一节点。",
         "skills": [
           "coding-standards",
           "workflow-discipline"
@@ -552,34 +552,38 @@
           "autoResume": false
         }
       },
+      {
+        "from": "ALIGN",
+        "to": "INTERACTION"
+      },
       {
         "from": "ALIGN",
         "to": "DESIGN"
       },
       {
-        "from": "DESIGN",
-        "to": "INTERACTION",
+        "from": "INTERACTION",
+        "to": "DESIGN",
         "pausePoint": {
           "type": "human_approval",
-          "description": "技术方案确认（技术方案 → 编码/交互设计阶段；须呈现方案摘要 + 评审结果 + 激活轨道列表）",
+          "description": "交互契约确认（交互设计 → 技术方案；须呈现契约要点摘要 + 自检清单核对结果 + 不适用判定（如有）；确认后交互契约定案，技术方案基于定案契约设计）",
           "autoResume": false
         }
       },
       {
-        "from": "INTERACTION",
+        "from": "DESIGN",
         "to": "CODE_BACKEND",
         "pausePoint": {
           "type": "human_approval",
-          "description": "交互契约确认（交互设计 → 后端编码；须呈现契约要点摘要 + 自检清单核对结果 + 不适用判定如有）",
+          "description": "技术方案确认（技术方案 → 后端编码；须呈现方案摘要 + 评审结果 + 激活轨道）",
           "autoResume": false
         }
       },
       {
-        "from": "INTERACTION",
+        "from": "DESIGN",
         "to": "CODE_UI",
         "pausePoint": {
           "type": "human_approval",
-          "description": "交互契约确认（交互设计 → 前端编码；须呈现契约要点摘要 + 自检清单核对结果 + 不适用判定如有）",
+          "description": "技术方案确认（技术方案 → 前端编码；须呈现方案摘要 + 评审结果 + 激活轨道）",
           "autoResume": false
         }
       },
@@ -714,16 +718,16 @@
       }
     },
     "isDefault": false,
-    "version": "3.6.4"
+    "version": "3.7.0"
   },
   "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. **推进节点**：推进前先核对当前节点资料包的检查项——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- 任务终止前，不推荐、不询问、不切换到下一个任务；终止后再输出完整任务总结。",
+        "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- 多轮复审优先在同一 reviewer 会话内续聊（宿主支持会话续用时传会话标识，reviewer 已持有上轮评审上下文）；换新会话时，重审 prompt 随附上轮全量 Findings 与处置状态（已修复待验证 / 记录保留理由），reviewer 只重验本轮修订触及的条目与受影响面，未触及项沿用上轮结论；每轮报告保持全量 Findings 快照，已解决的标记关闭、不静默丢弃，是否处理由主会话决策。\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.4.0",
+        "version": "1.5.0",
         "references": [],
         "scope": "global"
       },
@@ -796,7 +800,128 @@
         "scope": "global"
       }
     ],
-    "agents": [],
-    "modelAliases": []
+    "agents": [
+      {
+        "name": "prd-reviewer",
+        "description": "PRD 文档评审（价值、完整性、清晰性与可行性）",
+        "systemPrompt": "你是 PRD 的独立只读评审者。判断 PRD 是否足以让不了解当前对话的设计者、实现者和验收者理解产品目标、行为边界与验收依据。\n\n## 工作边界\n\n- 只读取评审对象及明确提供的评审目标与材料；不接受主会话的设计结论、修订理由、“用户已确认”或预期评审结果作为通过证据。\n- 只评审，不修改文档、不写代码、不执行命令、不委派其他 Agent，也不接管多轮评审协调。\n- 只判断产品需求的 What 和 Why，不设计技术架构，不推荐类、接口、数据库、框架或文件组织。\n- 文档无法读取，或缺少评审所必需的客观输入时，输出 BLOCKED 并说明缺失项，不猜测内容，也不将输入缺失误判为 PRD 缺陷。\n\n## 评审方法\n\n1. 识别 PRD 声明的问题、价值、目标用户、范围和非目标。\n2. 从关键用户场景追踪到功能行为、业务规则、异常边界和验收标准。\n3. 检查各部分是否完整、一致、可理解、可验证，并区分阻塞交付的问题与改进建议。\n4. 仅依据 PRD 原文与提供的评审材料形成结论；没有原文证据时不得声称需求已覆盖。\n\n## 评审维度\n\n1. **价值与场景**：问题、价值、目标用户和关键场景是否明确且互相一致；是否避免把预设解决方案直接当成用户问题。\n2. **功能与规则**：核心行为、业务规则、状态或权限差异、异常边界、必要的非功能要求和非目标是否足以界定本次范围。\n3. **清晰性与一致性**：不了解当前对话的读者能否独立理解；术语、规则、范围、假设和开放问题是否无矛盾；是否保持 What/Why 边界。\n4. **可验证性与可行性**：核心行为是否具有可观察、可判定的验收结果；开放问题是否说明影响；需求是否在已知项目约束下具备实现可能。\n\n## Finding 分级\n\n- **BLOCKER**：缺失或矛盾会导致范围、用户可见行为、业务规则或验收结论无法确定。\n- **WARNING**：不阻塞实施和验收，但会降低文档清晰度、可维护性或边界表达。\n- **SUGGESTION**：可选改进，不影响通过结论。\n\n每个 Finding 必须包含：\n\n- 维度与级别；\n- PRD 原文引用或明确指出缺失位置；\n- 问题及其实际影响；\n- 保持产品层表达的最小修复方向。\n\n不得把个人偏好、固定章节格式、篇幅、评分、商业模式、ROI、竞品分析或技术实现建议列为 Finding，除非当前需求或提供的评审材料明确要求。\n\n## 输出格式\n\n先输出四个维度的逐项结论：\n\n- `PASS`：没有 BLOCKER；\n- `FAIL`：存在至少一个 BLOCKER；\n- `BLOCKED`：输入不足，无法完成该维度判断。\n\n随后列出 Findings，按 BLOCKER、WARNING、SUGGESTION 排序；没有 Finding 时明确写“无”。\n\n最后输出总体结论：\n\n- 任一维度为 BLOCKED → `总体：BLOCKED`；\n- 存在任一 BLOCKER → `总体：FAIL`；\n- 没有 BLOCKER → `总体：PASS`，并单独列出不阻塞通过的 WARNING 和 SUGGESTION。\n\n完成本次评审报告后立即结束；文档修订、Finding 取舍和重新评审由主会话负责。",
+        "boundSkills": [],
+        "model": "powerful-model",
+        "version": "1.3.1",
+        "tools": [],
+        "permissions": [],
+        "references": [],
+        "scope": "global",
+        "function": "reviewer"
+      },
+      {
+        "name": "alignment-reviewer",
+        "description": "PRD 与技术方案对齐审查",
+        "systemPrompt": "你是 PRD 与技术方案的独立只读审查者，负责判断技术方案是否完整、准确地落实产品需求。\n\n只评审对齐关系，不评价架构质量，不修改文档、不写代码、不执行命令、不委派其他 Agent。完成报告后立即结束。\n\n## 审查流程\n\n1. 逐项核对 PRD 功能需求，确认技术方案有对应设计，且没有超出需求范围的扩张。\n2. 核对用户流程、业务规则、状态、权限、异常和边界，确认两份文档没有遗漏或矛盾。\n3. 逐项核对验收标准，确认技术方案提供了足以支持实现和验证的设计。\n4. 核对非目标，确认技术方案没有将明确排除的内容纳入范围。\n\n## 输出要求\n\n对每个检查项输出：\n\n- PRD 条目及原文；\n- 技术方案对应章节及原文；没有对应内容时明确写“缺失”；\n- 结论：`ALIGNED` 或 `MISALIGNED`；\n- 偏差影响和最小修正方向。\n\n最后汇总：\n\n- 文档不可读取或缺少必要输入：`总体：BLOCKED`；\n- 存在任一 `MISALIGNED`：`总体：FAIL`；\n- 全部对齐：`总体：PASS`。\n\n只依据两份文档中的证据判断。不得用主会话结论、“用户已确认”或推测补全缺失内容，也不得提出具体技术实现方案。",
+        "boundSkills": [],
+        "model": "powerful-model",
+        "version": "1.2.0",
+        "tools": [],
+        "permissions": [],
+        "references": [],
+        "scope": "global",
+        "function": "reviewer"
+      },
+      {
+        "name": "arch-reviewer",
+        "description": "技术方案架构评审",
+        "systemPrompt": "你是技术方案的独立只读架构评审者，负责判断方案是否完整、可行，并以合理复杂度解决实际问题。\n\n只评审，不修改文档、不写代码、不执行命令、不委派其他 Agent，也不接管多轮协调。完成报告后立即结束。\n\n## 评审原则\n\n- 先理解业务目标、需求约束和项目现状，再评价技术选择。\n- 评价具体取舍，不机械套用“最佳实践”；新增抽象和复杂度必须有明确收益。\n- 每个问题必须引用方案或项目约束中的具体证据，不凭假设制造风险。\n- 优先关注会影响正确性、数据安全、可恢复性和交付可行性的问题。\n- 在效果相近时，优先选择更简单、可逆、容易验证的方案。\n\n## 评审内容\n\n根据方案实际范围检查：\n\n1. **职责与边界**：模块、服务和层次划分是否清楚，有无职责重叠、遗漏或不必要拆分。\n2. **核心流程**：主流程、异常流程、状态变化和关键副作用是否完整且顺序正确。\n3. **数据与接口**：数据模型、约束、关系、接口输入输出、错误响应和一致性边界是否明确。\n4. **失败与恢复**：部分失败、重试、幂等、并发、事务、回滚和外部依赖故障是否得到适当处理。\n5. **安全与权限**：身份、授权、输入边界、敏感信息和跨项目或跨租户隔离是否符合需求。\n6. **兼容与迁移**：存量数据、既有调用方、版本升级、部署顺序和回退路径是否可执行。\n7. **性能与可维护性**：性能措施是否与真实负载匹配；方案是否容易理解、测试、观测和后续修改。\n8. **项目约束**：方案是否符合项目声明的技术栈、目录、配置、测试和部署规则。\n9. **验证闭环**：关键设计是否有对应测试或验证方式，风险是否可以通过可观察证据判断。\n10. **自由发现**：除上述内容外，指出最可能导致上线事故或实施返工的问题。\n\n不适用于当前方案的维度应注明理由，不因缺少无关章节判定失败。\n\n## Finding 分级\n\n- **BLOCKER**：方案无法正确实施，或会造成严重数据、安全、兼容性问题。\n- **HIGH**：关键路径存在明显设计缺口，实施前必须解决。\n- **MEDIUM**：不阻塞实施，但会显著增加维护、测试或运行风险。\n- **LOW**：局部清晰度或可选优化问题。\n\n每条 Finding 必须包含：\n\n- 编号、级别和所属维度；\n- 具体文档章节或项目约束证据；\n- 对实现或运行结果的实际影响；\n- 最小修正方向。\n\n不得把个人风格偏好、不适用的通用实践或没有证据的假设列为 Finding。\n\n## 输出与通过判定\n\n先逐项给出各评审维度的 `PASS / FAIL / N/A` 及简要依据，再按严重程度输出 Findings。\n\n最后给出总体结论：\n\n- 文档不可读取或缺少完成评审所必需的输入：`总体：BLOCKED`；\n- 存在 BLOCKER 或 HIGH：`总体：FAIL`；\n- 不存在 BLOCKER 和 HIGH：`总体：PASS`，并单独列出未阻塞的 MEDIUM、LOW 和已知风险。",
+        "boundSkills": [],
+        "model": "powerful-model",
+        "version": "1.2.0",
+        "tools": [],
+        "permissions": [],
+        "references": [],
+        "scope": "global",
+        "function": "reviewer"
+      },
+      {
+        "name": "code-reviewer",
+        "description": "代码实现与设计一致性评审",
+        "systemPrompt": "你是代码实现的独立只读评审者，负责发现代码中的真实缺陷，并判断实现是否正确落实需求和技术方案。\n\n只评审，不修改代码或文档、不执行命令、不委派其他 Agent，也不接管修订和多轮协调。完成报告后立即结束。\n\n## 评审依据\n\n读取需求、验收标准、非目标、已确认的技术方案、项目及所属模块的提示词、本次代码变更和必要的相关现有代码。\n\n依据这些评审材料与评审目标、结合你的代码审查能力独立发现问题。不加载编码执行阶段的通用 Skill，不把固定检查清单当作评审范围上限，也不得使用主会话结论、“用户已确认”或预期结果代替证据。\n\n缺少完成评审所必需的设计、代码或项目约束时，输出 `总体：BLOCKED` 并列出缺失项，不猜测实现行为。\n\n## 评审方法\n\n1. 从需求、验收标准和技术方案识别实现必须具备的行为、边界和副作用。\n2. 读取本次变更并沿相关调用链进入方法体，不能只凭文件名、类型、签名、注解或字段名称判断对齐。\n3. 从入口到出口追踪数据变换、状态变化、错误传播、资源生命周期、持久化、外部调用、事件和其他副作用。\n4. 区分实现方式不同但可观察行为等价的情况，与会改变产品结果、数据或运行语义的实质偏离。\n5. 结合项目现有代码自由检查正确性、安全、兼容性、并发、性能和可维护性问题。\n\n重点覆盖四个方向，但不限于此：\n\n- **设计与行为一致性**：需求、验收和方案是否真正落实，有无遗漏、错误实现或范围外扩张。\n- **正确性与边界**：数据、状态、错误、资源、事务、并发、幂等、批量、重试及副作用顺序是否正确。\n- **安全与兼容**：输入、权限、敏感信息、隔离、公开接口和存量行为是否得到保护。\n- **自由发现**：任何可能导致缺陷、回归、数据损坏、运行故障或显著维护风险的问题。\n\n## Finding 分级\n\n- **BLOCKER**：核心行为无法完成，或存在严重数据损坏、安全、权限、隔离及不可恢复风险。\n- **HIGH**：关键路径、边界或副作用明显错误，进入后续测试前必须修复。\n- **MEDIUM**：不阻塞核心行为，但存在明确的可靠性、兼容性或维护风险。\n- **LOW**：有证据的局部低风险问题。\n\n每条 Finding 必须包含：\n\n- 编号、级别和标题；\n- 代码文件与行号；\n- 对应需求或设计证据；设计未规定时明确说明；\n- 代码的实际行为及其影响；\n- 最小修正方向。\n\n不得把个人风格偏好、formatter 能处理的问题、没有证据的推测或单纯“与我的实现习惯不同”列为 Finding。实现方式不同但行为等价时，不得判为缺陷。\n\n## 输出与通过判定\n\n先给出总体结论，再按严重程度列出 Findings；没有 Finding 时明确写“无”。无需输出无问题项的逐项检查表。\n\n- 必要输入不足：`总体：BLOCKED`；\n- 存在 BLOCKER 或 HIGH：`总体：FAIL`；\n- 不存在 BLOCKER 和 HIGH：`总体：PASS`，并列出仍存在的 MEDIUM、LOW 和未被设计说明的新行为。",
+        "boundSkills": [],
+        "model": "powerful-model",
+        "version": "1.2.1",
+        "tools": [],
+        "permissions": [],
+        "references": [],
+        "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": "界面视觉验证的自主采证评审",
+        "systemPrompt": "你是界面视觉验证的自主采证评审者，在独立 subagent 会话内完成「驱动界面 → 采集证据 → 分析判定」的完整闭环：自己操作浏览器到达目标视觉状态、自己截图取证、自己分析判定，不依赖主会话预备的截图或结论。\n\n边界：只做采证与分析——不修改代码或文档、不执行测试或构建命令、不委派其他 Agent、不接管修复与多轮协调；评估范围以委派给定的场景清单为界，不自行扩张到清单外页面与断言。完成报告后立即结束。\n\n## 采证流程\n\n1. 读取委派材料：运行地址、认证方式（如有）、数据前置说明、场景清单（场景 × 呈现断言 × 锚点）、需求与设计依据。\n2. 打开运行地址，按场景清单驱动浏览器到达目标状态（导航、交互、等待渲染稳定）；到达失败时先自查操作与网络并重试，仍失败按 BLOCKED 处理并记录已尝试轨迹。\n3. 在代表性视口采集截图（桌面为主，响应式场景按清单补充移动宽度），证据文件落委派指定的证据目录（缺省工作区 temp/），文件名含场景与步骤语义；每条锚点至少有一份对应证据。\n4. 结合所见继续取证：断言存疑时换视口、跟进交互前后对比、查看控制台错误，直至每条锚点可判；不把行为断言（请求结果、状态推导、持久化结果）纳入评审，采证中发现明显行为异常记录为观察项交回。\n5. 材料缺口自查：某锚点证据不足时先自行补采；运行地址不可达、认证信息缺失或场景说明自相矛盾导致无法验证时，才输出 `总体：BLOCKED` 并列出缺失项与已尝试轨迹，不猜测不可见状态。\n\n## 评审方法\n\n1. 确认每份证据对应的页面、状态、视口和操作阶段，区分实际所见与场景说明。\n2. 检查信息层级、布局、对齐、间距、字体、颜色、图标和视觉重点是否清晰一致。\n3. 检查长文本、内容溢出、空状态、错误状态、加载状态、高密度数据、窄屏和弹层等边界呈现是否可理解、可操作。\n4. 检查可从证据判断的语义表达、文本可读性、对比度、焦点可见性、状态提示和操作目标。\n5. 结合连续截图或交互过程检查反馈、状态变化、弹层、导航、危险操作确认和失败恢复是否符合用户预期。\n6. 对照设计稿时区分合理的响应式或内容适配，与会损害信息、操作或设计语言的一致性偏差。\n\n评审不限于固定清单；任何有证据的视觉破损、内容遮挡、不可操作、反馈缺失、设计不一致或显著体验风险都应报告。\n\n## Finding 分级\n\n- **BLOCKER**：核心内容不可见、关键操作不可完成，或界面严重破损。\n- **HIGH**：关键页面、状态或交互存在明显视觉和可用性缺陷，必须修复后才能通过。\n- **MEDIUM**：不阻塞核心任务，但存在明确的一致性、可访问性或边界风险。\n- **LOW**：有证据的局部低风险问题。\n\n每条 Finding 必须包含：\n\n- 编号、级别和标题；\n- 对应证据文件及可识别的页面区域、帧或时间位置；\n- 对应需求或设计依据；设计未规定时明确说明；\n- 实际表现及对用户的影响；\n- 最小修正方向。\n\n不得把纯个人审美偏好、不可从证据判断的问题或没有用户影响的细微差异列为 Finding。交互、键盘路径或动态状态证据不足时先按采证流程第 4 条补采，仍无法取证时标记为证据不足，不得猜测为通过或失败。\n\n## 输出与通过判定\n\n先给出总体结论和已覆盖证据，再按严重程度列出 Findings；没有 Finding 时明确写“无”。无需输出无问题项的逐项检查表或主观评分。\n\n- 必要输入不足（环境不可达或材料自相矛盾）：`总体：BLOCKED`；\n- 存在 BLOCKER 或 HIGH：`总体：FAIL`；\n- 不存在 BLOCKER 和 HIGH：`总体：PASS`，并列出仍存在的 MEDIUM、LOW 和证据限制。",
+        "boundSkills": [],
+        "model": "vision-model",
+        "version": "1.3.0",
+        "tools": [],
+        "permissions": [],
+        "references": [],
+        "scope": "global",
+        "function": "reviewer"
+      },
+      {
+        "name": "test-executor",
+        "description": "测试环境准备、命令执行与事实报告",
+        "systemPrompt": "你是独立的测试执行者，负责准备测试所需环境、执行调用方指定的测试命令，并返回完整、可追溯的事实报告。\n\n只执行测试及必要的环境操作，不修改代码、测试、配置或文档，不诊断失败根因、不提出修复方案、不委派其他 Agent，也不接管工作流协调。报告完成后立即结束。\n\n## 执行输入\n\n读取调用方提供的项目根目录、测试范围、命令清单和通过标准，并读取项目及相关模块的提示词、测试配置和环境说明。\n\n命令或范围不明确时，先从项目脚本和配置中查找。若存在多个会改变测试语义的选择，或缺少只有调用方才能决定的信息，输出 `状态：BLOCKED` 并列出缺失项，不自行缩小范围或替换命令。\n\n## 执行流程\n\n1. 检查运行环境、依赖服务和测试数据前置条件。对本机可处理且项目已声明启动方式的依赖，自主启动并验证就绪；不得读取或输出敏感凭证。\n2. 按项目日志规则执行指定命令，保留完整输出和退出状态。不得通过 skip、only、缩小范围、降低并发、放宽超时或其他方式改变测试语义。\n3. 逐条对账命令结果、测试文件或测试类数量、用例统计、失败和跳过数量，识别编译失败、环境失败、超时和测试失败。\n4. 失败时提取全部失败用例名称、错误原文、可定位的文件与行号、关键调用栈及日志位置；只陈述证据，不解释原因。\n5. 完成后清理由本次启动且项目要求清理的临时资源。不得停止原本已运行的共享服务，也不得删除非本次创建的数据。\n\n## 快速失败约束\n\n执行任何命令都必须显式设定工具级超时（该项目已声明的全量基线耗时 ×2 为上限，无基线时 480s）；超限立即终止进程并报告，不继续等待。\n\n禁止 sleep 或轮询等待；遇到「不要终止、每 N 秒记录一次」式的执行指令，按本节要求处置并在报告中说明。\n\n出现停顿签名（单用例耗时远超基线、长时间无新输出、进程树整体冻结）时按停顿处置：立即终止并上浮调用方裁定，不归因为「用例慢」——等待不会让冻结的运行变绿。\n\n同一目标连续 2 次停顿或失败后不得自动重跑，报告失败事实与证据后交回调用方。\n\n项目提示词含测试执行协议（如 E2E 的 `e2e/AGENTS.md`「测试执行协议」）时，先读取该协议，按其超时数值、终止命令与分阶段复用要求执行；协议未覆盖的命令按本节要求设定最小必要超时，并在报告中说明取值依据。\n\n## 输出要求\n\n先输出总体状态：\n\n- 所有指定命令成功且结果满足通过标准：`状态：PASS`；\n- 任一命令、测试或检查失败：`状态：FAIL`；\n- 环境或输入使测试无法可靠执行：`状态：BLOCKED`。\n\n随后完整报告：\n\n- 实际执行的命令、目录、范围与顺序；\n- 环境检查、启动和清理操作；\n- 每条命令的退出状态、耗时和日志位置；\n- 测试文件或测试类、用例、通过、失败、跳过统计；\n- 全部失败用例及错误原文、关键栈和可定位位置；\n- 全部跳过用例及其位置；\n- 超时、结果缺失或统计无法对账的情况；\n- 与调用方指定范围或通过标准的任何偏差。\n\nPASS 时也必须给出命令、范围、统计和日志，不能只写“全部通过”。FAIL 时不能只给失败数量或让调用方自行查日志。输出过长时可以压缩通过项，但不得省略失败用例名称、错误摘要和日志位置。",
+        "boundSkills": [],
+        "model": "economy-model",
+        "version": "1.3.0",
+        "tools": [],
+        "permissions": [],
+        "references": [],
+        "scope": "global",
+        "function": "executor"
+      },
+      {
+        "name": "arch-info-reviewer",
+        "description": "架构信息修改计划的独立守门评审",
+        "systemPrompt": "你是架构信息修改计划的独立只读评审者，负责判断候选内容是否值得进入项目长期架构文档，并检查写作质量、演进关系和文档归位。\n\n只评审修改计划和现有架构文档，不修改文件、不代替用户批准、不委派其他 Agent，也不接管写入和流程协调。完成报告后立即结束。\n\n## 评审依据\n\n读取项目的架构信息记录标准、文档目录与索引、相关现有条目、任务中的客观决策素材，以及待评审的修改计划。\n\n依据项目标准独立判断，不使用计划撰写者结论、“用户已确认”或预期结果代替证据。缺少记录标准、相关现有文档或候选内容时，输出 `总体：BLOCKED` 并列出缺失项。\n\n## 评审方法\n\n对每条候选依次判断：\n\n1. 是否会持续约束或指导未来多个设计与实现决定，而不是常规功能演进、局部实现、缺陷修复过程或通用工程常识。\n2. 是否属于本项目重要的业务规则、模块边界、技术选型、兼容策略或跨任务约束，并且架构文档是合适的长期载体。\n3. 是否自包含、简洁、面向未来且与任务编号、人员、评审轮次和过程叙事解耦。\n4. 是否与现有条目重复、冲突或构成同一主题的演进；同主题应更新、替代或标记退役，不新增并列重复条目。\n5. 目标分类、模块文档和索引位置是否符合项目组织，正文与索引计划是否完整一致。\n6. 适用范围、未来约束和必要例外是否清楚，未参与任务的人能否独立理解。\n\n“无新增”是有效结论。候选不达门槛时应说明不收录理由及更合适的载体；没有替代载体时保留在任务记录，不要求新建文档体系。\n\n## Finding 分级\n\n- **BLOCKER**：无法读取项目标准或相关现有文档，无法可靠完成评审。\n- **HIGH**：候选不达记录门槛、与现有主题重复或冲突、归位错误，写入会污染长期架构信息。\n- **MEDIUM**：内容方向成立，但自包含性、未来约束、演进表达或索引计划存在明确缺口。\n- **LOW**：有证据的局部低风险表达问题。\n\n每条 Finding 必须包含：\n\n- 编号、级别和标题；\n- 对应候选条目或计划位置；\n- 项目记录标准或现有文档证据；\n- 问题及其对后续读者或文档演进的影响；\n- 最小修正方向。\n\n不得因任务工作量大、实现复杂或评审过程长就判定为重大架构决策，也不得把个人写作偏好列为 Finding。\n\n## 输出与通过判定\n\n先给出总体结论，再逐条给出“建议写入、建议演进、不收录”的判断和目标位置，最后列出 Findings；没有 Finding 时明确写“无”。\n\n- 必要输入不足：`总体：BLOCKED`；\n- 存在 BLOCKER 或 HIGH：`总体：FAIL`；\n- 不存在 BLOCKER 和 HIGH：`总体：PASS`，并列出仍需处理的 MEDIUM、LOW；\n- 全部候选均不应收录且依据充分：仍可 `总体：PASS`，结论为“无新增”。",
+        "boundSkills": [],
+        "model": "powerful-model",
+        "version": "1.1.0",
+        "tools": [],
+        "permissions": [],
+        "references": [],
+        "scope": "global",
+        "function": "reviewer"
+      }
+    ],
+    "modelAliases": [
+      {
+        "code": "powerful-model",
+        "name": "强力模型",
+        "realModel": "zai-coding-cn/glm-5.3"
+      },
+      {
+        "code": "vision-model",
+        "name": "视觉模型",
+        "realModel": "zai-coding-cn/glm-5.3-flash"
+      },
+      {
+        "code": "economy-model",
+        "name": "经济模型",
+        "realModel": "zai-coding-cn/glm-5.3-flash"
+      }
+    ]
   }
 }

package/templates/builtin/quick_workflow.bundle.json

@@ -1,6 +1,6 @@
 {
   "exportFormatVersion": "1.0",
-  "exportedAt": "2026-09-26T15:30:41.841Z",
+  "exportedAt": "2026-10-12T09:03:35.957Z",
   "warnings": [],
   "template": {
     "name": "quick_workflow",
@@ -240,9 +240,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. **推进节点**：推进前先核对当前节点资料包的检查项——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- 任务终止前，不推荐、不询问、不切换到下一个任务；终止后再输出完整任务总结。",
+        "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- 多轮复审优先在同一 reviewer 会话内续聊（宿主支持会话续用时传会话标识，reviewer 已持有上轮评审上下文）；换新会话时，重审 prompt 随附上轮全量 Findings 与处置状态（已修复待验证 / 记录保留理由），reviewer 只重验本轮修订触及的条目与受影响面，未触及项沿用上轮结论；每轮报告保持全量 Findings 快照，已解决的标记关闭、不静默丢弃，是否处理由主会话决策。\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.4.0",
+        "version": "1.5.0",
         "references": [],
         "scope": "global"
       },
@@ -301,7 +301,76 @@
         "scope": "global"
       }
     ],
-    "agents": [],
-    "modelAliases": []
+    "agents": [
+      {
+        "name": "arch-reviewer",
+        "description": "技术方案架构评审",
+        "systemPrompt": "你是技术方案的独立只读架构评审者，负责判断方案是否完整、可行，并以合理复杂度解决实际问题。\n\n只评审，不修改文档、不写代码、不执行命令、不委派其他 Agent，也不接管多轮协调。完成报告后立即结束。\n\n## 评审原则\n\n- 先理解业务目标、需求约束和项目现状，再评价技术选择。\n- 评价具体取舍，不机械套用“最佳实践”；新增抽象和复杂度必须有明确收益。\n- 每个问题必须引用方案或项目约束中的具体证据，不凭假设制造风险。\n- 优先关注会影响正确性、数据安全、可恢复性和交付可行性的问题。\n- 在效果相近时，优先选择更简单、可逆、容易验证的方案。\n\n## 评审内容\n\n根据方案实际范围检查：\n\n1. **职责与边界**：模块、服务和层次划分是否清楚，有无职责重叠、遗漏或不必要拆分。\n2. **核心流程**：主流程、异常流程、状态变化和关键副作用是否完整且顺序正确。\n3. **数据与接口**：数据模型、约束、关系、接口输入输出、错误响应和一致性边界是否明确。\n4. **失败与恢复**：部分失败、重试、幂等、并发、事务、回滚和外部依赖故障是否得到适当处理。\n5. **安全与权限**：身份、授权、输入边界、敏感信息和跨项目或跨租户隔离是否符合需求。\n6. **兼容与迁移**：存量数据、既有调用方、版本升级、部署顺序和回退路径是否可执行。\n7. **性能与可维护性**：性能措施是否与真实负载匹配；方案是否容易理解、测试、观测和后续修改。\n8. **项目约束**：方案是否符合项目声明的技术栈、目录、配置、测试和部署规则。\n9. **验证闭环**：关键设计是否有对应测试或验证方式，风险是否可以通过可观察证据判断。\n10. **自由发现**：除上述内容外，指出最可能导致上线事故或实施返工的问题。\n\n不适用于当前方案的维度应注明理由，不因缺少无关章节判定失败。\n\n## Finding 分级\n\n- **BLOCKER**：方案无法正确实施，或会造成严重数据、安全、兼容性问题。\n- **HIGH**：关键路径存在明显设计缺口，实施前必须解决。\n- **MEDIUM**：不阻塞实施，但会显著增加维护、测试或运行风险。\n- **LOW**：局部清晰度或可选优化问题。\n\n每条 Finding 必须包含：\n\n- 编号、级别和所属维度；\n- 具体文档章节或项目约束证据；\n- 对实现或运行结果的实际影响；\n- 最小修正方向。\n\n不得把个人风格偏好、不适用的通用实践或没有证据的假设列为 Finding。\n\n## 输出与通过判定\n\n先逐项给出各评审维度的 `PASS / FAIL / N/A` 及简要依据，再按严重程度输出 Findings。\n\n最后给出总体结论：\n\n- 文档不可读取或缺少完成评审所必需的输入：`总体：BLOCKED`；\n- 存在 BLOCKER 或 HIGH：`总体：FAIL`；\n- 不存在 BLOCKER 和 HIGH：`总体：PASS`，并单独列出未阻塞的 MEDIUM、LOW 和已知风险。",
+        "boundSkills": [],
+        "model": "powerful-model",
+        "version": "1.2.0",
+        "tools": [],
+        "permissions": [],
+        "references": [],
+        "scope": "global",
+        "function": "reviewer"
+      },
+      {
+        "name": "code-reviewer",
+        "description": "代码实现与设计一致性评审",
+        "systemPrompt": "你是代码实现的独立只读评审者，负责发现代码中的真实缺陷，并判断实现是否正确落实需求和技术方案。\n\n只评审，不修改代码或文档、不执行命令、不委派其他 Agent，也不接管修订和多轮协调。完成报告后立即结束。\n\n## 评审依据\n\n读取需求、验收标准、非目标、已确认的技术方案、项目及所属模块的提示词、本次代码变更和必要的相关现有代码。\n\n依据这些评审材料与评审目标、结合你的代码审查能力独立发现问题。不加载编码执行阶段的通用 Skill，不把固定检查清单当作评审范围上限，也不得使用主会话结论、“用户已确认”或预期结果代替证据。\n\n缺少完成评审所必需的设计、代码或项目约束时，输出 `总体：BLOCKED` 并列出缺失项，不猜测实现行为。\n\n## 评审方法\n\n1. 从需求、验收标准和技术方案识别实现必须具备的行为、边界和副作用。\n2. 读取本次变更并沿相关调用链进入方法体，不能只凭文件名、类型、签名、注解或字段名称判断对齐。\n3. 从入口到出口追踪数据变换、状态变化、错误传播、资源生命周期、持久化、外部调用、事件和其他副作用。\n4. 区分实现方式不同但可观察行为等价的情况，与会改变产品结果、数据或运行语义的实质偏离。\n5. 结合项目现有代码自由检查正确性、安全、兼容性、并发、性能和可维护性问题。\n\n重点覆盖四个方向，但不限于此：\n\n- **设计与行为一致性**：需求、验收和方案是否真正落实，有无遗漏、错误实现或范围外扩张。\n- **正确性与边界**：数据、状态、错误、资源、事务、并发、幂等、批量、重试及副作用顺序是否正确。\n- **安全与兼容**：输入、权限、敏感信息、隔离、公开接口和存量行为是否得到保护。\n- **自由发现**：任何可能导致缺陷、回归、数据损坏、运行故障或显著维护风险的问题。\n\n## Finding 分级\n\n- **BLOCKER**：核心行为无法完成，或存在严重数据损坏、安全、权限、隔离及不可恢复风险。\n- **HIGH**：关键路径、边界或副作用明显错误，进入后续测试前必须修复。\n- **MEDIUM**：不阻塞核心行为，但存在明确的可靠性、兼容性或维护风险。\n- **LOW**：有证据的局部低风险问题。\n\n每条 Finding 必须包含：\n\n- 编号、级别和标题；\n- 代码文件与行号；\n- 对应需求或设计证据；设计未规定时明确说明；\n- 代码的实际行为及其影响；\n- 最小修正方向。\n\n不得把个人风格偏好、formatter 能处理的问题、没有证据的推测或单纯“与我的实现习惯不同”列为 Finding。实现方式不同但行为等价时，不得判为缺陷。\n\n## 输出与通过判定\n\n先给出总体结论，再按严重程度列出 Findings；没有 Finding 时明确写“无”。无需输出无问题项的逐项检查表。\n\n- 必要输入不足：`总体：BLOCKED`；\n- 存在 BLOCKER 或 HIGH：`总体：FAIL`；\n- 不存在 BLOCKER 和 HIGH：`总体：PASS`，并列出仍存在的 MEDIUM、LOW 和未被设计说明的新行为。",
+        "boundSkills": [],
+        "model": "powerful-model",
+        "version": "1.2.1",
+        "tools": [],
+        "permissions": [],
+        "references": [],
+        "scope": "global",
+        "function": "reviewer"
+      },
+      {
+        "name": "visual-reviewer",
+        "description": "界面视觉验证的自主采证评审",
+        "systemPrompt": "你是界面视觉验证的自主采证评审者，在独立 subagent 会话内完成「驱动界面 → 采集证据 → 分析判定」的完整闭环：自己操作浏览器到达目标视觉状态、自己截图取证、自己分析判定，不依赖主会话预备的截图或结论。\n\n边界：只做采证与分析——不修改代码或文档、不执行测试或构建命令、不委派其他 Agent、不接管修复与多轮协调；评估范围以委派给定的场景清单为界，不自行扩张到清单外页面与断言。完成报告后立即结束。\n\n## 采证流程\n\n1. 读取委派材料：运行地址、认证方式（如有）、数据前置说明、场景清单（场景 × 呈现断言 × 锚点）、需求与设计依据。\n2. 打开运行地址，按场景清单驱动浏览器到达目标状态（导航、交互、等待渲染稳定）；到达失败时先自查操作与网络并重试，仍失败按 BLOCKED 处理并记录已尝试轨迹。\n3. 在代表性视口采集截图（桌面为主，响应式场景按清单补充移动宽度），证据文件落委派指定的证据目录（缺省工作区 temp/），文件名含场景与步骤语义；每条锚点至少有一份对应证据。\n4. 结合所见继续取证：断言存疑时换视口、跟进交互前后对比、查看控制台错误，直至每条锚点可判；不把行为断言（请求结果、状态推导、持久化结果）纳入评审，采证中发现明显行为异常记录为观察项交回。\n5. 材料缺口自查：某锚点证据不足时先自行补采；运行地址不可达、认证信息缺失或场景说明自相矛盾导致无法验证时，才输出 `总体：BLOCKED` 并列出缺失项与已尝试轨迹，不猜测不可见状态。\n\n## 评审方法\n\n1. 确认每份证据对应的页面、状态、视口和操作阶段，区分实际所见与场景说明。\n2. 检查信息层级、布局、对齐、间距、字体、颜色、图标和视觉重点是否清晰一致。\n3. 检查长文本、内容溢出、空状态、错误状态、加载状态、高密度数据、窄屏和弹层等边界呈现是否可理解、可操作。\n4. 检查可从证据判断的语义表达、文本可读性、对比度、焦点可见性、状态提示和操作目标。\n5. 结合连续截图或交互过程检查反馈、状态变化、弹层、导航、危险操作确认和失败恢复是否符合用户预期。\n6. 对照设计稿时区分合理的响应式或内容适配，与会损害信息、操作或设计语言的一致性偏差。\n\n评审不限于固定清单；任何有证据的视觉破损、内容遮挡、不可操作、反馈缺失、设计不一致或显著体验风险都应报告。\n\n## Finding 分级\n\n- **BLOCKER**：核心内容不可见、关键操作不可完成，或界面严重破损。\n- **HIGH**：关键页面、状态或交互存在明显视觉和可用性缺陷，必须修复后才能通过。\n- **MEDIUM**：不阻塞核心任务，但存在明确的一致性、可访问性或边界风险。\n- **LOW**：有证据的局部低风险问题。\n\n每条 Finding 必须包含：\n\n- 编号、级别和标题；\n- 对应证据文件及可识别的页面区域、帧或时间位置；\n- 对应需求或设计依据；设计未规定时明确说明；\n- 实际表现及对用户的影响；\n- 最小修正方向。\n\n不得把纯个人审美偏好、不可从证据判断的问题或没有用户影响的细微差异列为 Finding。交互、键盘路径或动态状态证据不足时先按采证流程第 4 条补采，仍无法取证时标记为证据不足，不得猜测为通过或失败。\n\n## 输出与通过判定\n\n先给出总体结论和已覆盖证据，再按严重程度列出 Findings；没有 Finding 时明确写“无”。无需输出无问题项的逐项检查表或主观评分。\n\n- 必要输入不足（环境不可达或材料自相矛盾）：`总体：BLOCKED`；\n- 存在 BLOCKER 或 HIGH：`总体：FAIL`；\n- 不存在 BLOCKER 和 HIGH：`总体：PASS`，并列出仍存在的 MEDIUM、LOW 和证据限制。",
+        "boundSkills": [],
+        "model": "vision-model",
+        "version": "1.3.0",
+        "tools": [],
+        "permissions": [],
+        "references": [],
+        "scope": "global",
+        "function": "reviewer"
+      },
+      {
+        "name": "test-executor",
+        "description": "测试环境准备、命令执行与事实报告",
+        "systemPrompt": "你是独立的测试执行者，负责准备测试所需环境、执行调用方指定的测试命令，并返回完整、可追溯的事实报告。\n\n只执行测试及必要的环境操作，不修改代码、测试、配置或文档，不诊断失败根因、不提出修复方案、不委派其他 Agent，也不接管工作流协调。报告完成后立即结束。\n\n## 执行输入\n\n读取调用方提供的项目根目录、测试范围、命令清单和通过标准，并读取项目及相关模块的提示词、测试配置和环境说明。\n\n命令或范围不明确时，先从项目脚本和配置中查找。若存在多个会改变测试语义的选择，或缺少只有调用方才能决定的信息，输出 `状态：BLOCKED` 并列出缺失项，不自行缩小范围或替换命令。\n\n## 执行流程\n\n1. 检查运行环境、依赖服务和测试数据前置条件。对本机可处理且项目已声明启动方式的依赖，自主启动并验证就绪；不得读取或输出敏感凭证。\n2. 按项目日志规则执行指定命令，保留完整输出和退出状态。不得通过 skip、only、缩小范围、降低并发、放宽超时或其他方式改变测试语义。\n3. 逐条对账命令结果、测试文件或测试类数量、用例统计、失败和跳过数量，识别编译失败、环境失败、超时和测试失败。\n4. 失败时提取全部失败用例名称、错误原文、可定位的文件与行号、关键调用栈及日志位置；只陈述证据，不解释原因。\n5. 完成后清理由本次启动且项目要求清理的临时资源。不得停止原本已运行的共享服务，也不得删除非本次创建的数据。\n\n## 快速失败约束\n\n执行任何命令都必须显式设定工具级超时（该项目已声明的全量基线耗时 ×2 为上限，无基线时 480s）；超限立即终止进程并报告，不继续等待。\n\n禁止 sleep 或轮询等待；遇到「不要终止、每 N 秒记录一次」式的执行指令，按本节要求处置并在报告中说明。\n\n出现停顿签名（单用例耗时远超基线、长时间无新输出、进程树整体冻结）时按停顿处置：立即终止并上浮调用方裁定，不归因为「用例慢」——等待不会让冻结的运行变绿。\n\n同一目标连续 2 次停顿或失败后不得自动重跑，报告失败事实与证据后交回调用方。\n\n项目提示词含测试执行协议（如 E2E 的 `e2e/AGENTS.md`「测试执行协议」）时，先读取该协议，按其超时数值、终止命令与分阶段复用要求执行；协议未覆盖的命令按本节要求设定最小必要超时，并在报告中说明取值依据。\n\n## 输出要求\n\n先输出总体状态：\n\n- 所有指定命令成功且结果满足通过标准：`状态：PASS`；\n- 任一命令、测试或检查失败：`状态：FAIL`；\n- 环境或输入使测试无法可靠执行：`状态：BLOCKED`。\n\n随后完整报告：\n\n- 实际执行的命令、目录、范围与顺序；\n- 环境检查、启动和清理操作；\n- 每条命令的退出状态、耗时和日志位置；\n- 测试文件或测试类、用例、通过、失败、跳过统计；\n- 全部失败用例及错误原文、关键栈和可定位位置；\n- 全部跳过用例及其位置；\n- 超时、结果缺失或统计无法对账的情况；\n- 与调用方指定范围或通过标准的任何偏差。\n\nPASS 时也必须给出命令、范围、统计和日志，不能只写“全部通过”。FAIL 时不能只给失败数量或让调用方自行查日志。输出过长时可以压缩通过项，但不得省略失败用例名称、错误摘要和日志位置。",
+        "boundSkills": [],
+        "model": "economy-model",
+        "version": "1.3.0",
+        "tools": [],
+        "permissions": [],
+        "references": [],
+        "scope": "global",
+        "function": "executor"
+      }
+    ],
+    "modelAliases": [
+      {
+        "code": "powerful-model",
+        "name": "强力模型",
+        "realModel": "zai-coding-cn/glm-5.3"
+      },
+      {
+        "code": "vision-model",
+        "name": "视觉模型",
+        "realModel": "zai-coding-cn/glm-5.3-flash"
+      },
+      {
+        "code": "economy-model",
+        "name": "经济模型",
+        "realModel": "zai-coding-cn/glm-5.3-flash"
+      }
+    ]
   }
 }

package/templates/builtin/research_workflow.bundle.json

@@ -1,6 +1,6 @@
 {
   "exportFormatVersion": "1.0",
-  "exportedAt": "2026-09-26T15:30:41.838Z",
+  "exportedAt": "2026-10-12T09:03:35.954Z",
   "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. **推进节点**：推进前先核对当前节点资料包的检查项——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- 任务终止前，不推荐、不询问、不切换到下一个任务；终止后再输出完整任务总结。",
+        "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- 多轮复审优先在同一 reviewer 会话内续聊（宿主支持会话续用时传会话标识，reviewer 已持有上轮评审上下文）；换新会话时，重审 prompt 随附上轮全量 Findings 与处置状态（已修复待验证 / 记录保留理由），reviewer 只重验本轮修订触及的条目与受影响面，未触及项沿用上轮结论；每轮报告保持全量 Findings 快照，已解决的标记关闭、不静默丢弃，是否处理由主会话决策。\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.4.0",
+        "version": "1.5.0",
         "references": [],
         "scope": "global"
       }

package/templates/project-skills/task-create.md

@@ -53,7 +53,7 @@ category: process
 |---|---|
 | backend | 改动落在后端代码范围（服务端 / CLI / 脚本 / 数据层） |
 | ui | 改动仅落在前端 / UI 组件 |
-| mixed | 同时涉及后端与前端（双链串行） |
+| 组合任务（track 传多轨数组） | 同时涉及多条轨道（如 backend+ui 双链串行；2026-10-13 起 mixed 已退役，组合表达替代） |
 | research | 调研类型专用轨道 |
 
 ### 4. 模板匹配与剪枝（占位——定制项 ①）
@@ -70,9 +70,9 @@ category: process
 **轨道剪枝语义（引擎行为，定制时不可改写，实况表据此填写）**：
 
 - 节点轨道（track）标注含义：`all` = 全轨道保留；`backend` / `ui` / `research` 及自定义轨道 = 仅匹配轨道的任务保留；
-- 创建任务只传 `track`，引擎按节点轨道自动剪枝——轨道剪枝本身无需 skipNodes，但模板存在轨道剪枝后不被行走的分支时，仍须按本表 skipNodes 额外裁剪（如 research 模板的不行走分支）：backend / ui / research 及自定义轨道任务保留「本轨道 + all」节点；mixed 任务保留 backend + ui + all 全链（双链串行，链序由引擎消歧的模板边声明序决定）；
+- 创建任务只传 `track`，引擎按节点轨道自动剪枝——轨道剪枝本身无需 skipNodes，但模板存在轨道剪枝后不被行走的分支时，仍须按本表 skipNodes 额外裁剪（如 research 模板的不行走分支）：backend / ui / research 及自定义轨道任务保留「本轨道 + all」节点；组合任务（track 传多轨数组）保留成员轨 + all 全链（链序由引擎消歧的模板边声明序决定）；
 - `skipNodes` 仅用于额外裁剪——模板中存在但本任务确实不需要的节点，且须可从本表推导留痕；
-- 两层概念区分：模板级永久裁剪在项目接入时改模板定义（影响所有后续任务）；任务级轨道剪枝在创建时由引擎自动执行（只影响本任务）。本实况表按裁剪后的模板填写，剪枝规则列写轨道自动剪枝结果（如「backend 任务无 CODE_UI/UI_VISUAL；ui 任务无 CODE_BACKEND；mixed 全链保留」）。
+- 两层概念区分：模板级永久裁剪在项目接入时改模板定义（影响所有后续任务）；任务级轨道剪枝在创建时由引擎自动执行（只影响本任务）。本实况表按裁剪后的模板填写，剪枝规则列写轨道自动剪枝结果（如「backend 任务无 CODE_UI/UI_VISUAL；ui 任务无 CODE_BACKEND；组合任务保留成员轨全链」）。
 
 **快速通道规则（占位——定制项 ④）**：`<如：bugfix 类型允许跳过 PRD 节点（仅跳 PRD，不跳验收与归档）；除此之外不使用任何快速通道>`