decision: objectui 按提交钉 objectstack（.objectstack-sha），开发与 CI 从该提交的源码构建 @objectstack/*，npm 版本范围与下限只在 objectui 发版时由提交算出 —— 前端不再逐个 PR 等后端发版 #12955

Ruled: 6248859734 · letter B · execution cards #12957 (pin and build), #12958 (floors at publish), objectstack-ai/objectstack#24306 (build-console) · dispatched by domain:ui seat 1 on the maintainer's order

Filing gate ②：只有维护者能做的决定。 维护者在 domain:ui seat 1 的会话（session_0188TsgPV8kQXfuRuKmkj2ks）里先问了这个问题，原文：「还有目前前后端互相依赖的方式开发太麻烦了，前端经常要等后端发版本，猴没有更好的方案」。席位给出四个方案并推荐 B，维护者随后写道（原文）：「写决策卡 objectui 也改成按提交钉 objectstack：新增 .objectstack-sha，开发和 CI 都从这个提交的源码构建 @objectstack/spec 等包（objectui 只依赖 spec、client、formula、lint 这几个）。npm 版本范围只在 objectui 发版时才起作用，下限也可以在那时按「哪个已发布版本包含这个提交」机械地算出来。」

• 立卡席： objectui domain:ui seat 1（座位帖 objectui#5560）。⛔ 这不是认领。
• 为什么立在 objectui： 推荐方案的主要改动落在本仓（跨仓规则 1）。车道归属：spec pin 耦合的决策卡归 domain:spec（lanes/spec.md:13），执行归本仓 domain:devx（.github/、scripts/、发布管线，见 lanes/devx.md:8），objectstack 侧另有一处 scripts/build-console.sh。
• 起因： 今天同时撞上两件事：三张前端卡的后端部分已合进 objectstack main，却仍在等发版；18.0.0-next.3 升级漏提了两个包的下限（objectui#12943、deps(plugin-detail): raise @object-ui/plugin-detail's @objectstack/spec floor from ^18.0.0-next.1 to ^18.0.0-next.3, the first release that exports the SelectOptionKind its published types reference #12946，见下）。

维护者速读

现在 objectui 从 npm 上的 @objectstack/*@next.N 取后端契约。后端改动合并以后，要等人工发版（2026-08-07 裁定：版本发布必须人工），前端才能开工。等待期间，被搁置的卡和版本下限都要靠人记，今天两样都出了错。

• A：维持现状。
• B（维护者提出的方案）：objectui 增加 .objectstack-sha。开发和 CI 从这个提交的源码构建所需的 @objectstack/* 包，按提交缓存。npm 版本范围只在 objectui 发版时起作用，下限由「哪个已发布版本包含这个提交」算出。
• C：objectstack 每次合并都把包发到第三方预览仓库（pkg.pr.new），objectui 按提交 URL 引用。
• D：objectstack 每次合并都自动往 npm 发 snapshot 版。需要先改 08-07 的人工发版裁定。

推荐 B。回一个字母：A / B / C / D。

一句话问题

后端已经合并的能力，要等下一次人工发版，前端才能开发和上线。一个跨前后端的功能因此至少要多一个发版周期才能到用户手里；等待期间被搁置的工作靠人记，记漏了就是漏发、漏改。

背景与 Governing text

• 人工发版裁定：objectstack/.github/workflows/release.yml 开头记录了维护者 2026-08-07 的原话：「刚才我也没提出要求,是哪个ai自己替我发了 rc.4,版本发布必须是人工的。这个要写入规范。」ADR-0125 把授权发版的人工动作定为 environment: release 审批。方案 B 和 C 不碰发版；D 与这条裁定直接冲突。
• 反方向已经按提交钉：objectstack 用 .objectui-sha 加 scripts/bump-objectui.sh（741 行）和 scripts/build-console.sh（435 行）从源码构建 objectui；cloud 也按 .objectstack-sha 钉 objectstack（references/triage-duties.md:28）。只有 objectui → objectstack 这个方向走 npm。
• console 打包已经注入源码 spec：objectstack#8134 把 framework 自己的 spec 注入 console 包，objectui#4854 加的钩子（PR feat(console): OBJECTSTACK_SPEC_DIST hook so a framework build can bundle its own @objectstack/spec (#4854) #4927，+799/−14）是它的落地，build-console.sh:276-286 的注释写明了要解决的就是「spec 发布 → objectui 刷锁文件 → pin 移动」这三步等待。但 objectui 自己的开发、类型检查和测试仍用 npm 上的 spec。objectstack#9659（把注入扩到另外 4 个包）于 2026-09-23 以 not_planned 关闭，维护者原话「第四组 同意」，理由是实测这 4 个包都不需要注入（2 个与已发布产物逐字节相同，另 2 个的差异 console 用不到）。
• spec 形状门已从 objectui 移走：objectstack#23238 裁定 B（2026-10-13，维护者「其他同意」）把「拿 objectstack main 编译 objectui」的形状门移到 objectstack，按小时跑，发版前必须过；objectui 删掉了它的副本（objectui#12352）。被否的 D 理由是「把 13 分钟的任务放上 PR 路径，违反两速 CI 规则 1」（objectstack#22998）。这对方案 B 是一条设计约束：按提交构建必须靠提交号缓存，不能每个 PR 都重建。
• 两速 CI 的原话（objectui#12214）：「我觉得能让整个车队提速的方案就是好方案，main 很多天才会发一个版本，我只要确保发版本之前做好各种测试就可以。」
• objectui AGENTS.md §9 版本号策略：objectui 的 major 与 @objectstack 的 major 保持一致。方案 B 不改这一条。

协议声明： 方案 B 会改 objectui AGENTS.md 里依赖和锁文件的规则，也会改 pm-dispatch 的 Restart-when: 写法：「等 next.N 发布」改成「pin 已包含 」。后者与 objectstack#24276（B 项）一并执行。

前提（每条带复核命令）

1. objectui 依赖的 @objectstack/* 包。 objectui 在 manifest 里声明 spec、client、formula、lint。但 client 依赖 @objectstack/core，lint 依赖 @objectstack/sdui-parser，所以从源码构建实际要 6 个包：spec、core、client、formula、sdui-parser、lint。
   • 复核：git grep -hoE '"@objectstack/[a-z-]+":' origin/main -- '**/package.json' | sort | uniq -c（objectui）；在 objectstack 里 node -e "console.log(require('./packages/client/package.json').dependencies)"，lint 同理。
2. 今天有三张卡在等发版。 objectui#12932、Studio 变更 drawer: on publish, offer 补默认值 per new field that carries a default, through the protocol's opt-in backfill (ruling A on cloud#2924) #12929、approvals B1 closing card (ruling C on objectui#12438): the inbox opens a request on the served sys_approval_request page where the side sheet is, deletes the sheet, and lists each retired pin against its user report #12484 都是 pm:blocked，Blocked-by: objectstack-ai/objectstack#24168（Version Packages PR，2026-10-17T12:12Z 开出，至今未合）。它们的后端部分 586705d85d、1e001c7df、e15897c0f1 已于今天 07:35–08:17Z 合进 objectstack main。
   • 复核：gh api 'repos/objectstack-ai/objectui/issues?labels=pm:blocked&state=open' --jq '.[].number'，再逐张读 body 里的 Blocked-by: 行。
3. 一次发版集中解锁很多卡，是常态。 objectui#11717 一次升到 17.7.0，解锁了 8 张等它的卡。
4. 发版频率。 npm view @objectstack/spec time：18.0.0-next.0 到 next.3 分别发于 10-13、10-14、10-16、10-17。
5. 今天的下限事故。 next.3 升级（objectui#12873，PR deps(v18): resolve @objectstack/* 18.0.0-next.3 and follow its contract (objectui#12873) #12887 写「Range floors. None moved.」）漏提了 app-shell 和 plugin-detail 的下限。plugin-detail 那处让 main 的夜检 Spec Range Floors 从 c4dd7078 起变红，changeset:publish 会因此拒绝发版；app-shell 那处是语义缺口，按符号判断的检查看不见。已由 objectui#12943、deps(plugin-detail): raise @object-ui/plugin-detail's @objectstack/spec floor from ^18.0.0-next.1 to ^18.0.0-next.3, the first release that exports the SelectOptionKind its published types reference #12946 修复，预防卡是 objectstack#24276。

选项 × 真实代价 × 工作量

不列：把两个仓库合成一个。它最彻底，但两个大仓库的历史、CI 和门禁迁移成本远超本问题。

业务含义直译

• A：前端每用一个新零件，都要等后端正式出货一次。
• B：前后端在同一条流水线上按零件编号对接，只有对外发货时才对版本号。这和 objectstack 取 objectui 的方式一样。
• C：零件先放进第三方的临时仓库中转。
• D：后端每改一次都自动正式出货，等于取消「发版必须人工」。

四轴（从业务立场论证）

• ① 项目长远合理性（领起）：B 让三条跨仓依赖（objectstack←objectui、cloud←objectstack、objectui←objectstack）用同一种机制，契约面不增加，也不引入第三方。npm 回到它本来的角色：对外发货的出口。C 多一个外部依赖面；D 推翻一条明确裁定。
  • 终态：两年后，objectui 与 objectstack 应像 Chromium 用 DEPS 文件按 git 修订钉住依赖仓、由 autoroller 滚动那样按提交互钉，版本范围由发版流水线从提交算出。
• ② 实际业务拉动：今天就有三张卡因此搁置（前提 2）；17.7.0 那次一次解锁 8 张（前提 3）。每个跨前后端的功能都会撞上，不是投机需求。
• ③ 防 AI 犯错：
  • A 出错时用户看到的是静默错误：下限漏提，按符号判断的检查一直绿；被搁置的卡被遗忘，功能没上线也没人知道。
  • B 出错时是响亮的拒绝：pin 不对，PR 的类型检查当场红；发版时 pin 不在任何已发布版本里，算下限这一步给不出答案，发版直接停下。
  • C 的 URL 依赖和 npm 上的版本可能悄悄不一致。D 自动发版出错时，错误版本直接公开发布。
• ④ 创业阶段不扩散：B 的工作量一次付清；check-spec-range-floors.mjs 在发版时的检查可能随之变得多余，可以退役，不新增门禁。C 和 D 各多一条长期运维的管道。

四棱

os-decision-facets

• ① 项目长远合理性：B 缩小特例，objectui 不再是三个仓库里唯一靠 npm 版本对接的方向；C 和 D 各增加一条长期维护的发布管道。
• ② 实际业务拉动：今天 objectui#12932、Studio 变更 drawer: on publish, offer 补默认值 per new field that carries a default, through the protocol's opt-in backfill (ruling A on cloud#2924) #12929、approvals B1 closing card (ruling C on objectui#12438): the inbox opens a request on the served sys_approval_request page where the side sheet is, deletes the sheet, and lists each retired pin against its user report #12484 正卡在等 next.4；objectui#11717 一次解锁过 8 张同类卡。
• ③ 防 AI 犯错：B 把「哪个版本包含这个提交」从凭记忆改成机械计算，出错时响亮拒绝；A 今天就出过一次静默错误（漏提下限）。
• ④ 创业阶段不扩散：B 不新增门禁，发版时的下限符号检查可能退役；C 和 D 各多一条长期维护的管道。

Prior rulings read: objectstack-sha, pkg.pr.new, snapshot, canary, publish ordering, OBJECTSTACK_SPEC_DIST, spec main shape gate, 发版 → 8 hits (release.yml 2026-08-07 ruling; objectstack#23238 ruling B; objectstack#8134; objectui#4854 / PR #4927; objectstack#9659 not_planned; objectui#12214; objectui#11717; triage-duties.md:28); ADR-0125; thread: none

推荐、回退与置信缺口

• 推荐 B。回退 A：保持现状，同时执行 objectstack#24276 的 A、B 两项，把漏记的风险降下来。
• 自检：只看①选 B；②③④ 是否翻转：否。
• 置信缺口（席位看不见、没测过的）：
  1. 在 objectui 的 runner 上从源码构建这 6 个包要多久，没测。旧的 Spec Main Shape Gate 中位数 13.3 分钟，其中还包括编译 objectui（objectui#12214 的实测表）。按提交号缓存后，每次换 pin 只付一次。
  2. pnpm.overrides 指向本地构建的 tarball 后，check:lockfile-integrity 和 check:installed-pin-claims 怎么改，没测。
  3. 循环：objectstack 按 .objectui-sha 构建 objectui，而那个提交的 objectui 又钉着更早的 objectstack。build-console.sh 已经在打包环节注入 framework 自己的 spec；把这种注入扩到安装环节是新做法。
  4. objectui 发 npm 版仍要排在包含该提交的 objectstack 版本之后。等待并没有消失，只是从「每个 PR 都等」移到「每次发版等一次」。

裁后执行

• 裁 B：席位在 objectui 立执行卡，domain:devx，按这个顺序：
  1. .objectstack-sha、bump 脚本、按 pin 构建（按提交号缓存）和 pnpm.overrides，锁文件相关检查跟着调整。改 .github/workflows/** 的 PR 属于 Tier H，需要维护者批准后合并。
  2. changeset:publish 之前由提交算出下限；提交不在任何已发布版本里时停止发版。
  3. objectstack scripts/build-console.sh：objectui 安装时换成 framework 的源码。
  4. AGENTS.md 规则和 Restart-when: 写法，并入 objectstack#24276。
  • 第一次把 pin 换到包含上述三个提交的位置时，objectui#12932、Studio 变更 drawer: on publish, offer 补默认值 per new field that carries a default, through the protocol's opt-in backfill (ruling A on cloud#2924) #12929、approvals B1 closing card (ruling C on objectui#12438): the inbox opens a request on the served sys_approval_request page where the side sheet is, deletes the sheet, and lists each retired pin against its user report #12484 立即解锁，不必等 next.4。
• 裁 A：本卡关闭，objectstack#24276 照常执行。
• 裁 C 或 D：席位按所选字母在 objectstack 立执行卡；D 需要先在卡上修改 08-07 裁定。

Generated by Claude Code