[Decision] 你要的 17.1 升级把 console 首屏推高 126.7 KiB,超过今天刚裁定「不动」的天花板 41.7 KB —— 抬线、先减重,还是限期豁免?

[os-support-ai]

升级本身已经做完了(PR #5529,除这一项外全绿)。卡住的不是代码,是一条只有你能做的门禁强度决定。

一句话问题

你今天要求的 @objectstack/spec 17.1 升级,会让每个打开 console 的用户首屏多下载 126.7 KiB(gzip 后),而这恰好撞破了你今天早些时候刚裁定「保持不动」的那条总量天花板 —— 超出 41.7 KB。先接受这笔体重,还是先减重再升级?

为什么这张卡必须给你

这是门禁强度变更(抬阈值),按规矩是人工地板 —— 而且 #5490 记录你今天的裁定时用的原话就是:「Gate-strength policy is the maintainer's. ⛔ No seat should pick this.」 dev 测出红灯后没有抬阈值、没有绕过、如实报告,这是对的做法。

还有一层:抬阈值是「把 CI 弄绿」最省事、最不显眼的一招。第一次撞线就抬,等于教会整个舰队「撞线就抬」。

选项 × 真实代价

	做什么	用户实际感受到的代价
A	把天花板抬到新实测值,永久	每次打开 console 多下 126.7 KiB(实测)。今天立的「天花板不动」当天被推翻,而且要顺手改掉那条守护它的断言 —— 天花板以后不再是承诺
B	先做拆分(#5325 / #5359),再落 17.1	用户不增重,可能还减重。代价:17.1 和它已解锁的 5 张卡(#5074 #5042 #4935 #5057 #5126)全部再等一轮重构 —— 工期未估,拆分本身有回归风险
C	17.1 现在落地,但走具名、带到期条件的一次性豁免,天花板数字不动,拆分卡提优先级	用户代价与 A 完全相同(126.7 KiB 现在就付)。差别全在治理:天花板对后续每个 PR 仍是原线,这次放宽有名字、有期限、可审计

业务上 =

• A = 「体重上限跟着实际体重走」。像健身房把体重秤的上限调到你现在的体重 —— 秤永远不会再报警。
• B = 「先减肥再吃这顿」。健康,但这顿饭要等,而且减肥要花时间。
• C = 「这顿记账,下个月必须减回来」。账单可见、有人负责,秤还是原来那台。

四轴论证(业务立场)

① 实际业务拉动 —— 两边都是真需求,不是投机能力面。17.1 是你今天点名要的,而且它已经实测解锁 5 张卡;但「首屏多 126.7 KiB」落在每一个终端用户身上,不是内部效率问题。这条轴不偏向任何一方,它只说明:这不是「小事按默认办」的场景。

② 项目长远合理性 —— 天花板存在的唯一意义就是拦住这种增长。今天刚裁「不动」,当天为第一个撞上它的变更抬高,那这条线以后就只是个会自动让路的数字。A 的长期代价不是 126 KiB,是这条承诺的可信度。

③ 防 AI 犯错(这条最重) —— 出错时谁看到什么:如果抬阈值成为惯例,下一次增长就没有任何人看到 —— 它会安静地落进新抬出来的余量里,直到某天用户抱怨首屏慢。这正是这道门当初为 #5266 那次 89 KiB 事故建起来的原因,而这次的 126.7 KiB 比它还大。门没坏,门正在按设计工作。C 让放宽这件事必须留名、留期限,而不是改个常量就消失。

④ 创业阶段不扩散 —— 反直觉的一点:这 126.7 KiB 大部分不是我们自己加的功能,是 spec 自己的 dist 长了 8%。为一次依赖升级先做一轮拆分重构,是把有限的工程预算花在减重上而不是做功能上 —— B 的隐性成本比它看起来高,除非拆分本来就快做完了。

推荐

荐 C,回退 A。

理由:用户代价 A 和 C 一模一样,但 C 不用付「天花板失去可信度」这笔长期账;而 B 只有在拆分已经接近可落地时才划算 —— 而这一点我看不见(见下)。

如果你觉得治理开销不值这个事,A 是诚实的选择,只是请连带确认「天花板可以为依赖升级让路」这条先例。

本分析看不见什么

• 没有实测加载时间影响。126.7 KiB 换算成秒需要真实网络实测,我只有字节数。按带宽粗估是零点几秒,这是估算不是读数。
• 不知道 finding(fields): every lazy widget import in packages/fields/src/index.tsx is defeated by a static import of the same module — 13+ INEFFECTIVE_DYNAMIC_IMPORT warnings per console build #5325 / finding(app-shell/console): the DraftChangesPanel /meta spelling fold puts @objectstack/spec/shared on the console's EAGER graph — +60.1 KB gzipped that no budget weighs #5359 拆分要多久、风险多大 —— B 的真实代价我估不出来,这直接决定 B 值不值。
• 不知道这 126 KiB 里有多少是可拆的。可能大部分是 tree-shake 不掉的 spec schema(那 B 的收益就有限),也可能有大块可以懒加载。
• CI 的 Bundle Analysis 还在跑。上面所有数字来自 dev 的本地实测,已对 origin/main 反查过(main 那侧 3,871,997 B PASS,余量 85.9 KB),但还没有 CI 的独立确认。

裁后我会怎么执行(你不用管)

• 回 A → 我立卡把天花板与那条 headroom 断言一起改到新实测值,派 devx 席实施,PR Pin @objectstack/* to 17.1.0 #5529 随后转 ready 入队。
• 回 B → Pin @objectstack/* to 17.1.0 #5529 保持 draft 停放,写 Blocked-by: 指向拆分卡,并把拆分卡提到本车道最前;17.1 的 5 张下游卡继续等。
• 回 C → 我立卡定义具名限期豁免的形状(带到期判据,不是裸常量),派实施,Pin @objectstack/* to 17.1.0 #5529 随后入队;同时把 Add per-chunk budgets on top of the aggregate eager-closure ceiling — vendor-objectstack (38%) first — ruled follow-up of #5468 #5490 的分块预算和拆分卡的优先级提上去。

回一个字母即可;或「C,但 X」—— 若 X 使豁免机制不成立,自动落到 A。

① 项目长远合理性:天花板今天刚裁「不动」,当天为第一个撞线的变更抬高,它以后就不再是承诺(缩小特例:C > B > A)。
② 实际业务拉动:17.1 是今天点名要的升级且已解锁 5 张卡,但 126.7 KiB 落在每个终端用户首屏上 —— 两侧都是真拉动,不适用「无拉动默认 defer」。
③ 防 AI 犯错:抬阈值是「把 CI 弄绿」最不显眼的一招;抬了之后下一次增长没有任何人看到,静默落进新余量,而这次的量比这道门当初要拦的 89 KiB 事故还大(响亮拒绝 > 静默容忍:C/B > A)。
④ 创业阶段不扩散:这 126.7 KiB 主要是 spec dist 自己长了 8%,不是我们新增的能力;为一次依赖升级先做整轮拆分,是把工程预算从做功能挪到减重(B 的隐性成本被低估)。
推荐:C(具名限期豁免,天花板不动),回退 A(永久抬线并确认先例);B 仅在拆分接近可落地时更优。
本分析看不见什么:126.7 KiB 对真实用户的加载时间(只有字节数,没有网络实测)、拆分卡的工期与风险、这 126 KiB 里可拆比例、以及 CI Bundle Analysis 的独立确认(数字来自 dev 本地实测,已对 origin/main 反查)。

---

出处:PR #5529(Fixes #5328)· 天花板裁定 #5468 / 执行卡 #5490(原话「其他接受」= A now + C next, B rejected)· 量具 #5324 / PR #5463–#5466 · 拆分方向 #5325 / #5359 · 历史事故 #5266(89 KiB)

⛔ 定级、type 与 domain:* 归分诊席;本卡按跨座位升级规则落 needs-user-decision,不自定级。

[os-support-ai]

四棱卡面块(canonical copy). 卡正文里那份的机器可寻标记被 sanitizer 吃掉了 —— 写入时是 HTML 注释形态,回读核验发现只剩一个空行,四棱行本身活着。按「提取按字面文本 grep,不依赖注释形状」的纪律,标记在这里以字面文本重发,本评论为该块的权威副本。

标记:os-decision-facets

① 项目长远合理性:天花板今天刚裁「不动」,当天为第一个撞线的变更抬高,它以后就不再是承诺(缩小特例:C > B > A)。
② 实际业务拉动:17.1 是今天点名要的升级且已解锁 5 张卡,但 126.7 KiB 落在每个终端用户首屏上 —— 两侧都是真拉动,不适用「无拉动默认 defer」。
③ 防 AI 犯错:抬阈值是「把 CI 弄绿」最不显眼的一招;抬了之后下一次增长没有任何人看到,静默落进新余量,而这次的量比这道门当初要拦的 89 KiB 事故还大(响亮拒绝 > 静默容忍:C/B > A)。
④ 创业阶段不扩散:这 126.7 KiB 主要是 spec dist 自己长了 8%,不是我们新增的能力;为一次依赖升级先做整轮拆分,是把工程预算从做功能挪到减重(B 的隐性成本被低估)。
推荐:C(具名限期豁免,天花板不动),回退 A(永久抬线并确认先例);B 仅在拆分接近可落地时更优。
本分析看不见什么:126.7 KiB 对真实用户的加载时间(只有字节数,没有网络实测)、拆分卡的工期与风险、这 126 KiB 里可拆比例、以及 CI Bundle Analysis 的独立确认(数字来自 dev 本地实测,已对 origin/main 反查)。

---

平台事实,值得记一笔:HTML 注释形态的机器可寻标记在本仓 issue 正文里活不下来。 这次是写后回读抓到的 —— 若不回读,这张卡会以「带四棱块」的样子存在,而任何按标记 grep 的提取都找不到它,静默漏掉。参考文件已经预告了这个失效模式并要求回读核验;这是它命中的一次实例。

---

Generated by Claude Code

[os-support-ai]

置信缺口更新:CI 已独立确认,那一条不再是缺口

卡片正文和四棱块里的置信缺口写着「CI 的 Bundle Analysis 还在跑……还没有 CI 的独立确认」。现在有了。 决策卡上的过时缺口行会让你以为把握比实际低,所以就地更正。

Bundle Analysis 已 completed / failure,head 97c1162a,并在 PR 上贴出了 Console Performance Budget 表:

读数	CI(KB)	dev 本地(B)	换算核对
eager closure(52 chunks)	3908.4 KB	4,001,689 B	3908.4 × 1024 = 4,002,202 B ✅
预算 / MAX_EAGER_CLOSURE_GZIP_BYTES	3867.2 KB	3,960,000 B	3867.2 × 1024 = 3,960,013 B ✅
结论	FAIL	FAIL	一致

两个读数是同一个测量,只是单位不同(CI 用 KiB 且显示到 0.1 KB,所以超出量在 41.2 KB 与 dev 报的 41,689 B ≈ 40.7 KB 之间有约 500 B 的显示取整差 —— 量级与结论不受影响)。

顺带一个 CI 独有的读数:入口 chunk 本身只有 151.1 KB / 预算 350 KB,很宽裕。所以这不是「入口变胖」,是静态可达的闭包变胖 —— 也就是说,靠给入口瘦身解决不了,只能减少 console 首屏静态可达的东西(或接受它)。这一点支持选项 B 的技术可行性判断需要真正的 cleave,而不是挪一挪 import。

修订后的「本分析看不见什么」

• CI 的独立确认 → 已确认,与本地实测一致。
• 仍然看不见:126.7 KiB 对真实用户的加载时间(只有字节数,没有网络实测)。
• 仍然看不见:finding(fields): every lazy widget import in packages/fields/src/index.tsx is defeated by a static import of the same module — 13+ INEFFECTIVE_DYNAMIC_IMPORT warnings per console build #5325 / finding(app-shell/console): the DraftChangesPanel /meta spelling fold puts @objectstack/spec/shared on the console's EAGER graph — +60.1 KB gzipped that no budget weighs #5359 拆分的工期与风险 —— 这仍是 B 值不值的决定性未知。
• 仍然看不见:这 126 KiB 里可拆比例(CI 的分包表给了每包大小,但没给「哪些是 console 首屏静态可达」的归因)。

其余分析、选项与推荐(荐 C,回退 A)不变 —— 唯一变化是这些数字现在有两个独立来源。

---

Generated by Claude Code

[os-zhuang]

Triage (decision-inbox duty): four-prism block validated — canonical literal-text copy in the first comment survives the sanitizer, confidence-gap lines updated with the CI confirmation; nothing to backfill. Added domain:devx (gate-strength question on the bundle-budget machinery — engineering face per the three-stream split, consistent with #5490) and type Task. Card stays in the decision inbox for the maintainer; no grading beyond routing per the card's own footer.

---

Generated by Claude Code