Filed unassigned by the domain:devx execution seat as an incidental observation while raising the framework per-chunk ceiling in PR #6772. Recording only — deliberately not fixed there, for the reason at the bottom.
Attached as a sub-issue of objectui#6631.
What is wrong
scripts/check-eager-closure-budget.mjs, in the doc comment on PER_CHUNK_BASELINE, carries a paragraph that opens:
This is a DIFFERENT and LATER reading than BASELINE above, which still carries 4c1623c0c. On 2c8474c04 the same build measures the closure at 3,298,620 bytes — 707,291 BELOW that recorded aggregate baseline ... the aggregate ceiling now sits ~787 KB above today's payload, which is far more than the REGRESSION_THIS_GATE_MUST_CATCH_BYTES it was sized to catch
Three of its statements were true when objectui#5490 wrote them and are false now, because objectui#5924 and objectui#6683 each re-baselined the aggregate underneath the paragraph without touching it:
BASELINE does not carry 4c1623c0c. It carries commit: 'bd2a7ec50' and gzipBytes: 3_254_004, about thirty lines above.- The "707,291 BELOW" arithmetic is against the retired reading. 4,005,911 (the
4c1623c0c figure the file header names) minus 3,298,620 is exactly 707,291, which is what pins the provenance. Against today's recorded BASELINE.gzipBytes of 3,254,004 the 2c8474c04 reading is 44,616 ABOVE it, not 707,291 below.
- The conclusion it draws is the reverse of the gate's live verdict. The paragraph tells its reader the aggregate ceiling sits ~787 KB above the payload and is therefore far wider than the regression it must catch — i.e. blind. The gate itself printed, on
b98352a15: aggregate closure 3180.2 KB measured / 3222.7 KB ceiling (headroom 42.5 KB = 0.48x the 89.0 KB regression). The aggregate half is in range today; the ~787 KB gap the paragraph describes was closed by objectui#5924 and objectui#6683.
Why this is worth a card rather than a shrug
This file's whole design is that its reasoning is CHECKED rather than argued — every ceiling is weighed against the report the run just read, and evaluateHeadroomSensitivity exists precisely so a claim about the gauge cannot go stale in silence. The doc comments are the one part with no such guard, and this is the paragraph a reader reaches at the moment they are deciding how to move a ceiling.
Point 3 is the sharp one. It does not merely age badly — it contradicts a verdict the same script prints in the same run, so an author sizing a re-baseline off it would conclude the aggregate half is decorative at exactly the moment the tool is telling them it is working.
Why PR #6772 did not fix it in passing
Point 1 is a one-token correction, but 2 and 3 are not. Restating the objectui#5490 aggregate-versus-per-chunk relationship correctly means re-deriving what that relationship IS after two intervening re-baselines — a decision about what the paragraph should now claim, not a typo repair. Doing it inside a surgical ceiling-raise would have been unreviewable scope, and guessing at it would reproduce the defect one layer up.
Why objectui#6631 is the parent
objectui#6631 is open on exactly this: the budget's headroom moved and nobody could establish which side moved it. A provenance comment that names a superseded commit and does arithmetic against a superseded figure is one direct cause of that — the constant's own documentation is the first place anyone looks, and here it points two re-baselines into the past.
Generated by Claude Code
Filed unassigned by the
domain:devxexecution seat as an incidental observation while raising theframeworkper-chunk ceiling in PR #6772. Recording only — deliberately not fixed there, for the reason at the bottom.Attached as a sub-issue of objectui#6631.
What is wrong
scripts/check-eager-closure-budget.mjs, in the doc comment onPER_CHUNK_BASELINE, carries a paragraph that opens:Three of its statements were true when objectui#5490 wrote them and are false now, because objectui#5924 and objectui#6683 each re-baselined the aggregate underneath the paragraph without touching it:
BASELINEdoes not carry4c1623c0c. It carriescommit: 'bd2a7ec50'andgzipBytes: 3_254_004, about thirty lines above.4c1623c0cfigure the file header names) minus 3,298,620 is exactly 707,291, which is what pins the provenance. Against today's recordedBASELINE.gzipBytesof 3,254,004 the2c8474c04reading is 44,616 ABOVE it, not 707,291 below.b98352a15:aggregate closure 3180.2 KB measured / 3222.7 KB ceiling (headroom 42.5 KB = 0.48x the 89.0 KB regression). The aggregate half is in range today; the ~787 KB gap the paragraph describes was closed by objectui#5924 and objectui#6683.Why this is worth a card rather than a shrug
This file's whole design is that its reasoning is CHECKED rather than argued — every ceiling is weighed against the report the run just read, and
evaluateHeadroomSensitivityexists precisely so a claim about the gauge cannot go stale in silence. The doc comments are the one part with no such guard, and this is the paragraph a reader reaches at the moment they are deciding how to move a ceiling.Point 3 is the sharp one. It does not merely age badly — it contradicts a verdict the same script prints in the same run, so an author sizing a re-baseline off it would conclude the aggregate half is decorative at exactly the moment the tool is telling them it is working.
Why PR #6772 did not fix it in passing
Point 1 is a one-token correction, but 2 and 3 are not. Restating the objectui#5490 aggregate-versus-per-chunk relationship correctly means re-deriving what that relationship IS after two intervening re-baselines — a decision about what the paragraph should now claim, not a typo repair. Doing it inside a surgical ceiling-raise would have been unreviewable scope, and guessing at it would reproduce the defect one layer up.
Why objectui#6631 is the parent
objectui#6631 is open on exactly this: the budget's headroom moved and nobody could establish which side moved it. A provenance comment that names a superseded commit and does arithmetic against a superseded figure is one direct cause of that — the constant's own documentation is the first place anyone looks, and here it points two re-baselines into the past.
Generated by Claude Code