[finding] An accept-set narrowing owes a `**BREAKING**` banner in `core` but not in `platform-objects` — and the ADR-0087 classifier reads the banner

[claude]

Two contract reviews in the same round, on PRs of the same shape (an accept-set narrowing shipped as minor), reached opposite answers about whether the changeset owes a **BREAKING** banner — each by correctly following the nearest precedent in its own package. The packages have drifted, and nothing in the tree reconciles them.

The two readings, both measured

@objectstack/platform-objects — no banner. PR #16296 declares a valueDomain on two published isSystem columns; a timezone value the shipped build accepts today (Mars/Olympus, UTC+8, China Standard Time) is refused after it — proved by runtime ablation against both legs' dist. Its changeset says "A NON-BREAKING ADDITION" and carries no banner. Precedent #14238 (6acb37eb9, .changeset/org-hierarchy-timezone-columns.md) shipped the identical shape in the same package: minor, ADR-0087 not-required marker, no banner.

@objectstack/core — banner mandatory. PR #16363 makes kernel.use() enforce PluginSchema; eight declared keys that load today are refused after it. Precedent d8024f0 — narrowing the same Plugin.type key — opens its changeset with:

**BREAKING** accept-set narrowing on a published type, shipped as minor under the repo's launch-window convention for breaking changes.

4635f3e (HotReloadConfig.stateStrategy refusing two values) is the same shape and carries the banner too.

Why the rules as written do not decide it

AGENTS.md:1021-1022 defines the trigger narrowly:

Breaking changesets must carry their migration. If the change removes or renames anything an author can write (a spec key, an export, a config field), the changeset body must state the FROM → TO mapping and the one-line fix

A value-set narrowing removes nothing and renames nothing — no key, no export, no config field disappears. By that text platform-objects is right. But d8024f0 shows core treating the same act as breaking anyway, and scripts/check-changeset-no-major.mjs:41-42 confirms the level cannot carry the signal (major is refused during the launch window, so breaking-ness rides on the banner plus the ADR-0087 disposition, not on the bump).

⇒ The banner is the only channel for "this narrows an accept set", and whether a narrowing must use it is decided today by which package you happen to be in.

Why this is worth a card rather than a per-PR judgement

⛔ It is not a defect in either PR — each followed its own package's precedent, and both were reviewed and verified on that basis.

⚠️ The cost is that check-adr-0087-registration classifies from the banner. A narrowing shipped without one is classified non-breaking, so the gate that would ask for a migration note never asks. That is a silent path, and it is the reason this is filed rather than left as a note on two PRs that have already landed the question.

What a fix would look like (⛔ not a recommendation — the options are the deliverable)

• A — extend the written definition. Amend AGENTS.md:1021-1022 so "removes or renames" also covers "narrows the set of values an author may write", making the banner mandatory for a narrowing everywhere. Cost: platform-objects' existing precedent becomes retroactively non-conforming; someone must decide whether that matters.
• B — keep the narrow definition and make core's practice explicit as a stricter local convention. Cost: the two packages stay divergent by design, and a reviewer must know which lane they are in — which is exactly the state that produced this card.
• C — make the classifier stop depending on prose. Have the clause-② declaration (already machine-readable in the fixed spelling, and already enforced on both carriers by check-clause2-carriers) feed the ADR-0087 classification, so a Clause-②: yes PR cannot be classified non-breaking by omitting a banner. Cost: couples two gates that are independent today.

Re-check commands

git show d8024f0:.changeset/core-plugin-type-closed-set.md | head -20     # the BREAKING banner
git show 6acb37eb9:.changeset/org-hierarchy-timezone-columns.md           # same shape, no banner
sed -n '1021,1022p' AGENTS.md                                            # the written definition
sed -n '41,42p' scripts/check-changeset-no-major.mjs                     # why the level cannot carry it

Sources: contract reviews on PR #16296 (comment 5562601809) and PR #16363, both this round. Related: #14238, #16049, #15872.

---

Generated by Claude Code

[claude]

⛔ Correcting this card's framing 25 minutes after filing it — it is not a divergence. There is a governing rule, repo-wide, and one package's precedent does not follow it.

domain:engine dispatching seat, session session_01ARYe3yQTQCUFm5qPYNgKaJ, 2026-09-06T22:4xZ. I filed this saying two packages had "drifted apart" and offered A/B/C as if the convention were undecided. That was wrong, and the reason is a citation I did not look for.

The text that decides it

scripts/check-changeset-no-major.mjs:55-66 — repo-wide, not package-scoped, verified verbatim:

End condition: at GA … From that point a required member on a published interface, an accept-set narrowing, or any compile-breaking change to implementers grades major … Until then it is NOT the carrier, and that is the whole cost of the window: a breaking change ships as minor, so the bump level tells a consumer nothing about whether the release breaks them. The mandatory information carriers for breaking-ness in the meantime are the **BREAKING** banner the author writes in the changeset body and the ADR-0087 migration-ledger disposition (check-adr-0087-registration.mjs refuses a declared breaking change that states neither). They are not documentation niceties

It names "an accept-set narrowing" in those words, and it names the banner as mandatory. AGENTS.md:1021-1022 ("removes or renames") is a narrower statement about migration mappings and does not override it.

⇒ @objectstack/core's practice (d8024f0, 4635f3e) conforms. @objectstack/platform-objects' precedent #14238 (6acb37eb9) does not — it is an accept-set narrowing shipped with no banner and no disposition.

What survives from the original filing, and it is the real defect

⭐ The gate cannot catch a missing banner, by construction. check-adr-0087-registration.mjs:572 classifies from the author's own declaration:

if (/\*\*BREAKING/i.test(parsed.body) || /^\s*BREAKING[ -]CHANGE/mi.test(parsed.body)) signals.push('BREAKING');

No banner ⇒ classified non-breaking ⇒ the gate reports "1 non-breaking changeset(s) seen" and never asks for the disposition. So a narrowing that omits the banner sails through both gates, and the consumer's CHANGELOG.md states the opposite of the truth. That is what wants fixing, and it is option C from the original filing — now the only live option, not one of three.

⛔ Options A and B are withdrawn. A ("extend the written definition") is moot: the definition already covers it. B ("keep them divergent by design") contradicts the text.

Revised ask

1. A predicate that does not depend on the author's honesty. The clause-② declaration is already machine-readable in the fixed spelling and already enforced on both carriers by check-clause2-carriers. A PR declaring Clause-②: yes on limb 2 (an accept-set narrowing, as opposed to a limb-1 additive widening) cannot legitimately be classified non-breaking — so that declaration can feed the ADR-0087 classification instead of the banner regex. ⚠️ The limb-1/limb-2 distinction matters: a purely additive widening declares Clause-②: yes too and owes no banner — PRs fix(core): plugin startup elapsed time is durationMs, the unit-bearing name its spec contract declares #16057, feat(objectql): publish DriverConnect, DatasourceUnavailable and SummaryRecompute error codes as constants #16308 and feat(objectql): the two transaction-seam refusals publish their error code as a constant #16326 are exactly that shape and are correct without one.
2. Decide what to do about No platform object carries a timezone, so every app that computes a date boundary has to invent one — and each will invent it differently #14238, which is landed and non-conforming. Probably nothing — but it should be a decision, not an oversight, because it is the precedent the next platform-objects author will copy.

Evidence trail from this round

• PR feat(core): enforce PluginSchema at kernel.use() (#16049) #16363 — core, accept-set narrowing, no banner ⇒ ruled NOT PASSED (5562633197), text-only remedy dispatched.
• PR feat(platform-objects): sys_job.timezone and sys_report_schedule.timezone are validated against the IANA domain #16296 — platform-objects, accept-set narrowing, no banner ⇒ I released it, then reversed myself 40 minutes later on this same text (5562629666). It is back in draft and out of the merge queue; verified by content on origin/main that nothing landed (0 hits, firing control 5).
• Counts: d8024f0's changeset carries 2 × BREAKING + 1 × adr-0087; both feat(platform-objects): sys_job.timezone and sys_report_schedule.timezone are validated against the IANA domain #16296's and feat(core): enforce PluginSchema at kernel.use() (#16049) #16363's carry 0 of each.

⛔ Still ungraded, still not this seat's to grade.

---

Generated by Claude Code