@siming-org/cli 0.6.4 → 0.6.5
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/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@siming-org/cli",
|
|
3
|
-
"version": "0.6.
|
|
3
|
+
"version": "0.6.5",
|
|
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/core": "0.6.5",
|
|
31
|
+
"@siming-org/server": "0.6.5"
|
|
32
32
|
},
|
|
33
33
|
"devDependencies": {
|
|
34
34
|
"tsup": "^8.3.5",
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"exportFormatVersion": "1.0",
|
|
3
|
-
"exportedAt": "2026-09-
|
|
3
|
+
"exportedAt": "2026-09-14T09:32:04.255Z",
|
|
4
4
|
"warnings": [],
|
|
5
5
|
"template": {
|
|
6
6
|
"name": "full_workflow",
|
|
@@ -159,7 +159,7 @@
|
|
|
159
159
|
"label": "单元测试设计",
|
|
160
160
|
"phase": "test",
|
|
161
161
|
"track": "backend",
|
|
162
|
-
"prompt": "# 单元测试设计\n\n## 节点职责\n\n为本次生产代码设计可执行的单元测试计划，明确测什么、为什么测以及预期什么。本节点只产出测试设计，不编写或执行测试代码，并通过独立 `test-reviewer` 评审设计质量。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、技术方案、生产代码变更、编码决策，以及项目和所属模块的测试约束。加载 `workflow-discipline`，调用独立 `test-reviewer` 评审测试设计。\n\n读取现有测试目录、配置和相关用例，确认测试框架、命名、替身边界、覆盖要求及与其他测试层级的分工。信息缺失时先从仓库现状推导；仍无法确定关键行为或测试边界时，说明缺失信息并暂停。\n\n## 执行流程\n\n1. 从需求、技术方案和生产代码整理本次需要验证的行为单元，明确输入、输出、状态变化、错误和副作用。\n2. 为每个行为单元设计正常、边界和失败场景，并按实际行为补充状态恢复、幂等、重试、权限、并发或资源生命周期场景；不适用项无需制造用例。\n3. 为每个用例写明优先级、前置条件、输入、替身或数据准备、操作、观察点、预期结果及覆盖的行为或分支，使后续实现者无需猜测测试意图。\n4. 明确哪些依赖使用真实实现、替身或受控环境，避免过度 Mock 掩盖业务行为，也避免把跨系统路径误当单元测试。\n5.
|
|
162
|
+
"prompt": "# 单元测试设计\n\n## 节点职责\n\n为本次生产代码设计可执行的单元测试计划，明确测什么、为什么测以及预期什么。本节点只产出测试设计，不编写或执行测试代码，并通过独立 `test-reviewer` 评审设计质量。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、技术方案、生产代码变更、编码决策，以及项目和所属模块的测试约束。加载 `workflow-discipline`，调用独立 `test-reviewer` 评审测试设计。\n\n读取现有测试目录、配置和相关用例，确认测试框架、命名、替身边界、覆盖要求及与其他测试层级的分工。信息缺失时先从仓库现状推导；仍无法确定关键行为或测试边界时，说明缺失信息并暂停。\n\n## 执行流程\n\n1. 从需求、技术方案和生产代码整理本次需要验证的行为单元，明确输入、输出、状态变化、错误和副作用。\n2. 为每个行为单元设计正常、边界和失败场景，并按实际行为补充状态恢复、幂等、重试、权限、并发或资源生命周期场景；不适用项无需制造用例。\n3. 为每个用例写明优先级、前置条件、输入、替身或数据准备、操作、观察点、预期结果及覆盖的行为或分支，使后续实现者无需猜测测试意图。\n4. 明确哪些依赖使用真实实现、替身或受控环境，避免过度 Mock 掩盖业务行为，也避免把跨系统路径误当单元测试。\n5. 逐项核对现有测试。标记为复用时，指出具体用例及其已覆盖的本次行为；需要调整或新增时明确差异，不用「已有覆盖」笼统跳过。\n6. 形成最终测试设计，包含范围与策略、行为单元、逐项用例、覆盖目标、测试层级边界、风险和不适用说明，以及需求→用例映射表（每条验收标准对应至少一个用例 ID）；不得包含可执行测试函数、断言代码或完整 fixture。\n7. 将测试设计连同映射表交给 `test-reviewer`，不提供设计者结论或预期结果。委派材料按「契约 + 路标 + 已验锚点」组装：项目测试约束以节选直接置入委派 prompt；需求、生产代码、现有测试给路径路标；非首轮重审随附上轮已验锚点清单。\n8. 修复 BLOCKER、HIGH Findings 后重新评审：reviewer 只重验本轮修订触及的条目与受影响锚点，未触及项沿用上轮结论，但每轮报告保持全量 Findings 快照——已解决的标记关闭，不允许静默丢弃，是否处理由主会话决策；评审至多 3 轮，第 3 轮仍未 PASS 时保留在当前节点并请用户裁定，附双方分歧清单。MEDIUM、LOW 逐项处理或记录保留理由。Findings 处理记录写入节点记录，禁止回写被评审文档——测试设计文档只保留设计本体。\n\n## 产出与检查\n\n推进前确认：\n\n- 生产变更与被测行为已逐项对应；\n- 每个行为单元都有明确场景、观察点和预期结果；\n- 需求→用例映射表完整，每条验收标准至少对应一个用例；\n- 关键边界、失败路径和副作用已覆盖，不适用项已有理由；\n- 替身、数据准备和测试层级边界合理；\n- 现有测试的复用、调整与新增判断均有具体依据；\n- 最终设计不包含可执行测试代码，也不包含评审处理记录；\n- `test-reviewer` 最终结论为 PASS（或按 3 轮上界经用户裁定通过），所有 Findings 均已处理或说明；\n- 测试设计已形成完整产物，登记值携带全文（超限时为路径引用且已说明理由）。\n\n## 任务差异处理\n\n根据被测行为选择覆盖维度，不机械套用固定方法或为不适用场景制造用例。纯文档、配置或其他不存在可单元验证行为的变更，应说明判断依据和后续适用的验证层级，不得静默产出空设计。测试设计文档超过约 400 行时先按行为单元拆分再送审。评审修订与执行障碍按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将测试设计结论、范围、覆盖维度、现有测试复用判断、测试层级边界、风险与不适用项、设计产物（登记携带全文，超限时为路径引用且已说明理由）、`test-reviewer` 结论与各轮 Findings 处理记录写入当前节点记录——处理记录只进节点记录，被评审文档保持设计本体。完成上述检查后推进下一节点。",
|
|
163
163
|
"skills": [
|
|
164
164
|
"workflow-discipline"
|
|
165
165
|
],
|
|
@@ -168,8 +168,8 @@
|
|
|
168
168
|
],
|
|
169
169
|
"sourcePreset": {
|
|
170
170
|
"code": "test-unit-design",
|
|
171
|
-
"version": "1.
|
|
172
|
-
"contentHash": "
|
|
171
|
+
"version": "1.5.0",
|
|
172
|
+
"contentHash": "d030a84ed2273c99",
|
|
173
173
|
"agents": [
|
|
174
174
|
"test-reviewer"
|
|
175
175
|
]
|
|
@@ -204,7 +204,7 @@
|
|
|
204
204
|
"label": "端到端测试设计",
|
|
205
205
|
"phase": "test",
|
|
206
206
|
"track": "backend",
|
|
207
|
-
"prompt": "# 端到端测试设计\n\n## 节点职责\n\n判断项目是否存在适用的端到端测试体系；适用时为本次变更设计跨真实系统边界的可执行场景，不适用时记录依据。本节点只产出测试设计，不编写或执行测试代码，并通过独立 `test-reviewer` 评审设计质量。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、技术方案、生产代码与单元测试变更、前序决策，以及项目和所属模块的测试约束。加载 `workflow-discipline`，调用独立 `test-reviewer` 评审测试设计或不适用判断。\n\n读取项目提示词、测试说明、E2E 目录、配置、执行入口和现有用例，确认项目是否定义了 E2E 对象、边界、框架、环境和数据规则。缺少信息时先从仓库现状补齐，不凭通用惯例新建测试体系。\n\n## 执行流程\n\n1. 记录已检索的项目声明、目录、配置和现有用例，判断项目是否存在可用的 E2E 体系。\n2. 项目未定义 E2E 时，说明检索范围、判断依据及不引入新体系的结论，形成 N/A 产物后进入独立评审。\n3. 项目已定义 E2E 时，从需求和变更中识别必须跨真实边界验证的用户或系统路径，结合风险、现有覆盖和低层测试确定纳入与排除范围。\n4. 为每个场景写明标识、目标、优先级、前置条件、步骤、观察点、预期结果、数据准备、隔离和清理要求。场景应验证最终可观察结果，不只验证请求成功或调用发生。\n5.
|
|
207
|
+
"prompt": "# 端到端测试设计\n\n## 节点职责\n\n判断项目是否存在适用的端到端测试体系；适用时为本次变更设计跨真实系统边界的可执行场景，不适用时记录依据。本节点只产出测试设计，不编写或执行测试代码，并通过独立 `test-reviewer` 评审设计质量。\n\n## 依赖信息\n\n先检查当前任务上下文，读取需求、验收标准、非目标、技术方案、生产代码与单元测试变更、前序决策，以及项目和所属模块的测试约束。加载 `workflow-discipline`，调用独立 `test-reviewer` 评审测试设计或不适用判断。\n\n读取项目提示词、测试说明、E2E 目录、配置、执行入口和现有用例，确认项目是否定义了 E2E 对象、边界、框架、环境和数据规则。缺少信息时先从仓库现状补齐，不凭通用惯例新建测试体系。\n\n## 执行流程\n\n1. 记录已检索的项目声明、目录、配置和现有用例，判断项目是否存在可用的 E2E 体系。\n2. 项目未定义 E2E 时，说明检索范围、判断依据及不引入新体系的结论，形成 N/A 产物后进入独立评审。\n3. 项目已定义 E2E 时，从需求和变更中识别必须跨真实边界验证的用户或系统路径，结合风险、现有覆盖和低层测试确定纳入与排除范围。\n4. 为每个场景写明标识、目标、优先级、前置条件、步骤、观察点、预期结果、数据准备、隔离和清理要求。场景应验证最终可观察结果，不只验证请求成功或调用发生。\n5. 覆盖正常、失败、权限、恢复、状态或兼容场景中的适用部分，并说明哪些行为已由单元或其他测试层级可靠覆盖，避免重复和遗漏；形成跨边界行为→场景映射表（每条须跨边界验证的行为对应至少一个场景 ID）。\n6. 形成最终设计，不包含测试函数、可执行 fixture、请求代码或浏览器操作代码。\n7. 将测试设计连同映射表交给 `test-reviewer`，不提供设计者结论或预期结果。委派材料按「契约 + 路标 + 已验锚点」组装：项目 E2E 约束以节选直接置入委派 prompt；需求、生产变更、现有用例给路径路标；非首轮重审随附上轮已验锚点清单。N/A 判断评审时提供检索范围与证据路标。\n8. 适用时修复 BLOCKER、HIGH Findings 后重新评审：reviewer 只重验本轮修订触及的条目与受影响锚点，未触及项沿用上轮结论，但每轮报告保持全量 Findings 快照——已解决的标记关闭，不允许静默丢弃，是否处理由主会话决策；评审至多 3 轮，第 3 轮仍未 PASS 时保留在当前节点并请用户裁定，附双方分歧清单。MEDIUM、LOW 逐项处理或记录保留理由。Findings 处理记录写入节点记录，禁止回写被评审文档——测试设计文档只保留设计本体。\n\n## 产出与检查\n\n推进前确认：\n\n- 项目 E2E 体系的适用性已有仓库证据；\n- N/A 时已记录检索范围和判断依据，未擅自新建框架、目录或入口；\n- 适用时，覆盖范围与本次跨边界行为逐项对应，纳入和排除均有理由；跨边界行为→场景映射表完整；\n- 每个场景的前置条件、步骤、观察点、预期结果和数据清理可供后续实现；\n- 与其他测试层级的边界明确，设计不含可执行测试代码，也不含评审处理记录；\n- `test-reviewer` 最终结论为 PASS（或按 3 轮上界经用户裁定通过），所有 Findings 均已处理或说明；\n- E2E 设计或 N/A 结论已形成完整产物，登记值携带全文（超限时为路径引用且已说明理由）。\n\n## 任务差异处理\n\n不默认逐接口覆盖，也不默认只测关键旅程；根据项目现有 E2E 体系、需求风险和低层覆盖确定范围。项目未定义 E2E 时不把本节点变成测试基础设施建设；若任务明确要求新建 E2E 体系，应将其作为范围与技术决策单独确认。E2E 设计文档超过约 400 行时先按场景分组拆分再送审。执行障碍和评审修订按 `workflow-discipline` 处理。\n\n## 节点记录与推进\n\n将 E2E 适用性、检索范围与依据、覆盖范围、场景设计、测试层级边界、数据与清理策略、不适用项及理由、设计产物（登记携带全文，超限时为路径引用且已说明理由）、`test-reviewer` 结论与各轮 Findings 处理记录写入当前节点记录——处理记录只进节点记录，被评审文档保持设计本体。完成上述检查后推进下一节点。",
|
|
208
208
|
"skills": [
|
|
209
209
|
"workflow-discipline"
|
|
210
210
|
],
|
|
@@ -213,8 +213,8 @@
|
|
|
213
213
|
],
|
|
214
214
|
"sourcePreset": {
|
|
215
215
|
"code": "test-e2e-design",
|
|
216
|
-
"version": "1.
|
|
217
|
-
"contentHash": "
|
|
216
|
+
"version": "1.5.0",
|
|
217
|
+
"contentHash": "f1d0e86615f305a3",
|
|
218
218
|
"agents": [
|
|
219
219
|
"test-reviewer"
|
|
220
220
|
]
|
|
@@ -457,7 +457,7 @@
|
|
|
457
457
|
}
|
|
458
458
|
},
|
|
459
459
|
"isDefault": false,
|
|
460
|
-
"version": "3.5.
|
|
460
|
+
"version": "3.5.1"
|
|
461
461
|
},
|
|
462
462
|
"dependencies": {
|
|
463
463
|
"skills": [
|