跳过 Tasks 以后，执行计划由高级模型在开发过程中动态维护，但项目仍然需要一份稳定的收口记录。本节增加一份自定义的实施报告，把 SPEC、代码、测试和验收结果重新连接起来，并说明本轮开发结束时到底应该留下哪些产物。
8.1 为什么还需要一份实施报告
实现 Agent 在任务结束后，如果只保留一句：“开发完成，测试全部通过”，这并不足以支持验收。
标准 Spec Kit 使用 tasks.md 记录待办任务和完成状态。但是，胶囊系统选择让高级模型直接从 Plan 进入实现，没有生成这份中间清单。我们因此增加 implementation-report.md，在实现结束以后记录最终结果：
SPEC：规定要实现和验收什么
↓
Plan：规定准备怎样实现和验证
↓
代码与测试：形成实际实现和验证证据
↓
implementation-report.md：逐项汇总实现结果
报告只是一张索引，把 SPEC 条目指向实现文件、测试文件、执行结果和已知问题。以后审查项目时，我们可以从报告快速找到证据，而不是重新翻阅整段开发对话。
implementation-report.md 是本项目增加的自定义产物，不是 Spec Kit 的标准文件。
8.2 先固定模板，再让 Agent 填写
如果 Prompt 只要求“生成一份最终报告”，不同 Agent 很可能给出完全不同的内容。有的只会概括改了哪些文件，有的只会粘贴测试命令，还有的会漏掉没有完成的需求。我们需要一份标准模板，约束 Agent 产生标准的报告。先在功能目录中建立报告模板：
specs/001-capsule-main-flow/implementation-report-template.md
实现完成以后，Agent 读取这份模板，根据真实结果生成：
specs/001-capsule-main-flow/implementation-report.md
模板和报告要分开保留。模板规定每次实施都应该回答哪些问题，最终报告只记录本次实施的答案。重新开发或进行一次新的完整验收时，可以再次从模板生成报告。
这份模板围绕一条很简单的主线组织：
实现了什么
↓
每项 SPEC 要求由哪里实现、怎样验证
↓
实际运行了哪些测试、结果是什么
↓
是否偏离 Plan，还有什么没有完成
↓
最终交付物是否齐全，能否进入验收
其中最重要的是“SPEC 逐项核对表”。它不能只写“FR-001 至 FR-056 全部完成”，而要保留每个编号，并给出对应的实现位置和验证方式。自动化测试无法覆盖的内容，也要明确写出采用了人工检查、文档检查还是端到端验收。通过、失败、未运行 和 阻塞 是不同结果，不能混写。
8.3 本轮开发的最终交付物
这里的“交付物”并不是给最终用户安装的安装包，而是当前开发阶段完成以后，项目仓库中应该具备并可供验收的内容。胶囊系统本轮开发需要核对下面四组产物。
产品实现
-
src/capsule_system/中的 Python 核心模块。 - 可供 Agent 稳定调用的
capsuleCLI。 -
skills/capsule-system/中与 Agent 基座无关的 Skill。 - 飞书存储适配及必要的配置、权限检查能力。
-
pyproject.toml、依赖锁定文件和开发运行说明。
测试与验收资料
-
tests/unit/中的单元测试。 -
tests/contract/中的 CLI、数据结构和外部适配契约测试。 -
tests/integration/中的模块协作与飞书适配测试。 -
tests/acceptance/中对应用户故事和验收场景的端到端测试。 -
tests/fixtures/中经过标注的输入样例和预期结果。
设计依据
-
spec.md及其需求清单和验收标准。 -
plan.md、research.md、data-model.md、contracts/和quickstart.md等 Plan 产物。 - 实现过程中发生的技术偏离及其理由已经记录。
实施结果
- 全部实际测试命令及通过、失败、未运行数量已经记录。
- SPEC 中的功能需求、边界情况、验收场景和成功标准已经逐项核对。
- 未完成、阻塞、跳过和需要人工验收的内容已经明确列出。
-
implementation-report.md已按模板生成，并给出是否可以进入验收的结论。
测试资料和实施报告属于开发与验收资产，应该保留在项目仓库中，但不等于以后必须发给最终用户。安装包包含什么、怎样检查用户环境、怎样升级和卸载，仍然留给后续发布阶段处理。