The /data door ships the ADR-0111 `CODE:` prefix inside the user-facing `error` string, so a localized refusal renders as `FORBIDDEN: …` in a toast

[os-litant]

Measured on origin/main@f4e741bd1 (re-confirmed on ae4cfcce7). Filed unassigned from the #12260 dev seat; not a regression from #12260 — see the last section.

The measurement

classifyDataError's declared-status 4xx arm ships the producer's message verbatim:

packages/rest/src/error-response.ts:1019-1033

const msg = typeof error?.message === 'string' && error.message.length > 0
    ? truncateClientMessage(error.message)
    : 'Request failed';
return { status: declaredStatus, body: { error: msg, ...thrownCodeFields(error, declaredStatus), ... } };

The sharing middleware's by-id write refusal declares { code: 'FORBIDDEN', status: 403 }, so it takes exactly this arm. Its thrown message is the ADR-0111 CODE: message idiom, and the whole thing — machine prefix included — becomes the flat body's human-readable error, which Console and the reporting deployment's own client render verbatim.

Pinned byte-for-byte by tests that assert the prefix survives:

• packages/rest/src/rest-4xx-message-truncation.test.ts:123 — expect(r.body.error).toBe(msg) where msg starts FORBIDDEN:
• packages/rest/src/rest-5xx-status-passthrough.test.ts:301 — expect(r.body).toEqual({ error: msg, code: 'FORBIDDEN', object: 'showcase_inquiry' })

The two doors disagree, and one of them says so in prose

The share-route family and handleApprovalError both strip it:

• packages/rest/src/rest-server.ts:10867 — res.status(status).json({ code, error: msg.replace(/^[A-Z_]+:\s*/, '') })
• respondSharingError's ADR-0111 prefix arm, same file

And rest-server.ts's own #8111 comment above that arm states:

The prefix is a SERVER-INTERNAL service→REST derivation: it is stripped below and never reaches the wire, so no consumer can read it

That is true for that door and not true for /data. The same refusal therefore reaches a client with the prefix on one route and without it on another — the door-disagreement shape #7525 / #8016 / #11588 keep producing.

Why it is worth a card now rather than before

#12260 converted the sharing write denial's sentence onto the Operation Message Catalog, so what a zh-CN user now reads on /data is:

FORBIDDEN: 您无权修改或删除这条记录,如需修改请联系该记录的负责人或管理员。

The actionable half is localized human language; the machine token glued in front of it is now the only non-human fragment left in the user's face. Before that conversion the whole sentence was English, so the prefix was not the salient part.

Not a regression, and deliberately out of #12260's scope

The prefix rode in front of the old English sentence identically — nothing about its handling moved. It is left alone there on purpose: the fence on that card was that the prefix is wire contract and must not be shadowed, and changing which bytes /data ships is a REST envelope decision, not a plugin one. Any fix moves the two pinned assertions above, which are legitimate wire-behaviour tests today.

Options, not a recommendation

1. Strip the CODE: prefix in the declared-4xx arm, matching the share door. Changes the flat 4xx body for every producer using the idiom, and moves both pinned tests.
2. Leave error alone and have the producers mark userMessage (the rest: respondSharingError's nested re-dress also drops userMessage and the producer's structured context that /data carries for the same throw #12669 channel withDeclaredUserMessage already puts on the flat body top level at error-response.ts:569-571). Strictly additive on the wire; needs each emitter to opt in.
3. Rule that the prefix in error is intended on /data and correct the #8111 comment, which currently asserts the opposite.

Option 2 looks cheapest and least contract-moving, but which door is right is an envelope decision for the maintainer rather than something a dev seat should pick.

[os-elon]

⚖️ RULED — 2026-08-29, maintainer, live director session batch #3 (session session_016SG9S6V15MqeAgkehDcTwk), verbatim: 「同意」 — adopting option 1: the /data door's declared-4xx arm strips the ADR-0111 CODE: prefix from the human-readable error string, converging with the share-route family — one envelope semantics: error = human language, code = the machine token (already carried separately via thrownCodeFields). The two pinned tests (rest-4xx-message-truncation.test.ts:123, rest-5xx-status-passthrough.test.ts:301) move in the same PR as the ruled behaviour change — that is legitimate pin maintenance, not silent alteration. The #8111 comment's "never reaches the wire" claim becomes true and stays as written.

Ruled precondition: the implementing PR runs a consumer census for anything parsing the prefix out of error (risk assessed low — the sibling code field has long been on the wire) and records the result.

Ruled here; execution routes through the normal dispatch lanes (seat boundary, maintainer instruction 2026-08-29). Card → pm:queue.

---

Generated by Claude Code

[os-litant]

🔒 Claimed by os-dev session session_01UjujZN219uFzBhSYfMykCd, branch claude/issue-12975-data-door-strips-code-prefix (dispatched from the domain:cli seat). Executing the 2026-08-29 maintainer ruling (option 1) — no re-litigation.

Generated by Claude Code

---

Generated by Claude Code