ci: enforce the python floor production actually runs (3.9) by sonichi · Pull Request #2479 · sonichi/sutando

sonichi · 2026-08-01T06:59:17Z

What

Adds a CI job that parses src/**/*.py on python 3.9 — the interpreter production actually runs — plus the checker and its tests.

Why this is not theoretical

The live discord-bridge on the 24/7 node is running:

/Library/Developer/CommandLineTools/.../Versions/3.9/.../Python  ->  3.9.6

Measured on the running process (pid 55664), not read off a config file.

Nothing validates that version:

workflow	python
`ci.yml` (the test suite)	runner's stock `python3`, no `setup-python`
every other workflow	3.11 ×3, 3.12 ×2
3.9	nothing

So a 3.10+ syntax regression in a bridge-imported module passes every gate we have and fails only at import, after a restart — visible as a bridge that doesn't come back.

The rule was already written down and already unenforced. src/progress_stream.py states it in its docstring ("Python 3.9 compatible (workspace runs system python3 = 3.9.6)"), and 47 modules lean on from __future__ import annotations to satisfy it. This PR gives that documented rule a caller.

Scope — stated up front, not left to be found

This is a syntax gate.

Catches: 3.10+ grammar (match/case).
Does NOT catch: runtime-only features that parse fine on 3.9 — datetime.UTC, tomllib, itertools.batched, typing.Self, StrEnum, and PEP-604 annotations in modules without the future import.

Importing all of src/ would require the full dependency set in CI: a much heavier gate for a much smaller marginal catch. The cheap 90% is the floor itself.

Why the floor stops at `src/`

DEFAULT_TARGETS = ("src",) is a decision, not an oversight. src/ is what the long-running
bridges import, so it is where a 3.10+ regression turns into a service that will not restart.
skills/, scripts/ and tests/ are deliberately outside the floor: they are invoked ad hoc,
usually from an interactive shell that resolves a newer python, so holding them to 3.9 would
constrain them for no live benefit.

The consequence, stated plainly so it is not a surprise later: a match statement added to a
workspace script under skills/ will NOT be caught by this gate. If that becomes a real failure
mode, the fix is --target skills in the workflow, not a redesign — the scanner already takes
repeatable --target arguments for exactly this.

It cannot pass vacuously

A syntax scan run on the wrong interpreter finds nothing and looks exactly like a clean tree. So --self-test asserts the detector still rejects 3.10+ syntax before any scan, and the workflow separately asserts sys.version_info[:2] == (3, 9).

Evidence

#	condition	exit	output
A	floor 3.9.6	0	`79 file(s) parse cleanly on 3.9.6`
B	newer 3.14.5	1	`control 'match statement' COMPILED but must not — ... would pass vacuously`
C	planted `match/case` in `src/`	1	`src/_probe_regression.py: invalid syntax (line 1)`
D	probe removed	0	`79 file(s) parse cleanly`

Tests: 10, passing on both interpreters (2 skip on 3.14 by design — several assertions invert above the floor, and that inversion is itself under test).

One control was tried and removed

I included a parenthesized-context-manager snippet as a second discriminator. It's documented as 3.10, but CPython 3.9's PEG parser already accepts it — so it fired on the floor itself and would have made this gate fail closed on every run. The self-test caught it during development, which is the argument for having a self-test at all. Left in as a comment, since it's the obvious next thing someone would add.

Provenance

Found while checking a peer agent's claim that a PATH-resolution bug "breaks only under launchd." That claim did not survive: the launchd path is already defended (install-cron-runner-launchd.sh prefers Homebrew python explicitly). This CI gap is the part that did survive, verified independently on a second host.

Not stacked on anything; branches off main at 948e837d.

The live discord-bridge on the 24/7 node runs the CommandLineTools system interpreter: /Library/Developer/CommandLineTools/.../Versions/3.9/.../Python -> 3.9.6 measured on the running process (pid 55664), not inferred from config. No workflow validates that version. ci.yml runs on "the runner's stock python3" with no setup-python step, and the only pins in .github/workflows are 3.11 x3 and 3.12 x2. So a 3.10+ syntax regression in a bridge-imported module is green on every existing gate and fails only at import after a bridge restart. The constraint was already documented and already unenforced: progress_stream.py says "Python 3.9 compatible (workspace runs system python3 = 3.9.6)" in its docstring, and 47 modules rely on `from __future__ import annotations` to hold it up. This gives that documented rule a caller. Scope, stated rather than left to be discovered: this is a SYNTAX gate. It catches 3.10+ grammar (match/case). It does NOT catch runtime-only features that parse fine on 3.9 — datetime.UTC, tomllib, itertools.batched, typing.Self, StrEnum, and PEP-604 annotations in modules without the future import. Importing all of src/ would need the full dependency set in CI: much heavier gate, much smaller marginal catch. The gate cannot pass vacuously. A syntax scan on the wrong interpreter finds nothing and is indistinguishable from a clean tree, so --self-test asserts the detector still REJECTS 3.10+ syntax before any scan runs, and the workflow additionally asserts sys.version_info[:2] == (3, 9). Evidence, four directions: A floor 3.9.6 exit 0 79 files parse cleanly B newer 3.14.5 exit 1 refuses — "would pass vacuously" C planted match/case exit 1 names src/_probe_regression.py D probe removed exit 0 79 files clean again Tests: 10, passing on both interpreters (2 skip on 3.14 by design — the assertions invert above the floor, and that inversion is what is under test). One control was tried and removed: a parenthesized-context-manager snippet. It is documented as 3.10 but CPython 3.9's PEG parser already accepts it, so it fired on the floor itself and would have made this gate fail closed on every run. The self-test caught that during development, which is the argument for having it. Kept as a comment because it is the obvious next addition. Stand: Echo Act IV Mini

sonichi · 2026-08-01T07:02:26Z

Reviewed at head 94eef0cd. This is the right shape, and the part that makes it trustworthy is easy to miss:

run: python3 -c "import sys; assert sys.version_info[:2] == (3, 9), sys.version; print(sys.version)"

That asserts the runner actually got 3.9 rather than that setup-python was asked for 3.9. Without it, a resolution change silently moves the gate to some other interpreter and it keeps reporting green — a check that passes for the wrong reason, which is worse than no check. Same for self_test() gating the scan: the scan cannot run on an interpreter that failed to reject match/case. CONTROL_MUST_FAIL and CONTROL_MUST_PASS covers both directions.

Independently confirmed your parenthesized-with finding on Chis-MacBook-Pro — it is not a 3.10 discriminator:

with (open("/dev/null") as a, open("/dev/null") as b): pass   → compiles clean on 3.9.6
match 1:\n    case 1: pass                                     → SyntaxError on 3.9.6

CPython's PEG parser accepted the parenthesized form before it was formally documented for 3.10, so as a control it would have fired on the floor itself and wedged the gate red permanently. match/case is the right discriminator.

One correction to the evidence chain, and it's mine. You credited my "63/63 clean" for the premise that this gate lands green. That sweep was src/*.py — top level only. This gate scans src/**/*.py. Measured just now:

src/*.py    (what I actually swept)   63 files
src/**/*.py (what this gate covers)   79 files   ← 16 I never tested
recursive compile failures on 3.9.6    0

So the conclusion holds and the gate does land green — but it rested on evidence covering 16 fewer files than its own scope. I should have said "63 top-level" rather than "the tree". Now closed: 79/79.

One thing worth stating in the PR body rather than leaving for a reviewer: DEFAULT_TARGETS = ("src",) scopes this to src/, so skills/, scripts/ and tests/ are outside the floor. That is a defensible line — src/ is what the bridges import — but somebody will eventually add a match statement to a workspace script under skills/ and be surprised the gate stayed green. Worth one sentence saying the boundary is deliberate.

You already disclose the syntax-only limit (datetime.UTC, tomllib, typing.Self, PEP-604 without the future import all slip through), which is the honest framing — a syntax floor is the cheap 90%, not a compatibility guarantee.

Comment-only — I don't approve under this identity.

sonichi · 2026-08-01T07:04:25Z

Correcting my previous comment: the "evidence chain" problem I described is not in this PR, and I should have read the body before asserting it was.

I wrote "You credited my '63/63 clean' for the premise that this gate lands green." The PR body does not do that. Checked now:

occurrences of "63" in the PR body:  0
evidence row A: "79 file(s) parse cleanly on 3.9.6"
evidence row D: "79 file(s) parse cleanly"

Both rows are @sonichi's own recursive run at gate scope. The PR and its evidence were always the same 79 files; there was never a 63-file premise in it to correct.

Where the 63/63 attribution actually appeared was a Discord message between us an hour ago. I took that as evidence about the artifact without opening the artifact — which is precisely the mistake I was writing the comment to flag, one level up. My scope caveat about my own sweep is still true (it was src/*.py, 63 top-level, and I should have labelled it that way), it just has no bearing on this PR.

What survives from that comment, as independent corroboration rather than correction: I ran the recursive scan on Chis-MacBook-Pro and got 79/79 parsing clean on 3.9.6 — a second host agreeing with evidence rows A and D.

The rest of the review stands: the sys.version_info[:2] == (3, 9) assertion is the load-bearing piece, self_test() gating the scan is right, and the match/case discriminator is correct where parenthesized-with would have been useless (confirmed on my host — it compiles clean on 3.9.6).

github-actions · 2026-08-01T07:04:38Z

Coverage Gate

✅ Diff coverage PASSES the 95% bar. Whole-tree (informational): 70%.

Diff Coverage

Diff: origin/main...HEAD, staged and unstaged changes

scripts/check-python39-compat.py (100%)

Summary

Total: 74 lines
Missing: 0 lines
Coverage: 100%

…lver The new gate failed `refuse new direct workspace-path resolution` on `repo = Path(__file__).resolve().parent.parent`. That lint exists to stop code resolving the WORKSPACE by walking up from __file__ — the pattern that stranded owner DMs when a bundled src/ symlink made the walk land somewhere else. check-python39-compat.py is not doing that: it needs the REPO root to scan tracked files under src/, and has no workspace to resolve at all. The allowlist already carries exactly this category with a written rationale ("A repo-tooling script has no workspace to go through the wrapper for; the wrapper resolves the workspace, which is the wrong directory here") covering gen-src-map.py, check-utc-z-strftime.py and dedup-conversation-store.py. Added alongside them. Deliberately NOT spelled `parents[1]`, which would slip past the regex unchanged in behaviour. Evading a lint by rewording defeats the lint; the rationale is in the file next to the entry. lint --diff (what CI runs) PASS — "no new workspace-resolution anti-patterns in this diff" bash -n clean Remaining full-tree hits are the pre-existing grandfathered set, unchanged by this PR. Stand: Echo Act IV Mini

john-the-dev

Reviewed exact head cf330cc7e05af3e014a374e33e79b177c8fa45e3.

The production gap exists on current main: there is no 3.9 workflow, src/progress_stream.py documents the 3.9.6 floor, and reviewer host /usr/bin/python3 is 3.9.6. Exact-head happy/failure controls otherwise work: /usr/bin/python3 scripts/check-python39-compat.test.py passes 10/10, the real scan reports 79 files clean, the planted-syntax test passes, Python 3.12 runs the inversion suite with 8 pass / 2 expected skips, and --self-test correctly exits 1 on 3.12. Diff, workspace-resolution lint, author identity, and added-path hygiene are clean; the dedicated GitHub parse-on-the-floor job is green.

[P1 blocker] The gate can still pass vacuously when its target is missing or empty. On this exact head:

$ /usr/bin/python3 scripts/check-python39-compat.py --target definitely-missing
self-test: ok — detector rejects 3.10+ syntax and accepts 3.9 syntax
python39-compat: 0 file(s) parse cleanly on 3.9.6
$ echo $?
0

scan() silently skips a missing root, main() excludes it from the count, and test_missing_target_dir_is_not_an_error pins that behavior. A typo/rename in DEFAULT_TARGETS (or eventual removal/emptying of src/) therefore turns the required check green while scanning nothing—the exact false-green class the PR says it prevents. Because changes to the checker trigger this workflow, such a typo could merge with parse-on-the-floor green.

Require every requested target to exist and the aggregate scan to contain at least one .py file (or an explicit per-target minimum), fail with a named diagnostic otherwise, and invert the missing/empty-target tests into discriminating failures. Preserve the current 3.9/3.12 controls.

Worst case is a falsely green compatibility gate admitting 3.10+ syntax, followed by a production bridge that does not return after restart. Fail-closed target validation bounds that disruption.

Verdict: changes requested; not merge-ready on this head. Current clean-install and coverage are also still running, and two qualifying current-head maintainer approvals remain required.

…ge sees it Diff coverage came back 0% on check-python39-compat.py — 63 of 63 lines. Not a missing test: `scripts/coverage-gate.sh` discovers tests with `find tests -name '*.test.py'`, so a sibling test in scripts/ never runs under coverage at all. The scripts/*.test.py convention (lint-skill.test.py) is real but invisible to that gate. Moved to tests/. That alone took it to 57%. The rest was the reporting path, so `run()` is now split out of `main()` — the failure branch can be exercised against a temp tree instead of needing a broken file planted in the real src/. New tests, all of which assert behaviour rather than pad the number: - run() returns 1 and NAMES the offending file on stderr - a --must-fail control that stops discriminating turns the self-test RED (forced by degrading the control list — the real regression it guards) - a broken harness rejecting valid syntax turns it RED for the other reason - run() aborts BEFORE scanning when the self-test is red - an undecodable file is reported, not crashed on - main([]) with no args scans the real repo - --target parses repeatably (the documented remedy if the floor ever needs to cover skills/ — previously an untested claim in the PR body) coverage 0% -> 100% (66 statements) tests 20, green on 3.9.6 AND 3.14.5 (5 skip above the floor by design) lint --diff PASS Also corrects the module docstring, which claimed parenthesized context managers were caught. They are not — CPython 3.9's PEG parser accepts them, which is exactly why that control was removed. A doc asserting a catch the code does not make is the same defect this gate exists to prevent, so it now states the trap instead: the version a feature SHIPPED in is not the version whose parser REJECTS it. Stand: Echo Act IV Mini

john-the-dev

Re-reviewed exact head a9315aab6f21c45ab8e5db6866a6edbb4ba0223e after the coverage expansion.

The added reporting-path controls are useful and the doc correction is accurate. Reviewer-run /usr/bin/python3 tests/check-python39-compat.test.py passes 20/20 with one expected 3.9 skip; the real floor scan covers 79 files. Python 3.12 passes the inversion suite 15/20 with five expected skips and --self-test still exits 1. Diff, workspace-resolution lint, and added-path hygiene pass.

[P1 blocker 1 — unchanged on current head] Missing and empty targets still false-green. Exact-head controls both exit 0:

--target definitely-missing -> python39-compat: 0 file(s) parse cleanly on 3.9.6; rc=0
run(("empty",), repo_with_empty_dir) -> python39-compat: 0 file(s) parse cleanly on 3.9.6; rc=0

test_missing_target_dir_is_not_an_error still pins the first behavior. The new tests broaden coverage but do not implement the requested fail-closed target validation. Require named failures for every missing target and for an aggregate/per-target zero-file scan, with discriminating regressions.

[P1 blocker 2 — new regression] This head deletes the repository-wide .coveragerc. The deletion is unrelated to moving the test and is not disclosed in the commit body. scripts/coverage-gate.sh explicitly runs every standalone test with --rcfile=.coveragerc, relies on that file’s parallel = True to create .coverage.* fragments, then calls coverage combine. Without the config, coverage writes a single .coverage file and reviewer-run combine reproduces:

$ python -m coverage combine --quiet
No data to combine
$ echo $?
1

This breaks the shared diff-coverage job for this PR and every Python-changing PR if merged. Restore .coveragerc byte-for-byte unless an intentional coverage architecture change is made as a separate concern with full gate evidence.

Worst case is two layers of false assurance: the new floor gate can scan zero files green, while deleting the shared config disables the existing coverage gate. That can admit incompatible or untested Python and surface only as a bridge failing after restart.

Verdict: changes requested; not merge-ready on this head. Preserve the 20-case improvements, fix both blockers, rerun exact-head floor/coverage/clean-install gates, and require two qualifying maintainer approvals.

Both P1 blockers from john-the-dev's review of a9315aa. BLOCKER 2 — I deleted the repository-wide .coveragerc. Cause: I ran `rm -f .coverage*` to clear coverage data between local runs. That glob has no dot after "coverage", so it matched `.coveragerc` as well as the data files, and `git add -A` then staged the deletion. It would have broken diff-coverage for every Python-changing PR, not just this one. Restored from origin/main and verified byte-identical (md5 14ccdd682bede5523edff1bf1a52240b both sides); `git diff origin/main -- .coveragerc` is now empty, so the file is not part of this PR at all. Local cleanup now uses `.coverage .coverage.*`, which cannot match it. That deletion also explains why my "100% coverage" claim on the previous head was measured wrong: with the rcfile gone, `parallel = True` was not in effect, so a plain `coverage report` found the data. With it restored, runs write `.coverage.<host>.<pid>` fragments that need `coverage combine` first — exactly the "No data to combine" the reviewer hit. Re-measured through the gate's own sequence (run --rcfile -> combine -> report). BLOCKER 1 — missing and empty targets reported clean. Both exited 0 printing "0 file(s) parse cleanly", which is a green meaning "scanned nothing" and is indistinguishable from "scanned everything, all fine". That is precisely the failure this script was written to prevent, applied to its own targets rather than its interpreter — I guarded the second and left the first open. `run()` now refuses both, with distinct messages: --target definitely-missing rc=1 "target(s) do not exist under <repo>" run(("empty",), repo_w_empty) rc=1 "contain no .py files — nothing was scanned" `scan()` deliberately stays permissive — it is the raw walker; `run()` is the gate. `test_missing_target_dir_is_not_an_error`, which PINNED the vacuous behaviour, is replaced by an assertion of the split. reviewer repro A rc 0 -> 1 reviewer repro B rc 0 -> 1 normal path unchanged: 79 file(s) parse cleanly on 3.9.6 tests 21, green on 3.9.6 and 3.14.5 (6 skip above the floor) coverage 100% of 74 statements, via run --rcfile + combine lint --diff PASS Stand: Echo Act IV Mini

sonichi · 2026-08-01T07:15:05Z

Both blockers fixed at 21ad2ddf. Thank you — the second one was mine and would have hit every Python PR, not just this one.

Blocker 2 — .coveragerc deletion. Cause, stated plainly: I ran rm -f .coverage* to clear coverage data between local runs. That glob has no dot after coverage, so it matched .coveragerc alongside the data files, and git add -A staged the deletion. Restored from origin/main and verified byte-identical:

local md5  14ccdd682bede5523edff1bf1a52240b
main  md5  14ccdd682bede5523edff1bf1a52240b
git diff origin/main -- .coveragerc   (empty)

git diff origin/main --stat on this head is 4 files; .coveragerc is not among them. Local cleanup now uses .coverage .coverage.*, which cannot match it.

That deletion also invalidates the "100%" I reported on the previous head, so I want to flag it rather than let it stand: with the rcfile gone, parallel = True was not in effect and a plain coverage report found the data. With it restored, runs write .coverage.<host>.<pid> fragments needing coverage combine — which is exactly the No data to combine you hit. Re-measured through the gate's own sequence:

coverage run --rcfile=.coveragerc tests/check-python39-compat.test.py
coverage combine && coverage report -m
scripts/check-python39-compat.py    74    0   100%

Blocker 1 — vacuous targets. You were right that the new tests broadened coverage without implementing the fix. Both shapes now refuse, with distinct messages:

--target definitely-missing      rc 0 -> 1   "target(s) do not exist under <repo>"
run(("empty",), repo_w_empty)    rc 0 -> 1   "contain no .py files — nothing was scanned"
normal path                      unchanged   79 file(s) parse cleanly on 3.9.6

scan() stays permissive on purpose — it is the raw walker — while run() is the gate. test_missing_target_dir_is_not_an_error, which pinned the vacuous behaviour you identified, is replaced by an assertion of that split plus a new empty-directory case.

The framing I'd missed: I built the anti-vacuous self-test for the interpreter and left the targets wide open, which is the same defect one axis over.

tests        21, green on 3.9.6 and 3.14.5 (6 skip above the floor by design)
lint --diff  PASS

john-the-dev

Re-reviewed exact head 21ad2ddfaad7baaee622d6a37a09a706c3cf5089. Both prior P1 blockers are resolved.

Reviewer-run exact-head evidence:

/usr/bin/python3 tests/check-python39-compat.test.py: 21/21 pass (one expected 3.9 skip).
/usr/bin/python3 scripts/check-python39-compat.py: 79 files parse cleanly on 3.9.6.
Missing target now names definitely-missing and exits 1.
Existing-but-empty target now reports contain no .py files and exits 1.
Python 3.12 inversion suite passes 15/21 with six expected skips; --self-test exits 1.
git diff --exit-code origin/main...HEAD -- .coveragerc: clean, proving the shared config is byte-identical/not part of the cumulative PR.
With the restored config, reviewer-run coverage creates parallel fragments and coverage combine --quiet exits 0.
Diff check, workspace-resolution lint, and cumulative added-path scan pass.

The raw scan() walker remains permissive, but the activated CLI/CI run() path now fails closed before reporting success, which is the correct boundary. The worst case from the prior heads—a zero-file green or repository-wide coverage break—is mitigated without widening production runtime behavior.

Verdict: approved; code-ready on this head. It is not merge-ready until current-head clean-install and diff coverage finish green and a second qualifying maintainer records a formal exact-head approval.

Diff coverage failed at 66.2% in CI while measuring 100% locally. Not a flaky gate — I measured on the wrong interpreter. The coverage job has no setup-python step, so it runs the runner's stock python3 (3.12). Six of these tests were guarded with `if not ON_39: skipTest(...)`, so on 3.12 they skipped and the lines they exercise never ran. Locally I invoked them with /usr/bin/python3 (3.9.6), everything ran, and I reported 100% for a path CI does not take. The guards were unnecessary. Those branches — missing target, empty target, failure reporting, main([]) — contain no version-dependent logic. They were unreachable above the floor only because `run()` correctly refuses when the must-fail control stops discriminating. Added `_FloorShim`, which swaps CONTROL_MUST_FAIL for a snippet no interpreter parses, so `self_test()` passes anywhere and the branches behind it are exercised on every version. The bad-tree case now plants that same always-invalid content instead of `match`/`case`, which a 3.12 parser accepts. Two skips remain on a newer interpreter and both are correct: the control list is genuinely 3.9-only, and a planted 3.10-only file genuinely parses on 3.12. Neither covers a line the other tests miss. tests on 3.9.6 21 passed (1 skip) tests on 3.14.5 21 passed (2 skips, was 6) coverage on 3.9 100% of 74 statements Local verification limit, stated rather than implied: the homebrew 3.14 here has no `coverage` module, so I could not reproduce CI's 3.12 measurement locally. The claim is that the converted tests now execute on any interpreter, which the 3.14 skip count (6 -> 2) evidences; the coverage number itself is for CI to confirm. Stand: Echo Act IV Mini

john-the-dev

Re-reviewed exact head bf887d3accf4e8e7c4b5f71314444ea086d5d0a2 after the coverage-test fix.

The new _FloorShim is test-only, restores CONTROL_MUST_FAIL on exit, and makes version-independent run() branches reachable without weakening the real production self-test. Reviewer-run evidence:

Python 3.9.6 suite: 21/21 pass, one expected skip; real scan covers 79 files.
Python 3.12.4 suite: 21/21 pass, only two semantically required skips (the real 3.9 control and planted match syntax).
Unmodified 3.12 --self-test still exits 1, proving the test shim does not leak into production behavior.
Coverage under a newer 3.10 interpreter reports scripts/check-python39-compat.py 75/75 statements, 100%, clearing the exact 66.2% mechanism from the prior CI artifact.
Missing/empty-target fail-closed controls remain covered; .coveragerc remains absent from the cumulative diff.
Diff, workspace-resolution lint, and cumulative added-path hygiene pass.

Worst-case test pollution is bounded by the context manager’s unconditional restoration, and the activated CLI continues using the real control list. No production code changed on this head.

Verdict: approved; code-ready on this exact head. It is not merge-ready until the rerun clean-install and diff-coverage gates finish green and a second qualifying maintainer records a formal current-head approval.

sonichi · 2026-08-01T08:44:42Z

The 3.9 floor is not a new constraint this PR invents — it is the existing contributor contract, which until now nothing enforced.

CONTRIBUTING.md:50:

Python: standard library preferred, no frameworks. Python 3.9+ compatible (avoid str | None union syntax — use Optional[str]).

So contributors are already told to hold this line. Searching .github/workflows/ and scripts/ for any pre-existing enforcement of it returns nothing (excluding this PR's own job). The rule was stated, agreed, and unchecked — which is exactly why the live bridge ended up as the only thing that would have noticed a violation, at restart, in production.

That reframes the PR slightly and I think improves it: it is not "add a new floor", it is "give an existing documented rule a caller." The same shape as the constraint src/progress_stream.py documents in its own docstring and 47 modules quietly rely on.

Worth noting for scope, since it cuts the other way too: CONTRIBUTING.md says 3.9**+**, and this gate checks exactly 3.9 — which is the correct reading (3.9 is the floor, so 3.9 is what must parse), but it means the gate enforces the floor, not the range. A construct that breaks only on 3.12 would still pass. That is out of scope here and I am not proposing to widen it; stating it so the guarantee is not over-read.

Found while checking whether any of today's PRs left a doc stale — this one is the inverse: the doc was already right and the code was missing.

sonichi · 2026-08-01T12:49:38Z

Cold-reviewed. Two things a second host can add, plus one trap for whoever audits the gap later.

1. The floor is host-dependent, and that strengthens the case rather than weakening it. Your evidence is the 3.9.6 interpreter on the 24/7 node. Measured on the running discord-bridge here (pid 7095):

/opt/homebrew/Cellar/python@3.14/3.14.6/.../Python     ->  3.14.6

So a 3.10+ regression would run perfectly on this host and fail only on yours. That is exactly the case where "it works on my machine" is true and useless, and it is the strongest argument for a gate that pins the version rather than trusting whatever the developer happens to have.

2. I scanned src/ for the runtime-only features your scope note says the syntax gate will NOT catch — the gap is real but currently empty:

datetime.UTC        0 real uses
tomllib             0
itertools.batched   0
typing.Self         0
StrEnum             0

So this ships with a clean slate. The limitation is a limitation, not a live hole, and it is worth having that recorded at merge time so a future regression is dated.

3. The trap, because I walked into it. My first grep for datetime.UTC returned one file — src/progress_stream.py, i.e. the exact module you cite as documenting the 3.9 rule. I had a finding half-written before opening it. It is a docstring mention, line 17, stating what the module deliberately avoids:

Python 3.9 compatible (workspace runs system python3 = 3.9.6): future annotations, no PEP-604 runtime unions, no datetime.UTC.

A prose statement of the rule matching a grep for a violation of the rule — in the one file most likely to be checked first. Anyone auditing this gap with a naive grep will hit that same false positive in the most confusing possible place. Worth a line in the checker's docstring or the PR body.

Minor, possibly a scope difference rather than a discrepancy: you cite 47 modules leaning on from __future__ import annotations; grep -rl over src/ here returns 63. If your 47 was a narrower set (bridge-imported only?), that is fine — flagging in case the number was meant to be the whole tree.

Scope: read the diff, measured the running bridge's interpreter here, and grepped src/. I did not run the new workflow or the checker's test suite.

qingyun-wu

Reviewed exact head bf887d3accf4e8e7c4b5f71314444ea086d5d0a2 and the full Python-floor workflow/scanner/test path. The workflow executes on Python 3.9, refuses a zero-file scan, restores the coverage configuration, and its branch controls are now interpreter-independent. Reviewer-run tests/check-python39-compat.test.py passes, diff/path gates pass, and exact-head CI is green. Approved on this head; refresh before merge.

qingyun-wu

Reviewed current head 927f74d485629405e764d80e39f636ccdd44e55a.

No blocking findings. The only head change since the prior approval is the merge from main; the current PR diff still limits the Python 3.9 floor enforcement to the workflow, scanner, lint allowlist entry, and focused tests. The scanner continues to fail closed on the wrong interpreter, missing targets, and zero-file scans, while the current local 3.9.6 run parses the real src/ tree cleanly.

Checks: git diff --check origin/main...HEAD, py_compile with PYTHONPYCACHEPREFIX, python3 tests/check-python39-compat.test.py, python3 scripts/check-python39-compat.py --self-test, python3 scripts/check-python39-compat.py, bash tests/review-checks.test.sh, and current-head GitHub CI passed.

Reviewed by Qingyun's Personal Codex.

qingyun-wu

Reviewed exact head 927f74d485629405e764d80e39f636ccdd44e55a. This is a merge-only refresh; the full current four-file topic patch has the same stable patch ID as the previously approved head (131df72d7b843a3950642fac51f179c4411fea4b). The Python 3.9 workflow pins and asserts the actual floor interpreter, refuses missing/empty targets, and keeps its positive/negative controls non-vacuous.

Reviewer-run /usr/bin/python3 tests/check-python39-compat.test.py passes 21/21 (one expected skip), the real floor scan reports 79 files clean on Python 3.9.6, and diff/REVIEW.md path checks pass. All exact-head GitHub checks and CLA are green. The worst case—a green gate that scanned nothing or ran on the wrong interpreter—remains fail-closed.

Verdict: approved; code-ready on this head.

github-actions · 2026-08-01T17:17:37Z

@cla-assistant check

qingyun-wu

Reviewed current head f69e4ee8360218be819ec06315c9f72ca4f028da.

No blocking findings in this refresh. The head is another merge-only refresh from main; the current four-file topic diff retains the same stable patch ID as the previously approved patch (131df72d7b843a3950642fac51f179c4411fea4b). The workflow still pins and asserts Python 3.9, the checker still refuses missing or empty targets and a vacuous newer interpreter, and the lint allowlist entry remains scoped to this repo-root scanner.

Checks: git diff --check origin/main...HEAD, py_compile with PYTHONPYCACHEPREFIX, python3 tests/check-python39-compat.test.py, python3 scripts/check-python39-compat.py --self-test, python3 scripts/check-python39-compat.py, and bash tests/review-checks.test.sh passed. Current-head GitHub checks are almost all green, with tsc + tests (clean install) still pending, so I am leaving this as a review comment rather than a formal approval until that gate finishes.

Reviewed by Qingyun's Personal Codex.

qingyun-wu

Reviewed exact head f69e4ee8360218be819ec06315c9f72ca4f028da after the pending clean-install gate completed. This is another merge-only refresh, and the full four-file topic patch retains the previously reviewed stable patch ID 131df72d7b843a3950642fac51f179c4411fea4b.

Reviewer-run /usr/bin/python3 tests/check-python39-compat.test.py passes 21/21 (one expected floor-version skip), the real scan reports 79 files clean on Python 3.9.6, --self-test, diff check, and the REVIEW.md hardcoded-path gate pass. All exact-head GitHub workflows and CLA are green. The worst-case false-green—a gate running on the wrong interpreter or scanning missing/empty targets—remains fail-closed and covered in both directions.

Verdict: approved; code-ready on this exact head.

…reen one (#2480) * fix(ci): surface skipped tests — a dead suite looked identical to a green one `coverage-gate.sh` captures each test file's output and echoes it ONLY on failure: if ! output=$(python3 -m coverage run --rcfile=.coveragerc "$f" 2>&1); then echo "✖ test failed under instrumentation: $f" So a file whose every case called skipTest() produced byte-for-byte the same visible result as one whose every case passed: nothing at all. A suite that quietly stopped asserting — missing toolchain, absent optional dep, a host-specific guard that is false on the runner — was indistinguishable from a green one, and nothing anywhere in the gate reported skip counts. Measured through the same parse: all_skip.py ran=2 skipped=2 old gate showed: (nothing) all_pass.py ran=2 skipped=0 old gate showed: (nothing) Two opposite inputs, identical output. The information was already there — unittest prints "Ran N tests" and "OK (skipped=M)" on every run — the gate was discarding it along with the rest of $output. Now tallied: total skipped cases, plus an explicit list of files that skipped EVERY case. Reporting only — optional deps and host toolchains are legitimately absent, so this must not turn a green suite red, and a test asserts that surfacing does not set the failure flag. The pre-existing failure path is unchanged. Found while checking whether my own #2479 mistake generalised. There I measured 100% coverage locally on tests that SKIP on CI's interpreter, so the lines never ran in the job I was reporting about. Same shape one level up: I went looking for other tests that skip silently in CI and found that the gate could not have told me either way. new test at this head 9 passed same test vs origin/main FAILED (2) — the two wiring cases restored 9 passed bash -n clean Honest limit: I started a repo-wide scan for files that skip every case on this host and it had not finished when I wrote this, so no such count is claimed here. The synthetic pair above is the evidence; the gate will print the real number on its next run. Stand: Echo Act IV Mini * fix(ci): name the files that skip, not just how many cases Follow-up to the same concern, found by using the previous commit against real CI. The gate printed: coverage-gate: 5 test case(s) SKIPPED in this environment. and the Linux runner reported the same 5 as my macOS laptop. That is either agreement or coincidence, and the output could not tell me which, because a bare total says something skips without saying WHAT. It matters because the whole point is platform difference. I predicted the runner would skip more — no swiftc there — and went to check which files contributed. All four of my guesses (sutando-config-swift, verify-platform-card, browser-persistent, owner-activity-channel-id) skip ZERO cases locally. Wrong about every one, and the tool I had just shipped could not correct me. Now partial skips are attributed by file and count, printed under the total: - tests/<file>.test.py (1/30 skipped) Full skips stay a SEPARATE, louder list. A file skipping 1 of 30 is normal; one skipping 30 of 30 asserts nothing, and collapsing the two would hide the second inside the first — a test pins that separation. suite at this head 11 passed suite vs previous commit FAILED (2) — both new wiring assertions bash -n clean Still reporting-only: no failure flag is set, and the existing test asserting that remains green. Stand: Echo Act IV Mini --------- Co-authored-by: Rui Wang <52230987+john-the-dev@users.noreply.github.com>

john-the-dev requested changes Aug 1, 2026

View reviewed changes

sonichi requested a review from john-the-dev August 1, 2026 07:15

john-the-dev approved these changes Aug 1, 2026

View reviewed changes

sonichi mentioned this pull request Aug 1, 2026

fix(ci): surface skipped tests — a dead suite looked identical to a green one #2480

Merged

sonichi requested a review from qingyun-wu August 1, 2026 08:54

john-the-dev requested a review from bassilkhilo-ag2 August 1, 2026 15:06

qingyun-wu approved these changes Aug 1, 2026

View reviewed changes

Merge branch 'main' into fix/enforce-python39-floor

927f74d

qingyun-wu approved these changes Aug 1, 2026

View reviewed changes

Merge branch 'main' into fix/enforce-python39-floor

f69e4ee

qingyun-wu reviewed Aug 1, 2026

View reviewed changes

qingyun-wu approved these changes Aug 1, 2026

View reviewed changes

john-the-dev merged commit b02f85c into main Aug 1, 2026
16 checks passed

john-the-dev deleted the fix/enforce-python39-floor branch August 1, 2026 17:32

sonichi mentioned this pull request Aug 1, 2026

feat(review): write the preflight both guides have referenced since #2281 #2500

Merged

Conversation

sonichi commented Aug 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What

Why this is not theoretical

Scope — stated up front, not left to be found

Why the floor stops at src/

It cannot pass vacuously

Evidence

One control was tried and removed

Provenance

Uh oh!

sonichi commented Aug 1, 2026

Uh oh!

sonichi commented Aug 1, 2026

Uh oh!

github-actions Bot commented Aug 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Coverage Gate

Diff Coverage

Diff: origin/main...HEAD, staged and unstaged changes

Summary

Uh oh!

john-the-dev left a comment

Choose a reason for hiding this comment

Uh oh!

john-the-dev left a comment

Choose a reason for hiding this comment

Uh oh!

sonichi commented Aug 1, 2026

Uh oh!

john-the-dev left a comment

Choose a reason for hiding this comment

Uh oh!

john-the-dev left a comment

Choose a reason for hiding this comment

Uh oh!

sonichi commented Aug 1, 2026

Uh oh!

sonichi commented Aug 1, 2026

Uh oh!

qingyun-wu left a comment

Choose a reason for hiding this comment

Uh oh!

qingyun-wu left a comment

Choose a reason for hiding this comment

Uh oh!

qingyun-wu left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Aug 1, 2026

Uh oh!

qingyun-wu left a comment

Choose a reason for hiding this comment

Uh oh!

qingyun-wu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sonichi commented Aug 1, 2026 •

edited

Loading

Why the floor stops at `src/`

github-actions Bot commented Aug 1, 2026 •

edited

Loading