Day 1：Foundation Goal Demo

当日成果

从通过预检的 starter repository 出发，启动一次 Foundation Goal，使 Codex 自动推进到底座 GREEN 或给出可复现的真实 blocker。

当天结束时，API、Admin、iOS、Android 必须形成一条真实 walking skeleton：登录、session、GET /me、本地持久化、Admin 用户列表和 SSE connection-ready。

能力边界

本日完成横向基础设施，不追求完整业务功能。

包括：

monorepo、构建、测试和架构文档。
PostgreSQL、Prisma、Redis adapter。
最小 user/credential/session。
API/Admin/iOS/Android 共享合同。
两端 auth shell、本地数据库、realtime/outbox 骨架。
Admin auth、布局和一条用户数据链路。
邮件、存储、推送、通话的 fake adapter。

不包括 OAuth、好友、聊天、动态、真实推送、真实通话、AI 和账号删除。

前置条件

scripts/doctor.mjs 全绿。
指定版本 Node、pnpm、Docker、Xcode、Simulator、JDK、Android SDK。
starter repository clean。
Codex Goal 可用且预算足以覆盖一个教学日。

章节

为什么底座决定后续十三天上限。
如何把架构定义变成可执行 baseline。
如何把任务依赖图交给 Goal。
如何观察 Goal，而不在每次失败时抢走控制权。
如何识别 Goal 的假完成和真实 blocker。
如何从 clean state 复验并冻结。

启动前调查

text

不要修改代码。读取 Foundation 规格、任务图、合同和验证器，检查当前机器与
starter repository 是否满足启动条件。输出会阻断 Goal 的环境问题、规格冲突、
缺失依赖和潜在不可逆动作。环境不合格时不要启动 Foundation Goal。

Foundation Goal

直接使用 Foundation Goal 协议中的推荐合同，并把课程版本和 baseline id 固定在 Goal 内。

教师演示重点

Goal 首次失败时如何读取日志并继续，而不是重新发一个大 Prompt。
Goal 如何维护 ExecPlan 和 evidence ledger。
模型什么时候应该自主修复，什么时候必须停下来问人。
为什么 foundation:verify 比生成的文件数量更重要。
为什么预算耗尽不等于完成。

Mandatory gates

[ ] empty database migration 成功。
[ ] API/Admin typecheck、test、production build。
[ ] auth/login/refresh/logout/me smoke。
[ ] SSE connection-ready/heartbeat。
[ ] Admin 登录后能查看真实测试用户。
[ ] iOS clean simulator build、启动、登录和本地 session 恢复。
[ ] Android clean build、启动、登录和本地 session 恢复。
[ ] shared contract drift 为零。
[ ] fake adapters 被清楚标识。
[ ] secret/env/architecture audit 通过。
[ ] clean state 运行 foundation:verify 通过。

常见假完成

只生成 iOS/Android project，没有真正启动。
移动端使用硬编码用户绕过 API。
Admin 用户列表使用 fixture。
SSE 只是接口声明，没有建立连接。
为了通过编译，把 local database、outbox 或 adapter 留成空实现。
验证器失败后直接修改验证器。

Checkpoint

冻结：

foundation-v1 capability ledger。
Foundation ExecPlan。
evidence ledger。
架构 README。
clean rebuild 证据。
Day 1 checkpoint commit/tag。

只有四端 walking skeleton 为 GREEN 才能进入 Day 2。