todo-execution

name	todo_execution
description	待办执行的思考方法论。面对一个该做的待办时，怎么判断下一步、怎么推进、何时算收束、卡了怎么办。
version	1.0.0
platforms	[]

待办执行方法论

它不做什么

• 不是按步骤 1-2-3 执行——那是待办清单，不是方法论。
• 不假设待办定义是完美的——执行中发现意图模糊是常态，处理模糊是能力的体现。

进入一个待办时

先回答三个问题（不用调工具，基于已加载的笔记和上下文想）：

• 它最终要产出什么？ 不是"完成"，是"能看到什么具体的东西"（一段代码、一份数据、一条消息发出去了）。
• 意图模糊的地方？ 该现在澄清还是带着合理假设往下走？——大部分时候，带着假设往下做比停下来问更高效。
• 这事该我做还是该派给兄弟实例？ 如果是项目协作（source=project:xxx），查一下角色分工。

推进中：每一步前问自己

• 这一步"做完了"长什么样？ 如果你没法判断"做完了"，说明它太大或太模糊，该拆。
• 不确定的地方：是阻塞（必须现在解决才能往下走）还是可以带假设推进？——能带假设的别停。
• 卡了 15 分钟没进展：是技术卡点（查资料/问人/换方案）还是方向错了（停下来想，或 todo_note add 记录卡点后 rest）？

何时算完成

对照进入时定义的产出标准，不是"步骤走完了"。

• 如果发现产出标准本身不对——回去改待办定义（todo update），不要假装完成。
• 完成后用 todo_note add 记一句最终产出，让下次醒来的人（你自己）一眼看到结论。
• 做不完时：todo(action="update", status="paused")——别让 in_progress 长期挂着。要么 done 要么 paused。过期 in_progress 在提示卡里标 ⚠️，是下次醒来最高优先处理目标。

拆解的判断

什么时候该拆（todo update 设 parent_id）：

• 待办有 3 个以上明显独立的子步骤
• 各子步骤可以用不同的工具/方式推进
• 整体跨度超过一个 session 能做完的量

什么时候不该拆：

• 子步骤之间强依赖、必须严格按序做
• 两步就能做完的——直接做，别过度规划

何时该放弃

诚实面对。如果一个待办连续多次醒来都没法推进，问自己：

• 是条件没满足？（等的东西等到了吗？没有就该 cancelled 并说明）
• 是方向本身错了？（承认错误比硬撑好——cancelled + note 写清理由）
• 是我能力做不到？（明确说出来，用 express_to_human 请求协助）

回避一个待办不丢人。假装在推进才丢人。

反模式

• "看一遍待办定义就开始敲代码"——没想清产出标准就动手
• "卡了不记录，硬扛到 timeout 一个产出都没有"
• "步骤全打勾就 done，不管产出质量"
• "每次醒来都重新理解一遍待办"——笔记里的上次进度是权威的，接着它走
• "创建一堆子待办但不推进"——拆解是为了做，不是为了看起来有计划