integrate: sync appendix sources to v0.5 appendix table (00-10)

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.

cloud/skills/software-engineering/templates/roles/07-acceptance.md

@@ -6,12 +6,18 @@
 
 1. 按 `templates/artifacts/acceptance-checklist.md` 生成本项目的验收清单，
    每一项对应 PRD 里的一条验收标准，不额外加、不悄悄删。
-2. 每个已选客户端准备一份演示产物：怎么启动、测哪个核心流程、
-   已知问题是什么、哪些平台未编译验证。web 演示可真跑，
-   未编译端审代码和构建步骤，两者效力不同，分开标注，不能混成一张“通过”表。
-3. 发布说明草稿，按端分别写：新能力、已知问题、回滚方式
-   （至少写清“出问题先停哪个端”）。web 部署、桌面安装包分发、
-   应用商店审核是三条流水线，分开记录，不要写成一次全上。
+2. 为 web 单端准备一份演示产物：怎么启动、测哪个核心流程、
+   已知问题是什么、哪些平台未编译验证。web 演示可真跑；
+   iOS / Android 原生只留后置占位，不进本轮演示产物，不混成一张“通过”表。
+3. 发布说明草稿，web 单端写：新能力、已知问题、回滚方式
+   （至少写清“出问题先停 web 端”）。web 部署的回滚方式单独记录；
+   桌面安装包分发、应用商店审核不在本轮流水线内，不写成已走完。
+4. 上手文档：web 版一份，写清启动、登录、核心流程、常见问题；
+   web 版在 G4a 交付时先交，不拖到 G6 才现写；iOS / Android 原生后置，
+   不在本轮补移动版上手文档。
+5. v1.1 交接清单：未修缺陷（带归属和严重程度）、开放问题
+   （含任务间问答里未关闭的假设）、下轮待办；三项缺一不算 G6 收尾完成；
+   G8 要把它更新为含 G7 结论的终版，三项缺一仍不算齐。
 
 ## 用户确认规则
 
@@ -31,8 +37,9 @@
 
 ## 按端发布与回滚（验收）
 
-- 发布按端分别做：每端发布时打 tag，例如 v0.1.0；
-  发布说明从已合 PR 汇总，不凭记忆重写；发布记录里写清端、tag、PR 号、执行人。
+- v0.5 起发布为 web 单端：web 发布时打 tag，例如 v0.1.0；
+  发布说明从已合 PR 汇总，不凭记忆重写；发布记录里写清端（web）、tag、PR 号、执行人；
+  iOS / Android 原生后置占位不打发布 tag。
 - 回滚是 revert 对应 PR，或重部署上一个 tag；绝不是 force-push 回退主线；
   回滚后重新走合并门（CI、评审）才能再发布。
 - 合并记录复核：PR 号、合并提交 hash、CI 运行链接、执行人缺一项，