@antprofuse/saddle-islands-workflow 0.1.5 → 0.1.7
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/SKILL.md +4 -0
- package/package.json +1 -1
- package/references/task-planning-review.md +12 -0
package/SKILL.md
CHANGED
|
@@ -46,6 +46,8 @@ Skill与工具分别冻结仓库、完整commit、版本、制品和文件摘要
|
|
|
46
46
|
|
|
47
47
|
## 执行和反馈
|
|
48
48
|
|
|
49
|
+
测试研发交付可用的覆盖定义与测试接入,以编译、静态及设施控制为主,验证不依赖产品制品或小程序模拟器;必要的轻量执行只验证测试设施;当前产品失败不阻止有效测试交付。产品研发负责实际业务运行、失败分析、实现和复验,不能把测试阶段存在或产品制品可用等同必须提前全量验收。除用户明确指定外,不把全量业务运行当作语法或基本接入检查。
|
|
50
|
+
|
|
49
51
|
测试按独立责任批次并行,同一产品代码单元保持一个研发写入者。产品研发自主消费测试、定位、实现和复验;Owner协调目标和共因,不逐行指定产品修法。
|
|
50
52
|
|
|
51
53
|
每轮产品迭代评估本批全部未通过项,处理可独立推进部分后交付完整增量。局部测试问题退原测试负责人审查整批同因,不自动退整批;跨批公共缺陷交唯一工具维护者,仅暂停受影响集合。测试交付不替代产品结果,真实回退不能为数字单调而隐藏。
|
|
@@ -62,6 +64,8 @@ Skill与工具分别冻结仓库、完整commit、版本、制品和文件摘要
|
|
|
62
64
|
|
|
63
65
|
## 迭代范围与无变更交付
|
|
64
66
|
|
|
67
|
+
检查范围与检查方式分开决定:测试研发根据业务迭代自主选择全量或增量的目录遍历、定义审查、编译及静态检查,全量静态检查不等于全量业务运行。本阶段不以真实产品业务执行作为覆盖建设的默认步骤;必要的轻量验证使用不依赖产品制品的设施自检。产品研发负责真实业务测试执行与修复。
|
|
68
|
+
|
|
65
69
|
阶段适用于新业务研发、已有业务的小范围变更和无业务变化的复核。按本轮目标与输入差异决定工作量;节点存在不等于必须修改代码、重建设计或重写测试,也不自动要求全量验证。优先复用仍有效成果和证据,对变更及其影响范围研发、验证。判定无需修改时交付依据、对应版本及必要检查结果,不能仅凭文件已存在认定完成;用户明确要求完整复核或全量测试时按该范围执行。无Git变更仍执行阶段交付门禁,基线与候选可以相同。
|
|
66
70
|
|
|
67
71
|
## 发起者持久管理
|
package/package.json
CHANGED
|
@@ -13,6 +13,18 @@
|
|
|
13
13
|
- 给执行者实际可访问的规则和工具,不把Owner已读过/Skill源码已改当成成员已获得。工程Skill按已推送Git原包传播并核实际内容;Owner规划规则不必整篇复制给执行者,本轮特有交付目标写入任务,通用交付要求由Skill承载。
|
|
14
14
|
- 任务应有范围内修复权限,普通测试红灯分清产品或设施责任,不因为一次失败就阻塞或新增节点。真正源冲突与缺少不可替代输入才升级。
|
|
15
15
|
|
|
16
|
+
## MT交付的全量编译基线
|
|
17
|
+
|
|
18
|
+
MT可自主决定研发及深入审查的增量范围,但成功交付必须满足当前活动case全量编译通过。Owner检查点核对编译集合、候选提交及工具身份,不能用真实业务运行代替编译门禁,也不能将测试编译通过解释为产品通过。编译设施缺口由公共工具维护者修复;测试定义错误退MT处理。
|
|
19
|
+
|
|
20
|
+
## 阶段环境准备闭包
|
|
21
|
+
|
|
22
|
+
Owner按阶段实际需要区分公共工具、测试编译器、模拟器或运行时、产品工程依赖;一个入口可用不能证明其他入口就绪。产品工程依赖从指定工作分支的清单、锁文件及安装配置准备,不能以测试编译器的依赖目录替代产品依赖,也不能为解决缺包擅自升级锁定版本。
|
|
23
|
+
|
|
24
|
+
放行产品阶段前,核查其工程命令所需的可执行入口和模块解析是否可用,记录依赖来源摘要、准备目录及实际消费方式。使用不执行产品业务的入口检查,不以完整构建或全量业务测试充当依赖预检。工具允许独立依赖目录时分别交接,不覆盖共享真源;工程命令仍从产品工作目录执行。
|
|
25
|
+
|
|
26
|
+
准备缺口由Owner统一补齐并更新版本化阶段环境,消费者只报告缺口;准备就绪不代表工程检查或业务测试已经通过,后者仍由产品阶段执行。此检查不成为测试研发依赖产品或模拟器的前置。
|
|
27
|
+
|
|
16
28
|
## 新任务继承公共能力,而非依赖旧Agent记忆
|
|
17
29
|
|
|
18
30
|
Owner先消化上游输入的不确定性:核定源版本,完成必要的编译、协议或目录生成及异常归因,准备实际可取的研发分支和生成物。首个设计阶段也基于明确分支与既定设计范围执行,不承担上游可用性探索。阶段内正常设计与实现判断仍归对应角色。正式交付物进入指定Git分支,运行证据、问题反馈和复盘进入指定共享目录。
|