GTD · update（状态更新 / 回报现实）

视角：David Allen，AI-native 改良。Update 处理的不是「新东西进系统」，而是现实已经变化：某个下一步做完了、等待的人回了、项目事实变了、日程细节确定了、承诺取消了。可信系统必须跟现实同步，否则它很快就会重新变成大脑里的负担。

加载与边界

• 清单边界和动作权限：先读 references/list-definitions.md。
• 涉及 hard landscape / 日历改动：读 references/capability-map.md。
• 涉及项目成果或下一步不清：按需读 references/clarify-decision-tree.md 和 references/natural-planning-model.md。
• 自动化边界：明确完成、明确等待回应、明确文本纠错可自动更新；多匹配、会删除整个项目块、日历事件无法唯一识别时问一句。

何时跑

• 用户说「做完了 / 搞定了 / 已买 / 已发 / 已确认 / 已经约好 / 对方回了」。
• 用户汇报项目进展：「我和家庭成员聊完了，已确认安排边界」。
• 用户纠正既有状态：「不是周三晚上，是周三中午 13:30 起飞」。
• 用户取消或降级承诺：「这个先不做了 / 不用跟了 / 这个项目关掉」。

与其他命令的边界

• 新输入 / 新承诺 → capture/SKILL.md。
• inbox 里的未理清项 → clarify/SKILL.md。
• 机械结构卫生（孤儿、重复、stalled 扫描）→ organize/SKILL.md。
• 此刻选做什么 → engage/SKILL.md。
• 方向/项目是否还值得 → review/SKILL.md。

Update 只做一件事：把用户刚报告的现实变化同步到 memory/gtd/ 和真实 hard landscape。

工作流

1. 读相关清单再改：

• 默认先扫描 next-actions.md、projects.md、waiting-for.md。
• 若涉及日期 / 时间 / 地点 / 航班 / 会议 → 先读外部 calendar provider；全部不可达时读 calendar.md 兜底。
• 若涉及项目支持事实 → 按需读 reference.md。

1. 判定 update 类型：

1. 匹配规则：

• 只有一个清晰匹配项 → 直接更新。
• 多个相似项、会删除整个项目块、或日历事件无法唯一识别 → 先问一句短问题，不猜。
• 删除清单行是 GTD 闭环，不是删除文件；本命令可直接删除明确完成的行动行。
• 不把「已完成」留成打勾历史；活清单只保留仍需关注的承诺。

1. 推进项目：

• 已完成行动属于某个 project 时，读该 project 块。
• 若期望成果已达成且没有仍需推动的下一步 → 删除整个 project 块。
• 若项目仍未完成 → 从新事实中起草一个当前最合适的 next-action，并把 project 的下一步指针更新到新行动。
• 如果新下一步需要用户价值判断或信息不足 → 不硬造，列出缺口并问一句。

1. 日历 update 契约：

• 外部 calendar provider 可达时，它是 hard landscape；更新成功前不得声称已写入。
• 能唯一匹配现有事件 → update event。
• 找不到现有事件但有标题 + 日期 + 开始时间 → create event。
• 缺关键字段或可能重复 → 问缺失字段，不写猜测日程。
• 全部外部 provider 不可达 / 失败 → 写 calendar.md 兜底并说明「未写入外部日历」。

1. 验证：

• 改完后检索对应关键词，确认旧行动 / 等待项已消失或新事件 / 新行动存在。
• 必要时跑 scripts/gtd_status.sh 看 dashboard。
• 回报只说关键变化，不转述整张清单。

输出格式

简短输出三件事：

1. 已更新：改了哪张清单 / 日历。
2. 现在剩什么：项目的新下一步、还在等谁，或确认已闭环。
3. 验证：说明已检索或读回确认。

质量检查

• [ ] 先读清单再改，没有凭记忆更新
• [ ] 区分了新输入 capture 与现实变化 update
• [ ] 已完成行动从 next-actions 删除，不留打勾历史
• [ ] waiting-for 回应已重新理清，不再挂在等待清单
• [ ] 项目仍活着时有新的当前 next-action；项目完成时整个项目块删除
• [ ] 日历更新只在 calendar provider / tool 成功后声称完成
• [ ] 多匹配或高风险删除时问一句，没有猜