测试闭环门控 freeze-F/dsh-test-closure

dsh-test-closure

为 DeepSeek Harness 提供的闭环：探测测试框架 → 运行测试套件 → 结构化汇总 → 在仍为红色时阻止回合完成 → 重试 → 释放或将会话标记为未解决。

该插件是一个 Cordis 插件包。它贡献三个模型工具和一个回合停止门控，并且自身不拥有任何服务。

它贡献的内容

| 行 | 类型 | 用途 |
| test_probe | 工具 | 检测 vitest / jest / npm 测试脚本 / pytest / node:test，而不运行任何内容 |
| test_run | 工具 | 在会话沙箱策略下运行测试套件，返回计数 + 逐用例失败信息 + 输出尾部 |
| test_closure_check | 工具 | 报告此会话是否满足完成条件 |
| agent/turn-stopping 监听器 | 门控 | 在最近一次运行仍为红色时，将纠正性消息引导回 agent |

安装

安装到某个 profile 中（这正是使该行成为组合一部分的方式）：

dsh plugin --profile web add /absolute/path/to/dsh-test-closure

然后将其列为该 profile 的 package.json 中的一个 bundle 层：

{
"dsh": {
"profile": {
"bundles": ["@deepseek-ai/dsh-base", "@deepseek-ai/dsh-web-app", "dsh-test-closure"]
}
}
}

bundle 层会在它所叠加的任何组合之上插入一行，因此无需编辑其他任何内容。可从后续层按 id 定位该行以重新配置或禁用它——补丁会替换该行的整个 config，因此请重新声明你需要的每个字段：

~/.dsh/profiles//cordis.patch.yml
- id: dsh-test-closure
disabled: true

- id: dsh-test-closure
config:
maxInterceptRounds: 1
summaryTailChars: 4000

它属于哪个平面

该补丁将行插入到 bundle 层，即宿主组合：该插件不发布任何服务，因此它不会与第二个会话冲突，并且它的回合停止监听器是一个按会话 id 键控的单一进程级监听器。
它同样可从 agent 预设中使用——它是 tools、 shell 和 sandboxPolicy 的纯消费者，因此不需要 isolate 领域——但预设本地的副本会让每个会话拥有自己的闭包状态，这只有在你想要按预设的测试策略而非按部署的测试策略时才有意义。

配置

由加载器在 apply 运行之前进行验证；任何 schema 无法表达的内容（整数性、正数性）都会在 apply 中被拒绝，并给出指明每个违规字段的消息。

| 字段 | 类型 | 默认值 | 含义 |
| maxInterceptRounds | 整数 ≥ 0 | 2 | 每回合允许的纠正性拦截次数 |
| defaultTimeoutMs | 整数 ≥ 1 | 120000 | 调用省略 timeout_ms 时的超时时间 |
| summaryTailChars | 整数 ≥ 0 | 3000 | 保留为 outputTail 的原始输出字符数 |
| enabled | 布尔值 | true | 总开关：false 时不贡献任何工具和门控 |

循环

test_probe → 框架、配置路径、测试文件、建议命令 test_run → { ok, summary{total,passed,failed,skipped}, failures[], outputTail } ↓ 红色 agent/turn-stopping ── 门禁 ──▶ agent.steer("…请修复后重新运行 test_run 验证。")
↓ 循环重新读取其下一步收件箱并运行另一步 test_run 再次 → 绿色 → test_closure_check 通过 → 该轮结束 ↓ 在 maxInterceptRounds 之后仍为红色轮次释放，会话标记为 unresolved

拦截实际是如何工作的

agent/turn-stopping 是一个串行事件：其监听器按顺序运行，其返回值不是否决权。文档化的异议渠道是
agent.steer(message) —— 循环在分发后立即重新读取其下一步收件箱，并在监听器放入内容时运行另一步。注入的消息携带插件来源标签
({kind:'plugin', plugin:'dsh-test-closure', form:'notice'})，因此它呈现为插件通知而非用户提示。

预算语义

预算按每轮计算，而非每会话 —— 契约规定“每轮最多可被拦截 maxInterceptRounds 次”。会话生命周期预算将意味着长会话早期两个不走运的轮次会静默地为其剩余部分禁用门禁。

因此 unresolved 是一个记录，而非开关：它报告某一轮在预算耗尽后仍以红色结束，并由 test_closure_check 呈现。后续轮次获得新的预算；一次通过的运行才是清除该标记的条件。在任何单轮内，门禁永远不会循环，因为预算限制了它，而新一轮需要新的输入。

门禁不做什么

它从不猜测。没有记录运行的会话会通过：门禁仅在有失败证据时才扣留完成。它也不监视文件系统 ——如果代码在一次绿色运行后发生变化而未重新运行测试，记录的判定保持绿色，直到下一次 test_run。

沙箱合规

test_run 本身不生成任何东西。它通过 ctx.sandboxPolicy.resolve({ session }) 解析调用会话的策略，并将命令交给 ctx.shell —— 与内置 bash 工具使用相同的接缝、策略、进程管理和输出预算：

const policy = ctx.sandboxPolicy.resolve(exec.agent === undefined ? {} : { session: exec.agent.session })
await ctx.shell.run(ctx.shell.resolve({
command, workdir: policy.workspaceRoot, timeoutMs,
dshEnv: ctx.shellEnv.collect(exec),
sandboxPolicy: policy,
signal: exec.signal,
}))

解析优先级由策略所有者决定：显式批准的模式优先于会话最近的 sandbox/mode 事件，后者又优先于部署默认值。工作区根目录和隔离范围从同一解析对象读取，因此它们不可能不一致。生成的策略模式会在每次运行时报告 (sandbox.mode)，而沙箱拒绝会按沙箱拒绝报告，而非按测试失败报告。
探针只读取：它以入口预算对工作区进行广度优先遍历，从不跟随符号链接目录，并跳过 node_modules、构建输出和 virtualenv 目录。

框架检测

首个匹配者胜出：

1. package.json 声明了 vitest
2. package.json 声明了 jest
3. package.json 有 scripts.test 条目
4. pytest 标记（pyproject.toml、pytest.ini、conftest.py、setup.cfg、tox.ini）
5. .test. / .spec. 文件，或 test/ 风格的目录

一项有文档记录的改进：当仅存在 Python 测试文件且没有任何内容声明 pytest 时，探针会回答 pytest 而非 node:test。规则 5 会指定一个根本不收集任何 Python 文件的运行器。

输出解析

每个运行器的默认报告器和紧凑报告器都会被解析：

| 框架 | 计数器 | 失败 |
| vitest | Tests 1 failed \| 3 passed (4) | FAIL file > name 块，× name + → message |
| jest | Tests: 1 failed, 3 passed, 4 total | ● name 块，✕ name |
| pytest | ===== 1 failed, 11 passed in 3.2s ===== | FAILED nodeid - message，traceback 段 |
| node:test | # tests 2（TAP）和 ℹ tests 2（默认报告器） | not ok N - name（TAP），✖ failing tests: 下的 ✖ name |

解析是全量的——无法识别的输出会产生空计数而非抛出异常——并且 ok 由进程结果决定，绝不通过解析决定：
ok = !timedOut && !aborted && exitCode === 0 && failed === 0。

test_run 参数

| 参数 | 含义 |
| framework | 覆盖检测：vitest / jest / npm-test / pytest / node:test |
| target | 以空格分隔的路径或节点 id，追加到命令中 |
| last_failed | 仅重新运行上一次运行报告为失败的用例 |
| command | 完整命令覆盖，原样运行；忽略 target 和 last_failed |
| timeout_ms | 本次运行的超时（默认为 defaultTimeoutMs） |
| run_in_background | 将测试套件作为作业启动并返回其 id |

last_failed 以每个运行器自己的方言表达：vitest/jest 用 -t ， pytest 用 -k ，node:test 用 --test-name-pattern。无法按名称过滤的运行器（npm-test）会退化为完整套件，并在 notes 中说明。

已知限制，全部通过 notes 报告而非被静默忽略：

- target 值作为路径过滤器传递；vitest 和 jest 在那里不接受裸测试名称。
- 后台运行在作业结束时记录其结果，因此门控会在下一次作业轮询时看到它，并且其 outputTail 由作业的流读取组装而成。

开发

npm install # dev dependencies, including TypeScript
npm run build # tsc: src/ → lib/, declarations to lib/types/
npm test # node --test test/*.test.mjs

测试套件有三层：

- 单元——解析（从真实运行器捕获的夹具）、探测、命令规划、闭包状态；
- 集成——针对桩上下文的真实 apply，因此 defineTool 真正编译两个 schema，并用一个假 agent 驱动该 gate；
- 真实运行时 —— 一个真实的 Cordis 应用（真实的工具注册表、真实的 ctx.shell、真实的子进程后端、真实的 ctx.sandboxPolicy）在临时工作区中运行一个真实的测试套件，包括 mount → red run → interception → fix → green → turn closes 这一序列。

设置说明

lib/ 已提交，因为 profile 通过路径或 URL 安装此包，必须能找到构建产物。每当 src/ 发生变化时，运行 npm run build 并提交结果。

运行时包是 peer 依赖，永远不会被打包：在运行时，它们从 dsh 安装的共享模块回退目录（$DSH_HOME/profiles/node_modules）解析。npm install 会获取与每个声明范围匹配的最新发布版本，这是获取构建产物的常规方式。若要针对某次部署实际加载的确切版本进行类型检查，请将 node_modules/@deepseek-ai 指向该安装自有的 node_modules/@deepseek-ai —— 这正是此工作副本所做的。

该插件在运行时需要 @deepseek-ai/cordis、@deepseek-ai/dsh-tools、 @deepseek-ai/dsh-llm、@deepseek-ai/dsh-shell、@deepseek-ai/dsh-sandbox-policy 和 @deepseek-ai/schemastery；它们被声明为 peer 依赖，并从 dsh 安装的共享模块回退目录（$DSH_HOME/profiles/node_modules）解析，而不是从此包中解析。