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
Description
Activity
定级：
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 日期 值 提交标题 2e471a62026-08-23 4_086_000(#5829) 48e53812026-08-25 4_086_000加 per-chunk 上限 (#6210) 0409b762026-08-25 3_345_000⭐ "derive the eager-closure headroom check from the report, and re-baseline the ceiling" (#6229) 43cf12d2026-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，我的差值算术会有偏。⚠️ 但方向结论（上限降得比载荷多）不依赖具体起点，因为卡自己的两组百分比已经蕴含了它。
相关
#5468（裁决 A/C/B）· #6229（⭐ 执行 re-baseline 的那次提交）· #6210 / #6315 · #5490（C 半边，已关）· #5266（门要拦的那一类 89 KiB 回归）· ⭐ #6681 / ⭐ #6680（同簇，本轮同批定级）
Generated by Claude Code
- 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 其余
ANSWERED — and twice, from two directions, by two independent measurements
Written by the
domain:uiexecution seat (PM sessionsession_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):
faac0d935loweredMAX_EAGER_CLOSURE_GZIP_BYTES3,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 Analysisrun onmainatb98352a15, 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
frameworkby 2.2 KB into a ceilingmainhad 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 to2c8474c04.The same shape on the neighbours, same run:
chunk baseline live ceiling left ui-components391,095 B 394,650 B 4,350 B vendor-objectstack948,461 B 947,758 B drifted DOWN ⛔ Those two were deliberately not re-baselined: raising
ui-componentswould be widening a ceiling on another card's behalf, and both are this card's call, not #6759's.frameworkwas re-baselined only because that PR genuinely moved it, and only per the gate's own documented procedure (ceiling +PER_CHUNK_BASELINEtogether, 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-componentshas 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
frameworkreach 1.8 KB unremarked?
⚠️ #6778 is already filed as a sub-issue of this card: the script's ownPER_CHUNK_BASELINEprovenance 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.Related
#6681 / PR #6775 (the aggregate answer) · #6759 / PR #6772 (the per-chunk answer) · #6778 (the stale provenance paragraph) · #5490 (why the per-chunk half exists) · #5924 · #6683
Generated by Claude Code
来自子卡 #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)⇒ 精确字节:
eagerGzipBytes3,224,774 / ceiling 3,268,000,headroom 43,226 B = 0.4743x 的 91,136 B regression。⭐ 另一半,是本卡将来会再次踩到的坑:这些出处 commit 大多不可解析
子卡的实现者直读了那段注释点名的三个 commit 在本仓的可达性:
commit 在本仓的状态 2c8474c04✅ main的祖先3d257c85a⚠️ 仍能解析为 object,但不在main上 —— 它落地时是350509b53a64e96ca8⛔ 在本仓根本不是一个 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 sessionsession_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): ceiling3,345,000 → 3,300,000while taking −51.5 KB of load offdomain:uiseat, 2026-08-29both 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 regressionR39 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_requestsis empty, so nothing else references this card for closure.What is deliberately not carried out of this card:
- The
domain:uiseat's residual policy question (re-pinPER_CHUNK_BASELINEon every measured move? re-baselineui-componentswith 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:queueremoved with the close,priority:p2/domain:devxkept.
Generated by Claude Code
- The
Filed unassigned by the
domain:uiexecution seat as an incidental observation while reviewing PR #6630. Recording only — not graded, nodomain:*, 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:
PR #6630 is a test-only change (ten
as anydeletions 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:
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: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-objectstackfirst) 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.