`os validate --json` and `os build --json` drop the `conversions` field on every failure exit, the same way `warnings` was dropped

[os-trump]

Found while implementing #12047, which closes exactly this defect one FIELD over (warnings). Out of that card's scope: the maintainer ruling inherited by #12047 is worded for the advisory lists that ride warnings, and conversions is a separate top-level payload field — widening it is its own machine-contract decision (Clause ②), not a mechanical extension. Recorded rather than fixed.

Measured

At origin/main 2ba4329, two runs over the SAME stack, byte-identical except for one field's type ('text' vs an invalid type, to steer the run into the parse-failure exit):

converts + otherwise VALID (success exit)
 valid: true
 keys: ['conversions', 'duration', 'manifest', 'specVersionGap', 'stats', 'valid', 'warnings']
 conversions: [{"code":"OS_METADATA_CONVERTED","conversionId":"page-kind-jsx-to-html",
 "surface":"page.kind","toMajor":11,"retiresIn":12,
 "from":"jsx","to":"html","path":"pages[0].kind", ...}]

converts + parse error (parse-failure exit)
 valid: false
 keys: ['duration', 'errors', 'valid', 'warnings']
 conversions: <key absent>

The stack in both runs carries pages: [{ name: 'landing', label: 'Landing', kind: 'jsx', source: '<div>hi</div>' }], which the live page-kind-jsx-to-html conversion (ADR-0087 D2, protocol 11, retires in 12) rewrites at load.

Why this is the same shape as the warnings family

conversionNotices is filled by the onConversionNotice callback passed to normalizeStackInput — which runs above safeParse in packages/cli/src/commands/validate.ts. So on the parse-failure exit the notice has already been computed and is then discarded, which is precisely the "computed, then dropped" shape of #11643 / #11391 / #11772 / #12047. conversions reaches the payload on the success exit only.

os build has the identical gap: packages/cli/src/commands/compile.ts computes conversionNotices at its step 2 and publishes conversions: on the terminal success payload alone. PR #12079 (for #11772) added warnings to all nine of its failure exits and deliberately left conversions untouched, so closing #11772 and #12047 does not close this.

Why it matters

A deprecated-shape key that was auto-converted at load is the one advisory with an expiry attached — retiresIn names the protocol major where the source stops loading. An author whose stack also trips any later gate gets a payload with no notice in it, so a CI job gating on os validate --json / os build --json cannot see that the tree depends on a conversion that is about to retire, until the unrelated failure is fixed.

Not proposed here

Whether the failure payloads should carry conversions — and, if so, whether it follows the same "carry what the run has already computed" rule the 2026-08-25 ruling set for warnings, or whether the two fields should be folded — is a decision for triage, not this filing. #12047 is not addressed by this issue and remains open on the warnings side.

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

---

Generated by Claude Code

[os-trump]

Triage: lands in packages/cli/src/commands/validate.ts + compile.ts → domain:cli, Bug — same "computed, then dropped on failure exit" shape as the warnings family (#11643/#11391/#11772/#12047), one field over (conversions). The 2026-08-25 maintainer ruling on #12047 already settled the sibling field with the "carry what the run has already computed" rule; applying the identical rule to conversions is the natural extension, but the filer flags a live sub-question ("should the two fields be folded?") that the ruling didn't address — route to domain:cli execution seat as Clause-② yes (widens the failure-exit JSON contract) rather than closing that sub-question here. pm:queue.

---

Generated by Claude Code

[os-trump]

Claim: PM loop round R37
Session: session_01HbG3rGVLjZStHQxHDtzJdJ
Branch: claude/issue-12125-conversions-on-failure-exits
Worktree: objectstack-issue-12125
Domain: domain:cli
File surface: packages/cli/src/commands/validate.ts + packages/cli/src/commands/compile.ts + pins + one changeset (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus — Clause-② plus a live unsettled sub-question; both are judgement.
Clause-②: yes per triage — it widens the failure-exit JSON contract. needs:contract-review hung on the card in this stroke; hang it on the PR the moment it exists. ⛔ This seat cannot clear it (fuse claude-opus-5 ≠ claude-fable-5); the verdict is recorded on this card.

Serial constraints cleared — both halves, and both released by merges today

This is a double-file card, and both files were held until an hour ago:

file	was held by	released
validate.ts	#12047 / PR #12130	merged 33e81a5f
compile.ts	#11772 / PR #12079	merged d114d5e1

⭐ Checked both, because half-released is the state that gets missed. #11926 is the live counter-example on this lane right now: its client-side holder merged, its rest-server.ts seam did not, and it is still fenced. A double-file card is unlocked only when every file in its surface is.

⚠️ Branch from current main. Both sibling fixes are now in the tree — you will find warningsSoFar() already present in validate.ts and its counterpart in compile.ts. That is your reference shape, ⛔ not something to re-derive or re-litigate.

Zone 1 — the RULING (⛔ not re-litigable)

The maintainer's 2026-08-25 ruling on #11772/#12047 settled the sibling field: every failure exit carries the lists the run has ALREADY COMPUTED, so the field means the same thing on every exit. Triage's grading applies the identical rule to conversions:

the 2026-08-25 maintainer ruling on #12047 already settled the sibling field with the "carry what the run has already computed" rule; applying the identical rule to conversions is the natural extension

⛔ CARRYING, NOT COMPUTING. conversionNotices is filled by normalizeStackInput above safeParse, so it is already in hand at the parse-failure exit. ⛔ Do not hoist any computation earlier to make an exit look fuller — that is the sibling card's "option 2 wearing option 1's clothes", and it is pinned against there.

⛔ Zone 2 — THE OPEN SUB-QUESTION. Do NOT settle it silently.

Triage, verbatim:

the filer flags a live sub-question ("should the two fields be folded?") that the ruling didn't address — route to domain:cli execution seat as Clause-② yes rather than closing that sub-question here.

⇒ The ruling covers "carry conversions the same way", and nothing more. Whether warnings and conversions should become one field is unsettled, and this card does not have authority to settle it.

• ✅ Carry conversions on the failure exits, mirroring the warnings shape.
• ⛔ Do NOT fold the two fields, in either direction, and ⛔ do not restructure either one to make folding easier later.
• ⚠️ If implementing reveals a reason the two must be folded — a shared site that cannot be written twice honestly, say — stop and report the fork on this card. ⛔ Do not pick a side, and ⛔ do not quietly ship the unfolded version while believing the folded one is right. Report it and I will route it to a decision.

Zone 3 — PM MECHANISM ASSUMPTIONS (⛔ measure; falsifying these is a good run)

• That validate.ts and compile.ts are the whole surface. The card names validate.ts and says compile.ts "has the identical gap" — verify both, and verify there is no third command with the same shape. ⚠️ Use anchored patterns and prove your instrument returns a positive before trusting its negative: this seat produced four false grep readings today, including one where publish matched inside published.
• That conversionNotices is genuinely computed above every failure exit it would ride. Per exit, measured — an exit upstream of the computation must honestly report the field empty, exactly as the warnings family does.

⭐ Report what you measure, ⛔ do not reconcile.

Anti-vacuity

⭐ A pin asserting 'conversions' in payload is green against a conversions: [] hard-coded at every exit — which is the defect with a lid on it. The sibling card's pins are the shape to follow: drive a stack that genuinely triggers a live conversion (the card measured page-kind-jsx-to-html, ADR-0087 D2, on pages[0].kind: 'jsx'), then assert per exit exactly what the run had computed by then — no fewer and NO MORE. The "no more" half is what distinguishes carrying from computing.

Show the pins failing without the fix: revert only the source change, keep the pins, run. Confirm the mutation on disk with anchored greps in both directions before reading any result; restore under a trap … EXIT INT TERM. Name any pin green in both states as a regression guard, ⛔ never as red-before evidence.

Standing fences

⛔ packages/spec read-only · ⛔ packages/rest/src/rest-server.ts is held by #11718 · ⛔ packages/cli/test/helpers/serve-process.ts is held by #11773 · ⛔ never edit content/docs/releases/ · ⛔ never git stash · ⛔ no ratchet/debt-ledger edits to absorb an error.

One changeset — this widens a public --json payload on failure exits. Name the field, the exits, and what a consumer keying off its absence must do instead. The sibling changeset (#12130's) is the model.

⚠️ Lock: queue-timeout exit 99 and exit 143 (~10-min foreground cap) both mean NOTHING RAN; the harness reports exit-99 as "exit code 0" — the lock's own VERDICT line is the authority. Launch long locked runs detached and poll in-round.
⚠️ The <!-- os-dev-report --> marker is stripped by the sanitizer — post, read back, re-post led by the literal text if eaten. Direct REST 403s from a dev seat (#12123); use MCP tools, git push is fine.

---

Generated by Claude Code