check-attention-rung-consistency's population floor is pinned at today's exact count, so every allowlisted row reds it by removing its naive call

[localai-bot]

test_check_attention_rung_consistency.py pins the naive-call population at exactly today's count, so every row on its own allowlist reds it by doing the thing the allowlist exists for.

Found while landing #1578 and #1579 together. #1578 is green in isolation and #1579 is green in isolation; main goes red once both land, on the required agent-record job.

The coupling

scripts/attention-rung-allowlist.txt parks three model stems whose vt::Attention call another in-flight row is deleting: muse_glimmer_vision (#1545, PR #1579), ltx2 and ltx2_device (the LTX-2.5 routing row). The checker itself handles their removal correctly — it reports STALE (not a failure).

Two cases in tests/scripts/test_check_attention_rung_consistency.py do not:

• ShippedTreeTests::test_the_population_is_not_empty asserts sum(len(v) for v in scanned.values()) >= 9. The shipped tree has exactly 9 sites, so the floor has zero headroom and any removal reds it.
• ShippedTreeTests::test_allowlist_holds_only_the_in_flight_stems pins the allowlist set exactly, so deleting the stem reds that case.

A removing row therefore has no green path. Measured on #1578's head 89925ad6f with #1579's muse_glimmer_vision.cpp copied in:

# leave the stem (what the allowlist header tells the row to do):
FAIL: test_the_population_is_not_empty        AssertionError: 8 not greater than or equal to 9
Ran 31 tests   FAILED (failures=1)

# delete the stem (the other option):
FAIL: test_allowlist_holds_only_the_in_flight_stems
FAIL: test_the_population_is_not_empty
Ran 31 tests   FAILED (failures=2)

Tree restored byte-for-byte after each; 31 tests ... OK again, and git status --short empty.

Why the header does not warn about it

scripts/attention-rung-allowlist.txt:21-28 documents the first coupling carefully and concludes "the removing row is free to leave the deletion to whoever runs preflight next". That guidance is what reds the population floor, and the floor is not mentioned anywhere in the header, the checker docstring, or spec D7. So the one path the allowlist explicitly recommends is the path that breaks.

This is the shape AGENTS.md names under ## Records: never store a measurement of one file inside another file — "a number that changes after each edit couples every pull request to lines that it does not own". It is not every pull request here, but it is precisely the three rows the allowlist was created to unblock.

Not fixed in flow, and why

Changing the floor changes what the gate accepts, which AGENTS.md ## Changing the rules or a checker routes to a row, a spec, and a red-before/green-after mutation rather than an operator edit. Lowering the number is also the known mute-switch failure, so the repair is a design decision and not a constant edit.

Direction, not a design. test_the_six_deliberate_sites_carry_a_marker already pins six sites by name and asserts each carries a marker, which is a stronger guard against "the regex stopped matching after a rename" than a raw total is — a derived floor, or dropping the total in favour of the named set, both look plausible. Neither is chosen here.

Blast radius

• PR fix(MUSE-GLIMMER-VISION-ATTN-FLASH): route the perception encoder off the correctness-grade attention kernel (#1545) #1579 (Muse Glimmer's vision tower runs 50 layers on the naive attention kernel: ~4.8 s/image at 1024 tokens, unreached today and a 5 s TTFT stall the moment W3 lands #1545) cannot land until this is repaired. It is otherwise fresh-reviewed PASS, re-merged onto current main, and green on every job that can see it.
• The LTX-2.5 routing row deletes two of the three stems and hits the same wall.

Found while landing #1578; #1578 itself is green and is not blocked by this.

[localai-bot]

Reassigned into #1578 rather than deferred, on coordinator direction, and the framing in the issue body is corrected here.

## Changing the rules or a checker governs a checker already on main. test_the_population_is_not_empty has not landed — it is new in #1578 — so correcting it inside its own pull request is repairing the change, not amending a gate. Shipping a known lock into the required agent-record job and filing a follow-up is the worse trade.

The defect is also plainer than the issue body put it: the test's own name says "is not empty" while its assertion says "is at least 9". The name states the correct intent. Anti-vacuity — a scanner that matches nothing is green for the wrong reason — is discharged by >= 1. The 9 adds nothing but a pin on today's incidental site count.

The repair now in flight on #1578:

• the floor becomes genuine non-emptiness (>= 1), with the comment recording why a raw total is deliberately not pinned;
• one new case asserts every allowlisted stem names an existing model source file, which catches the real risk (a typo'd or bogus entry).

The second assertion is deliberately file-existence and not scan membership. Asserting that an allowlisted stem still has a call site would rebuild this same lock one line over, because a stem becomes legitimately call-site-free the moment its removing row lands — which is the contract stale_allowlist_entries already states in its own docstring: "Reported, never fatal: the row that removes the call must not be forced to edit this file to stay green."

This issue stays open until that lands, then it is closed or narrowed to whatever remains, with the reasoning recorded. #1579 is held until then.

[localai-bot]

A SECOND instance of the same shape, in the same unlanded file

The fresh review of the floor repair found another live-tree measurement stored in tests/scripts/test_check_attention_rung_consistency.py, and it is also being repaired inside #1578 rather than deferred, for the same reason: the file is CREATED by #1578, so none of it has landed and correcting it is repairing the change.

GreenReportTests::test_the_ok_line_reports_the_excused_sites:

self.assertGreater(excused, 0, "the shipped tree must exercise this branch")

excused counts unmarked calls in allowlisted files. The allowlist parks exactly three stems — muse_glimmer_vision (#1545), ltx2, ltx2_device — so when the LAST one is cleaned up the allowlist empties, excused becomes 0, and the case reds while the production checker is green at rc=0. Simulated end state, all three rows landed:

OK (attention rung): 6 vt::Attention call site(s) in 6 model source file(s); 6 carry a recorded reason, 0 unmarked and excused by 0 allowlisted in-flight stem(s).
rc=0
FAIL: test_the_ok_line_reports_the_excused_sites
  line 321: AssertionError: 0 not greater than 0 : the shipped tree must exercise this branch

It does not fire for any of the three rows individually — with only #1579 landed the suite is 32/32 green — so it would have sat latent until the LTX-2.5 reroute row tripped it, in the required agent-record job.

Milder than the floor in one respect worth recording: once #1578 is on main, any row that trips this sees it on its own pull request CI, whereas the floor was invisible to #1579 (whose merge base predates #1578) and would have redded main only after the merge. Loud debt rather than silent. It is being fixed here anyway, because the principle is the same and the file has not landed.

The repair keeps both of the case's jobs and drops only the coupling: the shipped-tree assertion assertIn(f"{excused} unmarked and excused by", report) recomputes the count instead of pinning it and holds at 0 as well as at 3, so it stays; the "this branch is actually exercised" guard moves onto a synthetic fixture so it holds regardless of what the model tree contains.

Once both repairs are in, this issue closes with the reasoning recorded rather than staying open as a placeholder.

[localai-bot]

Where the scope line falls, and why the remaining tree pins are NOT this issue

A fresh review of the two repairs swept the whole suite for assertions that read the live tree. Four remain. None is being repaired here, and that is a considered line rather than fatigue, so the reasoning is recorded for whoever picks this up.

file:line	pins	reds on a future tree change?
:198	sum(sites) >= 1	only at zero sites — the minimum non-vacuous floor, not a lock
:211-212	the six deliberate stems are in scanned and all marked	yes
:218	the allowlist set is exactly the three in-flight stems	yes, by design
:272, :280	self.scanned["…/whisper_audio.cpp"], ["…/qwen3_5.cpp"] indexed directly	yes, as a KeyError

The distinction that matters. The two locks repaired in #1578 redded on a row doing exactly what the design intends — removing an allowlisted naive call. The sanctioned path had no green route, which is what made them defects: the allowlist header tells a removing row it owes the file nothing, and both the population floor and excused > 0 contradicted that.

The four above pin something different: the six deliberate sites and the allowlist set. Both are surfaces this row deliberately made review-gated. Rerouting one of the six deliberate vt::Attention calls is not routine cleanup — three of them are reference arms a gate compares against and two are VT_*_EAGER rungs of a same-binary A/B, so moving one changes what a comparison computes. A row that does it SHOULD have to edit the test that records the choice. Same for growing or shrinking the allowlist, which the header states outright: "growth of a parking lot must be a review decision and not a silent edit."

So those are design pins, not drift locks. Repairing them would delete the enforcement, which is the "widen the assertion until the gate passes" failure AGENTS.md names.

One real ergonomic defect worth a follow-up, not a fix here. :272 and :280 index self.scanned[...] directly, so a future reroute raises KeyError and surfaces as a unittest ERROR rather than a clean FAIL with a message naming the site. The reviewer demonstrated it — checker green at rc=0 while the suite reports FAILED (failures=1, errors=1). The verdict is correct and the diagnostics are poor. A assertIn(path, scanned, path) guard ahead of each index would fix it without weakening anything.

Also recorded: at the current head the disabled-checker stub reds 34 of 34, so the three retained 31s now understate by three rather than one. Nothing they assert is false — each names the stub experiment, and the load-bearing clause at check-pr-size.py:372-373 ("the suite has no case that passes without calling into the checker at all") is confirmed, not contradicted, by 34/34. The check-pr-size.py one cannot be reworded at all while #1631 stands.