# 检查点确认流程

## 触发条件

- 定时提醒到达
- 用户主动汇报“盒子完成了”或“来个检查点”

## 检查点问题

始终先复述本盒子的预期成果，再让用户汇报实际结果。

涉及“距离截止还有多久”“下一盒几点开始”“还剩多少分钟”时，先用用户当前本地时间和任务的绝对时间重新计算，再输出结论；如果当前时间不可靠，优先直接说绝对时间，不要口算。

四档完成度只是内部判断框架，不要机械地每次都把 A/B/C/D 原样甩给用户。

必要时可以自然地问：

- “这一盒大概完成了多少？”
- “已经收尾了，还是只推进了一半？”
- “是差一点结束，还是几乎没开始？”

内部可参考这四档完成度：

- A. 100%，按计划完成
- B. 80%，基本完成，尾巴可并入下一盒
- C. 50%，需要延长
- D. 未完成，需要诊断原因

## 根据结果处理

### A / B

- 确认完成
- 给一句符合文风的反馈
- 提醒休息和下一盒开始时间
- 更新滴答清单任务状态，优先用 `complete_task`
- 完成后立刻用 `get_task_by_id` 回读当前状态

### C

- 问是否延长 10-15 分钟，还是拆分剩余部分
- 用 `extend_box_duration()` 或重排后续盒子
- 更新检查点提醒，并同步用 `update_task` 回写任务时间信息
- 更新后用 `get_task_by_id` 回读

### D

追问阻碍属于哪一类：

- 任务过难
- 分心
- 没动力
- 被更紧急的事打断
- 忘记开始

然后再提供补救方案，而不是只做情绪安慰。

默认先用自然语言接住用户，再做完成度判断，不要像质检流程。
如果要说“还有 X 分钟”，先说清楚当前本地时间和目标时间；不要把错的倒计时说得很确定。

## 记录闭环

在任务备注或后续复盘里保留这些信息：

- 预期成果
- 实际完成度
- 未完成原因
- 新约定时间

如果要把任务移动到其他清单，使用 `move_task`，不要假设更新任务本身就能完成跨清单移动。

## 状态判定约束

判断“当前任务是否已完成”时，只看当前实例的显式完成状态。

- 可以参考：`status`、`isCompleted`、`completed`
- 不要仅凭历史 `completedTime` 或类似字段，就把当前任务标记为已完成