MemoFlow · Task 模块开发笔记

按版本记录 Task 从模板与实例、KR 测量，到 TaskPlan / TaskOccurrence 的方案。

#blog #growing #dev

Task 模块目标

我想做的不是只有“标题 + 完成按钮”的 Todo，而是能够管理一次性和重复行动的 Task。例如每天早上跑步、某个时间点抢票，或者一项持续几个月的学习计划。

任务可能有时间点、时间段、全天安排和提醒；部分任务还会关联 Goal 的 Key Result。

第一版决定采用 TaskTemplate + TaskInstance。模板负责一项任务的长期定义、时间、重复规则和提醒；实例记录某一天真正需要执行的那一次。

这样做是因为“每天八点跑步”只有一套重复规则，但周一与周二的完成情况必须分别保存。若直接把一个 Todo 反复改成“已完成/未完成”，就失去了每次执行的历史。

时间模型先考虑一次性、每日、每周等重复方式，以及开始时间、结束时间、全天和提前提醒。子任务先采用简单 Checklist；层级任务和复杂依赖图可以探索，但不希望它们影响最基本的创建与完成流程。

现在 Task 要与 Goal 的 KR 联动。最直接的实现是：模板绑定一个 KR 和固定贡献值，实例完成时自动添加 GoalRecord。

这个方案对“每完成一次阅读就累计一篇”比较合适，但对下面的例子不成立：

KR 是“考试最高分达到 90 分”，Task 是“每月参加一次考试”。

参加考试不等于考了 90 分。只根据模板预设值自动增加记录，会把完成动作错误解释成指标结果。

这里需要明确区分两种模式：能够预设的固定贡献，以及需要用户输入实际结果的测量。对于第二种，完成时应让用户填写真实分数，由 Goal 判断怎样更新 Max、Average 等指标。确认输入可以减少误触，但不能因为有确认弹窗就假设所有撤销和重复提交问题都消失了。

这版把 Template / Instance 进一步整理成 TaskPlan / TaskOccurrence。名称变化的重点，是把“计划定义”和“执行事实”明确分开。

TaskPlan 定义行动名称、一次性或重复时间安排、提醒策略、Goal 关联以及计划是否继续生效；Occurrence 则记录一次具体的执行，包括安排时间快照、Checklist、真实执行时段和执行结果。

两类状态也不该共用一套枚举：

尤其要注意：超过时间不等于用户已经确认 Missed。Overdue 可以作为计算出来的提示，但不能偷偷覆盖用户的执行事实。

我希望 Task 页面回到“今天做什么”这条主线。首页优先显示 Today 和 Plans；未来日期的浏览可以交给 Schedule / Calendar，而不在 Task 里再做一整套日历。

新建临时任务也应该足够快：输入标题就可以形成今天的简单任务，详细的重复规则、时间安排和 Checklist 在需要时再展开。Occurrence 的完成、跳过和检查详情使用更紧凑的操作入口。

Goal/KR 联动统一成三种用户可理解的选择：仅关联、固定值自动记录、完成时输入测量。执行事实仍由 Task 保存；需要影响 KR 时，通过受控的跨模块结算交给 Goal。这样 Task 不必为了支持目标进度而承担另一模块的计算规则。