[ryanduguid]

Summary

Two tests failed on any machine without Chrome because they relied on the host's Chrome without saying so. They now get a stand-in executable through CHROME_PATH, so they give the same result on every host. No assertion or production code changes.

 bridge_doctor_accepts_and_ignores_verbose_like_commander
+  CHROME_PATH = the alcuin test binary
 McpChild::spawn (every MCP child in stdio_and_cli.rs)
+  CHROME_PATH = the alcuin test binary

The failures were correct production behaviour: bridge doctor exits 1 without Chrome, and MCP refuses a browser consult before creating a session. The no-Chrome refusal keeps its own test in tests/mcp_service_parity.rs.

Evidence

• Before, on clean f12ebe9, Windows without Chrome:
  bridge_doctor_accepts_and_ignores_verbose_like_commander fails at plain.status.code() with left: Some(1) right: Some(0). Doctor prints No Chrome installation detected.
  local_browser_cli_and_mcp_admit_foreground_and_detached_rust_workers fails in public_session with left: 0 right: 1.
  After: both pass.
• CI on f12ebe9 and on Keep waiting for the answer when a page read stalls after the send #17's head: both tests pass on ubuntu-latest. On windows-latest they pass on Keep waiting for the answer when a page read stalls after the send #17's head; on f12ebe9 that job stopped at a timing failure in the unit tests before reaching them. This is why only local runs showed the failures.
• The stand-in is never launched: a recording executable used in its place left no trace across all 43 tests in tests/stdio_and_cli.rs.
• Checks: cargo build, cargo clippy --all-targets --locked -- -D warnings and cargo fmt --check pass. cargo test --locked --no-fail-fast: 923 passed, 0 failed, 15 ignored, on the first commit. The second commit changes only a comment; after it, cargo fmt --check and the admission test pass.

Merge danger

Door: two-way. Blast radius: tests

These tests no longer exercise real Chrome discovery on the host. src/browser_detect.rs has its own unit tests for discovery order.

Unverified

• Not run on a Windows machine with Chrome installed; CI on this PR covers that case.
• The Windows timing failures that Stop Windows CI failing on slow durable writes #18 addresses are separate and can still fail this PR's CI.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud