@siming-org/cli 0.8.4 → 0.8.6

package/templates/builtin/quick_workflow.bundle.json

@@ -1,6 +1,6 @@
 {
   "exportFormatVersion": "1.0",
-  "exportedAt": "2026-09-26T15:30:41.841Z",
+  "exportedAt": "2026-10-14T08:44:31.836Z",
   "warnings": [],
   "template": {
     "name": "quick_workflow",
@@ -159,15 +159,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推进前将验收摘要、证据时效、验收标准对照、范围变化、已知问题和位置判定结果写入当前节点记录；非终态形态同时写入归档待办，并在归档完成前保持其未闭环。终态形态在用户确认后追加确认原文与归档结果；非终态形态在暂停点审批通过并完成归档后，追加审批引用、归档策略与结果、最终提交和远程状态，闭环归档待办。完成推进前检查后推进下一节点；批后追加动作发生在推进之后，不阻塞推进。",
+        "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.0",
-          "contentHash": "d9ef06ee6f469ce2",
+          "version": "1.5.1",
+          "contentHash": "abab1a2557e55c73",
           "agents": []
         },
         "toolChecks": [
@@ -233,16 +233,16 @@
       }
     ],
     "isDefault": false,
-    "version": "2.0.6"
+    "version": "2.0.7"
   },
   "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"
       },
@@ -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-14T08:44:31.834Z",
   "warnings": [],
   "template": {
     "name": "research_workflow",
@@ -45,15 +45,15 @@
         "label": "调研验收",
         "phase": "exit",
         "track": "all",
-        "prompt": "# 调研验收\n\n## 节点职责\n\n对照已确认的调研范围核对报告完整性和证据状态，向用户呈现可独立判断的验收摘要；用户明确确认后，按项目策略归档报告并完成任务。\n\n## 依赖信息\n\n先检查当前任务上下文，读取已确认的调研问题、范围、证据标准、停止条件、调研报告、来源与实验记录、限制和开放问题，以及项目的归档约定。加载 `workflow-discipline`。\n\n本节点不重新执行调研，不虚构独立 reviewer，也不做代码测试或代码评审。报告存在缺失、越界或证据不匹配时，返回 `research-execute` 补充或修订。\n\n## 执行流程\n\n1. 建立“调研问题 → 结论或无法结论 → 证据 → 报告位置”的对应关系，确认已确认范围中的问题没有遗漏。\n2. 核对结论是否能追溯到报告所列代码、原始资料或实验，事实、推断、建议、限制和开放问题是否清楚区分。\n3. 检查问题校正和新增发现是否改变了已确认范围；属于范围外的重要事项只列为后续议题，不在本任务中静默扩展。\n4. 发现问题遗漏、证据无法支持结论、限制被隐瞒或报告不可复核时，记录具体缺口并返回调研执行修订；修订后重新核对受影响内容。\n5. 形成验收摘要，逐项呈现问题与结论、关键证据、无法结论、可信度与适用限制、开放问题和建议边界，并说明报告归档位置。\n6. 请求用户对本次调研结果作明确确认。提问、条件句、模糊表态或沉默不视为确认；用户未确认时保持当前节点。\n7. 用户确认后记录确认原文，按项目约定归档调研报告和相关记录，完成任务。\n\n## 产出与检查\n\n完成前确认：\n\n- 已确认范围中的每个问题都有结论或明确的无法结论及原因；\n- 结论可追溯到对应证据，报告位置明确；\n- 事实、推断、建议、限制和开放问题已清楚区分；\n- 问题校正与新增发现没有静默改变任务范围；\n- 验收摘要足以让用户判断调研结果及其边界；\n- 用户已明确确认，确认原文已记录；\n- 调研报告已按项目策略归档，归档结果可追溯。\n\n## 任务差异处理\n\n调研报告可以包含无法结论，前提是原因、已尝试方法和缺失证据如实说明。项目没有特殊归档流程时，采用现有文档和版本控制惯例保存报告，不擅自建立新流程。报告之外出现生产代码变更时，说明任务越界并暂停，不在调研验收中处理。用户要求改变调研目标或补充新的范围时，记录为范围变更并回到适当节点处理。\n\n## 节点记录与推进\n\n将问题覆盖关系、证据核对结果、退回修订及结果、无法结论、限制和开放问题、验收摘要、用户确认原文、报告与归档引用写入当前节点记录。所有检查完成后结束任务；任何检查未满足时保留在当前节点或返回相应节点处理。",
+        "prompt": "# 调研验收\n\n## 节点职责\n\n对照已确认的调研范围核对报告完整性和证据状态，向用户呈现可独立判断的验收摘要；用户明确确认后，按项目策略归档报告并完成任务。\n\n## 依赖信息\n\n先检查当前任务上下文，读取已确认的调研问题、范围、证据标准、停止条件、调研报告、来源与实验记录、限制和开放问题，以及项目的归档约定。加载 `workflow-discipline`。\n\n本节点不重新执行调研，不虚构独立 reviewer，也不做代码测试或代码评审。报告存在缺失、越界或证据不匹配时，返回 `research-execute` 补充或修订。\n\n## 执行流程\n\n1. 建立“调研问题 → 结论或无法结论 → 证据 → 报告位置”的对应关系，确认已确认范围中的问题没有遗漏。\n2. 核对结论是否能追溯到报告所列代码、原始资料或实验，事实、推断、建议、限制和开放问题是否清楚区分。\n3. 检查问题校正和新增发现是否改变了已确认范围；属于范围外的重要事项只列为后续议题，不在本任务中静默扩展。\n4. 发现问题遗漏、证据无法支持结论、限制被隐瞒或报告不可复核时，记录具体缺口并返回调研执行修订；修订后重新核对受影响内容。\n5. 形成验收摘要，逐项呈现问题与结论、关键证据、无法结论、可信度与适用限制、开放问题和建议边界，并说明报告归档位置。\n6. 请求用户对本次调研结果作明确确认。提问、条件句、模糊表态或沉默不视为确认；用户未确认时保持当前节点。\n7. 用户确认后记录确认原文，按项目约定归档调研报告和相关记录，完成任务。\n\n## 产出与检查\n\n完成前确认：\n\n- 已确认范围中的每个问题都有结论或明确的无法结论及原因；\n- 结论可追溯到对应证据，报告位置明确；\n- 事实、推断、建议、限制和开放问题已清楚区分；\n- 问题校正与新增发现没有静默改变任务范围；\n- 验收摘要足以让用户判断调研结果及其边界；\n- 用户已明确确认，确认原文已记录；\n- 调研报告已按项目策略归档，归档结果可追溯。\n\n## 任务差异处理\n\n调研报告可以包含无法结论，前提是原因、已尝试方法和缺失证据如实说明。项目没有特殊归档流程时，采用现有文档和版本控制惯例保存报告，不擅自建立新流程。报告之外出现生产代码变更时，说明任务越界并暂停，不在调研验收中处理。用户要求改变调研目标或补充新的范围时，记录为范围变更并回到适当节点处理。\n\n## 节点记录与推进\n\n将问题覆盖关系、证据核对结果、退回修订及结果、无法结论、限制和开放问题、验收摘要、用户确认原文、报告与归档引用写入当前节点记录。所有检查完成后结束任务——终节点推进必须带收尾确认参数（CLI `--finalize` / MCP `finalize=true`），缺省 advance 会被拒绝并提示；任何检查未满足时保留在当前节点或返回相应节点处理。",
         "skills": [
           "workflow-discipline"
         ],
         "agents": [],
         "sourcePreset": {
           "code": "research-accept",
-          "version": "1.3.0",
-          "contentHash": "26e6f298b87ec0bf",
+          "version": "1.3.1",
+          "contentHash": "19e18ecbc644e994",
           "agents": []
         }
       }
@@ -88,16 +88,16 @@
       }
     },
     "isDefault": false,
-    "version": "1.0.3"
+    "version": "1.0.4"
   },
   "dependencies": {
     "skills": [
       {
         "name": "workflow-discipline",
         "description": "DAG 节点执行、角色分离、授权、暂停点与任务边界纪律",
-        "content": "# workflow-discipline\n\n保证所有 DAG 节点以一致方式确定工作边界、分离执行与验证、处理授权与暂停点，并在完成判定满足后安全推进。\n\n## 铁律\n\n本 Skill 是保障 siming 流程正确执行的基础资产。执行会话加载本 Skill 后，任何上下文压缩操作一律不得压缩本 Skill 正文——它是后续所有节点判定与推进的准绳，必须完整留存在上下文中。\n\n执行会话只专注当前任务本身，不关注执行效率等其他因素；节点提示词、skill、委派 brief 中不得出现任何让 AI 转移任务注意力的描述。\n\n## 适用边界\n\n- 所有节点执行者都应用本 Skill；任务简单、用户催促或改动很小，不改变节点步骤、质量门和完成标准。\n- 本 Skill规定跨节点通用纪律，不替代当前节点提示词中的职责、产出、检查项和具体执行方法。\n- 当前节点提示词与本 Skill共同生效；发现冲突时不得自行忽略任一约束，应先按权限和任务边界判断，无法收敛再向用户呈现冲突。\n\n## 节点执行流程\n\n1. **确认当前边界**：读取任务上下文、当前节点职责、所需产出、完成判定、暂停点和项目约束。执行 git 操作前确认当前分支及项目声明的分支模型。\n2. **确定执行角色**：设计文档和编码由主会话完成；测试命令由 `test-executor` 执行；节点要求独立审查时，由不同 session 的只读 Verifier 执行。\n3. **完成节点工作**：只实施当前节点和已确认任务范围内的工作。发现死代码删留、顺手重构、范围扩张或其他范围外动作时，将其作为独立决策呈现给用户，不自行纳入。\n4. **执行独立验证**：Worker 与 Verifier 必须分离。Verifier 只接收评审目标与材料（评审对象路径、参照位置、已认定非问题的历史事项），不接收设计结论、决策理由或“用户已确认”等预设结论。\n5. **处理审查结果**：审查是否通过，以 Verifier 本次输出为准。逐条修复 finding，或记录不修复理由；修复阻塞问题后重新审查。交互式审查最多 3 轮，连续 3 轮仍未通过时，保留在当前节点并请用户决定。\n6. **检查并记录**：逐项核对当前节点的完成判定，记录实际产出、检查结果、评审结论与轮次、关键决定、不适用项及其理由。\n7. **提交节点成果**：完成判定全部满足后、推进节点前，检查工作树和 diff。存在本节点产生的应提交改动时，只纳入当前任务与当前节点范围内的代码、测试、文档等成果并创建 git commit；不得混入无关改动，也不得用空提交代替成果提交。提交失败或本节点应提交改动仍有遗漏时，留在当前节点处理。\n8. **推进节点**：推进前先核对当前节点资料包的检查项——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，不跳验收与归档）；除此之外不使用任何快速通道>`