mirror of
https://github.com/stablyai/orca.git
synced 2026-10-03 08:02:12 +00:00
The parent commit pins the whole tree to LF and leaves one question open: whether resources/win32/bin/orca.cmd should be an exception. Measured against the shipped v1.4.192 installer, it should -- though for a narrower reason than the open question assumed. See the finding below. The release Windows runner pins nothing and sets no core.autocrlf, so it converts this file on checkout. The committed blob is 644 bytes with 0 CR; the copy inside orca-windows-setup.exe is 665 bytes with 21 CR, and is sha256- identical to that blob with every LF doubled. 665 - 644 = 21, the file's line count. The same installer carries its own control: the seven files under resources/plugins/ were already pinned eol=lf and shipped unconverted, byte- identical to their blobs. One artifact proves both that the conversion is live and that a pin overrides it. That reverses the framing. Pinning CRLF reproduces today's artifact exactly; it is leaving the file to the blanket rule that flips a shipped byte. Verified across every checkout config: with the pin the working tree is 665 B / 21 CR under core.autocrlf=true, false and input alike; without it, 644 B / 0 CR under all three, and a real windows-2022 runner confirms `i/lf w/crlf` with the pin and `i/lf w/lf` without. The index blob is unchanged either way. FINDING: LF is not broken. check-windows-launcher-line-endings.ps1 ran the shim both ways on windows-2022 and both encodings passed both arms -- the goto-label hazard did not reproduce. So this pin is a consistency choice, not a correctness fix: it reproduces the bytes v1.4.192 shipped and stops them being decided by a build-image default nobody controls. A uniform-LF decision would now be defensible; what should survive either way is that something finally executes this file. Until now nothing did -- smoke-packaged-cli.mjs resolves the packaged CLI to resources/bin/orca.exe on win32, never the .cmd beside it. The shim sits outside the parent gate's population (no shebang, mode 100644), so the two rules cannot contradict each other; a test asserts that. check-line-ending-policy.mjs now asserts the exception rather than merely permitting it: the blob must still be LF and eol must resolve to crlf. An exception nothing checks is how this file's encoding became a runner-image accident in the first place. check-windows-launcher-line-endings.ps1 adds the empirical half on the existing package (windows) job, first step after checkout, one second. It confirms the runner really wrote CRLF, then runs the shim's guard path and its fall-through under a real cmd.exe, using a copy of cmd.exe as the orca.exe the shim requires -- without one the shim exits 1 before reaching either arm. It reports the LF verdict without ever failing the job on it. Both checks were watched failing with the pin removed before this landed.