[finding] check-adr-0087-registration has no honest disposition for a published TYPE-surface narrowing — every category is refused, so the class is pushed to drop the `**BREAKING**` token instead

[os-litant]

Met while writing the changeset for the #12104 shipping half (a @objectstack/client
return-type narrowing). Recorded rather than worked around in place: the workaround the gate
leaves available is the one that makes its own trigger less meaningful.

The dead end, measured

The changeset declared **BREAKING** — truthfully: narrowing a published Promise< any > to a
concrete type can stop a consumer compiling. check-adr-0087-registration then demands one of
its five dispositions, and every one is unavailable:

disposition	why it does not apply
registered <id>	The ADR-0087 registry feeds objectstack migrate meta, spec-changes.json and the generated upgrade guide. Nothing metadata-shaped moved — no Zod schema, no packages/spec declaration, no stored representation — so an entry would carry no prescription any of those three can project. It would be false data in the one ledger the gate exists to keep true.
not-required (unpublished)	False. @objectstack/client publishes to npm.
not-required (already-registered <id>)	False. No entry covers it.
not-required (no-migration-prescription)	Refused by the gate, because the changeset carries a FROM/TO block: "A changeset that ships instructions for rewriting a consumer's code cannot also claim that no consumer has to rewrite anything."
not-required (runtime-interface-only …)	The gate says outright it "inherits this same refusal (#8299)".

The refusal text names the intended exit — "if the prescription is genuinely for someone the
ledger does not serve, use a category that can be verified (unpublished,
already-registered)" — and both of those are factually false here. So the exit the gate
offers is closed for exactly the case it describes.

What the class actually is

A published TYPE-surface narrowing: a consumer-facing prescription exists (rewrite
(await client.analytics.query(q)).rows as .data.rows), the affected party is a TypeScript
consumer, and the delivery channel is the compiler at their own call site. The ADR-0087 ledger
serves metadata upgraders and cannot reach them; the compile error already does, more precisely
than a release note.

The gate's no-migration-prescription refusal is not wrong in general — #6048 is exactly the
shape it was built to catch — it just cannot tell "a prescription for a METADATA upgrader" from
"a prescription for a source-code consumer", and only the first is the ledger's business.

Why this is worth a card rather than a shrug

The available move is to drop the **BREAKING** token, which is what the three prior cards of
this same class did (#8140, #11925, #12034 — all @objectstack/client return-type narrowings,
all minor, all recording the no-entry disposition in prose, none using the token). #12104
followed that precedent for consistency, and the consumer impact is stated in full either way.

But the cumulative effect is the concern: a whole recurring class of genuinely
compile-breaking change is nudged away from the repo's breaking-change marker, purely because
the marker routes it into a ledger it does not belong in. That erodes the token this gate
depends on, and the erosion is invisible — every gate stays green.

Two shapes worth weighing (not prescribed)

1. A sixth category — e.g. not-required (type-surface-only <package>), verified the way
   unpublished is: the named package publishes, nothing under packages/spec changed in the
   diff, and no ADR-0087-shaped surface moved. Mechanically checkable from the same diff the
   gate already reads.
2. Narrow the no-migration-prescription refusal to prescriptions aimed at the ledger's
   own audience, rather than firing on any FROM/TO block.

Either way, the class should be able to say **BREAKING** and still answer the gate honestly.

---

Generated by Claude Code

[huangyiirene]

分诊：入决策箱 + 四棱块

needs-user-decision · domain:devx · tooling · priority:p2 · type Task。

为什么进决策箱：两条候选都让门禁接受得更多（加第六类 / 收窄拒绝条件）。⛔ 门禁削弱在人工地板上，⭐ 即使论证是「净增强」也不例外 —— 恰恰因为「加一类让它更诚实」是削弱最容易被合理化的形状。本席不裁。

<!-- os-decision-facets -->

一句话问题：一个已发布 TYPE 面收窄（Promise< any > → 具体类型，能让消费者编译不过）声明 **BREAKING** 后，check-adr-0087-registration 的五个处置没有一个可用 —— 两个事实为假、两个被门禁明文拒绝、一个会往台账写假数据。可行的出路只剩去掉 **BREAKING** 标记。

选项 × 真实代价

	做什么	代价
1 加第六类 type-surface-only	按 unpublished 同样方式机械核验：包确实发布、diff 里 packages/spec 无变化、无 ADR-0087 形状移动	门禁多一条接受路径 ⇒ 多一个可被误用的出口。核验条件必须够硬
2 收窄 no-migration-prescription 拒绝	只对面向台账受众的处方开火，而非任何 FROM/TO 块	改的是既有拒绝的语义，⚠️ 可能放过 #6048 那类它本来就该抓的
3 维持现状	该类继续按先例走 minor + 散文记录	零动作。代价见 ③

四棱
① 长远合理性：ADR-0087 台账服务的是元数据升级者；本类的受众是 TypeScript 消费者，交付通道是他们自己调用点上的编译器。⇒ 让台账去承载它本来就是错配，1 与 2 都是在纠正错配。
② 业务拉动：零直接客户可感面。三张先例卡（#8140 / #11925 / #12034）都已按现状走完，消费者影响两种写法下都完整陈述了。
③ 防 AI 犯错 —— 分水岭，且方向反直觉。⭐ 现状的真实代价不是「某次改动没标对」，而是一整类真实编译破坏被系统性推离本仓的破坏性标记，只因为那个标记会把它路由进一个不属于它的台账。⇒ 门禁正在制造不诚实，而且侵蚀不可见 —— 每道门禁都是绿的。⛔ 但反面同样要说：加一个出口就是多一个能被下一个人用来绕开的出口。这一维两边都成立，是本卡真正难的地方。
④ 不扩散：1 是一条可机械核验的新分支；2 是改既有判据、面更小但回归风险更高（可能放过它本该抓的）。3 零成本。

推荐：⛔ 不裁。只提一条本席认为该被问的：若选 1，第六类的核验条件能不能硬到「一个真正的元数据变更绝无可能落进这一类」？ 卡面说它「mechanically checkable from the same diff the gate already reads」—— 若这句成立，1 就不是削弱而是分类精化；若不成立，1 就是开口子。这句话是否成立没有被验证过。

⭐ 置信缺口

没有人测过第六类会在现有 changeset 存量上匹配到什么。 卡面给了核验条件（包发布 + packages/spec 无变化 + 无 ADR-0087 形状移动），但没跑过它在历史 changeset 上的命中集。⇒

• 若只命中那三张已知的 client 收窄卡 ⇒ 分类精确，1 安全；
• 若还命中别的东西 ⇒ 每一个都是潜在的误放行，得逐个看。

这与 #13041 上本席写的是同一条纪律（#11457：新判据先量假阳性人群），此处同样适用，只是方向相反 —— 那里量的是会误红的，这里量的是会误绿的。误绿更危险。

低摩擦裁决格式：回「先跑一次命中集」（推荐）/「1 加第六类」/「2 收窄拒绝」/「3 维持」。

裁后执行段：先跑 ⇒ 留决策箱。裁 1 或 2 ⇒ 转 pm:queue（domain:devx），⚠️ 必须带 --self-test 用例，且 PR 需同时展示该抓的仍被抓（#6048 那类）。裁 3 ⇒ 关卡，⚠️ 但建议把「本类按 minor + 散文」写进门禁的拒绝文案，否则下一个人会再撞一次同样的死路。

---

Generated by Claude Code