Day 14：系统收敛、故障演练与最终验收

当日成果

不再增加新功能。把 Day 1–13 的能力作为一个系统进行 clean rebuild、跨端验收、故障注入、安全审查、文档对账和发布演练。

能力边界

目标是证明 Teaching Baseline，而不是临时补充未进入 manifest 的“最后一个需求”。任何新增能力必须进入未来版本。

前置条件

• Day 1–13 capability 均为 GREEN 或有经教师批准的明确 conditional blocker。
• 工作树可以解释全部变更。
• 隔离测试环境可重建。

系统级场景

场景一：全新用户

注册/登录、onboarding、好友、会话、消息、动态、通话、AI、客服、退出。

场景二：多设备

同一用户在 iOS/Android 同时在线，验证 read state、realtime、session revoke 和 projection 收敛。

场景三：断网与重启

发送消息、发布动态、上传媒体、恢复网络、杀进程、重启，确认 outbox 和 cursor。

场景四：权限变化

好友变 block、群成员被移除、会话解散、官方 operator 降权，确认旧缓存不能继续写入。

场景五：外部服务失败

Redis、邮件、对象存储、推送、Agora、AI provider 分别故障，确认降级、重试和观测。

场景六：账号删除

临时账号受理后立即失效，worker 中断恢复，外部撤权和两端本地 purge。

最终 Goal

/goal 使当前教学仓库完整满足冻结的 Srome Teaching Baseline。不得新增 baseline 外能力。
从 clean state 重建数据库、API、Admin、iOS、Android，运行全部 capability 和 system
acceptance，执行规定的故障注入、安全审查、文档/schema/contract 对账与内部发布演练。

发现失败时按最小复现定位到所属 capability，修复后重跑受影响的局部 gate 和全局 gate。
不得降低验收、删除测试、把 conditional 假装 mandatory 通过或把已知问题隐藏在总结中。

只有 capability ledger 全部符合最终状态、system acceptance 全绿、独立审查无 blocker、
证据可复核且 clean rebuild 成功时才可完成；否则以 confirmed/partial/blocked/failed
分别报告。

独立审查

至少进行四个彼此独立的 review：

1. 数据、API 与权限。
2. iOS architecture、生命周期与体验。
3. Android architecture、生命周期与体验。
4. 安全、运维、发布与文档一致性。

reviewer 不接受“前一线程已经通过”的结论，必须重新读取证据。

Mandatory gates

• [ ] empty database migration 到最新状态。
• [ ] README 数据模型与全部 Prisma model/enum 机械对账。
• [ ] API/Admin production build 和真实 fallback smoke。
• [ ] iOS clean build、安装、启动、主流程。
• [ ] Android clean build、安装、启动、主流程。
• [ ] 多设备 realtime/local-first convergence。
• [ ] push/call/provider conditional gates。
• [ ] account deletion 全域验收。
• [ ] secret、permission、privacy、dependency audit。
• [ ] capability ledger 无隐式 YELLOW。
• [ ] 四组独立 review 无 blocker。
• [ ] 最终 evidence package 不含敏感数据。

常见假完成

• 在旧数据库和热缓存上通过，clean environment 失败。
• 只跑 happy path。
• 为赶结课把失败 capability 改成 optional。
• iOS/Android 版本行为不一致但分别演示成功。
• 文档仍描述已删除或未实现能力。
• 发布包与验收 commit 不一致。

最终交付物

• Teaching Baseline capability ledger。
• 架构 README 和 ADR。
• 完整 evidence package。
• API/Admin 部署演练记录。
• iOS/Android 内部安装包及校验信息。
• 已知限制和 residual risk。
• 十四天 ExecPlan 与每日 checkpoint。
• 学员自己的 Codex 项目交付协议。
• 下一阶段产品路线图。

结课标准

结课不是“做出了一个看起来像微信的 App”，而是：

学员能够证明自己用 Codex 推进了一套跨后端、运营端和双移动端的系统，并且知道每项能力为何成立、如何验证、失败后如何恢复、下一次如何重复。