DSH Taskboard

它是什么

DSH Taskboard 给 DeepSeek Harness 加了一套项目任务板：项目、带可读编号（如 DSH-42）的任务、评论、任务关系、附件、可保存的工作流，以及一个调度器。README 把权限归属说得很直白——SQLite 是任务状态的唯一权威，而 session、Goal、Workspace、工具、权限与对话历史仍然归 Harness 管。

最容易被误读的一句话是 「不是 iframe，也不建立第二套聊天运行时」。这是一句关于「如何接入」的声明，它包含两件事：

• 界面是原生的 —— 侧栏按钮加一个 overlay 页面，由插件自己的客户端一半通过既有的 Typert 连接、基于有界 Remote 快照渲染，而不是用 <iframe> 嵌一个独立 Web 应用。
• agent 那一侧也不是平行运行时。 架构文档写明自动化驱动「从不 import agent-loop」：它通过公开服务创建或恢复一个 root Agent，挂载配置好的 preset 与模型路由，选定 Workspace 工作目录，创建 Goal，并写入一条普通用户消息——因此任务工作就是一次正常的 Harness session，跑在 Harness 自己的权限模型之下。

所以它不是第二个编排器，没有自己的模型调用和审批链路；它是「一个任务数据库 + 一个会启动普通 Harness session 的调度器」。

领取与评审循环

七种状态：backlog、todo、in_progress、in_review、done，另有 blocked 与 canceled。README 记录的流程是：

human creates backlog
  -> human approves to todo
  -> Agent or automation claims (dependency recheck + exclusive claim + Session)
  -> Agent works in the bound Workspace / branch / worktree
  -> Agent verifies and submits in_review
  -> human accepts done, or returns to todo / in_progress

agent 怎么领取任务。 通过 taskboard_claim，参数是 task_id 与 expected_version。工具描述写明服务会「在同一个事务里重新检查依赖与排他所有权」。只有合格的 todo 能被领取；README 还补了一条对故障恢复很关键的细节：孤儿认领会保持可见，不会被悄悄抢走。

谁来 review。 人类。README 说了两遍：agent 只能把已验证的工作提交到 in_review，「只有经过认证的人类 UI 或 CLI 操作才能把它验收为 done」，以及「Goal 完成不会验收任务」。

状态是否自动流转。 部分是。批准进入 todo、认领、提交 in_review、阻塞与释放认领都是真实的状态流转，但验收在任何来源描述的路径下都不是自动的——它是一次人为的「Accept」点击或 CLI 的 task accept，自动化同样止步于 in_review。

全程还有第二道闸门：除创建之外，每一次变更都必须带上当前精确的 version，而 TASK_STALE_VERSION 的语义是重新读取，而不是用旧版本重试。

agent 能做什么、不能做什么

面向模型的工具共八个：taskboard_list、taskboard_get、taskboard_claim、taskboard_comment、taskboard_submit_review、taskboard_block、taskboard_release_claim、taskboard_relate。源码里这组工具上方的注释写着它「刻意不包含验收，也不包含通用状态变更」。验收、删除、归档与强制接管都只属于人类。包内附带一个 manage-taskboard skill，要求 agent 在写入前立刻 taskboard_get。默认并发上限是每项目 2 个、全局 4 个认领，allowSharedWorktrees: false 表示一份工作只对应一个开发上下文。

自动化，以及这里的「工作流」是什么意思

自动化按项目配置：间隔、agent preset、模型路由、工作器数量与配额策略，间隔下限为 30 秒。启用后，Host 调度器会认领合格的 todo，驱动一个 root agent session 与 Goal，并停在 in_review。

有一点值得重复，因为它出现在 README 里相当罕见：Harness 目前不提供主动的配额信号，所以插件把配额状态报为不确定。新规则默认选择忽略；若选配额不确定时暂停，它会刻意阻止新的认领，但不会取消已在跑的工作。

工作流比看上去要窄。指派一个工作流，只是把它的有序文档作为指导渲染进 agent 的任务指令；调度器不会自动调用工作流节点。某个节点上的 executable 意味着该节点类型已注册了 Host provider，并不代表指派就让工作流变成了执行器。

数据落在哪里

两个有界位置，都可配置，都由 Host 侧解析：databasePath，默认 .dsh/taskboard.sqlite（环境变量 DSH_TASKBOARD_DATABASE）；attachmentRoot，默认 .dsh/taskboard-attachments（环境变量 DSH_TASKBOARD_ATTACHMENTS）。附件默认单文件上限 25 MiB、单任务上限 100 MiB。

请仔细读默认路径这一条。 README 说路径由 Host 解析、浏览器无法选择，但源码在服务构造函数里调用 resolve(config.databasePath)，因此相对路径是按进程工作目录解析的，并不锚定 $DSH_HOME。仓库自己开着的 issue #23 记录了它在真实环境里翻车的样子：因为 Harness 进程继承了某个目录，数据库被静默建在了 ~/.claude/.dsh/ 下。如果你在意文件落在哪，请设成绝对路径。

备份与迁移都有文档：把 SQLite 文件、在线时的 WAL 文件以及附件目录一起复制，先停掉 Harness 才能得到一致的离线备份。要换位置，就停掉 Harness、把两者搬过去，再把上面两个设置指向新路径。schema 两个方向都有保护——来自更高 schema 版本的数据库会被拒绝，而旧的受支持版本会单调向前迁移。

另有一个 headless CLI dsh-taskboard，按 schema 版本输出 JSON，分组为 project、task、relation、attachment、workflow、automation、storage；退出码 0 成功、2 用法错误、3 服务不可用、4 领域错误、5 乐观锁冲突。

运行要求

• Node ^22.19.0 || >=24.0.0，来自 engines —— 它建在 Node 自带的 node:sqlite 上，不是原生扩展，README 建议用 Node 24。包管理器声明为 pnpm 11。
• Harness 0.1.2-alpha.2，README 声明的兼容 Host，且需要 web profile。请注意这里的版本纪律：peer 依赖把一大批 @deepseek-ai/* 包精确锁在 0.1.2-alpha.2，仓库最后几次提交也是为适配该版本做的 CI 修复。已发布的 npm 0.1.4 包稍旧，其内置 README 写的是 0.1.2-alpha.1。
• 对 $DSH_HOME 的写权限，以及重启 Harness 的能力。组装与客户端模块扫描只在启动时发生，所以重启是安装流程的一部分，而它会中断正在进行的 agent 轮次。
• 依赖： 运行期只有 zod 一个依赖；React ^18.2.0 与大量 @deepseek-ai/* 是 peer，通过 profile 的 fallback 链接解析。
• 安装期不执行代码。 包内只有 build、test、typecheck、check、example 五个脚本，没有 preinstall、install、postinstall 或 prepare。README 仍然保留了那条通用提醒：pnpm 会执行生命周期脚本，只安装你信任的包。
• 网络与遥测。 README 说只有克隆本仓库和安装 Node 依赖需要网络；没有任何遥测说明，清单与 Host 源码里也没有分析类依赖。调度器启动的那些 session 能跑什么，属于 Harness 的权限模型，不归这个插件管。本次没有任何第三方对该包的安全扫描记录。
• 安装方式是「先构建再打包」。 README 的流程是 pnpm install、pnpm build、pnpm pack，然后 dsh plugin --profile web add -w <tarball>——其中 workspace 根标记被标为必需。因为 lib/ 被 gitignore，发布的 git 树里没有编译产物，README 两次警告不要把本仓库当作原始插件源直接添加。已发布的 npm tarball 里确实带有编译好的 lib/ 与 cordis.patch.yml，所以「按包名添加」看似可行，但 README 并未记录这条路径。

已知限制

• 版本滞后是最直接的风险。 仓库在 peer 里锁死 harness 0.1.2-alpha.2。它能否跑在更新的 harness 上，两份来源都没有说。
• 默认数据库路径不锚定 $DSH_HOME。 开着的 issue #23 报告它会在无关目录里静默建库，本次查看时维护者尚未回复。
• 工作流指派只是指导，不是执行；而配额处理被明确标注为不确定，因为 Harness 目前没有主动配额信号。
• docs/security.md 是设计说明，不是审计结论，README 也没有给出任何安全审查状态。
• 星数不等于维护：327 stars、8 forks，最近一次提交是 2026-08-31。

什么时候用它、什么时候不要用

如果你希望 agent 的工作落在一份持久、可检视的任务清单上而不是一次聊天轮次上，而且你特别想要一道 agent 点不过去的人类验收闸门，那就用它。认领加版本号的机制给了你一块重启也不丢的看板；又因为自动化复用的是普通 Harness session，你不需要再学第二套编排模型。

不要指望它替你管理仓库。它不会 commit、push、merge，也不会开 pull request；它自己只写数据库和附件目录，而它启动的 session 和你其他 session 一样，只是在绑定的 workspace 里改文件。

FAQ

agent 会把自己的任务标成完成吗？

不会。README 写明 agent 只能把已验证的工作提交到 in_review，只有经过认证的人类 UI 或 CLI 操作才能把它验收为 done。它从另一个方向又强调了一遍：Goal 完成不会验收任务，agent 的成功终态就是 in_review。面向模型的工具集刻意没有验收工具，也没有通用状态变更工具。

agent 是怎么领取一个任务的？

调用 taskboard_claim，传入 task_id 与当前精确的 expected_version。只有合格的 todo 能被领取，服务会在同一个事务里重新检查依赖、归档状态与排他开发上下文。版本已经变动时插件返回 TASK_STALE_VERSION——此时应重新读取而不是重试；孤儿认领会保持可见、交给人来处理，而不是被悄悄改派。

它能配我这版 harness 吗？

这正是悬而未决的地方。README 声明的兼容 Host 是 DeepSeek Harness 0.1.2-alpha.2，peer 依赖又把一长串 @deepseek-ai/* 精确锁在那个版本上。对其他任何版本（包括更新的版本）的兼容性，两份来源都没有结论。

说它「不是第二套聊天运行时」，是因为它没有 agent 能力吗？

恰恰相反。它确实驱动 agent session：启用自动化后，调度器会认领 todo 并驱动一个 root agent session 与 Goal，最终停在 in_review。那句话的意思是：插件复用了 Harness 既有的 session、Goal、Workspace 与权限机制，而没有自带第二套运行时。架构文档说得很精确——驱动从不 import agent-loop，而是通过公开服务创建或恢复 root agent。

我的数据会离开本机吗？

已记录的行为都不会。README 说只有克隆仓库和安装 Node 依赖需要网络；唯一的运行期依赖是 zod，包里和 Host 源码里都没有遥测或分析库。任务状态是本地 SQLite 文件，附件是本地目录。

能备份吗？能搬家吗？

能。把 SQLite 文件、在线时的 WAL 文件以及附件目录一起复制，先停掉 Harness 以获得一致的离线备份。要换位置就停掉 Harness、把两者搬过去，再把 databasePath 与 attachmentRoot 指向新路径。注意默认的相对路径——想让位置可预期，就设成绝对路径。