dsh-failure-lens — distinguish Windows sandbox spawn EPERM from test assertion failures

[ArmyWas]

Unofficial project, independently developed and maintained by a community member.

Project: https://github.com/ArmyWas/dsh-failure-lens
Release: https://github.com/ArmyWas/dsh-failure-lens/releases/tag/v0.1.1

The real pain

While dogfooding dsh-plugin-reducer on Windows, I ran npm test inside a normal Harness workspace-write sandbox. Six test files were shown as failed, but no test body had started: Node/esbuild was blocked while spawning a child process with piped stdio.

The durable event was a tool/result with isError: false, a non-zero exit code, and repeated stacks containing all four markers:

1. Error: spawn EPERM
2. code: 'EPERM'
3. syscall: 'spawn'
4. node:internal/child_process

That presentation makes an infrastructure boundary easy to misread as broken test assertions.

What the plugin does

dsh-failure-lens keeps the original tool result and adds a separate Conversation Node immediately beside it:

• Harness 沙箱限制 / Harness sandbox limitation
• “The test never started; this does not mean a test assertion failed.”
• A safe recommendation to retry outside the sandbox only after user approval

This is a deterministic read-only explanation, not a workaround for the sandbox restriction. It makes no model call, writes no session state, sends no telemetry, auto-approves nothing, does not patch the DOM, and does not hide or duplicate the raw output.

Why this is not a duplicate

dsh-fail-logger is adjacent but records thrown failures into a long-term skill and explicitly excludes non-zero shell exits. This observed result is isError: false. Failure Lens writes no skill and only explains this four-condition signature in the current conversation.

Harness integration and verification

• Public APIs only: conversationEvents.register, slots.inject('conversation.chat.node', ...), and locale.register.
• Standard dsh.client lazy-CJS bundle plus dsh.bundle.patch profile integration.
• 32/32 tests, including the real-event-derived fixture and negative lookalikes.
• GitHub Actions passes on Node 22 and 24.
• Installed into the real Web profile and reacted to a fresh genuine spawn EPERM result.
• The prebuilt v0.1.1 release was installed from a clean DSH home; profile composition and peer checks both passed.

dsh plugin --profile web add https://github.com/ArmyWas/dsh-failure-lens/releases/download/v0.1.1/dsh-failure-lens-0.1.1.tgz

Maintainer feedback requested

1. Is a narrow out-of-tree Conversation Node the right long-term home for this signature?
2. Would the core UI benefit from a generic, evidence-based “infrastructure failure vs. test assertion failure” explanation seam?
3. If more users confirm the same signature, would maintainers prefer an upstream patch to the official conversation/sandbox UI or continued iteration as a community plugin?

中文摘要

这是一个来自真实 Harness 使用痛点的只读 Web 插件：Windows 沙箱阻止 Node 子进程启动时，界面可能把所有测试文件显示为失败，让用户误以为测试断言坏了。插件只有在四项高置信证据同时出现时，才在原始工具结果旁增加“Harness 沙箱限制”提示，并明确“测试根本没有启动”。

它不绕过沙箱、不自动审批、不调用模型、不写日志、不做 DOM 补丁。已完成 32 项测试、Node 22/24 CI、真实 Web profile 安装回放，以及 GitHub Release 的全新环境安装验证。希望官方反馈：这一能力更适合继续作为窄插件，还是在收集更多证据后进入官方会话/沙箱 UI。