三条使用反馈：陈旧待办浮现（is:stale） / 同前置动作合并 / 首次上手扫欠账

[LinnnnYue]

三条使用反馈：陈旧待办浮现 / 同前置动作合并 / 首次上手扫欠账

使用者背景：INFP，长期并行多个工作区（DSH 里 16 个工作区、115 个会话），
典型失败模式是「想法多、开枝散叶快、没设截止时间的事永远沉底」。
全局待办插件是目前最贴合这个场景的工具，用下来有三点体会，按「对我价值 ÷ 实现成本」排序。

---

① 建议：按「静默天数」浮现陈旧待办（is:stale）

现状

面板已有 is:overdue / group.overdue / meta.overdue: 逾期 {n} 天
（lib/client.js，summary.overdue / filter.overdue / counts.overdue）。

但 overdue 的前提是「设了 dueAt」。

问题

对 INFP 型使用者，绝大多数待办在登记时根本不会设截止时间——
因为当时只是「记一下，别忘了」，并不确定什么时候做。

结果就是：这类待办永远不逾期，也永远不浮现。

实测观察：我今天登记了 5 条，全部没设 dueAt。其中 3 条已经因为「都在等同一个动作」而具有时间压力，
但面板上它们和三天前的陈条目看起来一模一样。

建议

updatedAt 字段已经存在（lib/model.js 里 todo.updatedAt = now，多处维护），
不需要新字段，只需要：

1. 一个派生判据：now - updatedAt > N 天（N 可配，默认建议 7 或 14）
2. 一个过滤器：is:stale，与既有 is:overdue 同形（lib/client.js 的 search.hint 里已经列了语法示例，加一项即可）
3. 一个分组或徽标：类似 meta.overdue 的 meta.stale: 静默 {n} 天

为什么值得

overdue 服务「有明确期限的事」；
stale 服务「没期限但搁太久了」—— 这两类在真实使用里比例大概是 1:9。

而且它天然接进 GET /report?days=7：周报里加一节「搁置最久的 5 条」，比任何提醒都有效。

需要注意的边界

• updatedAt 会被 note / update 刷新 —— 这未必是想要的。
  「追加了一条进展」不等于「这条重新活跃了」。可能需要在写 note 时不更新 updatedAt，
  或者引入一个独立的 lastTouchedAt。这一点我拿不准，取决于你对 updatedAt 语义的定义，
  所以只提出来，不主张。
• 已 cancelled / archived 的条目不应参与 stale 统计。

---

② 建议：支持「多个待办卡在同一个前置动作」（blocks 或手动分组）

场景（真实发生）

今晚我一次性登记了 5 条待办，其中 3 条都卡在同一个动作上：

#9  测 TRAE 全部 flash/flashx/mimo 的智商与 token 成本比   ← 等 DSH 重启（白名单生效）
#10 重启 DSH 让 mneme 新模型配置生效并验证                 ← 就是重启本身
#11 重启 DSH 让 PATHEXT 去掉 .JS 生效                      ← 等 DSH 重启

问题不是「忘了记」，而是「记完更乱」：
用户过几天回来，看到三条各说各的「重启」，反而更容易漏掉。
当时我手动合并成一条会更清楚，但合并后就丢失了三件事各自的验收标准。

建议

给 global_todo_capture / add 加一个可选字段，让多条待办声明它们共享同一个前置动作。

两个可能的形态，我不确定哪个更合你的设计方向：

形态 A：blocks 字段

{ "title": "测 TRAE ...", "blocks": ["重启 DSH"] }
{ "title": "mneme 新配置生效", "blocks": ["重启 DSH"] }

面板把 blocks 值相同的条目聚成一组，组头显示前置动作，组内是各自的验收标准。
前置动作做完一次 → 整组推进。

形态 B：不新增字段，只做「手工分组」
在面板上把几条拖进同一个组（但 ROADMAP 的 Later 里已经把「drag to reorder」列为待议，
说明拖拽涉及 position 字段和分组的交互，可能成本不低）。

为什么值得

「等重启 / 等对方回复 / 等某个决定」是唯一可枚举的阻塞原因，
它们天然是共享的。现在的模型里每条待办都是孤岛，必须靠人脑记住「A 和 B 是同一件事的两个面」。

与现有设计的关系

• ROADMAP 的「Not there yet」列了「Auto-running todos」明确不做 —— 这个建议不违背它：
  它不自动开工，只是把共享的阻塞原因显式化。
• 「Multi-list / projects」被 defer 了（理由是「global single list 是当前身份」）——
  这个建议也不要求多列表，它是在同一个列表内加一层分组维度。

---

③ 建议：首次安装时给一次「扫历史欠账」的上手动作

现状（我核对过）

• lib/index.js 的 GUIDANCE 写得很完整：「主动记，不必等用户开口」「一轮收尾发现还有一步没做」「不要记本会话能做完的」等，这部分设计得非常到位；
• docs/QUICKSTART.md 有清晰的 7 步：安装 → 打开面板 → 加第一条 → 交给一个对话 → 待确认 → 数据在哪 → 接下来；
• 但这 7 步里没有「把过去散落在各个会话里的欠账扫一遍」这一步。

代码里也没有任何 first-run / onboarding 相关实现（grep onboard|firstRun|welcome|首次 无命中）。

问题

插件的价值在安装后的第一周才体现，而第一周恰好是「新工具还没融入习惯」的阶段。
此时清单是空的，用户（尤其是我这种）会想「好像也没什么可记的」，然后放着不管。

实际上那时候最该做的事，是把几十个旧会话里悬空的事一次性捞出来——
一旦清单有了 10 条真实的欠账，这个工具对用户就立刻「有内容」了，习惯才建立得起来。

建议

不一定要写代码，哪怕只在 QUICKSTART 里加一步「3.5 把过去的欠账扫一遍」 也有价值：

## 3.5 把过去的欠账扫一遍（建议在第一天做）

新装的清单是空的，这会让人误以为「没什么可记」。
实际上你过去几十个会话里，大概率躺着「改了一半没验证」「等某个决定」这类事。

做法：开一个新会话，把下面这句丢给它 ——

> 扫一遍我最近的会话，找出「没做完但没登记」的事，用 global_todo_capture 一次性登记。
> 只报有把握的，宁缺毋滥。别在当前会话里翻，派个子 agent 去扫。

扫完你会得到 10~30 条真实欠账。**这时候清单才有内容，习惯才立得住。**

进一步（可选）

如果愿意多做一点：GET /session?id= 已经能读到会话的 tail（0.12 landed），
理论上可以做一个「读最近 N 个会话的尾段，列出疑似悬空事项」的只读接口。
但这会碰到「主动判断」的边界，可能不符合你「只记不开工」的定位 ——
所以只当作一个想法，不主张实现。

---

最后

插件本身质量很高：跨进程锁、附件健康探测、去噪规则（规范化标题 + 72h Dice 0.8 + 7 天内完成去重）、
steps 随派发提示词传递 —— 这些细节能看出是真的在用、真的踩过坑。

上面三条里，① 和 ② 是需要动代码的，③ 主要是文档。
如果只能做一件事，我推荐 ① —— 它对「不设截止时间」的使用者收益最大，且 updatedAt 现成。

作者：LUgABeEEE · 使用者反馈（DSH 0.2.1-rc.3 / dsh-global-todo 0.19.0）