[PR #1936] [MERGED] test(clients): verify native Gemini CLI integration on Windows #4921

Closed
opened 2026-10-31 00:56:48 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/1936
Author: @pablodiazjorge
Created: 10/11/2026
Status: ✅ Merged
Merged: 10/12/2026
Merged by: @morluto

Base: main ← Head: feat/windows-gemini-verifier


📝 Commits (2)

  • 4e88262 test(clients): verify native Gemini CLI integration on Windows
  • 710560a test(clients): resolve the selected Gemini CLI entry point once

📊 Changes

2 files changed (+26 additions, -15 deletions)

View changed files

📝 docs/testing.md (+7 -3)
📝 scripts/verify-gemini-client.mjs (+19 -12)

📄 Description

Summary

Fixes #1935. verify:gemini-client asserted POSIX. With the assertion removed, Windows also needs a way to select the npm install's JavaScript entry point, because only a gemini.cmd shim reaches PATH, and two setup-plan checks compared paths with a hard-coded /. This makes the lane run on native Windows, as #1926 did for the Claude Code lane.

Problem and expected behavior

On win32 the verifier stopped at the assertion. Without it, the default gemini fails the preflight with spawn gemini ENOENT, and REA_VERIFY_GEMINI_COMMAND cannot name bundle/gemini.js because it is spawned as an executable. Once Gemini CLI runs, the dry-run plan checks fail: they build the expected prefixes as join(profile, ".agents", "skills") + "/" and profile + "/", while the planned targets use \ on Windows. Expected: the same lane runs on native Windows with the npm install's entry point selected.

Change and scope

  • scripts/verify-gemini-client.mjs:
    • remove the POSIX assertion;
    • run a selected .js, .mjs or .cjs entry point under the verifier's Node (process.execPath), for both the preflight and the client call; any other value is spawned as before;
    • build the two setup-plan prefixes with path.sep;
    • on win32, the preflight error names the entry point to select.
  • docs/testing.md: record 0.63.0 as verified on native Windows too, explain how to select the entry point, and drop native Windows from the unverified list of this lane.

Not included: running the .cmd shim through a shell, and the other client verifiers that still assert POSIX.

Contract and boundary impact

  • Semantic owner and earliest changed stage: the Gemini CLI client verifier script and its testing documentation.
  • CLI and MCP/tool-catalog contract: none.
  • Provider, bridge, target-format, or platform compatibility: the Gemini CLI client lane now runs on native Windows; no product code changes.
  • Evidence, artifact, provenance, or reconstruction contract: none.
  • Process execution, authorization, cleanup, or containment impact: a selected JavaScript entry point runs under the verifier's own Node instead of being spawned directly; the lane keeps its isolated GEMINI_CLI_HOME, Git project and loopback model fixture.
  • Generated metadata, package, or installation impact: none.

Evidence and regression coverage

  • Tests added or updated: none; the change is the verifier itself, executed below on native Windows.
  • Base reproduction or other evidence: on fb43dd97 the verifier exits on win32 at the assertion. With only the assertion removed and the entry point selected, it fails at the dry-run plan check that builds its prefix with /. With all the changes, every run below passed.
  • User-visible CLI/MCP output (if applicable): receipt fields from the Windows runs below.
  • Remaining proof gaps: live Google API compatibility stays unverified, as on POSIX; the POSIX lane was not rerun (its default command still takes the unchanged spawn path).

Validation performed

Windows 11 x64 (26H2), non-elevated, Node 22.22.3, on fb43dd97 (the branch was then rebased onto d802304c; none of the 11 new commits touch the verifier, its model fixture, verify-package-core.mjs or the client setup code, and the docs/testing.md change there is in another section):

  • npm ci, npm run build:cached — passed
  • node scripts/verify-gemini-client.mjs call with REA_VERIFY_GEMINI_COMMAND set to the npm-installed Gemini CLI 0.63.0 bundle/gemini.js — passed: catalogSize 172, schemasChecked 172, evidenceSeen true, skillLoaded true
  • node scripts/verify-gemini-client.mjs chat with the same entry point — passed: catalogSize 172, schemasChecked 172
  • node scripts/verify-gemini-client.mjs call without REA_VERIFY_GEMINI_COMMAND — fails at the preflight with spawn gemini ENOENT and the new Windows hint

WSL Ubuntu, Node 24.18.0:

  • npm run check:fast — passed
  • npx oxfmt --check scripts/verify-gemini-client.mjs docs/testing.md — passed

Compatibility, safety, and release

  • Breaking changes or migration steps: none.
  • Real Hopper/Ghidra, browser, or OS coverage: native Windows 11 x64 for the Gemini CLI client lane.
  • Package or release metadata impact: none.
  • Security, privacy, process, or containment review: no new process launches beyond running the selected entry point under Node; the verifier still uses a loopback model fixture and isolated configuration folders.

Review checklist

  • This PR addresses a concrete problem or an agreed enhancement.
  • The PR has one focused outcome and the title follows type(scope): outcome.
  • Related issue is linked, or the reason for not linking one is stated above.
  • Tests cover changed observable behavior and meaningful failure paths.
  • Owning docs, contracts, and generated metadata are updated where needed.
  • User-visible CLI/MCP changes include representative output.
  • I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/1936 **Author:** [@pablodiazjorge](https://github.com/pablodiazjorge) **Created:** 10/11/2026 **Status:** ✅ Merged **Merged:** 10/12/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `feat/windows-gemini-verifier` --- ### 📝 Commits (2) - [`4e88262`](https://github.com/morluto/rea/commit/4e882625a698d3f243add05707a5637d72de034c) test(clients): verify native Gemini CLI integration on Windows - [`710560a`](https://github.com/morluto/rea/commit/710560a8db90ced57180be988c0e3256a52ad783) test(clients): resolve the selected Gemini CLI entry point once ### 📊 Changes **2 files changed** (+26 additions, -15 deletions) <details> <summary>View changed files</summary> 📝 `docs/testing.md` (+7 -3) 📝 `scripts/verify-gemini-client.mjs` (+19 -12) </details> ### 📄 Description ## Summary Fixes #1935. `verify:gemini-client` asserted POSIX. With the assertion removed, Windows also needs a way to select the npm install's JavaScript entry point, because only a `gemini.cmd` shim reaches `PATH`, and two setup-plan checks compared paths with a hard-coded `/`. This makes the lane run on native Windows, as #1926 did for the Claude Code lane. ## Problem and expected behavior On win32 the verifier stopped at the assertion. Without it, the default `gemini` fails the preflight with `spawn gemini ENOENT`, and `REA_VERIFY_GEMINI_COMMAND` cannot name `bundle/gemini.js` because it is spawned as an executable. Once Gemini CLI runs, the dry-run plan checks fail: they build the expected prefixes as `join(profile, ".agents", "skills") + "/"` and `profile + "/"`, while the planned targets use `\` on Windows. Expected: the same lane runs on native Windows with the npm install's entry point selected. ## Change and scope - `scripts/verify-gemini-client.mjs`: - remove the POSIX assertion; - run a selected `.js`, `.mjs` or `.cjs` entry point under the verifier's Node (`process.execPath`), for both the preflight and the client call; any other value is spawned as before; - build the two setup-plan prefixes with `path.sep`; - on win32, the preflight error names the entry point to select. - `docs/testing.md`: record 0.63.0 as verified on native Windows too, explain how to select the entry point, and drop native Windows from the unverified list of this lane. Not included: running the `.cmd` shim through a shell, and the other client verifiers that still assert POSIX. ## Contract and boundary impact - Semantic owner and earliest changed stage: the Gemini CLI client verifier script and its testing documentation. - CLI and MCP/tool-catalog contract: none. - Provider, bridge, target-format, or platform compatibility: the Gemini CLI client lane now runs on native Windows; no product code changes. - Evidence, artifact, provenance, or reconstruction contract: none. - Process execution, authorization, cleanup, or containment impact: a selected JavaScript entry point runs under the verifier's own Node instead of being spawned directly; the lane keeps its isolated `GEMINI_CLI_HOME`, Git project and loopback model fixture. - Generated metadata, package, or installation impact: none. ## Evidence and regression coverage - Tests added or updated: none; the change is the verifier itself, executed below on native Windows. - Base reproduction or other evidence: on `fb43dd97` the verifier exits on win32 at the assertion. With only the assertion removed and the entry point selected, it fails at the dry-run plan check that builds its prefix with `/`. With all the changes, every run below passed. - User-visible CLI/MCP output (if applicable): receipt fields from the Windows runs below. - Remaining proof gaps: live Google API compatibility stays unverified, as on POSIX; the POSIX lane was not rerun (its default command still takes the unchanged spawn path). ## Validation performed Windows 11 x64 (26H2), non-elevated, Node 22.22.3, on `fb43dd97` (the branch was then rebased onto `d802304c`; none of the 11 new commits touch the verifier, its model fixture, `verify-package-core.mjs` or the client setup code, and the `docs/testing.md` change there is in another section): - `npm ci`, `npm run build:cached` — passed - `node scripts/verify-gemini-client.mjs call` with `REA_VERIFY_GEMINI_COMMAND` set to the npm-installed Gemini CLI 0.63.0 `bundle/gemini.js` — passed: `catalogSize` 172, `schemasChecked` 172, `evidenceSeen` true, `skillLoaded` true - `node scripts/verify-gemini-client.mjs chat` with the same entry point — passed: `catalogSize` 172, `schemasChecked` 172 - `node scripts/verify-gemini-client.mjs call` without `REA_VERIFY_GEMINI_COMMAND` — fails at the preflight with `spawn gemini ENOENT` and the new Windows hint WSL Ubuntu, Node 24.18.0: - `npm run check:fast` — passed - `npx oxfmt --check scripts/verify-gemini-client.mjs docs/testing.md` — passed ## Compatibility, safety, and release - Breaking changes or migration steps: none. - Real Hopper/Ghidra, browser, or OS coverage: native Windows 11 x64 for the Gemini CLI client lane. - Package or release metadata impact: none. - Security, privacy, process, or containment review: no new process launches beyond running the selected entry point under Node; the verifier still uses a loopback model fixture and isolated configuration folders. ## Review checklist - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-31 00:56:48 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#4921
No description provided.