@antprofuse/saddle-islands-workflow 0.0.0-stage → 0.1.1
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 +55 -0
- package/package.json +18 -4
- package/references/case-coverage.md +69 -0
- package/references/changes.md +43 -0
- package/references/ownership.md +30 -0
- package/references/task-planning-review.md +164 -0
- package/references/task-retrospective.md +13 -0
- package/README.md +0 -3
package/SKILL.md
ADDED
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: saddle-islands-workflow
|
|
3
|
+
description: 协调Islands正式输入、工程设计、独立测试和小程序端与后端研发,确定范围、职责、依赖、公共工具消费和增量交付。用于新业务、已有业务变更及技术改造;不替代上游业务语义、产品实现或生产发布决策。
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Saddle–Islands Workflow
|
|
7
|
+
|
|
8
|
+
本Skill拥有跨阶段协同规则,不拥有业务答案。阶段执行者读取本轮冻结的对应Skill与实际公共工具说明,不能凭旧会话推断输入或能力。
|
|
9
|
+
|
|
10
|
+
## 规划与路由
|
|
11
|
+
|
|
12
|
+
每次新迭代、新协同任务或实质改变目标、职责、输入、依赖、验收方式前,重新读取本正文及[任务规划规则](references/task-planning-review.md)。跨轮恢复后准备重新规划或处理集中偏差时同样重读;普通进度查询无需机械重复。
|
|
13
|
+
|
|
14
|
+
阶段按职责、权威输入、交付结果、公开工具和交接条件划分,不按Agent数量划分。同一Agent承担多个阶段或多个Agent分别执行时,工作策略与验收标准一致。单Agent切换阶段也需读取对应Skill、核输入并保留交付依据,不以会话记忆省略交接,不因兼任而混淆测试期望与产品实现。阶段不必各建节点,按真实依赖决定并行与串行。
|
|
15
|
+
|
|
16
|
+
先落实用户允许的仓库、目录、版本和交付目标。按[职责边界](references/ownership.md)建立来源变化到设计、测试和实现的影响关系,不因近期只处理某层而缩小完整迭代范围。
|
|
17
|
+
|
|
18
|
+
| 工作 | 使用的角色或权威输入 |
|
|
19
|
+
|---|---|
|
|
20
|
+
| Spec、视觉、physical与上游协议生成 | 当前Islands正式指南与公开工具 |
|
|
21
|
+
| 小程序端与后端契约、必要数据库设计 | saddle-islands-design |
|
|
22
|
+
| 小程序端独立测试建设 | saddle-islands-minifish-test |
|
|
23
|
+
| 后端独立测试建设 | saddle-islands-backend-test |
|
|
24
|
+
| 小程序端产品研发 | saddle-islands-minifish |
|
|
25
|
+
| 后端产品研发 | saddle-islands-backend,另消费目标版本Saddle框架Skill |
|
|
26
|
+
|
|
27
|
+
当前小程序角色只适用于Minifish,它是前端的一类,不代表所有前端。其他前端平台需选择其独立的研发、测试与接入能力,不能套用小程序宿主规则;尚无对应能力时明确缺口。
|
|
28
|
+
|
|
29
|
+
正式physical绑定和上游生成协议作为输入消费,不默认恢复独立adapt或人工外部协议设计阶段。真实语义缺口回报责任方,不向执行者下放未知设计或要求试到能跑。
|
|
30
|
+
|
|
31
|
+
任务节点只声明明确输入及版本、所用Skill与阶段、范围和Git分支或共享目录交付目标。通用执行、门禁、复盘和交付细则由Skill与工具说明承载,不在节点重复维护;上游产物的精确提交由检查点确认后交接。
|
|
32
|
+
|
|
33
|
+
## 工具与规则消费
|
|
34
|
+
|
|
35
|
+
通用工具来自独立工具集,使用其公开入口;本Skill及其他角色Skill不包含执行、观察、断言和报告实现。Owner交接实际可取得的工具包及公开说明、适用输入及输出,不重新规定已经工具化的内部细节。缺失能力由公共维护者修复,不让消费者另写同功能脚本。
|
|
36
|
+
|
|
37
|
+
Skill与工具分别冻结仓库、完整commit、版本、制品和文件摘要,并核兼容关系。使用已提交推送且可验证的Git分发包;npm可以作为备份,不要求等待中心传播。独立Skill包含所需的使用规范与参考,公共命令和接口说明随独立工具提供;不要求使用者阅读体系研发docs。不能只拷正文或用版本号相同冒充内容一致。
|
|
38
|
+
|
|
39
|
+
外部框架保持权威来源和目标版本,不因本体系升级自动升级业务运行时。活动批次不静默换输入,在安全点接入变更。
|
|
40
|
+
|
|
41
|
+
## 执行和反馈
|
|
42
|
+
|
|
43
|
+
测试按独立责任批次并行,同一产品代码单元保持一个研发写入者。产品研发自主消费测试、定位、实现和复验;Owner协调目标和共因,不逐行指定产品修法。
|
|
44
|
+
|
|
45
|
+
每轮产品迭代评估本批全部未通过项,处理可独立推进部分后交付完整增量。局部测试问题退原测试负责人审查整批同因,不自动退整批;跨批公共缺陷交唯一工具维护者,仅暂停受影响集合。测试交付不替代产品结果,真实回退不能为数字单调而隐藏。
|
|
46
|
+
|
|
47
|
+
用户状态与数字按约定粒度、真实执行状态和产品交付证据更新,不把问题存在称为有人正在研发。后端覆盖方法见[固定边界覆盖规范](references/case-coverage.md),不将其组合方法用于改造Islands小程序端目录。
|
|
48
|
+
|
|
49
|
+
## 决策与收尾
|
|
50
|
+
|
|
51
|
+
按[变更规则](references/changes.md)明确唯一归属和受影响消费者。通用规范进本体系,业务事实与测试回归留业务项目,日志和报告留项目运行区。所有提交、推送、发布遵守对应仓库当前授权,不把本库master研发方式强加业务仓。
|
|
52
|
+
|
|
53
|
+
节点按[简短复盘格式](references/task-retrospective.md)反馈输入、耗时、返工及改进依据。Owner核关键路径及自身规划责任,修正有证据的通用缺口,验证新成员能够消费;不能只通知旧成员或追加口号。
|
|
54
|
+
|
|
55
|
+
完成时区分设计、设施、Mock验收、真实联调和生产发布。持久保存必要且唯一的交付证据,清理失效入口;不重复归档缓存、不默认生成下载包,不以编译或数量替代业务正确性。
|
package/package.json
CHANGED
|
@@ -1,6 +1,20 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@antprofuse/saddle-islands-workflow",
|
|
3
|
-
"version": "0.
|
|
4
|
-
"
|
|
5
|
-
"
|
|
6
|
-
|
|
3
|
+
"version": "0.1.1",
|
|
4
|
+
"description": "协调Islands输入、工程设计、独立测试与产品研发,明确职责、公共工具消费及增量交付。",
|
|
5
|
+
"license": "MIT OR Apache-2.0",
|
|
6
|
+
"files": [
|
|
7
|
+
"SKILL.md",
|
|
8
|
+
"references",
|
|
9
|
+
"resources"
|
|
10
|
+
],
|
|
11
|
+
"publishConfig": {
|
|
12
|
+
"access": "public",
|
|
13
|
+
"registry": "https://registry.npmjs.org/"
|
|
14
|
+
},
|
|
15
|
+
"repository": {
|
|
16
|
+
"type": "git",
|
|
17
|
+
"url": "git+ssh://git@code.alipay.com/profuse/saddle-islands.git",
|
|
18
|
+
"directory": "skills/workflow"
|
|
19
|
+
}
|
|
20
|
+
}
|
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
# 固定边界 case 与有效覆盖
|
|
2
|
+
|
|
3
|
+
本文件以下归一化、组合选取、case 拆合与身份规则适用于后端测试。小程序测试必须改读 `saddle-islands-minifish-test` 的 `references/islands-miniapp-case-tree.md`,不把以下规则用于重新设计 Islands 小程序端目录。测试阶段先冻结源责任基线与覆盖范围,再按确定的分区逐批物化完整case、编写、复用和执行测试;API 设计不承担 coverage。业务依据限当前 Spec、Prototype、公开平台合同及明确批准的工程约定,不能用产品现状补需求。
|
|
4
|
+
|
|
5
|
+
## 被测对象决定边界
|
|
6
|
+
|
|
7
|
+
先声明被测对象、直接输入/输出和拥有的逻辑。小程序端边界包括页面入参、前置页面状态、宿主环境/事件,以及小程序端直接调用的后端或外部接口的请求、返回、失败和相关时序。后端接口背后的SQL、gRPC、分支或外部服务内部过程均在小程序端边界外;这些过程变化若未改变小程序端边界,不增加小程序端 case。
|
|
8
|
+
|
|
9
|
+
后端以自身公开入口、可信上下文和直接依赖的请求/返回、数据库状态/副作用为边界,不展开被依赖服务内部实现。两层的分母独立,从共同源责任分别投影,不按后端路径数乘出小程序端 case 数。
|
|
10
|
+
|
|
11
|
+
归一化前先将来源世界投影到被测对象边界。边界外差异产生相同的本层输入、答复、事件及相关时序时,合并本层 case,并保留多个来源关联。边界内不同值也可按有据的分支等价类选代表,但不能只因预期最终画面相同就合并:不同的本层处理、请求、失败或等待行为仍需独立覆盖。扩展数量以本层程序的分支和行为差异为依据。
|
|
12
|
+
|
|
13
|
+
## Case 的单位
|
|
14
|
+
|
|
15
|
+
一个 case 是一次触发后连续程序行为,在所有影响被测对象本次分支的边界条件下的一种确定情况。定义中固定:正式来源起点、触发输入、前置状态、外部预期请求及返回/失败、相关宿主环境、影响结果的时序,以及结束条件。未知或遗漏的边界不得隐含为成功。
|
|
16
|
+
|
|
17
|
+
一般以人为中断结束本次 case;下次用户操作或回调是新起点。例如页面打开并自动查询直到等待用户、点击支付直到交给收银台等待用户、收到支付结果后的自动处理分别成 case。普通自动 RPC 不因此拆开。小程序端以公开页面/宿主事件触发,后端以公开接口请求触发并保留页面起点归属;两层分别定义边界,不强求 case 数相同。
|
|
18
|
+
|
|
19
|
+
局部确定序列是例外:一系列动作仅影响同一局部状态,固定边界下没有条件分叉、没有新的独立业务选择时,可以在一个 case 内连续操作并充分断言,不按点击数量强制拆分。例如同一公告的展开、收起可合验;进入收银台等待用户选择仍拆分。记录合并依据和每步预期;若后续变更新增分支或边界,则重新拆分。不能用这个例外合并跨业务阶段或不同边界组合。
|
|
20
|
+
|
|
21
|
+
前置准备可复用先前操作,但必须与被验收的触发区分;除上述局部确定序列外,不把多个独立用户动作串成一个 case。迟到响应可以来自前序准备,当前 case 固定其交付时序并检查当前行为。参数化每一种不同边界组合分别列举;一份运行文件或循环不是一个 case 的依据。
|
|
22
|
+
|
|
23
|
+
## 先定分母和选取理由
|
|
24
|
+
|
|
25
|
+
1. 从当前正式输入取得起点、条件、分支、结果、元素和副作用义务;保留来源身份与原文坐标。编译工具 TODO 或不能投影首先是工具/分析缺口,不直接认定 Spec 缺失。
|
|
26
|
+
2. 列出边界等价类、相关性与可达约束。值可合并为同一类,必须说明为何不改变被测规则;边界值仍单列。排除不可达组合要有依据。
|
|
27
|
+
3. 每条正式分支及正常、失败、空、等待等已有语义都要有见证。复合判断验证条件的独立影响;无法独立影响时记录约束,验证优先级、互斥、遮蔽及回退。不能用分支命中替代这些组合责任。
|
|
28
|
+
4. 对共享状态、数据依赖、因果顺序及竞争时序建立联合 case,包含前序失败禁止后续调用等反例。独立区域不机械做全局笛卡尔积,也不能仅声称独立:记录依赖分析与组合削减理由。pairwise、单因素或 MC/DC 都不能单独证明整个业务覆盖完整;存在多条件共同作用时补相应联合组合。
|
|
29
|
+
5. 物化完整 case 清单、边界预期和归一化描述后去重,交付确定数量、待明确数量及复用/新增/退役明细。源目录、ASSERT、脚本和已通过数量不能替代 case 分母。策略由测试设计负责,不把专业组合选择推给用户。
|
|
30
|
+
|
|
31
|
+
归一化描述保留源起点和边界含义,排除断言排列、报告路径等非语义差异。只有证明边界语义等价才合并;新增断言不新建 case,边界组合变化须重新核定身份。沿项目统一身份工具生成标识,不自行发明另一套摘要算法;尚无 case 身份实现时显式保留规范原文与唯一性检查,不能冒称自动身份机制已经完成。
|
|
32
|
+
|
|
33
|
+
## 覆盖公式与有效性
|
|
34
|
+
|
|
35
|
+
维护单一关联:来源义务 → case → 具体断言 → 可检测的错误 → 执行证据。至少分别报告:
|
|
36
|
+
|
|
37
|
+
- case 执行覆盖 = 实际执行 case 数 / 已确定的适用 case 数。
|
|
38
|
+
- case 通过率 = 通过 case 数 / 已确定的适用 case 数。
|
|
39
|
+
- 义务验证覆盖 = 本次已执行且通过有效断言的义务数 / 本层适用来源义务数。
|
|
40
|
+
|
|
41
|
+
分母附具体清单与排除依据;未确定、未映射、未运行、失败与不适用分别呈现,不从报告中删除以制造全覆盖。一个 case 可以验证多项义务,一项义务也可能需要多个 case;需多个见证的义务必须全部满足才记已验证。
|
|
42
|
+
|
|
43
|
+
在固定 case 内充分断言请求身份/参数/次数、返回消费、状态、内容、数量、显隐、适用样式/图片加载、禁止调用及副作用。只选择源中适用的义务,不机械添加无依据约束。关键共享断言和每个漏测回归须有针对性负对照,证明错误会被拒绝;前序失败时后续断言不记执行。数量或全绿都不能证明绝对无缺陷。
|
|
44
|
+
|
|
45
|
+
## 独立分工与持续迭代
|
|
46
|
+
|
|
47
|
+
一个完整 case 的编写和修复只归属一个执行节点;节点可批量负责多个完整 case。禁止把同一 case 按视觉、内容、请求或单个 ASSERT 分给不同成员。独立审查不改变编写归属。公共设施单一维护后供各 case 使用;Owner 在检查点处理分支与交接,不让整合节点补全拼接的半成品 case。
|
|
48
|
+
|
|
49
|
+
并行按独立 case 集合、预计耗时与共享设施依赖规划,目标是缩短关键路径,不能用节点数量衡量效率。先明确源责任范围、分区判定与所有权,再在各区物化完整case并编写。已有正式测试输入时先满足本轮适用基线,不把额外全组合研究或全局case数量审批作为全部执行的前置。
|
|
50
|
+
|
|
51
|
+
下一迭代按来源、边界、契约和设施差异分析影响。未变化 case 可以复用,经核对补断言而不重建;受影响部分重审并运行,新来源补分母,失效 case 记录退役原因。历史运行证据不自动证明新制品通过。漏测记录来源、漏掉的边界/断言、最小反例、修复证据与同类影响,项目具体回归留测试目录,通用规则在本规范及所属测试参考中持续归并。
|
|
52
|
+
|
|
53
|
+
## 可判定的分工与责任满足
|
|
54
|
+
|
|
55
|
+
分区依据是完整case的固定边界,不是自然语言标题或产品实际输出。交付可执行判定器或等价的确定性规则:对每个合法边界恰有一个分区成立,非法或未确定输入明确拒绝;用交集检查和遗漏检查核验,不能只测试几个正例。分区归属正确不证明覆盖完整。
|
|
56
|
+
|
|
57
|
+
每条源责任保留稳定源ID、适用边界条件、必须验证的预期,以及case/具体断言/执行证据。涉及多个见证时显式列出全部要求。公共检查器应拒绝重复归属、悬空引用、未登记责任和前序失败后仍标通过;文件行存在只能证明引用有效,不能证明断言语义充分。不能机器证明的转换明确待审,并保留原责任,不由执行者自行删除或计为满足。
|
|
58
|
+
|
|
59
|
+
## 终态预期与阻塞归因
|
|
60
|
+
|
|
61
|
+
原型可能同时保存多个分支。以固定边界→状态变化或分支选择→预期终态→断言推导预期;静态HTML当前hidden、空节点或分支名字均不能单独证明该case终态。也不能按产品截图反推预期。判断源冲突之前,核对场景准备、转换合同、生成描述及运行时观察语义;证据不完整时记录待核,不提前要求上游修复。
|
|
62
|
+
|
|
63
|
+
测试建设、设施验证、产品验收分阶段报告。已知产品红灯不阻塞仍可编写的独立case,也不允许降低断言。只影响部分责任的观测或环境缺口单列具体范围,其余继续;修复或新证据出现前不反复运行同一失败。无法证明的内部任务状态不能用直接RPC完成冒充,也不能未经依据要求产品新增内部观察API。
|
|
64
|
+
|
|
65
|
+
## 经验进入下一轮的条件
|
|
66
|
+
|
|
67
|
+
执行中在首批可读产物、阶段变化或阻塞处抽查实际边界、代码与源映射,不仅等待最终报告。发现偏差只调整必要范围,保留有效成果,遵守活动任务输入变更协议。
|
|
68
|
+
|
|
69
|
+
问题登记至少含来源证据、事实/推论、影响责任、最终决策、实施和复验状态、下一轮预防检查。纠正旧结论时标明被替代依据;未核实推论不得变成通用规则。项目事实和回归留项目交付/报告,已确认且可复用的决策进入规则所属Skill。下一轮先核未闭环项及预防检查,再按新输入判断是否适用,不能机械继承旧业务结论。记录或解除阻塞不代表缺陷已关闭。
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
# 决策和变更闭环
|
|
2
|
+
|
|
3
|
+
## 决策记录最小内容
|
|
4
|
+
|
|
5
|
+
在用户指定协作位置记录,而非塞进 code 交付目录:
|
|
6
|
+
|
|
7
|
+
- 决策身份/主题、已确认内容、依据与待确认内容。
|
|
8
|
+
- 唯一规则所有者及对应 Skill/reference。
|
|
9
|
+
- 消费者 Skill 和具体产物范围;不受影响者可给出理由,不盲目全改。
|
|
10
|
+
- 变更前后差异、兼容性和授权范围。
|
|
11
|
+
- 静态/设施/业务黑盒/真实联调各自的验证及未完成项。
|
|
12
|
+
|
|
13
|
+
历史决策不删除;取代关系明确,不让两个现行规则并存。未批准提案不能当实现输入;发生冲突时返回最早拥有该语义的阶段。
|
|
14
|
+
|
|
15
|
+
## 示例:一个外部结果增加已确认字段
|
|
16
|
+
|
|
17
|
+
上游正式输入确定字段语义与获得方式,并由官方工具生成外部协议 → design 调整必要的后端结果契约 → 后端测试补外呼返回、投影断言 → backend 消费。上游外部实现和接入由其责任方维护,不在下游另造同一适配层。若页面不消费,则小程序端契约/测试不必为了“全链路更新”加字段。
|
|
18
|
+
|
|
19
|
+
## 示例:契约标识或命名规则改变
|
|
20
|
+
|
|
21
|
+
workflow 维护命名规则 → design 校验/分配身份 → minifish 唯一请求入口和 backend 唯一注册入口同步 → 两类测试及覆盖关联更新。是否改变 wire 必须单独判断,不能把文件重命名等同兼容,也不能把纯文件迁移宣称为新业务。运行时无冲突无需改 Saddle。
|
|
22
|
+
|
|
23
|
+
## 示例:测试库启动失败
|
|
24
|
+
|
|
25
|
+
backend-test 负责公开配置、DDL、映射及实例校验;backend 提供真实制品。按证据区分设施、产品和框架问题,不修改业务查询来迎合测试。框架问题提交具体公开入口复现,由 Saddle 维护;不将测试环境的一个数值固定到通用业务设计。
|
|
26
|
+
|
|
27
|
+
## 跨 Skill 冲突与上线顺序
|
|
28
|
+
|
|
29
|
+
先修改规则所有者,再更新实际受影响消费者;校验引用、示例、模板和检查器的一致性。不为消除冲突擅自改变业务输入。
|
|
30
|
+
|
|
31
|
+
工程Skill按已提交推送的原始包传播,记录各包Git提交、完整文件及摘要,同一批次冻结。先核依赖包和消费者内容一致,再通知可消费;npm发布作为备份,不以registry传播或安装作为可用性门槛。已分发Git包不得冒称npm已发布。版本相同但内容不同仍视为交接差异;发现冲突修正确定的受影响包,不偷偷回退或使用未提交草稿。
|
|
32
|
+
|
|
33
|
+
Skill 发布不自动升级现有业务交付;业务迁移仍需独立范围、diff 和验收。提交权限不等于 push 权限,push 权限不等于 npm 发布权限。
|
|
34
|
+
|
|
35
|
+
## 测试通过却漏出缺陷
|
|
36
|
+
|
|
37
|
+
1. 记录用户实际看到的错误、影响范围与当前输入依据。先倒查测试是否表达了正确预期、是否有足够断言、是否实际执行到目标边界,再判断测试输入本身是否缺失或冲突。不要仅因代码有错就跳过测试层复盘。
|
|
38
|
+
2. 输入清晰:测试建设先修错误预期/遗漏责任,建立能检出缺陷的回归和设施反例,再让研发修复并完成自己的全量相关自测。输入歧义:返回语义所有者确认,明确受影响边界,独立工作继续。普通 TDD 红灯且预期正确时,研发内部修复即可,不为每次失败启动跨节点大循环。
|
|
39
|
+
3. 独立验收同时检查断言依据与真实执行结果;核对整体组合边界,不能把各层单独通过相加当作整体正确。确认新增回归能拒绝已知错误且不拒绝合法替代。
|
|
40
|
+
4. 闭环记录:缺陷及来源、漏测机制、测试/产品/输入各自变更、正反例与实际运行证据、剩余限制、规则所有者与消费者。已知错误尚不能被自动检测时,不把“已看截图”标成闭环。
|
|
41
|
+
5. 提炼时先区分项目事实、测试工具修复、可复用方法、跨阶段职责。项目事实进项目回归;通用方法进所属 Skill 的单一参考;消费者只增加必要交接义务。检查同类规则,合并重复、注明替代关系;本次只影响少数 Skill 时不机械全改。
|
|
42
|
+
|
|
43
|
+
迭代开始读取与本轮范围有关的未闭环问题,交付时核对新发现是否已进入回归或明确待办。持续积累不等于宣称测试穷尽;记录具体适用范围,不引入无来源的业务要求、发布权限或技术限制。Skill 静态校验与示例审阅不等于真实业务回归通过。
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# 阶段与决策归属
|
|
2
|
+
|
|
3
|
+
| 内容 | 唯一责任方 | 消费者 |
|
|
4
|
+
|---|---|---|
|
|
5
|
+
| 业务规则、视觉、正式测试责任与物理绑定 | 正式输入与Islands上游责任方 | 设计、测试、产品 |
|
|
6
|
+
| 上游外部协议和生成实现 | Islands正式生成器及对应平台责任方 | 后端、测试、宿主接入 |
|
|
7
|
+
| 小程序端与后端请求、结果、错误和来源 | design | 小程序端与后端测试及研发 |
|
|
8
|
+
| 必要持久化表结构与关联 | design | 后端测试及研发 |
|
|
9
|
+
| 框架运行时和数据库公开能力 | Saddle | 后端及测试 |
|
|
10
|
+
| 小程序端测试定义、准备和独立预期 | minifish-test | 小程序端研发 |
|
|
11
|
+
| 后端测试定义、准备和独立预期 | backend-test | 后端研发 |
|
|
12
|
+
| 公共执行、观察、断言、报告工具 | 工具体系维护者 | 所有工具消费者 |
|
|
13
|
+
| 小程序端产品逻辑 | minifish | 小程序端验收 |
|
|
14
|
+
| 后端产品逻辑 | backend | 后端验收 |
|
|
15
|
+
| 任务输入、范围、共因分流及规则同步 | workflow / Owner | 各角色 |
|
|
16
|
+
| 真实环境与生产发布 | 获授权的平台/发布责任方 | 联调与发布参与方 |
|
|
17
|
+
|
|
18
|
+
本体系不默认安排独立adapt设计或人工重建上游外部协议/适配实现。缺少正式绑定、协议或真实平台事实时,定位具体影响并回报对应责任方,不由下游猜填。
|
|
19
|
+
|
|
20
|
+
## 交接条件
|
|
21
|
+
|
|
22
|
+
正式输入到设计:本范围的入口、来源、绑定和结果语义足以确定工程边界。真实下游尚未部署不等于协议不明确。
|
|
23
|
+
|
|
24
|
+
设计到测试:输入、结果、错误和来源可形成独立预期;后端另有必要DB设计与正式外部协议。不要让研发生成测试答案。
|
|
25
|
+
|
|
26
|
+
测试到研发:交接完整测试、准备、禁止结果、公共运行入口、冻结输入与已知有效失败。测试设施归测试/公共工具职责;产品研发不补写测试以掩盖缺口。
|
|
27
|
+
|
|
28
|
+
研发到验收:产品研发自主运行、实现和复验后交付完整增量。验收核证据适用性,必要时补验证,不机械重跑。小程序端与后端契约明确后可分别研发验收合入,不让另一端或联合验证成为无关的串行门槛。
|
|
29
|
+
|
|
30
|
+
Mock到联调、联调到生产分别确认环境、授权与独立验收要求;不以Mock通过宣称真实下游或生产可用。
|
|
@@ -0,0 +1,164 @@
|
|
|
1
|
+
# 任务规划与过程复盘
|
|
2
|
+
|
|
3
|
+
操作CoTask前读取平台cotask-owner协议;本文归saddle-islands-workflow,承载Owner的规划经验,不另定义工具协议。任务授权和用户当前要求优先。
|
|
4
|
+
|
|
5
|
+
## 启动前
|
|
6
|
+
|
|
7
|
+
先把用户指定项目落实为本轮允许读取的仓库、目录和输入版本。相似目录名、相邻项目或更多用例不构成扩大范围的理由;发现已有材料来自范围外,隔离该材料并回到正式输入重新核对,不把其统计和结论继续作为任务依据。
|
|
8
|
+
|
|
9
|
+
- 范围指向可索引的具体目录/原ID或具体交付对象,不只分配“处理测试”“完善小程序端”等分类。说明完成条件、文件所有权、依赖输入与输出位置。
|
|
10
|
+
- 在放行并行任务前核清共同入口、真实请求边界、可调用公共接口、工具与规则版本。未决业务选择列出依据供用户决策,不派开放任务靠执行者猜。
|
|
11
|
+
- 按写入冲突决定并行:区域测试在文件和准备接口互不冲突时可并行;同一页面产品实现采用单写者。公共设施、全局索引有唯一维护者,各区域独立文件和分支,集成后以精确版本交接。
|
|
12
|
+
- 产品任务以本轮完整需求和case集合为输入,不指定按目录或case顺序逐一研发。已有工程先运行本轮范围测试,以失败及需求变化定位工作,按共因统一修复;改后验证失败项和受影响的已通过项。单写者仅限制多个产品节点的并发写入,不限制节点内部统筹全部需求。普通case失败不应阻断其他独立case的失败收集,公共设施失效则先修共因。
|
|
13
|
+
- 给执行者实际可访问的规则和工具,不把Owner已读过/Skill源码已改当成成员已获得。工程Skill按已推送Git原包传播并核实际内容;Owner规划规则不必整篇复制给执行者,本轮特有交付目标写入任务,通用交付要求由Skill承载。
|
|
14
|
+
- 任务应有范围内修复权限,普通测试红灯分清产品或设施责任,不因为一次失败就阻塞或新增节点。真正源冲突与缺少不可替代输入才升级。
|
|
15
|
+
|
|
16
|
+
## 新任务继承公共能力,而非依赖旧Agent记忆
|
|
17
|
+
|
|
18
|
+
Owner先消化上游输入的不确定性:核定源版本,完成必要的编译、协议或目录生成及异常归因,准备实际可取的研发分支和生成物。首个设计阶段也基于明确分支与既定设计范围执行,不承担上游可用性探索。阶段内正常设计与实现判断仍归对应角色。正式交付物进入指定Git分支,运行证据、问题反馈和复盘进入指定共享目录。
|
|
19
|
+
|
|
20
|
+
任务分发只驱动阶段,不再编写一份研发手册。每个节点明确三件事:输入对象及精确版本、使用哪个Skill完成哪个阶段、交付到哪个Git分支或共享目录。存在业务分组时补充具体范围;不同节点可共用一份明确的版本清单,但不能仅写“自行看计划”而省略本节点输入对象。上游尚未完成时,写明所依赖的阶段产物,由检查点交接确认后的精确提交。
|
|
21
|
+
|
|
22
|
+
阶段职责、工具使用策略、门禁、结果判定、交付内容与复盘规则由对应Skill承载;公开命令和参数由工具说明承载。任务只提供这些资料可访问的冻结位置,不复制通用规则或逐条工具命令。Git分支和共享目录是交付承载位置,节点明确实际需要的目标即可,不为每个任务另造交付文件格式。
|
|
23
|
+
|
|
24
|
+
新Agent应能从节点直接找到业务输入、对应Skill和公开工具资料,并依此完成阶段。发现只有任务里的临时指令才能保证正确执行时,区分业务特有约束与通用规范缺口:前者保留在任务,后者修到Skill或工具,不继续堆长节点。
|
|
25
|
+
|
|
26
|
+
消费者先核入口可访问、满足当前交付目标;缺能力时给公共维护者具体缺口和使用场景,不自行复制算法或建立平行报告工具。已有工具即使工作正常,绕过它也属于消费与规划缺陷。Owner交付时核实际执行入口、输入身份和可访问产物,不以版本声明、文件存在或外观相似替代实际消费证据。
|
|
27
|
+
|
|
28
|
+
以新Agent仅凭新任务输入能找到并调用正确入口为检查标准。发现重复踩坑,区分Skill规则缺失、任务没有提供入口、执行绕过和公共能力退化,修到唯一责任处;通知当前执行者只是止损,不等于长期修复。后续新批次记录采用规则及实际入口,验证该缺陷是否复发;不为证明复用而重跑无关业务。
|
|
29
|
+
|
|
30
|
+
## 测试分批与产品单写者
|
|
31
|
+
|
|
32
|
+
同一页面的产品代码由唯一产品研发成员统一修改,不按case或测试区域分配多个产品写入者。测试按正式树结构划分互不重叠的责任批次,每个case自包含准备、请求计划和断言,由原负责该批的测试成员连续维护。
|
|
33
|
+
|
|
34
|
+
某批测试出错时,先区分单例问题与共同准备、生成器、观察方法等共性缺陷。共性问题交回原批次负责人统一修复,并暂停受影响批次的后续执行,保留在途清理和证据;其他独立批次照常推进。修后以代表验证再恢复该批,不转交Owner逐例修、不暂停整图,也不把未执行记为跳过。跨批公共工具缺陷明确唯一维护者和影响批次,由各原负责人接入修复。
|
|
35
|
+
|
|
36
|
+
真实产品缺陷汇总为功能和共因批次,提前交唯一产品成员,测试成员不为自己的case改页面逻辑。测试与产品可并行,但运行消费冻结的明确版本;产品成员自行运行独立测试完成修复反馈,修复后按影响集合复验;独立验收核证据并补必要验证,不机械重跑。职责调整须有明确依据,效率优化不能隐含授权测试成员修改产品。
|
|
37
|
+
|
|
38
|
+
跨多个独立测试批次出现同类失败时,Owner先审共同输入:Skill和任务是否明确源范围、准备闭包、公共API与观察合同,实际消费版本是否一致,控制是否覆盖真实接入。区分规则缺失、明确规则未落实、公共工具缺陷和局部case错误;确认上游原因后统一修规则或工具,由原批负责人接入,只暂停受影响组。不能让各批重复探索来补偿Owner规划缺陷,也不能仅凭相同报错就判定全部case同因。
|
|
39
|
+
|
|
40
|
+
## 节点完成与Owner复盘
|
|
41
|
+
|
|
42
|
+
阶段交付包含短篇过程复盘,字段见[复盘模板](task-retrospective.md)。报告写任务共享证据区,最终由Owner持久归档,不能混入业务代码仓。无问题可以明确写无,不为模板制造问题。
|
|
43
|
+
|
|
44
|
+
Owner收尾时结合报告和真实执行记录核对:
|
|
45
|
+
- 总历时与关键路径,安装/有效建设/验证/等待/返工分开;并行节点时长不能直接相加当总历时。
|
|
46
|
+
- 输入缺失、不准确、版本不可用、职责冲突造成的试错具体是哪一条;区分Owner设计缺陷、平台限制、正常产品修复。
|
|
47
|
+
- 重复运行是否由代码变化/失败修正/独立验收需要支撑,不能把必要验证称浪费,也不以省时为由减少覆盖。
|
|
48
|
+
- 给下一轮最多几项有证据的可执行改进:改哪里、谁负责、预期省掉哪类工作、怎样验证有效。节省时间未实测时标为待验证,不能凭感觉报提升。
|
|
49
|
+
|
|
50
|
+
## 长期沉淀与归属
|
|
51
|
+
|
|
52
|
+
通用规划/交接/效率经验进入本workflow参考;测试覆盖与断言进入测试Skill;小程序实现进入产品Skill。业务未决值、单次失败日志、具体任务SHA不作为通用规则。
|
|
53
|
+
|
|
54
|
+
只有来源清楚、能改变后续决策的经验才进入Skill。一次性细节留在任务复盘;不追加越来越长的强制流程。新规则先在小范围下一轮验证,再据效果保留或修正。已确认有效的技术方法必须通过实际发布/安装/任务引用链送达消费者,不能只记录在聊天或未发布源码。
|
|
55
|
+
|
|
56
|
+
本参考由Owner直接使用。修改后核规范与实际Skill引用及用户决策一致;Skill格式校验不等于效率已证明。下轮规划显式读取最近Owner复盘和本参考,记录采用了哪项改进。
|
|
57
|
+
|
|
58
|
+
## 由复盘落实下一轮
|
|
59
|
+
|
|
60
|
+
规划要列出“已证问题 → 本轮改变 → 检查证据”,不能只附历史复盘链接。优先处理关键路径:若耗时主要是逐case构建启动,采用经验证的批量并行工具;覆盖编写可以按区域并行,统一产品后由一个验收节点调用工具,不为分区运行重复安排agent。并发度、资源及生命周期验证属于测试设施,具体方法由测试Skill维护。
|
|
61
|
+
|
|
62
|
+
交接使用小型摘要加独立明细引用:唯一SHA、范围原ID、case manifest、准备接口与精确工作目录;运行原件不要多层重复嵌入。公开工具说明提供最小可运行用法,节点只交接其冻结位置,消费者不靠命名猜接口。原始完整输入仍保留,摘要不能删掉字段来源与边界。
|
|
63
|
+
|
|
64
|
+
冻结输入、兼容旧定义、依赖复用、失败共因归并及报告规则由本Skill及工具合同统一承载,任务仅声明本轮输入和交付目标。节点复盘核对是否还有源码漂移补跑、重复安装、输入截断补读和不必要串行等待;没有计时证据时不编造收益。通用规则发布并验证实际安装后再交消费者,本轮具体SHA和路径留在任务输入,不写死进通用Skill。
|
|
65
|
+
|
|
66
|
+
## 在研发前发现接入问题
|
|
67
|
+
|
|
68
|
+
- Owner交接Skill时提供执行者实际可访问的发布包路径和版本/摘要,并读取验证;只在Owner安装、只列私有入口或manifest不代表成员能消费。执行者接入时先核文件可读,缺失及时报告,不能悄悄不读。
|
|
69
|
+
- 新增公共准备与观察能力先用真实小程序代表场景验证调用闭包和原生载体,再并行扩展。SDK探针通过只证明探针;纯静态编译或假DOM控制不能证明产品接入已成立。代表场景准备被共因阻断时先处理该原因,不继续批量制造同类失败。
|
|
70
|
+
- 测试交给产品前检查新增观察是否沿用已核原生适配、有无残留HTML标签/属性假设,并提交首次真实接入结果;产品红灯与设施/准备红灯分列。集成负责检查跨区一致性,不能只合代码和清点数量。
|
|
71
|
+
- 复盘记录问题首次可发现阶段、当时缺少的信息或检查、实际重复工作及下一轮具体前置改进;已写Skill但未消费属于交接问题,已消费仍违规属于执行/审核问题,不用反复新增口号替代落实。
|
|
72
|
+
|
|
73
|
+
## 真实小程序运行依据
|
|
74
|
+
|
|
75
|
+
批量并行降低启动成本,但真实小程序用例仍是昂贵验证,不能默认每个节点都完整运行。任务规划逐节点明确:本次运行要消除什么不确定性、确切case集合、触发它的变更或失败、可复用的已有证据,以及耗时与停止条件。没有新增验证价值时不安排重复运行。
|
|
76
|
+
|
|
77
|
+
- 覆盖编写优先完成定义校验、静态门禁、编译与设施控制;新增或修改平台接入时,以能覆盖变化能力的最小真实代表集合验证,不要求各区域重复整批。
|
|
78
|
+
- 产品节点先消费已有有效失败清单;缺少适用于当前输入的结果时才建立批量基线。按共因统一修复后,只复验失败项及受影响已通过项,不在每次局部修复后全量跑。
|
|
79
|
+
- 最终验收统一运行约定交付范围。前序已在相同产品、测试、配置和环境输入上完成且有完整可信收据时,可核验复用;变更使证据失效或独立验收有明确需要时再运行,不为节点名称不同重复启动。
|
|
80
|
+
- 正常业务失败继续收集独立case;发现公共设施共因导致大批case无法到达目标时停止受影响批次,修复并用代表确认后恢复。环境未变、缺陷未修时不反复重试。
|
|
81
|
+
- 复用必须写清覆盖范围和输入依据,不能把旧SHA结果拼成新版本全绿。复盘记录启动次数、实际耗时和重复原因,用于下轮减少无效运行。
|
|
82
|
+
|
|
83
|
+
|
|
84
|
+
## 交付依赖闭包与证据复用
|
|
85
|
+
|
|
86
|
+
跨区域责任在任务输入中列齐参与目标及辅助锚点,公共合同、产品声明和编译运行包均须可解析。生成、门禁、依赖核验与运行启动串成失败即停止的入口,不能一边补准备元数据一边启动昂贵批次。
|
|
87
|
+
|
|
88
|
+
收尾基于变更依赖决定复用:保留每条原执行SHA、收据和适用性;内部文案/请求未变不代表整屏位置和截图仍适用。重新验证受影响区域及宿主外观,历史图明确标记,不能把汇总证据写成在最终SHA全部重新运行。瞬态截图干扰的处理归测试Skill,任务验收分别统计完整行为和独立展示采集,不通过重复全量运行掩盖设施问题。
|
|
89
|
+
|
|
90
|
+
## 未完成责任的收口
|
|
91
|
+
|
|
92
|
+
用原ID核三个集合:有可执行定义、实际执行到自身断言、已通过。节点partial完成不等于范围完成;“本批未覆盖”不是延期原因。未完成项关联具体定义或明确缺定义、原始收据、阻断阶段、共因、影响和下一动作。成员历史理由须与后来新增的公共能力和产品变化核对,不能永久继承已消除的阻碍。
|
|
93
|
+
|
|
94
|
+
证据复用同时审查绿例和旧失败。后续产品修复了旧缺失调用或目标时,旧失败仍保历史,但应按确切受影响集合重新验证;不能静态看到代码就转pass,也不需重跑无关全量。共同原因先归并再安排范围内修复与一次验证,独立组不依赖所有代表全绿才能前进。
|
|
95
|
+
|
|
96
|
+
只对用户授权的小范围、高成本残余作明确延期;无法达到目标的准备、观察工具缺口、源冲突、真实产品缺陷及跨端工作分开。不得把大批未设计用例统一包装为后端延期,或用通用下一步文字替代逐组可执行交接。
|
|
97
|
+
|
|
98
|
+
运行预算限制无依据的重复,并不禁止已查明配置错误后的必要复验。任务预先区分:配置预检失败(未进入业务)、真实断言失败、已修复后的验证;共同制品选择与输入hash校验在批次启动前完成。有限收口遇到新的独立问题时保首次原件及具体影响,按授权决定修复或延期,不把“只跑一次”变成机械阻塞。
|
|
99
|
+
|
|
100
|
+
|
|
101
|
+
## 整批收口与下一轮输入
|
|
102
|
+
|
|
103
|
+
剩余问题较多时,先把全部未闭合原ID按可验证的共同原因分组,明确每组责任方、输入、修改权限、依赖与验收集合,再分派可独立的组。Owner负责源决策与跨组边界,不成为每条失败等待人工分析和解阻的串行执行者。普通范围内修复由既定节点统一完成,不用不断追加一两个case节点替代整轮设计。
|
|
104
|
+
|
|
105
|
+
进入下一轮前,记录旧输入的最终结果与剩余交接,核对代码已推送及必要证据有持久位置,然后结束旧任务。Git已保全的源码不另备份,已有持久原件不重复复制整套shared;只补会随任务结束丢失的唯一结果、收据、复盘和剩余清单,缓存和可重建依赖不作为收尾前置。
|
|
106
|
+
|
|
107
|
+
源更新后先比较正式目录/原ID、语义目标、请求边界和准备条件,再判定旧定义与证据能否复用。保留旧结果作为历史,不在新目录直接继承pass或永久继承旧缺口。规划前核对本轮采用的Skill规则与实际消费者入口;发现同包旧文与已确认规则冲突,修改唯一规范并清理旧文,不让执行者自行选规则。
|
|
108
|
+
|
|
109
|
+
## 新迭代范围不得被近期子任务替代
|
|
110
|
+
|
|
111
|
+
新迭代先重述用户本轮交付目标,再建立源变化到各层产物的责任矩阵。按实际授权核对适配、契约、必要存储与外部协议、小程序端与后端测试、小程序端与后端实现和联合验收;每层列变更、无需变更的依据或具体待办。只要求某一层时不扩大范围,要求完整迭代时不能因近期一直做测试而缩成测试覆盖任务。
|
|
112
|
+
|
|
113
|
+
覆盖目录与原ID计数是验收索引,不是全部需求或后端覆盖的替代品。产品节点依据完整确定需求实现,失败清单用于定位和增量修复,不能把“尚无case暴露”当作不实现的理由。上轮裁剪、延期或小项降级须重新核对本轮授权,不能自动继承。
|
|
114
|
+
|
|
115
|
+
Owner启动前确定跨层边界及交付清单;执行节点可落实已确定设计,不能用新增“设计/研发”泛化节点掩盖输入未定。局部源待办只隔离准确影响项,工具与研发缺口仍由对应工程责任方解决。
|
|
116
|
+
|
|
117
|
+
小程序端与后端契约确定后,两侧可独立研发、以各自正式边界Mock验收并分别交付合入。联合接线验证单独安排,不默认成为两端独立合入的共同阻塞门槛;每次合入仍核相应权限、兼容性和提交历史,不把分层通过宣称为联合通过。
|
|
118
|
+
|
|
119
|
+
## 决策到实际Skill消费的同步
|
|
120
|
+
|
|
121
|
+
用户确认职责或策略变更后,在所属Skill唯一来源更新、提交并推送,按完整commit传播原始包并核workspace入口、任务共享输入逐文件一致。只有报告记录或未提交共享副本不算同步完成;npm发布用于备份,不作为消费前置。传播清单保仓库、commit、包目录、版本和每个文件哈希,后续可从Git恢复。规划新阶段、交接执行和发现冲突时重读实际Skill及对应参考,不能只凭包名、版本号或旧摘要。执行批次冻结内容,运行中不静默替换。
|
|
122
|
+
|
|
123
|
+
## 通用体系交付入口收敛
|
|
124
|
+
|
|
125
|
+
按当前仓库明确的研发规则交付,不能把某业务的分支或PR流程写成所有仓库的规则。公共规则和工具使用唯一正式来源;修改提交推送后,通过有完整来源身份的分发包交接。已有同一演进的交付入口持续更新,不因节点数量复制真源。
|
|
126
|
+
|
|
127
|
+
清理被替代引用前核对独有变更已保留;活动批次在安全点接入,不能为整理交付中断真实验证。平台流程故障由Owner处理,与已完成的源码和验证结果分别报告。
|
|
128
|
+
|
|
129
|
+
## 提交粒度与合入方式
|
|
130
|
+
|
|
131
|
+
用户选择“保留commit个数、允许原SHA变化”时,合入默认先将本批提交rebase到最新目标分支,再快进合入,禁止squash。保留各独立变更提交的粒度及对应说明;已在目标存在的补丁、rebase后变空或冲突导致需合并提交时,明确说明,不静默丢弃以凑流程。核对旧→新提交映射、range-diff及最终文件树;SHA改变本身不代表代码丢失。已完成的历史合入不追溯重写。活动任务保持冻结输入,Owner可用短生命周期集成分支完成rebase,未经交接不重写成员正在消费的分支。平台是否逐条发通知另属平台能力,不保证rebase会逐条通知。其他用户明确要求原SHA不变时,仍按其要求保留祖先历史。
|
|
132
|
+
|
|
133
|
+
## Owner前置探索与分组滚动交付
|
|
134
|
+
|
|
135
|
+
CoTask执行已明确的工程方案,不承担Owner尚未完成的设计探索。启动前由Owner核清范围、源义务、契约、准备闭包、平台接入、产物及验收方式;有不确定性的关键链路先作有限探索并保留结论和证据,再形成具体任务输入。不能把“研究可行方案、试到能跑”为公共节点的隐含职责,或以静态控制通过替代当前产品真实接入证据。
|
|
136
|
+
|
|
137
|
+
执行中出现超出预期的集中失败、依赖长期阻塞或重复探索,Owner应及时深入原件并重新评估计划,接回未决设计和探索,给出有依据的修订方案。仅暂停受影响工作并保全现场,确定且独立的研发继续;不要只定时查询状态,也不要为制造并行而派出输入未定的任务。
|
|
138
|
+
|
|
139
|
+
运行前按准备状态、外部请求链、插件/原生载体和观察能力建立依赖组,明确代表集合、扩展条件、停止条件及责任方。新增接入先验证实际产品代表能够到达目标并完成严格边界,再扩展同依赖组;已有可信证据可复用,不机械要求每组重跑。代表通过仅允许扩大执行,不代表该组所有原ID通过。
|
|
140
|
+
|
|
141
|
+
大批运行采用有界分组并持续读取阶段与错误,及时区分症状与已证实共因。确认共因阻止目标到达时,停止继续调度该组,保留在途执行清理和证据,其他独立组继续;暂缓项保留notrun及原因,不变成skip或pass。修复后先定向确认共因消除再扩展,不等待上万个case全跑完才分析。
|
|
142
|
+
|
|
143
|
+
已确认的产品问题以固定提交、完整可取源码、输入摘要和必要收据提前交付,产品研发可与剩余独立测试及报告整理并行。依赖应指向真实必需产物,不把整批完成或最终报告作为产品首次启动门槛。并行工作使用隔离副本,禁止修改正在验证的冻结输入;最终验收再核集成交付和证据适用性。报告整理本身不触发额外SDK运行。
|
|
144
|
+
|
|
145
|
+
|
|
146
|
+
## 产品自主研发与批次数据
|
|
147
|
+
|
|
148
|
+
Owner负责目标、正式输入、契约边界、职责和交付验收,不把前置设计明确误解为替产品成员指定代码修法。正常产品故障定位与实现决策属于产品研发:消费独立测试与真实失败,必要时自行运行,设计实现并定向复验。禁止以SDK0交付切断研发反馈,也不以报数需要强制每轮全批重跑。
|
|
149
|
+
|
|
150
|
+
测试按固定树区并行,交付后等待产品消费;唯一产品成员串行处理就绪功能批次,其他就绪组排队。每次产品迭代完成,不论完全通过与否,发布固定分组的逐ID覆盖账本及版本/证据,Owner在检查点核对并更新用户约定的通过数/总数,再安排下一批。汇报分组不是执行粒度,允许有效证据复用,真实回归不能为数字单调而隐藏。测试共因交原负责人审计整批同类消费者,仅暂停并退回实际受影响集合;跨批公共缺陷由统一公共节点处理,其他独立部分继续。
|
|
151
|
+
|
|
152
|
+
## 产品迭代的完整增量交付
|
|
153
|
+
|
|
154
|
+
每轮产品迭代先评估本责任批所有未通过case,按共因判断可研发、测试阻塞及源或契约待决,不能只挑少量代表后把局部错误当作整批结束理由。能处理的完成产品研发、受影响复验及必要回归后交付;确有共同前置失效或边界未决时,附影响范围和证据,不能盲目继续或泛化停工。评估全体不等于每轮全量重跑。
|
|
155
|
+
|
|
156
|
+
交付是覆盖本批全部责任的完整增量:保留有效通过证据,列本轮处理和复验、仍未通过项的共因与处置、测试退回集合及不受影响部分。整批同因审计不等于整批退回,只有证据表明整批测试大概率存在共同错误且没有独立可继续部分时才整体退回。原测试负责人修复增量,公共断言由公共维护者统一修;不作废无关成果或重复整批交接。
|
|
157
|
+
|
|
158
|
+
用户进度数字仅在产品完成本批实质迭代并经检查点核对后更新。测试交付本身不触发数字更新;产品验证或审查有效复用的依据逐ID保留,不因换发布人就把测试报告变成产品新增成效。其他批次维持上次产品发布结果,回退如实记录。
|
|
159
|
+
|
|
160
|
+
## 替代方案的退役与状态核实
|
|
161
|
+
|
|
162
|
+
测试树、工具入口或索引被新方案替代时,交付同时检查旧命令、文档、引用和仅服务旧体系的控制。仍被当前测试消费的能力迁入公共设施并核依赖;无当前用途的旧文件删除,历史由Git保留。确需并存时写明各自当前职责和退出条件,不能以“历史兼容”无限保留两套入口。清理不改变当前业务责任及通过数,按依赖验证,不因此重跑无关业务。
|
|
163
|
+
|
|
164
|
+
汇报中的研发状态须对应实际执行节点;问题存在不等于有人正在研发。等待项标明真实前置、负责人及是否已排队,不能仅改状态标签掩盖调度缺口。产品批次数字仍按检查点规则更新。
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
# 节点过程复盘(给Owner,不是业务验收报告)
|
|
2
|
+
|
|
3
|
+
建议控制在一页内。复用已有日志和handoff,不额外重跑收集统计。不能精确测量的写估算及依据,无法得到的写未知。
|
|
4
|
+
|
|
5
|
+
- 节点/职责/交付:本次完成范围,引用现有handoff。
|
|
6
|
+
- 时间:开始/结束;安装、实际建设、验证、等待、返工的可测耗时或估算;并行重叠注明,不重复计时。
|
|
7
|
+
- 运行:实际运行次数,哪些因修改/失败修正/独立验收必需,哪些本可避免,附对应命令或日志索引。
|
|
8
|
+
- 输入问题:缺失、不准确、冲突、不可访问或版本漂移的具体输入 → 导致的尝试 → 代价 → 最终依据。没有就写无。
|
|
9
|
+
- 协作问题:依赖等候、公共文件冲突、职责不清、交接缺项、Owner额外介入及原因。
|
|
10
|
+
- 有效做法:本轮实际避免了什么重复,证据或对照是什么;无对照不声称量化提效。
|
|
11
|
+
- 改进建议:至多3项,包含应改的任务定义/接口/环境/Skill、适用范围、后续如何验证。区分已验证经验与待验证建议。
|
|
12
|
+
|
|
13
|
+
Owner最终汇总另写:关键路径与主要浪费;自身规划责任;采纳/暂不采纳的建议及理由;下一轮具体修改;经验进入哪个Skill、是否已真正送达消费者。报告/日志/截图不提交业务Git。
|
package/README.md
DELETED