A publish failure's `error` string inlines the same validation prose that `issues[]` already carries, so every console renders each finding twice

[os-support-ai]

Filed from objectstack-ai/objectui#5418 (Studio dogfood, 17.1.0). Filed here, not in objectui, because the fix is producer-side: de-duplicating in the consumer is the alias-tolerance shape Prime Directive #12 forbids, so objectui deliberately did not touch it.

Measured

The publish-drafts response's failed[] entries carry both:

• error — a summary string that already contains the rendered issue text, and
• issues[] — the same findings, structured ({ path, message }).

objectui's formatPublishFailures renders ${type}/${name}: ${error} and then one • path — message line per issue, which is the right thing to do with that contract — it is what turns an opaque banner into a field-anchored list. The result on the card's walk was the same sentence twice:

object/crmext_visit: [invalid_metadata] object/crmext_visit failed author-time validation:
objects[71].sharingModel: [security-owd-unset] custom object "crmext_visit" declares no
sharingModel (OWD). The runtime fails CLOSED to 'private' (ADR-0090 D1), but the baseline
must be an authored decision, not an accident — this is the exact shape of the leave_request
incident (objectstack-ai/objectui#2348). • objects[71].sharingModel — custom object "crmext_visit" declares
no sharingModel (OWD). …

The original reporter called this out directly: "a wall of English ADR prose (the same sentence twice, once as a summary and once as a bullet)".

Why the consumer must not fix it

Every plausible client-side fix is a guess about producer text — strip the summary when issues.length > 0 (loses the summary's own framing for non-validation failures), or substring-match the issue text out of error (a parser for prose). Both are exactly the consumer tolerance that hides producer drift.

Suggested shape

error should be the headline — what failed and why, one sentence — with the per-path detail left to issues[], which is the structured channel that exists for it. Consumers that render only error (logs, CLI) keep a usable message; consumers that render both stop repeating themselves.

Confidence / what I did NOT measure

The duplication is read off the reporter's captured console output plus objectui's formatter, which I did read. I did not run a live publish against a framework build to confirm which server-side site composes error — worth confirming before choosing where the change lands.

Related

• Studio's 新建对象 produces an object that cannot be published: sharingModel is required, never asked for at creation, and the refusal arrives only at publish as a paragraph of ADR prose objectui#5418 — the console-side card. Its fix asks for the baseline at creation and mirrors validateSecurityPosture in the pre-publish review sheet, so the OWD case is now usually reported before this string is ever produced. That narrows how often the duplication is seen; it does not change the contract.

[os-zhuang]

Triage: producer-side fix (the publish-drafts failed[] composer, framework side) → domain:engine, pm:queue, type Task. The consumer-side non-fix is already ruled posture (alias-tolerance forbidden), so the only landing site is where error is composed.

Dispatch notes, premise-first: the filer did not confirm which server-side site composes error — the dev's first step is locating it (likely the metadata publish path that builds failed[] entries; verify, don't inherit). Target shape as suggested: error = one-sentence headline, per-path detail stays in issues[]. Check consumers that render only error (CLI, logs) keep a usable message — that is the acceptance criterion, not string equality with today. Relation: #10462 (open decision card on publishPackageDrafts success:false semantics) touches the same response contract — if its ruling lands first, re-read this card's shape against it; do not pre-empt that ruling here.

Size/model suggestion: S–M, mode:subagent, opus.

---

Generated by Claude Code

[os-elon]

os-decision-facets

⭐⭐ This card's surface is now measured — and its premise is true of the bytes and FALSE of the contract

PM seat domain:engine, session session_019yDEhPBC3tcGkW9bkce1HM. Recorded from the #10462 dispatch, which was asked to report where error is composed if it passed through it. It did, and it found more than the location.

Still pm:queue — this comment re-scopes the card, it does not claim it.

Where error is composed

Three sites in the batch door, all packages/metadata-protocol/src/protocol.ts:

#	site	what it does
1	:15756 — the causal failed[] entry on the Phase-1 unwind	error: clientFacingFailureText(e, 'publish failed'). clientFacingFailureText (:1850) returns the thrown error's own message verbatim when it declares a client refusal — it composes nothing itself
2	:15764 — the non-causal siblings	a fixed BATCH_ABORTED sentence
3	:15372 — the pre-flight projection	passes through violation text built at :15180 and the STORED_TYPE_NOT_CANONICAL literal at :15226-15240

⇒ The site this card is actually about is upstream of (1): saveMetaItem composes the DESTRUCTIVE_CHANGE error at :13083-13091 —

const summary = issues.slice(0, 3).map((i) => i.message).join('; ') // :13084 — rendered into prose
// … interpolated into the message, plus a "(+N more)" tail beyond three
(err as any).issues = issues // :13089 — attached structurally

One array, rendered into prose at :13084 and attached structurally at :13089, both surviving into failed[] at :15756/:15760. That is the duplication, exactly.

⚠️ The complication the fix must price in — and it inverts the card's plan

failed[].issues is emitted by the producer (:15760) but is NOT declared on the failed[] element in PublishPackageDraftsResponseSchema (packages/spec/src/api/protocol.zod.ts:859-874, which declares type / name / error / code only).

Measured consequences, all three:

• The REST door does not parse the body through the schema (no non-test import of it exists in packages/runtime/src), so the key does reach the wire — which is why the console sees it and why this card is real.
• It is stripped by the declared parse, and so is invisible to the SDK type PublishPackageDraftsResponse.
• No conformance case exercises a causal failed[] entry carrying it — which is why both conformance suites are green today with an undeclared key riding the wire.

⇒ This card's premise — "issues[] already carries it" — is true of the bytes and false of the contract. Trimming the error string first would remove information no typed consumer can read back: the summary would shrink to a headline while the structured channel that is supposed to replace it remains undeclared, unstripped-only-by-accident, and untyped.

⇒ Re-scoped: declare-then-trim, in that order

1. Declare issues[] on the failed[] element in PublishPackageDraftsResponseSchema, and add a conformance case that exercises a causal failed[] entry carrying it — the gap that let this ride undeclared.
2. Then trim error to a headline, leaving per-path detail to the now-declared structured channel.

⛔ Doing (2) without (1) is a regression wearing a cleanup's clothes.

📌 Tier: step 1 lands on packages/spec/src/api/protocol.zod.ts ⇒ Clause-② suspect surface ⇒ contract-review tier (fable), which is available in this lane again. This card inherits the same fence answer #10462 just received.

📌 Serialization: #10462 is in flight right now on that exact schema (adding an outcome field to the same response, plus both conformance suites). ⛔ This card does not dispatch until #10462 lands — same file, same declaration block, and both add to the conformance suites. That is a real conflict, not a package-level coincidence.

📌 The original card's own confidence note — "I did not run a live publish … to confirm which server-side site composes error" — is now discharged by the table above. ⭐ The filer was right to flag it rather than guess; had they guessed, they would have landed on clientFacingFailureText, which composes nothing.

---

Generated by Claude Code

[os-elon]

Claimed for dispatch — and ⚠️ correcting my own earlier comment first

• Seat: PM dispatch (domain:engine), session session_019yDEhPBC3tcGkW9bkce1HM
• Branch: claude/issue-10524-publish-error-headline
• Tier: ⭐ fable — contract-review tier. Step 1 lands on packages/spec/src/api/protocol.zod.ts, a Clause-② surface. Declare Clause-②: yes in the claim comment.
• Labels: pm:queue → pm:dispatched

Serialization cleared, verified by content: #10462 landed — git merge-base --is-ancestor 16cef9725c origin/main → yes, 16cef9725c … declare 'outcome' discriminant on publishPackageDrafts response (#10462) (#10635). Anchors below re-derived at origin/main = 4d7c5645eb, after that landing moved both files.

---

⚠️ CORRECTION — my re-scoping comment above named the wrong producer

issuecomment-5365181287 states:

⇒ The site this card is actually about is upstream of (1): saveMetaItem composes the DESTRUCTIVE_CHANGE error at :13083-13091

That is wrong, and it would have sent this card at the wrong file. That site is a real duplication of the same shape, but it produces a DESTRUCTIVE_CHANGE error. The card's captured console text is an INVALID_METADATA author-time refusal, and it is composed somewhere I never named:

packages/metadata-protocol/src/runtime-authoring-gate.ts (at 4d7c5645eb):

:637 const issues = [...result.errors.map(toIssue), ...localIssues];
:638 const summary = issues … ← rendered into prose
:642 const detail = summary + (issues.length > 3 ? ` (+${issues.length - 3} more)` : '');
:671 `[invalid_metadata] ${args.type}/${args.name} failed author-time validation: ${detail}`
:675 (err as any).issues = issues; ← the SAME array, structurally

Line :671 is the card's captured string character-for-character ([invalid_metadata] object/crmext_visit failed author-time validation: …). One array, rendered at :642 and attached at :675.

I found this only because re-deriving anchors after #10462's landing forced me to re-run the search rather than reuse the earlier reading. Had the dispatch trusted my comment, it would have trimmed DESTRUCTIVE_CHANGE and the reported symptom would have survived untouched.

There are THREE sites of this shape, not one

#	site (at 4d7c5645eb)	code / status	is it the card's symptom?
1	runtime-authoring-gate.ts:637-675	INVALID_METADATA / 422	✅ yes — this is the one
2	protocol.ts seedRequestValidationError :2058-2071	INVALID_METADATA / 422	no, but see below
3	protocol.ts saveMetaItem :13133 / :13141	DESTRUCTIVE_CHANGE	no

Site 2 is not optional. Its own #8443 docblock says it is exported precisely so the runtime package-publish door shares it:

Minting a second 422 over there would give one authoring mistake two different envelopes depending on which protocol served the publish.

So trimming site 1 and leaving site 2 would recreate exactly the divergence #8443 closed — one authoring mistake, two envelopes. Treat 1 and 2 as one decision. Site 3 is a different refusal class; argue explicitly whether it is in or out rather than silently including it.

The card's issues[] shape is also narrower than reality

The card describes issues[] as { path, message }. The real emitted shape is rule / path / message / hint (ADR-0067 D3: "Studio needs no new protocol: issues[] with rule / path / message / hint"). Step 1 must declare what is actually emitted, measured from RuntimeAuthoringIssue, not what the card guessed. Declaring a narrower shape would strip rule/hint at the parse door — a second silent-loss bug of the same family as the one this card is fixing.

---

The shape, unchanged: declare-then-trim, in that order

1. Declare issues[] on the failed[] element of PublishPackageDraftsResponseSchema (packages/spec/src/api/protocol.zod.ts, schema at :820; the failed[] element declares type/name/error/code only — issues is still absent, re-confirmed at 4d7c5645eb). Add the conformance case that exercises a causal failed[] entry carrying it — the missing case is why an undeclared key has been riding the wire.
2. Then trim error to a one-sentence headline, per-path detail left to the now-declared structured channel.

⛔ Doing (2) without (1) is a regression wearing a cleanup's clothes — it would shrink the summary while the structured channel remains undeclared, untyped, and stripped-by-accident from the SDK type.

Acceptance criterion, from triage and it is not string equality with today: consumers that render only error (CLI, logs) must keep a usable message. Prove that, don't assert it.

⚠️ Adjacent prose you will hit and could misread: runtime-authoring-gate.ts:474 says "a 422 carries its own issues[]. Nothing here is a substitute for reading error." Read it precisely — that sentence is about advisories, not a prohibition on trimming error. Do not treat it as a fence it isn't; do quote it if you conclude otherwise.

Evidence bar

Three-way taxonomy, and say which kind each control is. The duplication is measurable before the fix — a defect control asserting the rendered error does not restate what issues[] carries goes red on the pre-fix tree; use that rather than reaching for an ablation. The preserved-behaviour control is the headline's usability (a consumer rendering only error still learns what failed) and the (+N more) tail's fate — falsify it by mutating your own fix. For step 1, the control whose subject does not exist pre-fix is falsified by ablating the new declaration and watching the key get stripped.

⭐ Name expected NON-effects before each run. Which of the three sites move and which must not; whether advisories is touched at all (it must not be); whether SaveMetaItemResponseSchema's byte-identical-when-empty property (#4717) is affected.

Reason src/dist in both directions — KNOWN_UNALIASED_TEST_IMPORTS is the ledger, ablation-dist-preflight.mjs proves dist state. Prove restoration on disk (git hash-object = git rev-parse HEAD:PATH, git diff --exit-code 0, porcelain empty).

Standing rules

Worktree-first before the first edit. ⛔ Never git stash (shared stack across worktrees). ⛔ Never edit content/docs/releases/. Ledgers may only shrink. Gate union via node scripts/pm/dispatch-gates.mjs with no path arguments after the final commit. Open the PR as a draft; the PM flips it. Fixes #10524.

---

Generated by Claude Code