dsh-workplan

dsh plugin --profile web add dsh-workplan

dsh-workplan

两个卖点，一句话：ISO/IEC 15408:2026 全套安全证据，5 条命令自己验；安装一条命令、零第三方运行时依赖。



给 DeepSeek Harness（DSH） 加一段「先拆计划 → 真派部门子 Agent 去做 → 左侧栏实时看进度」的能力。不装 App、不改 DSH 源码、不换页面。

• 对话里先出【任务分解】：阶段、子任务、部门、验收标准，一样不缺
• 最多 5 个真实子 Agent 并行执行，结果写回会话
• 左侧栏「任务进度」：谁在做、做到哪、哪件卡住了

English (US) — plain-language guide: [README.en.md](README.en.md)

---

为什么敢拿 ISO/IEC 15408 当卖点，又不算吹牛

CC（Common Criteria，ISO/IEC 15408）的规矩是三方分工：开发者交材料 → 独立实验室评测 → 国家机构发证。软件不能给自己发证。 所以「本插件已通过 CC 认证」这句话，没有证书编号就是假的——这种话我们不说。

我们做的是能自己做的那一半：按 2026 版（不是 2022 版）标准的结构，把材料真做出来、公开出来，任何人都能自己核对。

我们公开的 · 对应标准 · 在哪儿

保护什么、防谁、边界在哪 · 安全目标（ST） · [docs/cc/SECURITY-TARGET.md](docs/cc/SECURITY-TARGET.md)

攻击面、7 条威胁、对策、残留风险 · 脆弱性评定（AVA） · [docs/cc/AVA-VULNERABILITY-ANALYSIS.md](docs/cc/AVA-VULNERABILITY-ANALYSIS.md)

逐类对照 + EAL1 就绪度 + 还缺什么 · 自评估 · [docs/cc/CC-2026-ASSESSMENT.md](docs/cc/CC-2026-ASSESSMENT.md)

第三方组件、许可证、哈希 · 生命周期（ALC） · [docs/SBOM.md](docs/SBOM.md)

漏洞怎么报、多久回、部署怎么配 · 安全策略 · [SECURITY.md](SECURITY.md)

470 项自动化测试（2026-11-03 独立复检实测 470/470 全绿），一条命令复跑 · 测试（ATE） · npm run verify

现状（2026-11-03 独立复检报告结论，33 条差距逐条复核）：26 条已关闭（通过）；4 条经判定为「不适用或固有残留」且判定本身成立；1 条（发布包 sha256 数值）属发布期执行件，脚本已就绪、随发布公布。无新发现的代码类缺口。必须如实披露的固有残留：ATE_IND.1（测试执行需认可实验室见证）与 AVA_VAN.2+（独立渗透评测）——按 CC 规则只能由认可实验室完成，本项目以「公开自评估」口径如实标注，任何宣传材料都不省略这条。

版本口径（两个头都有官方来源佐证）：证据包按 ISO/IEC 15408:2026（已列入 ISO 官方目录）的结构编写；现行国家认证体系（如德国 BSI）受理的版本仍为 CC:2022。所以我们说「对齐 2026 结构、认证体系现行受理 CC:2022，公开全套自评证据 + 完整安装使用方法」，不说「已通过 CC 认证」。

自己验，3 行，复制即用：

git clone https://github.com/abbaababa/dsh-workplan.git && cd dsh-workplan
npm ci && npm run verify                                  # 期望：tests 470 / pass 470 / fail 0
grep -RInE "child_process|execSync|eval\(|writeFileSync" src || echo "0 命中（预期）"

一句话记住：有证书是第三方给的，有证据是自己挣的。

自我更正记录：v1.8.1 公开更正了 v1.8.0 里三处「文档写得比代码多」的地方（图表路由其实不鉴权、自测并未覆盖鉴权与截断分支、EAL1 矩阵把一个自相矛盾的组件判成就绪），详情见 [CHANGELOG](CHANGELOG.md) 与 [自评估 §6.1](docs/cc/CC-2026-ASSESSMENT.md)。

它到底做了什么（用大白话讲）

平时你给 AI 一个复杂任务，它经常「一边想一边做」，做到一半你才发现方向不对。

这个插件把节奏改成三拍：

1. 先排计划：你发出任务后、AI 真正动手前，它先写一份计划——分几个阶段、每个阶段几件具体工作、每件工作交给哪个部门、怎么做、什么算做完、可能卡在哪。

2. 计划先给你看：这份计划以「任务分解」的形式出现在对话里，包含每一步的依据与验收标准，而不是一句话糊过去。

3. 真的派人去做：确认后，每一件具体工作交给一个真实的 DSH 子 Agent 去执行（最多 5 个同时跑），结果写回会话；你在左侧栏「任务进度」里随时能看到谁在做、做到哪、哪件卡住了。

计划不是装饰品：主 Agent 必须先派发、等到部门结果回来，才能继续往下答。

装之前你需要什么

要求 · 说明

DeepSeek Harness · 官方 Web 版（dsh web / --profile web 跑的这套）

Node.js · 22 或更高（node -v 自查）

网络 · 安装时需要能访问 npm registry

一键安装

dsh plugin --profile web add dsh-workplan@2.1.3

装完重启一次 DSH Web（或重新载入当前页面）让插件生效。

没有 dsh 命令的话，先确认它在 PATH 里；用 npx 起的 DSH 可以直接用完整路径调用同一个 dsh。

从源码安装（可选，想改代码时用）

git clone https://github.com/abbaababa/dsh-workplan.git
cd dsh-workplan
npm ci && npm run build
dsh plugin --profile web add "$(pwd)"

装好以后怎么用（小白版）

1. 打开 DSH Web，随便发一个有实际目标的任务，例如「帮我把这个目录的测试补到 80% 覆盖」。

2. 等一两秒，对话里会出现一块【任务分解】：阶段、子任务、部门、验收标准齐全。

3. 你只需要正常对话；主 Agent 会按规则派发计划，遇到要拍板的地方会问你。

4. 点左侧栏的「任务进度」，就能看到：

• 顶部五个数字：几个任务 / 分配了多少件工作 / 做好了 / 正在做 / 卡住了；
• 计划卡：分「进行中」「已结束」「已完成」三组，右上角是完成率。「已结束」= 这一轮已经停了（没有东西在跑）但计划还没做完，卡片会写清停在哪儿（预算用完 / 卡住了 / 还没开始），说一句「继续」即可接着推进；
• 展开任意计划：每个阶段的进度、每件具体工作由哪个部门负责、当前状态。

5. 进度数字背后的每一行，都来自同一份任务状态——不会再出现「显示 0 个正在做、但下面明明写着正在做」这种自相矛盾（1.4.3 专门修的就是这个，见下文）。

纯打招呼、道谢、问「做到哪了」不会触发拆解，不会平白多出一堆子 Agent。

九个模型工具（你不用直接调用）

工具 · 作用

dsh_workplan_dispatch · 派发当前计划，把结果写回会话。默认 mode:"wait" 等结束；mode:"async" 立刻返回、后台继续。重复调用是幂等的。

dsh_workplan_status · 只读：问到哪了。重启或刷新后也能从会话记录重建。

dsh_workplan_update · 主 Agent 核对结果、修正某个子任务状态与证据。带 expectedRevision 防覆盖，运行中默认拒绝（force:true 才覆盖）。子 Agent 不能调用。

dsh_workplan_cancel · 取消还没派发的计划，不会伪造任何「已完成」。

dsh_workplan_replan · 需求变更时就地修订：cancel / replace / add，旧行标为「已取代」保留可追溯，计划版本号递增。主 Agent 专用。

dsh_workplan_escalate · 子 Agent 执行中遇阻上报：问题、选项、建议进状态机，等主 Agent 指示；不再是「只能憋到结尾写 BLOCKED」。

dsh_workplan_instruct · 主 Agent 回答请示并下达指示；失败则挂起，子任务下次激活时注入。带 60s/180s 回执检查。

dsh_workplan_handoff · 处置跨部门需求：list / assign / resolve / close。未处置会拦住交付；对「待指示」的行 resolve 会直接把答复投递给子会话。

dsh_workplan_followup · 给预算/超时中止、但产物已落盘的直接子会话补一条收尾说明。

在 plan 模式下只会给你看计划，dispatch 会被明确拦下并说明原因，不会偷偷开跑。

部门怎么协作（1.11.0 的真实能力）

计划里的每件工作都带一个部门标签（工程研发、研究分析、设计、产品、数据、质量验证、安全、运维、文档写作、运营、法务合规、财务）。标签决定提示词与统计口径，不是组织架构：

• 部门之间不能直接对话（这是刻意的权限边界）；跨部门信息由主 Agent 转达，或落到双方都能读的工作区文件。但每个子 Agent 的提示词里会带上兄弟部门的只读一览（谁、做什么、产出什么、已完成摘要），需要协作就写进 needs；每条 needs 会自动登记成带编号的跨部门需求（open → routed → answered/closed），结果消息与 status 都能看到，未处置就拦住交付。主 Agent 用 dsh_workplan_handoff 逐条处置；提出需求的行若正在等指示，resolve 会把答复直接投递给该子会话。
• 下游只看到 dependsOn 里上游的摘要与完整体检结果，看不到上游的完整对话。所以上游必须把「产物绝对路径 + 怎么验收」写进摘要；声明为 file 的产物会被逐个核实，缺失就不给下游解锁。
• 子 Agent 在输出末尾回传结构化证据块（status / acceptance / artifacts / needs）。非空输出不再等于完成：partial、任一条验收失败、坏块都判受阻，只有全 pass 才可直接采信，其余在结果消息里标「未验证」等主 Agent 核对。
• 阶段（stage）只是展示分组，不是执行门槛；真正决定先后的是 dependsOn。

完整的角色、数据契约、状态机、失败恢复与「改代码时必须同步的三处」，见 协作契约；12 个部门的职责与交接清单见 部门职责与交接约定。

预算、超时与续跑（知道这些就不会误以为卡死）

项 · 默认值 · 怎么改

单轮派发预算 · 20 分钟 · DSH_WORKPLAN_TOTAL_TIMEOUT_MS

单个子 Agent 上限 · 15 分钟 · DSH_WORKPLAN_CHILD_TIMEOUT_MS

子 Agent 无进展判定 · 5 分钟 · DSH_WORKPLAN_IDLE_TIMEOUT_MS

自动续跑次数 · 4 次 · DSH_WORKPLAN_MAX_RESUMES

并发子 Agent · 5 个（固定） · —

预算用尽不是失败：计划会变成「本轮预算用尽，可续跑」，已完成的不重跑，剩下的下次接着做。被判定卡住的子任务只卡它自己，不会拖垮整个计划；重试只会发生一次，第二次的提示词会带上一次的失败原因，不会原样重撞。

环境变量写在启动 DSH 的那个 shell 里，或者写进插件配置：

// cordis.pat

…(truncated)