Feature Delivery Protocol

目的

Day 2–14 的每个能力包都使用同一协议，把 Codex 从“按要求生成代码”约束为“按合同交付跨端能力”。

每个能力包使用独立 thread 和 Goal。跨天真相写回 capability ledger、共享合同、架构文档、测试和 Git 历史，不依赖旧线程记忆。

六步交付循环

1. 调查

学员提供 capability id，要求 Codex只读调查：

进入 <CAPABILITY_ID>。先读取能力包、根架构、真实 Prisma 模型、共享合同、
四端现有实现和验收。当前阶段禁止修改。输出事实、缺口、依赖、风险、
规格冲突和必须由我决定的问题，并给出文件与测试证据。

调查阶段不得：

• 从字段名称猜测数据库 relation。
• 因为另一端有实现就假设当前端相同。
• 把 README 的计划能力当成已落地能力。
• 提前写代码来“探索”产品决策。

2. 决策

Codex 只提出会改变产品行为、数据所有权、安全边界或发布方式的问题。学员记录：

• 决策。
• 备选方案。
• 采用理由。
• 被拒绝方案。
• 是否需要 ADR 或 README 更新。

纯实现细节由 Codex 在协议边界内自主处理。

3. 计划

基于已确认决策，创建可持续更新的 ExecPlan。按垂直切片组织，而不是先做完
全部 API 再分别补客户端。每个阶段必须列出 API/Admin/iOS/Android 工作面、
真实模型与合同、异常和恢复路径、验证命令、文档影响和退出条件。

计划必须明确：

• capability dependencies。
• data migration 和 backfill。
• realtime 和 repair scope。
• 本地缓存与服务端真值边界。
• permission 和 abuse cases。
• fake 与真实外部集成边界。
• rollout、rollback 和兼容性。

4. Goal 实施

Feature Goal 使用能力包中的完成合同。Goal 可以持续迭代，但不能自行扩大能力边界。

建议格式：

/goal 完成 <CAPABILITY_ID>，以 <acceptance command / manifest> 为完成证据，
同时保持 <cross-client contracts / security / data constraints>。
仅使用 <allowed files and services>。每次失败后根据日志和最小复现选择下一步，
更新 ExecPlan 与 evidence ledger。若在现有边界内无有效路径，按 blocked contract
停止并报告。

5. 独立审查

Goal 完成后开启新线程：

不要相信实现线程的完成声明。作为独立 reviewer，根据 <CAPABILITY_ID> 的规格、
真实模型、共享合同和验收，从 API、Admin、iOS、Android、异常恢复、安全和文档
七个方向审查。优先寻找能在生产触发的具体缺陷。没有可行动问题时明确说明验证范围。

阻断问题回到原 Goal thread 修复；修复后重新审查受影响范围。

6. 冻结

能力包只有满足以下条件才可冻结：

• mandatory gates 全绿。
• capability ledger 更新。
• schema/API/realtime contract 无漂移。
• 架构和运行手册已同步。
• 证据包可以由别人复核。
• 没有被悄悄降级的功能。
• Git diff 只包含当日范围和必要的共享修改。

每日节奏

08:30-09:30  调查与产品决策
09:30-10:00  计划审阅
10:00-15:30  Goal 实施与自动续跑
15:30-17:30  真机、故障注入和跨端验收
17:30-19:00  独立审查与修复
19:00-20:00  文档、证据、复盘和 checkpoint

时间只是建议。未达到 GREEN 时不能为了日程把 YELLOW 写成完成。

复盘如何更新协议

每天结束记录：

• 哪个事实最晚才被发现。
• 哪个测试最早可以暴露问题。
• 哪条规则应进入 AGENTS.md。
• 哪个能力包输入不够清晰。
• 哪个 blocker 属于环境而不是代码。
• 哪个 Codex 行为属于可复现的假完成模式。

复盘结果进入下一版本课程，而不是留在聊天记录里。