Do not run `python3` on windows

[ptr727]

Agent keeps invoking python3 on windows and it keeps failing and result is ignored because it is a compound statement, over and over and over.

cd "C:\Users\piete\repos\worktrees\w5-harvest" && python3 -c "
import csv
from collections import Counter
c = Counter()
with open('data/archive/catalog.csv', newline='', encoding='utf-8') as f:
    for row in csv.DictReader(f):
        c[row['doc_type']] += 1
for k,v in sorted(c.items()):
    print(f'{v:4d}  {k}')
"

And I've added it to the standing brief boilerplate alongside the pytest -q line.

Worse than wasted tokens, though. python3 here is a Microsoft Store app-execution alias that prints "Python was not found" and exits 0. So it doesn't just fail — it fails claiming success. A && chain keeps going, an if takes the success branch, and any check reading only the return code records a pass while the script never ran. That's precisely the silent-success pattern this repo's own rules forbid on mutations (|| true, 2>/dev/null), sneaking in through the interpreter name instead.

So beyond the cost to you, it means any agent that used python3 and reported a result may have reported nothing at all. I'll treat conclusions from those calls as unverified.

This was a brief problem, not an agent problem — several reached for it because nothing told them not to. That's on me.

Start menu, Manage app execution aliases.

Explore option for host setup to alias python3 after installing python using winget:
https://superuser.com/questions/1576758/how-do-i-alias-python3-on-windows

[ptr727]

Heads up from the develop -> main promotion #1163, since this touches your area.

Two reviewers found that .husky/pre-push and .husky/pre-commit both say the interpreter is chosen "by running the probes spec/host-tools.json declares, in its order" and then probe python3 before py -3, while #1166 moved the spec to py -3 first. The spec changed and the hooks did not, so the hooks' own comments assert an order they do not follow.

#1167 aligns the hooks to the spec, because the spec is the declared ground truth and the hooks were the stragglers. It is six lines in each hook. If this issue lands python3 everywhere on Windows and concludes the order should flip back, flipping the spec and those six lines together is the whole change, so nothing here is meant to pre-empt that decision.

Worth flagging that the spec's stated reason for py first survives python3 existing on Windows: it is about which interpreter answers rather than which name exists, since a bare python3 is reached through PATH where an activated virtual environment or an MSYS2, Cygwin or Scoop interpreter can answer ahead of the managed one, while py reaches a registered interpreter whatever is active. That may or may not be what you want once python3 is universal, but it is the argument the order rests on today.

#1167 also adds the 3.13 floor check the same spec entry declares and neither hook enforced. That half is independent of the naming question.

[ptr727]

Closed by #1166, promoted to main in #1163. Recording one correction, because the fix shipped for a different reason than this issue gives and the difference is worth having written down.

The premise here is wrong

This issue says the stub "prints Python was not found and exits 0", and so "fails claiming success". Measured directly on the host, with the alias re-enabled from Settings for the purpose:

stdout	(empty)
stderr	Python was not found; run without arguments to install from the Microsoft Store, ...
exit code, PowerShell	9009
exit code, Git Bash	49 (9009 truncated to a byte)
stub && echo ...	chain stops

So the stub fails loudly and correctly. It never produced a false pass, and a && chain does not run on past it.

What was actually wrong

Two things, and the second is the one that bit.

1. The stub occupies the name. WindowsApps is on PATH by default, so wherever it precedes the install directory, python3 cannot reach the installed interpreter under that name at all. Loud, but still broken.
2. A foreign python3 earlier on PATH is the silent one. On this host python3 was C:\msys64\ucrt64\bin\python3.exe, Python 3.14.5, a real interpreter that answers cleanly and announces nothing. That also meant scripts/host_gate.py was grading MSYS2's interpreter rather than the managed 3.13, which nothing had noticed.

The silent-success pattern this issue invokes was real, but it lived in the second case rather than in the alias stub.

What shipped

install-tools.ps1 removes the App Installer alias placeholder and puts a real python3.exe beside the interpreter winget installed, resolving the line from whatever version winget reports for the pinned package id so nothing in the repair names a version. python3 is now the fleet's interpreter name on Windows as it already was on Linux and macOS. The gate keeps py -3 as its first probe, the only place that name survives, because it measures the host and py is immune to both a virtual environment and a foreign python3.

Two limits are documented rather than papered over. A Microsoft Store Python registers aliases under the same names with the same reparse tag, and those reach an interpreter somebody chose, so the installer reports them and leaves them alone. And removing a stub is not the same act as the Settings toggle, which keeps reading On afterwards, so the alias can return when App Installer is next serviced; TODO.md carries that as a pending measurement across a logout and a reboot.

Follow-ups from this work: #1170, #1171, #1172.