Repository navigation
docs(gate): the eager-closure gate's prose stops writing counts it cannot keep - #7858
Merged
Merged
Conversation
…nnot keep Three sentences described the aggregate as "one number over N chunks" with N frozen as a literal, and the workflow's ceiling clause named a size the gate retired two re-baselines ago. Neither number was load-bearing for a verdict, which is why nothing caught either. The prose now states its population and points at the gate's own verdict line for the figure, and a pin refuses any chunk count no commit anchors. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KbJQ1y1J12nZxYzFWhP8Q3
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
This was referenced Sep 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #7528
The deliverable is "stop writing the count", not "52 becomes 50"
Three sentences described the aggregate as "one number over 52 chunks". The
card's diagnosis is the whole design brief: the count is not load-bearing for
any verdict — the sentence is rhetorical ("one total over N chunks cannot say
WHERE the payload moved") — which is exactly why nothing ever caught it. And
today there were three different counts in play, so refreshing one literal
would have turned three into two and let the next build spread them again.
Each sentence now states its population and leaves the figure to the gate, which
prints it on every run. The checker's header carries the rule, generalised from
the one that file already applies to its own motivating table:
An anchored count is a measurement of a named build and cannot go stale; an
unanchored one is a standing claim about the live closure, which moves on most
builds. That is also the distinction the card used to leave
vite-declared-lazy-views.ts's "42.5 KB of headroom" alone — it sits in aparagraph dated to a
b98352a15measurement and reads as history.The numbers, measured on this branch, not copied from the card
pnpm turbo run build --filter='./packages/*'pluspnpm --filter @object-ui/console buildon52cac3886, thenpnpm check:eager-closure:across **50 of 518** chunksBASELINE.chunksf620a26f6)The three counts confirmed; the payload has grown 5,608 bytes since the card was
written.
BASELINE.chunksis not a fourth defect and is untouched: it namesthe commit it was measured on (
3d257c85a), which is the anchored form the ruleasks for.
Site 2 — the workflow cited a ceiling that no longer exists
3.15 MBis 3,300,000 bytes, the ceiling objectui#6683set and objectui#6776 retired. Established on today's tree before rewriting,
rather than assumed: the criterion actually in force is
MAX_EAGER_CLOSURE_GZIP_BYTES = 3_268_000(3.12 MiB), plus the objectui#5924sensitivity half that weighs each ceiling against the report it just read. So a
sentence whose entire purpose is to stop a reader concluding the payload is
acceptable was itself quoting a size the gate had not allowed for two
re-baselines.
The repair names no size at all — which is the rule the same paragraph already
applies to the ceiling itself ("The closure ceiling is NOT set here. It lives in
scripts/check-eager-closure-budget.mjsnext to the reasoning that producedit"), now applied to the ceiling's value too. The removed literal is not quoted
back, for the same reason the pin refuses quotations.
The pin
One
it.eachin the gate's own test file — one gate, one home. It fails when anumeral qualifies a chunk noun in either script's prose and no commit in its
window anchors it, so the class fails loudly rather than waiting to be read.
Deliberately narrow, each limit a decision: numerals qualifying a chunk noun
(the file's "144 modules" and "166 modules" are module counts inside anchored
change records); own-line comments; and an anchor window of a paragraph plus the
one before it, because the header writes "Measured on
77f846a8b:" as a lead-inand its table as a separate paragraph. A line of code breaks that window, so a
hash in one block never vouches for a count in another. The window errs toward
allowing, which is the tolerable side for a check on prose; the intolerable side
is a standing claim nobody refuses.
cannot tell a quotation from a claim. That is recorded in the docblock, and it is
why the prose above says "N" where the number used to be.
Ablation — three legs, and the sharp one is (b)
(a) The genuine pre-fix prose, pin retained. Both files went red, each naming
itself and the exact literals:
(b) A literal that is CORRECT TODAY — the leg that proves the pin governs the
class of writing rather than wrong numbers.
50 chunksand50 of 518 chunksareexactly what the gate printed an hour earlier, and both are still refused:
(c) The same today-correct count, ANCHORED — "Measured on
52cac3886, theclosure held 50 of 518 chunks" — is accepted (
101 passed). So the pin is not"no digits near chunks"; it is the anchoring rule, and the escape hatch its own
failure message offers actually works.
Ordering, and it is the reason all three legs are trustworthy: the implementation
was committed first, and only then was the restore
traparmed — the siblingseat on objectui#7448 had its trap fire on a precondition guard's own exit and
silently restore both files to a HEAD that did not contain the fix. Each leg
re-checked that HEAD carried the fix before arming (
exit 92if not). Mutationproven on disk each time (blob hash flip plus an injected-anchor count) before
running; restored with
git checkout HEAD -- ABSOLUTE_PATH; restoration provenby state —
git diff HEADempty, porcelain empty, both blobs back to theirHEAD hashes. No build or
dist/is on this path: the pin reads the checkout.a hash in one comment block anchored a count in the next block across a line of
code. That is why
proseLinesdistinguishes a blank comment line from code, andwhy the self-test asserts that case.
Verification, all on
8537eb4b4pnpm exec vitest run scripts/__tests__(whole dir)Test Files 104 passed (104)·Tests 3065 passed (3065)pnpm run type-check:scripts--listFilesconfirms both edited script files are in the programnode scripts/check-eager-closure-budget.mjs✅ Console eager closure is 3187.4 KB gzipped across 50 of 518 chunks (budget: 3191.4 KB, headroom: 4.0 KB).node scripts/check-control-bytes.mjs✅ check-control-bytes: OK (scanned 6365 tracked text file(s); skipped 85 binary).node scripts/check-governed-queue-guard.mjs --self-testOK check-governed-queue-guard self-test: 132 cases passnode scripts/check-governed-queue-guard.mjs --test .github/workflows/performance-budget.yml✅ NOT GOVERNED — 1 path(s) checked against 5 governed surface(s); none matched.node scripts/check-shell-escape-residue.mjs✅ check-shell-escape-residue: OKnode scripts/check-changeset-presence.mjs✅ No source or published contract of a released package changed in this range, so no changeset is owed.— acted on: none addedEvery gate's own verdict line, with the exit code captured by redirecting to a
file first — never read through a pipe.
ESLint, narrowed and the narrowing proven (repo-wide
pnpm lintis CI's run):the two edited script files lint clean —
--format jsonreports 2 files, 0 errors,0 warnings. The workflow is outside ESLint's population entirely: asked with the
repo's own config it answers "File ignored because no matching configuration was
supplied." And the config enables no type-aware linting
(
js.configs.recommended+tseslint.configs.recommended, noparserOptions.projectorprojectService), so this diff cannot move the verdicton any untouched file.
Scope
Clause-② stayed
no— no predicate, no scan population, no verdict, noconstant. Comments in three files, plus four
itcases in the gate's existingtest file. The prose was checked against the gate's behaviour, not only its
count, and it was right about behaviour: the aggregate really is one number over
the whole closure and really cannot localise a regression, which is why
PER_CHUNK_GZIP_CEILINGSexists. objectui#7518's aggregate-headroom sentenceswere not touched.
Also folded in, exactly as the card and its triage ruled — a clarifying sentence,
deleting neither figure: the header names both
3.07 MBand3.12 MBin oneparagraph without saying which is which. They are
BASELINE's measured payloadand
MAX_EAGER_CLOSURE_GZIP_BYTESrendered in MiB; the note now says so.Out of scope, filed unassigned after a REST dedup over the
findinganddomain:devxlabel listings paged to exhaustion (203 unique open issues) with#7528 as a known-hit control:
regression the gate must catch**)** where the file's own design argument assumes
45.7 KB.
Bundle Analysisis a required context, so the next ~4 KB of eagerclosure lands red on
main. Not a ceiling-raise request; the two honest routes(find the bytes, or a declared re-baseline) are the maintainer's call.
performance-budget.yml's prose carries no pin of this shape, andthe two obstacles to extending it are named there.
Neither is addressed here; both remain open.
Generated by Claude Code