Integration arbitration, not a PR commit: v0.3/v0.4/v0.5 synced body changes into appendix chapters 00/02/04/06/07 while templates/roles/ sources stayed at v0.2, so check_appendix failed 6 chapters; and 09-ops/10-iteration chapters (v0.5) were invisible to the strict chapter regex because of the ', v0.5 new' title suffix, breaking the #214 matrix-vs-appendix test. Direction is sources follow the appendix (appendix is the tenant-visible authoritative version; never overwrite v0.5 text with v0.2). 09/10 headers normalized to strict form (suffix only); 09/10 sources split mechanically from the appendix; EXPECTED_IDS extended to 11 chapters in the checker and both appendix tests.
2.6 KiB
2.6 KiB
角色模板:验收 / 发布(协调员兼任,用户拍板)
这不是一个可以自己给自己打分的开发线程。协调员准备材料,用户逐项确认。
协调员准备
- 按
templates/artifacts/acceptance-checklist.md生成本项目的验收清单, 每一项对应 PRD 里的一条验收标准,不额外加、不悄悄删。 - 为 web 单端准备一份演示产物:怎么启动、测哪个核心流程、 已知问题是什么、哪些平台未编译验证。web 演示可真跑; iOS / Android 原生只留后置占位,不进本轮演示产物,不混成一张“通过”表。
- 发布说明草稿,web 单端写:新能力、已知问题、回滚方式 (至少写清“出问题先停 web 端”)。web 部署的回滚方式单独记录; 桌面安装包分发、应用商店审核不在本轮流水线内,不写成已走完。
- 上手文档:web 版一份,写清启动、登录、核心流程、常见问题; web 版在 G4a 交付时先交,不拖到 G6 才现写;iOS / Android 原生后置, 不在本轮补移动版上手文档。
- v1.1 交接清单:未修缺陷(带归属和严重程度)、开放问题 (含任务间问答里未关闭的假设)、下轮待办;三项缺一不算 G6 收尾完成; G8 要把它更新为含 G7 结论的终版,三项缺一仍不算齐。
用户确认规则
- 用户逐项勾选通过 / 不通过。不通过项写清原因,变成新一轮待办, 不算“基本通过”或“下次再说”。
- 协调员不能代替用户勾选,不能把 QA 通过等同于用户验收通过。
完成定义
- 验收清单全部通过,或不通过项已明确列入下一轮待办并经用户确认。
- 发布说明里的已知问题和未验证项与各客户端交付物一致,没有美化。
- 分支合并记录完整:哪个分支、何时、谁评审、CI 结果是什么、执行合并的人或宿主操作是谁。 协调员只给合并决定,不冒充执行人。
按端发布与回滚(验收)
- v0.5 起发布为 web 单端:web 发布时打 tag,例如 v0.1.0; 发布说明从已合 PR 汇总,不凭记忆重写;发布记录里写清端(web)、tag、PR 号、执行人; iOS / Android 原生后置占位不打发布 tag。
- 回滚是 revert 对应 PR,或重部署上一个 tag;绝不是 force-push 回退主线; 回滚后重新走合并门(CI、评审)才能再发布。
- 合并记录复核:PR 号、合并提交 hash、CI 运行链接、执行人缺一项, 验收就不算完成;已删远程分支的要确认合并提交已在主线。