[Decision] 发布条件 (c) 的「objectui 升 spec 18」半句：改成「发布的控制台不误报」（A，已满足），还是保留并让 objectui 先依赖 18.0.0-next（B） #23230

Ruled: 6144977963 · letter B · 2026-10-13T12:00Z · condition (c) keeps both halves; objectui moves to spec 18 before the GA cut through objectstack-ai/objectui#12030 (18.0.0-next.x)
Part of #15204
Filing gate ②：只有维护者能做的决定。v18 正式版的发布条件由维护者定。也算 ③：维护者在本席会话中要求「补这 4 张决策卡」。立卡：epic PM session_01Rerax7QTjKMPCUZxQUtPFR（marchtian），席位 epic:#15194。
Prior rulings on this card: none（新卡）。相关记录：

• 发布条件 6102862135，其中 (c) 是「C9 with stage 7」；
• 本席在 objectui#7611 上加了「objectui 升 spec 18」半句（6104671088）；
• 本席提出改写（6111428679）；
• F1 的实测（6111383302）；
• next 预发布豁免发布条件（6117174845）。

锚点： 改写提案 6111428679 是 #15204 上的一条席位说明，写的是「维护者确认后生效」，一直没有立卡。#15204 是活动中的执行卡，给它挂决策标签会让它退出活动队列，所以单开本卡。

查重： 用语义检索搜 objectstack 卡，关键词 release-cut condition / objectui spec 18 pin / console banner / does not match the spec，命中 27 张，前 8 张全部已关，都是 console pin 和 checklist 的旧卡（#21709、#21993、#21802、#21797、#21589、#8051、#20029、#19503）。没有同题的开着的卡或决策卡。在 objectui 搜 upgrade @objectstack/spec to 18 / major sync，命中 0 张。

动手的读者：

• 裁 A：本席在 refactor(plugin-security,platform-objects,spec): retire the catalog seeders, the per-organization catalog machinery and the four catalog objects; Setup creation is an environment write under single and refused under a wall (ADR-0131 D2/D3/D5/D13) #15204 上改写发布条件记录。正式版切版前，交 domain:devx 车道按 6111383302 的方法重测一次。
• 裁 B：本席在 objectui 为 domain:ui 车道立 1 张 spec 18 升级卡。

维护者速读

事情： v18 正式版的发布条件 (c) 有两半：

• 前一半：C9 和阶段 7 合入。这一半不变。
• 后一半：objectui 把它依赖的 @objectstack/spec 升到 18。这一半是本席 10 月 11 日加的（6104671088）。

当时为什么加： objectui 用的是 spec 17.7.0。它的控制台会对「声明了权限集的岗位」显示横幅「与 spec 不符」，把一个合法的岗位说成不合法（F1）。我们不能发布一个会这样误报的控制台。

后来实测（6111383302）： 我们的两条发布流水线构建控制台时，会把本仓库这一版的 spec 注入进去。

• 注入后的控制台：横幅 0/4；
• 不注入的对照：横幅 4/4；
• 正向对照：故意填一个非法名字，横幅会出现，说明它没坏。

而且只要构建出来的控制台带的是旧 spec，流水线就会失败。昨天的 18.0.0-next.0 发布（Release run 38366760783）里，「控制台带的是本仓库的 spec」这一步是绿的。

原文的问题：

• 要 objectui 升到正式的 spec 18，得先有 18.0.0 正式版；而 (c) 又挡着正式版发布。这是个死循环。
• objectui 自己的版本规则也写明：objectstack 跨 major 之后，objectui 的下一次发版再跟上。

两个选项：

• A： 把后一半改成「我们发布的控制台，对声明了权限集的岗位不显示『与 spec 不符』横幅」。今天已满足，正式版切版前再重测一次。objectui 自己什么时候升 spec 18，按它自己的版本规则。
• B： 保留原文。现在 18.0.0-next.0 已经在 npm 上，objectui 可以先把依赖改成 18.0.0-next，在正式版之前合入，死循环就解开了。代价是 objectui 要提前吸收 spec 17→18 的全部破坏性变更，在此期间 objectui 的发版要么带一个预发布依赖，要么暂停。

本席推荐 A。 选 A 还是 B？

背景（实测：objectstack origin/main 8024e1243a，objectui origin/main，2026-10-13）

• objectui 现在的依赖： 根 package.json 是 "@objectstack/spec": "^17.0.0"，packages/types/package.json 是 "^17.7.0"。

• 控制台的 pin： objectstack 的 .objectui-sha 现在是 objectui 1fb1ced36243（chore(objectui): move the console pin to 1fb1ced36243 (objectui main tip, Half 1 of #23104) #23110）。F1 上次实测是在 pin 4997995022f8、main 55382dc02a 上；在当前 pin 上没有重测。

• 发布流水线的断言： Release run 38366760783 的发布作业里，以下几步都通过：

  • 「Verify Console dist stamp matches pin」；
  • 「Verify the restored Console dist bundles this tree's spec」。

  6111428679 还记录：release.yml 的 check:console-sha 和 check:console-injection --require-stamp 会拒绝带旧 spec 的控制台。

• npm： @objectstack/spec 的 next 标签是 18.0.0-next.0，latest 是 17.7.0。

• objectui 的版本规则（objectui AGENTS.md「版本号策略」）： 「objectui 的 major 与 @objectstack（spec/client/formula）的 major 保持一致」；「objectstack 跨 major（→12）时，下一次 objectui 发版一并把 major 提到 12」。

Governing text

• 发布条件（6102862135）： 「(c) C9 (objectui#7611) with stage 7, after which Setup's "Bind permission set" writes the definition」。
• 加入后一半的记录（objectui#7611 6104671088）： 「objectui's spec-18 pin bump is added to release-cut condition (c) of objectstack 6102862135: no objectstack release that carries this console may ship while the banner calls a valid position invalid」。
  • 它要防的是后半句：发布出去的控制台把合法岗位说成不合法。
• next 豁免（6117174845）： 维护者让 next 预发布不受这组发布条件约束，条件仍约束 v18 正式版。
• objectui AGENTS.md「版本号策略」： 原文见上。
• ADR： 检索 release-cut / console / spec pin / banner，命中 15 处，都只是在谈控制台或发布路径，没有任何 ADR 规定发布条件 (c)。这里 none found。

前提（每条带复核命令）

• objectui 仍依赖 spec 17：gh api repos/objectstack-ai/objectui/contents/packages/types/package.json --jq .content | base64 -d | grep '"@objectstack/spec"'，应为 ^17.x。
• npm 上有 18 的预发布：npm view @objectstack/spec dist-tags，next 应为 18.0.0-next.*。
• 发布流水线的注入断言是绿的：gh api repos/objectstack-ai/objectstack/actions/runs/38366760783/jobs --jq '.jobs[].steps[] | select(.name|test("bundles this tree")) | .conclusion'，应为 success。
• 当前 pin：git show origin/main:.objectui-sha，应为 1fb1ced36243…。不一样时，F1 的读数离当前 pin 更远了，正式版切版前必须重测。

选项 × 真实代价

（排除项：保留原文且必须依赖正式的 18.0.0。正式版发布前不可能满足，是死循环。）

业务含义直译

• A： 我们验的是出厂的成品：出厂的控制台不误报，就放行。供应商（objectui）自己的零件型号什么时候换新，按它的节奏。
• B： 出厂前要求供应商先把零件型号换成新一代的试产型号，哪怕成品已经没问题。

四轴（从业务看）

• 项目长远合理性（领起）：
  • 两年后的样子：发布条件约束的是我们发布的那个产物，并由流水线断言结构性地保证；依赖方的版本升级是依赖方自己的生命周期。
  • 参照主流做法：发行版只验证自己打包进去的内容（例如 Debian 发布时验证的是它打进包里的版本，上游何时发布新版本不是它的发布条件）。
  • A 正是这个形状。B 让一个下游仓库的依赖升级卡住上游的正式版。
• 实际业务拉动：
  • 原文要防的伤害：用户在我们发布的控制台里看到合法岗位被误报。已实测不存在（0/4），并有流水线断言保证。
  • objectui 独立使用者（直接用 @object-ui/* npm 包连 spec 18 的服务器）可能看到横幅。但这是跨版本组合，按 objectui 的版本规则，由它在 objectstack 正式版之后的那次发版解决。
• 防 AI 犯错（出错时谁看到什么）：
  • A：如果哪天控制台没带上本仓库的 spec，发布流水线当场失败，响亮。
  • B：靠一个跨仓库的人工依赖升级；升级做完以后，也不能防止以后的控制台再带回旧 spec，真正防住这一点的仍是 A 里的那道断言。
• 创业阶段不扩散：
  • A 零代码，只改一条记录加一次重测。
  • B 要求 objectui 提前做一次 major 同步，并在此期间带预发布依赖。

os-decision-facets

• ① 项目长远合理性：A 让条件约束我们实际发布的产物，并由流水线断言保证；B 让下游的依赖升级卡住上游的正式版。
• ② 实际业务拉动：原文要防的误报在我们发布的控制台里实测为 0/4；objectui 独立使用者的跨版本组合按它自己的版本规则解决。
• ③ 防 AI 犯错：A 的保证是流水线断言，出错就响亮失败；B 靠一次人工依赖升级，防不住以后的回退。
• ④ 创业阶段不扩散：A 零代码；B 要 objectui 提前做 major 同步，并带预发布依赖。

Prior rulings read: release-cut, console, spec pin, banner → 15 hits; ADR-0036 §1/§5, ADR-0045 §7, ADR-0053 §9, ADR-0076 D12 (all incidental, none governs condition (c)); thread: #15204 (6102862135, 6111428679, 6117174845), objectui#7611 (6104671088, 6111055760).

推荐

推荐 A，回退 B。

• 只看①选 A；②③④ 是否翻转：否。
• 工作量：A 是一条记录加一次测量；B 是 objectui 的一次 major 同步，规模未实测。如果 B 的同步超过一个 PR，差距就远超 3×。
• 置信缺口：
  • F1 是在旧 pin 4997995022f8 上实测的，当前 pin 1fb1ced36243 没有重测（所以 A 带一次切版前重测）；
  • objectui 吸收 spec 17→18 破坏性变更的工作量没有统计；
  • 6111428679 里写的范围只覆盖本仓库发布的控制台，cloud 的控制台叠加层没有实测。cloud 是否也要满足这一条，是另一个问题，不在本卡里。

裁后执行

• 裁 A：
  • 本席在 refactor(plugin-security,platform-objects,spec): retire the catalog seeders, the per-organization catalog machinery and the four catalog objects; Setup creation is an environment write under single and refused under a wall (ADR-0131 D2/D3/D5/D13) #15204 上发一条记录，把 (c) 的后一半改写成 A 的措辞，引用本卡的裁决；
  • 更新已知限制记录 6139333945 里 (c) 那一行；
  • 在正式版切版前的检查项里加一条「按 6111383302 的方法，在当时的 pin 上重测 F1」，交 domain:devx 车道执行；
  • objectui 的 spec 18 升级不再是 objectstack 的发布条件。本席在 objectui#7611 上留一条指针，说明它回到 objectui 自己的版本规则。
• 裁 B：
  • 本席在 objectui 立 1 张卡给 domain:ui 车道：依赖改成 18.0.0-next.x，吸收破坏性变更，在 objectstack 正式版之前合入；
  • 卡上写明在此期间 objectui 的发版怎么处理（带预发布依赖或暂停），这一点要你一并裁。
• 不论裁哪一项，你只需回一个字母。

Generated by Claude Code