T-1124 Establish #71's install-root containment for the wrapper path on Windows

[MongLong0214]

Ticket authority: docs/tickets/F14-distribution.md § T-1124. PRD: PRD-F14 requirement 26.

Depends on: T-1121 merged. There is no wrapper on Windows before it.

Why this is separate from reachability: install.ps1 makes Windows reachable. It does not make it supported. #71's install-root containment — the check that stops a recorded commitlore.bin from pointing at an arbitrary executable — has only ever been verified on macOS. A property verified on one platform is not a property of the product.

RED test: #71's two containment attacks, executed against a wrapper target on windows-latest — a recorded target outside the install root is refused, and a recorded target that is neither a script nor a recognised wrapper is refused.

Minimum GREEN: both attacks pass on windows-latest, in a required job, in this ticket's own pull request. Only then may any document call Windows supported.

Forbidden scope: continue-on-error is forbidden; do not mark Windows supported unless the attacks pass on Windows; do not loosen any containment match to make a test pass — the match being exact is the property.

Stop condition: if the attacks fail on Windows for any reason, stop. Do not weaken the job or skip the assertion. Record the failure as its own issue. Ending with "Windows is reachable but not supported, and here is the executed evidence" is an acceptable outcome; a supported claim without the property is not.

No implementation code until PRD-F14 and this ticket are both approved.

[MongLong0214]

Executed evidence: what a wrapper install actually records, and whether containment holds

Run against the shipped installer at dev (7b23e71), in a scratch HOME, on macOS.

commitlore init through the wrapper records the bundle, not the wrapper:

commitlore.bin     …/.local/share/commitlore/v0.4.1/dist/commitlore.mjs
commitlore.root    …/.local/share/commitlore/v0.4.1
commitlore.node    …/node/v24.18.0/bin/node

So the recorded target is a .mjs script, matched by classifyBinTarget's script arm. The compiled-binary arm is not involved in a wrapper install at all.

#71's two attacks, executed:

Attack	Result
commitlore.bin pointed at a script outside the install root, no commitlore on PATH	refused — commitlore: cannot find the CLI this hook was installed with. · exit 0 (fail-open) · the tampered script ran 0 times
commitlore.bin pointed at an arbitrary executable (/usr/bin/true), no commitlore on PATH	same refusal, same exit 0
legitimate recorded target	shape ok · references ok, commit lands

The tampered program is never executed, and the hook declines rather than blocking the commit.

What this changes for the two tickets

T-1125 (#284) — its forbidden-scope clause says a diff that removes matchesRunningBinary without a wrapper equivalent is the failure mode. Measured, the wrapper install never reaches matchesRunningBinary: its target is a script. The requirement to protect is therefore the script arm's install-root check, and building a "wrapper equivalent" of the binary arm would be work with nothing behind it while possibly leaving the check that matters unguarded.

T-1124 (#283) — the Windows question narrows. It is not whether .exe classification works, because there is no .exe to classify. It is whether init on Windows records the same .mjs target with a root that the stub's containment check resolves the same way, given Windows path semantics. That is a smaller and sharper question than the ticket currently states.

Not established here: the same behaviour on Windows, which is exactly what T-1124 exists to execute. This is the macOS baseline it will be compared against.

[MongLong0214]

Evidence from T-1121's Windows runner

install.ps1's CI job ran commitlore init through the installed shim on windows-latest. This is the measurement T-1124 starts from, produced before any of its own work.

What worked: init succeeded at Hooks, Index and Agent integration, and recorded the shapes this ticket needs to reason about:

commitlore.bin  = C:\Users\runneradmin\AppData\Local\commitlore\v9.9.9\dist\commitlore.mjs
commitlore.node = C:\hostedtoolcache\windows\node\22.23.1\x64\node.exe
cli runtime — ...\dist\commitlore.mjs runs (0.4.1)

So the question T-1124 narrowed to — whether Windows init records the same shape — is answered: yes. It records the .mjs bundle and an absolute interpreter, exactly as the macOS wrapper install does. The script arm is the arm that matters on Windows too.

Three checks failed, and they are this ticket's subject:

check	outcome
commit-msg hook	could not run the hook: spawnSync /bin/sh ENOENT
hook runtime	could not run the hook: spawnSync /bin/sh ENOENT
PreToolUse hook runtime	configured PreToolUse hook executable "commitlore" is not resolvable from PATH

Two causes, not three:

1. The probe spawns /bin/sh. Windows has no such path, so the probe cannot report on a Windows hook at all — it fails before reaching the hook. Note this is the probe, not necessarily the hook: Git for Windows runs hooks with its own bundled sh, so the stub may work while the probe cannot see it. Establishing which is true is the first thing T-1124 has to measure.
2. The shim is commitlore.cmd. The configured PreToolUse entry names commitlore; cmd resolves that to the .cmd, a bare-name PATH lookup from Node does not. T-1121 deliberately did not add a second extensionless artifact to satisfy this — Windows will not execute one, and the resolution logic is what should learn about Windows.

Also relevant to the containment question: #71's install-root check now has one kind after #284 — an extensionless path is refused outright. On Windows the recorded value is the .mjs under the checkout root, so the script arm's isInsidePackage containment is the property to establish, and the compiled-artifact arm that T-1124's original text referenced no longer exists.

Everything above is from the runner, not from reasoning about Windows. T-1121's job prints doctor's full output on every run, so this evidence stays current rather than being a snapshot in a comment.

[MongLong0214]

Executed on windows-latest: the question resolves, and not the way the ticket expected

Work is in PR #320 (draft). The measurement is complete; the two containment attacks have not executed, because the baseline in front of them fails.

The stop condition applies. Per this ticket: if the attacks fail on Windows, stop, do not weaken the job, do not mark Windows supported, record the failure as its own issue. That issue is #321, with the full runner output.

What the runner established

git version 2.55.0.windows.2 · /usr/bin/sh · MINGW64_NT-10.0-26100

commitlore.bin  = C:\Users\...\commitlore\v9.9.9\dist\commitlore.mjs
commitlore.root = C:\Users\...\commitlore\v9.9.9
dirname+pwd -P  = /c/Users/.../commitlore/v9.9.9/dist
containment case: NO MATCH -- the stub falls through
test -x node: yes
test -L bin: no
command -v commitlore: NOT found (the shim is commitlore.cmd)
real commit: HUNG -- killed at 90s, the hook never returned

And from a probe hook installed in a scratch repository on the same runner:

hook argv0    = .git/hooks/commit-msg
hook PWD      = C:/Users/RUNNER~1/AppData/Local/Temp/.../probe
hook pwd -P   = /c/Users/runneradmin/AppData/Local/Temp/.../probe
walk: NON-TERMINATING, stuck at [C:]

Answering this ticket's five questions

1. Does Git for Windows run the hook with its bundled sh? Yes. /usr/bin/sh, and the hook demonstrably executes — it hangs. So the spawnSync /bin/sh ENOENT in doctor is the probe's failure, not the hook's. Separating those was this ticket's first task and it is now separated.
2. Is a recorded target outside the install root refused? Not established. The baseline fails first.
3. Is an unrecognised target refused? Not established, same reason.
4. Does a legitimate .mjs target still work? No. The commit hangs and never returns.
5. Does PreToolUse resolution find the .cmd shim? No.

Why the narrowing in the earlier comment was right, and where it now leads

That comment narrowed this to "whether the stub's root resolution agrees under Windows path semantics". It does not, and the disagreement is inside a single hook invocation: $PWD answers C:/... while pwd -P answers /c/.... commitlore.root is written by node as a win32 path, so the case compares two different path worlds and cannot match for any value — including the installer's own bundle. Both other conditions on that line pass. The guard neither contains nor permits; it is dead, and that is what lets control reach the non-terminating walk.

Also worth carrying forward: doctor's TypeScript mirror reports no problem in exactly this state, because node:path is path.win32 and handles the backslashed pair correctly. It is green precisely when the hook is dead, so a fix that only touches the stub would leave the check that should warn about this still reporting healthy.

Standing conclusion

Windows is reachable through install.ps1 (#282) and not supported. No document is changed to say otherwise, and docs/COMPATIBILITY.md does not exist on dev yet (#271 unmerged), so this ticket's one-cell edit has no target — the row is left unflipped with this as the recorded reason.