With every Windows test finally passing — 1239 passed, 0 failed — the last
red was the critical-coverage gate: manager.py at 59.80% against a 60.00%
floor, on Windows only. It measures 60.74% on Linux.
The gap is not missing tests. Windows runs MORE of them (1239 against 1223)
and still covers less of that module, because manager.py holds POSIX-only
paths that cannot execute there at all. A floor checked on Windows therefore
measures platform reachability rather than test quality, and fails by two
tenths of a point for a reason no test author can act on.
So the floor is measured on Linux, the same reasoning as the lockfile check
earlier in this session: a property of the codebase is one question about one
artifact and wants asking once, on a canonical platform, not re-derived per
matrix entry where platform differences make the number wobble. Every
platform still RUNS the full suite and the 20% overall floor; only the
per-module floor is Linux-measured.
Recorded separately, because the gate being right does not make the number
good: a 2970-statement module central to the application sits at 60% with no
headroom, and its uncovered part is almost all interactive prompt handling.
Raising it honestly means extracting logic out of the input() loops, not
writing tests that drive prompts.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01Vtx94nXDmNgXEeThUZP4QN
The previous attempt failed loudly with the resolved paths, which is what it
was built to do, and they said the rest: on Windows BOTH `python` and
`python3` are MSYS2's. The toolchain that must be on PATH so native wheels
can build is the very thing hiding the interpreter the tests need, and no
bare name can reach past it.
setup-python exports `pythonLocation` (here C:\hostedtoolcache\...\3.10.11)
without necessarily putting it first on PATH, so that is now tried before the
bare names, along with a last-resort candidate derived from wherever `pytest`
itself resolves — the determinism gate proves that one is reachable on this
runner. Selection is still by capability: the first candidate that can
actually import pytest wins, and a total failure prints every path it tried.
It also now echoes the interpreter it chose, so the next surprise of this
kind is one line of log rather than a deduction.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01Vtx94nXDmNgXEeThUZP4QN
With Windows finally installing its dependencies, the CI build job reached
the test step for the first time and died on
"msys64/mingw64/bin/python.exe: No module named pytest".
The MSYS2 toolchain is prepended to PATH so native wheels can build, and
MSYS2 ships its own python.exe. run_ci_tests.sh took the first `python` on
PATH, which was therefore MSYS2's. The determinism gate immediately before it
had passed on the same runner because it invokes the `pytest` executable,
which MSYS2 does not provide — so PATH resolution quietly sent the two
scripts to different interpreters.
Selection is now by capability rather than by name: try each candidate and
keep the first that can actually import pytest, failing loudly with the
resolved paths if none can. Unchanged on Linux and macOS, where the first
`python` is the right one.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01Vtx94nXDmNgXEeThUZP4QN
- fix unformatted test file src/tests/test_nostr_resilience_failure_modes.py
- fix missing PYTHONPATH and use poetry run in scripts/tui2_check_smoke.sh
- fix failing test test_legacy_index_reinit_syncs_once_when_confirmed by updating sync call assertion
- configure run_ci_tests.sh to use proper python binary
Co-authored-by: PR0M3TH3AN <[email protected]>
thePR0M3TH3ANandClaude Opus 5