用 /goal 模式交给 Codex 完成实现HERMES & AGENT ENGINEERING · 课时 09

/goal 完成胶囊系统 001-capsule-main-flow 的 P1、P2 全部实现。

依据：
- 读取当前项目中适用的 AGENTS.md。
- 读取 specs/001-capsule-main-flow/spec.md。
- 读取该功能目录中的全部 Plan 产物，包括 plan.md、research.md、data-model.md、contracts/ 和 quickstart.md。
- 读取 specs/001-capsule-main-flow/implementation-report-template.md。

执行要求：
1. 开始编码前先检查现有代码和工作区，保留用户已有修改，不得擅自还原或删除。
2. 在进入自动开发以前，根据 quickstart.md 和飞书存储契约完成外部环境预检：检查 `lark-cli` 配置和登录状态、飞书应用权限、目标资源权限，以及专用验收空间是否已经准备。验收只能使用专用测试资源，不得操作用户的正式数据。
3. 如果缺少飞书配置、登录授权或必要的资源标识，主动执行安全的初始化或登录命令。当授权流程必须由用户在浏览器或飞书中完成时，暂停当前步骤，向用户说明正在等待的具体操作。用户完成后重新验证，然后继续同一个 Goal，不得因为这次正常交互就结束任务。不得要求用户在对话中直接粘贴访问令牌或客户端密钥，应使用飞书正式授权流程或安全的凭证存储。
4. 飞书环境预检通过后，自行制定并持续更新执行计划，可以根据代码和测试结果调整顺序；本项目不生成 tasks.md。
5. 按照 SPEC 完成 P1、P2，并遵守 Plan 已经确定的架构、数据边界和模块契约。不实现 SPEC 和 Plan 明确排除的功能，不把发布打包扩大到本轮开发中。
6. 根据 SPEC 的功能需求、边界情况、验收场景和成功标准，以及 Plan 中的测试策略，创建或更新必要的单元测试、契约测试、集成测试和端到端验收测试。不能只运行已有测试。
7. 实现过程中持续运行与当前修改相关的测试；实现完成后运行全部自动化测试，包括使用专用飞书空间的实时端到端验收测试，并根据失败结果继续修正。不得伪造测试通过或外部系统验收结果。
8. 实际执行逐项核对：每一条用户故事、验收场景、边界情况、功能需求和成功标准，都必须能指向实现文件、测试文件或其他可检查的验证方式。
9. 完成后按 implementation-report-template.md 生成 specs/001-capsule-main-flow/implementation-report.md。报告必须填写真实的实现位置、测试命令、结果数量、Plan 偏离、未完成项和最终判断，不得保留模板占位内容。

完成标准：
- P1、P2 的代码和必要测试已经完成，SPEC 各条要求都有可核对的实现或验证依据。
- 飞书配置、授权、资源权限和专用验收空间已经通过实际检查。
- 全部自动化测试和实时飞书端到端验收测试已经实际运行，没有被隐藏或未解释的失败。
- implementation-report.md 已经完整生成，所有结论与真实代码和测试结果一致。
- 最终回复需要概括实际完成的功能、测试结果、尚未解决的问题，并给出实施报告的路径。

阻塞处理：
- 需要用户完成飞书登录、授权或选择专用验收资源时，这属于 Goal 内的正常交互，不属于任务失败。明确告诉用户应该完成的操作，等待用户处理，验证成功后继续执行。
- 只有当用户明确拒绝或无法提供必要授权、无法准备专用验收资源，或飞书平台经过合理检查后仍然不可用时，才能将 Goal 标记为阻塞。此时必须在实施报告中写明已完成的部分、缺少的条件和恢复后应执行的命令，不得宣布目标完成。
- 遇到问题时先尝试在现有 SPEC 和 Plan 范围内解决。只有在缺少用户决定或外部条件，并且已经无法继续完成其他有意义的工作时，才报告阻塞。

不得因为已经生成项目骨架、完成部分模块、通过部分测试或写出总结，就宣布目标完成。