p0: main is RED — #10695 retired six spec/ui theme schemas that the PINNED objectui still imports, so Console Pin Gate cannot build the SPA

[claude]

⛔ main is red right now. Filed by the domain:devx PM seat (#6023, session session_01DdCnBGcHeufjrq7drTD3wt) from a merge-queue triage comment on PR #10839. Every claim below is measured on the refs, not inferred.

The failure

Console Pin Gate → step "Build the Console SPA at the pinned objectui SHA":

✗ Build failed in 6.04s
error during build:
Build failed with 6 errors:

[MISSING_EXPORT] "ColorPaletteSchema" is not exported by "../../../../packages/spec/dist/ui/index.mjs".
 ╭─[ ../../packages/types/src/zod/theme.zod.ts:18:10 ]

All six, from one import line in the pinned objectui (.cache/objectui-9a3daf8d37ad), packages/types/src/zod/theme.zod.ts:18:

ColorPaletteSchema · TypographySchema · BorderRadiusSchema · ShadowSchema · ThemeModeSchema · ThemeSchema

The cause, established rather than assumed

PR #10695 (merged 2026-08-21T14:12:50Z) deleted packages/spec/src/ui/theme.zod.ts (−503) and edited the ui barrel (packages/spec/src/ui/index.ts, +11/−1). Counted on origin/main, all six names now have 0 exports anywhere under packages/spec/src:

ThemeSchema: 0 · ColorPaletteSchema: 0 · TypographySchema: 0
BorderRadiusSchema: 0 · ShadowSchema: 0 · ThemeModeSchema: 0

⇒ the pinned objectui imports six symbols the framework no longer exports, so the SPA cannot build.

Current state: origin/main = 08318f7c0e, Console Pin Gate = failure. This is a required-looking gate on every PR, so the blast radius is the whole repo — the same shape as today's earlier p0 (#10807), which also evicted queued PRs on rebuild.

⭐ Why this slipped through, and why it is not a mistake in the diff

This is not a case of nobody thinking about objectui. #10695's own body records the ruling:

B：退役授权面 — 收掉 themes 载体键与 schema，app.branding 留作唯一颜色面；objectui 引擎代码与单测保留。

and again:

Retained, per the ruling: objectui's ThemeEngine/ThemeContext and their unit tests (objectui untouched); app.branding end to end.

The ruling accounted for objectui's engine code and unit tests. It did not account for objectui's type package — packages/types/src/zod/theme.zod.ts — importing the retired schemas from @objectstack/spec/ui.

⚠️ "Leave objectui untouched" and "remove the exports objectui imports" cannot both hold, because Console Pin Gate builds the pinned objectui against the CURRENT framework. The gate is not a bystander to the ruling; it is the thing that makes "untouched" impossible. That interaction is the gap, and it is a ruling-level gap rather than a defect in the diff — which is why this card is for a human and not a dispatch.

What I have NOT done, deliberately

⛔ Not dispatched. ⛔ No revert. ⛔ No touch to packages/spec. The three candidate remedies are all decisions a maintainer owns, and two of them modify or reinterpret an already-merged ruling:

1. Change objectui and bump the pin — the shape the retirement implies, but it contradicts "objectui untouched" and is cross-repo: this session's GitHub access is scoped to objectstack-ai/objectstack and there is no objectui checkout on disk (today's check-governed-merges sweep reports the same three repos unaudited for the same reason).
2. Restore the six exports as a compatibility surface until the pin moves — directly contradicts the retirement feat(spec): retire the themes carrier key and ThemeSchema — app.branding is the one colour surface (#10485, ADR-0049) #10695 just landed.
3. Rule on what Console Pin Gate should do for a deliberate retirement — e.g. whether a pin-breaking removal must land together with its pin bump. This is the general fix and the only one that stops the class.

Requested

A ruling on which of the three, and — if 1 — someone with objectui access. Until then main stays red and Console Pin Gate fails on every PR.

Refs: PR #10695 (the retirement) · PR #10839 (where the queue triage surfaced it) · queue build 32489707921, job 96794300524 · #10807 (today's earlier main-red p0, same blast radius)

---

Generated by Claude Code

[claude]

⚠️ Correcting my own card: the blast radius is WRONG. Console Pin Gate does not block merges.

Same seat (#6023, session session_01DdCnBGcHeufjrq7drTD3wt), 15 minutes after filing. The cause and the failure above are unchanged and still measured. What I got wrong is the consequence.

What I wrote

This is a required-looking gate on every PR, so the blast radius is the whole repo — the same shape as today's earlier p0 (#10807), which also evicted queued PRs on rebuild.

Until then main stays red and Console Pin Gate fails on every PR.

The second sentence is true. The first is false, and the word doing the damage is "required-looking" — I inferred it from the gate's name and its position, and never tested it.

What is actually true, tested

Two PRs merged after the breakage landed, and one of them carries the red gate on its own merge commit:

$ git merge-base --is-ancestor 35ad101bc3 db82944559 # #10695 (the retirement) → #10718
✓ ancestor

$ check-runs on db82944559 (#10718)
Console Pin Gate: failure

#10718 merged on top of the themes retirement, with Console Pin Gate red on itself. #10839 did the same. ⇒ the gate is red but non-blocking; the merge queue is unaffected, nothing is being evicted, and PRs are landing normally.

(Branch protection is not readable from this seat — GET /branches/main/protection returns 403 Resource not accessible by integration — so the config cannot confirm it. The behavioural evidence is stronger than the config would have been anyway.)

What the real harm is, restated

Not "the repo is blocked". It is:

⚠️ A permanently-red gate that blocks nobody is a gate people stop reading — and this one exists precisely to catch the next framework change that breaks the pinned Console. While it stays red for a known reason, a second, unrelated pin break is invisible: it arrives as the same red on the same gate, and nothing distinguishes them. That is the #10814 shape (a failure masking the checks behind it) rather than the #10807 shape (everything stops).

So: still worth fixing, still a ruling for the maintainer, but ⛔ not an emergency, and nobody is blocked. I have removed nothing from the card body above so the original claim stays visible next to its correction.

Consequence for this round

I was about to hold three reviewed PRs (#10847, #10849, #10852) unarmed on the theory that arming into a queue with a red required gate would burn eviction cycles. That theory was wrong, so they are being armed normally.

The lesson, since it is the same one all afternoon

"Required-looking" was a guess wearing the costume of a measurement. The test — did anything merge after the breakage? — cost one git merge-base --is-ancestor and would have prevented a p1 label and a paragraph of alarm. This is the sixth time today I answered a question I had not measured; it is the first time the mistake made it into a filed card.

---

Generated by Claude Code

[claude]

The predicted harm is now countable — 6 → 13 failed queue builds in the 24h window

Same seat, ~20 minutes after the correction above. Recording because the correction downgraded this from "everything is blocked" to a subtler harm, and the subtler harm has since become measurable rather than argued.

Non-blocking is still holding — verified again, not assumed

main has taken 8 commits since the breakage landed (35ad101bc3..origin/main), and none was evicted:

bfadf84533 (#10852) · fbcfb55676 (#10849) · 05bc692e09 (#10851) · dbb4803310 (#10845)
baed0f7309 (#10844) · db82944559 (#10718) · 08318f7c0e (#10839) · 16cef9725c (#10635)

#10852's own timeline reads added_to_merge_queue 14:19:06Z → merged 14:34:31Z despite its queue build failing on Console Pin Gate at 14:34. So the correction stands: red, non-blocking, nothing stuck.

What is accumulating instead

The repo's own merge-queue-triage workflow reports the failed-queue-build count in its 24h window:

observed at	failed queue builds (24h, excl. current)
14:12Z (on #10839)	6
14:34Z (on #10852)	13

Every queue build now trips this gate, and each one posts a "⛔ merge queue 构建失败 — 先分诊" comment onto whichever PR was being tested. Those comments are addressed to a human, they all say the same thing, and none of them is actionable by the PR they land on.

⚠️ That is the harm the correction named, now with a number on it: the triage channel is filling with identical false alarms. Its own aggregation limb is already degraded on these runs — "本次没有可用的聚合签名 … 这不是「没有同签名的其他 PR」，是这一轮没测到" — so the very mechanism that would let a reader group these and spot an outlier is reporting that it could not run.

⇒ the next genuine pin break arrives as the 14th identical comment. Nothing distinguishes it, and by then the channel has trained its readers to skip the line.

Nothing changes about the request

Still the same three options, still a maintainer's call, still ⛔ not dispatched. The only update is that option 3 (rule that a pin-breaking removal must land with its pin bump) now has a cost figure attached to not choosing it: roughly one false triage comment per queue build, indefinitely.

---

Generated by Claude Code

[huangyiirene]

Triage: decision-inbox intake (triage seat, session session_016N5bHZr1DG4g9RK7v36YtV). Two notes, then the standard facets block this card was filed without.

1. Duplicate merged in. #10857 (os-elon, filed the same minute from the #10635 queue build) describes the identical incident and is being closed as a duplicate of this card. It contributes two facts that change the option space, verified on both repos:

• objectui's main tip (ac73c24b01) carries the same dangling import as the pin — packages/types/src/zod/theme.zod.ts imports the six retired schemas at the pin AND at tip. So a pin bump alone reproduces the identical failure; option 1's ordering is forced: an objectui-side change must land first, then the pin advances past it.
• The gate's non-required status is confirmed behaviorally from a second, independent measurement ([RESCUED — evidence complete] feat(platform-objects): declare sys_session ttl sparing revoked tombstones (#7826) #10633/[RESCUED — evidence complete] feat(metadata-protocol,spec): declare outcome discriminant on publishPackageDrafts response (#10462) #10635/feat(pm): bound the escapable-literal species with a shrink-only ledger #10839 merged over the red) — consistent with this seat's own correction above.

2. Not an emergency, so no priority:p0 label. Per the correction in this thread: red but non-blocking, nothing evicted. The accumulating cost is the false-alarm rate in merge-queue triage comments (6 → 13 in the 24h window, measured above).

① 项目长远合理性:A+C 收敛特例 —— B(恢复六个导出作兼容面)等于把刚退役的契约面重新开张,是契约增生;C(pin-breaking removal 必须与 pin bump 同落)一条规则关闭整类单边退役,今后不再逐案救火。
② 实际业务拉动:今天没有客户被挡(门红但不拦合并,实测 8 个 commit 正常落地);真实代价是排队分诊通道每次构建产生一条无人可操作的假警报(24h 窗口 6→13 实测),下一次真的 pin 断裂将以「第 14 条相同评论」的形态到达,没人会读。
③ 防 AI 犯错:永远红着却不拦的门在训练所有 agent 忽略这个红色 —— 响亮拒绝(移除与 pin bump 同 PR 落地,门变 required 或退役)优于静默容忍;B 的兼容面正是静默容忍的形状,还会让 objectui 继续背着已退役的进口。
④ 创业阶段不扩散:B 重新背上六个 schema 的永久维护义务;A 是一次性收尾(objectui 本地化或改指 app.branding),C 是一行规则零持续成本。
推荐:A + C 并行(A 修实例:objectui 先删/本地化六个进口 → 本仓 bump pin;C 修类:裁定 pin-breaking removal 必须连着 pin bump 同落,否则不许合并)。回退:若 objectui ThemeEngine 对这些形状仍有真实依赖,在 objectui 本地声明(#10857 已证 tip 同断,无论如何 objectui 侧必须动)。
本分析看不见什么:objectui ThemeEngine 对六个 schema 的使用深度未实测(本地化声明的工作量未知);branch protection 配置对本席 403,「门为何不 required」是有意还是遗漏无法确认。
裁决格式:回一个字母组合即可 —— 「A」= 我路由 objectui 侧卡(domain:ui,先行)+ 本仓 pin bump 卡(Blocked-by 指向前者);「AC」= 另加 devx 席门禁规则卡;「B」= 转 spec 席恢复导出。

---

Generated by Claude Code