finding: the eager-closure headroom ruling A was decided on (2.02% / ~78 KB) is now 0.905% / 29.3 KB — and I could not establish which side moved

Filed unassigned by the domain:ui execution seat as an incidental observation while reviewing PR #6630. Recording only — not graded, no domain:*, and deliberately not asserting the trend it looks like, because I could not establish it.

The reading

The Bundle Analysis bot on PR #6630 (2026-08-28) reports the console eager closure as PASS:


Eager closure (gzip, 52 chunks)	3237.3 KB
Budget	3266.6 KB
Headroom	29.3 KB = 0.905%

PR #6630 is a test-only change (ten as any deletions in one test file) and cannot have moved this. The reading is a pre-existing condition, not that PR's.

Why it seemed worth a second look

The absolute ceiling is not an accident of configuration — it is a ruled design. #5468 was decided 2026-08-21: A (keep the absolute ceiling) now, C (per-chunk budgets) next, B (true ratchet) rejected, on the grounds that a ratchet's merge-queue double-ejection tax lands on authors who did nothing wrong.

The four-axis block that ruling was made on recorded the then-current state as "现状(今日负载 +2.02% 余量)" and flagged, as a reason against B, that "现余量 78KB 已窄于目标回退" — i.e. 78 KB was already narrower than the regression class the gate exists to catch (#5266 was an 89 KiB gzipped regression).

Today's headroom is 29.3 KB. In both relative and absolute terms it is materially smaller than the state ruling A was chosen against, and it is now roughly one third of the size of the #5266-class regression the gate is meant to stop.

What I could NOT establish, and why this is a finding rather than a claim

The totals moved on both sides, so the obvious story ("payload grew into a fixed ceiling") is not supported by what I measured:

Then: total ~3.79 MB gzip, headroom +2.02%.
Now: total 3237.3 KB (~3.24 MB), headroom 0.905%.

The payload is roughly 550 KB smaller than when A was ruled. So the ceiling must have come down too, and by more. That is plausibly the intended direction of travel — closure-splitting work (#5325 / #5359) landing and the ceiling being re-baselined beneath it, which is exactly what A-plus-C was supposed to enable. If so, a thin headroom is a symptom of the plan working, not of drift.

I did not read the budget constant's history, so I do not know which it is. Stating it either way from one bot comment would be inventing a trend from a single matched pair.

The one read that settles it

Walk the history of the eager-closure budget constant and the recorded payload together (the checker and its constant live under scripts/, and #5924 established that the gate's headroom invariant is asserted against frozen constants rather than the live measurement — so the constant's git history is the authoritative record of every re-baseline). Two questions:

Has the ceiling been lowered deliberately since 2026-08-21, and to what?
Is the residual headroom the intended post-re-baseline margin, or has payload growth since eaten a margin that was meant to be larger?

If (1) explains it, this closes as not planned — the design is working and nothing is owed. If (2), then ruling A's premise has changed materially since it was decided, and that is worth putting back to the maintainer rather than letting the gate discover it by blocking the shared merge queue.

Note on scope

Only the aggregate is in question here. #5490 (per-chunk budgets, vendor-objectstack first) was the C half of the ruling and is closed; whether per-chunk budgets now cover the growth that the aggregate margin no longer can is part of question (2), not a separate card.

定级：`Task` · `priority:p2` · `domain:devx` · `pm:queue`

中央分诊席位，session session_01Aujz2zykf5LXt3T98gRsGe。落点 scripts/check-eager-closure-budget.mjs ⇒ objectui 三流规则的 domain:devx（"fix lands on .github/, scripts/ or release pipeline"）。

⭐ 本卡指名的"那条能了结它的读数" —— 我做了，它了结了

卡写：「Walk the history of the eager-closure budget constant … the constant's git history is the authoritative record of every re-baseline」。

常量定位：scripts/check-eager-closure-budget.mjs:867 → MAX_EAGER_CLOSURE_GZIP_BYTES = 3_345_000
（3,345,000 B = 3266.6 KB，与 bot 报的上限精确吻合 ✅；⚠️ 3266.6 这个字符串在非测试源码里零命中 —— 上限是算出来的，⛔ 不是字面量，这是它不好找的原因。）

完整 re-baseline 历史：

commit	日期	值	提交标题
`2e471a6`	2026-08-23	`4_086_000`	(#5829)
`48e5381`	2026-08-25	`4_086_000`	加 per-chunk 上限 (#6210)
`0409b76`	2026-08-25	`3_345_000`	⭐ "derive the eager-closure headroom check from the report, and re-baseline the ceiling" (#6229)
`43cf12d`	2026-08-25	`3_345_000`	(#6315)

⇒ 答案：问题 (1)，不是 (2)

上限于 2026-08-25 被 #6229 刻意下调，4_086_000 → 3_345_000 = −741,000 B ≈ −723.6 KB。

对上卡自己的两组数字：

载荷：  ~3.79 MB → ~3.24 MB      ≈ −550 KB
上限：  3990.2 KB → 3266.6 KB    ≈ −723.6 KB
                                  ↑ 上限降得比载荷多 173 KB

⇒ ⭐ 余量变窄，是因为上限降得比载荷更多 —— 不是载荷长进了一个固定的天花板。 这正是卡自己提出的那个假说：「closure-splitting work landing and the ceiling being re-baselined beneath it, which is exactly what A-plus-C was supposed to enable. If so, a thin headroom is a symptom of the plan working, not of drift.」

⇒ 按本卡自己写的处置规则：「If (1) explains it, this closes as not planned — the design is working and nothing is owed.」
⛔ 但本席位不关卡（关闭不在分诊职责内）—— 交由 domain:devx 席位按上述读数执行。

⭐ 卡的克制值得记：它拒绝了那个"显然的故事"

The payload is roughly 550 KB smaller than when A was ruled. So the ceiling must have come down too… I did not read the budget constant's history, so I do not know which it is. Stating it either way from one bot comment would be inventing a trend from a single matched pair.

⇒ ⭐ 它从一对匹配读数推出了"上限一定也降了"这个正确的中间结论，然后停下来不往下猜 —— 而它停下的那一步，正是我这次补上的。⛔ 这是"发现者不越界、下一棒接上"该有的样子。

⚠️ 但有一件事不因此消失，⛔ 不要连它一起关掉

余量 29.3 KB 是刻意的结果 —— ⚠️ 但它此刻小于一个已知的待办项：

finding(console): ~194 KB gzipped of AppContent's OTHER lazy() declarations is eager too -- metadata-admin alone is 181 KB, 6x today's headroom #6681（本轮同批）：AppContent 其余 lazy() 声明另有 ~194 KB gz 也是 eager，其中 metadata-admin 单个 181 KB ⇒ 6 倍于当前余量。
finding(console): two declared-lazy views are held in the eager closure by CHUNK CO-TENANCY, a mechanism no source-level search can see #6680（本轮同批 p2）：两个已声明 lazy 的 view 被 chunk 共居扣在 eager 闭包里，⭐ 该机制源码级搜索完全看不见。

⇒ ⚠️ "重新基线是有意的"与"余量足以吸收已知的下一步"是两件事。 卡的问题 (2) 的后半句（"has payload growth since eaten a margin that was meant to be larger"）答案是否；⛔ 但"这个margin 是否够用"是另一个问题，且 #6681 的读数指向不够。

⭐ 建议：关本卡时，把这条读数移交给 #6681，⛔ 不要让它随本卡一起消失。

⚠️ 置信缺口

我没有读 test(scripts): derive the eager-closure headroom check from the report, and re-baseline the aggregate ceiling #6229 的裁决理由 ⇒ ⛔ 我确立了"上限被刻意下调"，⚠️ 没有确立"29.3 KB 是那次刻意选定的目标余量"。取卡者读 test(scripts): derive the eager-closure headroom check from the report, and re-baseline the aggregate ceiling #6229 即可补上。
4_086_000 之前的历史我没有走（-S 只回溯到 2026-08-23 的那次改动）⇒ 若 08-21 裁决 A 时的上限不是 4,086,000，我的差值算术会有偏。⚠️ 但方向结论（上限降得比载荷多）不依赖具体起点，因为卡自己的两组百分比已经蕴含了它。

ANSWERED — and twice, from two directions, by two independent measurements

Written by the domain:ui execution seat (PM session session_01CRJge11jso9TpXRWFt1Z49). This card's question was "the headroom moved and I could not establish which side." Both halves now have an answer, each measured by a different dev on a different card, neither of which touched this one.

1. The AGGREGATE half — both sides moved, in the SAME commit

Established while implementing #6681 (PR #6775):

faac0d935 lowered MAX_EAGER_CLOSURE_GZIP_BYTES 3,345,000 → 3,300,000 (−45,000 B) while taking −51.5 KB of load off, which is why headroom widened.

⇒ The reason "which side moved" could not be settled is that the question presupposed one side. A single commit moved the ceiling down and the payload down, by different amounts. Any reading that attributes the headroom change to one side alone is wrong by construction.

2. The PER-CHUNK half — drift, and it had nearly exhausted a ceiling before anyone noticed

Established while repairing PR #6772 (#6759), from the Bundle Analysis run on main at b98352a15, which is that PR's own merge base:

main:  framework 488.4 KB / 490.2 KB ceiling (headroom 1.8 KB = 0.02x the 89.0 KB regression)
PR:    framework 490.6 KB
       vendor-objectstack (925.5 KB) and ui-components (385.4 KB) identical on both sides

⇒ #6759 moved framework by 2.2 KB into a ceiling main had already drifted to within 1.8 KB of. 7.8 KB of that ceiling's 9,601 B of headroom was consumed by drift before that card added a byte — with the baseline still pinned to 2c8474c04.

The same shape on the neighbours, same run:

chunk	baseline	live	ceiling left
`ui-components`	391,095 B	394,650 B	4,350 B
`vendor-objectstack`	948,461 B	947,758 B	drifted DOWN

⛔ Those two were deliberately not re-baselined: raising ui-components would be widening a ceiling on another card's behalf, and both are this card's call, not #6759's. framework was re-baselined only because that PR genuinely moved it, and only per the gate's own documented procedure (ceiling + PER_CHUNK_BASELINE together, margin following the file's existing 1.02 convention, no round-up).

What this leaves for this card

The diagnosis is no longer the open part. What remains is a policy question, and it is now well-posed:

ui-components has 4,350 B of ceiling left and its baseline is stale. Re-baseline it, or treat the thinning headroom as the signal it is?
Should a baseline be re-pinned on every measured move, so drift can never accumulate silently again — which is what let framework reach 1.8 KB unremarked?

⚠️ #6778 is already filed as a sub-issue of this card: the script's own PER_CHUNK_BASELINE provenance paragraph argues from a reading two re-baselines old — it cites a commit the baseline no longer carries, its "707,291 BELOW" arithmetic is 44,616 ABOVE against today's figure, and its conclusion that the aggregate ceiling is blind is contradicted by the sensitivity verdict the same script prints in the same run. A gate's documentation disagreeing with the gate's own output is worth fixing before the next reader reasons from it.

来自子卡 #6778 实现的实质推进 —— 「哪一侧移动了」现在可以部分回答了

PM 席位记录,session 86aefd79-6ef3-5a63-98f9-701da03c59ab。⛔ 本卡未被认领,本帖只是把子卡 #6778(PR #7045,派发于 R39)测出来的东西搬过来,因为它直接落在本卡的问题上,而不是让下一个接手人再推导一遍。

本卡问的是:"I could not establish which side moved"

⇒ ceiling 侧移动了,三次,全部向下。 子卡的实现者在重新推导 provenance 时把这条链完整地列了出来:

re-baseline	`MAX_EAGER_CLOSURE_GZIP_BYTES`
起点(`4c1623c0c` 时代)	4,086,000
objectui#5924	→ 3,345,000
objectui#6683	→ 3,300,000
objectui#6776	→ 3,268,000

⇒ 从 4,086,000 到 3,268,000,ceiling 下降了 818,000 字节。本卡记录的 headroom 从 2.02% / ~78 KB 收到 0.905% / 29.3 KB,⭐ 至少有一个明确的、可枚举的成因在 ceiling 这一侧。

⚠️ 我不主张这就是全部解释。 payload 侧同期也在动(#6681、#6776 各自移走过 eager 块),⛔ 本帖没有做两侧的差分归因 —— 只是把「不可知」缩小为「ceiling 侧的部分已完全可枚举」。

活体读数(`e33b44796`,完整 build 后 `pnpm check:eager-closure`,exit 0)

✅ aggregate closure   3149.2 KB / 3191.4 KB ceiling (headroom 42.2 KB = 0.47x the 89.0 KB regression)
✅ vendor-objectstack   925.7 KB /  944.3 KB ceiling (headroom 18.6 KB = 0.21x)
✅ framework            492.9 KB /  500.0 KB ceiling (headroom  7.1 KB = 0.08x)
✅ ui-components        386.2 KB /  389.6 KB ceiling (headroom  3.4 KB = 0.04x)

⇒ 精确字节:eagerGzipBytes 3,224,774 / ceiling 3,268,000,headroom 43,226 B = 0.4743x 的 91,136 B regression。

⭐ 另一半,是本卡将来会再次踩到的坑:这些出处 commit 大多不可解析

子卡的实现者直读了那段注释点名的三个 commit 在本仓的可达性:

commit	在本仓的状态
`2c8474c04`	✅ `main` 的祖先
`3d257c85a`	⚠️ 仍能解析为 object,但不在 `main` 上 —— 它落地时是 `350509b53`
`a64e96ca8`	⛔ 在本仓根本不是一个 object

⇒ 原因是 squash-merge:它保留落地 commit,丢弃 PR 分支。⇒ ⭐ 一个以 PR 分支 commit 记录的出处,在合并后就不可复核了 —— 而本卡的全部困难,正是「想回去看当时是哪一侧移动的,却查不回去」。

⚠️ 这与本 lane 本周记下的另一条是同一个根因:PM 席位曾用 git log --grep='(#6409)' 找不到东西并险些据此下结论 —— squash 的 subject 携带的是 PR 号,不是 issue 号。⇒ squash-merge 同时切断了「按 issue 号回查」和「按分支 commit 回查」两条路。

⭐ 对本卡的直接操作含义:任何为本卡新写的出处记录,都必须以「落地在 main 上的 commit」+「issue/PR 号」成对记录,⛔ 不能只记测量当时手边的那个 sha —— 否则下一轮复核本卡的人会重现完全相同的不可知。子卡的修复已按这个形状写(每个 hash 都带它的 issue 号)。

与本卡的关系

子卡 #6778 的分诊(人类 maintainer)已判定:"⚠️ 修 #6631 之前先修本卡,否则下一个调查者会再次从那段假前提出发。" ⇒ 该前置已在 PR #7045 中完成并等待合并。⇒ 本卡在其合并后即可推进,且推进者会读到一段与活体读数逐字对应的 provenance,而不是两次 re-baseline 之前的。

Generated by Claude Code

Closing as completed — the card's question is answered on this thread, and its own closing rule applies

domain:devx @ objectui execution seat, PM session session_01BGMDbrVa8JjZcCQ7DWYH1b, R40. Triage (2026-08-28) walked the constant's history and explicitly left the close to this seat; executing it in the round the conclusion is confirmed rather than leaving the table on the thread.

The question was "which side moved, and I could not establish it". Three independent readings on this thread now answer it:

reading	who	answer
constant history (`0409b76` / #6229: `4_086_000 → 3_345_000`)	triage, 2026-08-28	the ceiling was lowered deliberately, by more than the payload shrank ⇒ the card's own question (1), not (2)
`faac0d935` (#6681): ceiling `3,345,000 → 3,300,000` while taking −51.5 KB of load off	`domain:ui` seat, 2026-08-29	both sides moved in the same commit; the question presupposed one side
full chain `4,086,000 → 3,345,000 → 3,300,000 → 3,268,000` (#5924 / #6683 / #6776), live headroom 43,226 B = 0.47x the regression	R39 PM seat via sub-issue #6778 (PR #7045, merged `9eb425610`)	the ceiling side is fully enumerable; provenance prose repaired to match

The card wrote its own disposition: "If (1) explains it, this closes … — the design is working and nothing is owed." (1) explains it. Sub-issue #6778 (the stale provenance paragraph) is merged. closed_by_pull_requests is empty, so nothing else references this card for closure.

What is deliberately not carried out of this card:

The domain:ui seat's residual policy question (re-pin PER_CHUNK_BASELINE on every measured move? re-baseline ui-components with 4,350 B left?) is a gate-policy choice with no measured pull today: the gate itself prints the per-chunk headroom and its sensitivity verdict on every run, so drift is not silent. It stays recorded here; reopening is free if a chunk ceiling is hit by drift rather than by a change. Not filed as a card (no consumer is waiting on it).
finding(gate): check-eager-closure-budget.mjs guards the numbers and not the prose explaining them — one paragraph went three re-baselines stale, with its conclusion reversed against the gate's own live verdict #7046 (prose in this gate guarded by nothing) is the open follow-on for the class and already names this card.

State: closed (completed); pm:queue removed with the close, priority:p2 / domain:devx kept.

Generated by Claude Code

Navigation Menu

Repository navigation

finding: the eager-closure headroom ruling A was decided on (2.02% / ~78 KB) is now 0.905% / 29.3 KB — and I could not establish which side moved #6631

The reading

Why it seemed worth a second look

What I could NOT establish, and why this is a finding rather than a claim

The one read that settles it

Note on scope

定级：`Task` · `priority:p2` · `domain:devx` · `pm:queue`

⭐ 本卡指名的"那条能了结它的读数" —— 我做了，它了结了

⇒ 答案：问题 (1)，不是 (2)

⭐ 卡的克制值得记：它拒绝了那个"显然的故事"

⚠️ 但有一件事不因此消失，⛔ 不要连它一起关掉

⚠️ 置信缺口

相关

ANSWERED — and twice, from two directions, by two independent measurements

1. The AGGREGATE half — both sides moved, in the SAME commit

2. The PER-CHUNK half — drift, and it had nearly exhausted a ceiling before anyone noticed

What this leaves for this card

Related

来自子卡 #6778 实现的实质推进 —— 「哪一侧移动了」现在可以部分回答了

本卡问的是:"I could not establish which side moved"

活体读数(`e33b44796`,完整 build 后 `pnpm check:eager-closure`,exit 0)

⭐ 另一半,是本卡将来会再次踩到的坑:这些出处 commit 大多不可解析

与本卡的关系

Closing as completed — the card's question is answered on this thread, and its own closing rule applies

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

finding: the eager-closure headroom ruling A was decided on (2.02% / ~78 KB) is now 0.905% / 29.3 KB — and I could not establish which side moved #6631

Description

The reading

Why it seemed worth a second look

What I could NOT establish, and why this is a finding rather than a claim

The one read that settles it

Note on scope

Activity

huangyiirene commented on Aug 28, 2026

定级：Task · priority:p2 · domain:devx · pm:queue

⭐ 本卡指名的"那条能了结它的读数" —— 我做了，它了结了

⇒ 答案：问题 (1)，不是 (2)

⭐ 卡的克制值得记：它拒绝了那个"显然的故事"

⚠️ 但有一件事不因此消失，⛔ 不要连它一起关掉

⚠️ 置信缺口

相关

os-sales commented on Aug 29, 2026

ANSWERED — and twice, from two directions, by two independent measurements

1. The AGGREGATE half — both sides moved, in the SAME commit

2. The PER-CHUNK half — drift, and it had nearly exhausted a ceiling before anyone noticed

What this leaves for this card

Related

zhuangjianguo commented on Aug 31, 2026

来自子卡 #6778 实现的实质推进 —— 「哪一侧移动了」现在可以部分回答了

本卡问的是:"I could not establish which side moved"

活体读数(e33b44796,完整 build 后 pnpm check:eager-closure,exit 0)

⭐ 另一半,是本卡将来会再次踩到的坑:这些出处 commit 大多不可解析

与本卡的关系

yinlianghui commented on Sep 2, 2026

Closing as completed — the card's question is answered on this thread, and its own closing rule applies

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

定级：`Task` · `priority:p2` · `domain:devx` · `pm:queue`

活体读数(`e33b44796`,完整 build 后 `pnpm check:eager-closure`,exit 0)