问题
DevLog 把任务派发给 coding agent，但一次真实的 agent 运行很少是"单一不透明的一步"——尤其当它由一个多阶段的 skill / workflow 驱动时。今天缺了两样东西，而且这两样会叠加放大彼此的痛点：
1. 没有进度可见性。 一个运行中的 session 只暴露一个粗粒度的生命周期状态——看板卡片上是一个彩色小圆点（running/idle/failed）+ "N 分钟前开始"（task-card.tsx），session 页面上是一个 ProcessIndicator（同样的粗状态，sessions/[id]/page.tsx）。你没法一眼看出 agent 是在第 1 步还是第 6 步、是卡住了还是快完成了。想知道，只能点进 session 去读原始输出流。
2. 没有人工介入（human-in-the-loop）的控制能力。 很多 skill 阶段在往下走之前需要人来做决定（批准一个方案、确认一个有破坏性的操作、在几个选项里选一个、对某个阶段签字确认）。今天 agent 没有办法"在关卡处停下来发问"。虽然有一个 Instruct tab（SessionChat）可以给活跃 session 推消息，但：
- 它不是一个结构化的"已阻塞、等待你批准"的状态——看板上没有任何东西告诉你某个任务正在等你；
- 它要求你打开那一个具体的桌面 session，所以一个由看板/远程驱动的流程，没法靠在工单上直接回复来解阻塞；
- 批准之后，也没有"从关卡处恢复 workflow 继续往下"的概念。
对一个主打"速览即行动"的 ADHD 看板来说，最糟的情况就是：一个任务悄无声息地停在那里，等着一个没人知道它需要的确认。
我希望做到
把一个运行中的任务变成一个双向控制面，而不只是一个状态查看器：
A. 进度 / 阶段（读）
- 让 agent 发出里程碑/阶段标记（一种 stdout 约定，或在 worktree 里写一个小的状态文件）；DevLog 解析出最新的那个。
- 在看板小圆点下方、以及 session 头部展示
阶段 3/7 · 正在跑测试。尽力而为：没有标记就退回到今天的圆点状态。
B. 审批关卡（写 / 介入）
- 允许某个阶段声明一个关卡（gate）：agent 暂停，并发出结构化的"等待确认：<问题> [+ 选项]"。
- 把它作为看板上的一等状态暴露出来——比如一个
needs-input 列/徽章——这样能一眼看出哪个任务在等、等的是什么。
- 让人可以在工单上回应（评论/回复，或一个看板操作），并把这个回应回灌给暂停中的 agent，让它恢复并进入下一阶段。
- 关卡 → 回复 → 恢复，如此循环，直到 workflow 达成最终目标。
把"关卡/标记"这套约定做成引擎无关的（一个 stdout/文件约定），意味着 agent 自己永远不需要拥有看板的写权限——由 DevLog 居中转发两个方向。
为什么是这个形态
重点不是为了可观测而可观测。一个多阶段的 agent workflow，只在关卡之间能自主跑；到了关卡，必须由人来掌舵。把这些关卡连同进度上下文（让人知道自己在流程的哪一步）一起摊到工单上，才是让一个长的、skill 驱动的任务真正跑到完成、而不必有人盯着原始 session 日志的关键。
背景
来自一个 fork（loop2zero/DevLog），在驱动长的、基于 skill 的 agent 运行时这个缺口尤为明显。如果你对方向有偏好，我很乐意先做一个 PR 原型。
问题
DevLog 把任务派发给 coding agent，但一次真实的 agent 运行很少是"单一不透明的一步"——尤其当它由一个多阶段的 skill / workflow 驱动时。今天缺了两样东西，而且这两样会叠加放大彼此的痛点：
1. 没有进度可见性。 一个运行中的 session 只暴露一个粗粒度的生命周期状态——看板卡片上是一个彩色小圆点（
running/idle/failed）+ "N 分钟前开始"（task-card.tsx），session 页面上是一个ProcessIndicator（同样的粗状态，sessions/[id]/page.tsx）。你没法一眼看出 agent 是在第 1 步还是第 6 步、是卡住了还是快完成了。想知道，只能点进 session 去读原始输出流。2. 没有人工介入（human-in-the-loop）的控制能力。 很多 skill 阶段在往下走之前需要人来做决定（批准一个方案、确认一个有破坏性的操作、在几个选项里选一个、对某个阶段签字确认）。今天 agent 没有办法"在关卡处停下来发问"。虽然有一个 Instruct tab（
SessionChat）可以给活跃 session 推消息，但：对一个主打"速览即行动"的 ADHD 看板来说，最糟的情况就是：一个任务悄无声息地停在那里，等着一个没人知道它需要的确认。
我希望做到
把一个运行中的任务变成一个双向控制面，而不只是一个状态查看器：
A. 进度 / 阶段（读）
阶段 3/7 · 正在跑测试。尽力而为：没有标记就退回到今天的圆点状态。B. 审批关卡（写 / 介入）
needs-input列/徽章——这样能一眼看出哪个任务在等、等的是什么。把"关卡/标记"这套约定做成引擎无关的（一个 stdout/文件约定），意味着 agent 自己永远不需要拥有看板的写权限——由 DevLog 居中转发两个方向。
为什么是这个形态
重点不是为了可观测而可观测。一个多阶段的 agent workflow，只在关卡之间能自主跑；到了关卡，必须由人来掌舵。把这些关卡连同进度上下文（让人知道自己在流程的哪一步）一起摊到工单上，才是让一个长的、skill 驱动的任务真正跑到完成、而不必有人盯着原始 session 日志的关键。
背景
来自一个 fork（
loop2zero/DevLog），在驱动长的、基于 skill 的 agent 运行时这个缺口尤为明显。如果你对方向有偏好，我很乐意先做一个 PR 原型。