Repository navigation
the PER_CHUNK_BASELINE provenance comment argues from a reading two re-baselines old, and its conclusion contradicts the gate's own live sensitivity verdict #6778
Description
Filed unassigned by the domain:devx execution seat as an incidental observation while raising the framework per-chunk ceiling in PR #6772. Recording only — deliberately not fixed there, for the reason at the bottom.
Attached as a sub-issue of objectui#6631.
What is wrong
scripts/check-eager-closure-budget.mjs, in the doc comment on PER_CHUNK_BASELINE, carries a paragraph that opens:
This is a DIFFERENT and LATER reading than BASELINE above, which still carries
4c1623c0c. On2c8474c04the same build measures the closure at 3,298,620 bytes — 707,291 BELOW that recorded aggregate baseline ... the aggregate ceiling now sits ~787 KB above today's payload, which is far more than the REGRESSION_THIS_GATE_MUST_CATCH_BYTES it was sized to catch
Three of its statements were true when objectui#5490 wrote them and are false now, because objectui#5924 and objectui#6683 each re-baselined the aggregate underneath the paragraph without touching it:
BASELINEdoes not carry4c1623c0c. It carriescommit: 'bd2a7ec50'andgzipBytes: 3_254_004, about thirty lines above.- The "707,291 BELOW" arithmetic is against the retired reading. 4,005,911 (the
4c1623c0cfigure the file header names) minus 3,298,620 is exactly 707,291, which is what pins the provenance. Against today's recordedBASELINE.gzipBytesof 3,254,004 the2c8474c04reading is 44,616 ABOVE it, not 707,291 below. - The conclusion it draws is the reverse of the gate's live verdict. The paragraph tells its reader the aggregate ceiling sits ~787 KB above the payload and is therefore far wider than the regression it must catch — i.e. blind. The gate itself printed, on
b98352a15:aggregate closure 3180.2 KB measured / 3222.7 KB ceiling (headroom 42.5 KB = 0.48x the 89.0 KB regression). The aggregate half is in range today; the ~787 KB gap the paragraph describes was closed by objectui#5924 and objectui#6683.
Why this is worth a card rather than a shrug
This file's whole design is that its reasoning is CHECKED rather than argued — every ceiling is weighed against the report the run just read, and evaluateHeadroomSensitivity exists precisely so a claim about the gauge cannot go stale in silence. The doc comments are the one part with no such guard, and this is the paragraph a reader reaches at the moment they are deciding how to move a ceiling.
Point 3 is the sharp one. It does not merely age badly — it contradicts a verdict the same script prints in the same run, so an author sizing a re-baseline off it would conclude the aggregate half is decorative at exactly the moment the tool is telling them it is working.
Why PR #6772 did not fix it in passing
Point 1 is a one-token correction, but 2 and 3 are not. Restating the objectui#5490 aggregate-versus-per-chunk relationship correctly means re-deriving what that relationship IS after two intervening re-baselines — a decision about what the paragraph should now claim, not a typo repair. Doing it inside a surgical ceiling-raise would have been unreviewable scope, and guessing at it would reproduce the defect one layer up.
Why objectui#6631 is the parent
objectui#6631 is open on exactly this: the budget's headroom moved and nobody could establish which side moved it. A provenance comment that names a superseded commit and does arithmetic against a superseded figure is one direct cause of that — the constant's own documentation is the first place anyone looks, and here it points two re-baselines into the past.
Generated by Claude Code
Activity
huangyiirene commentedon Aug 29, 2026
定级：
pm:queue·domain:devx·priority:p1。车道：
scripts/check-eager-closure-budget.mjs= objectui 根scripts/⇒ 三流规则里的domain:devx（与父卡 #6631 一致）。p1 是个边界判断，我把判据写出来
同族的 objectstack#13128（门禁 floor 的出处与树脱钩）我判了 p2。本卡看起来同形，但有一处实质差异，我按它判 p1：
⇒ 决定性的是第 3 点：那段话告诉读者 aggregate ceiling 高出 payload ~787 KB、因而是装饰性的；而同一个脚本在同一次运行里打印的是
headroom 42.5 KB = 0.48x the 89.0 KB regression—— 在范围内、正在工作。⇒ 这不是"过期"，是一条会引导人做出错误动作的断言：一个据此 sizing re-baseline 的作者，会在工具正告诉他"这一半有效"的时刻，得出"这一半可以忽略"的结论。惰性的陈旧 vs 指导行动的陈旧 —— 这是我在这两张卡之间画的线。
⛔ 派发围栏
⛔ 不要只修第 1 点。 卡自己已经把难度分开了：
BASELINE实际带的是bd2a7ec50/3_254_004，不是4c1623c0c）是一个 token 的更正；@object-ui/app-shelldeclare asideEffectsfield? Measured at 242.6 KB gzipped — 8x today's console headroom — but it is a published contract whose failure mode is silent #6683）之后重新推导这个关系是什么。⇒ 那是一个判断，不是打字错误修复。⭐ 而且卡自己说明了为什么 PR #6772 没有顺手修：在一次外科式的 ceiling 抬升里做这件事是不可复审的范围，而猜则会把同一个缺陷复制到上一层。⇒ ⛔ 接手人同样不得猜；若重新推导后仍不确定那段该主张什么，停下回填，不要写一段新的、同样无人校验的散文。
⭐ 这张卡对父卡 #6631 是实质推进，不只是子项
#6631 的问题是「headroom 移动了，但没人能确定是哪一侧移动的」。本卡指出：那个常量自己的文档指向两次 re-baseline 之前 —— 而那正是任何人第一个去看的地方。⇒ 本卡不是 #6631 的一个症状，是它的一个直接成因。⚠️ 修 #6631 之前先修本卡，否则下一个调查者会再次从那段假前提出发。
⭐ 最后记一条这张卡自己点破、值得推广的观察：这个文件的整体设计是"推理被校验而非被论证"（每个 ceiling 都对着刚读到的报告称重，
evaluateHeadroomSensitivity的存在就是为了让关于量具的断言不能静默过期）—— 而 doc comment 是唯一没有这层守卫的部分。⇒ 这是本周那一族的又一种形态：守卫覆盖了数字，没覆盖解释数字的散文。Generated by Claude Code
zhuangjianguo commentedon Aug 31, 2026
认领 · PM 派发 R39
domain:devx @ objectuiPM 席位认领本卡并派发。86aefd79-6ef3-5a63-98f9-701da03c59abclaude/issue-6778-per-chunk-baseline-provenancepm:queue→pm:dispatched前提复核（在当前
main=e33b44796上重新推导，⛔ 不继承卡里的行号）scripts/check-eager-closure-budget.mjs存在，66,289 B。main已推进；⛔ 取卡者不得引用卡里的任何行号，必须自己重读。我把分诊席（
huangyiirene，人类）的围栏原样传下，一条不减@object-ui/app-shelldeclare asideEffectsfield? Measured at 242.6 KB gzipped — 8x today's console headroom — but it is a published contract whose failure mode is silent #6683 两次 re-baseline 之后重新推导 aggregate 与 per-chunk 的关系。PM 追加的一条要求
⭐ 本卡的第 3 点是「文档结论与脚本自己在同一次运行里打印的裁决相反」。⇒ 修复必须以脚本的活体输出为准，而不是以任何静态推算为准。 请实际运行该门禁、贴出它这一次打印的 headroom / ceiling / regression 三个数，并让新写的那段话与之逐字对应。⛔ 一段没有被当次运行验证过的新散文，不构成对本卡的修复。
Generated by Claude Code
zhuangjianguo commentedon Aug 31, 2026
os-dev-report
{ "issue": 6778, "branch": "claude/issue-6778-per-chunk-baseline-provenance", "pr_url": "https://github.com/objectstack-ai/objectui/pull/7045", "commit": "aebe091748c17f61884b990fe97df851292a1fde", "status": "ACCEPT_REQUESTED", "files_changed": [ "scripts/check-eager-closure-budget.mjs (comment only: the PER_CHUNK_BASELINE doc block, +68/-12 lines)", ".changeset/6778-per-chunk-baseline-provenance.md (new, empty frontmatter — nothing ships)" ], "gate_output_quoted": "Full package build + console build on e33b44796 (clean tree), then `pnpm check:eager-closure`, exit 0:\n OK Console eager closure is 3149.2 KB gzipped across 48 of 517 chunks (budget: 3191.4 KB, headroom: 42.2 KB).\n OK Ceiling sensitivity (4 ceilings, each weighed against the report just read):\n OK aggregate closure 3149.2 KB measured / 3191.4 KB ceiling (headroom 42.2 KB = 0.47x the 89.0 KB regression) [MAX_EAGER_CLOSURE_GZIP_BYTES]\n OK chunk `vendor-objectstack` 925.7 KB measured / 944.3 KB ceiling (headroom 18.6 KB = 0.21x the 89.0 KB regression)\n OK chunk `framework` 492.9 KB measured / 500.0 KB ceiling (headroom 7.1 KB = 0.08x the 89.0 KB regression)\n OK chunk `ui-components` 386.2 KB measured / 389.6 KB ceiling (headroom 3.4 KB = 0.04x the 89.0 KB regression)\nExact bytes from the same report: eagerGzipBytes 3,224,774 vs 3,268,000 ceiling = 43,226 B headroom = 0.4743x the 91,136 B regression. Every digit in the new prose comes from this run. Re-run after the edit: verdict byte-identical (diffed).", "ablation_evidence": "No test was added or changed, so no ablation was owed and none is claimed. What IS proved is that the edit landed on disk, in both directions, before any measurement: deleted anchors 'DIFFERENT and LATER' / '707,291 BELOW' / 'now sits ~787 KB' / 'still carries 4c1623c0c' each grep -c = 0; injected anchors 'WHICH ONE IS LATER' / 'e33b44796' / '3149.2 KB' each = 1; blob hash 314b15e0d34cd669c1963e1cfee36a8a9ce9ed1c -> d3ccb096c732262daf3129d2cb0ee40732f43767. Control on the surviving historical citations: the two past-tense mentions of 4c1623c0c at lines 121 and 239 still hit, so the greps were not scanning a dead file. Every zero-hit in this run carried a control that hit: git cat-file on 4c1623c0c/bd2a7ec50/a64e96ca8 returns 'Not a valid object name' with deadbeef123 as the negative control and 2c8474c04/3d257c85a/e33b44796 as positive controls; the control-byte grep was proved live against a planted BEL byte.", "what_you_established": "All three card points confirmed, and the card's own point 1 was itself one re-baseline stale. (1) BASELINE carries 3d257c85a / 3_222_314, not 4c1623c0c and not the bd2a7ec50 / 3_254_004 the card names — objectui#6776 re-baselined again on 2026-08-31 (350509b53). (2) The 707,291 figure is exactly 4,005,911 - 3,298,620, arithmetic against the retired reading; removed from the present-tense paragraph, while the two genuinely-historical citations of 4c1623c0c elsewhere in the file are left alone as correct past-tense narrative. (3) The conclusion is reversed, live: the aggregate sits at 0.47x, and evaluateHeadroomSensitivity errors 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. THE RE-DERIVED RELATIONSHIP: not 'the aggregate is decorative' — all four ceilings are inside one regression; what survives is the narrower true claim that the per-chunk ceilings are the TIGHTER half (0.21x / 0.08x / 0.04x vs the aggregate's 0.47x) and that they say WHERE, which one total never can. Two further defects found that the card did not name: (a) the paragraph's opening direction is now INVERTED — BASELINE's 3d257c85a (2026-08-30) is LATER than the per-chunk readings 2c8474c04 (2026-08-25) and a64e96ca8 (objectui#6759, landed 2026-08-29) — so rather than swap LATER for EARLIER, which goes stale on the next re-baseline in either direction, the comment now states the direction as unstable by construction and tells the reader to read the commit names; (b) '~787 KB' was a units slip — 4,086,000 - 3,298,620 = 787,380 BYTES, i.e. ~769 KB; the magnitude of the point (8.64x, blind) was right, the unit was not.", "what_you_could_not_establish": "a64e96ca8 is not an object in this repository at all (squash-merge kept the landing commit 4f3a1e2b4 and dropped the PR branch), so its own commit DATE cannot be read. The comment therefore does not assert one: it says the reading was recorded by objectui#6759, which landed 2026-08-29 — a date read from 4f3a1e2b4, not inferred for the missing commit. An earlier draft did state '(2026-08-29)' for a64e96ca8 directly; that was an inference and was removed before commit. Same class, recorded in the comment because it bears on the parent card: 3d257c85a still resolves as an object but is NOT an ancestor of main (it landed as 350509b53), and 4c1623c0c and bd2a7ec50 are gone entirely. Part of why objectui#6631 could not establish which side moved is that most of the hashes this file cites cannot be resolved against main.", "open_questions": [ "Structural, recorded per the PM's instruction and deliberately NOT implemented here — this file's guards cover the numbers and not the prose that explains them, which is how one paragraph went three re-baselines stale in silence while evaluateHeadroomSensitivity could not. A cheap mechanical backstop exists: VERDICT_CEILING_CONSTANTS already deliberately excludes BASELINE and PER_CHUNK_BASELINE, so a unit test could assert that the commit string in each baseline appears in the doc block that cites it, and/or that the doc block carries no OTHER 9-hex-digit token — turning 'the prose names a retired commit' from an unguarded claim into a red test. Worth its own card; I did not file it, since it is one keyword away from the parent objectui#6631 and PM may prefer it as a sub-issue there.", "Not acted on, flagged only: the aggregate measured on e33b44796 is 3,224,774 against BASELINE.gzipBytes 3,222,314 — 2,460 bytes of drift since 3d257c85a, and ui-components has drifted +4,424 bytes above its PER_CHUNK_BASELINE, leaving it 3,481 bytes (0.04x) under its ceiling. Still green, but ui-components is the thinnest margin of the four and will be the next ceiling to come due. No card filed; this is a reading, not a defect." ] }Generated by Claude Code