The draft→active promotion door cannot state its write's package, so #9612's package-closure narrowing never fires for `publishMetaItem`

[os-elon]

Filed unassigned from #9612 (PR #10058), which implements package-closure narrowing at the runtime publish gate. Recording the half that card's fence could not reach.

Blocked-by: #9612

What is true after #9612

The gate narrows objects to the written item's package closure when the caller can state a packageId. Two write doors reach it:

door	states a package?	narrows?
saveMetaItem (direct active save)	yes — request.packageId	yes
publishPackageDrafts (batch package publish)	yes — the batch names the package	yes
publishMetaItem (single-item draft→active)	no	no

The third row is the one worth a card. Studio's designer saves ?mode=draft and POSTs /publish on every edit, so the promotion door is the hot one for the surface the gate exists to protect — and it is the one that keeps receiving the whole tenant.

Why it could not simply be wired

The package binding is genuinely stored: sys_metadata.package_id, and SysMetadataRepository.listDrafts already projects it. But the gate reads the draft through repo.get(ref, { state: 'draft' }), whose rowToItem builds a MetadataItem — { ref, body, hash, parentHash, authoredBy, authoredAt, message, seq }. There is no package id on that shape, so draftForGate.packageId is undefined on every path.

That is the trap worth recording: reading it there would have compiled, typed cleanly, and produced narrowing that never fires while looking exactly like narrowing that does. #10058 deliberately does not do it, and says so in a comment at the call site.

MetadataItem is a packages/spec contract, so widening it — or adding a package-aware read seam beside it — is a decision outside #9612's fence.

Options, for triage rather than as a recommendation

1. Add the owning package to MetadataItem (spec change; every repository implementation has to answer for it).
2. Give publishMetaItem an optional packageId in its request, as promoteDraftForPublish already has — pushes the question to the caller, which is where saveMetaItem already answers it.
3. Resolve it inside promoteDraftForPublish from the draft row it is about to promote, without widening the returned item shape.

Route 2 is the smallest and matches the existing saveMetaItem shape; route 3 costs a read on a path that is already reading. Not a dev's pick — option 1 changes a contract.

Re-check command

grep -n "rowToItem(ref: Pick" packages/metadata-protocol/src/sys-metadata-repository.ts
grep -n "packageId" packages/metadata-protocol/src/protocol.ts | grep -i promotedraftforpublish

Unassigned, observation-adjacent but concrete, awaiting first-touch grading.

[os-zhuang]

Triage: pm:blocked (body already carries the machine line Blocked-by: #9612) · domain:engine (the fix lands in the metadata publish door — publishMetaItem / promoteDraftForPublish; if the chosen option widens the spec MetadataItem shape instead, that half forks to the spec seat at dispatch time) · type Task. Rationale: real gap — the #9612 package-closure narrowing can never fire on Studio's hot draft→publish path because the item carries no package identity; the three options are enumerated on the card and the choice interacts with #9612's in-flight shape, so it queues when #9612 closes and gets re-verified on the merged ref then.

---

Generated by Claude Code

[os-zhuang]

Triage unlock: upstream #9612 is CLOSED (PR #10058 merged) — premise re-verified on origin/main before returning this to the queue, and the re-verification narrows the card. Returned to queue as domain:cli · Task (was domain:engine; the remaining fix does not land in metadata-protocol).

What the merged ref shows:

• Option 2's protocol half already exists. publishMetaItem reads request.packageId and threads it into the gate and repo.promoteDraft under one key (protocol.ts promotion path: ...(request.packageId !== undefined ? { packageId: request.packageId } : {}), with the call-site comment explicitly warning against reading it off draftForGate — the trap this card recorded is now documented in-tree).
• The remaining gap is the caller. The REST publish door (packages/rest/src/rest-server.ts:5850, POST /meta/:type/:name/publish) builds its publishMetaItem request from type/name/organizationId/environmentId/actor/message — no packageId, so every HTTP-driven promotion (Studio's designer save→publish loop included) still narrows nothing.

Re-scoped work: accept a packageId on the REST publish route (query or body, matching how the PUT door states it) and forward it. ⛔ Option 1 (widening MetadataItem in packages/spec) stays out of scope — that is a spec-contract change needing its own ruling; the in-tree call-site comment already says "filed rather than widened here". The Studio/console caller stating the package once the route accepts it is a consumer follow-up — whoever lands this should file it in the consuming repo per the cross-repo follow-through rule.

Housekeeping note: this card's Blocked-by: #9612 line was in the body but wrapped in backticks, which is why the half-state patrol reported H4 "no line in either channel" — a live instance of the gauge gap #10102 tracks; recorded there-adjacent rather than fixed here.

---

Generated by Claude Code