cmdr-mcp 0.4.0 → 0.6.0

package/docs/dashboard-plan.md

@@ -0,0 +1,327 @@
+# cmdr 内置 Dashboard 方案
+
+状态：首版已在 `feat/dashboard` 分支实现，基于 `main` 的 `9c95e8f`。本文保留设计约束与验收范围；实际工具、容量与操作方式见[看板使用说明](dashboard.md)。真实模型宿主的唤醒仍需独立验证。
+
+## 1. 目标与已确认的约束
+
+为本机用户提供一个由 cmdr 运行时内置的 Dashboard，查看不同小队的任务与成员状态，并直接回答指挥官提出的问题。看板随原生插件或 setup 安装的完整运行时提供，二者共用同一套实现。
+
+- 使用 React；样式、布局、导航和常规交互由 cmdr 维护并随完整运行时分发。
+- Agent 通过工具操作任务数据、报告进展、设置问题；常规流程无需编写或修改 HTML。
+- 同一个 Dashboard 展示多个小队，通过页面导航切换。每个小队的数据独立，当前指挥官负责管理本小队。
+- 简单数据结构难以解释的问题，允许 Agent 编写原始 HTML，通过工具发布为任务或问题的补充展示块。
+- 页面根据数据局部更新，保持稳定的组件与 DOM 节点。普通进展变化不触发整页刷新。
+- 使用常规 React 状态管理，不为连续交互引入专门的状态恢复协议、更新握手、延迟替换机制或 HTML 交互 SDK。
+- 保持本机、单用户、已有 Agent 会话的范围。现有任务归属、取消、接管和宿主唤醒语义继续有效。
+
+## 2. 用户看到的页面
+
+一个本地入口对应当前 `CMDR_HOME` 管理的数据。不同数据目录之间不自动聚合；多个宿主配置目录可以共享同一个 `CMDR_HOME`，此时共用看板，不按宿主 profile 再拆分数据。页面应能查看当前连接的数据目录，便于区分多套安装。
+
+左侧为小队列表，显示名称、执行中任务数和待用户回复数。中间展示选中小队的四列任务看板，底部固定成员／活动坞；右侧常驻待确认事项与用户留言框。顶部使用一行指标，任务详情替换中间看板而不遮挡答复表单。未选中小队的摘要继续更新，便于发现需要处理的问题。
+
+| 区域 | 内容与行为 |
+| --- | --- |
+| 任务看板 | 展示待派发、待接单、执行中、阻塞、已完成、失败与取消的任务；进入详情查看说明、执行记录和成果 |
+| 待确认事项 | 展示问题、关联任务、选项、补充输入和提交状态；复杂说明可以附带 HTML 展示块 |
+| 成员状态 | 展示角色、当前任务、最近报告、连接状态、监听健康与自动响应能力；有证据时展示唤醒投递状态 |
+| 活动记录 | 展示任务派发、接单、进展、终态及用户决策，便于追溯 |
+
+页面明确区分连接、监听、唤醒投递和工作状态：离线不代表任务停止，监听健康不代表模型已开始处理，宿主接受唤醒不代表任务已接单，用户答案已接收或已读不代表指挥官已处理。没有可靠依据时显示未知或最近观测时间，不生成推测性的完成百分比。
+
+用户切换小队只改变页面选择，不改变任何 Agent 的成员关系或 commander 身份。看板数据归属小队，指挥官更换会话或发生接管后，任务、问题和回复继续保留。
+
+首版不提供通过拖动卡片直接修改执行状态的能力。用户可以查看进展、回答问题、向指挥官留言；任务执行状态由实际协作事件驱动。留言只复用现有消息队列，不增加任务管理入口。
+
+## 3. 职责与运行结构
+
+| 层次 | 职责 |
+| --- | --- |
+| Agent / MCP 工具 | 指挥官维护计划、任务说明和问题，派发工作；执行者报告接单、进展与结果 |
+| daemon / SQLite | 保存任务、问题和展示块，校验操作权限，维护执行关联，路由用户答复并发布事件 |
+| 本地 Web 接口 | 提供内置静态资源、状态快照、事件订阅和用户答案提交入口 |
+| React 页面 | 渲染数据，管理当前小队、展开项和表单草稿，提交用户输入 |
+
+已确定采用单 daemon 进程：按需启动一个默认监听 `0.0.0.0`、由系统分配端口的 HTTP 服务，同时提供静态资源和业务接口。浏览器通过 HTTP 与 SSE 访问 daemon；Agent 继续使用现有 MCP / Unix socket 链路。两种入口共用业务方法、SQLite 事务和提交后的事件，不维护额外的前端数据库或独立 Dashboard 服务进程。
+
+HTTP 层采用 Hono 路由与 `@hono/node-server` 适配器，运行在现有 daemon 中。使用内置 JSON 请求上限和 Cookie 辅助函数，以 `streamSSE` 提供浏览器通知；连接缓冲上限、鉴权、CSP 和关闭清理由看板维护，不引入独立服务或通用控制器层。
+
+HTTP 模块负责会话与请求校验、调用业务方法和返回结果，不直接修改数据库，也不将本机用户伪装成 Agent。业务操作提交成功后才发布变更通知。React 构建为随完整运行时发布的静态资源，由正在运行的 daemon 从自身运行时目录提供，不需要 SSR 或额外前端运行进程。
+
+使用 `cmdr dashboard` 打开看板，`--no-open` 返回 `127.0.0.1` 与本机非回环网卡 IPv4 的多个访问地址。每个地址使用独立且绑定来源的 60 秒一次性凭证；自动打开本机地址不会消耗局域网凭证。重新运行命令时刷新网卡地址及 Host 白名单，写请求 Origin 必须与当前访问地址一致。入口负责启动或定位本地服务并打开页面。关闭浏览器只结束查看，不关闭小队、不取消任务，也不停止成员监听。
+
+setup 安装使用其返回的稳定 CLI 路径打开看板，沿用启动器绑定的 `CMDR_HOME`；原生插件使用对应安装的 CLI。资源定位不依赖当前工作目录、skill 目录或 npx 临时缓存。仅通过 `npx skills add` 安装技能不会安装运行时或启用看板，仍需已有可用集成或完成 setup。
+
+浏览器是本机用户的操作界面，可查看当前数据目录中的各小队；Agent 的写权限仍由 daemon 按身份、角色和小队归属校验。Web 接口不暴露任意 RPC 转发，写请求校验看板会话凭证与来源，HTML 展示块不能取得这些凭证。
+
+服务生命周期沿用 daemon 管理：重复打开复用同一 HTTP 服务；活跃的 Dashboard 连接计入使用状态，仅监听端口不阻止空闲退出；关闭页面后恢复原有空闲退出判断。daemon 停止时显式关闭 SSE 连接和 HTTP 服务，避免长连接阻塞退出。
+
+## 4. 数据模型
+
+### 4.1 任务 Task
+
+现有 command 跟踪已派发工作的交付与执行，看板还需要尚未派发的计划及已完成历史，因此增加独立任务记录。
+
+任务的最小信息包括：稳定 ID、小队 ID、标题、说明、验收条件、排序位置、关联执行记录、可选展示块以及创建和更新时间。负责人使用稳定成员 ID 表达，具体执行记录仍保留实际会话和 command ID。
+
+任务与执行的关系如下：
+
+- 指挥官创建任务时，它可以尚未派发、尚无负责人。
+- 派发时关联现有 command；接单与终态继续由 `report + reply_to` 推进。
+- 重新分配保留同一个任务，关联新的 command，继续遵守原有取消与替代任务放行规则。
+- Task 保留执行摘要和关联历史。消息保留期清理不能让看板上的任务或终态凭空消失。
+- 执行中状态来自 command 和关联报告，不提供另一套任意修改为“完成”的路径。
+
+| 看板状态 | 依据 |
+| --- | --- |
+| 待派发 | Task 已创建，没有当前执行记录 |
+| 待接单 | command 为 queued / read；已读可作为附加标记 |
+| 执行中 | 当前执行者已发送关联的 working 报告 |
+| 阻塞 | 当前执行者已发送关联的 blocked 报告，或替代执行仍受取消门控 |
+| 已完成 / 失败 / 已取消 | 当前有效执行链产生对应终态 |
+
+“待用户确认”作为问题关联产生的提示，不直接改写底层 WorkState。问题需要用户回复不等于当前执行者已停止；要求停止正在进行的工作时，仍使用现有合作式取消机制。新执行记录尚未放行时，也不能用前一条执行的终态把整个任务误标为结束。
+
+维护状态和执行摘要时，应与对应消息、事件在同一事务中更新；不引入依赖后台扫描才能保持正确的第二套状态机。
+
+### 4.2 用户问题 Question
+
+首版支持单选、多选、文本输入和确认／拒绝；选择类问题可以附带补充说明。控件由插件根据类型渲染，不让 Agent 描述组件树或编写常规表单 HTML。
+
+最小信息包括：稳定 ID、小队 ID、可选任务 ID、题目与说明、类型、带稳定 ID 的选项、内容版本、状态、可选展示块及答案。
+
+问题流程为：
+
+`待回复 → 答复已接收 → 指挥官已处理`
+
+另支持撤回问题。撤回不等于用户拒绝；“已处理”需要指挥官明确记录处理结果，不能因为读取消息就自动成立。
+
+题目、选项或影响决策的说明修改时增加内容版本。用户提交携带问题 ID、版本和提交 ID；版本不匹配时保留用户输入并提示核对新内容。普通任务进展不改变问题版本。
+
+用户答案提交按提交 ID 去重。同一次提交重试返回原回执；不同内容不能复用同一提交 ID。首版只接受问题当前版本的首个有效答案；已回答的问题再次征询需创建新问题，不增加复杂的多方编辑机制。
+
+### 4.3 HTML 展示块 Artifact
+
+展示块包括稳定 ID、小队 ID、标题、HTML 内容及内容版本，可以关联到任务或问题。首版保存当前内容，不建设完整的成品版本管理系统；问题提交时保存题目、选项及关联 HTML 说明的快照，满足答复追溯需求。
+
+任务、问题和 HTML 的保存边界独立于短期事件日志，不使用消息 TTL 自动删除。首版每小队每类记录最多 200 条（含归档），每任务最多 100 次执行；单份 HTML 最大 256 KiB，每小队当前 HTML 合计最大 8 MiB。归档不删除记录，显式 `purge --all` 会连同协作数据一起清除持久数据，详见[容量与保留](dashboard.md#容量与保留)。
+
+## 5. 工具操作与权限
+
+本分支实现以下操作语义，尚未发布；完整参数和用例见看板使用说明。
+
+| 操作 | 建议接入位置 | 权限与约束 |
+| --- | --- | --- |
+| 创建、编辑、查看、归档任务 | `task` | 当前指挥官管理本小队；执行状态不能通过编辑任意覆盖，未完成执行不能用归档释放归属 |
+| 派发与重新分配 | 扩展现有 `send` 的任务关联 | 复用角色校验、task_key、取消与替代任务门控 |
+| 接单、进展与终态 | 现有 `report` | 执行者针对其拥有的 command 使用 reply_to；同步相关 Task |
+| 创建、修改、撤回用户问题、记录处理结果 | 扩展 `ask` 的用户目标和管理操作 | 当前指挥官管理本小队的问题；原有 executor 向 commander 提问的行为保留 |
+| 发布或更新 HTML 展示块 | `artifact` | 当前指挥官发布本小队的说明内容；不开放页面布局或主应用脚本修改 |
+| 读取用户答复 | 现有 `read` 与问题查询 | 答复送入小队的稳定指挥官收件箱；只有当前指挥官消费该收件箱 |
+
+工具优先接收结构化参数。首版 HTML 工具直接接收内容，保存成功后再发布；不监听 Agent 文件的每次写入，也不直接让浏览器读取任意本机路径。
+
+本分支暴露九个 MCP 工具，新增 `task`、`artifact` 并扩展 `ask` 和 `send`。schemas、daemon、MCP/CLI、角色技能、工具发现及离线包验证同步更新；doctor/setup 的 `probeMcp` 按当前 schema 工具集合检查。
+
+Agent 使用说明以 `plugins/cmdr/skills/cmdr/references/commander.md` 和 `executor.md` 为角色协议源，构建会同步生成兼容的 `cmdr-commander`／`cmdr-executor` 技能正文。新增看板操作在这些源文件中维护，并同步主技能、命令和安装说明，避免 setup 与原生插件各有一套协议。
+
+现有 `list` 不暴露 command 正文的约定保留。Dashboard 的任务详情使用面向本机用户的专用查询，Agent 的新增任务查询遵循小队权限，不借扩展 `list(full=true)` 绕过原有约定。
+
+留言使用单独的 `POST /api/messages` 入口，校验看板会话、同源请求、小队与文本长度。daemon 以用户身份将 `info` 消息送入相同的指挥官角色收件箱，设置 attention 并复用已有通知／唤醒。提交 ID 在原消息保留期间去重，沿用消息 TTL 与队列容量；它不创建 Question、处理回执或任务。浏览器按小队保留草稿，发送失败使用原内容与 ID 重试。只有问题答复具有独立于消息 TTL 的持久化决策记录。
+
+## 6. 用户答复如何回到指挥官
+
+### 6.1 答案入队与处理回执
+
+1. 指挥官创建问题，daemon 保存并发布事件，页面显示内置表单和可选 HTML 说明。
+2. 用户选择或输入后明确点击提交。控件变化只修改草稿，不立即发送。
+3. daemon 校验小队、问题、内容版本与提交 ID，在一个事务中保存答案并写入指挥官角色收件箱。
+4. 页面收到持久化成功的回执后显示“答复已接收”；超时或失败保留草稿，以同一提交 ID 重试。
+5. 答案入站消息具备明确的 attention 标记，通过现有 actionable 与宿主唤醒机制通知当前指挥官。仅在事务提交后通知；重复提交返回原回执，不再产生一条消息。没有健康唤醒能力时保留答案，如实显示等待、监听异常或 manual 状态。
+6. 指挥官读取答案，决定如何调整任务或回复执行者，再显式记录问题已处理及简短结果。
+
+用户来源由 Web 提交入口在服务端确定，不允许 Agent 在普通消息参数中自行声明“用户已确认”。现有 `send(type=answer)` 用于 commander 回答 executor 的 ask，用户答案需要独立的内部入站语义，不能绕过校验伪装成该调用。
+
+角色收件箱在没有指挥官时仍保存答案，后续接管者可以继续处理。浏览器切换小队不会改变已经发出的提交所属小队。用户的答复只应用于具体问题，不自动转化成额外任务授权。
+
+### 6.2 复用现有宿主唤醒
+
+目标是让轻量监听进程等待事件，再由宿主调度已有 Agent 会话。Unix socket、HTTP 长连接或心跳只能维持通信与健康检查，不能单独唤醒已经结束当前轮次的模型。Dashboard 的 SSE 仅服务浏览器；Agent 继续走现有 MCP / Unix socket 与宿主适配器，无需另建 Agent SSE、WebSocket 或无限前台 `poll` 通道。
+
+以下能力已在基线代码中实现，不列为 Dashboard 的新增基础设施：
+
+| 宿主 | 当前唤醒路径 | 等待与恢复方式 |
+| --- | --- | --- |
+| Codex | daemon 优先使用 app-server proxy，不可用时检查 `codex queue` 能力 | 注册 auto 并确认健康后可结束空闲轮次；复用忙时合并、持久化唤醒请求与投递核对 |
+| Claude Code | 宿主 Monitor 运行内置 watcher，每行输出产生原生通知 | 正常等待时保持监听，过期或退出后重新启动；仅在支持后台完成通知时使用 `--once` 后备路径 |
+| ZCode | 宿主后台 Bash 运行同一 watcher，输出后退出，由完成通知恢复会话 | 空闲时静默；处理通知后核对后台任务状态并重新启动监听 |
+| 不支持的宿主或无法建立唤醒路径 | 明确为 manual 或监听异常 | 使用现有有界等待／人工继续，不承诺后台自动响应 |
+
+Claude/ZCode watcher 先订阅事件，再检查当前待处理工作，避免启动时遗漏消息；观察本身不消费消息。watcher 每 30 秒续租，租约为 90 秒，同一成员只允许一个有效监听租约。心跳、页面查询和 SSE 重连不应单独触发模型；watcher 检查发现需处理的消息时才输出通知元数据。实际断线或租约过期更新健康状态；daemon 重启导致 watcher 退出，由宿主通知 Agent 重新建立监听。
+
+宿主工具不保证继承 MCP 启动器的环境。当前 `listener.arm.command` 已包含 daemon 的 `CMDR_HOME` 与实际运行时命令路径，必须完整使用该指引，不能省略环境绑定或自行拼接全局 `cmdr` 路径。看板如展示重新监听指引，也直接使用此返回值，防止监听误连另一套数据目录。
+
+报告的唤醒判断使用入队时计算的 `attn`。默认实时事件与回放事件均可能省略 `data`，不能通过 `data.status` 再判断报告是否需要唤醒。`working`／`ready` 和无 attention 的广播保持安静，`done`／`failed`／`blocked`／`cancelled` 等需关注的报告按现有策略通知。长时间没有输出是正常等待状态，不采用定时重连来维持“活跃”。
+
+Codex 的宿主投递复用现有 `requested → accepted → observed` 跟踪与不确定结果核对，不能因超时就盲目重复提交唤醒。该路径的请求状态与 Claude/ZCode 的监听租约含义不同，看板按各宿主已有证据展示，不虚构统一的“模型已唤醒”确认。
+
+### 6.3 阻塞等待、重新监听与恢复
+
+已接单任务可以在等待用户或指挥官答复期间保持归属。watcher 初次检查时，将没有待处理取消请求的 accepted command 记为已知，不因这条未完成任务立即重复通知。因此“已接单 → blocked → 等答复 → 重新监听”不会反复触发同一工作。
+
+- queued 或 read 但尚未接单的 command、未读答案和待处理取消请求仍需通知；取消消息已读但取消请求尚未完成，也不能被忽略。
+- 启动、上下文丢失或收到唤醒后，Agent 使用 `read` 与 `read(recover=true)` 检查消息和未完成工作，优先处理取消，核对实际文件／进程后再继续已接单任务。
+- 指挥官恢复时还需查询本小队“答复已接收但未处理”的问题。`read(recover=true)` 恢复 command，不替代问题查询；答案消息已经读过，也不能使未处理决策丢失。
+- 新任务通过关联的 `report(working, reply_to)` 接单，终态继续关联原 command；用户问题通过显式处理结果结束。消息读取、宿主接受唤醒和任务完成分别记录，不增加 exactly-once 执行承诺。
+- 需要重新启动 watcher 时，先完成消息处理与状态核对，再确认旧后台任务已退出，按宿主提供的 arm 指引操作。Claude 的健康流式 Monitor 无需每次收到通知都重启。
+
+这些规则复用当前恢复和去重语义。Dashboard 新增的是用户问题的持久化状态、答案入站事件及处理回执；关闭页面只断开浏览器，不改变 Agent 的监听、任务归属或取消状态。
+
+## 7. React 更新与多小队状态
+
+### 7.1 通信选择：SSE
+
+选定 SSE，配合普通 HTTP 查询和写请求；首版不同时实现 WebSocket 或传输自动切换。
+
+| 对比项 | SSE | WebSocket | 本看板的判断 |
+| --- | --- | --- | --- |
+| 通信方向 | 服务端向浏览器推送 | 双向消息通道 | 持续通信只需要发送变更通知 |
+| 用户提交 | 使用独立 HTTP 请求与响应 | 可使用消息协议，也可继续走 HTTP | 保留 HTTP 状态码、校验错误和持久化回执 |
+| 连接恢复 | 浏览器 EventSource 提供断线重连机制 | 原生接口需要应用或库处理重连 | SSE 减少连接管理代码；数据恢复仍由应用负责 |
+| 二进制和高频双向交互 | 文本事件流 | 支持文本和二进制双向消息 | 当前没有此类需求 |
+
+这一选择基于交互模式与实现量，不宣称 SSE 在性能或可靠性上普遍优于 WebSocket。SSE 的单向事件与重连行为见 [WHATWG EventSource 标准](https://html.spec.whatwg.org/multipage/server-sent-events.html)；WebSocket 的双向发送接口见 [WHATWG WebSockets 标准](https://websockets.spec.whatwg.org/)。
+
+每个 Dashboard 标签页只建立一个 EventSource，复用它接收所有小队的变更通知，切换小队不新建连接。HTTP/1.x 下浏览器的同源连接数量有限，大量标签页会竞争连接；首版面向一个页面切换多个小队，不为此引入跨标签页连接共享或 HTTP/2 部署。[浏览器连接限制说明](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events#listening_for_custom_events)
+
+静态资源、HTTP API 和 SSE 使用同一来源及会话认证。原生 EventSource 不提供任意请求头配置，采用同源会话 Cookie，无需把长期凭证放在事件 URL 中。流使用 `text/event-stream`、及时输出和低频注释心跳；心跳只维持连接，不触发模型调用。
+
+### 7.2 数据同步：变更通知 + 重新查询
+
+任务、成员或用户问题变化时，SSE 只通知受影响的小队；HTTP 快照是页面数据的依据。前端不根据原始 command/report 日志重建业务状态，也不要求 SSE 精确交付每一条历史事件。
+
+1. 服务端先注册变更订阅，再向浏览器确认事件流已建立；页面在连接打开后获取小队摘要和当前小队快照。
+2. 收到变更通知时，重新获取受影响的摘要或当前小队数据，并合并到 React state。未选中小队仅更新摘要，进入时再查询详情。
+3. 同一资源短时间内的多次通知合并为一次查询；若查询期间又有变化，查询完成后补读一次，避免遗漏。避免同一资源的重叠请求让旧响应覆盖新状态。
+4. 连接中断时保留当前内容并标记连接状态；EventSource 重连成功后重新读取摘要及当前小队快照，无需回放断开期间的全部事件。快照读取失败时保留待刷新标记并重试，不能只等下一次业务变化。
+5. HTML 正文单独按展示块读取，普通任务快照只携带展示块 ID 和内容版本；版本不变时不重新加载 iframe。
+
+daemon 内部继续使用现有事件和事务机制。Dashboard 通知是提交后生成的轻量失效提示，首版无需依赖 Last-Event-ID 建设持久化重放协议；原有 CLI 事件游标与回放语义保持不变。
+
+重新查询只更新 React 数据，不执行浏览器整页刷新。看板观察不消费成员消息，也不会把任务标成已读或接单。通知生成需要覆盖 working/ready 等影响展示的变化，不能只复用用于唤醒模型的 actionable 过滤结果。
+
+### 7.3 页面状态
+
+- 小队、任务、成员、问题和展示块使用各自稳定 ID 作为 React key；不用更新时间、事件序号或内容版本充当 key。
+- React state 保存当前小队、展开项和草稿。草稿以小队 ID 与问题 ID 索引，避免小队切换导致丢失或串用。
+- 服务端数据与本地草稿分开保存；接收状态更新不能覆盖正在编辑的输入。
+- 列表使用稳定排序，普通进展报告不重新洗牌。输入控件和提交表单保持稳定组件位置与类型。
+- 小队切换只需常规 state 和必要的滚动位置记录，不建设复杂页面缓存。首版不承诺任意浏览器重载后的草稿恢复。
+- 断线时保留现有内容并标记连接状态；恢复时更新数据，不用全屏加载状态替换正在使用的页面。
+
+React 重新渲染是正常行为，重点是稳定的组件身份和 DOM 节点。状态切换造成卡片正常移动可以接受；不为每种移动增加焦点捕获、延迟迁移或交互锁定机制。
+
+## 8. 原始 HTML 展示能力
+
+复杂的方案对比、架构说明、图表和交互演示可以用 HTML 表达。Dashboard 提供固定外框、标题和展开查看入口，内部内容由 Agent 发布。
+
+首版使用稳定的 sandbox iframe，通过 `srcDoc` 或等价的受控内容入口渲染。允许内部演示脚本，但不授予 same-origin、父页面访问、看板凭证或任意任务写接口；不把原始 HTML 直接插入主应用 DOM。
+
+首版要求自包含 HTML：样式和脚本内联，必要图片可内嵌，不建设本地目录映射、任意文件服务或外部依赖管理。内容设置明确的大小限制，发布成功才更新可见内容。
+
+更新规则保持简单：
+
+- task/member 等普通数据变化不改变 iframe 的 key、src 或 srcDoc，因而不会重新加载其文档。
+- 只有展示块内容变化时才更新对应内容，允许这一次更新重置其内部状态。
+- 切换小队使展示块卸载后，再次进入可以正常重新加载；不保证任意 HTML 内部交互状态跨切换保留。
+- 不引入 HTML 状态保存接口、更新握手、延迟替换、DOM 自动合并或专门的交互 SDK。
+
+正式的用户问题仍使用 iframe 外的内置表单。HTML 内的控件可以用于模拟和说明，首版不从任意脚本动作推断用户已提交答案。影响问题含义的展示块更新应同时更新该问题的内容版本；仅用于任务展示的修改无需使无关问题失效。
+
+## 9. 对 Lavish 的借鉴范围
+
+借鉴其围绕成品展示问题的方式，以及原生表单、明确提交、草稿与已发送状态分离、稳定反馈身份等机制。复杂问题可附带 HTML 说明，使用户在上下文中作决定。
+
+本方案由 cmdr 内置 React 页面和数据接口完成协作闭环，不把 Lavish CLI、`poll` 或 Agent 重写整个 HTML 文件作为运行时依赖。用户答案直接进入 cmdr 的持久化与回复路由，不从自然语言反馈中猜测是否完成确认。
+
+Lavish 对等待的关键约束值得沿用：后台任务必须由能将结果通知回原会话的宿主管理，单纯使用 shell `&` 或 `nohup` 不能构成模型唤醒路径；等待时保持安静，只在反馈等有意义的事件到达后恢复处理。其默认前台长轮询、HTTP 保活和 CLI 等待提示服务于自身执行环境，不照搬为 cmdr 的新机制。cmdr 已有宿主适配器、watcher 与租约，应复用这些能力。浏览器断线与协作结束仍分开处理，在本方案中关闭看板不结束小队。
+
+源码调研参考为 Lavish v0.1.71，固定提交 `4413dcc8eff35cdc659e2035b94194d3c9be55fa`：
+
+- [输入交互指导](https://github.com/kunchenguid/lavish-axi/blob/4413dcc8eff35cdc659e2035b94194d3c9be55fa/src/playbooks.js)：结构化控件、明确提交、选择与发送状态分离。
+- [浏览器 SDK](https://github.com/kunchenguid/lavish-axi/blob/4413dcc8eff35cdc659e2035b94194d3c9be55fa/src/artifact-sdk.js)：HTML 内反馈控件与展示上下文。
+- [会话存储](https://github.com/kunchenguid/lavish-axi/blob/4413dcc8eff35cdc659e2035b94194d3c9be55fa/src/session-store.js)：反馈身份、去重与结束状态处理。
+- [CLI 等待与宿主唤醒约束](https://github.com/kunchenguid/lavish-axi/blob/4413dcc8eff35cdc659e2035b94194d3c9be55fa/src/cli.js)：前台等待、后台完成通知与结果交付的边界。
+
+## 10. 首版范围与实施拆分
+
+首版覆盖一条完整闭环：
+
+`工具维护任务 → 多小队看板展示 → 成员报告自动更新 → 用户回答问题 → 对应指挥官继续处理`
+
+建议按以下顺序实施，每一步仍需满足原有协作语义：
+
+1. 增加 Task、Question、Artifact 数据及工具操作，复用 command/report 状态和角色收件箱，完成持久化、权限和答复去重；答案入站接入现有 actionable 策略及宿主唤醒路径。
+2. 增加本地 Web 服务、快照和事件接口，构建 React 固定布局，接通多小队切换、任务、成员与问题表单。
+3. 增加隔离的 HTML 展示组件和发布工具，完成用户答复、既有宿主唤醒、指挥官读取与处理回执的联调，以及打包和浏览器验证。
+
+现有 proxy/queue 适配、watcher 长连接、续租、重新监听去重、忙时合并和唤醒投递核对均直接复用，不重复实现。看板只增加业务接入和状态展示，不以模型定时轮询或周期重连维持可响应状态。
+
+看板允许局域网浏览器访问同一个本机用户的数据；首版不包含公网部署、多用户账户、跨机器小队、创建新 Agent、executor 互发消息、可视化页面搭建、复杂工作流编辑器或任意 HTML 的状态恢复。无需先建设通用插件 UI 框架，也不加入与本看板无关的全局请求重试改造。
+
+构建与分发沿用 0.4.0 的两条安装路径：
+
+- 前端资源放在随完整运行时复制的目录中，例如 `plugins/cmdr/dist/dashboard/`；在生成 `dist/integrity.json` 前完成前端构建，并将前端依赖的许可证纳入分发声明。现有完整性清单递归覆盖运行时文件，setup 根据该清单生成构建摘要，只有前端内容变化时也应得到新的运行时目录。
+- 原生插件从宿主缓存使用资源；setup 将完整运行时持久化到 `<CMDR_HOME>/runtimes/<version>-<digest>/`，通过稳定启动器访问。两种路径均使用预构建资源，不启动开发服务器、不现场安装前端依赖；删除 npx 缓存或安装源不能影响看板运行。
+- setup 升级保留旧运行时，更新稳定启动器，但不自动重启已有 daemon。看板静态资源与接口均由当前 daemon 对应的运行时提供；启用新版按既有流程使用新 CLI 显式重启 daemon、重连 MCP，并按宿主要求重新监听。原生插件另外需要刷新／重装缓存，不增加看板热切换协议。
+
+上述安装与升级能力已有实现；新增工作是将前端资源纳入现有构建、完整性检查、复制和包验证流程。
+
+## 11. 验收标准
+
+| 场景 | 预期结果 |
+| --- | --- |
+| 两个小队同时有任务 | 一个入口可以切换查看，各自任务与成员清晰隔离，后台小队待确认数量更新 |
+| 任务从计划到派发再完成 | 看板与实际 command 接单、终态一致，不能用编辑任务绕过执行语义 |
+| 成员离线或消息已读 | 不误报任务完成、停止或已接单，不释放任务归属 |
+| 用户输入期间连续收到报告 | 输入、选择、焦点不被普通数据更新重置，页面不整页刷新 |
+| 用户切换小队后返回 | 结构化表单草稿仍在，答案不会提交到另一个小队 |
+| HTML 展示块保持不变 | 其他状态更新不重载 iframe；HTML 自身更新允许局部状态重置 |
+| HTML 内部脚本运行 | 可以做局部演示，不能读写 Dashboard 状态或直接确认任务 |
+| 重复提交或响应丢失 | 同一提交 ID 返回原回执，只记录一次答案，不产生重复指挥官通知消息 |
+| 问题已被修改或撤回 | 旧表单不被静默接受，用户输入保留，并得到明确提示 |
+| 指挥官退出后有人接管 | 任务、问题及已提交答案保留，新指挥官能继续处理 |
+| 用户回答时指挥官空闲或正忙 | 答案持久化并接入现有宿主通知／队列；忙时沿用宿主适配语义，不新建竞争会话 |
+| 已接单任务阻塞后重新监听 | 无新消息时保持静默；答案、新的未接单工作和待处理取消仍可通知，原任务归属与恢复能力不变 |
+| 答案已读但指挥官尚未记录处理结果 | 问题仍显示待处理，恢复或接管时可通过问题查询继续核对 |
+| 监听健康、唤醒已投递或宿主状态未知 | 分别展示已有证据，不把连接、监听或投递状态显示成模型已处理或任务已接单 |
+| 浏览器断线后恢复 | SSE 重连后重新查询快照，保持外层交互状态，展示实际连接情况 |
+| 首次查询或重新查询期间发生变化 | 订阅已经生效，查询期间的通知触发补读，旧响应不覆盖新状态 |
+| 一个页面切换多个小队 | 始终复用一条 SSE 连接，不按小队或组件增加长连接 |
+| daemon 重启或历史消息过期 | 任务、未处理问题和答案可恢复；不依赖短期消息日志维持看板事实 |
+| 关闭 Dashboard | 小队、任务和宿主监听继续按原有规则运行 |
+| 原生插件或 setup 安装后移除安装源／npx 缓存 | 各自完整运行时仍可提供页面和接口，不依赖临时路径或技能目录 |
+| 多个宿主 profile 或自定义数据目录 | 相同 `CMDR_HOME` 共用看板；不同目录保持隔离，打开入口与 watcher 均指向预期目录 |
+| 升级或扩展 MCP 工具 | doctor/setup 自检识别新版工具集合；完整性检查包含前端资源，显式重启后页面与接口来自同一运行时 |
+
+基线回归测试覆盖 watcher 重新启动、daemon 重启后重新监听、未读答案、未接单工作、待处理取消，以及省略 `data` 的实时／回放事件和同一订阅上的连续报告通知；standby 测试还覆盖忙时合并、投递结果不确定时的核对及无进展停滞。本分支保留这些测试，并新增用户答案去重入队、当前指挥官路由、问题恢复与处理回执验证。
+
+setup 测试与离线包验证覆盖持久运行时、升级、配置保留、profile 隔离、watcher 数据目录绑定及清除 npx 缓存后的检查。本分支补充静态资源、HTTP/SSE 和新版工具集合验证；安装自检成功仍不代表宿主信任、hooks 执行或模型自动响应已经通过验证。
+
+本分支已通过 `npm run check`、最低 Node 版本下的看板测试和 ZCode runtime 插件验证，并完成真实浏览器的输入、切换、iframe 保留、答复提交和 CLI 指挥官处理回执验证。真实宿主中的空闲唤醒、忙时积压及原生任务过期后的重新监听仍需单独验证；已有进程测试和浏览器／CLI 流程均不代表真实模型已处理。
+
+自动化测试与浏览器验证的实际结果记录在 `docs/implementation.md`，不将进程测试等同于真实模型协作验证。
+
+## 12. 仓库实现入口
+
+- [长期协作语义](long-running-collaboration.md)：归属、取消、角色收件箱、恢复、事件游标与宿主唤醒。
+- [当前实现与验证范围](implementation.md)：已有能力和验证边界。
+- [安装与升级](setup.md)、[安装实现](../src/cli/setup.ts)：持久运行时、稳定启动器、数据目录及宿主 profile。
+- [安装诊断](../src/cli/doctor.ts)、[离线包验证](../scripts/verify-package.mjs)、[setup 进程测试](../tests/setup-process.test.ts)：MCP 工具集合检查及移除缓存后的验证入口。
+- [协议与模型](../src/shared/protocol.ts)、[工具 schema](../src/shared/schemas.ts)：现有类型和九个工具。
+- [核心逻辑](../src/daemon/core.ts)、[持久化](../src/daemon/store.ts)：事务、任务执行和消息路由。
+- [看板业务](../src/daemon/dashboard.ts)、[HTTP/SSE 服务](../src/daemon/dashboard-http.ts)、[React 页面](../src/dashboard/app.tsx)：任务、问题、HTML 与浏览器交互。
+- [事件观察](../src/cli/tail.ts)、[唤醒策略](../src/shared/wake.ts)：非消费式观察与 actionable 分类。
+- [宿主 watcher](../src/cli/watch.ts)、[standby 调度](../src/daemon/standby.ts)：监听、续租、重新监听去重与宿主投递。
+- [watcher 进程测试](../tests/host-watch-process.test.ts)、[standby 测试](../tests/standby.test.ts)：已有自动化覆盖，区别于真实宿主与看板联调。
+- [daemon 服务](../src/daemon/server.ts)、[构建脚本](../scripts/build.mjs)：本地服务生命周期、打包和完整性校验。

package/docs/dashboard.md

@@ -0,0 +1,101 @@
+# 内置小队看板
+
+看板随 cmdr 完整运行时分发，支持原生插件与 standalone setup 安装。它使用 React、HTTP 与 SSE，在一个页面中切换本数据目录下的小队。Agent 通过工具更新数据；用户通过内置表单回复问题，也可以向当前小队的指挥官留言。
+
+```sh
+cmdr dashboard
+# 不自动打开浏览器，输出本机及网卡 IPv4 访问地址
+cmdr dashboard --no-open
+```
+
+setup 安装使用 setup 返回的稳定 CLI 路径，例如 `~/.cmdr/bin/cmdr dashboard`。不同 `CMDR_HOME` 对应不同看板；同一数据目录的多个宿主 profile 共享看板。开发分支使用构建后的 `plugins/cmdr/bin/cmdr`。如果已有旧 daemon，先协调当前工作，使用该安装的 CLI 执行 `cmdr daemon restart`，再重连 MCP；相同版本的本地代码变化也需要重启。
+
+命令输出的地址含有效期 60 秒的一次性打开凭证。浏览器将它换为 HttpOnly、SameSite Cookie，并从地址栏清除。服务默认绑定 `0.0.0.0`，端口由系统分配。输出中的 `url` 是自动打开的 `127.0.0.1` 地址，`urls` 包含该地址与各非回环网卡 IPv4 地址（去重），使用同一端口。每个地址有独立、绑定来源的一次性凭证，本机打开不会消耗其他地址的凭证。允许的 Host 来自这些地址，写请求的 Origin 必须与所访问的地址一致；不提供任意 RPC 转发。关闭页面不关闭小队、不取消任务、不停止成员监听。活跃 SSE 连接使 daemon 保持运行；关闭后恢复原有空闲退出规则。
+
+看板文案默认跟随系统／浏览器的首选语言：中文（`zh-*`）显示简体中文，其他语言显示英文。页面标题、无障碍标签和时间格式使用相同语言。Agent／用户提供的消息、任务与问题内容、选项及 HTML 展示保持原样，不自动翻译；更改浏览器语言后重新打开或刷新页面生效。
+
+网卡地址变化后重新运行 `cmdr dashboard` 会刷新地址列表。局域网设备使用对应网卡 IP 的链接访问，连通性取决于网络与主机防火墙。所有持有有效链接的浏览器具有同一用户权限；当前为 HTTP 服务，无多用户权限隔离。
+
+## HTTP 实现
+
+看板 HTTP 层使用 Hono 路由和 `@hono/node-server` 适配器，仍由现有 daemon 懒启动、监听所有 IPv4 网卡并由系统分配端口并统一关闭。JSON 请求通过中间件限制为 64 KiB；错误响应沿用 `{ code, message }` 和原有状态码。静态资源只提供三个固定入口，路径从运行时目录解析。
+
+SSE 使用 Hono 的 `streamSSE`，保留提交后失效通知、20 秒注释心跳及断线后的活跃连接清理。每条连接的待写数据和 Node 输出缓冲合计超过 1 MiB 时关闭连接，由浏览器重连并重新读取快照。框架不负责业务事务、Agent 唤醒或访问策略；一次性凭证、同源校验、会话验证和 HTML 沙箱规则仍由看板明确实施。
+
+前端按组件职责拆分：`app.tsx` 负责页面组装、SSE 订阅和跨小队草稿；`question-card.tsx`、`task-details.tsx`、`squad-dock.tsx`、`commander-message.tsx` 和 `artifact-view.tsx` 分别负责问题、详情、成员／活动、留言及 HTML 展示；`display.ts` 共享状态标签与时间／错误格式化。组件拆分不改变状态归属和挂载位置。
+
+## 页面布局
+
+宽屏使用三栏布局：左侧切换小队，中间是四列任务看板与底部成员／活动坞，右侧常驻待确认事项和留言框。顶部将任务数、执行中、待回复和成员数压缩为一行。点击任务或问题中的关联任务，在中间工作区打开详情；返回看板不影响右侧填写中的答复。
+
+已接收、已处理和已撤回的问题折叠在“其他事项”中，可展开查看答复、处理说明和提交时的证据。窄屏将确认面板排列在工作区下方，任务列与成员表格可横向滚动。
+
+## 向指挥官留言
+
+右下方的留言框向**当前选中小队**发送用户消息，不直接编辑、派发或取消任务。只在点击“发送”或按回车后提交；切换小队保留各自草稿。成功回执表示已进入队列，尚不代表指挥官已读取或处理。
+
+留言通过受鉴权、同源校验的 `POST /api/messages` 提交，只有 `squad_id`、`submission_id`（UUID）、`text` 三个字段，文本限 8,000 字符。daemon 以 `from_role="user"` 的 `info` 消息写入 `squad:<id>` 稳定指挥官收件箱，复用 SQLite 队列、容量限制、提交后的通知和现有唤醒机制，不新增 MCP 工具或专用监听链路。没有指挥官时仍可排队，接管者通过现有 `read` 读取；已关闭小队拒绝新留言。
+
+发送失败保留内容和原提交 ID，在消息仍保留期间重试返回同一回执；不同内容复用 ID 会被拒绝。留言沿用普通消息 TTL，不属于永久保存的用户问题／答复记录，也没有独立的“已处理”状态。
+
+## 指挥官操作
+
+新增 `task`、`artifact`，共九个 MCP 工具。原来的 executor `ask(question=...)` 行为保持不变；指挥官用 `ask(target="user", ...)` 管理用户问题。CLI 后备路径支持同名操作，通过 `cmdr session <tool> --agent HOST --native-id REAL_ID --input '<JSON>'` 传入结构化参数。
+
+创建任务并派发：
+
+```text
+task(action="create", title="完成导出功能", description="支持 CSV 导出", acceptance="中文字段正确，空结果可导出")
+send(to="实现者", task_id="<返回的任务 ID>", message="实现导出功能并验证验收条件")
+```
+
+`task` 支持 `create/update/get/list/archive/restore`。`update` 可修改标题、说明、验收条件、`position` 和 `artifact_ids`，不能直接修改执行状态。小队成员可以查询本小队任务，只有当前指挥官可修改。`list` 使用 `offset/limit`，可按 `archived` 过滤；`get` 的执行记录按新到旧分页，返回 `next`。任务摘要只保留最近的执行信息，详情按需读取。
+
+派发、接单、阻塞、终态和合作式取消仍由 command/report 驱动。`send(task_id=...)` 只允许一个接收者，默认用 task ID 作为 `task_key`；已有未完成工作必须使用 `reassign`，关联任务随重新分配保留。消息已读不等于接单。归档不能释放未完成任务，任务及执行摘要不随消息 TTL 删除。
+
+创建用户问题：
+
+```text
+ask(target="user", question="采用哪种导出范围？", kind="single",
+    options=[{id:"current",label:"当前筛选结果"},{id:"all",label:"全部数据"}],
+    task_id="<任务 ID>")
+```
+
+支持 `single`、`multiple`、`text`、`confirm`。选择题有 2–20 个带稳定 ID 的选项；其他类型不传 options。选择题和确认题均可填写补充文字。`artifact_ids` 可关联复杂说明；普通表单由看板内置，不需要 Agent 编写 HTML。
+
+`ask(target="user")` 支持以下操作：
+
+| action | 行为 |
+| --- | --- |
+| `create` | 创建问题，默认类型为 `text`，返回 ID 和版本 |
+| `get` / `list` | 获取问题或分页查询；可按 `status` 查询，包括 `answered` 的未处理答复 |
+| `update` | 传 `id/version` 修改 pending 问题，增加内容版本 |
+| `withdraw` | 传 `id/version` 撤回 pending 问题，不等于用户拒绝 |
+| `handle` | 传 `id/version/result`，明确记录已回答问题的处理结果 |
+
+用户问题不使用 `wait`。用户提交后，答案和去重回执在同一事务内持久化，带 `from_role="user"` 的 answer 消息进入 `squad:<id>` 指挥官收件箱，并接入现有唤醒机制。浏览器失败重试保留原提交 ID；相同 ID 和内容返回原回执。旧版本、撤回问题或第二次不同提交会被拒绝。没有指挥官时答案继续保存；接管者可读取和处理。
+
+读取不代表处理完成。指挥官恢复时除 `read` 和 `read(recover=true)` 外，还应查询 `ask(target="user", action="list", status="answered")`，核对未处理决策，再显式 `handle`。`read(recover=true)` 只恢复未完成 command。已回答的问题不再编辑；再次征询创建新问题。
+
+## HTML 展示块
+
+```text
+artifact(title="两种方案对比", html="<!doctype html><html>…自包含内容…</html>")
+task(action="update", id="<任务 ID>", artifact_ids=["<展示块 ID>"])
+```
+
+`artifact` 支持 `publish/get/list`。更新时提供 `id/version/title/html`；只支持直接传 HTML 内容，不读取任意本机文件。HTML 必须自包含，样式和脚本内联，图片可用 data URL。展示块位于独立 sandbox iframe 中，允许演示脚本，禁止 same-origin、父页面访问、外部资源、网络接口调用和表单提交。用户的正式答复只来自 iframe 外的内置表单。
+
+普通数据更新保留 iframe 节点与地址。展示块内容变化会重新加载该 iframe，切换小队后也可能重新加载，不提供任意 HTML 内部状态恢复。更新关联 pending 问题的 HTML 会递增问题版本，保留草稿并要求用户核对。提交时保存完整说明和 HTML 快照，之后可在“查看提交时的说明”中追溯。
+
+## 容量与保留
+
+每个小队每种记录（Task、Question、Artifact）上限为 200，包括已归档记录；每项任务最多 100 条执行记录，命令与报告各保存最多 2,000 字符的摘要。单份 HTML 上限为 256 KiB，当前展示块总量上限为 8 MiB，每个任务或问题最多关联 8 份。看板记录及提交快照不使用消息 TTL 自动清理；首版不提供单条删除，显式 `purge --all` 会连同协作数据一起清除。
+
+## 连接与验证边界
+
+每个标签页一条 SSE，所有小队共享。事件只提示数据变化，页面再查询快照；断线恢复同样重新查询。表单草稿保存在当前页面内存中，按小队和问题区分，切换小队不丢失；浏览器整页重载不保证恢复。
+
+监听健康、宿主接受唤醒、任务接单和问题处理各自显示。Codex 复用 proxy/queue；Claude/ZCode/Kimi 完整执行 `listener.arm.command`，保留其中的 `CMDR_HOME`，使用宿主原生通知。安装自检与自动化测试不代替真实宿主的信任提示和模型唤醒验证。
+
+设计背景见[方案文档](dashboard-plan.md)。

package/docs/implementation.md

@@ -1,11 +1,12 @@
 # Implementation and verification
 
-This document records the implementation and its verification scope. The design's historical v0.1.x trial reports described a prior prototype; they are not test evidence for this implementation. This release is versioned from `package.json` as **0.4.0**, internal protocol **1**.
+This document records the implementation and its verification scope. The design's historical v0.1.x trial reports described a prior prototype; they are not test evidence for this implementation. This release is versioned from `package.json` as **0.6.0**, internal protocol **1**.
 
 ## Delivered behavior
 
 - A single on-demand daemon, Unix socket, SQLite WAL persistence, exclusive process lock, spawn coordination, idle exit, retention cleanup, log rotation and preflight-validated explicit replacement.
-- Seven MCP stdio tools with input limits, role enforcement, atomic named squads, priorities, queue backpressure, sender rate limits, correlated asks/answers, peek/history and cancellable long polling.
+- Nine MCP stdio tools with input limits, role enforcement, atomic named squads, priorities, queue backpressure, sender rate limits, correlated asks/answers, peek/history and cancellable long polling. Dashboard operations add `task` and `artifact`; `ask(target="user")` manages durable user questions.
+- A bundled React dashboard served on demand by the existing daemon over loopback HTTP/SSE, with multiple squads, durable task execution summaries, structured user replies and isolated HTML explanations.
 - Orphan/takeover/dissolve semantics, stable native identities, provisional identity migration, resume/reconnect, per-stamped-session MCP connections, Claude clear rebinding, cwd filtering and derived titles.
 - Lifecycle hooks with a flag-file fast path, metadata-only reminders, repeat throttling, actionable Stop interception, compact/resume context and fail-open behavior.
 - Operator status/list/tail/send/read, daemon controls, cleanup, environment diagnostics and printable MCP configuration.
@@ -14,7 +15,7 @@ This document records the implementation and its verification scope. The design'
 
 ## Deliberate clarifications to the design
 
-Generated `dist` files and license notices are excluded from Git, including this PR branch's history. `prepack` builds the publishable npm package; explicit package files and executable mappings include the runtime and all host plugin metadata. Source marketplace installation requires a build first. CI packs the real tarball and installs it offline into a temporary prefix, testing the CLI and seven MCP tools without external runtime dependencies. No registry publication is performed by this PR.
+Generated `dist` files and license notices are excluded from Git, including this PR branch's history. `prepack` builds the publishable npm package; explicit package files and executable mappings include the runtime, dashboard assets and all host plugin metadata. Source marketplace installation requires a build first. CI packs the real tarball and installs it offline into a temporary prefix, testing the CLI and nine MCP tools without external runtime dependencies. No registry publication is performed by this PR.
 
 Tool schemas live in `shared/schemas.ts` separately from protocol/error types, so the hook does not pull in Zod just to handle RPC errors. The member CLI now deliberately shares the tool schemas and includes their validator.
 
@@ -32,7 +33,7 @@ Cancellation is propagated from MCP through the Unix socket (`rpc.cancel`). Disc
 
 ## Automated verification
 
-The checked-in suite covers core, hooks/identity, utilities, real processes and release scenarios across five files:
+The checked-in suite covers core, hooks/identity, utilities, real processes, dashboard interactions and release scenarios:
 
 | Coverage | Evidence |
 | --- | --- |
@@ -41,6 +42,7 @@ The checked-in suite covers core, hooks/identity, utilities, real processes and
 | Utilities | Host detection and namespaces, timeout negotiation, symlink/cwd handling, Codex/Claude titles, socket path fallback, lock recovery and config defaults |
 | Release | Member CLI workflow with hook-stamped MCP identity, cancellation and ask non-replay, missing/corrupted bundles, stale versions, bounded diagnostics, isolated handshake timeout and cleanup |
 | Real processes | Bundled MCP tool discovery, simultaneous daemon startup, messaging/ask/read, graceful restart, SIGKILL recovery, version upgrade, pooled ZCode session isolation, hook executable behavior, protocol rejection, end-to-end MCP cancellation |
+| Dashboard | Task/report ownership, reassignment gates, durable answers and immutable evidence, rollback/deduplication, HTTP authorization/CSRF, SSE invalidation, stable React DOM and drafts, installation after source/cache removal |
 
 Validation commands:
 
@@ -123,3 +125,22 @@ Verification of the independent branch on 2026-09-17 (macOS, Node 24.16.0):
 Outstanding host acceptance is the real idle→notification→read→working→done loop in refreshed Codex, Claude and ZCode sessions, including a busy-turn backlog and watcher re-arm after native task expiry. Use a disposable channel/workspace and inspect tail/list for acceptance; tool/CLI availability alone is not the success criterion. No normal ~/.cmdr state, installed plugin cache or host trust settings were changed during verification.
 
 Release preparation for 0.3.0 synchronizes npm and host manifests and injects the package version into Vitest, matching the production build so process tests validate the released version rather than the minimum compatible client version. The release is prepared from merged PR #10 in a clean worktree.
+
+## Dashboard iteration — feat/dashboard
+
+Implemented on `feat/dashboard`, based on merged `main` (`9c95e8f`). The existing daemon starts one loopback HTTP service on demand through `cmdr dashboard`. Bundled React assets, HTTP snapshots and one SSE stream per browser tab support multiple squads without page reloads. The browser uses a one-use opening token exchanged for an HttpOnly, SameSite cookie; Host/Origin checks protect writes. HTML explanations run in separate sandboxed documents with no same-origin privilege, network API access or form submission.
+
+`task` and `artifact` extend the public MCP set to nine tools; `ask(target="user")` provides structured questions. Task execution follows existing commands/reports, including acceptance, cancellation and gated reassignment. User submission, immutable evidence, receipt and stable commander-inbox message commit together. Reading an answer does not mark it handled; commanders explicitly record the result. Records survive message retention and daemon restart. The browser's SSE connection keeps the daemon available while open, and user answers use the existing attention/wake paths. No additional Agent long connection or periodic model wake is introduced. See [dashboard usage](dashboard.md) for tool parameters, limits and recovery.
+
+Frontend assets and dependency licenses are built before the integrity manifest, so native plugin caches and persisted setup runtimes carry the same complete build. The package-size review threshold against the historical 0.1.0 baseline is exceeded; the release tarball is approximately 443 kB compressed, including the production React bundle and dashboard assets. No new runtime dependency installation is required.
+
+Verification on 2026-09-17 (macOS, Node 24.16.0):
+
+- `npm run check`: **139 tests across 17 files passed**, plus formatting, strict typing, build, offline npm installation and nine-tool discovery. Source-removal/setup and npx-cache-removal checks verify dashboard resources and authenticated HTTP access from the persistent runtime.
+- Node **22.5.0**: all **16 dashboard domain, HTTP and React tests** passed, including the jsdom environment used by frontend tests.
+- `npm run verify:zcode`: the installed desktop runtime validated the release cache, discovered 1 command / 4 skills / 4 hooks / 1 MCP server, and connected nine tools after source removal. The runtime used an explicitly isolated temporary session database. No model request was made.
+- A real browser against a disposable `CMDR_HOME` verified two-squad navigation, task/member views, HTML script rendering, retained input/selection/focus during report updates and unchanged iframe content, and draft preservation across squad switches. A browser-submitted answer reached the correct commander inbox; a CLI-issued handled result appeared on the page. A subsequent daemon restart preserved tasks, answers and handling results. Temporary sessions, browser tabs and daemon state were removed afterward.
+
+Real idle-model wake and GUI trust across Codex, Claude and ZCode remain a separate acceptance check. The browser/CLI loop and deterministic wake regressions do not claim that a live model processed the answer.
+
+看板 UI 使用小队导航、任务工作区和常驻确认面板三栏布局，成员与活动位于底部。用户留言经专用 HTTP 入口进入现有指挥官角色收件箱，来源为 user、类型为 info，复用原有队列和通知，不增加 MCP 工具；留言保留与去重边界见 [Dashboard 操作说明](dashboard.md#向指挥官留言)。

package/docs/long-running-collaboration.md

@@ -62,6 +62,7 @@ On startup or after a wake, use ordinary `read` and `read(recover=true)`. Recove
 | Codex | Daemon attaches through app-server proxy; falls back to `codex queue` when proxy is unavailable | Join with auto, check health, end the idle turn |
 | Claude Code | Native Monitor emits a notification for each watcher output line | Run `listener.arm.command` with Monitor; re-arm on expiry/exit |
 | ZCode desktop | Native background Bash re-invokes its session when the watcher exits | Run `listener.arm.command` with `run_in_background=true`; re-arm after each notification |
+| Kimi Code desktop | Native background Bash re-invokes its session when the watcher exits | Run `listener.arm.command` with `run_in_background=true`; re-arm after each notification |
 
 All paths share the same actionable policy: command, cancel, ask, answer, system, terminal/blocked reports, attention-marked info and direct info. working/ready reports and broadcast info without attention are quiet. Commands gated by reassignment remain blocked. Observation does not consume messages or accept tasks. Every wake must be followed by `read` and `read(recover=true)`, cancellation handling, and correlated working/terminal reports.
 
@@ -99,18 +100,19 @@ cmdr standby resume --session SID --resolve retry
 
 `retry` explicitly permits a new submission; it does not establish that the earlier one failed. Busy sessions coalesce backlog. Host acceptance remains separate from the command owner's working report.
 
-### Claude and ZCode: native host watchers
+### Claude, ZCode and Kimi Code: native host watchers
 
 Join/list returns `listener.arm` with an absolute installed command, the native host tool and re-arm instructions. The standard command is:
 
 ```sh
 cmdr standby watch --session claude:REAL_ID
 cmdr standby watch --session zcode:REAL_ID
+cmdr standby watch --session kimi:REAL_ID
 ```
 
 Claude uses its **Monitor tool**, not foreground Bash or shell `&`. Each stdout line becomes a native notification, queued into an active turn or opening an idle turn. The reporter's Monitor has a 30-minute lifetime; re-arm when the host reports expiry/exit. If Monitor is absent but the host supports background Bash completion notifications, use `--once` with `run_in_background=true`. If neither mechanism exists, explicitly select manual.
 
-ZCode uses **Bash with run_in_background=true**. Its native task survives the current turn and automatically re-invokes the session on completed/failed/killed. The built-in watcher remains silent during idle periods and exits after printing actionable metadata. It never consumes inbox messages, so a lost output notification still leaves the work available for recovery. On notification: inspect task output, read/recover, handle work, and re-arm. An immediate backlog produces an immediate notification; drain/reconcile it before re-arming.
+ZCode and Kimi Code use **Bash with run_in_background=true**. Their native task survives the current turn and automatically re-invokes the session on completed/failed/killed. The built-in watcher remains silent during idle periods and exits after printing actionable metadata (on Kimi Code it also exits after one wake because its hook reminders cannot reach the model, so the agent must re-arm from the completion notification). It never consumes inbox messages, so a lost output notification still leaves the work available for recovery. On notification: inspect task output, read/recover, handle work, and re-arm. An immediate backlog produces an immediate notification; drain/reconcile it before re-arming.
 
 The command subscribes before inspecting current work, covering startup races, unread messages and read-but-unaccepted commands. At attach, accepted commands without pending cancellation are treated as already known: a blocked executor can re-arm and wait for an answer without repeatedly waking on its own unfinished task. Ownership and `read(recover=true)` remain unchanged; reconcile accepted work on startup or after context loss before arming. Unread answers, new commands and pending cancellation still notify, including cancellation requested after attach.
 

package/docs/publishing.md

@@ -1,6 +1,6 @@
 # npm 发布
 
-本次发布版本为 `cmdr-mcp@0.4.0`。npm 包名是 `cmdr-mcp`，CLI、宿主插件和 marketplace 名称仍为 `cmdr`。全局安装后的包根目录是 `$(npm root -g)/cmdr-mcp`。
+本次发布版本为 `cmdr-mcp@0.6.0`。npm 包名是 `cmdr-mcp`，CLI、宿主插件和 marketplace 名称仍为 `cmdr`。全局安装后的包根目录是 `$(npm root -g)/cmdr-mcp`。
 
 ## 准备与验证
 
@@ -10,12 +10,12 @@
 npm ci
 npm run check
 npm pack
-npm publish ./cmdr-mcp-0.4.0.tgz --dry-run --access public --registry https://registry.npmjs.org/
+npm publish ./cmdr-mcp-0.6.0.tgz --dry-run --access public --registry https://registry.npmjs.org/
 ```
 
-涉及 ZCode 的发布另运行 `npm run verify:zcode`：从实际 tarball 安装到隔离缓存，核对完整性并移走安装源后验证 7 个工具；需要本机 ZCode runtime。
+涉及 ZCode 的发布另运行 `npm run verify:zcode`：从实际 tarball 安装到隔离缓存，核对完整性并移走安装源后验证 9 个工具；需要本机 ZCode runtime。
 
-`npm run check` 包括格式、类型、构建、测试以及临时目录中的 npm 包离线安装验证：检查发布资源、安装后 marketplace 路径、CLI 和 7 个 MCP 工具。`npm pack` 通过 `prepack` 生成 4 个运行入口及第三方许可证声明，输出 `cmdr-mcp-0.4.0.tgz`。源码、测试和开发依赖不进入发布包。
+`npm run check` 包括格式、类型、构建、测试以及临时目录中的 npm 包离线安装验证：检查发布资源、安装后 marketplace 路径、CLI 和 9 个 MCP 工具。`npm pack` 通过 `prepack` 生成 4 个运行入口及第三方许可证声明，输出 `cmdr-mcp-0.6.0.tgz`。源码、测试和开发依赖不进入发布包。
 
 检查 `git diff`，确认版本与预期一致，构建未意外修改宿主 manifests。发布前保留经过验证的源码提交；不要手改或提交 `plugins/cmdr/dist/`、`THIRD_PARTY_NOTICES.txt` 和 `.tgz`。
 
@@ -33,23 +33,25 @@ npm view cmdr-mcp name version --registry https://registry.npmjs.org/
 
 包已经存在，发布前核对账号的包所有权和目标版本是否尚未发布。网络或身份验证错误不能作为版本可用的依据。账号需要启用 2FA，按 CLI 提供的浏览器链接完成发布授权。
 
+CLI 输出授权地址后，立即把本次链接发到对话中，让维护者可用手机完成验证；默认不在本机浏览器反复尝试。保留发布进程等待验证。链接失效或返回 404 时，先确认目标版本尚未发布、旧请求已结束，再用同一已验证 tarball 重新发起发布，并立即发送新链接。维护者完成验证后，检查 CLI 结果及 npm 上的版本、完整性和 `latest` 标签，再继续 GitHub Release 与 marketplace 分发。
+
 确认发布时，上传已检查的 tarball，并按 npm 提示完成账号验证：
 
 ```sh
-npm publish ./cmdr-mcp-0.4.0.tgz --access public --registry https://registry.npmjs.org/
+npm publish ./cmdr-mcp-0.6.0.tgz --access public --registry https://registry.npmjs.org/
 ```
 
-此命令会公开发布 `0.4.0` 并使用默认的 `latest` 标签。相同包名和版本不能重复发布；后续修改需要提升版本并重新构建验证。发布使用 tarball，以保持上传内容与已检查产物一致。
+此命令会公开发布 `0.6.0` 并使用默认的 `latest` 标签。相同包名和版本不能重复发布；后续修改需要提升版本并重新构建验证。发布使用 tarball，以保持上传内容与已检查产物一致。
 
 ## 发布后核对
 
 ```sh
-npm view cmdr-mcp@0.4.0 name version dist.integrity --registry https://registry.npmjs.org/
-npm install --global cmdr-mcp@0.4.0 --registry https://registry.npmjs.org/
+npm view cmdr-mcp@0.6.0 name version dist.integrity --registry https://registry.npmjs.org/
+npm install --global cmdr-mcp@0.6.0 --registry https://registry.npmjs.org/
 cmdr --help
 ```
 
-按照[安装说明](README.zh-CN.md#安装)运行 setup 或注册原生插件。原生插件升级后刷新或重装宿主缓存，使用新版本 CLI 执行 `cmdr daemon restart`，再重连 MCP；该命令先做一致性预检，再替换旧 daemon。随后检查监听状态，Claude/ZCode 按 `listener.arm` 重新挂载 watcher。
+按照[安装说明](README.zh-CN.md#安装)运行 setup 或注册原生插件。原生插件升级后刷新或重装宿主缓存，使用新版本 CLI 执行 `cmdr daemon restart`，再重连 MCP；该命令先做一致性预检，再替换旧 daemon。随后检查监听状态，Claude/ZCode/Kimi 按 `listener.arm` 重新挂载 watcher。
 
 npm 命令行为参考：[npm publish 官方文档](https://docs.npmjs.com/cli/v11/commands/npm-publish/)。