Ship：交付、提交与复盘

本节目标

让这次的成果可以被找到、被检查、被继续开发：

• 对照 SPEC.md 核查没有越界功能。
• 修复尚未通过的核心测试。
• 提交一次有意义的 Git commit。
• 请另一位同学实际操作验收。

版本不是一句「我做完了」，而是可追溯的成果。

交付前，先把最低要求补齐

1. 对照 SPEC.md 确认没有越界功能（没有多出来的登录、数据库、AI 接口）。
2. 优先修复尚未通过的 T01–T06 核心项。
3. 暂时不做 UI 美化、不加新功能。

暂时无法全部通过？如实记录现象和原因线索，保留可运行版本。不把未通过改成「已完成」。

提交版本

1. 保存项目根目录的 SPEC.md。
2. 提交源代码与需要的项目文件。
3. 写一次有意义的 Git commit（说明这次做了什么）。
4. 保留验收结果记录。

按课程既有的 gitee 作业仓库约定提交，建仓与目录结构见 C102 的「如何提交作业」。

注意：不要提交 node_modules、密钥或本地私密信息。提交后检查这次提交真的包含代码和 SPEC，而不是只看到一个「成功」提示。

同伴验收

把鼠标交给另一位同学，请他：

• 新建一篇笔记；
• 修改并重新打开；
• 删除，然后刷新。

观察并记录：他在哪一步卡住了？是操作入口不明确，还是功能本身失败？

别人能独立操作，结果才更可信。用真实运行的项目演示，不是 AI 的输出文字或静态截图。未通过项如实记录。

课后复盘

回答三个问题：

1. 哪条 SPEC 避免了 AI 的误解？
2. 哪个结果是你亲手验证过的？
3. AI 说完成，与实际完成，差在哪里？

Think → Build → Verify → Ship：这次的成果，是一个可运行的 V0。 先明确问题，再确定范围；先约定验收，再交给 AI；完成靠证据。

本次交付清单

• 项目根目录有 SPEC.md。
• Web 应用能打开，空状态正常。
• CRUD 与刷新持久化可以实际演示。
• T01–T06 有真实记录（含未通过项的说明）。
• 代码与 SPEC 已提交到 Git。

第一版的意义不是「做完了」，而是可以继续迭代。后续模块会在这个 V0 上继续加能力——但现在，先确认它真的能跑。

完成后回到 模块导学，对照学习路线检查每一站是否都留下了结果。