catchup

从当前状态出发，以人的视角帮助他们快速跟上进度，而不是依赖记忆。

目标

catchup 是让失去上下文的人重新进入项目的入口。漫长的 Agent 工作周期中，Agent 创造新词、重命名文件、运行实验和做出调用的速度，远快于项目负责人跟进的速度。在任何下一步行动变得有意义之前，必须先恢复负责人的心智模型。catchup 读取项目的实时状态，并生成一份简报，让完全没有上下文的人也能据此行动。它会在决定下一步之前运行：catchup 还原地图，让决策从事实出发，而不是基于对事实已经过时的记忆。

工作流

1. 只读取实时状态：近期文件修改时间、git 日志和差异、计划与状态文档、re0-memo 备注、任务看板。绝不要只根据对话记忆生成简报——发生偏差的正是记忆。
2. 以人最近一次参与为锚点（他们最近一次发言、判断或提交）。此后的所有内容都是变化；此前的内容则视为已知，不再提及。
3. 按决策顺序组织内容，而非按时间顺序：
   • 需要你处理——只有人才能做出的决定、判断或提供的输入；每项都要足够完整，无需打开其他文件即可采取行动。
   • 你离开期间的变化——说明结果，而非过程。“计划的评分规则已被替换”胜过“我进行了三轮分析”。
   • 新词——列出自他们最近一次参与以来创造或赋予新义的每个术语，每个术语单独一行，并注明出处。跳过他们自己已经使用过的术语。
4. 首次出现时解释：简报中出现的任何项目专用术语，都要在首次出现时附上通俗易懂的简短说明，即使后面还有术语表章节也不例外。
5. 默认保持简短（一屏以内）。每个部分结尾都提供深入了解的选项，而不是一次性展开所有内容。

规则

• 以状态为依据：每项陈述都必须能追溯到人可以打开的文件、提交或产物。不要说“正如我们讨论过的”。
• 对项目只读。catchup 只生成简报；不修复、不重命名，也不做决定。
• 优先提出请求。把唯一需要人回答的问题埋起来的简报，就是日志。
• 说明结果，而非过程。叙述 Agent 的工作过程属于自述，不是简报。
• 对已解决的事项保持简略：已结束的决策和正常的指标只用一行说明，或完全不提。
• 诚实地说明完成情况：“完成”意味着已经核实完成；“已移动”不等于“已协调”；要明确说明是哪一种。
• 不要重新解释有证据表明人已掌握的术语（他们先前使用过的术语）。

验证

完成前：

1. 以初次阅读者的视角通读简报：每句话都不应依赖空档期之前的记忆，也不应包含未解释的新造术语。
2. “需要你处理”中的每项内容，都应无需打开其他文件即可采取行动。
3. 每项陈述都有可核查的来源（文件、提交或产物路径）。
4. 内容控制在一屏以内，提供展开选项，而不是直接展开所有内容。