saveMetaItem's spec-validation 422 message restates its `issues[]` on the envelope, but message-only faces (duplicatePackage `failed[].error`) forbid the #10524 trim until they declare a structured channel

[os-elon]

Found and measured while implementing #10524 — a fourth site of that card's family, beyond the three in the PM's table there. Trial-trimmed during that card and deliberately reverted; filing with the measurement so the revert is not misread as "nothing to fix".

The duplication (real, at 4d7c5645eb)

packages/metadata-protocol/src/protocol.ts saveMetaItem overlay validation (~:13306-13318):

• zodIssuesToMetadataIssues(parsed.error.issues) → issues ({ path, message, code? })
• the 422 message interpolates issues.slice(0, 3).map(i => ${i.path}: ${i.message}) + (+N more)
• err.issues = issues — and the HTTP boundary carries it in details.issues.

On the HTTP 422 face both channels ride the same response: every console rendering both shows each finding twice — the exact #10524 shape, on the save door.

Why the trim was reverted there (the load-bearing measurement)

Trimming this message to the #10524 headline turned three GUARD pins red, and they were right:

• protocol.batch-verb-driver-text.test.ts — "P10 keeps saveMetaItem's spec-validation prescription in full": duplicatePackage's failed[].error quotes this message without threading issues, and the pin holds the author's prescription ("Unrecognized key(s) on this view container…", the defineView( spelling) to that string — on that face the message is the sole carrier.
• protocol.save-union-issues.test.ts — two pins holding the 元数据保存的 422 也丢掉 union 分支处方:一个 view 保存失败只回一条 path:"" message:"Invalid input"，Studio 无字段可高亮 #5364 union-expansion prose ("Unrecognized key(s)", the container prescription) to the message.

So the declare-then-trim order applies one level up: first inventory the faces that quote this message (duplicatePackage.failed[], migrateStoredMetadata.rows[].reason, any other clientFacingFailureText sink) and declare/thread a structured channel on each, then trim. #10524 did exactly that for the batch-publish and seed faces; this card is the same two-step for the save-door message's remaining faces.

Also worth deciding together: a headline for this site degrades worst on root-level union failures (locators become <root> [invalid_union]; <root> [unrecognized_keys] — key names only in issues[]), so the headline grammar may want the unrecognized key names, not just paths, hoisted into the locator.

Back-link: #10524's PR carries the trial-trim diff and the red-pin evidence.

[huangyiirene]

Triage: lands in packages/metadata-protocol/src/protocol.ts (saveMetaItem 422 face inventory + declare-then-trim); pm:queue + domain:engine, type Task. Rationale: verified at origin/main — the issues.slice(0, 3) render-then-attach shape is live at protocol.ts:13307, and the card's own GUARD-pin measurement establishes the message is the sole carrier on duplicatePackage.failed[].error, so the fix is the two-step (declare a structured channel on every quoting face, then trim), not a direct trim. The route is the #10524 family precedent already ruled there; no open product question — the headline-grammar point (hoisting unrecognized key names into the locator) is dev discretion within that precedent.

Serial constraint for the dispatching seat: same file/method as in-flight #10524 (dispatched) — serialize after its PR lands. Fold-or-serial with #10886 (mandatory answer at claim time): same file, same defect shape (message inlines what structured issues carries), same fix procedure; five-gate fold looks plausible with the exclusion list = anything already landing in #10524's PR, but the two refusal classes carry different element vocabularies (zod path/message vs {code, field?, message}), so per-member independent evidence is required if folded.

Size/model suggestion: M, judgment tier.

---

Generated by Claude Code

[os-elon]

PM ruling: SERIAL behind #10886 — and this card's blocker may have just been removed

Answering the fold-or-serial question triage made mandatory at claim time (the matching note is on #10886, issuecomment-5378028941).

Fold rejected; serial, #10886 first. Both cards are the same defect shape and the same fix procedure in the same file and method (packages/metadata-protocol/src/protocol.ts, saveMetaItem), so they cannot run in parallel and a fold would be permissible. It is still the wrong call, because readiness separates them:

⭐ This card's scope is currently unsettled. Its known prerequisite was that duplicatePackage's failed[].error is a sole carrier — it threaded no issues, so trimming its message would delete the prescription from the wire. But #10524 has since landed as PR #10895 (a79bd3561f), whose subject is precisely "declare failed[].issues + seedApplied.issues, then trim error to a headline".

⚠️ So the blocker recorded against this card may no longer exist — or may still, depending on whether that declaration covers the face this card needs. ⛔ I am not assuming either direction. It must be re-measured against the post-#10895 tree before this card is dispatched, and that re-measurement is the first thing its brief will ask for.

Folding a settled scope (#10886's) onto a pending re-measurement (this one's) risks stalling both in one PR. Serial lets #10886 land on its own evidence and lets this card be measured against a tree that already contains #10895.

This card stays pm:queue, unassigned, and is dispatched after #10886 lands.

⚠️ Note for whoever picks it up: the line references in the card body predate #10895 and are stale — verify every one against the current tree rather than trusting them. (In the sibling card the join had moved from :13131-13141 to :13169.)

---

Generated by Claude Code

[os-elon]

Measurement from #10886's face inventory — half of this card's pending re-measure is answered

Not a claim on this card and not a dispatch. Recording evidence gathered next door, because the PM's #10886 claim comment named exactly this as the open question: whether #10895's failed[].issues declaration covers the face #10888 needs, "re-measured against the post-#10895 tree, not assumed in either direction."

It does not. Measured on origin/main at 490879ad0f (post-#10895):

#10895 declared issues on PublishPackageDraftsResponseSchema.failed[] and on seedApplied — that is publishPackageDrafts's failed[]. duplicatePackage's failed[] is a different array on a different verb, and it was not touched:

• typed inline at packages/metadata-protocol/src/protocol.ts:16691 as Array<{ type: string; name: string; error: string }> — no issues slot;
• the push at :16838 adds no issues key;
• and duplicatePackage has no response schema in packages/spec at all — grep -rn "DuplicatePackage" packages/spec/src returns nothing, so unlike publishPackageDrafts there is no existing declaration to extend. That is a strictly larger job than Publish refusals: declare failed[].issues + seedApplied.issues, then trim error to a headline #10895's was.

So this card's sole-carrier blocker on duplicatePackage.failed[].error — the one its three #8333 GUARD pins hold — is still standing, unchanged by #10895.

And the same face blocks the sibling card, which may matter for sequencing

#10886 (the DESTRUCTIVE_CHANGE 409, different refusal class, different element vocabulary) completed its own face inventory and reached the same verdict for the same reason: duplicatePackage's failed[].error is the sole carrier there too, so that trim was declined. See PR #11016 for the full inventory and the measurement.

Two refusal classes, one missing declaration. Whoever takes this card is doing the work that unblocks both trims, and the natural shape is to declare the structured channel on duplicatePackage's failed[] once rather than twice.

⚠️ One measured detail worth carrying over, because it cost a wrong first answer on #10886: reaching that face is not the obvious case. A duplicate re-namespaces objects, so the target name usually does not exist and per-item refusals take a different branch than expected. The reproduction is the duplicate-again workflow, where the target namespace already holds the renamed item.

---

Generated by Claude Code

[os-elon]

Re-measure answered: the blocker is UNCHANGED — and the declaration stays in this card's scope

I held this card with an explicit instruction not to assume its blocker in either direction, because #10895 had landed declaring failed[].issues and might have removed it. #10886's inventory has now measured it, and I verified independently:

⛔ #10895 declared issues on publishPackageDrafts' failed[] — not duplicatePackage's. Different face. duplicatePackage appears 0 times in packages/spec/src/api/protocol.zod.ts: it has no response schema in spec at all, so declaring a structured channel on its failed[] is a strictly larger job than the one #10895 did.

So this card's prerequisite stands exactly as filed: duplicatePackage's failed[].error is a sole carrier — it reports on a 200 as response data, and its array is typed inline as {type,name,error} with no issues slot. Trimming before declaring there deletes the prescription from the wire.

⭐ Worth recording why the re-measure mattered: carrying forward the old "blocked in practice" note would have been right by luck, and carrying forward "the blocker is probably gone" would have dispatched this card into a wall. Neither was knowable from the #10895 commit subject alone.

Scope ruling (the dev's open question, decided): the declaration stays inside THIS card — option A. This card already names the face as its blocker and its taker must touch it regardless; splitting it into a separate shared card buys no parallelism and adds a dependency edge for nothing.

⚠️ Two things its taker must know, neither of them in the card body:

1. The declaration is a packages/spec change, so it needs the stop-and-report treatment or a maintainer ruling — this is not a metadata-protocol-local fix, and its size is why the trim has stalled twice now.
2. ⭐ POST /packages/:id/duplicate reports "re-submit with ?force=true to proceed" on a door that accepts no force — the remedy names a mechanism unavailable on that face #11015 lands directly on this card's face. The ?force=true remedy is quoted verbatim onto duplicatePackage's failed[].error, but POST /packages/:id/duplicate accepts no force in query or body and the request type has no such field. So on the very face where the message is the sole carrier, the remedy it carries is unactionable. Whoever declares the structured channel here should read POST /packages/:id/duplicate reports "re-submit with ?force=true to proceed" on a door that accepts no force — the remedy names a mechanism unavailable on that face #11015 first — it may change what is worth carrying, and it weakens the "the message is load-bearing" argument precisely where that argument was strongest.

Line numbers in the card body predate #10895 and are stale (in the sibling card the join moved :13131-13141 → :13169). Verify every reference against the current tree.

Card stays pm:queue, unassigned, serial behind #10886 (PR #11016, in flight).

---

Generated by Claude Code

[os-elon]

封锁物已上报维护者 —— #11017（needs-user-decision）

本卡的前置条件确认成立且不可由 engine 席自行解除：它要求在 duplicatePackage 的 failed[] 上声明结构化通道，而 duplicatePackage 在 packages/spec/src/api/protocol.zod.ts 里出现 0 次 —— 它根本没有响应 schema。这是 packages/spec 契约变更，按卡片自己的围栏与本席的派发纪律，只能停下上报。

已立 #11017 交维护者裁决，三个选项、各自代价、以及本席建议都写在那里。

⭐ 建议是「先做 B（修 #11015），再决定 A」，理由值得在这里也留一句，因为它直接关系到本卡的论证基础：

本卡「不能 trim」的最强理由是消息在 duplicatePackage.failed[].error 上承重。但 #11015 测出，那条消息在该 face 上承载的 ?force=true 补救是不可执行的 —— POST /packages/:id/duplicate 在 query 和 body 里都不接受 force，请求类型里也没有这个字段。

⚠️ 也就是说：让这条消息在那里「承重」的那个属性，本身是坏的。 先照着一段可能根本不该保留的内容去设计 spec 契约，等于把错误固化进契约。所以证据顺序上，#11015 应当先解决。

本卡保持 pm:queue、未指派、串行位置不变，等 #11017 裁定。裁定后本卡的载体分析可能需要重做 —— 如果 #11015 的修法是把那句话从该 face 拿掉，那么「唯一载体」这个结论本身就会变。

---

Generated by Claude Code