在 CI 中把 GitHub 交付事件沉淀为 Basic…

当 CI 已由 `bm ci collect` 生成 ProjectUpdateContext，并且需要为 `bm ci publish` 输出结构化项目更新摘要时使用。

适用场景

解决思路

1. 读取 `bm ci collect` 在 `.github/basic-memory/project-update-context.json` 生成的 `ProjectUpdateContext` JSON。
2. 把该 JSON 当作不可变的唯一事实来源，用于获取 repository、event type、PR number、workflow run、SHA、source URL、timestamps、deployment environment。
3. 不要编造测试、部署检查、关联 issue、产品影响或决策。
4. 如果证据缺失，在 `verification` 中简短说明，或将该字段留空。
5. 只返回符合 `AgentSynthesis` 结构的 JSON，字段包括 `summary`、`why_it_matters`、`user_facing_changes`、`internal_changes`、`verification`、`follow_ups`、`decision_candidates`、`task_candidates`；无内容的数组字段留空数组。
6. 优先写简短解释，而不是逐 commit 的 changelog。
7. 保留意图、行为变化、源链接、上下文中已有的验证证据，以及具体后续事项。
8. 仅当源上下文明确包含明确的产品或架构决策时，才把它们放入 `decision_candidates`。
9. 仅当未来工作足够具体、可执行时，才把它放入 `task_candidates`。
10. 保持事实性和实用性；这是项目记忆，不是营销文案。
11. 对于已合并的 pull request，聚焦：PR 为何存在、哪个区域发生变化、推进或关闭了哪些 issue，以及上下文中出现了哪些验证证据。
12. 对于生产部署，聚焦：什么到达生产环境、部署的 SHA、environment、workflow run，以及验证证据。
13. 不要超出 workflow 和源事实去过度声称成功。

适用边界 · 注意事项

• 未在 CI 中运行，或 `bm ci collect` 尚未生成 `.github/basic-memory/project-update-context.json` 时。
• 不准备使用 Basic Memory / `bm ci publish` 流程时。
• 需要生成营销宣传文案、逐 commit changelog 或自由创意文本时。