@siming-org/cli 0.6.2 → 0.6.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/index.js
CHANGED
|
@@ -4751,7 +4751,7 @@ async function fetchManifest(pkgSpec, registry) {
|
|
|
4751
4751
|
{ maxBuffer: 16 * 1024 * 1024 }
|
|
4752
4752
|
);
|
|
4753
4753
|
const packInfo = JSON.parse(stdout);
|
|
4754
|
-
const filename = packInfo[0]?.filename;
|
|
4754
|
+
const filename = (Array.isArray(packInfo) ? packInfo[0] : Object.values(packInfo ?? {})[0])?.filename;
|
|
4755
4755
|
if (filename === void 0) {
|
|
4756
4756
|
cleanup();
|
|
4757
4757
|
return fail({
|
|
@@ -7548,6 +7548,12 @@ ${ROADMAP_TEXT}
|
|
|
7548
7548
|
version \u5224\u5B9A\u66F4\u65B0\uFF09\uFF1B
|
|
7549
7549
|
\u88C1\u526A\u540E\u6A21\u677F\u5347\u7EA7\u4ECD\u8D70 dag template upgrade\uFF08\u4EC5\u4F5C\u7528\u4E8E\u73B0\u5B58\u8282\u70B9\uFF0C\u88AB\u526A
|
|
7550
7550
|
\u8282\u70B9\u4E0D\u4F1A\u88AB\u5347\u7EA7\u627E\u56DE\uFF09\u3002
|
|
7551
|
+
\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
|
|
7552
|
+
\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
|
|
7553
|
+
\uFF08backend/ui/research \u53CA\u81EA\u5B9A\u4E49\u8F68\u9053\u4EFB\u52A1\u4FDD\u7559\u672C\u8F68\u9053+all \u8282\u70B9\uFF0C
|
|
7554
|
+
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
|
|
7555
|
+
\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
|
|
7556
|
+
\u4EFB\u52A1\u7EA7\u8F68\u9053\u526A\u679D\u8BED\u4E49\u8BE6\u89C1 task-create \u5B9A\u5236\u9AA8\u67B6\u3002
|
|
7551
7557
|
|
|
7552
7558
|
\u5907\u9009\u8DEF\u5F84\u2014\u2014npm \u5305\u5185\u7F6E\u57FA\u7840\u6A21\u677F bundle\uFF08templates/builtin/\uFF0C\u542B\u4F9D\u8D56
|
|
7553
7559
|
\u95ED\u5305 skills/agents/\u6A21\u578B\u522B\u540D\uFF0C\u5BFC\u5165\u5373\u5B8C\u6574\u53EF\u7528\uFF09\uFF1A
|
|
@@ -7598,6 +7604,9 @@ ${MCP_TOOLING_TEXT}
|
|
|
7598
7604
|
\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
|
|
7599
7605
|
\u4E0D\u652F\u6301 MCP \u65F6\u8D70 siming CLI \u515C\u5E95
|
|
7600
7606
|
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
|
|
7607
|
+
\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
|
|
7608
|
+
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
|
|
7609
|
+
\u6A21\u677F\u5B58\u5728\u8F68\u9053\u526A\u679D\u540E\u4E0D\u88AB\u884C\u8D70\u7684\u5206\u652F\u65F6\u5FC5\u987B skip\uFF09
|
|
7601
7610
|
3. \u521B\u5EFA\u9996\u4EFB\u52A1\uFF1A\u4EFB\u52A1\u5F15\u7528\u6A21\u677F\u4E00\u5F8B\u7528 code \u5F62\u6001\uFF08templateId \u4F20\u6A21\u677F code +
|
|
7602
7611
|
projectId \u6307\u5B9A\u9879\u76EE\u57DF\uFF1B24 \u4F4D\u6570\u636E\u5E93 id \u517C\u5BB9\uFF09\u2014\u2014code \u7ECF
|
|
7603
7612
|
siming_template\uFF08\u53EA\u8BFB list\uFF09\u83B7\u53D6\uFF0C\u4E0D\u5B58\u5728\u65F6\u9519\u8BEF\u4FE1\u606F\u542B\u76F8\u8FD1\u5019\u9009\u6E05\u5355
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@siming-org/cli",
|
|
3
|
-
"version": "0.6.
|
|
3
|
+
"version": "0.6.4",
|
|
4
4
|
"license": "MIT",
|
|
5
5
|
"author": "Wuchao",
|
|
6
6
|
"engines": {
|
|
@@ -27,8 +27,8 @@
|
|
|
27
27
|
"picocolors": "^1.1.1",
|
|
28
28
|
"yaml": "^2.6.0",
|
|
29
29
|
"zod": "^4.4.3",
|
|
30
|
-
"@siming-org/
|
|
31
|
-
"@siming-org/
|
|
30
|
+
"@siming-org/server": "0.6.4",
|
|
31
|
+
"@siming-org/core": "0.6.4"
|
|
32
32
|
},
|
|
33
33
|
"devDependencies": {
|
|
34
34
|
"tsup": "^8.3.5",
|
|
@@ -1,10 +1,10 @@
|
|
|
1
1
|
{
|
|
2
2
|
"exportFormatVersion": "1.0",
|
|
3
|
-
"exportedAt": "2026-09-
|
|
3
|
+
"exportedAt": "2026-09-13T10:34:25.480Z",
|
|
4
4
|
"warnings": [],
|
|
5
5
|
"template": {
|
|
6
6
|
"name": "full_workflow",
|
|
7
|
-
"description": "通用软件开发全流程：PRD
|
|
7
|
+
"description": "通用软件开发全流程：PRD 设计与确认、分支对齐、完整技术方案双审，界面任务经交互设计节点产出可核对交互契约（含人工确认），按任务轨道进入后端或前端实现与验证，完成单元测试和项目适用的端到端测试，经最终集成验证、发布验收与架构信息归档后收敛。feature 使用完整路径；bugfix 和界面微调可按任务配置跳过 PRD。混合任务先完成后端测试链，再进入前端实现与视觉验证。",
|
|
8
8
|
"nodes": [
|
|
9
9
|
{
|
|
10
10
|
"id": "PRD",
|
|
@@ -49,7 +49,7 @@
|
|
|
49
49
|
"label": "技术方案",
|
|
50
50
|
"phase": "entry",
|
|
51
51
|
"track": "all",
|
|
52
|
-
"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`
|
|
52
|
+
"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全部产出检查满足后再推进；创建任务分支后，记录任务与分支的关联。",
|
|
53
53
|
"skills": [
|
|
54
54
|
"tech-design",
|
|
55
55
|
"workflow-discipline"
|
|
@@ -60,20 +60,41 @@
|
|
|
60
60
|
],
|
|
61
61
|
"sourcePreset": {
|
|
62
62
|
"code": "design-tech",
|
|
63
|
-
"version": "1.
|
|
64
|
-
"contentHash": "
|
|
63
|
+
"version": "1.5.0",
|
|
64
|
+
"contentHash": "3366c9c3336fbc9f",
|
|
65
65
|
"agents": [
|
|
66
66
|
"alignment-reviewer",
|
|
67
67
|
"arch-reviewer"
|
|
68
68
|
]
|
|
69
69
|
}
|
|
70
70
|
},
|
|
71
|
+
{
|
|
72
|
+
"id": "INTERACTION",
|
|
73
|
+
"label": "交互设计",
|
|
74
|
+
"phase": "entry",
|
|
75
|
+
"track": "ui",
|
|
76
|
+
"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` 结论与轮次、用户确认原文写入当前节点记录，完成产出检查后推进下一节点。",
|
|
77
|
+
"skills": [
|
|
78
|
+
"workflow-discipline"
|
|
79
|
+
],
|
|
80
|
+
"agents": [
|
|
81
|
+
"alignment-reviewer"
|
|
82
|
+
],
|
|
83
|
+
"sourcePreset": {
|
|
84
|
+
"code": "interaction-design",
|
|
85
|
+
"version": "1.0.0",
|
|
86
|
+
"contentHash": "740111e7a661be78",
|
|
87
|
+
"agents": [
|
|
88
|
+
"alignment-reviewer"
|
|
89
|
+
]
|
|
90
|
+
}
|
|
91
|
+
},
|
|
71
92
|
{
|
|
72
93
|
"id": "CODE_BACKEND",
|
|
73
94
|
"label": "后端编码",
|
|
74
95
|
"phase": "track",
|
|
75
96
|
"track": "backend",
|
|
76
|
-
"prompt": "# 后端编码\n\n## 节点职责\n\n依据已确认的需求和技术方案完成后端生产代码，并通过项目静态检查和独立代码评审。测试设计、测试代码与测试执行由后续节点负责。\n\n## 依赖信息\n\n
|
|
97
|
+
"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 处理情况写入当前节点记录。完成上述检查后推进下一节点。",
|
|
77
98
|
"skills": [
|
|
78
99
|
"coding-standards",
|
|
79
100
|
"workflow-discipline"
|
|
@@ -83,8 +104,8 @@
|
|
|
83
104
|
],
|
|
84
105
|
"sourcePreset": {
|
|
85
106
|
"code": "code-backend",
|
|
86
|
-
"version": "1.
|
|
87
|
-
"contentHash": "
|
|
107
|
+
"version": "1.4.0",
|
|
108
|
+
"contentHash": "53cebe02565babcc",
|
|
88
109
|
"agents": [
|
|
89
110
|
"code-reviewer"
|
|
90
111
|
]
|
|
@@ -95,7 +116,7 @@
|
|
|
95
116
|
"label": "前端编码",
|
|
96
117
|
"phase": "track",
|
|
97
118
|
"track": "ui",
|
|
98
|
-
"prompt": "# 前端编码\n\n## 节点职责\n\n依据已确认的需求和技术方案完成前端生产代码，包括界面结构、视觉样式、交互、响应式和可访问性，并通过项目静态检查和独立代码评审。测试与视觉验收由后续节点负责，但设计要求的界面能力必须在本节点实现完成。\n\n## 依赖信息\n\n
|
|
119
|
+
"prompt": "# 前端编码\n\n## 节点职责\n\n依据已确认的需求和技术方案完成前端生产代码，包括界面结构、视觉样式、交互、响应式和可访问性，并通过项目静态检查和独立代码评审。测试与视觉验收由后续节点负责，但设计要求的界面能力必须在本节点实现完成。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、技术方案、既有决策以及项目和所属模块的提示词。存在交互契约产物时，将其列为显式输入依赖：先读契约再实现，界面实现项与契约条款逐项对应；交互设计节点已判定不适用（无契约）时，按技术方案实现并在节点记录中引用该判定。加载 `coding-standards`、`workflow-discipline`，并按实际技术栈读取 `coding-standards` 的 UI 及其他相关 references；调用独立 `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- 适用的静态检查通过并留有结果；\n- `code-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明；\n- 生产代码和必要说明已形成可引用产物。\n\n## 任务差异处理\n\n新增依赖、破坏性变更、公开契约变化、设计语言变化或真实范围扩张需要用户决定时，先呈现必要性和影响再暂停。某项界面状态或检查因任务性质不适用时，说明理由，不得静默跳过；执行障碍和评审修订按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将实现摘要、主要变更、静态检查结果、代码产物引用、接口与界面边界处理、关键决策、未适用项及理由、`code-reviewer` 结论与 Findings 处理情况写入当前节点记录。完成上述检查后推进下一节点。",
|
|
99
120
|
"skills": [
|
|
100
121
|
"coding-standards",
|
|
101
122
|
"workflow-discipline"
|
|
@@ -105,8 +126,8 @@
|
|
|
105
126
|
],
|
|
106
127
|
"sourcePreset": {
|
|
107
128
|
"code": "code-frontend",
|
|
108
|
-
"version": "1.
|
|
109
|
-
"contentHash": "
|
|
129
|
+
"version": "1.4.0",
|
|
130
|
+
"contentHash": "6013913c24b5e6b7",
|
|
110
131
|
"agents": [
|
|
111
132
|
"code-reviewer"
|
|
112
133
|
]
|
|
@@ -117,7 +138,7 @@
|
|
|
117
138
|
"label": "视觉验证",
|
|
118
139
|
"phase": "track",
|
|
119
140
|
"track": "ui",
|
|
120
|
-
"prompt": "# 视觉验证\n\n## 节点职责\n\n运行当前界面并通过浏览器完成验收路径，验证功能结果、采集视觉证据，再根据独立 `visual-reviewer` 的评审结果完成修复和回归。本节点负责运行、操作、采证和流程收敛，不代替 Agent 判断视觉质量。\n\n## 依赖信息\n\n
|
|
141
|
+
"prompt": "# 视觉验证\n\n## 节点职责\n\n运行当前界面并通过浏览器完成验收路径，验证功能结果、采集视觉证据，再根据独立 `visual-reviewer` 的评审结果完成修复和回归。本节点负责运行、操作、采证和流程收敛，不代替 Agent 判断视觉质量。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、技术方案、前端实现记录，以及项目和所属模块的提示词。存在交互契约产物时，读取契约并将其自检清单与验收点作为验证清单的底座；无契约时以验收标准为底座。加载 `workflow-discipline`，调用独立 `visual-reviewer` 评审视觉证据。\n\n根据需求整理待验证页面、用户路径、需要呈现的状态和代表性视口。缺少运行方式、访问地址、认证或数据准备信息时，先从项目脚本、配置和现有环境中查找；仍无法运行当前实现时，说明缺失信息并暂停。\n\n## 执行流程\n\n1. 按项目声明启动当前实现及其依赖服务，确认页面对应本次代码。\n2. 使用浏览器自动化能力执行需求涉及的真实用户路径，验证操作后的页面结果、请求结果、反馈、错误处理和持久化后的重新加载结果。\n3. 检查浏览器控制台中的新增错误、失败请求和其他运行异常。\n4. 按验收范围触发适用的加载、空、错误、成功和关键交互状态，并在代表性视口采集截图、视频或等价原始证据；有交互契约时按契约条款逐项触发与核对，证据覆盖契约验收点；不在本节点预判视觉结论。\n5. 将需求、设计规范、场景说明、视口信息和原始证据交给 `visual-reviewer`；交互契约（如有）随需求与设计规范一并作为客观约束移交，不提供实现者结论或预期缺陷。\n6. 修复功能验证失败项以及 `visual-reviewer` 报告的 BLOCKER、HIGH Findings，然后重新执行受影响路径、采集同场景证据并再次评审，直至功能验证通过且视觉评审为 PASS。MEDIUM、LOW 逐项处理或记录保留理由。\n7. 清理本次创建的临时数据和运行资源，不删除非本次创建的数据。\n\n## 产出与检查\n\n推进前确认：\n\n- 需求涉及的用户路径已通过真实浏览器操作验证，并观察到最终结果；\n- 页面结果、请求、反馈、错误处理、持久化和控制台均无未解决的严重问题；\n- 验收所需状态与视口已呈现，原始证据对应当前实现且可追溯；\n- `visual-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明；\n- 修复后的受影响路径已重新验证并重新采证；\n- 临时数据和运行资源已按项目规则清理。\n\n## 任务差异处理\n\n根据需求和页面能力选择用户路径、状态、视口与证据，不套用固定 CRUD 或截图数量。某项不适用时说明理由，不得静默跳过。完全无法运行当前实现，或修复需要改变已确认需求、设计方向、公开契约或引入新依赖时，说明影响并暂停；验证与修订轮次按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将功能验证结论、已覆盖的用户路径、状态与视口、请求和控制台结果、原始证据引用、缺陷修复、未适用项及理由、`visual-reviewer` 结论与 Findings 处理情况写入当前节点记录。完成上述检查后推进下一节点。",
|
|
121
142
|
"skills": [
|
|
122
143
|
"workflow-discipline"
|
|
123
144
|
],
|
|
@@ -126,8 +147,8 @@
|
|
|
126
147
|
],
|
|
127
148
|
"sourcePreset": {
|
|
128
149
|
"code": "verify-visual",
|
|
129
|
-
"version": "1.
|
|
130
|
-
"contentHash": "
|
|
150
|
+
"version": "1.4.0",
|
|
151
|
+
"contentHash": "bca69ce7876c0620",
|
|
131
152
|
"agents": [
|
|
132
153
|
"visual-reviewer"
|
|
133
154
|
]
|
|
@@ -204,7 +225,7 @@
|
|
|
204
225
|
"label": "端到端测试开发",
|
|
205
226
|
"phase": "test",
|
|
206
227
|
"track": "backend",
|
|
207
|
-
"prompt": "# 端到端测试开发\n\n## 节点职责\n\n依据已确认的 E2E 设计实现并验证跨真实系统边界的测试场景；设计结论为 N/A 时复核依据并记录结果。测试代码和必要的生产代码修复由当前执行者完成；测试命令交给独立 `test-executor` 执行，最终代码交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、技术方案、生产代码、E2E 设计、单元测试结果、前序决策，以及项目和所属模块的测试约束。加载 `coding-standards`、`workflow-discipline`；测试失败且根因不明确时，再加载 `bugfix-root-cause-verification`。调用 `test-executor` 执行测试，调用 `code-reviewer` 审查代码变更。\n\n读取项目的 E2E 目录、配置、执行入口、邻近用例和环境规则。缺少关键信息时先从仓库现状补齐，不擅自引入项目未定义的测试体系。\n\n## 执行流程\n\n1. 读取 E2E 适用性结论并建立“设计场景 → 测试实现或已有用例”的逐项映射。\n2. 设计结论为 N/A 时，复核项目仍未定义适用的 E2E 体系；依据成立则记录 N/A，发现依据不成立则返回设计范围判断，不直接越过设计补写测试。\n3. 适用时，按项目现有框架和唯一执行入口实现测试，落实前置条件、操作步骤、观察点、预期结果、数据隔离和清理。测试必须经过项目定义的真实边界，并验证最终可观察结果。\n4. 完成一个场景或紧密相关的一组场景后，将明确的命令、范围和通过标准交给 `test-executor` 执行。\n5. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按需加载 `bugfix-root-cause-verification`，确认根因后再修改测试、生产代码或环境。\n6. 修复后重新执行原失败场景及受影响回归。不得通过删除有效测试、skip/only、绕开真实边界、缩小应执行范围、放宽正确断言、吞异常或硬编码结果制造通过。\n7.
|
|
228
|
+
"prompt": "# 端到端测试开发\n\n## 节点职责\n\n依据已确认的 E2E 设计实现并验证跨真实系统边界的测试场景；设计结论为 N/A 时复核依据并记录结果。测试代码和必要的生产代码修复由当前执行者完成；测试命令交给独立 `test-executor` 执行，最终代码交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、技术方案、生产代码、E2E 设计、单元测试结果、前序决策，以及项目和所属模块的测试约束。加载 `coding-standards`、`workflow-discipline`；测试失败且根因不明确时，再加载 `bugfix-root-cause-verification`。调用 `test-executor` 执行测试，调用 `code-reviewer` 审查代码变更。\n\n读取项目的 E2E 目录、配置、执行入口、邻近用例和环境规则。缺少关键信息时先从仓库现状补齐，不擅自引入项目未定义的测试体系。\n\n## 执行流程\n\n1. 读取 E2E 适用性结论并建立“设计场景 → 测试实现或已有用例”的逐项映射。\n2. 设计结论为 N/A 时，复核项目仍未定义适用的 E2E 体系；依据成立则记录 N/A，发现依据不成立则返回设计范围判断，不直接越过设计补写测试。\n3. 适用时，按项目现有框架和唯一执行入口实现测试，落实前置条件、操作步骤、观察点、预期结果、数据隔离和清理。测试必须经过项目定义的真实边界，并验证最终可观察结果。\n4. 完成一个场景或紧密相关的一组场景后，将明确的命令、范围和通过标准交给 `test-executor` 执行。\n5. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按需加载 `bugfix-root-cause-verification`，确认根因后再修改测试、生产代码或环境。\n6. 修复后重新执行原失败场景及受影响回归。不得通过删除有效测试、skip/only、绕开真实边界、缩小应执行范围、放宽正确断言、吞异常或硬编码结果制造通过。\n7. 全部场景实现后，以证据链确定 E2E 回归范围：列出本节点的测试与生产代码变更，映射到受影响场景（同一入口、同一链路、共享前置数据的用例），逐项给出执行或排除的依据。E2E 全量是须举证的主动决策而非兜底——仅当证据表明改动横切多个入口或共享基础设施时执行；未完成受影响分析就宣称无法判断、或以「保险起见」直接全量，均判定为范围决策失败。生产代码发生修复时，同样按证据链确定并执行受影响的低层测试。\n8. 检查设计映射、测试删除、skip/only、断言有效性、真实边界、数据隔离、清理和环境可重复性。\n9. 将需求、E2E 设计、项目约束和全部代码变更位置交给 `code-reviewer`，不提供实现者结论或预期结果。修复 BLOCKER、HIGH Findings 后重新执行受影响测试并复审，直至测试通过且评审为 PASS；MEDIUM、LOW 逐项处理或记录保留理由。\n\n## 产出与检查\n\n推进前确认：\n\n- N/A 结论已有复核证据，或每个适用设计场景都有对应实现或明确的已有测试；\n- 测试遵循项目现有 E2E 体系并经过真实系统边界；\n- 观察点、数据隔离、清理和环境准备符合项目约束；\n- 所有失败均在根因明确后修复，没有制造假绿；\n- `test-executor` 报告适用 E2E 和必要的低层回归全部通过，失败为 0，未授权跳过为 0；\n- 完整性检查通过，日志和报告可追溯；\n- `code-reviewer` 最终结论为 PASS，所有 Findings 均已处理或说明；\n- 测试代码、必要的生产修复和执行报告已形成可引用产物。\n\n## 任务差异处理\n\n项目没有适用的 E2E 体系时不新建框架、目录或执行入口。根据项目能力和设计范围选择测试、环境和回归方式，不套用固定浏览器、协议、命令或覆盖指标。失败修复涉及破坏性契约、新依赖或真实范围扩张时先说明影响并暂停；同一问题多轮仍不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将 E2E 适用性复核、设计到实现的映射、测试代码变更、真实边界、数据与清理、实际执行命令、范围及判断依据、通过/失败/跳过统计、低层回归、日志与报告引用、根因和修复、完整性结论、`code-reviewer` 结论与 Findings 处理情况写入当前节点记录。完成上述检查后推进下一节点。",
|
|
208
229
|
"skills": [
|
|
209
230
|
"coding-standards",
|
|
210
231
|
"workflow-discipline"
|
|
@@ -215,8 +236,8 @@
|
|
|
215
236
|
],
|
|
216
237
|
"sourcePreset": {
|
|
217
238
|
"code": "test-e2e-implement",
|
|
218
|
-
"version": "1.3.
|
|
219
|
-
"contentHash": "
|
|
239
|
+
"version": "1.3.1",
|
|
240
|
+
"contentHash": "4c0b71a785fe001a",
|
|
220
241
|
"agents": [
|
|
221
242
|
"test-executor",
|
|
222
243
|
"code-reviewer"
|
|
@@ -228,7 +249,7 @@
|
|
|
228
249
|
"label": "集成验证",
|
|
229
250
|
"phase": "test",
|
|
230
251
|
"track": "all",
|
|
231
|
-
"prompt": "# 集成验证\n\n## 节点职责\n\n
|
|
252
|
+
"prompt": "# 集成验证\n\n## 节点职责\n\n将远程主线最新状态整合到任务分支，并在最终集成态执行适用回归，形成绑定明确版本的验证结论。版本控制与范围判断由当前执行者负责——范围判断是严肃决策，跑与不跑都必须有证据支撑，全量是须举证的选项而非默认值。测试命令交给独立 `test-executor` 执行；若产生代码修复，再交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、技术方案、实现与测试记录、`align-branch` 的基础分支与合并记录，以及项目的分支策略、测试体系和所属模块提示词。加载 `workflow-discipline`，调用 `test-executor` 执行回归；发生代码修复时调用 `code-reviewer`。测试失败且根因不明确时，再加载 `bugfix-root-cause-verification`。\n\n优先使用 `align-branch` 已记录的基础分支；记录缺失时，按与该节点相同的规则从任务上下文或项目提示词解析，例如 `main`、`master` 或 `dev`。仍无法解析时询问用户是否需要合并某个分支的远程代码，不根据版本历史猜测基础分支。\n\n## 执行流程\n\n1. 获取远程状态，优先读取 `align-branch` 记录的基础分支；记录缺失时从任务上下文或项目提示词解析，仍无法解析则询问用户。记录当前任务版本、基础分支、远程版本及判断依据。\n2. 用户明确表示无需合并时记录该决定；否则按项目策略整合基础分支的远程最新代码。发生冲突时理解双方意图后逐项融合并验证结果，不盲目选择任一侧；无法可靠解决时说明冲突与缺失决策并暂停。\n3. 汇总任务改动和主线整合改动，读取项目测试目录、配置、脚本与现有用例，列出适用的测试层级和执行入口；项目未定义的层级记录 N/A。\n4. 回归执行决策由「是否执行」与「执行什么」两半构成，每一半都必须由证据支撑，禁止无分析的保守回退：\n - 零差异不重跑：某层级相对既有已验证版本（绑定明确版本标识、全绿证据在案）覆盖面差异为空时，该层级禁止重复执行，记录绑定证据替代重跑；\n - 有差异走判断链：a) 变更清单——汇总任务改动、主线整合改动与集成期修复，落到具体文件和对外可见的符号、契约、配置；b) 依赖分析——逐变更点查明引用方与波及面（导入、调用、共享契约、构建配置），得出受影响模块清单；c) 测试映射——把受影响模块映射到具体用例（既有用例位置、任务新增或修改的用例、所属层级与执行入口）；d) 最小充分决策——按定向用例、受影响模块、整层级的顺序逐级扩大，每次扩大都指出上一级不充分的具体证据；\n - 全量须举证：仅当判断链证据表明影响面确实覆盖整个层级（如横切基础设施、共享契约、构建配置变更）才执行全量。宣称「无法判断影响范围」前必须已完成 a)–c) 分析；分析后仍存在的盲区逐条列明（哪个变更点、查了什么、缺什么信息），把盲区对应的补充用例并入执行范围并留痕。未做分析就宣称无法判断、或以「保险起见」跳过判断直接全量，均判定为范围决策失败。\n5. 将明确的命令、顺序、范围和通过标准交给 `test-executor` 执行——委派命令的覆盖范围必须与第 4 条判断链结论一致，判了定向就执行定向入口，不得委派时顺手扩大。依据事实报告核对各层级统计、失败、跳过和日志。\n6. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按需加载 `bugfix-root-cause-verification`，确认根因后再修改代码、测试或环境。\n7. 每次修复后重新执行原失败范围和受影响回归。不得通过删除有效测试、skip/only、缩小应执行范围、放宽正确断言、吞异常或硬编码结果制造通过。\n8. 检查新增 skip/only、测试删除、未执行的适用层级、范围遗漏和统计对账。发生代码修复时，将客观约束与变更位置交给 `code-reviewer`；修复 BLOCKER、HIGH Findings 后重跑受影响测试并复审，直至测试通过且评审为 PASS。\n9. 记录最终同步状态、实际回归范围、测试结果和已验证的提交或等价版本标识，确保后续能够判断证据是否仍有效。\n\n## 产出与检查\n\n推进前确认：\n\n- 基础分支沿用 `align-branch` 记录，或已按相同规则重新解析并留痕；\n- 基础分支的远程状态已获取并完成整合，或用户已明确表示无需合并；\n- 所有冲突均已理解并正确融合；\n- 项目适用测试层级与执行入口已识别，N/A 有具体依据；\n- 回归范围由完整判断链支撑（变更清单 → 依赖分析 → 测试映射 → 逐级扩大决策），每个执行范围都能指认其覆盖的变更点；零差异层级以绑定证据替代重跑；全量执行附有影响面覆盖整个层级的具体证据；不存在无分析的全量兜底；\n- `test-executor` 报告所有适用回归通过，失败为 0，未授权跳过为 0；\n- 所有失败均在根因明确后修复，没有制造假绿；\n- 发生代码修复时，`code-reviewer` 最终结论为 PASS；\n- 集成结论绑定明确版本，日志和报告可追溯。\n\n## 任务差异处理\n\n基础分支没有新提交时无需制造合并提交；回归是否执行、执行什么，一律按第 4 条的零差异判定与判断链决定——集成态与已验证版本一致且证据在案时以证据绑定替代重跑，集成态有新增内容时按判断链定范围。用户明确表示无需合并时保留决定，验证决策同样按第 4 条执行。根据项目实际体系选择测试层级和命令，不擅自引入未定义的测试类型。远程状态不可获取、冲突无法可靠解决，或修复涉及破坏性契约、新依赖和真实范围扩张时，说明证据与影响并暂停；同一问题多轮不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将基础分支来源、同步策略与结果、任务和远程版本、冲突处理、适用测试层级、回归范围判断链（变更清单、依赖分析、测试映射、逐级扩大证据、零差异证据绑定）及结论、实际命令与统计、失败根因和修复、完整性检查、代码评审结果、日志与报告引用、最终已验证版本写入当前节点记录。完成上述检查后推进下一节点。\n",
|
|
232
253
|
"skills": [
|
|
233
254
|
"workflow-discipline"
|
|
234
255
|
],
|
|
@@ -238,8 +259,8 @@
|
|
|
238
259
|
],
|
|
239
260
|
"sourcePreset": {
|
|
240
261
|
"code": "test-integrate",
|
|
241
|
-
"version": "1.
|
|
242
|
-
"contentHash": "
|
|
262
|
+
"version": "1.4.0",
|
|
263
|
+
"contentHash": "2a6c9a9bbc3452ce",
|
|
243
264
|
"agents": [
|
|
244
265
|
"test-executor",
|
|
245
266
|
"code-reviewer"
|
|
@@ -301,19 +322,28 @@
|
|
|
301
322
|
},
|
|
302
323
|
{
|
|
303
324
|
"from": "DESIGN",
|
|
325
|
+
"to": "INTERACTION",
|
|
326
|
+
"pausePoint": {
|
|
327
|
+
"type": "human_approval",
|
|
328
|
+
"description": "技术方案确认（技术方案 → 编码/交互设计阶段；须呈现方案摘要 + 评审结果 + 激活轨道列表）",
|
|
329
|
+
"autoResume": false
|
|
330
|
+
}
|
|
331
|
+
},
|
|
332
|
+
{
|
|
333
|
+
"from": "INTERACTION",
|
|
304
334
|
"to": "CODE_BACKEND",
|
|
305
335
|
"pausePoint": {
|
|
306
336
|
"type": "human_approval",
|
|
307
|
-
"description": "
|
|
337
|
+
"description": "交互契约确认（交互设计 → 后端编码；须呈现契约要点摘要 + 自检清单核对结果 + 不适用判定如有）",
|
|
308
338
|
"autoResume": false
|
|
309
339
|
}
|
|
310
340
|
},
|
|
311
341
|
{
|
|
312
|
-
"from": "
|
|
342
|
+
"from": "INTERACTION",
|
|
313
343
|
"to": "CODE_UI",
|
|
314
344
|
"pausePoint": {
|
|
315
345
|
"type": "human_approval",
|
|
316
|
-
"description": "
|
|
346
|
+
"description": "交互契约确认（交互设计 → 前端编码；须呈现契约要点摘要 + 自检清单核对结果 + 不适用判定如有）",
|
|
317
347
|
"autoResume": false
|
|
318
348
|
}
|
|
319
349
|
},
|
|
@@ -344,11 +374,11 @@
|
|
|
344
374
|
},
|
|
345
375
|
{
|
|
346
376
|
"from": "E2E_DEV",
|
|
347
|
-
"to": "
|
|
377
|
+
"to": "CODE_UI"
|
|
348
378
|
},
|
|
349
379
|
{
|
|
350
380
|
"from": "E2E_DEV",
|
|
351
|
-
"to": "
|
|
381
|
+
"to": "INTEGRATE"
|
|
352
382
|
},
|
|
353
383
|
{
|
|
354
384
|
"from": "UI_VISUAL",
|
|
@@ -370,60 +400,64 @@
|
|
|
370
400
|
],
|
|
371
401
|
"layout": {
|
|
372
402
|
"PRD": {
|
|
373
|
-
"x":
|
|
374
|
-
"y":
|
|
403
|
+
"x": 170,
|
|
404
|
+
"y": 40
|
|
375
405
|
},
|
|
376
406
|
"ALIGN": {
|
|
377
|
-
"x":
|
|
378
|
-
"y":
|
|
407
|
+
"x": 170,
|
|
408
|
+
"y": 184
|
|
379
409
|
},
|
|
380
410
|
"DESIGN": {
|
|
381
|
-
"x":
|
|
382
|
-
"y":
|
|
411
|
+
"x": 170,
|
|
412
|
+
"y": 328
|
|
383
413
|
},
|
|
384
|
-
"
|
|
385
|
-
"x":
|
|
414
|
+
"INTERACTION": {
|
|
415
|
+
"x": 170,
|
|
386
416
|
"y": 472
|
|
387
417
|
},
|
|
388
|
-
"
|
|
389
|
-
"x":
|
|
390
|
-
"y":
|
|
391
|
-
},
|
|
392
|
-
"UI_VISUAL": {
|
|
393
|
-
"x": 480.00000000000006,
|
|
394
|
-
"y": 664
|
|
418
|
+
"CODE_BACKEND": {
|
|
419
|
+
"x": 300,
|
|
420
|
+
"y": 616
|
|
395
421
|
},
|
|
396
422
|
"UT_DESIGN": {
|
|
397
|
-
"x":
|
|
398
|
-
"y":
|
|
423
|
+
"x": 300,
|
|
424
|
+
"y": 760
|
|
399
425
|
},
|
|
400
426
|
"UT_DEV": {
|
|
401
|
-
"x":
|
|
402
|
-
"y":
|
|
427
|
+
"x": 300,
|
|
428
|
+
"y": 904
|
|
403
429
|
},
|
|
404
430
|
"E2E_DESIGN": {
|
|
405
|
-
"x":
|
|
406
|
-
"y":
|
|
431
|
+
"x": 300,
|
|
432
|
+
"y": 1048
|
|
407
433
|
},
|
|
408
434
|
"E2E_DEV": {
|
|
409
|
-
"x":
|
|
410
|
-
"y":
|
|
435
|
+
"x": 300,
|
|
436
|
+
"y": 1192
|
|
437
|
+
},
|
|
438
|
+
"CODE_UI": {
|
|
439
|
+
"x": 40,
|
|
440
|
+
"y": 616
|
|
441
|
+
},
|
|
442
|
+
"UI_VISUAL": {
|
|
443
|
+
"x": 40,
|
|
444
|
+
"y": 760
|
|
411
445
|
},
|
|
412
446
|
"INTEGRATE": {
|
|
413
|
-
"x":
|
|
414
|
-
"y":
|
|
447
|
+
"x": 170,
|
|
448
|
+
"y": 1336
|
|
415
449
|
},
|
|
416
450
|
"ACCEPT": {
|
|
417
|
-
"x":
|
|
418
|
-
"y":
|
|
451
|
+
"x": 170,
|
|
452
|
+
"y": 1480
|
|
419
453
|
},
|
|
420
454
|
"ARCHIVE": {
|
|
421
|
-
"x":
|
|
422
|
-
"y":
|
|
455
|
+
"x": 170,
|
|
456
|
+
"y": 1624
|
|
423
457
|
}
|
|
424
458
|
},
|
|
425
459
|
"isDefault": false,
|
|
426
|
-
"version": "3.
|
|
460
|
+
"version": "3.5.0"
|
|
427
461
|
},
|
|
428
462
|
"dependencies": {
|
|
429
463
|
"skills": [
|
|
@@ -439,13 +473,13 @@
|
|
|
439
473
|
{
|
|
440
474
|
"name": "tech-design",
|
|
441
475
|
"description": "将产品需求转化为可实现、可验证的技术设计",
|
|
442
|
-
"content": "# 技术方案设计\n\n将已确认的产品需求转化为可以直接指导实现和验证的技术设计。\n\n## 工作原则\n\n- 先理解需求、项目约束和现有架构，再选择技术方案。\n- 设计必须覆盖需求，但不扩张产品范围。\n- 关键决策说明备选方案、最终选择及取舍理由。\n- 设计到足以消除实现歧义为止，不编写生产代码或完整测试代码。\n- 根据任务范围调整设计深度，避免为简单任务堆叠无关内容。\n\n## 执行方法\n\n1. 建立需求、验收标准与设计内容的对应关系。\n2.
|
|
476
|
+
"content": "# 技术方案设计\n\n将已确认的产品需求转化为可以直接指导实现和验证的技术设计。\n\n## 工作原则\n\n- 先理解需求、项目约束和现有架构，再选择技术方案。\n- 默认以图形表达结构与流程：架构图（模块或组件划分及相互关系）与核心功能流程图（主要功能的执行步骤与关键分支）。\n- 设计必须覆盖需求，但不扩张产品范围。\n- 关键决策说明备选方案、最终选择及取舍理由。\n- 设计到足以消除实现歧义为止，不编写生产代码或完整测试代码。\n- 根据任务范围调整设计深度，避免为简单任务堆叠无关内容。\n\n## 执行方法\n\n1. 建立需求、验收标准与设计内容的对应关系。\n2. 识别模块边界、核心流程及适用的数据和接口契约，并据此形成架构图与核心功能流程图。\n3. 根据实际影响设计异常处理、安全、兼容迁移、发布回退和验证方式。\n4. 检查设计是否足以支持实现、测试和验收。\n5. 读取 `references/template.md` 形成技术方案；可以增加任务特有章节，但必须保留最低必备信息。\n\n## 模板使用规则\n\n所有技术方案必须包含：\n\n- 目标与范围；\n- 现状与约束；\n- 方案总览；\n- 需求与设计对应；\n- 关键决策；\n- 详细设计；\n- 验证方案；\n- 风险与开放问题。\n\n所有技术方案默认包含两张图，无需用户额外要求：\n\n- **架构图**：呈现系统或模块的划分及其相互关系；\n- **核心功能流程图**：呈现主要功能的执行步骤与关键分支。\n\n图使用项目约定的图形表达方式；项目未约定时使用可渲染的图形语法（如 Mermaid），不使用纯文字罗列或代码片段代替。示意级别即可，不追求专业绘图工具的精细度。图中出现的模块、步骤和分支必须在正文有对应说明，正文描述的结构与流程也必须在图中出现。两张图不因任务规模小、改动简单或用户未要求而省略；确实不存在可表达的结构或流程时，按“不适用项”规则写明具体对象和理由。\n\n以下内容按任务实际影响填写：\n\n- 数据设计；\n- 接口与交互契约；\n- 安全与可靠性；\n- 发布、迁移与回退。\n\n按需章节不适用时，可以省略正文，但必须在“不适用项”中记录具体对象和理由。不得保留空章节，也不得只写“无影响”而不说明判断依据。\n\n## 设计边界\n\n允许使用字段表、接口 schema、状态机、时序图、架构图、流程图、决策表和测试矩阵表达设计。\n\n不写完整方法体、可直接执行的生产代码、完整测试代码或完整配置文件；这些内容属于后续实现节点。",
|
|
443
477
|
"category": "process",
|
|
444
|
-
"version": "1.
|
|
478
|
+
"version": "1.1.0",
|
|
445
479
|
"references": [
|
|
446
480
|
{
|
|
447
481
|
"path": "references/template.md",
|
|
448
|
-
"content": "# <任务标题>技术方案\n\n> 输入需求：<PRD 或任务需求引用>\n> 状态：<草稿/已确认>\n> 版本：<版本>\n\n## 1. 目标与范围【必备】\n\n- 解决的问题：\n- 本次覆盖：\n- 明确不做：\n- 成功判定：\n\n## 2. 现状与约束【必备】\n\n说明现有架构、相关模块、项目规则、兼容要求和已知限制。\n\n## 3. 方案总览【必备】\n\n### 3.1 整体设计\n\n
|
|
482
|
+
"content": "# <任务标题>技术方案\n\n> 输入需求：<PRD 或任务需求引用>\n> 状态：<草稿/已确认>\n> 版本：<版本>\n\n## 1. 目标与范围【必备】\n\n- 解决的问题：\n- 本次覆盖：\n- 明确不做：\n- 成功判定：\n\n## 2. 现状与约束【必备】\n\n说明现有架构、相关模块、项目规则、兼容要求和已知限制。\n\n## 3. 方案总览【必备】\n\n### 3.1 整体设计\n\n默认必须包含以下两张图（示意级别，使用可渲染的图形语法，如 Mermaid；项目已约定图形表达方式时从其约定），并配合正文说明：\n\n- **架构图**：系统或模块的划分及其相互关系；\n- **核心功能流程图**：主要功能的执行步骤与关键分支。\n\n图中的模块、步骤和分支必须在正文有对应说明；正文描述的结构与流程必须在图中出现。\n\n### 3.2 需求与设计对应【必备】\n\n| 需求或验收项 | 对应设计章节 | 覆盖说明 |\n|---|---|---|\n\n### 3.3 关键决策【必备】\n\n| 决策点 | 备选方案 | 最终选择 | 取舍理由 |\n|---|---|---|---|\n\n## 4. 详细设计【必备】\n\n按功能或模块组织；每项说明：\n\n- 职责与边界；\n- 输入、输出和依赖；\n- 正常流程；\n- 异常与边界流程；\n- 数据或状态变化；\n- 与其他模块的交互；\n- 兼容与迁移影响。\n\n## 5. 数据设计【按需】\n\n说明数据结构、字段、约束、关系、索引、生命周期和存量数据处理。\n\n## 6. 接口与交互契约【按需】\n\n说明调用方、输入输出、错误响应、权限、幂等和兼容策略。\n\n## 7. 安全与可靠性【按需】\n\n说明权限边界、输入安全、敏感信息、一致性、部分失败、重试、恢复和回滚。\n\n## 8. 验证方案【必备】\n\n| 验证对象 | 验证层级 | 场景 | 预期结果 |\n|---|---|---|---|\n\n说明单元测试、集成测试、端到端测试和人工验证的边界。\n\n## 9. 发布、迁移与回退【按需】\n\n说明部署顺序、配置变化、数据迁移、兼容窗口、可观测信号、回退条件和回退步骤。\n\n## 10. 风险与开放问题【必备】\n\n| 风险或问题 | 影响 | 应对方式 | 状态 |\n|---|---|---|---|\n\n## 11. 不适用项【必备】\n\n列出模板中不适用于当前任务的内容及理由；没有时写“无”。"
|
|
449
483
|
}
|
|
450
484
|
],
|
|
451
485
|
"scope": "global"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"exportFormatVersion": "1.0",
|
|
3
|
-
"exportedAt": "2026-09-
|
|
3
|
+
"exportedAt": "2026-09-13T10:34:25.485Z",
|
|
4
4
|
"warnings": [],
|
|
5
5
|
"template": {
|
|
6
6
|
"name": "quick_workflow",
|
|
@@ -28,7 +28,7 @@
|
|
|
28
28
|
"label": "快速设计",
|
|
29
29
|
"phase": "entry",
|
|
30
30
|
"track": "all",
|
|
31
|
-
"prompt": "# 快速设计\n\n## 节点职责\n\n将用户描述的小型改动直接整理为最小技术方案——改动点、影响面、验证方式——经一次独立 AI 评审和用户人工确认后进入编码。本流程不设独立需求节点：用户描述与任务上下文就是需求源头。本节点只产出方案，不编写生产代码或测试代码。\n\n## 依赖信息\n\n先检查当前任务上下文：用户需求描述、验收标准、非目标、已有决策，以及项目和所属模块的提示词。加载 `workflow-discipline`；调用独立 `arch-reviewer` 完成方案评审。\n\n直接阅读相关代码和文档，确认真实改动位置、调用关系、依赖方与影响。缺少会改变方案的关键信息时先从仓库现状补齐；仍存在歧义时集中向用户说明并确认，不凭猜测设计。\n\n## 正向执行流程\n\n1. 从用户描述提炼目标行为、保持不变的行为和非目标，整理为可核对的改动点清单。\n2. 逐项定位改动点涉及的模块、调用关系与依赖方，说明对接口、数据、配置、兼容性和用户行为的影响。\n3.
|
|
31
|
+
"prompt": "# 快速设计\n\n## 节点职责\n\n将用户描述的小型改动直接整理为最小技术方案——改动点、影响面、验证方式——经一次独立 AI 评审和用户人工确认后进入编码。本流程不设独立需求节点：用户描述与任务上下文就是需求源头。本节点只产出方案，不编写生产代码或测试代码。\n\n## 依赖信息\n\n先检查当前任务上下文：用户需求描述、验收标准、非目标、已有决策，以及项目和所属模块的提示词。加载 `workflow-discipline`；调用独立 `arch-reviewer` 完成方案评审。\n\n直接阅读相关代码和文档，确认真实改动位置、调用关系、依赖方与影响。缺少会改变方案的关键信息时先从仓库现状补齐；仍存在歧义时集中向用户说明并确认，不凭猜测设计。\n\n## 正向执行流程\n\n1. 从用户描述提炼目标行为、保持不变的行为和非目标，整理为可核对的改动点清单。\n2. 逐项定位改动点涉及的模块、调用关系与依赖方，说明对接口、数据、配置、兼容性和用户行为的影响。\n3. 形成最小技术方案，必含：背景与目标、改动点清单（位置+目标行为）、影响面、架构图与核心功能流程图、验证方式、非目标、必要决策；验证方式须能对应验收标准。两张图用可渲染的图形语法表达（项目未约定时用 Mermaid），示意级别即可，不使用文字罗列代替；图中模块、步骤、分支与正文互相有对应说明。\n4. 检查复杂度红线：跨多个边界模块、新增公开接口或数据契约、数据迁移、新依赖、破坏性变更、需要多路线取舍。命中时说明快速流程为何不足，建议改走完整流程；用户明确接受风险坚持快速路径时，记录确认原文。\n5. 将方案全文与客观约束（用户描述、验收标准、参照代码位置）交给 `arch-reviewer` 单轮独立评审，不提供主会话的设计结论。存在 BLOCKER 或 HIGH 时修复后重新发起评审；MEDIUM、LOW 逐项处理或记录保留理由，直至评审 PASS。\n6. 评审通过后先把方案全文落盘为可独立阅读的文档（项目正式文档路径；尚未确定时写临时草稿并注明），再向用户呈现该文档的可读位置、改动点清单、影响面、验证方式、AI 评审结论与红线判断，等待人工确认——确认前用户必须能打开完整方案。\n7. 用户确认后：把已呈现的方案文档按项目文档约定保存为正式文档并登记任务产物（携带全文；超限时路径引用须说明理由），已落盘的草稿直接转为正式文档，不重写内容；按项目分支策略创建任务分支并记录关联。若预判改动可能无可自动验证行为，在方案中显式声明——该声明进入编码节点测试范围判定与本次确认范围。\n\n## 产出与检查\n\n推进前确认：每个改动点有位置、目标行为与影响说明；验证方式对应验收标准；方案含架构图与核心功能流程图，以可渲染的图形呈现且与正文一致（确实不适用时已写明对象与理由）；复杂度红线已检查，命中项已升级或取得用户风险确认；`arch-reviewer` 最终 PASS 且 Findings 处理留痕；用户明确确认且原文已记录；方案全文已保存登记；任务分支已就绪；呈现给用户的方案文档可独立打开阅读，且与确认的版本一致。\n\n## 任务差异处理\n\n纯文档、配置类改动可裁剪方案章节，但改动点、影响面、架构图与核心功能流程图、验证方式、非目标不得缺失。信息不足以形成方案时保留在本节点补齐，不推进。\n\n## 节点记录与推进\n\n将方案要点、改动点、影响面、验证方式、红线判断、AI 评审结论与轮次、用户确认原文、方案产物与分支信息写入节点记录，推进编码节点。",
|
|
32
32
|
"skills": [
|
|
33
33
|
"workflow-discipline"
|
|
34
34
|
],
|
|
@@ -37,8 +37,8 @@
|
|
|
37
37
|
],
|
|
38
38
|
"sourcePreset": {
|
|
39
39
|
"code": "quick-design",
|
|
40
|
-
"version": "1.
|
|
41
|
-
"contentHash": "
|
|
40
|
+
"version": "1.1.0",
|
|
41
|
+
"contentHash": "98b00192cc580305",
|
|
42
42
|
"agents": [
|
|
43
43
|
"arch-reviewer"
|
|
44
44
|
]
|
|
@@ -99,7 +99,7 @@
|
|
|
99
99
|
"label": "集成验证",
|
|
100
100
|
"phase": "test",
|
|
101
101
|
"track": "all",
|
|
102
|
-
"prompt": "# 集成验证\n\n## 节点职责\n\n
|
|
102
|
+
"prompt": "# 集成验证\n\n## 节点职责\n\n将远程主线最新状态整合到任务分支，并在最终集成态执行适用回归，形成绑定明确版本的验证结论。版本控制与范围判断由当前执行者负责——范围判断是严肃决策，跑与不跑都必须有证据支撑，全量是须举证的选项而非默认值。测试命令交给独立 `test-executor` 执行；若产生代码修复，再交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、技术方案、实现与测试记录、`align-branch` 的基础分支与合并记录，以及项目的分支策略、测试体系和所属模块提示词。加载 `workflow-discipline`，调用 `test-executor` 执行回归；发生代码修复时调用 `code-reviewer`。测试失败且根因不明确时，再加载 `bugfix-root-cause-verification`。\n\n优先使用 `align-branch` 已记录的基础分支；记录缺失时，按与该节点相同的规则从任务上下文或项目提示词解析，例如 `main`、`master` 或 `dev`。仍无法解析时询问用户是否需要合并某个分支的远程代码，不根据版本历史猜测基础分支。\n\n## 执行流程\n\n1. 获取远程状态，优先读取 `align-branch` 记录的基础分支；记录缺失时从任务上下文或项目提示词解析，仍无法解析则询问用户。记录当前任务版本、基础分支、远程版本及判断依据。\n2. 用户明确表示无需合并时记录该决定；否则按项目策略整合基础分支的远程最新代码。发生冲突时理解双方意图后逐项融合并验证结果，不盲目选择任一侧；无法可靠解决时说明冲突与缺失决策并暂停。\n3. 汇总任务改动和主线整合改动，读取项目测试目录、配置、脚本与现有用例，列出适用的测试层级和执行入口；项目未定义的层级记录 N/A。\n4. 回归执行决策由「是否执行」与「执行什么」两半构成，每一半都必须由证据支撑，禁止无分析的保守回退：\n - 零差异不重跑：某层级相对既有已验证版本（绑定明确版本标识、全绿证据在案）覆盖面差异为空时，该层级禁止重复执行，记录绑定证据替代重跑；\n - 有差异走判断链：a) 变更清单——汇总任务改动、主线整合改动与集成期修复，落到具体文件和对外可见的符号、契约、配置；b) 依赖分析——逐变更点查明引用方与波及面（导入、调用、共享契约、构建配置），得出受影响模块清单；c) 测试映射——把受影响模块映射到具体用例（既有用例位置、任务新增或修改的用例、所属层级与执行入口）；d) 最小充分决策——按定向用例、受影响模块、整层级的顺序逐级扩大，每次扩大都指出上一级不充分的具体证据；\n - 全量须举证：仅当判断链证据表明影响面确实覆盖整个层级（如横切基础设施、共享契约、构建配置变更）才执行全量。宣称「无法判断影响范围」前必须已完成 a)–c) 分析；分析后仍存在的盲区逐条列明（哪个变更点、查了什么、缺什么信息），把盲区对应的补充用例并入执行范围并留痕。未做分析就宣称无法判断、或以「保险起见」跳过判断直接全量，均判定为范围决策失败。\n5. 将明确的命令、顺序、范围和通过标准交给 `test-executor` 执行——委派命令的覆盖范围必须与第 4 条判断链结论一致，判了定向就执行定向入口，不得委派时顺手扩大。依据事实报告核对各层级统计、失败、跳过和日志。\n6. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按需加载 `bugfix-root-cause-verification`，确认根因后再修改代码、测试或环境。\n7. 每次修复后重新执行原失败范围和受影响回归。不得通过删除有效测试、skip/only、缩小应执行范围、放宽正确断言、吞异常或硬编码结果制造通过。\n8. 检查新增 skip/only、测试删除、未执行的适用层级、范围遗漏和统计对账。发生代码修复时，将客观约束与变更位置交给 `code-reviewer`；修复 BLOCKER、HIGH Findings 后重跑受影响测试并复审，直至测试通过且评审为 PASS。\n9. 记录最终同步状态、实际回归范围、测试结果和已验证的提交或等价版本标识，确保后续能够判断证据是否仍有效。\n\n## 产出与检查\n\n推进前确认：\n\n- 基础分支沿用 `align-branch` 记录，或已按相同规则重新解析并留痕；\n- 基础分支的远程状态已获取并完成整合，或用户已明确表示无需合并；\n- 所有冲突均已理解并正确融合；\n- 项目适用测试层级与执行入口已识别，N/A 有具体依据；\n- 回归范围由完整判断链支撑（变更清单 → 依赖分析 → 测试映射 → 逐级扩大决策），每个执行范围都能指认其覆盖的变更点；零差异层级以绑定证据替代重跑；全量执行附有影响面覆盖整个层级的具体证据；不存在无分析的全量兜底；\n- `test-executor` 报告所有适用回归通过，失败为 0，未授权跳过为 0；\n- 所有失败均在根因明确后修复，没有制造假绿；\n- 发生代码修复时，`code-reviewer` 最终结论为 PASS；\n- 集成结论绑定明确版本，日志和报告可追溯。\n\n## 任务差异处理\n\n基础分支没有新提交时无需制造合并提交；回归是否执行、执行什么，一律按第 4 条的零差异判定与判断链决定——集成态与已验证版本一致且证据在案时以证据绑定替代重跑，集成态有新增内容时按判断链定范围。用户明确表示无需合并时保留决定，验证决策同样按第 4 条执行。根据项目实际体系选择测试层级和命令，不擅自引入未定义的测试类型。远程状态不可获取、冲突无法可靠解决，或修复涉及破坏性契约、新依赖和真实范围扩张时，说明证据与影响并暂停；同一问题多轮不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将基础分支来源、同步策略与结果、任务和远程版本、冲突处理、适用测试层级、回归范围判断链（变更清单、依赖分析、测试映射、逐级扩大证据、零差异证据绑定）及结论、实际命令与统计、失败根因和修复、完整性检查、代码评审结果、日志与报告引用、最终已验证版本写入当前节点记录。完成上述检查后推进下一节点。\n",
|
|
103
103
|
"skills": [
|
|
104
104
|
"workflow-discipline"
|
|
105
105
|
],
|
|
@@ -109,8 +109,8 @@
|
|
|
109
109
|
],
|
|
110
110
|
"sourcePreset": {
|
|
111
111
|
"code": "test-integrate",
|
|
112
|
-
"version": "1.
|
|
113
|
-
"contentHash": "
|
|
112
|
+
"version": "1.4.0",
|
|
113
|
+
"contentHash": "2a6c9a9bbc3452ce",
|
|
114
114
|
"agents": [
|
|
115
115
|
"test-executor",
|
|
116
116
|
"code-reviewer"
|
|
@@ -176,7 +176,7 @@
|
|
|
176
176
|
}
|
|
177
177
|
],
|
|
178
178
|
"isDefault": false,
|
|
179
|
-
"version": "2.0.
|
|
179
|
+
"version": "2.0.2"
|
|
180
180
|
},
|
|
181
181
|
"dependencies": {
|
|
182
182
|
"skills": [
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: task-create
|
|
3
3
|
description: 本项目任务创建入口：需求访谈 → 类型/轨道判定 → 模板与剪枝匹配 → 结构化写入 siming。（项目级待定制骨架——按下方定制清单逐项替换后方可正式使用）
|
|
4
|
-
version: 1.
|
|
4
|
+
version: 1.1.0
|
|
5
5
|
category: process
|
|
6
6
|
---
|
|
7
7
|
|
|
@@ -11,7 +11,7 @@ category: process
|
|
|
11
11
|
|
|
12
12
|
## 定制清单（逐项完成后删除本段标记）
|
|
13
13
|
|
|
14
|
-
- [ ] ① 替换「模板实况表」：按本项目实际组装的模板填写模板 code
|
|
14
|
+
- [ ] ① 替换「模板实况表」：按本项目实际组装的模板填写模板 code、适用任务类型与剪枝规则（剪枝规则列按下方「轨道剪枝语义」写引擎自动剪枝结果）
|
|
15
15
|
- [ ] ② 替换「模块映射」：backend / ui 轨道对应的真实目录范围
|
|
16
16
|
- [ ] ③ 替换「项目标识」：project key、仓库地址、分支模型
|
|
17
17
|
- [ ] ④ 替换「快速通道规则」：按本项目流程约定确认或改写
|
|
@@ -67,6 +67,13 @@ category: process
|
|
|
67
67
|
| ui-tweak | `<本项目快速修复模板 code>` | `<占位>` |
|
|
68
68
|
| research | `<本项目调研模板 code>` | `<占位>` |
|
|
69
69
|
|
|
70
|
+
**轨道剪枝语义（引擎行为，定制时不可改写，实况表据此填写）**：
|
|
71
|
+
|
|
72
|
+
- 节点轨道（track）标注含义：`all` = 全轨道保留；`backend` / `ui` / `research` 及自定义轨道 = 仅匹配轨道的任务保留；
|
|
73
|
+
- 创建任务只传 `track`，引擎按节点轨道自动剪枝——轨道剪枝本身无需 skipNodes，但模板存在轨道剪枝后不被行走的分支时，仍须按本表 skipNodes 额外裁剪（如 research 模板的不行走分支）：backend / ui / research 及自定义轨道任务保留「本轨道 + all」节点；mixed 任务保留 backend + ui + all 全链（双链串行，链序由引擎消歧的模板边声明序决定）；
|
|
74
|
+
- `skipNodes` 仅用于额外裁剪——模板中存在但本任务确实不需要的节点，且须可从本表推导留痕；
|
|
75
|
+
- 两层概念区分：模板级永久裁剪在项目接入时改模板定义（影响所有后续任务）；任务级轨道剪枝在创建时由引擎自动执行（只影响本任务）。本实况表按裁剪后的模板填写，剪枝规则列写轨道自动剪枝结果（如「backend 任务无 CODE_UI/UI_VISUAL；ui 任务无 CODE_BACKEND；mixed 全链保留」）。
|
|
76
|
+
|
|
70
77
|
**快速通道规则（占位——定制项 ④）**：`<如：bugfix 类型允许跳过 PRD 节点（仅跳 PRD，不跳验收与归档）；除此之外不使用任何快速通道>`
|
|
71
78
|
|
|
72
79
|
### 5. 模块映射（占位——定制项 ②）
|