工作流管家 Rx12453345/dsh-workflow-manager

dsh-workflow

为 DeepSeek Harness（DSH）打造的分层、可完全开关的智能体工作流框架。它把 Harness-Engineering 的核心机制——上下文隔离、独立评审、风险分级审批、约束退役——变成一段配置，于是「让流程适配这个任务」变成改配置，而不是改提示词。

设计宪法：人是懒的。
每个机制都能一句话关掉。默认配置开箱即用。需要人拍板的地方尽量少，而且都是真正需要判断的地方。

为什么要有它

长时间运行的智能体任务会以几种方式失败，而这些靠多写提示词是修不好的：

- 上下文污染。 评审来回一轮很长，而且大部分跟任务无关；这些内容一旦发生在主对话里，信号就被淹没了。
- 自我认证。 智能体给自己的活打分，永远是通过。Anthropic 的 harness 研究说得很直白：自我评估的生成器就是在「给自己的作业打分」。
- 无界 harness。 约束会一直堆积。Mitchell Hashimoto 的规则是——智能体犯了错，就改系统，让它再也犯不了这个错——照这条规则做出来的系统只会不断膨胀，除非每条约束都带一个退役条件。
- 一刀切的严格度。 改一行 CSS 也跑完整评审循环，成本跟重写审批门一样，流程就是这么被抛弃的。

dsh-workflow 把针对这四个问题的解法打包成可开关的机制，再加上一个阶段状态机和一份产物契约，让「已验证」有实际含义，不是随便声称就能糊弄过去的。

这个插件在项目主动启用之前是惰性的。 只有当项目里存在 .dsh/workflow.yml 时，它才会对该项目激活。安装它不会改变任何现有对话的行为。

它能做什么

- 阶段状态机 —— INIT → PLAN → PICK → NEGOTIATE → BUILD → VERIFY → EVALUATE → COMMIT → HANDOFF，项目自己的传感器不通过，就拒绝进入 BUILD。
- 独立评审 —— workflow_review 启动一个全新的子代理，它没写过这些代码，按声明的维度打分，并在配置的 mustPass 维度上行使否决权。只有本次会话真正跑过的评审，才能把功能标记为完成。
- 评审指纹 —— 对评审过的文件做哈希。评审之后再改这些文件，审批即失效。
- 上下文隔离 —— 评审来回在委派的子进程里跑，只返回摘要，不占用主对话。
- 风险分级审批门 —— low 放行，medium 按配置的强度处理，high 一律拒绝，靠一个单调守卫实现，后面的监听器再怎么改也翻不回 allow。
- 带退役机制的约束台账 —— 约束记录时会带上 retire_when 条件。GC 只负责建议，绝不自动退役。自然语言的退役信号一律报告为需要人工处理，绝不报告为已满足。
- 基于风险的验证深度 —— 可选地，变更类别（docs / ui / logic / security）声明验证必须做到多深，框架会把声明和实际改动的文件做比对。

安装

插件在工作区里开发，但 DSH 配置档在工作区之外，所以只能手动安装。

1. 把依赖加进配置档的 package.json —— 用目录路径，不要用 tarball，这样改代码就不用重新打包：

"src-12453345_-dsh-workflow": "file:D:/DSH/P5/src-12453345_-dsh-workflow"

2. 把包名加进配置档的 bundles 数组，和其他 bundle 放在一起。

3. 在配置档目录里安装，然后重启 DSH：

cd <profile>
pnpm install

插件的 cordis.patch.yml 由加载器自动追加；配置档的补丁里不用手动加任何东西。

file: 依赖是副本，不是符号链接 —— 改完插件代码必须重新复制并重启。见 docs/USAGE.md。

安装后应该看到什么

插件会挂载三行 Loader，每行都能单独开关：

| 行 | 包 | 职责 |
| dsh-workflow-module | src-12453345_-dsh-workflow | 只做声明。它的存在是为了让浏览器那一半能被发现 —— 见 docs/PITFALLS.md。 |
| dsh-workflow-core | src-12453345_-dsh-workflow/core | 六个面向模型的工具、阶段状态机、审批闸门。 |
| dsh-workflow-panel | src-12453345_-dsh-workflow/panel | 掌管面板命名空间和侧边栏入口。 |

宿主日志行 dsh-workflow: core mounted. services: tools=yes, systemPrompt=yes, subagent=yes, settings=yes, approval=yes 确认挂载成功。

快速开始

在想用工作流的项目里：

1. 让项目选择启用。 让模型初始化工作流，或者调用 workflow_init。这会创建 .dsh/workflow.yml。在这个文件存在之前，项目里什么都不会发生。
2. 照常提需求。 不用说「用工作流」—— 模型会看到项目已经选择启用。
3. 要求独立验证。 唯一要紧的一条：干活的人不能自己宣布干完了。
4. 看项目标签页（「工作流（本工程）」），查看这个项目实际生效的值，以及哪些是项目覆盖、哪些是继承的默认值。

完整走查、三个界面和 FAQ 都在 docs/USAGE.md。

六个工具

| 工具 | 做什么 | 会写入吗？ |
| workflow_status | 报告阶段、生效配置、解析出的验证深度、服务可用性和主机诊断信息。只读。 | no |
| workflow_init | 创建 .dsh/workflow.yml，让项目选择启用。幂等、原子。 | yes |
| workflow_set | 读取或修改某个项目级参数，带路径和枚举校验。项目没有选择启用时，拒绝写入。 | yes |
| workflow_review | 启动一个全新的审查者子代理，给出独立结论。接收变更类别和 changed_files/diff，这样声明能被核实，而不是被采信。 | 记录结论 |
| workflow_advance | 驱动阶段状态机。拒绝非法转换，并列出合法的转换。这是唯一能把功能标记为完成的路径，而且只能基于本次会话跑过的审查。 | yes |
| workflow_gc | 约束台账：显示哪些约束该退役了。只实现了 scope=constraints；其他 scope 会拒绝，而不是假装支持。 | 先询问 |

架构简述

config (defaults) ──► project .dsh/workflow.yml ──► per-call arguments
│
▼
phase machine (lib/advance.js)
│
┌─────────────────────┼──────────────────────┐
▼ ▼ ▼
artifact contract independent review approval gate
(features / state) (fresh subagent) (pre-execute)

- 主机侧（lib/index.js、lib/config.js、lib/tools.js、lib/gc.js、lib/review.js、lib/approval.js、lib/advance.js、lib/gate.js、lib/work-unit.js）注册工具，并持有全部状态。
- 浏览器侧只有一个手写的 lib/client.js —— 一个懒加载 CJS 包，通过 window.__ModuleLoader__.load({ id, factory }) 加载。它同时注册插件设置页和侧边栏入口。不需要官方构建工具链。
- 状态用 JSON，叙述用 Markdown。 .dsh/FEATURES.json、.dsh/WORKFLOW.json、.dsh/CONSTRAINTS.json 归机器所有；给人看的文档是另外的文件。

架构、完整设计理由，以及这些决策背后的每一份第一方来源：docs/DESIGN.md。

验证状态

在这里，如实说明已经证明了什么，比打磨措辞更重要，因为这个项目有过一段有据可查的历史：文档声称的东西并不属实。

- 单元测试套件：493 个测试，492 通过，0 失败，1 跳过 —— 在本仓库运行 node run-unit-tests.mjs 验证。唯一的跳过是 Windows 独有的限制（该平台没有可捕获的 SIGTERM），不是失败用例。
- 变异测试是体现测试有杀伤力的那一层：七个 mutation-check-*.mjs 测试装置注入缺陷，要求测试套件变红，然后逐字节还原源码。它们绝不能并发运行 —— 共享锁会拒绝第二个。
- verification.policy 默认是 off。 这个功能不启用就什么都不做；报告只供参考。别把 class/depth 表当成实际生效的行为来读。
- 部署没法由智能体自己完成。 sync-to-profile.mjs 仍然被当作不透明脚本拒绝，而自部署豁免——它覆盖的是带显式路径的文件工具——也没法授权它自己的首次部署，因为正在运行的那份副本早于豁免存在。首次部署需要人工带外复制一份，或者由一个不受这道门管控的会话来复制。

未验证、以及刻意不实现的条目都列在 docs/ROADMAP.md 里，而不是暗示它们能用。

文档

每份文档只干一件事。

| 文档 | 职责 |
| docs/GETTING-STARTED.zh-CN.md | 中文入门指南。 给不配置软件的人看：记住两句话，每种项目该说什么，觉得慢的时候怎么办。 |
| docs/USAGE.md | 给用户。 四步起步、三个界面、九个阶段、常见问题。 |
| docs/DESIGN.md | 为什么这样设计。 设计决策，以及背后的第一手来源。 |
| docs/PITFALLS.md | 哪里出过错。 每一个踩过的坑，附根因和修法。 |
| docs/TESTING.md | 怎么验证改动。 六层验证和深度策略。 |
| docs/ROADMAP.md | 哪些还没做。 未验证条目、刻意不实现的部分、已知欠账。 |
| CHANGELOG.md | 用户可见的变更，最新的在前。 |
| CONTRIBUTING.md | 改动算完成之前必须跑什么。 |

开发

cd D:\DSH\P5\src-12453345_-dsh-workflow

node run-unit-tests.mjs # the full unit suite
node run-smoke-test.mjs # full apply/execute/render chain on a fake ctx
node run-config-check.mjs # patch values vs code defaults
node tooling/validate-tool-definition.mjs # run the SHIPPED registry validator on our six definitions
node tooling/simulate-client-scan.mjs # will the browser half be discovered?

在认为改动完成之前，先读 CONTRIBUTING.md。简短版：一个没法让它变红的测试不算测试，而「测试套件是绿的」从来都不足以断定插件能用。

许可

MIT。