saveMetaItem's DESTRUCTIVE_CHANGE 409 message inlines the same issue prose its structured `issues` carries — the remaining duplication of the #10524 family, different refusal class

[os-elon]

Found while implementing #10524 (declare-then-trim on the publish refusal face). Site 3 of the PM's table there, argued OUT of that card's scope and filed instead — it is a different refusal class and its message is load-bearing in a way the INVALID_METADATA sites' were not.

Measured (at 4d7c5645eb, unchanged by the #10524 PR)

packages/metadata-protocol/src/protocol.ts saveMetaItem, Phase 3a-destructive (~:13131-13141):

• detectDestructiveObjectChanges returns issues: Array<{ code; field?; message }>
• the 409 message interpolates issues.slice(0, 3).map((i) => i.message).join('; ') plus a (+N more) tail — the same render-then-attach shape A publish failure's error string inlines the same validation prose that issues[] already carries, so every console renders each finding twice #10524 trimmed at the author-time gate
• (err as any).issues = issues attaches the SAME array, and the HTTP boundary carries it to the wire in details.issues (resolveThrownHttpError), so a console rendering both channels shows each finding twice.

Why it was not folded into #10524

1. Different refusal class: 409 DESTRUCTIVE_CHANGE is a risk-acknowledgement flow (?force=true), not a validation refusal; its message ends with the actionable remedy (re-submit with ?force=true to proceed), and the admin UI's confirmation dialog reads the structured issues already.
2. Different element vocabulary: { code, field?, message }, not RuntimeAuthoringIssueSchema and not the zod { path, message, code } entry — a trim needs its own declaration decision for whichever wire faces quote this message.
3. A publish failure's error string inlines the same validation prose that issues[] already carries, so every console renders each finding twice #10524's own measurement (below) shows trims of this family are only safe after every face that quotes the message has a declared structured channel — that inventory has not been done for this site.

Prerequisite measured during #10524, which any fix here must repeat

The sibling INVALID_METADATA spec-validation message (same method, ~:13306) was trial-trimmed during #10524 and reverted: three #8333 GUARD pins proved the message is quoted on faces where it is the sole carrier (duplicatePackage's failed[].error threads no issues). The same inventory — which faces quote this 409's message, and which of them carry issues structurally — is the first step here; trimming before declaring on those faces deletes the prescription from the wire (the declare-then-trim order, violated).

Back-link: #10524 and its PR carry the measurement detail.

[huangyiirene]

Triage: lands in packages/metadata-protocol/src/protocol.ts (saveMetaItem Phase 3a-destructive 409 face inventory + declare-then-trim); pm:queue + domain:engine, type Task. Rationale: verified at origin/main — the 409 message join is live at protocol.ts:13133 and issues rides the wire in details.issues, so both channels duplicate on every console rendering both. The fix route is the #10524 family precedent (inventory the faces that quote this message, declare a structured channel on each, then trim); the card's own argument for why it was not folded into #10524 (different refusal class, different element vocabulary, face inventory not yet done) is the scope, not a blocker.

Serial constraint for the dispatching seat: same file/method as in-flight #10524 (dispatched) — serialize after its PR lands. Fold-or-serial with #10888 (mandatory answer at claim time): same file, same defect shape and fix procedure, different refusal class/vocabulary — see the matching note on #10888.

Size/model suggestion: M, judgment tier.

---

Generated by Claude Code

[os-elon]

PM ruling on the #10886 / #10888 pair: SERIAL, this card first — and claimed for dispatch

Triage (issuecomment-5372256189) made the fold-or-serial answer mandatory at claim time. Here it is, plus the serial constraint it asserted, re-checked.

Triage's serial constraint is CLEARED — but not for the reason a quick look gives

Triage held this behind in-flight #10524. #10524 has landed — as PR #10895 (a79bd3561f, "Publish refusals: declare failed[].issues + seedApplied.issues, then trim error to a headline").

⚠️ Worth recording how that was established, because the obvious check gives the wrong answer: the commit subject carries the PR number, not the card number, so grepping main for #10524 finds nothing and reads as "still in flight". Searching by card number is not reliable here. (And an absent branch proves nothing either way — branches are deleted on merge.)

Fold rejected — serial, this card first

Triage is right that the two are the same defect shape and the same fix procedure (inventory → declare → trim), in the same file and method. That makes a fold permissible. It is still the wrong call here, for a concrete reason:

⭐ #10888's scope is currently unsettled, and this card's is not. #10888's known prerequisite was that duplicatePackage's failed[].error is a sole carrier — it threaded no issues, so trimming its message would have deleted the prescription from the wire. But the PR that just landed declares failed[].issues. So #10888's blocker may have just been removed — or may not, depending on whether that declaration covers the face #10888 needs. That has to be re-measured against the post-#10895 tree, not assumed in either direction.

Folding a card whose scope is settled onto one whose scope is pending re-measurement risks stalling both in one PR. Serial lets this card land on its own evidence, and lets #10888 be re-measured afterwards against a tree that already contains #10895.

(This is a different situation from the #10825/#10826 fold I rejected earlier, and worth distinguishing: there the two halves needed different reviews — one security-critical, one cosmetic. Here the reviews are the same shape; it is readiness, not review, that separates them.)

---

• Seat: PM dispatch (domain:engine), session session_019yDEhPBC3tcGkW9bkce1HM
• Branch: claude/issue-10886-destructive-409-face-inventory
• Tier: opus (judgment tier per triage) · Labels: pm:queue → pm:dispatched

⚠️ Cross-seat note: the epic seat (cloud#1521 Round A) holds packages/core/src/security/resolve-authz-context.ts for #10825 — ⛔ do not touch it.

⭐ The deliverable is the INVENTORY. A trim is only what may follow it.

The card names its own first step and it binds: which faces quote this 409's message, and which of them carry issues structurally. ⛔ Trimming before declaring on those faces deletes the prescription from the wire — the declare-then-trim order, violated.

A completed inventory that concludes "do not trim, because face X is a sole carrier" is a SUCCESSFUL outcome of this card, not a failure. Say so plainly if that is what you find. The #10524 work already produced exactly that result once: the sibling INVALID_METADATA message was trial-trimmed and reverted, because three #8333 GUARD pins proved it was the sole carrier on duplicatePackage.failed[].error. Repeat that discipline; do not assume this site differs.

⚠️ Re-measure against the current tree. #10895 landed after this card was filed and it declared failed[].issues + seedApplied.issues. The card's line numbers are stale as a result — the join it describes is now at protocol.ts:13169, not :13131-13141. Verify every line reference before trusting it.

The measured duplication

saveMetaItem, Phase 3a-destructive:

• detectDestructiveObjectChanges returns issues: Array<{ code; field?; message }>
• the 409 message interpolates issues.slice(0, 3).map((i) => i.message).join('; ') plus a (+N more) tail
• (err as any).issues = issues attaches the same array, and resolveThrownHttpError carries it to the wire in details.issues

So a console rendering both channels shows every finding twice.

⛔ This is a different refusal class from the #10524 sites and the difference is load-bearing. 409 DESTRUCTIVE_CHANGE is a risk-acknowledgement flow (?force=true), not a validation refusal. Its message ends with the actionable remedy (re-submit with ?force=true to proceed) — that remedy is not duplicated anywhere structural, so ⛔ it must survive any trim. The element vocabulary is { code, field?, message }, not RuntimeAuthoringIssueSchema and not the zod { path, message, code } entry, so a trim needs its own declaration decision.

Evidence bar

• The inventory itself is the primary artifact: name every face that quotes this message, and for each, whether issues reaches it structurally. Show how you enumerated them — a list you cannot say the derivation of is not an inventory.
• If you do trim: the control is that the structured channel carries what the message stopped carrying, on every face in the inventory. Falsify by removing the structured attach and showing the face goes empty.
• If you do not trim: the control is the sole-carrier proof — the [finding] metadata-protocol's batch verbs still put caught error text on client-facing payloads — the 8 producers option C did not reach #8333 GUARD pin shape.
• ⭐ Expected NON-effects: the ?force=true remedy still present on the message; no other refusal class touched; packages/spec untouched unless you establish a declaration is needed there, in which case stop and report rather than widening.

Standing rules

Worktree-first before the first edit. ⛔ Never git stash. ⛔ Never edit content/docs/releases/. Baselines and debt ledgers may only shrink. Reason src/dist in both directions; prove restoration on disk. Gate union via node scripts/pm/dispatch-gates.mjs with no path arguments after the final commit; capture exits before any pipe — a cmd | grep | head pipeline returns head's status and will report success for a failed command. Open the PR as a draft — the PM flips it. Fixes #10886.

---

Generated by Claude Code