@siming-org/cli 0.8.0 → 0.8.2
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.
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"exportFormatVersion": "1.0",
|
|
3
|
-
"exportedAt": "2026-09-
|
|
3
|
+
"exportedAt": "2026-09-26T15:30:41.841Z",
|
|
4
4
|
"warnings": [],
|
|
5
5
|
"template": {
|
|
6
6
|
"name": "quick_workflow",
|
|
@@ -11,24 +11,38 @@
|
|
|
11
11
|
"label": "分支对齐",
|
|
12
12
|
"phase": "entry",
|
|
13
13
|
"track": "all",
|
|
14
|
-
"prompt": "# 分支对齐\n\n## 节点职责\n\n在后续工作开始前，确认是否需要合并基础分支的远程最新代码。\n\n## 依赖信息\n\n检查当前任务上下文和项目提示词，从中解析基础分支，例如 `main`、`master` 或 `dev`。按名称加载 `workflow-discipline` Skill。\n\n## 正向执行流程\n\n1. 能解析出基础分支时，获取并合并该分支的远程最新代码。\n2. 无法解析时，询问用户是否需要合并某个分支的远程代码。\n3. 用户指定分支后执行合并；用户明确表示不需要时，直接推进下一节点。\n\n## 产出检查\n\n推进前确认：基础分支的远程代码已成功合并，或者用户已明确表示不需要合并。\n\n## 任务差异处理\n\n没有远程仓库或用户不要求合并时，记录不执行的事实和理由。合并发生冲突且无法可靠解决时，保留在当前节点并向用户说明。\n\n## 节点记录与推进\n\n
|
|
14
|
+
"prompt": "# 分支对齐\n\n## 节点职责\n\n在后续工作开始前，确认是否需要合并基础分支的远程最新代码。\n\n## 依赖信息\n\n检查当前任务上下文和项目提示词，从中解析基础分支，例如 `main`、`master` 或 `dev`。按名称加载 `workflow-discipline` Skill。\n\n## 正向执行流程\n\n1. 能解析出基础分支时，获取并合并该分支的远程最新代码。\n2. 无法解析时，询问用户是否需要合并某个分支的远程代码。\n3. 用户指定分支后执行合并；用户明确表示不需要时，直接推进下一节点。\n\n## 产出检查\n\n推进前确认：基础分支的远程代码已成功合并，或者用户已明确表示不需要合并。\n\n## 任务差异处理\n\n没有远程仓库或用户不要求合并时，记录不执行的事实和理由。合并发生冲突且无法可靠解决时，保留在当前节点并向用户说明。\n\n## 节点记录与推进\n\n将基础分支经 record-set 结构化写入 baseBranch 字段（后续节点门禁的参数解析链依赖该值）；记录合并结果，或不执行合并的理由，然后推进下一节点。",
|
|
15
15
|
"skills": [
|
|
16
16
|
"workflow-discipline"
|
|
17
17
|
],
|
|
18
18
|
"agents": [],
|
|
19
19
|
"sourcePreset": {
|
|
20
20
|
"code": "align-branch",
|
|
21
|
-
"version": "1.
|
|
22
|
-
"contentHash": "
|
|
21
|
+
"version": "1.4.0",
|
|
22
|
+
"contentHash": "1f0f21110ce062f9",
|
|
23
23
|
"agents": []
|
|
24
|
-
}
|
|
24
|
+
},
|
|
25
|
+
"toolChecks": [
|
|
26
|
+
{
|
|
27
|
+
"type": "git-base-recorded"
|
|
28
|
+
},
|
|
29
|
+
{
|
|
30
|
+
"type": "git-base-merged"
|
|
31
|
+
}
|
|
32
|
+
],
|
|
33
|
+
"aiChecks": [
|
|
34
|
+
{
|
|
35
|
+
"id": "align-merge-or-waive",
|
|
36
|
+
"item": "基础分支远程最新代码已合并入当前分支；用户明示不需合并时已写 decisions（topic=merge-waived）并附用户原话"
|
|
37
|
+
}
|
|
38
|
+
]
|
|
25
39
|
},
|
|
26
40
|
{
|
|
27
41
|
"id": "DESIGN",
|
|
28
42
|
"label": "快速设计",
|
|
29
43
|
"phase": "entry",
|
|
30
44
|
"track": "all",
|
|
31
|
-
"prompt": "# 快速设计\n\n## 节点职责\n\n将用户描述的小型改动直接整理为最小技术方案——改动点、影响面、验证方式——经一次独立 AI
|
|
45
|
+
"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 处理留痕；审批材料（文档位置、改动点清单、影响面、验证方式、AI 评审结论、红线判断）已完整呈现，可支撑暂停点审批；方案全文已保存登记；任务分支已就绪；呈现给用户的方案文档可独立打开阅读，且与确认的版本一致。\n\n## 任务差异处理\n\n纯文档、配置类改动可裁剪方案章节，但改动点、影响面、架构图与核心功能流程图、验证方式、非目标不得缺失。信息不足以形成方案时保留在本节点补齐，不推进。\n\n## 节点记录与推进\n\n将方案要点、改动点、影响面、验证方式、红线判断、AI 评审结论与轮次、方案产物与分支信息写入节点记录，推进编码节点（确认原文由暂停点审批记录承载，须逐字引用用户确认表态、不得转述失真；不双写）。",
|
|
32
46
|
"skills": [
|
|
33
47
|
"workflow-discipline"
|
|
34
48
|
],
|
|
@@ -37,8 +51,8 @@
|
|
|
37
51
|
],
|
|
38
52
|
"sourcePreset": {
|
|
39
53
|
"code": "quick-design",
|
|
40
|
-
"version": "1.
|
|
41
|
-
"contentHash": "
|
|
54
|
+
"version": "1.2.0",
|
|
55
|
+
"contentHash": "522c3d00f4ee7a26",
|
|
42
56
|
"agents": [
|
|
43
57
|
"arch-reviewer"
|
|
44
58
|
]
|
|
@@ -73,7 +87,7 @@
|
|
|
73
87
|
"label": "前端编码与测试",
|
|
74
88
|
"phase": "track",
|
|
75
89
|
"track": "ui",
|
|
76
|
-
"prompt": "# 前端编码与测试\n\n## 节点职责\n\n在单一节点内完成界面实现与验证闭环：界面生产代码与配套测试、测试全绿、视觉验证、独立代码评审，五项同为节点完成判定。\n\n## 依赖信息\n\n
|
|
90
|
+
"prompt": "# 前端编码与测试\n\n## 节点职责\n\n在单一节点内完成界面实现与验证闭环：界面生产代码与配套测试、测试全绿、视觉验证、独立代码评审，五项同为节点完成判定。\n\n## 依赖信息\n\n同「后端编码与测试」，另：涉及后端接口时读取服务端入口与请求响应结构确认真实契约；委派 `visual-reviewer` 自主采证执行视觉验证（提供运行地址、认证与数据前置，采证由其完成）；`coding-standards` 读 UI 相关 reference。\n\n## 正向执行流程\n\n1. 将方案整理为界面实现项：页面结构、交互流程、视觉状态、数据状态、响应式与可访问性；调查现有页面、组件、设计系统与状态管理，沿用既有模式。\n2. 实现生产代码：完整覆盖结构、数据流、事件、副作用、样式与反馈；处理加载、空、错误、成功、重复操作、危险操作、长内容、窄屏、键盘与焦点等适用状态；不清除无关注释。\n3. 编写配套测试：按项目声明的前端验证体系（类型检查+组件/逻辑单测）覆盖本次改动；同节点产出生产与测试代码（同后端条款）。\n4. 无可自动验证行为判定与静态检查：同后端条款。\n5. 测试执行交 `test-executor`，纪律同后端（根因先行、禁制造通过）。\n6. 界面可视改动委派 `visual-reviewer` 自主采证验证（主会话提供运行地址、认证与数据前置，不预备截图），纳入完成判定；纯非可视改动（逻辑/数据层）记录不适用理由。\n7. `code-reviewer` 独立评审至 PASS，条款同后端。\n\n## 产出与检查\n\n推进前确认：界面实现与方案逐项对应；配套测试完成（或判定已记录）；静态检查通过；`test-executor` 全绿；`visual-reviewer` PASS（或不适用理由已记录）；`code-reviewer` PASS。\n\n## 任务差异处理 / 节点记录与推进\n\n同后端条款，另记录视觉验证结论与不适用理由。",
|
|
77
91
|
"skills": [
|
|
78
92
|
"coding-standards",
|
|
79
93
|
"workflow-discipline"
|
|
@@ -85,8 +99,8 @@
|
|
|
85
99
|
],
|
|
86
100
|
"sourcePreset": {
|
|
87
101
|
"code": "quick-code-frontend",
|
|
88
|
-
"version": "1.
|
|
89
|
-
"contentHash": "
|
|
102
|
+
"version": "1.1.0",
|
|
103
|
+
"contentHash": "4ee29fe569790c0a",
|
|
90
104
|
"agents": [
|
|
91
105
|
"code-reviewer",
|
|
92
106
|
"test-executor",
|
|
@@ -99,7 +113,7 @@
|
|
|
99
113
|
"label": "集成验证",
|
|
100
114
|
"phase": "test",
|
|
101
115
|
"track": "all",
|
|
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
|
|
116
|
+
"prompt": "# 集成验证\n\n## 节点职责\n\n将远程主线最新状态整合到任务分支，并在最终集成态执行适用回归，形成绑定明确版本的验证结论。版本控制与范围判断由当前执行者负责——范围判断是严肃决策，跑与不跑都必须有证据支撑，全量是须举证的选项而非默认值。测试命令交给独立 `test-executor` 执行；若产生代码修复，再交给独立 `code-reviewer` 评审。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、技术方案、实现与测试记录、`align-branch` 的基础分支与合并记录，以及项目的分支策略、测试体系和所属模块提示词。加载 `workflow-discipline`，调用 `test-executor` 执行回归；发生代码修复时调用 `code-reviewer`。测试失败且根因不明确时，再加载 `bugfix-root-cause-verification`。\n\n优先使用 `align-branch` 已记录的基础分支；记录缺失时，按与该节点相同的规则从任务上下文或项目提示词解析，例如 `main`、`master` 或 `dev`。仍无法解析时询问用户是否需要合并某个分支的远程代码，不根据版本历史猜测基础分支。\n\n## 执行流程\n\n1. 获取远程状态，优先读取 `align-branch` 记录的基础分支；记录缺失时从任务上下文或项目提示词解析，仍无法解析则询问用户。记录当前任务版本、基础分支、远程版本及判断依据。\n2. 用户明确表示无需合并时记录该决定；否则按项目策略整合基础分支的远程最新代码。发生冲突时理解双方意图后逐项融合并验证结果，不盲目选择任一侧；无法可靠解决时说明冲突与缺失决策并暂停。\n3. 汇总任务改动和主线整合改动，读取项目测试目录、配置、脚本与现有用例，列出适用的测试层级和执行入口；项目未定义的层级记录 N/A。\n4. 回归执行决策由「是否执行」与「执行什么」两半构成，每一半都必须由证据支撑，禁止无分析的保守回退：\n - 零差异不重跑：某层级相对既有已验证版本（绑定明确版本标识、全绿证据在案）覆盖面差异为空时，该层级禁止重复执行，记录绑定证据替代重跑；\n - 有差异走判断链：a) 变更清单——汇总任务改动、主线整合改动与集成期修复，落到具体文件和对外可见的符号、契约、配置；b) 依赖分析——逐变更点查明引用方与波及面（导入、调用、共享契约、构建配置），得出受影响模块清单；c) 测试映射——把受影响模块映射到具体用例（既有用例位置、任务新增或修改的用例、所属层级与执行入口）；d) 最小充分决策——按定向用例、受影响模块、整层级的顺序逐级扩大，每次扩大都指出上一级不充分的具体证据；\n - 全量须举证：仅当判断链证据表明影响面确实覆盖整个层级（如横切基础设施、共享契约、构建配置变更）才执行全量。宣称「无法判断影响范围」前必须已完成 a)–c) 分析；分析后仍存在的盲区逐条列明（哪个变更点、查了什么、缺什么信息），把盲区对应的补充用例并入执行范围并留痕。未做分析就宣称无法判断、或以「保险起见」跳过判断直接全量，均判定为范围决策失败。\n5. 将明确的命令、顺序、范围和通过标准交给 `test-executor` 执行——委派命令的覆盖范围必须与第 4 条判断链结论一致，判了定向就执行定向入口，不得委派时顺手扩大。依据事实报告核对各层级统计、失败、跳过和日志。\n6. 测试失败时读取完整证据。根因明确则做最小正确修复；根因不明确则按需加载 `bugfix-root-cause-verification`，确认根因后再修改代码、测试或环境。\n7. 每次修复后重新执行原失败范围和受影响回归。不得通过删除有效测试、skip/only、缩小应执行范围、放宽正确断言、吞异常或硬编码结果制造通过。\n8. 检查新增 skip/only、测试删除、未执行的适用层级、范围遗漏和统计对账。发生代码修复时，将评审目标与材料（变更位置与相关任务信息）交给 `code-reviewer`；修复 BLOCKER、HIGH Findings 后重跑受影响测试并复审，直至测试通过且评审为 PASS。\n9. 记录最终同步状态、实际回归范围、测试结果和已验证的提交或等价版本标识，确保后续能够判断证据是否仍有效。\n\n## 产出与检查\n\n推进前确认：\n\n- 基础分支沿用 `align-branch` 记录，或已按相同规则重新解析并留痕；\n- 基础分支的远程状态已获取并完成整合，或用户已明确表示无需合并；\n- 所有冲突均已理解并正确融合；\n- 项目适用测试层级与执行入口已识别，N/A 有具体依据；\n- 回归范围由完整判断链支撑（变更清单 → 依赖分析 → 测试映射 → 逐级扩大决策），每个执行范围都能指认其覆盖的变更点；零差异层级以绑定证据替代重跑；全量执行附有影响面覆盖整个层级的具体证据；不存在无分析的全量兜底；\n- `test-executor` 报告所有适用回归通过，失败为 0，未授权跳过为 0；\n- 所有失败均在根因明确后修复，没有制造假绿；\n- 发生代码修复时，`code-reviewer` 最终结论为 PASS；\n- 集成结论绑定明确版本，日志和报告可追溯。\n\n## 任务差异处理\n\n基础分支没有新提交时无需制造合并提交；回归是否执行、执行什么，一律按第 4 条的零差异判定与判断链决定——集成态与已验证版本一致且证据在案时以证据绑定替代重跑，集成态有新增内容时按判断链定范围。用户明确表示无需合并时保留决定，验证决策同样按第 4 条执行。根据项目实际体系选择测试层级和命令，不擅自引入未定义的测试类型。远程状态不可获取、冲突无法可靠解决，或修复涉及破坏性契约、新依赖和真实范围扩张时，说明证据与影响并暂停；同一问题多轮不收敛时按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将基础分支来源、同步策略与结果、任务和远程版本、冲突处理、适用测试层级、回归范围判断链（变更清单、依赖分析、测试映射、逐级扩大证据、零差异证据绑定）及结论、实际命令与统计、失败根因和修复、完整性检查、代码评审结果、日志与报告引用、最终已验证版本（经 record-set 结构化写入 verifiedCommit 字段；本轮发生修复时经 record-set 写入 fixesApplied 次数）写入当前节点记录。完成上述检查后推进下一节点。\n",
|
|
103
117
|
"skills": [
|
|
104
118
|
"workflow-discipline"
|
|
105
119
|
],
|
|
@@ -109,30 +123,73 @@
|
|
|
109
123
|
],
|
|
110
124
|
"sourcePreset": {
|
|
111
125
|
"code": "test-integrate",
|
|
112
|
-
"version": "1.
|
|
113
|
-
"contentHash": "
|
|
126
|
+
"version": "1.5.0",
|
|
127
|
+
"contentHash": "ab9d4711637b2fc3",
|
|
114
128
|
"agents": [
|
|
115
129
|
"test-executor",
|
|
116
130
|
"code-reviewer"
|
|
117
131
|
]
|
|
118
|
-
}
|
|
132
|
+
},
|
|
133
|
+
"toolChecks": [
|
|
134
|
+
{
|
|
135
|
+
"type": "git-worktree-clean"
|
|
136
|
+
},
|
|
137
|
+
{
|
|
138
|
+
"type": "record-base-re-merged"
|
|
139
|
+
},
|
|
140
|
+
{
|
|
141
|
+
"type": "record-test-report"
|
|
142
|
+
},
|
|
143
|
+
{
|
|
144
|
+
"type": "record-fix-review-pass"
|
|
145
|
+
},
|
|
146
|
+
{
|
|
147
|
+
"type": "record-verified-commit"
|
|
148
|
+
}
|
|
149
|
+
],
|
|
150
|
+
"aiChecks": [
|
|
151
|
+
{
|
|
152
|
+
"id": "integ-regression-chain",
|
|
153
|
+
"item": "回归范围判断链（变更清单/依赖分析/测试映射/逐级扩大或零差异证据）已写入节点记录；最终已验证版本经 record-set 写 verifiedCommit"
|
|
154
|
+
}
|
|
155
|
+
]
|
|
119
156
|
},
|
|
120
157
|
{
|
|
121
158
|
"id": "ACCEPT",
|
|
122
159
|
"label": "发布验收",
|
|
123
160
|
"phase": "exit",
|
|
124
161
|
"track": "all",
|
|
125
|
-
"prompt": "# 发布验收\n\n## 节点职责\n\n
|
|
162
|
+
"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推进前将验收摘要、证据时效、验收标准对照、范围变化、已知问题和位置判定结果写入当前节点记录；非终态形态同时写入归档待办，并在归档完成前保持其未闭环。终态形态在用户确认后追加确认原文与归档结果；非终态形态在暂停点审批通过并完成归档后，追加审批引用、归档策略与结果、最终提交和远程状态，闭环归档待办。完成推进前检查后推进下一节点；批后追加动作发生在推进之后，不阻塞推进。",
|
|
126
163
|
"skills": [
|
|
127
164
|
"workflow-discipline"
|
|
128
165
|
],
|
|
129
166
|
"agents": [],
|
|
130
167
|
"sourcePreset": {
|
|
131
168
|
"code": "release-accept",
|
|
132
|
-
"version": "1.
|
|
133
|
-
"contentHash": "
|
|
169
|
+
"version": "1.5.0",
|
|
170
|
+
"contentHash": "d9ef06ee6f469ce2",
|
|
134
171
|
"agents": []
|
|
135
|
-
}
|
|
172
|
+
},
|
|
173
|
+
"toolChecks": [
|
|
174
|
+
{
|
|
175
|
+
"type": "git-worktree-clean"
|
|
176
|
+
},
|
|
177
|
+
{
|
|
178
|
+
"type": "git-archive-merged"
|
|
179
|
+
},
|
|
180
|
+
{
|
|
181
|
+
"type": "record-prev-nodes-done"
|
|
182
|
+
},
|
|
183
|
+
{
|
|
184
|
+
"type": "record-version-consistent"
|
|
185
|
+
}
|
|
186
|
+
],
|
|
187
|
+
"aiChecks": [
|
|
188
|
+
{
|
|
189
|
+
"id": "accept-confirmation-archived",
|
|
190
|
+
"item": "位置判定结果已写入节点记录；终态形态用户确认原文与归档执行结果（merge --no-ff 回基础分支并推送）、最终提交与远程状态已留痕；非终态形态归档待办已写入且动作清单明确（归档由审批通过后执行并回写闭环）"
|
|
191
|
+
}
|
|
192
|
+
]
|
|
136
193
|
}
|
|
137
194
|
],
|
|
138
195
|
"edges": [
|
|
@@ -176,16 +233,16 @@
|
|
|
176
233
|
}
|
|
177
234
|
],
|
|
178
235
|
"isDefault": false,
|
|
179
|
-
"version": "2.0.
|
|
236
|
+
"version": "2.0.6"
|
|
180
237
|
},
|
|
181
238
|
"dependencies": {
|
|
182
239
|
"skills": [
|
|
183
240
|
{
|
|
184
241
|
"name": "workflow-discipline",
|
|
185
242
|
"description": "DAG 节点执行、角色分离、授权、暂停点与任务边界纪律",
|
|
186
|
-
"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.
|
|
243
|
+
"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- 任务终止前，不推荐、不询问、不切换到下一个任务；终止后再输出完整任务总结。",
|
|
187
244
|
"category": "process",
|
|
188
|
-
"version": "1.
|
|
245
|
+
"version": "1.4.0",
|
|
189
246
|
"references": [],
|
|
190
247
|
"scope": "global"
|
|
191
248
|
},
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"exportFormatVersion": "1.0",
|
|
3
|
-
"exportedAt": "2026-09-
|
|
3
|
+
"exportedAt": "2026-09-26T15:30:41.838Z",
|
|
4
4
|
"warnings": [],
|
|
5
5
|
"template": {
|
|
6
6
|
"name": "research_workflow",
|
|
@@ -11,15 +11,15 @@
|
|
|
11
11
|
"label": "调研范围确认",
|
|
12
12
|
"phase": "entry",
|
|
13
13
|
"track": "research",
|
|
14
|
-
"prompt": "# 调研范围确认\n\n## 节点职责\n\n
|
|
14
|
+
"prompt": "# 调研范围确认\n\n## 节点职责\n\n将初始调研诉求整理为可直接执行的范围说明，明确需要回答的问题、纳入与排除边界、证据标准和交付物。关键缺口补齐后进入调研执行，用户确认由流程暂停点承载；本节点不提前给出调研结论或实施方案。\n\n## 依赖信息\n\n先检查当前任务上下文，读取初始诉求、期望支持的决策、已有材料、时间或环境限制，以及项目提示词。加载 `workflow-discipline`。\n\n优先复用已有信息，只对会改变调研方向、证据有效性或交付结果的关键缺口向用户确认。非关键的格式、命名和组织偏好沿用项目惯例；无惯例时采用清晰常规格式并记录默认。\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将调研背景与决策用途、问题清单、纳入与排除范围、证据标准、来源规则、交付物、限制、默认和审批材料索引写入当前节点记录（确认原文由暂停点审批记录承载，须逐字引用用户确认表态、不得转述失真；不双写），并登记完整范围说明产物（登记携带全文，超限时路径引用并说明理由）。完成上述检查后推进调研执行节点。",
|
|
15
15
|
"skills": [
|
|
16
16
|
"workflow-discipline"
|
|
17
17
|
],
|
|
18
18
|
"agents": [],
|
|
19
19
|
"sourcePreset": {
|
|
20
20
|
"code": "research-scope",
|
|
21
|
-
"version": "1.
|
|
22
|
-
"contentHash": "
|
|
21
|
+
"version": "1.5.0",
|
|
22
|
+
"contentHash": "c37bfd8f733f259b",
|
|
23
23
|
"agents": []
|
|
24
24
|
}
|
|
25
25
|
},
|
|
@@ -88,16 +88,16 @@
|
|
|
88
88
|
}
|
|
89
89
|
},
|
|
90
90
|
"isDefault": false,
|
|
91
|
-
"version": "1.0.
|
|
91
|
+
"version": "1.0.3"
|
|
92
92
|
},
|
|
93
93
|
"dependencies": {
|
|
94
94
|
"skills": [
|
|
95
95
|
{
|
|
96
96
|
"name": "workflow-discipline",
|
|
97
97
|
"description": "DAG 节点执行、角色分离、授权、暂停点与任务边界纪律",
|
|
98
|
-
"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.
|
|
98
|
+
"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- 任务终止前，不推荐、不询问、不切换到下一个任务；终止后再输出完整任务总结。",
|
|
99
99
|
"category": "process",
|
|
100
|
-
"version": "1.
|
|
100
|
+
"version": "1.4.0",
|
|
101
101
|
"references": [],
|
|
102
102
|
"scope": "global"
|
|
103
103
|
}
|