The eager-closure budget has 4.0 KB of live headroom (0.05x the regression it must catch) where its own design argument assumes 45.7 KB

[claude]

Measured while working objectui#7528 (prose-only card, no constant touched). Filing
rather than riding it in: this is a decision about bytes, not a comment fix.

The live margin is 4.0 KB, and the design argument assumes 45.7 KB

Measured on 52cac3886 — a full pnpm turbo run build --filter='./packages/*'
plus pnpm --filter @object-ui/console build, then pnpm check:eager-closure:

✅ Console eager closure is 3187.4 KB gzipped across 50 of 518 chunks (budget: 3191.4 KB, headroom: 4.0 KB).
✅ Ceiling sensitivity (5 ceilings, each weighed against the report just read):
  ✅ aggregate closure   3187.4 KB measured / 3191.4 KB ceiling (headroom 4.0 KB = 0.05x the 89.0 KB regression)  [MAX_EAGER_CLOSURE_GZIP_BYTES]

Raw, from apps/console/dist/eager-closure.json: eagerGzipBytes 3,263,896
against MAX_EAGER_CLOSURE_GZIP_BYTES 3,268,000 — 4,104 bytes of headroom.

The header of scripts/check-eager-closure-budget.mjs states what the ceiling was
chosen to be: "today's measured payload plus half the 89 KiB regression the gate
exists to catch". Against BASELINE.gzipBytes (3,222,314, commit 3d257c85a)
that is 45,686 bytes, 0.50x the regression — the figure objectui#7518 confirmed as
the file's own current reading. The live payload has since grown 41,582 bytes, so
the margin actually in force is 9% of the one the design argues for.

Why this is worth a card

• Bundle Analysis is a required context. Any change adding ~4 KB to the
  eager closure lands red on main, not on the PR that discusses it.
• The per-chunk ceilings are in the same state: ui-components 4.0 KB (0.04x),
  i18n-locales 5.7 KB (0.06x), framework 2.4 KB (0.03x). Only
  vendor-objectstack (18.2 KB, 0.20x) has real room.
• The gate is not broken — it is reporting this itself, in the sensitivity half
  objectui#5924 added. Nothing else says it out loud.

⛔ What this is NOT a request for

Not a ceiling raise. The file rules on that in its own words: "Silently bumping
the number to make CI green reproduces the gate this file replaced", and
re-baselining "is a DECISION, so make it visible". Two honest routes:

1. Find the bytes. objectui#7486 is a live candidate already filed — the
   console eagerly fetches all ten locale catalogues, ~476 KB gzipped, where a
   viewer uses one.
2. A declared re-baseline, with what the added bytes buy written in the PR,
   which is the procedure the header already sets out.

Choosing between them is the maintainer's call, which is why this is filed
unassigned rather than fixed.

Not covered elsewhere

objectui#7518 (closed) was about two prose sentences disagreeing about the
headroom, both computed against the frozen baseline; this is the live margin,
which neither sentence describes. objectui#7528 is prose-only and ⛔ ruled out
touching any constant or verdict.

---

Generated by Claude Code

[claude]

独立复现：4 KB 余量已在第二个、与本卡无关的 PR 上被重新观测到

本卡的读数原本只有一个来源（卡 #7528 的执行席在自己重新构建后测出的 3,263,896 / 3,268,000）。现在有了第二次、独立的观测，来自一个内容完全不相干的 PR。

2026-09-06T01:16Z，PR #7879（fix(app-shell): a failed package-list refresh is not a deletion，卡 #7821，3 files +362/−4）上 Console Performance Budget 机器人的报告：

Metric	Value	Budget	余量
Eager closure (gzip, 50 chunks)	3187.3 KB	3191.4 KB	4.1 KB
Main entry chunk (gzip)	143.5 KB	350 KB	206.5 KB
Status	PASS

⇒ 三件事因此从「一次测量」升级为已确认的现状：

1. 余量确实是约 4 KB，不是某次构建的抖动。 两次观测相隔约一小时、在两棵不同的树上、由两条不同的路径产生（一次是人手重新构建，一次是 CI 的必需上下文），给出同一个量级。
2. 50 chunks 这个数也被机器人独立复现了 —— 与 Two more frozen measurements in the eager-closure gate's prose that #7518's ruling did not cover: "52 chunks" and the workflow's "3.15 MB" #7528 落地时实测的 50 一致（而当时该文件散文写的是 52、BASELINE.chunks 写的是 48）。
3. ⚠️ 入口 chunk 的余量是 206.5 KB，eager closure 的余量是 4.1 KB —— 相差 50 倍。 这正是本卡最容易被误读的地方：一个只看入口 chunk 的读者会得出「预算宽松得很」的结论。⭐ 机器人自己的说明文字已经把这件事写清楚了："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 Analysis 是必需上下文 ⇒ 下一个净增约 4 KB eager 闭包的 PR 会让 main 变红，而该文件自己的设计论证假定的是 45.7 KB 余量。逐 chunk 天花板同样紧。

⚠️ 需要注意的一点：#7879 自己是 +362/−4 的 app-shell 改动，它通过了 —— 所以这不是「任何 PR 都会挂」。危险的是净增静态导入闭包的改动（新的顶层 import、把懒加载改成静态、给已在闭包里的包加依赖），而这类改动的作者通常不会预期自己在动 bundle 预算。

⛔ 本车道仍不抬天花板、不重设基线，等人工裁决。

🔎 一条待你核实的线索：另有席位正在 PR #7685 上执行一次四常量天花板抬升（MAX_EAGER_CLOSURE_GZIP_BYTES + BASELINE.gzipBytes + PER_CHUNK_GZIP_CEILINGS / PER_CHUNK_BASELINE['vendor-objectstack']），并称持有维护者原话授权。若属实，本卡的处置可能已由那条路径覆盖；⛔ 本席只记录，不据此动手，也未去核实那条授权的真伪。

---

Generated by Claude Code

[claude]

⚠️ 给维护者的状态更新：本卡的中心数字正被另一条在飞的 PR 取代 —— 核实过，⛔ 本席未动任何东西

本卡仍在 pm:awaiting-maintainer，本席不推进。但有一件会让本卡读数在无人改动的情况下作废的事，必须记在这里，否则下一个读者会拿着一组已经不存在的常量去决策。

核实到的事实

objectui#7685（chore(deps): resolve @objectstack/spec at 17.3.0 in the lockfile，仍是 draft、仍带 needs:contract-review、head 901c4b867、未合并）里，预算常量已经被抬高。证据不是别人的转述，是这张 PR 上预算机器人自己的连续读数：

时间	eager closure	budget	判定
2026-09-06T01:40:08Z	3467.8 KB	3191.4 KB	❌ FAIL
2026-09-06T01:46:03Z	3467.8 KB	3512.7 KB	✅ PASS

⭐ 测量值一字未动（两次都是 3467.8 KB），翻绿的是天花板。 这一点是本条记录的承重部分。

换算回本卡引用的字节常量（KB × 1024）：

MAX_EAGER_CLOSURE_GZIP_BYTES   3_268_000  →  3_597_000   （+329_000）
BASELINE.gzipBytes             3_222_314  →  3_551_191   （+328_877）

它落地后，本卡正文里的两个数字都不再指向任何东西

• 本卡的「设计论证假设 45.7 KB」= 3_268_000 − 3_222_314 = 45_686 字节。抬升后的对应数是 3_597_000 − 3_551_191 = **45_809** 字节 —— 天花板与基线同步平移（+329_000 / +328_877），所以文件自己那条「今天的载荷加上它要抓的 89 KiB 回归的一半」的 0.50× 比例被恢复了，不是被稀释。
• 本卡的「实际在手余量 4.0 KB（4_104 字节）」是在旧天花板下测的。在 objectui#7685 的分支上，抬升后的在手余量读作 3512.7 − 3467.8 = 44.9 KB。

⇒ 就形状而言，objectui#7685 走的是本卡「⛔ 这不是在要求抬天花板」一节里列出的第二条诚实路线（a declared re-baseline, with what the added bytes buy written in the PR），而不是第一条（找回字节，objectui#7486）。买到的东西是 spec 17.3.0 的升级。

⛔ 三条我没有做、也不建议本车道做的事

1. ⛔ 没有据此关掉本卡。 抬升尚未落地（objectui#7685 仍是 draft 且 needs:contract-review 未解除），而且第一条路线（objectui#7486：console 预取十份 locale catalogue，约 476 KB gzipped）没有因为这次抬升而失效 —— 它是独立的字节回收机会。
2. ⛔ 没有碰任何常量。 本卡自己的话仍然成立：Silently bumping the number to make CI green reproduces the gate this file replaced。
3. ⛔ 没有把 objectui#7685 当作先例。 它是另一个会话的 PR、另一条车道的裁量，本席只做核实。

⚠️ 一条必须转达的、不是我发现的限制

驱动 objectui#7685 的那个会话自己记录了：这次抬升是按约 4 个 commit 的漂移定尺寸的，而该分支落后 main 37 个 commit。所以合并后的真实在手余量目前是未知数，44.9 KB 这个读数不能当作落地后的结论。那个会话已经给自己定了硬约束：合并 main 后若超出，停下报数字，不许再挪常量；第二次抬升必须重新锚定 BASELINE.commit 重新推导。本席把这条原样转达，⛔ 不代它裁定，也不去核对它是否照做。

顺带更正一条本席早前的内部记录

早前有一条未核实情报被记为「另一席在 objectui#7685 上抬四个天花板常量，称持有维护者原话授权」。回到源头读，那句授权指的是分层契约复审是维护者授权（在 fable 上跑的），不是天花板抬升的授权；抬升本身是那个 PM 席在评论 5556211864 里按余量（而非按天花板）自行重新推导并辩护的。两者不是一回事，记在这里免得这条情报被下一个读者放大。

给维护者的实际问题没有变，只是换了张表： 若 objectui#7685 落地，本卡要问的就不再是「4.0 KB 够不够」，而是「37 个 commit 的漂移吃掉重建的 45.8 KB 之后还剩多少，以及 objectui#7486 那 476 KB 要不要收」。

---

Generated by Claude Code

[claude]

第九次观测 —— 余量 2.1 KB，迄今最紧，而且这次不是舍入噪音

我在 03:41 那次刻意没有上卡（3187.5 KB / 3191.4 KB ⇒ 3.9 KB，与本卡记录的 4.0 KB 只差 0.1 KB，在 KB 显示精度下等于没动，把它讲成趋势是过读）。这一次不同。

预算机器人 2026-09-06T04:08:57Z 在 PR objectui#7948 上：

Eager closure (gzip, 50 chunks)   3189.3 KB     Budget   3191.4 KB     PASS

⇒ 余量 2.1 KB。天花板仍是旧的 3191.4 KB，再次确认 objectui#7685 的抬升尚未到达 main。

⚠️ 这个位移不来自那张 PR 的 diff，这是它值得记的原因

objectui#7948 是 3 个文件 +342 / −4，但真正会进产物的只有 ObjectView.tsx 上删掉的两行（另外两个文件是一个测试文件和一个 changeset，都不发布）。一个净删除两行的分支不可能把 eager closure 推高 1.8 KB。

三次读数并排：

来源	eager closure	余量
本卡原始测量（52cac3886）	3187.4 KB	4.0 KB
PR objectui#7937 分支（03:41）	3187.5 KB	3.9 KB
PR objectui#7948 分支（04:08）	3189.3 KB	2.1 KB

⇒ 位移几乎只能来自各分支所基于的 main 不同。这半小时里 main 上落了数个 PR（objectui#7931 @03:53:51、objectui#7937 @04:10:36 等）。

⚠️ 我把它标为推断而不是测量：我没有在同一棵 main 上做前后两次 pnpm check:eager-closure，只是并排读了三个分支的机器人输出。要坐实「main 自己涨了 1.8 KB」，需要在 main 上直接测两次。⛔ 我没做，所以不声称做过。

为什么仍然值得上卡

本卡正文自己写着这条风险：

Bundle Analysis is a required context. Any change adding ~4 KB to the eager closure lands red on main, not on the PR that discusses it.

在 4.0 KB 余量下，这句话说的是「一个 4 KB 的改动会把 main 弄红」。在 2.1 KB 余量下，门槛减半 —— 一个2 KB 的普通改动就够了。这不是同一个风险等级，所以不再是噪音。

⛔ 本席未动任何常量、未做任何抬升、未推进本卡 —— 仍在 pm:awaiting-maintainer。只是把「维护者要决定的那个数字」更新到今天的真实值，免得决策基于一个 4.0 KB 的旧读数。

---

Generated by Claude Code

[claude]

⚠️ 更新：读数朝反方向动了，我早前那条推断不应被依赖

我在 04:19 贴过一条观测（#issuecomment-5556855324），说余量收紧到 2.1 KB，并推断位移来自 main 本身而非某个分支。那条我明确标了「推断，未在同一棵 main 上前后测两次」。现在有一条反方向的读数，所以必须更新，否则它会成为这张等人工卡上的最后一句话。

预算机器人 2026-09-06T05:29:40Z 在 PR objectui#7978 上：

Eager closure (gzip, 50 chunks)   3185.9 KB     Budget   3191.4 KB     PASS

⇒ 余量 5.5 KB —— 今晚最宽的一次，不是最紧的。

不只是总数，几乎每个包都变小了

包	早前读数	本次
components	510.60 KB / 116.20 gz	497.06 / 113.79
plugin-detail	250.55	247.59
plugin-chatbot	196.19	193.53
plugin-designer	212.86	211.51
plugin-form	132.87	131.01

⚠️ 这不可能由 objectui#7978 的 diff 解释 —— 那是 packages/vscode-extension 的模板改动，而 vscode 扩展根本不在 console 产物里。所以是这条分支所基于的树与早前那些分支不同。

⛔ 我不测量、也不猜原因

今晚落地了多张 PR，我没有在同一棵 main 上做前后两次 pnpm check:eager-closure，因此说不出这 13.5 KB 是哪一次改动带来的，也说不出它是否稳定。⛔ 我不会为了让记录好看而编一个因果。

对本卡的实际影响

1. ⚠️ 我 04:19 那条「余量在收紧」的推断，方向已被这条读数推翻，⛔ 不要据它决策。本卡正文里那个 4.0 KB 的原始测量，与今晚这些分支读数（1.8 / 2.1 / 5.5 KB）都不是同一棵树上的对照。
2. ⭐ 本卡要问的问题没有变：它问的从来不是「今天余量是多少」，而是**「一个由分支读数拼出来的余量，凭什么算数」**。今晚这一串来回摆动的读数，恰恰是这个问题的证据 —— 它们互相之间不可比。
3. ⇒ 维护者要决定的，仍然是本卡列的那两条诚实路线（找回字节，objectui#7486 那 476 KB locale 预取；或一次声明过的 re-baseline），外加一条本卡已经具备的方法要求：在同一棵 main 上前后各测一次，而不是并排读分支上的机器人输出。

⛔ 本席未动任何常量、未推进本卡，仍在 pm:awaiting-maintainer。

---

Generated by Claude Code