host
4e554b5c07
SKILL.md claimed its appendix was spliced verbatim from templates/roles/ by a generation script (see CHANGELOG), but the pack contained none of the three. Add the nine role sources (mechanically split from the v0.2 appendix; SKILL.md untouched, zero semantic change), tools/check_appendix.py (verify + --emit, stdlib only, never edits SKILL.md), CHANGELOG.md, and test_skill_appendix_provenance.py (5 tests). Seeding unchanged: skill_seed copies SKILL.md only, so templates/tools/CHANGELOG never reach the tenant home.
40 lines
2.1 KiB
Markdown
40 lines
2.1 KiB
Markdown
# 角色模板：验收 / 发布（协调员兼任，用户拍板）
|
|
|
|
这不是一个可以自己给自己打分的开发线程。协调员准备材料，用户逐项确认。
|
|
|
|
## 协调员准备
|
|
|
|
1. 按 `templates/artifacts/acceptance-checklist.md` 生成本项目的验收清单，
|
|
每一项对应 PRD 里的一条验收标准，不额外加、不悄悄删。
|
|
2. 每个已选客户端准备一份演示产物：怎么启动、测哪个核心流程、
|
|
已知问题是什么、哪些平台未编译验证。web 演示可真跑，
|
|
未编译端审代码和构建步骤，两者效力不同，分开标注，不能混成一张“通过”表。
|
|
3. 发布说明草稿，按端分别写：新能力、已知问题、回滚方式
|
|
（至少写清“出问题先停哪个端”）。web 部署、桌面安装包分发、
|
|
应用商店审核是三条流水线，分开记录，不要写成一次全上。
|
|
|
|
## 用户确认规则
|
|
|
|
- 用户逐项勾选通过 / 不通过。不通过项写清原因，变成新一轮待办，
|
|
不算“基本通过”或“下次再说”。
|
|
- 协调员不能代替用户勾选，不能把 QA 通过等同于用户验收通过。
|
|
|
|
## 完成定义
|
|
|
|
- 验收清单全部通过，或不通过项已明确列入下一轮待办并经用户确认。
|
|
- 发布说明里的已知问题和未验证项与各客户端交付物一致，没有美化。
|
|
- 分支合并记录完整：哪个分支、何时、谁评审、CI 结果是什么、执行合并的人或宿主操作是谁。
|
|
协调员只给合并决定，不冒充执行人。
|
|
|
|
---
|
|
|
|
|
|
## 按端发布与回滚（验收）
|
|
|
|
- 发布按端分别做：每端发布时打 tag，例如 v0.1.0；
|
|
发布说明从已合 PR 汇总，不凭记忆重写；发布记录里写清端、tag、PR 号、执行人。
|
|
- 回滚是 revert 对应 PR，或重部署上一个 tag；绝不是 force-push 回退主线；
|
|
回滚后重新走合并门（CI、评审）才能再发布。
|
|
- 合并记录复核：PR 号、合并提交 hash、CI 运行链接、执行人缺一项，
|
|
验收就不算完成；已删远程分支的要确认合并提交已在主线。
|