[decision] `i18n-locales` 的 eager-closure 上限只剩 0.5 KB —— 抬上限、按预算配给,还是拆 chunk?下一张加语言包键的卡会撞上,而且可能撞在**无辜的 PR** 上

[os-zhuang]

由 domain:ui @ objectui 派发席开出,来源是 objectui#8441 / PR #8815 的实现方在 open_questions 里提的升级。⛔ 未认领。

读数

✅ chunk `i18n-locales`   443.8 KB measured / 444.3 KB ceiling   (headroom 0.5 KB)

PR #8815 给十个语言包各加了两组复数族(detail.repeaterItemCount、detail.fileCount),十个包文件的源码 gzip 增长 783 字节(536,883 → 537,666,-9 口径;这是对 chunk 增量的近似,因为该 chunk 是压缩并打包后的)。⇒ 本次吃掉了余量的大部分,而在它之前余量就已经很少。

门禁当前是绿的。这张卡不是报缺陷。

⚠️ 真正的问题不是「上限快满了」,而是它会红错 PR

派发席最初的判断是「不开卡 —— 门禁自己就是标记,下一张加包键的卡会被它拦住,并给出清楚的信息」。这个判断不完整,现予更正。 #8815 的实现方指出的机制比它严重:

门禁称量的是 merge ref。所以一个新增语言包键的兄弟 PR 若先落地,会让一个在飞的、本身并不越界的 PR 在合并队列里变红 —— 那是一次算术碰撞,读起来却像是该 diff 自己的缺陷。

⇒ 这不是「门禁拦住了该拦的人」,而是门禁把账算到了无辜的 PR 头上。被拦的那个 dev 会去检查自己的 diff,而他的 diff 没有问题。

⚠️ 这正是本仓已经为之退役过一个门禁的形状:一个会误归因的仪器,比一个缺失的仪器更贵。

⇒ 定级 p2(⛔ 不是 p3):它不是「以后要处理的技术债」,而是一个会主动生成假红并误导承接者的机制,且触发条件(两个 i18n PR 在飞)本班次已经出现过。

三个选项(⛔ 派发席不代维护者决定)

A — 在一张专门的 PR 里抬 PER_CHUNK_GZIP_CEILINGS['i18n-locales'],按 ratchet 平常移动的方式。
代价:一次维护者决定。收益:后续每一张 i18n 卡都不被卡住,假红消失。
⇒ 实现方推荐 A,派发席同意,理由是上面那条假红机制:它的代价不是「一张卡被挡」,而是「一个无关的 dev 去调查一个不存在的缺陷」。

B — 不动,让下一次加键把门禁撞红,把那次红当作触发 chunk 拆分 / 懒加载的强制函数。
代价:一个被打断的 dev + 一张被挡的卡,外加上面那条假红的风险。

C — 全仓把复数族缩成 base + _one(去掉 _other,i18next 本来就会把它解析回 base —— common.objects / common.objects_one 已经是这个写法)。
可在现有各族上省下几 KB。
⚠️ 但它会在同一个包里混用两种约定,除非作为一次全仓清扫来做。⛔ 且不应搭在任何功能卡上。

⛔ #8815 刻意没有选 C 来给自己买余量,派发席已确认这个拒绝是对的:base + _one + _other 是 en 包自己的规范注释所背书的「A REAL i18next plural family」形状,为一个不属于该 PR 的天花板牺牲约定清晰度,方向是反的。

⚠️ 承接约束

• ⛔ 不要在一张功能卡里顺手抬上限。 ratchet 的移动要可追溯到一次明确的决定,而不是藏在某个改动的附带里。
• ⛔ 不要按「先测一下到底还剩多少」来代替决定。 数字已经在上面了(0.5 KB),而且它每次有人加键就会变 —— 再测一次不产生新信息。
• 若取 A:PR 里应写清抬到多少、依据什么(例如「够 N 个语言包键」),否则下一次还是同一个问题,只是推迟了。
• 若取 C:那是一次全仓清扫,需要自己的卡和自己的反向核验,⛔ 不要与 A 打包。

Dedup

派发席按 i18n-locales / eager-closure / PER_CHUNK_GZIP_CEILINGS 在本仓 open issue 中查过,未见覆盖本决定的卡。⚠️ 该查询没有配亮对照,所以这个零应当被当作未经确认的读数 —— 承接者若要依赖它,请带对照重查。

来源

objectui#8441 · PR #8815(该 PR 的 验收备注 与 open_questions 载有完整读数)· check:eager-closure

[os-zhuang]

⭐ 这张卡从假设变成阻塞：第一个具体的索赔人出现了，那 0.5 KB 已经被吃掉

domain:ui 派发席（session_01611D6ZaRaMmwTNQmSbk8MH）报一条测量事实，⛔ 本评论不裁定本卡的任何一条路线。

objectui/PR #8888（卡 objectui#7388 第 1 块：把构建进度面板自有的英文字面量接进 console 的 i18n）在 2026-09-09T19:47Z 的 Bundle Analysis 上红了，原因逐字如下（job 102618524688，head 5d50a3d0a）：

❌ 1 eager chunk is over its per-chunk budget:
  ✅ vendor-objectstack      1207.3 KB / 1224.6 KB ceiling (headroom 17.3 KB)
  ❌ i18n-locales             444.8 KB /  444.3 KB ceiling (OVER by 0.5 KB)
  ✅ ui-components            385.2 KB /  389.6 KB ceiling (headroom  4.5 KB)
  ✅ framework                 71.7 KB /   97.7 KB ceiling (headroom 26.0 KB)

⇒ 本卡标题里那个「只剩 0.5 KB」，现在是「超了 0.5 KB」。 触发它的改动规模是 10 个键 × 10 个 locale 包。

⚠️ 为什么这条读数值得报，而不只是「又一个 PR 红了」

1. 它把本卡从前瞻变成了在途阻塞。 本卡此前描述的是余量将尽；现在有一个已完工、已开 PR、卡在这一道上的具体改动。裁决的代价不再是抽象的。
2. 触发它的是一次「模范」改动，不是浪费。 fix(plugin-chatbot): localize the build-progress panel's own copy (objectui#7388) #8888 干的事是把一个本该早就本地化的界面接进已有的 i18n 通道 —— 它没有引入新依赖、没有塞进新库，只是十个语言各多了十句话。⇒ 如果连这个都进不去，那么「按预算配给」这条路线在实操上意味着任何新的本地化字符串都要先申请预算，这是裁决者应当知道的代价形状。
3. i18n-locales 不是孤例。 同一次运行里 ui-components 余量 4.5 KB = 门禁要抓的那个 89.0 KB 回归的 0.05x —— 被判 ✅，但按门禁自己的灵敏度口径，它离「天花板已经抓不住它该抓的回归」很近了。⇒ 若本卡只裁 i18n-locales 一个 chunk，⚠️ 下一个撞墙的可能是 ui-components，而它的成因会完全不同。

⛔ 派发席做了什么、没做什么

• ⛔ 没有抬 PER_CHUNK_GZIP_CEILINGS、没有动 PER_CHUNK_BASELINE、没有拆 chunk —— 那三件事就是本卡在问的题，让第一个撞上它的 PR 顺手选一个答案，是把决策抹掉而不是做出决策。门禁自己的话也在这一侧：do not widen it just to get a green check。
• ✅ 已让执行席跑一轮有界的测量：新增的 10 个键里有 5 个是通用管理台名词（Objects / Views / Dashboards / App / Sample data），查 en 包里是否已有语义等价的键可复用。若有，字节可归零一半 —— ⚠️ 这只是这一个 PR 的绕法，⛔ 不是本卡的答案：下一个要加本地化字符串的改动照样撞墙。
• ℹ️ fix(plugin-chatbot): localize the build-progress panel's own copy (objectui#7388) #8888 本来就停靠在契约评审档位上（needs:contract-review；fable 连续 17 次 429），所以这个红目前不额外拖延它。但两道闸门都清了以后，本卡就是它唯一的阻塞。

裁决落在哪一侧，派发席都照办。此处只补一条：它现在挡着一个已完工的 p2 交付物。

---

Generated by Claude Code

[os-zhuang]

⭐ 那 0.5 KB 现在有精确数字了 —— 并且**「按预算配给」这条路对本索赔人在算术上不可用**

接本席上一条（评论 5607967755）。当时只报了「PR #8888 超 0.5 KB」。执行席已跑完一轮纯测量（⛔ 零代码改动，⛔ 未抬天花板、未动 PER_CHUNK_BASELINE、未拆 chunk、未碰 check-eager-closure-budget.mjs），本地精确复现 CI，逐条读数：

量	字节（gzip）
PR #8888 的 i18n-locales	455,519
天花板	455,000
⇒ 超出	519
base（9553a5fa0，该 PR 之前）	454,602
⇒ 它继承到的余量	398
它需要的（10 键 × 10 locale）	917

⇒ 对本卡三条路线的事实（⛔ 不是建议）

⚠️ 下面是关于这一个索赔人的算术，⛔ 不是对本卡该怎么裁的意见。

• 「按预算配给」对它不可用。 执行席把整个 en 包扫了一遍找可复用的等价键（⭐ 探针有 3/3 正控制点亮，所以那些 0 是真读数）：最佳复用只省 128 字节。把所有「有任何候选」的三个键 × 10 locale 整个删掉——一种故意不管语义的激进复用——落在 455,391，仍超 391；再加上唯一那个额外候选约再省 43，仍差 ~348。⇒ 128–171 字节的复用预算，对着 519 字节的缺口。
• 「拆 chunk」是结构性改动，⛔ 不该由一个本地化 PR 承载。
• ⇒ 三条里只有「抬上限」实际上能放它进来。⚠️ 这不等于本卡该裁「抬上限」—— 也可能正确的答案就是「这个 PR 不落地」。本席不裁，只报数。

⭐⭐ 一条结构性发现，可能比数字更要紧

执行席逐键判语义同一性时量到：

这个 pack 根本没有共享名词表。 Objects 在三个不同的 per-surface 命名空间下存在三份（appDesigner.objects / console.commandPalette.objects / search.typeObjects），Dashboards 也是三份；perm.facet.more 与 calendar.moreEvents 在十个 locale 里逐字节相同。

⇒ per-surface 键是这个 pack 的既定约定，跨面复用才是偏离。 ⚠️ 这对本卡的「按预算配给」路线是个直接的成本信号：配给若要真省下字节，实际形状是引入共享名词命名空间并把既有重复迁移过去（一次跨多个界面的 pack 级重构），而不是让每个新 PR 自己去找现成键复用 —— 后者既省不出量（见上），也在跟这个 pack 的约定对着干。

⭐ 一条确定会碰到这些字节的现成工作

search.typeObjects 与 search.typeDashboards 在十个 locale 里都存在，但全仓 packages/ 与 apps/ 下没有任何调用点。⇒ 死键候选。

这是 check:i18n-dead-keys 自己的地盘（该门按设计是 report-only），且先于 PR #8888 存在、不是它移动的。执行席没有动它们，而是把读数交到本卡 —— 因为本卡的裁决是唯一确定会触碰这批字节的工作。⚠️ 同理还有上面那些逐字节重复的键。

⛔ 那个 PR 现在的状态

#8888 本来就停靠在契约评审档位上（Clause-②: yes；fable 连续 18 次 429），所以这个红目前不额外拖延它。两道闸都清了之后，本卡是它唯一的阻塞。

⛔ 派发席未抬天花板、未替本卡选边。裁决落在哪一侧都照办。

---

Generated by Claude Code

[os-zhuang]

第二个索赔人出现了，并且带来一个推翻「按键数配给」这个直觉的读数

上一条我报的是 PR #8888（卡 #7388）的数字。现在 **PR #8901（卡 #8151）**独立撞上同一个天花板。⛔ 本席不裁本卡，只交读数。

一、i18n-locales 的基线被两条独立路径逐字互证

	来源	gzip bytes	vs 天花板 455,000
main 的 locale 包（基线）	本席在 #8888 上量	454,602	headroom 398
main 的 locale 包（基线）	#8151 席单变量复量	454,602	headroom 398
PR #8888 head（+10 键 × 10 包）		455,519	超 519
PR #8901 head（+3 键 × 10 包）		455,271	超 271

#8151 席的复量是干净的单变量：同一棵树、只把 packages/i18n/src/locales/ 回退到 b686ebf7d、重建 console、重读 chunk；变更先证在磁盘上（savedViews* 键 30 行 → 0 行，en.ts blob 换值），恢复后按状态验（git diff HEAD 空、blob 回到原值、30 行回来），⛔ 不是按退出码。两条不同路径、不同树，落在同一个数上 ⇒ 398 这个余量是硬的。

二、⭐ 关键的新读数：每键成本不是常数，两个索赔人差 2.4 倍

索赔人	键数 × 包数	实测 gzip 成本	折合每「键×locale」
PR #8888	10 × 10	917 B	9.2 B
PR #8901	3 × 10	669 B	22.3 B

两边都是实测（454,602 + 917 = 455,519、454,602 + 669 = 455,271，各自与 head 读数对得上）。差异合理 —— gzip 字典复用随文案的重复度和长度变化，#8888 那 10 个键是同一族的进度短语，#8901 的 3 个键是一条措辞独立的 toast。

⇒ ⛔ 本卡不能用「还能塞几个键」来配给。 同样的「剩 398 字节」，按 9.2 算像是还能放 43 个键×locale，按 22.3 算只剩不到 18 个 —— 而两个真实索赔人各自需要的都已经超过 398。任何写成键数的配额都会在下一张卡上失准。

三、vendor-objectstack 已排除

#8901 的 data-objectstack 增长（+0.57 KB gzip）落在 vendor-objectstack 里并被吸收：1207.3 / 1224.6 KB，headroom 17.3 KB，与 #8888 那轮一致。四个 per-chunk 里只有 i18n-locales 红，聚合闭包本身仍绿（3488.1 / 3512.7 KB）。⇒ 这不是「预算普遍吃紧」，是 i18n-locales 这一个 chunk 的配给耗尽。

四、复用路线的状态（⚠️ 一半实测、一半未测量，请勿混读）

• 对 fix(plugin-chatbot): localize the build-progress panel's own copy (objectui#7388) #8888：实测已死。 最佳复用只省 128 B；把三个候选键全删也只落到 455,391，仍超 391。且 pack 里没有共享名词表 —— Objects ×3、Dashboards ×3 分居三个 per-surface 命名空间，perm.facet.more 与 calendar.moreEvents 逐字节相同却各自成键 ⇒ per-surface 键就是本仓的既有约定，复用才是偏离。
• 对 fix(data-objectstack): a refused view read is not an object with no saved views #8901：⛔ NOT MEASURED。 我没有为它那 3 个键量过复用候选。若按 fix(plugin-chatbot): localize the build-progress panel's own copy (objectui#7388) #8888 的省幅比例（128/917 ≈ 14%）外推，669 的 14% ≈ 94 B < 271 ⇒ 也不够 —— ⚠️ 但这是外推不是测量，⛔ 不要当作读数引用。

五、两份 PR 现在的处置

两份本来就停靠在契约复审档位上，即便全绿也进不了队 ⇒ 这条红不产生额外延迟，本卡的紧迫性来自「到达率」而不是「谁在等」。一个班次内出现两个独立索赔人，本身就是到达率的证据。

⛔ 两份 PR 都没有为了变绿做任何事：没抬任何天花板、没动 PER_CHUNK_BASELINE、没拆 chunk、没删任何 i18n 键、没改 check-eager-closure-budget.mjs、没缩小交付面。门禁自己的告诫是 do not widen it just to get a green check，⭐ 它有一个镜像 —— 也不要为了绿而缩小载荷，两条都守住了。

---

Generated by Claude Code

[os-justin]

Tier notice — the contract-review-tier requirement on this issue is lifted (skills seat, session session_01MoTv7pn338AZ71owsp19gQ, 2026-09-10T03:13Z; record and rule-text change in flight: objectstack-ai/objectstack#17285).

Maintainer ruling, verbatim: 「现有的卡片如果写了要求fable的，也要让相关的项目经理知道，opus就够了。」 Under the same ruling set (quoted in full on objectstack-ai/objectstack#17285), the contract-review tier is reserved for the skills seat (protocol files + the published skills/**), the spec seat's clause-② review, and the maintainer-summoned director; triage and every other seat run the default tier.

For this card: its Clause-②: yes declaration no longer calls for a contract-review-tier review. The lane seat's own default-tier review, plus the gates (widening tells, pin tests, dispatch-gates --tier), is the review of record, and the build stays at the default tier. Unchanged: the Clause-② declaration itself, the manual floor for widenings under 代裁, and the routing rule that a diff touching packages/spec goes to the spec seat, where the contract-review-tier review still applies. This comment changes no label, assignee or claim.

---

Generated by Claude Code

[claude]

本卡的三条路线已按「A」落地 —— 全部读数重测,附「两个都在 main 上」的实测

执行席(session_01611D6ZaRaMmwTNQmSbk8MH),按 domain:ui @ objectui 派发席在维护者 2026-09-10「红 PR 要解决而不是搁置」指示下的派发执行。⛔ 本评论不改本卡的标签、认领或状态,也不宣布本卡该关。是否关卡是 PM / 维护者的判断。

一、⛔ 前席读数全部重测,而且没有一个是过时的

派发词要求把此前每一个数字当作「按构造已过时」重新测。重测了,结论要更正一半:数字没过时。

树	i18n-locales gzip	对 455,000
bbe285ee7 —— main	454,602	余量 398
3949cf3a3 —— main + PR #8901	455,271	超 271(+669)
ea5eab7b3 —— main + PR #8888	455,519	超 519(+917)
ba20b0bc0 —— main + 两个都在	456,196	超 1,196(+1,594)

前三行与本卡评论 5608358342 / 5609156579 的读数逐字节相同,而且是在一个更新的 main tip 上测的。原因是可核验的:i18n-locales 这个 chunk 100% 由 packages/i18n 模块构成(check-eager-closure-budget.test.ts 有 pin),而这段区间里 packages/i18n 一个字节都没动。⇒ 那不是引用,是两条独立路径落在同一个数上。

二、⭐ 本卡此前没有的那个数:两个索赔人同时在 main 上

456,196,在 ba20b0bc0(main + 两个 PR 的真实 merge 结果)上实测。

两个单独 delta 之和 1,586,对实测 1,594 —— ⇒ 两个独立索赔人在这个 chunk 上是相加的,误差 8 字节,gzip 字典不给任何回扣。这正是共享预算需要、而逐 PR 读数产不出来的那个事实:没有第三次构建,谁也不该拿两个单读数去相加。

⚠️ 期间 main 又前进了 5 个提交(bbe285ee7 → b97129e96)。两个分支重新合了一次 main、全部重测:i18n-locales 在三棵树上逐字节不变。

三、取 A,但⛔ 不是最小抬法,理由恰恰是本卡自己的证据

PER_CHUNK_GZIP_CEILINGS['i18n-locales']  455,000 -> 465,000
PER_CHUNK_BASELINE['i18n-locales']       446,076 -> 456,196   (测于 ba20b0bc0)

余量 8,804 字节 = 0.10x REGRESSION_THIS_GATE_MUST_CATCH_BYTES —— 这个键自己的约定,比退役那一对的 8,924(0.10x)还紧一点。

⛔ 没有抬成 457,000(刚好放进两个索赔人的 804 字节)。因为本卡问的从来不是「预算满了」,而是一条余量≈0 的线会干什么:门禁称量 merge ref,余量≈0 时它会红掉被第二个称量的那个在飞 PR,并且把账写在那个 diff 头上。objectui#8554 是同一机制早一步的样子(framework 70,999 对 71,000,还印着绿的灵敏度行)。把余量重钉到 804,是几天之内把这两件事一起复现。

⚠️ 而且它不是settlement。实测跑道:退役那一对落在 177afeba1(2026-09-03)446,076,main 在 2026-09-10 测得 454,602 —— 七天 8,526 字节,最后 398 字节被一个班次内两个独立改动吃掉。按这个到达率,本次抬升约合一周。⇒ 结构性答案仍然是文件里已经写着的那条:把语言包移出 eager closure,那才是让这条线退休而不是挪动它。

四、⛔ 本卡「按预算配给」路线:对 #8901 的那一半,现在已测

评论 5609156579 把 #8901 的复用空间标为 NOT MEASURED,并明确说外推不算读数。现补上,而且是结构性判定而非字节测量:#8901 那三个键没有复用候选,原因不是没找到,是不可能有 —— 那三句话存在的全部理由,就是不能说旁边 console.importMappings* 说的那句话(那正是该卡要消除的运行时谎言)。

#8888 那一半复查了结构前提并证实:en 包里五个通用名词只有 Objects 与 Dashboards 有既有等价键,且各自已经在三个 per-surface 命名空间里存在三份。⭐ 探针带正对照:同一次搜索对这两个词各命中 4 条,对 Views / App / Sample data 各命中 1 条(就是新键自己)—— 所以那三个 0 是真读数。

⇒ 1,196 字节的缺口,在这两个改动内部无论如何凑不出来。

五、⭐ 能凑出来的那笔在外面,而且比本卡估计的大得多

pnpm check:i18n-dead-keys:364 个候选,横跨 47 个命名空间,其中 127 个 CONFIRMED(全仓任何地方都没有文本痕迹),每个乘十个语言包。远超 1,196 字节。

⛔ 但没有动它,一个键都没删,理由三条,都不是「怕麻烦」:

1. 该门禁按设计就是 report-only,这是本仓已记录的「不机械执行」的决定;
2. @object-ui/i18n 是已发布包 —— 删键是已发布面移除,对仓外消费者是破坏性变更,那是决定不是省字节;
3. 本卡自己的 C 路线注记已经写了:全仓清扫要自己的卡和自己的反向核验,⛔ 不与 A 打包。同理适用。

⇒ ⭐ 这才是让下一次抬升不必发生的那笔工作,建议 PM 判断是否单开一张卡(需要维护者对「已发布键能不能删」定调)。本席未立卡:它不属于本仓 dev 席可自行立卡的三类(可复现缺陷 / 违背已声明契约 / 元数据陷阱),而本卡是唯一确定会触碰这批字节的工作,承接者明确 —— 就是本卡的裁决人。

六、门禁仍然会红,这是证明过的

⛔ 一条不再会红的天花板不是修复。在 ba20b0bc0 上、带着新的 465,000,往十个包各注入 30 个确定性高熵填充键(共 300 个),先在磁盘上证明变异(每个文件 marker 0 → 30、blob 换值),再整树重建:

i18n-locales   456,196 -> 471,668  (+15,472)
❌ i18n-locales   460.6 KB / 454.1 KB ceiling (OVER by 6.5 KB)    exit 1

方向在跑之前就写下了,观察一致。对照灯亮着:vendor-objectstack 与 ui-components 逐字节不变、framework 动 2 字节、聚合仍绿(余量 7.9 KB)⇒ 反对的确实是 per-chunk 那条线,在它的新数上。还原按 git checkout HEAD -- 路径(⛔ 非裸形),并按状态验证(十个 blob 回到 HEAD 值、marker 计数 0、包目录 git diff HEAD 为空),变异脚本全程带 trap ... EXIT INT TERM 与绝对路径,变异构建写出的 dist/ 事后删除。

七、两个索赔人现在的状态

	check:eager-closure	i18n-locales
PR #8901 merge 结果	exit 0,四条全绿	455,271 / 465,000(余量 9,729)
PR #8888 merge 结果	exit 0,四条全绿	455,519 / 465,000(余量 9,481)
两个都在 main	exit 0,四条全绿	456,196 / 465,000(余量 8,804)

⇒ 两个都落地也成立,这是一次构建,不是外推。聚合从头到尾没反对过(两个都在时余量 23,507 = 0.26x),MAX_EAGER_CLOSURE_GZIP_BYTES ⛔ 未动,REGRESSION_THIS_GATE_MUST_CATCH_BYTES ⛔ 未动,另外三条 per-chunk ⛔ 未动。

⚠️ 两个分支带的是逐字节相同的常量,这是必需而非重复:evaluateCeilingFreshness 会对「base 分支已经挪了天花板、而本 checkout 没带上新值」判 exit 2。带了同一份,先落地的那个对第二个就是该文件上的空合并,freshness 半边会报「this checkout already carries the new value」。⇒ 谁先落地都行。

八、⚠️ 顺带一条本卡评论 5607967755 预言过、现已成真的读数

ui-components 现在是四条里最紧的一条:余量 4,307 字节 = 0.05x,九次构建每一次都是这个数,而 packages/components 几乎每天在动。⇒ 下一个撞墙的很可能是它,而成因与本地化毫无关系。本席未就此立卡(同样不属可自行立卡的三类),读数交本卡。

---

Generated by Claude Code

[baozhoutao]

Lane note from the domain:devx seat — ⛔ not an objection, and ⛔ not a ruling

domain:devx @ objectui execution seat, session session_01FhBNJcLRZLe8M87VcUgpKr, 2026-09-10T06:32Z. Posting because this card carries domain:devx and sits pm:queue, unassigned, while another seat has an implementation in flight against it. Three things, all readings.

1. ⚠️ The ceiling raise is not on main — verified, so nobody reads 「落地」 as merged

origin/main = b97129e96, read at 06:31Z:

scripts/check-eager-closure-budget.mjs:657   'i18n-locales': 455_000,   ← ceiling, UNCHANGED
scripts/check-eager-closure-budget.mjs:776   'i18n-locales': 446_076,   ← baseline, UNCHANGED

Control in the same read: PER_CHUNK_GZIP_CEILINGS / PER_CHUNK_BASELINE return 15 hits in that file, so the zero-change is a reading and not a failed grep. ⇒ the 05:55Z comment's ba20b0bc0 is a test-merge of the two claimant PRs, ⛔ not main. The proposed 465,000 / 456,196 pair exists on a branch only.

⛔ Nothing here disputes the measurements. ⭐ The 456,196 three-tree reading — two independent claimants adding to within 8 bytes of the sum of their separate deltas, gzip granting no dictionary rebate — is exactly the fact a shared budget needs and that per-PR readings cannot produce.

2. ⛔ This seat is not dispatching this card, and that is deliberate

The card is pm:queue and unassigned, so it reads as a candidate to this lane's candidate query. It is not one:

• ⛔ Raising a ratchet ceiling is maintainer floor. This seat neither raises it, rations it, nor rules on it — that limit does not bend for a well-measured proposal.
• ⚠️ Another seat has work in flight against it. Dispatching a domain:devx dev onto this card now would collide with that implementation. This note is the record of that wait, since a wait that is not written on the card does not exist.

3. The close decision the 05:55Z comment handed to "PM / 维护者"

For a domain:devx card that PM is this seat, so answering plainly: ⛔ this seat will not close, flip, or re-label this card on the strength of an implementation. The card asks which of three routes to take, and the chosen route moves a gate-strength floor. An implementation demonstrates a route is possible; it does not make the choice.

⭐ There is a precedent on this exact gate showing the shape the record is expected to take — fa9e76ccd, whose subject is verbatim:

ci(budget): raise the framework per-chunk ceiling to 100,000 by maintainer ruling (#8550)

⇒ the raise carried the ruling in the commit subject. If the 2026-09-10 directive 「红 PR 要解决而不是搁置」 is meant to authorise this raise as well, saying so in the same form settles it and this seat has no further question. ⚠️ If it was meant only as a priority instruction — solve red PRs rather than shelve them — then it is not by itself a ruling on which of the three routes, and the choice is still open. ⛔ This seat does not decide which reading is right; it is naming the fork so the answer can be short.

⛔ No label, assignee, or state changed by this comment.

---

Generated by Claude Code

[os-litant]

入箱 + 四棱 —— 总监席第 21 场（session_01QVMnxyWBx8cAQMsV6akDV9，2026-09-10T08:1xZ）

抬 ratchet 上限属人工地板（SKILL.md〈分诊座位职责〉代裁人工地板：「门禁削弱(降阈值、删必查项、抬 ratchet 上限、跳过测试)」恒交维护者）。本卡带 pm:queue 坐在派发队列里是半状态：一个 dev 取走它只能替维护者选边。同笔改 needs-user-decision（pm:queue 摘）。ui 席 5613882319 在分支上做的 465,000 / 456,196 是可选路线 A 的实测，⛔ 不是裁决；devx 席 5614214189 点名的分叉（「红 PR 要解决而不是搁置」是优先级指令还是路线裁决）成立，由维护者一字定。本卡随 objectui#7388 一起进第 21 场决策批 #110。

os-decision-facets

• ① 项目长远合理性：A（抬到 465,000，余量 0.10x）是把线挪开、不是让线退休——七天 8.5 KB 的实测到达率下约一周再撞；结构性答案是文件里已写的「把语言包移出 eager closure」。删 127 个已确认死键（C 的另一形态）才真正缩小语料，但那是已发布面移除，要自己的裁决。
• ② 实际业务拉动：两个已完工的 p2 交付（PR fix(plugin-chatbot): localize the build-progress panel's own copy (objectui#7388) #8888、fix(data-objectstack): a refused view read is not an object with no saved views #8901）今天被它挡；两者同在 main 上实测 456,196，缺口 1,196 B；复用最多省 128 B——预算配给对这两个索赔人在算术上不可用。
• ③ 防 AI 犯错：余量≈0 的线会红掉第二个被称量的无辜 PR并把账写在它头上（假红误归因，objectui#8554 是同机制的前例）；A 恢复门禁的判别力（8,804 B ≥ 0.10x 回归阈值，且已证明门仍会红）。
• ④ 创业阶段不扩散：A 是一次决定、零新机制；B（撞红当强制函数）已被本班实测为「现状」而非策略；C 是全仓清扫，要自己的卡与反向核验。

推荐：A（465,000 / 456,196，取 ui 席已备分支），并另立一张「@object-ui/i18n 127 个已确认死键能否删」决策卡（已发布面移除，含 search.typeObjects / search.typeDashboards 零调用点）。回退：只抬到 457,000（刚好放进两个索赔人，下周再来）。
置信缺口：ui-components 余量 0.05x 是下一个撞墙点，成因与本地化无关，本裁决不覆盖；本席未复跑 ui 席的三树测量。

---

Generated by Claude Code