fix(acp): resolve Windows ENOENT when spawning ACP agent process

[Lygggggg]

AcpClient.initialize() used bare child_process.spawn() which cannot find npm-global .cmd shims on Windows. Reuse the same 3-tier fallback from cli-spawn.ts: resolve .cmd → underlying .js script, then Git Bash shell, then cmd.exe shell. Skipped when custom spawnFn is injected (test path unchanged).

PR Type

• 🐛 Patch — Bug fix, typo, test gap (no Feature Doc needed)
• ✨ Feature — New capability or behavior change (requires Feature Doc)
• 📋 Protocol — Rules, skills, workflow changes (the doc IS the contribution)

Related Issue

Closes #401

What

• Modified AcpClient.ts to add Windows .cmd shim resolution using the existing 3-tier fallback from cli-spawn-win.ts
• Added regression test acp-client-windows-spawn.test.js covering the default spawn path on Windows

Why

On Windows, npm-global CLI tools like gemini are installed as .cmd shim scripts. child_process.spawn() without shell: true cannot locate .cmd files, causing ENOENT. The non-ACP path (cli-spawn.ts) already handled this; AcpClient did not.

Tradeoff

Could have used shell: true universally, but that introduces shell injection risk and is inconsistent with the existing strategy in cli-spawn-win.ts.

Test Evidence

$ pnpm check
✔ All checks passed

$ pnpm lint
✔ No type errors

$ node --test test/acp/acp-client-windows-spawn.test.js test/acp/acp-client.test.js
▶ AcpClient Windows default spawn path
  ✔ resolves .cmd shim to node + script.js when spawnFn is omitted (52ms)
▶ AcpClient Windows default spawn path (1 test, 1 pass)

▶ AcpClient
  ... (26 tests, 26 pass)

ℹ tests 27
ℹ suites 2
ℹ pass 27
ℹ fail 0

[zts212653]

Thanks for the fix. I checked the ACP path against our current Windows spawn helpers, and the bug itself looks real: AcpClient was still using a bare child_process.spawn(...), while the non-ACP CLI path had already added Windows shim handling for .cmd wrappers.

The fix direction here also looks right. Reusing the same 3-step Windows fallback (resolve shim -> Git Bash -> cmd.exe) is consistent with our existing cli-spawn-win.ts logic.

That said, I don’t think we should merge this PR as-is yet:

1. There is no open accepted issue linked to this PR. The historical Windows ENOENT discussion in #64 documents the same root cause, but that issue is already closed, and this PR body still leaves Closes # empty.
2. This change touches a branch that is not currently covered by AcpClient tests: the Windows + no-custom-spawnFn path inside initialize().
3. The PR also has no CI / test evidence attached yet, so the maintainer-side merge gate is still incomplete.

What I’d suggest before merge:

• reopen #64 or open a small follow-up issue specifically for the ACP-side Windows ENOENT path, then link it here;
• add one regression test that exercises the Windows ACP spawn branch in AcpClient.initialize();
• fill in the test evidence / checks in the PR body.

Once those are in, this looks like a good candidate to land.

— 缅因猫-gpt5.4

[zts212653]

Bug 确认真实：AcpClient 在 Windows 下确实漏了 .cmd shim fallback。这轮已经补了回归测试，并且我补推了 lint fixup；等当前 CI 全绿后就可以合。