fix(tools): resolve external tools on Windows

[jz-wilson]

What

bridge/tools.ts assumes a POSIX environment in three ways. On Windows all three fail closed, so every external tool resolves as "not installed on this host".

The user-visible symptom is on the phone: "The preflight couldn't be run on this machine." The chain behind it is findTool("git") → null → isGitCheckout false → install kind unknown → collie update refuses. collie doctor reports the same machine as having no herdr and no python3 while both sit on PATH, and collie update's own build step fails with bun not found.

The three

1. PATH split on ":". Windows separates with ;, so the split does not merely miss entries — it shreds each one at its drive letter (C:\Program Files\Git\cmd becomes C and \Program Files\Git\cmd). searchDirs' absolute-only filter then drops every fragment and PATH contributes nothing at all. Now node:path's delimiter.

2. No PATHEXT. The bare name was joined to each directory as-is, but the executable is git.exe, herdr.exe, python3.exe. findIn now takes an exts list and tries each suffix within a directory before moving on, bare name first, so PATH order still decides. The parameter defaults to [""] and toolExts returns [""] off win32 — the search is byte-for-byte unchanged on Linux and macOS.

3. env.PATH misses Windows' Path spelling. Case-insensitivity survives only while the environment is the live process.env proxy; this module is handed plain copies of it (the CLI merges .env over the ambient environment before building Exec). So PATH and PATHEXT are read case-insensitively on win32.

The third one is why this was not caught earlier by anyone poking at it from a terminal: the same binary passes under Git Bash, which exports the name uppercase, and fails under PowerShell — which is what a Windows bridge actually runs under.

Verification

On Windows 11, against a Herdr-managed checkout at v1.5.3, collie doctor goes from

error: herdr-version   no `herdr` on this host
error: hook-python3    no `python3` on PATH
warn:  install         cannot tell how this Collie was installed (… has no .git of its own …)

to herdr 0.8.2, python3.EXE, and Herdr-managed checkout … (detached at 1.5.3). collie update --check --local --json then produces a real preflight (bun green, tree green, upstream green) instead of update.preflight_unavailable, and the Updates page on the phone works.

Checks run on Linux, all green: bun run typecheck, cd web && bun run typecheck, bun run lint (0 warnings, 0 errors), bun test ./cli/tools.test.ts ./bridge/dial.test.ts (23 pass, 3 skip), and cd web && bun run test (181 files, 5050 pass).

Notes

• No version bump, per CONTRIBUTING's fork rule. Suggested ## [Unreleased] entry:
  - Fixed: external tools (git, herdr, python3, bun) now resolve on Windows, so doctor and update work there.
• New tests cover the suffix search cross-platform and toolExts on both sides of the platform check; the three win32-only assertions skipIf off Windows.
• Two things remain Windows-rough and are deliberately not in this PR, since each is a separate decision: the manifest skips build on win32 so there is no bin/collie for canRunUpdate to find (and a bun build --compile there emits bin/collie.exe, not the bare name the bridge checks), and doctor's disk check cannot read free space on Windows. Happy to follow up on either.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UDQT5GAR9qRs6ukXrmDzhL

[AltanS]

Thanks Johnzell, this lands. Your commit is on main as d80ebbe with your authorship, plus one of mine that makes the platform an injected parameter so the Windows cases run on our Linux CI instead of being skipped, and the changelog names the .cmd shim limit. It ships in 1.6.0.