ci(budget): raise the framework per-chunk ceiling to 100,000 by maintainer ruling - #8550
Merged
Merged
Conversation
…ntainer ruling `PER_CHUNK_GZIP_CEILINGS.framework` moves 71,000 -> 100,000 and `PER_CHUNK_BASELINE.framework` moves 61,465 -> 72,245 in the same commit, the latter re-derived from a real `apps/console` build on `3f775eeb8` rather than copied from a card. The number is the maintainer's, taken after the trade-off was put to them. What the bytes buy is nothing identifiable: `Bundle Analysis` went red on `main` at `f76f43628` with `40a7c538a` the last green, and that window has never been bisected. This raise does not answer that question, it makes it harder to ask. Headroom is 27,755 bytes = 0.30x REGRESSION_THIS_GATE_MUST_CATCH_BYTES, which makes `framework` the loosest per-chunk ceiling in the file (0.21x, 0.06x, 0.03x for the other three, all read from the same build). The sensitivity constant is untouched at 89 * 1024, and so are the other three ceilings, the aggregate and BASELINE. The per-KEY provenance block splits `framework` out of the bullet it shared with `i18n-locales`, since the two are no longer one build. The test file's prose restatement of the retiring pair is updated because this commit is what makes it false. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CZY49skxUBYyJcdnTcYPrE
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
|
os-sales
marked this pull request as ready for review
September 8, 2026 11:03
os-sales
enabled auto-merge
September 8, 2026 11:03
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 8, 2026
os-sales
pushed a commit
that referenced
this pull request
Sep 8, 2026
…sified Three statements in `.changeset/8505-grid-columns-breakpoint-narrowing.md` became false because of this PR, and a PR that falsifies pending release text owns correcting it. The changeset is unreleased, so this keeps pending text true rather than rewriting a record. Corrected, each naming #8573 as the cause: the zod mirror is no longer left open; the 70,999-against-71,000 byte reasoning that deferred the narrowing is retired by PR #8550's raise to 100,000 against a 72,245 baseline; and the handoff assertion no longer asserts acceptance. Each correction quotes the new state rather than re-arguing the measurement. Nothing else in the file is touched -- the frontmatter and the other four paragraphs are byte-identical. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CZY49skxUBYyJcdnTcYPrE
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
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.
Part of #8541. Related: #8542, which owns the attribution and stays open.
⛔ This is a MAINTAINER RULING, and nothing else. The number
100_000is themaintainer's, taken after the trade-off was put to them. It is ⛔ not derived in this
PR, ⛔ not rounded, and ⛔ not a figure any measurement here recommends. Everything
below is what the ruling COSTS, measured — that is the half a later reader cannot
recover from the constant.
What moved
PER_CHUNK_GZIP_CEILINGS.framework71_000100_000PER_CHUNK_BASELINE.framework61_46572_245Both in one commit, as the gate's own failure text and the "Raising one" section
require. ⛔ Nothing else in that file's constants was touched: not the other three
ceilings, not
MAX_EAGER_CLOSURE_GZIP_BYTES, notBASELINE, and above all notREGRESSION_THIS_GATE_MUST_CATCH_BYTES, which stays at89 * 1024— the file saysat
:203-205that re-baselining must never become an excuse to widen the sensitivity,and this raise is the exact case that rule was written for.
The baseline was re-derived, not copied
72_245is read out ofapps/console/dist/eager-closure.jsonfrom a real build on3f775eeb8(this branch's base, themaintip it was cut from), with no diff of itsown applied —
pnpm turbo run build --filter='./packages/*'thenpnpm --filter @object-ui/console build, wrapper exit 0. ⛔ Not copied from #8541,#8542, or PR #8544.
It coincides exactly with the
72,245a dev on PR #8544 measured on merge base3bc187b7f. Two independent builds on two different commits agreeing to the byte isworth more than either alone, and it is a coincidence of readings, not a citation.
The per-KEY provenance block is updated with it:
frameworkis split out of the bulletit shared with
i18n-locales, because the two are no longer one build. That split alsocorrects a claim in the inherited text — the shared bullet warned that neither entry was
a reading of an unmodified tree, which is true of
i18n-locales(its chunk does notexist without the
vite.config.tsdiff that created it) and is not true of the newframeworkreading, whose change lives entirely inscripts/, not a build input.What the bytes buy: NOTHING IDENTIFIABLE
The gate's failure text demands the author "say in the PR what the bytes buy". The
honest answer is that nobody knows, and stating that is the point rather than a gap to
be filled with a plausible story.
The ~1.6 KB regression between
40a7c538a(last green) andf76f43628(first red) isstill UNATTRIBUTED. Nobody has run the bisect. Two seats looked at the same
four-commit window and named two different "obvious" suspects —
f76f43628(#8512'sper-operator refusal strings into
packages/core) and270f2825b(#8518, five shippedpackages plus console) — and neither built anything to check. The endpoints of that
~1.6 KB are themselves arithmetic over figures quoted in other PRs' commit messages
(
70,651, then70,999), ⛔ neither of them re-measured on the commit it is attributedto.
was the only thing holding the unexplained bytes in view; after this it passes over
them. The checker is a two-build predicate over four commits — the cheapest bisect this
repository has — and raising the ceiling removes the daily reminder that nobody has run
it. #8542 owns that attribution and is deliberately left open.
This makes
frameworkthe loosest per-chunk ceiling in the fileMeasured, not asserted. All four read from the one
3f775eeb8build, againstREGRESSION_THIS_GATE_MUST_CATCH_BYTES=91,136:frameworkvendor-objectstackui-componentsi18n-locales⇒
frameworknow carries more slack than the next loosest and an order of magnitudemore than the tightest, and it abandons the 0.10x convention objectui#7399 re-pinned
this key and
i18n-localesto. It is still inside one regression — 1.00x is whereevaluateHeadroomSensitivitycalls a line blind — but "not blind" is the floor thisfile refuses to fall through, not a standard it aims at.
Verification
All exit codes captured by redirect before any pipe.
node scripts/check-eager-closure-budget.mjs(before)framework 70.6 KB / 69.3 KB ceiling (OVER by 1.2 KB)node scripts/check-eager-closure-budget.mjs(after)pnpm exec vitest run— 5 gate test filesTest Files 5 passed (5)·Tests 219 passed (219)node scripts/check-control-bytes.mjsnode scripts/check-changeset-presence.mjsno changeset is owedpnpm run type-check:scriptspnpm exec eslint(2 changed files)Four-leg verdict after the change, from the gate's own printed lines:
The payload is byte-identical before and after: the diff is two files under
scripts/,and the console build's turbo
inputscoverscripts/vite-*.ts, notscripts/check-*.mjsorscripts/__tests__/— the same argumentBASELINE's own blockmakes about its commit. Only the line the payload is weighed against moved.
PER_CHUNK_BASELINEfeeds no verdict — ablated, with a positive controlThe file states at
:1227thatBASELINEandPER_CHUNK_BASELINEare deliberatelyabsent from
VERDICT_CEILING_CONSTANTS. Checked rather than taken on trust, both legsrestored by comparing
git hash-objectagainst theHEADblob:PER_CHUNK_BASELINE.framework72,245 to 9,999PER_CHUNK_GZIP_CEILINGS.framework100,000 to 9,999framework ... OVER by 60.8 KB⇒ leg A's identity is a real reading and not a harness that sees nothing. Moving the
baseline changes no verdict; it changes what the unit test weighs the ceiling against,
which is the constraint
ceiling - measuredstays under one regression (27,755 against91,136 — asserted in
scripts/__tests__/check-eager-closure-budget.test.ts).One correction outside the two named constants
scripts/__tests__/check-eager-closure-budget.test.tscarried the sentence "frameworkis now pinned at 71,000 over a 61,465 payload". This commit is what makes that false, so
it is updated in the same commit — two numerals and the magnitude word that follows from
them. ⛔ No constant, assertion or test behaviour changed;
git diffon that file isfour lines of prose.
The dispatch stated that #8541 and #8542 are both unlabelled, and that no card could
therefore be claimed. Read over REST at the time of writing, both carry labels:
bug,ci/cd,tooling,domain:devx— and is closed, as aduplicate of CI BLOCKER:
mainis red onBundle Analysissincef76f4362— theframeworkchunk is OVER its per-chunk ceiling, and every PR touching core/react/types inherits it #8542.mainis red onBundle Analysissincef76f4362— theframeworkchunk is OVER its per-chunk ceiling, and every PR touching core/react/types inherits it #8542 —bug,ci/cd,pm:queue,tooling,domain:devx,priority:p1, andis open.
This does not change what was done: the authorisation for this PR is the maintainer
ruling, not a card claim, and no claim was posted. It does mean the stated reason for
not claiming was not the true one, and that
Part of #8541points at a card that isalready closed — #8542 is the live one. ⛔ Neither card is closed by this PR; that is
triage's call, and the attribution question stays open regardless.
🤖 Generated with Claude Code
https://claude.ai/code/session_01CZY49skxUBYyJcdnTcYPrE
Generated by Claude Code