前言¶
在 DSH 里让智能体写测试和实现代码时，常见做法是口头约定「先写失败测试再写实现」。模型仍可能跳过 RED、改测试凑绿，或在没有真实测试命令的情况下宣称通过。DeepSeek Harness 采用插件化扩展；社区目录 skillhub.cn 上的工作流类插件，可以把阶段约束落到 ToolRuntime 工具与本地子进程证据上。
下面介绍维护者 LIghtJUNction 发布的 @lightjunction/dsh-red-green（仓库 LIghtJUNction/dsh-red-green）。它在用户明确请求 TDD 之后，才启动 RED → GREEN → REFACTOR → COMPLETE 循环，用固定测试命令的输出与文件内容指纹绑定证据，而不是默认接管每个会话。
这是什么¶
一句话定位：面向 DSH 0.2.1-rc.2、Node 24+ 的可选 TDD 工作流插件（简介：Evidence-driven RED GREEN REFACTOR workflow for DSH）。
加载插件后，每个会话默认处于 idle；只有用户在对话中明确要求使用 TDD 时，调用方才应带 userRequested: true 启动周期。Real ToolRuntime 工具会执行你声明的测试命令，并把结果与跟踪文件内容关联。
核心功能¶
显式 opt-in¶
插件不会在加载后自动进入 TDD，也不提供默认 TDD 提示或强制 TDD。周期由 tdd_start 开启，由 tdd_reset 结束并移除守卫；tdd_reset 不会回滚磁盘上的文件。
四阶段与 revision¶
典型推进方式：
- 先创建测试文件（以及你声明的源码路径）。
- 用户说「use TDD」或等价明确请求后，调用
tdd_status、tdd_start。 - 每次改代码后调用
tdd_run，使用上一次结果返回的revision作为下一次变异的参数。 - 识别到失败的断言后，从 RED 进入 GREEN，并锁定测试内容；实现通过后进入 REFACTOR，再运行直至 COMPLETE。
tdd_status 会报告自上次证据以来，跟踪文件是否相对快照发生变化。调用会拒绝过期的 revision 与重叠的变异。
RED 阶段的工具守卫¶
在 RED 阶段，插件会限制名称中包含 write、edit、patch、bash、shell、exec 或 terminal 的工具。仅允许对声明列表里、且路径完全匹配的测试文件做编辑；实现代码与 shell 类工具在观察到失败测试之前会被拒绝。RED 之外，工作流约束多为建议性质；自定义工具别名、直接写主机文件或其他插件的编辑不在守卫边界内。
证据与指纹¶
测试、源码以及 root 内的 symlink 目标会被指纹化；遍历或指向 root 外的 symlink 会被拒绝。测试命令运行期间若跟踪文件被改动，结果会被丢弃。RED 之后若再改测试内容，需要 tdd_reset 后重新开始。非零退出码加上可识别的失败文本（如 not ok、AssertionError、FAIL/FAILED 或失败计数）用于启发式判断 RED；语法或模块错误不会推进 RED。GREEN/REFACTOR 依赖退出码为零，应配置真实测试 runner，不要用空操作命令。标准输出/错误仅保留最后 64 KiB。
作用域与生命周期¶
每个周期绑定到 agent 与 canonical workspace；无 agent 的调用有独立状态。Abort、超时、卸载会终止并回收 Unix 进程组；agent 销毁会移除其周期。状态在内存中，卸载即消失；无磁盘历史、覆盖率、Pi TUI、斜杠命令或手动绕过证据。
安装与启用¶
要求：DSH 0.2.1-rc.2、Node >= 24。安装包内含 dsh.bundle patch；若 profile 未启用 HMR，安装后需重启 DSH。
README 给出的安装模式（说明为 pattern，不表示该 release 一定已发布）：
dsh plugin --profile headless add https://github.com/LIghtJUNction/dsh-red-green/releases/download/v0.1.0/lightjunction-dsh-red-green-0.1.0.tgz
可选 profile 配置（cordis.patch.yml 中示例）：
- id: dsh-red-green
name: '@lightjunction/dsh-red-green'
config:
root: /absolute/host/project
timeoutMs: 120000
root 默认为调用 agent 的工作目录；无 agent 的调用必须设置 root。timeoutMs 范围为 100–600000 ms。TypeScript 直接注册时使用 import * as plugin 与 await ctx.plugin(plugin, { root, timeoutMs: 120000 })。
包版本在 package.json 中为 0.1.0，许可证 MIT。
典型用法¶
README 示例：先建测试文件，用户明确要求 TDD 后依次调用：
tdd_status {}
tdd_start {"revision":0,"userRequested":true,"task":"return one","command":["node","--test","test/example.test.cjs"],"tests":["test/example.test.cjs"],"files":["src/example.cjs"]}
tdd_run {"revision":1}
后续每一步使用返回的 revision。实现行为后再次 tdd_run 进入 REFACTOR，重构后再运行直至完成。需要停止周期时：
tdd_reset {"revision":4}
（示例中的 revision 需与当前会话实际返回值一致。）
适用场景与注意¶
适合：已在本地用 Node 跑真实测试命令、希望 agent 在 DSH ToolRuntime 内按 RED-GREEN-REFACTOR 推进、并愿意在用户口头 opt-in 后再启动周期的开发者。
环境与限制（摘自 README Limits）：
- 仅支持主机本地 Node 文件系统与子进程；远程 DSH world/sandbox 不支持。命令继承 DSH 主机环境，以主机权限运行，未沙箱化；无 shell 展开，显式调用 shell 时 shell 同样享有主机权限。
- 所有跟踪文件必须事先存在；须在
tdd_start中声明相关源码、测试与 fixture；未跟踪的依赖、并发编辑在最终快照前被还原等情况无法检测。快照是内容校验，不是 OS 级事务，也不能防 hostile symlink 竞态。 userRequested: true由调用方断言，插件无法证明人类已请求；工具描述要求模型必须取得用户明确请求。- 仅 Unix；Windows 进程生命周期未实现。安装前请阅读仓库源码与 LICENSE，确认命令不会打印密钥等敏感信息。
社区目录页：skillhub.cn - LIghtJUNction/dsh-red-green（独立站点，与 DeepSeek / 幻方无官方从属关系）。源码与问题跟踪：GitHub。
结尾¶
@lightjunction/dsh-red-green 把 TDD 循环做成 DSH 里可选、证据驱动的工作流：真实测试命令、revision 协议、RED 写守卫与文件指纹，用于减少「没跑测试就宣称完成」的漂移。默认不打扰 idle 会话；需要时在用户明确请求后 tdd_start，按 tdd_run 返回的 revision 逐步推进即可。
