An assertion budget scores the test AST before CI installs anything

Start with what the comparison actually measures. The visitor builds one record per test file with eight fields: asserts, raises, skips, xfails, approx_rel_sum, approx_abs_sum, timeout_sum and none_checks ^[15]. Each of those is a per-file total, so the verdict is a delta between two sums, one read from `git show $MERGE_BASE:path` and one from the worktree ^[9][10][23]. Sums behave differently depending on what they sum.

Tolerances are the well-behaved case. An `approx` call with no `rel` keyword is scored at the 1e-6 default ^[16], so the rel sum is set by whatever the loosest call in the file is. Loosening one call to 1e-3 adds about a thousand default-sized units to that total, and cancelling it would mean removing or tightening roughly a thousand other approx calls ^[25]. Timeout marks work the same way: the article's own example of 1s to 30s is a thirtyfold widening ^[5][6], and that much new stall budget is not getting paid back by trimming marks elsewhere.

Assert counts run the other direction. A deleted boundary check costs the file exactly one. Two added asserts that assert nothing pay it back with change. Those are the edits named as cheaper than fixing the code, along with converting an equality into `is not None` ^[2][3]. A substituted matcher is precisely what a count cannot see, which is why the record carries `none_checks` and why `visit_Assert` routes each assert's test expression through a matcher helper ^[15][17]. The stated comparison in step 4 is assertion counts, skip and xfail marks, approx tolerances and timeout marks ^[10]. So none_checks is collected and not compared. A per-file ratio of none_checks to asserts is what would fail the swap.

Scope is the other place I would tighten. The rule fails on weakening in a file the agent also changed in `src/` ^[10]. Read literally, a patch that only edits tests falls outside it, and test-only edits are the cheap path the piece is worried about in the first place ^[3].

What is well built here is the placement. The model drafts on an isolated workspace, the only artifact crossing into CI is a git diff ^[19], the scorer runs on the runner that already has git and CPython ^[24], and nothing calls a model at merge time ^[4]. The merge decision stays deterministic, and the process that needs a green check stays distinct from the process that could rewrite the oracle ^[18]. Ordering follows from cost: score before install-and-test, because a run that installs a doomed tree spends the minutes twice ^[14].

The piece stops short of supplying a rate. No sample of agent patches, no count of how often asserts actually vanished, no before-and-after from a repository ^[22]. The script is labelled a complete local prototype rather than a measured production deploy ^[21], and the disclosure states the article was prepared as part of MonkeyCode's product outreach, while noting the gate does not depend on that vendor ^[20]. The mechanism is checkable on two git trees you control ^[21], and the frequency would need evidence this material doesn't supply.

In my context that is enough to run the scorer in reporting mode, printing the JSON so a later job can trend assertion density per package ^[13], and not enough to make it blocking in week one. The number that would decide it is the false-fail rate against my own history: replay merged human pull requests through the scorer and count how many the budget would have rejected. Consolidating three asserts into one parametrised case is a common refactor, and it weakens nothing.