Uh oh!
There was an error while loading. Please reload this page.
docs(scripts): re-derive the PER_CHUNK_BASELINE provenance against a live gate run - #7045
Merged
zhuangjianguo merged 1 commit intoAug 31, 2026
Merged
Conversation
…live gate run The doc comment on `PER_CHUNK_BASELINE` argued from a reading three aggregate re-baselines old, and its conclusion was the reverse of what the same script prints in the same run. Three statements were false. `BASELINE` does not "still carry `4c1623c0c`" — it carries `3d257c85a`. The "707,291 BELOW" arithmetic is 4,005,911 minus 3,298,620, against a reading retired by objectui#5924. And the paragraph told a reader sizing a re-baseline that the aggregate ceiling sat far above the payload and was therefore decorative, at the moment the gate prints that it is in range. Re-derived against a live run rather than recomputed on paper. A full console build on `e33b44796` and `pnpm check:eager-closure`: ✅ aggregate closure 3149.2 KB measured / 3191.4 KB ceiling (headroom 42.2 KB = 0.47x) ✅ chunk `vendor-objectstack` 925.7 KB measured / 944.3 KB ceiling (headroom 18.6 KB = 0.21x) ✅ chunk `framework` 492.9 KB measured / 500.0 KB ceiling (headroom 7.1 KB = 0.08x) ✅ chunk `ui-components` 386.2 KB measured / 389.6 KB ceiling (headroom 3.4 KB = 0.04x) All four are inside one regression, so the aggregate half is working. What survives is a narrower claim: the per-chunk ceilings are the TIGHTER half and they say WHERE, not the only half that holds. objectui#5924, objectui#6683 and objectui#6776 closed the gap the old text described. Two things are stated so they cannot go stale the same way. Which side carries the later reading flips on every re-baseline, so the comment now tells the reader to read the commit names rather than a direction written in prose; and the quoted figures are labelled as one dated run, with the gate's own printed table named as the answer in force. Comment-only: no constant, no verdict and no test changed, and the gate prints an identical verdict before and after. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GgDDqh6YnkXqsnVTCa7wHk
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 Aug 31, 2026
zhuangjianguo
marked this pull request as ready for review
August 31, 2026 15:41
Uh oh!
There was an error while loading. Please reload this page.
zhuangjianguo
deleted the
claude/issue-6778-per-chunk-baseline-provenance
branch
August 31, 2026 15:54
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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#6778
Comment-only change to
scripts/check-eager-closure-budget.mjs: the doc comment onPER_CHUNK_BASELINE. No constant, no verdict and no test moved, and the gate prints an identical verdict before and after the edit.The live run this is written against
The card's third point is that the paragraph's conclusion contradicts a verdict the same script prints in the same run, so the new prose is validated against an actual run rather than a static recomputation. Full package build + console build on
e33b44796(the branch point, clean tree), thenpnpm check:eager-closure, exit 0:Exact bytes from the same report:
eagerGzipBytes3,224,774 against a 3,268,000 ceiling — 43,226 bytes of headroom, 0.4743x the 91,136-byte regression.What the three points turned out to be
1.
BASELINEdoes not carry4c1623c0c. It carries3d257c85a/3_222_314. The card saidbd2a7ec50/3_254_004; that was correct on 2026-08-29 and objectui#6776 has since re-baselined again, so the card's own figure was one re-baseline stale by the time it was picked up. Re-derived one33b44796, not inherited.2. The "707,291 BELOW" arithmetic. Confirmed as 4,005,911 − 3,298,620 = 707,291 exactly, which is what pinned the provenance to the retired
4c1623c0creading. Removed from the present-tense paragraph. The two historical citations of4c1623c0celsewhere in the file (in the "Why this number has moved" narrative and in theMAX_EAGER_CLOSURE_GZIP_BYTESre-baseline list) are correct as past-tense statements and are deliberately left alone.While re-deriving it, one further error in the old text: "the aggregate ceiling now sits ~787 KB above today's payload" was a units slip. 4,086,000 − 3,298,620 = 787,380 bytes, i.e. ~769 KB, not ~787 KB. The magnitude of the point (8.64x the regression, blind) was right; the unit was not. The replacement states bytes and the multiple.
3. The sharp one — the conclusion is reversed. It is. The paragraph said the aggregate ceiling is far wider than the regression it must catch, and therefore that the per-chunk ceilings are the only lines holding the three biggest chunks in place. The run above says the aggregate sits at 0.47x — in range, and
evaluateHeadroomSensitivityerrors at 1.00x. Three downward re-baselines closed the gap the old text described: objectui#5924 (4,086,000 → 3,345,000), objectui#6683 (→ 3,300,000), objectui#6776 (→ 3,268,000).What the relationship IS now
Not "the aggregate is decorative". All four ceilings are inside one regression. What survives is narrower and still worth stating: the per-chunk ceilings are the tighter half — 0.21x / 0.08x / 0.04x against the aggregate's 0.47x — so growth in those three chunks reds the gate well before the aggregate would, and they say where, which one total never can.
A fourth thing, not in the card
The paragraph opened "This is a DIFFERENT and LATER reading than
BASELINEabove". That direction is now inverted:BASELINEis3d257c85a(2026-08-30), while the per-chunk readings are2c8474c04(2026-08-25) anda64e96ca8(recorded by objectui#6759, landed 2026-08-29). Rather than swap "LATER" for "EARLIER" — which would go stale on the next re-baseline in either direction — the comment now says the direction flips on every re-baseline and tells the reader to read the commit names.Also verified and recorded, because it bears directly on objectui#6631's "nobody could establish which side moved": of the three commits the comment names, only
2c8474c04is an ancestor ofmain.3d257c85astill resolves as an object but is not onmain(it landed as350509b53), anda64e96ca8is not an object in this repository at all — squash-merge keeps the landing commit and drops the PR branch. That is why each hash is cited with its issue.Against staleness
The card's structural observation is that this file's guards cover the numbers and not the prose that explains them. This PR does not add a mechanism for that (that is a separate card), but it writes the prose so the same failure is harder: the direction claim is stated as unstable by construction, the figures are labelled as one dated run, and the gate's own printed table is named as the answer in force.
Verification
Union re-run on the final commit
aebe09174, clean tree:pnpm check:eager-closurevitest run—check-eager-closure-budget,check-side-effects-array,render-budget-comment,vite-declared-lazy-views,vite-ineffective-dynamic-importspnpm check:control-bytespnpm lint:root— the full root scope that ownsscripts/pnpm changeset:check,check-changeset-presence.mjspnpm check:entry-guard,check:esm-specifiers,check:doc-fencesThe five test files are every file in the repo that names this script (
git grep -l check-eager-closure-budget), not just its own suite.Generated by Claude Code