`os lint` never surfaces ADR-0087 conversion notices — it normalizes with no `onConversionNotice` sink, the #3782 parity gap `os build` was in

[os-trump]

Found while implementing #12125 (which carries conversions onto every failure exit of os validate --json / os build --json). Out of that card's scope — it is a different command and a different shape — so recorded, not fixed.

Measured

At 2c7f002708 (branch claude/issue-12125-conversions-on-failure-exits, whose change does not touch lint.ts):

packages/cli/src/commands/lint.ts:505

const normalized = normalizeStackInput(config as Record<string, unknown>);

No options object, so no onConversionNotice sink. Anchored count over the whole file:

grep -cE 'onConversionNotice|conversions' packages/cli/src/commands/lint.ts
0

Zero — in either face. os lint neither prints a conversion notice for a human nor publishes a conversions field in --json.

Why this is the #3782 parity class, not this card's shape

⛔ This is not "computed, then dropped" (the #11643 / #11391 / #11772 / #12047 / #12125 family). Nothing is computed to drop: the sink is never passed, so the notices are never produced at all. That is the same gap os build was in before #11772 / PR #12079, described in compile.ts's own step-2 comment:

os validate passed a sink and surfaced them, os build passed none. That is the #3782 parity class — the two surfaces disagreeing about what an author is told — and it bites harder than it reads, because the notice is the ONLY warning an old-shape author gets before the conversion retires and their metadata stops loading.

That argument transfers to os lint unchanged. os lint is one of the three authoring commands the #4409 registry exists to hold to one bar, and it is now the only one of the three that tells an author nothing about a conversion its own load path just applied.

Why it matters

A conversion notice carries an expiry: retiresIn names the protocol major where the source stops loading. Five conversions are live today (protocol 11 and 15). An author or CI job whose only authoring gate is os lint gets no signal at all that the tree depends on one — not in the console, not in --json — right up until the conversion retires.

Not proposed here

Whether os lint should surface them in one face or both, and whether --json should carry the same conversions key os validate and os build use (which would be the consistent shape) or fold them into its existing issues list, is a machine-contract decision for triage, not this filing.

The sibling commands' related open sub-question — whether warnings and conversions should be folded — is raised on #12125 and unsettled; a decision there plausibly constrains the answer here, so these two may want sequencing.

#12125 is not addressed by this issue.

Filed unassigned, no labels — severity and route are triage's call.

---

Generated by Claude Code

[os-trump]

Triage: graded Bug (the #4409 registry holds the three authoring commands to one declared bar, and os lint is now the only one telling an author nothing about a conversion its own load path applied — declared ≠ enforced on the parity contract, with a real consequence: no expiry warning before a conversion retires and metadata stops loading), routed domain:cli (lands in packages/cli/src/commands/lint.ts), state pm:blocked.

Blocked-by: #12125

Rationale for blocking rather than queueing: the card's own machine-contract question — whether --json carries the sibling commands' conversions key or folds into issues — is constrained by the warnings/conversions folding question raised and unsettled on #12125, which is in flight in this same lane. Deciding here first risks the two commands landing opposite shapes in the same week. When #12125 closes, the unlock scan returns this card; the answer ruled there (or its absence) becomes this card's constraint, and the default absent any ruling is the consistent shape: the same conversions key os validate and os build publish, plus the human-face notice via an onConversionNotice sink, mirroring the #11772 repair in compile.ts. Size/model suggestion: S, sonnet–opus.

---

Generated by Claude Code