Handle Antigravity .cmd execution on Windows

Context

PR #11764 narrowed #10684 by making Antigravity CLI path resolution portable and verifying the Linux executable path with the existing mock-executable harness pattern. During cross-family review, @neo-opus-ada identified the remaining Windows-specific execution gap: the Windows resolver naturally finds antigravity.cmd, but the shared spawnAsync() helper currently calls spawn(cmd, args, { stdio: 'ignore' }) without a Windows shell strategy.

This ticket preserves that remaining work as a focused Windows follow-up instead of letting PR #11764 claim full Windows execution before a safe .cmd/.bat execution strategy exists.

The Problem

On Windows, Node cannot execute .cmd or .bat files through plain child_process.spawn(file, args) without a shell/cmd.exe execution layer. If resumeHarness.mjs routes @neo-gemini-pro into the antigravity-cli adapter and resolves antigravity.cmd, the current executor can fail with EINVAL rather than producing the controlled Antigravity diagnostic used for missing executables.

The obvious fix, shell: true, is not a free win: the boot-grounding payload flows through the command arguments and can contain shell-significant characters. The Windows path needs a deliberate command-line construction/quoting strategy or an equivalent safer execution substrate, plus test coverage that proves the win32 resolution branch is exercised.

The Architectural Reality

• ai/scripts/resumeHarness.mjs owns the fresh-session harness recovery adapters.
• resolveAntigravityCliPath() in PR #11764 owns env-var, platform-candidate, and PATH lookup resolution for Antigravity.
• spawnAsync() is the shared execution helper for harness adapter process launch.
• The current unit suite lives in test/playwright/unit/ai/scripts/resumeHarness.spec.mjs and can mock executable dispatch in-sandbox, but cannot provide full L4 proof of a real Windows Antigravity host launch.

The Fix

Implement a Windows-safe .cmd/.bat execution path for the Antigravity CLI adapter:

1. Decide the execution primitive for Windows batch wrappers: scoped shell: true, explicit cmd.exe /d /s /c, or a safer equivalent.
2. Quote/escape the chat -n <payload> command deliberately so boot-grounding payload content cannot become shell syntax.
3. Add focused unit coverage for the win32 resolution/execution branch using mock process-platform and mock executable patterns where possible.
4. Preserve Linux and macOS behavior from PR #11764.
5. Record the evidence ceiling clearly: unit coverage can prove resolution/dispatch shape; real Windows Antigravity host launch remains L4 post-merge validation.

Contract Ledger

Acceptance Criteria

• Windows .cmd/.bat Antigravity CLI execution no longer fails through plain spawn() EINVAL.
• The command construction treats the boot-grounding payload as data, not shell syntax.
• Unit coverage exercises the win32 Antigravity resolution/execution branch with a mock executable or command-capture strategy.
• Linux and macOS Antigravity CLI behavior from PR #11764 remains unchanged.
• PR evidence states the L2/L4 boundary explicitly, including the required real Windows Antigravity host probe.

Out of Scope

• Reworking the Codex or Claude non-macOS adapters.
• Replacing the Antigravity CLI adapter with a different transport.
• Adding a Windows CI runner.

Avoided Traps

Related

• #10684 — original cross-platform Antigravity CLI portability ticket
• PR #11764 — path-resolution + Linux execution scope
• PR #10680 — introduced the Antigravity CLI adapter
• Node child_process Windows batch-file execution behavior

Origin Session ID

2741c4bd-92b2-428b-92d3-ab718d9a7c41

Handoff Retrieval Hints

• query_raw_memories(query="PR 11764 Antigravity Windows cmd spawnAsync shell true")
• query_raw_memories(query="Antigravity CLI .cmd EINVAL Windows resumeHarness")
• Review anchor: PR #11764 review cycle 1 by @neo-opus-ada, PRR_kwDODSospM8AAAABAwwbQA.