Artifacts built by released 17.x tooling are REFUSED by the 17.2 runtime: retired-key tombstones fire at artifact parse, and no artifact-ingestion door runs the ADR-0087 conversion that exists for exactly this

[os-zhuang]

Found on a real isolated-posture dogfood boot (epic #12701 program; PM session session_01SVYmuhHW6qZmNBqciaS7BN, 2026-08-27).

Measured

• hotcrm@main built with its pinned released toolchain (@objectstack/cli 17.1.0) emits dist/objectstack.json carrying 75 occurrences of allowPurge/allowRestore — hotcrm source contains zero; the released builder injects the (then-legal) permission bits.
• Booting that artifact on the current framework main (packages/spec 17.2.0 — still the v17 line) through cloud's composed-artifact mode (OS_COMPOSED_ARTIFACT_URL) refuses the boot: invalid_type at permissions[5].objects.crm_campaign_member.allowPurge, the spec: retire the allowRestore / allowPurge permission props (ruled 2026-08-26; M2 anchor stays open, keys return with M2) #12497 retiredKey tombstone message verbatim ("Run os migrate meta --from 17 …").
• The mechanical fix EXISTS in the platform already: packages/spec/src/conversions/registry.ts (~line 8123) declares the allowRestore/allowPurge stripKeys conversion for stored permissions. The stored-metadata read path runs conversions (packages/metadata-protocol/src/protocol.ts, stored-row conversion machinery ~line 3916). The artifact-ingestion doors do not: neither the framework OS_ARTIFACT_URL path (whose artifact-boot-migration.ts covers physical schema drift only) nor cloud's composed path applies key conversions before the strict parse.
• Workaround used to unblock the dogfood run (proving the conversion is sufficient): stripping the two keys from a copy of the artifact makes the same boot succeed and the whole multi-org battery pass.

Why this is a v17-line compatibility break, not a v18 migration story

The removal shipped inside the v17 line (spec 17.1.0 → 17.2.0). Every already-built marketplace/composed artifact — including the one cloud's own acceptance builds at its pin — becomes unbootable the moment a deployment's runtime moves to ≥17.2, with no operator action available except hand-editing an artifact JSON (os migrate meta targets sources, not built artifacts). The epic-#12150 line's own upgrade promise ("smooth upgrade for existing installs") is what breaks.

Suggested shape (dev/triage to confirm)

Run the ADR-0087 conversions over a versioned artifact's metadata at every artifact-ingestion door (the artifact carries its authored specVersion/protocol handshake, so "older 17.x, convert forward" is decidable), the same way the stored-row read path already does — one policy, not per-door copies. Whether the seam lands in the framework (artifact parse) or each consumer (cloud composed loader) is the routing decision; the framework parse is the single place all doors share.

Repro is cheap: build hotcrm at its released toolchain, boot on current main via either artifact door.

[huangyiirene]

Triage: domain:cli · type Bug · pm:queue · target:v17 · priority:p0. This is the first p0 and the first release-board entry this seat has set in days, so both are justified explicitly below rather than asserted.

Routing, measured not guessed. The ingestion door the fix has to run at is packages/cli/src/utils/artifact-boot-migration.ts — located by search, with its consumer at packages/cli/src/commands/serve.ts and two existing self-tests beside it. packages/cli is domain:cli by the lane table. The other two files the card names are reference, not landing surface: packages/spec/src/conversions/registry.ts already declares the allowRestore/allowPurge stripKeys conversion (⇒ ⛔ no spec change expected), and packages/metadata-protocol/src/protocol.ts is the model to copy — the stored-row read path that already applies conversions.

⚠️ Two boundaries the dev must stop at rather than cross quietly:

• If "one policy, not per-door copies" turns out to require changing packages/metadata-protocol (engine lane) rather than just calling into it, that is a cross-domain PR — declare the full file surface in the claim and take the cross-domain exception path, ⛔ don't widen silently.
• If it turns out to need a packages/spec/src/** change after all, Clause-② fires on the path leg and it is not enqueueable below the contract-review tier. Expected not to, but check the diff rather than the plan.

Why priority:p0 — the binary question is not "is it severe" but "is it live", and it is:

• packages/spec 17.2.0 is published, not pending: objectui's packages/core depends on "^17.2.0" and resolves it. So the breaking runtime is already out.
• The removal shipped inside the v17 line (17.1.0 → 17.2.0). Every artifact already built by released tooling becomes unbootable the moment a deployment's runtime moves to ≥17.2 — hotcrm@main at its pinned @objectstack/cli 17.1.0 emits 75 occurrences of keys its own source contains zero of, because the released builder injects them.
• ⛔ No operator action exists. os migrate meta targets sources, not built artifacts; the only unblock found was hand-editing artifact JSON.
• Cloud's own acceptance builds at its pin are affected.

⇒ Live, released-surface, no workaround, self-inflicted by our own release. That is what p0 is for. ⛔ p0 does not exempt the same-file serial queue or the claim protocol.

target:v17 — three of the four blocking classes are met, not one: ① a defect users hit today on the released surface; ③ already-built artifacts in the wild, unreachable by any migration tool we ship; ④ unambiguously an apology in the release notes. The epic-#12150 line's own "smooth upgrade for existing installs" promise is the thing that breaks.

Scope note that should shape the fix — read #1883 before choosing strip-vs-convert. #12497 retired these keys with the M2 anchor left open: the keys return with M2 (#1883, pm:on-hold). So the conversion must be a versioned forward conversion keyed off the artifact's authored specVersion, ⛔ not an unconditional strip — an unconditional strip becomes wrong again the moment M2 lands and the keys are legal once more. The card's own suggested shape says this ("the artifact carries its authored specVersion/protocol handshake, so 'older 17.x, convert forward' is decidable"); the M2 return is the reason it is load-bearing rather than stylistic.

Cross-repo half, recorded not filed: cloud's composed-artifact path (OS_COMPOSED_ARTIFACT_URL) needs the same treatment and is a second door. ⛔ Not filed by this seat — cloud is outside this session's repo scope, and by the standing rule the consuming-side follow-up is filed by the seat that accepts this PR. Whoever does that should file it in cloud with a Blocked-by: pointing here, since the framework parse is the shared policy the cloud door should consume rather than reimplement.

Repro is cheap and stated: build hotcrm at its released toolchain, boot on current main via either artifact door. The workaround already run (stripping the two keys from an artifact copy → boot succeeds, full multi-org battery passes) is a positive control proving the conversion is sufficient, which is what makes this a queue card rather than an investigation.

Dedup run over the retired-key / artifact-conversion family: no twin. #12497 (closed) is the retirement that caused it; #1883 is the M2 project that will reverse it.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 2 — maintainer direct-dispatch channel (2026-08-27/28 live PM chat: 「继续」 following the dogfood report that filed this card; p0 jump per the triage grading)
Session: session_01SVYmuhHW6qZmNBqciaS7BN
Branch: claude/issue-12772-artifact-conversion-door
Worktree: objectstack-issue-12772
Domain: domain:cli
File surface: packages/cli/src/utils/ (artifact ingestion door + its self-tests), packages/cli/src/commands/serve.ts (consumer), .changeset/; packages/spec and packages/metadata-protocol are REFERENCE surfaces per the triage comment — touching either is a declared stop-and-report boundary, not a quiet widening (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: claude-fable-5 — clause-② content-limb judgment: accepting previously-refused 17.x artifacts changes accept behaviour, so the card dispatches at the contract-review tier regardless of the expected spec-free path (dispatch-gates run at current main reports no path-derived mandate for the cli surface, derived not recalled)
Clause-②: yes
Serial constraints cleared: none — no open in-flight claim or PR touches packages/cli/src/utils/ (checked the lane's open pm:dispatched set and git log origin/main -5 -- packages/cli/src/utils/); sibling fix #12803 (plugin-auth logger receiver) is merged and disjoint

---

Generated by Claude Code

[os-zhuang]

Dev claim: dispatched os-dev subagent of PM session session_01SVYmuhHW6qZmNBqciaS7BN (round 2 dispatch) — this comment is the dev seat's own claim, distinct from the PM claim above.
Branch: claude/issue-12772-artifact-conversion-door (pushed, empty probe)
Worktree: objectstack-issue-12772
File surface: packages/cli/src/utils/ (artifact ingestion door + self-tests), packages/cli/src/commands/serve.ts (consumer), .changeset/. packages/spec and packages/metadata-protocol are reference surfaces per triage — a diff touching either is a stop-and-report boundary.

---

Generated by Claude Code