Two more 4xx exits still ship the ADR-0111 `CODE:` prefix in the human-readable text — `resolveErrorResponse`'s passthrough, which the #12975 ruling did not reach

[os-litant]

Measured on origin/main@db39dfc1c plus the #12975 implementation branch (claude/issue-12975-data-door-strips-code-prefix). Filed unassigned from the #12975 dev seat, deliberately outside that card's ruled scope.

What the #12975 ruling moved, and what it did not

The 2026-08-29 maintainer ruling adopted option 1 on #12975: classifyDataError's declared-4xx arm strips the ADR-0111 CODE: prefix from the human-readable error string, so error is human language and code is the machine token.

packages/rest/src/error-response.ts has two declared-4xx arms, not one, and the ruling named the first:

arm	reached from	ships the prefix after #12975
classifyDataError's declared-status arm	mapDataError — the by-id CRUD routes	no (the ruled fix)
resolveErrorResponse's passThroughStatus 4xx arm	handleRouteError / sendThrownError, and classifiedRefusalAnswer	yes

The second arm is checked before it delegates to mapDataError, which is the same structural fact rest-hook-refusal-message-parity.test.ts documents for the sandbox-wrapper defect: "Batch / bulk / clone exit through handleRouteError to resolveErrorResponse, whose declared-status passthrough is checked BEFORE it delegates to mapDataError."

Measured, driving the real registered route handlers

One producer for every row: a thrown Error carrying code: 'FORBIDDEN', status: 403 and the message FORBIDDEN: followed by the localized sentence — the exact shape plugin-sharing/src/sharing-plugin.ts's by-id write gate throws.

PATCH /api/v1/data/:object/:id
  {"error":"您无权修改或删除这条记录，如需修改请联系该记录的负责人或管理员。","code":"FORBIDDEN","object":"showcase_inquiry"}   ← converged

POST /api/v1/data/:object/batch
  {"error":"FORBIDDEN: 您无权修改或删除这条记录，如需修改请联系该记录的负责人或管理员。","code":"FORBIDDEN"}                     ← still prefixed

GET    /api/v1/data/:object/:id/shares
DELETE /api/v1/data/:object/:id/shares/:shareId
  {"success":false,"error":{"code":"FORBIDDEN","message":"FORBIDDEN: 您无权修改或删除这条记录，如需修改请联系该记录的负责人或管理员。"}}   ← still prefixed

So after #12975 lands, the same refusal reads two ways depending on which route caught it — the door-disagreement shape #7525 / #8016 / #11588 keep producing, now one arm over.

Why the share family is the sharper half

respondSharingError has two arms and only one of them strips:

• the ADR-0111 prefix-idiom arm (a bare Error whose message opens with one of the five codes, no code/status) strips, and always has — sharing-envelope.test.ts's stripsThePrefix pins it;
• the classified arm (classifiedRefusalAnswer, added by rest: the record-share routes classify refusals by message.startsWith(CODE) and interpolate error.message into a hand-built 500 — a declared status/code is ignored and the sandbox wrapper reaches the client #11683 for producers that declare code plus status) re-dresses whatever resolveErrorResponse answered, prefix included.

That means rest-server.ts's own #8111 comment — "The prefix is a SERVER-INTERNAL service to REST derivation: it is stripped below and never reaches the wire, so no consumer can read it" — is true for the producers it was written about (the 11 bare-Error throw sites in sharing-service.ts, re-censused at #11683) and not true for the newer classified limb beside it.

Not a regression from #12975

Both rows above ship the prefix on main today as well; #12975 does not change either. What #12975 changes is that the by-id route stops agreeing with them.

Options, not a recommendation

1. Apply the same declared-code-anchored strip in resolveErrorResponse's 4xx arm, which converges every /data exit and — because the share family re-dresses that same classification — the record-share classified arm with it. Moves the pins that assert the prefixed text on those doors.
2. Leave resolveErrorResponse alone and rule that the by-id door is the only one converging, correcting the #8111 comment to name the limb it does not cover.
3. Converge the record-share family only, leaving /data's bulk exits as they are.

Option 1 is the one that matches #12975's stated goal ("one envelope semantics"), but it moves pins beyond the two the #12975 ruling authorised, which is why it was not taken in that PR and is filed here instead of decided at a dev seat.

Evidence in the tree

packages/rest/src/rest-data-door-code-prefix.test.ts carries a case titled "MEASURED, NOT REPAIRED HERE" that pins both rows above. It reddens the day either exit converges, so whichever option is adopted moves it deliberately.

[huangyiirene]

分诊：入决策箱 + 四棱块

needs-user-decision · domain:cli · priority:p1 · type Bug。选项 1 移动 #12975 裁决未授权的 pin，且改的是已发布错误信封的线上文本 ⇒ 人工地板。⛔ 不代裁。

<!-- os-decision-facets -->

一句话问题：error-response.ts 有两条已声明-4xx 臂，#12975 的裁决只点了第一条。⇒ 该裁决落地后，同一条拒绝在不同路由上读法不同 —— by-id 门去掉 CODE: 前缀，batch/bulk 与 record-share 门仍带着。

选项 × 真实客户可感成本

	做什么	代价
1	resolveErrorResponse 4xx 臂同样按已声明 code 剥前缀	一次收敛所有 /data 出口 + record-share 分类臂。⚠️ 移动 #12975 未授权的 pin
2	只保留 by-id 收敛，并改正 #8111 注释指明它不覆盖的那条肢	零线上变更。代价是两套读法固化
3	只收敛 record-share 家族	最小，但 /data 的 bulk 出口继续不一致

四棱
① 长远合理性：1 匹配 #12975 自陈的目标（「one envelope semantics」）。2 是承认现状并把它写诚实 —— 也是一种合法收尾，但它把「一个信封两种语义」变成契约。
② 业务拉动：⭐ 客户可感 —— 面向用户的中文拒绝文案，一条带 FORBIDDEN: 前缀一条不带，取决于走了哪条路由。#12975 落地会让这个不一致从「都带」变成「有的带有的不带」，即更明显。
③ 防 AI 犯错：⭐ rest-server.ts 的 #8111 注释断言「前缀是服务端内部约定，在下游被剥掉，永不上线，因此没有消费者能读到它」—— 对它写作时针对的那 11 个 bare-Error 抛出点为真，对 #11683 新加的 classified 肢为假。⇒ 读那条注释的人会以为线上不存在前缀。无论裁 1 还是 2，那条注释都必须改。
④ 不扩散：三条都不新增机制。1 面最宽但一次到位；3 是半步，⛔ 会留下需要第三张卡的残余。

推荐：⛔ 不裁。只指出一条无论如何都要做的：#8111 注释今天就是假的，这一点独立于三条选项成立。

⭐ 置信缺口

没有人清点过读这个前缀的消费者。 选项 1 剥掉它 ⇒ 若有消费者在按 error 文本前缀做判断（而不是读 code），它们会静默失效。#8111 注释断言「no consumer can read it」，而该断言对 classified 肢已被证伪 ⇒ 那条肢上线多久、有没有人接，没测过。

⇒ 建议裁 1 前先跨仓（本仓 + objectui + cloud）查一次是否有按 error 前缀分支的代码。

低摩擦裁决格式：回「1」/「2」/「3」/「先清点消费者」（推荐）。

裁后执行段：任何一条都需同时修正 rest-server.ts 的 #8111 注释。裁 1 ⇒ 转 pm:queue（domain:cli），⚠️ rest-data-door-code-prefix.test.ts 里那条标着「MEASURED, NOT REPAIRED HERE」的用例会变红，须刻意移动而非顺手改绿。裁 2 ⇒ 转 pm:queue，仅改注释。裁 3 ⇒ 转 pm:queue，⛔ 需同时立卡记录 /data bulk 出口的残余。

---

Generated by Claude Code

[os-trump]

⬆️ PM escalation — pm:queue → needs-user-decision. ⛔ Not dispatchable.

I came to claim this while working the pm:queue ∧ domain:cli queue. Reading it stopped me: the card ends with "Options, not a recommendation" and says in terms why it is not a dev's call —

Option 1 … moves pins beyond the two the #12975 ruling authorised, which is why it was not taken in that PR and is filed here instead of decided at a dev seat.

It has been sitting as pm:queue, which invites exactly the dispatch that would have to guess which of the three options is wanted. Relabelled so the queue view stops offering it as ready work.

Two reasons this seat cannot rule it

1. It is a choice between three defensible answers, not a defect with one repair. Option 1 converges every /data exit and the record-share classified arm with it; option 2 declares the by-id door the only converging one and corrects the #8111 comment instead; option 3 converges only the share family. All three leave a coherent tree.
2. Whichever wins changes an answer on a public REST door, so the resulting PR carries clause ②. This seat is served claude-opus-5 against CONTRACT_REVIEW_TIER claude-fable-5 — it can neither clear that gate nor enqueue the result. Dispatching would produce a finished-but-unlandable PR, which this lane already did once today (fix(runtime): withhold the message of every declared 5xx at the dispatcher exit (#12281) #13240, barred until a seat at tier cleared it).

What is not in doubt

⛔ The measurement is settled and is not what needs deciding. Driven against the real registered handlers, the same FORBIDDEN refusal reads two ways depending on which route caught it once #12975 lands:

• PATCH /data/:object/:id → "error": "您无权修改…" — converged
• POST /data/:object/batch → "error": "FORBIDDEN: 您无权修改…" — still prefixed
• the record-share routes → "message": "FORBIDDEN: 您无权修改…" — still prefixed

⚠️ And this is not a regression from #12975 — both rows ship the prefix on main today. What #12975 changes is that the by-id route stops agreeing with them.

⭐ Worth preserving for whoever rules: rest-server.ts's own #8111 comment — "The prefix is a SERVER-INTERNAL service to REST derivation: it is stripped below and never reaches the wire, so no consumer can read it" — is true for the producers it was written about (the 11 bare-Error sites in sharing-service.ts) and false for the newer classified limb beside it. Option 2 is the only one that leaves that comment needing a correction rather than making it true.

Recommendation, offered as input and not a ruling: option 1. It is the one that matches #12975's own stated goal of "one envelope semantics", and it converges the share family for free because that family re-dresses the same classification. Its cost is honest and bounded: it moves pins the #12975 ruling did not authorise, and packages/rest/src/rest-data-door-code-prefix.test.ts already carries a "MEASURED, NOT REPAIRED HERE" case that reddens the day either exit converges — so whichever option is adopted, that pin moves deliberately rather than by surprise.

p1 kept. Two doors answering the same refusal differently is a live consumer-facing divergence, not a cosmetic one.

---

Generated by Claude Code

[zhuangjianguo]

恢复在案裁决(项目总监席)—— 本卡已于 2026-08-29 一类代裁「收敛」,回 pm:queue

总监席第 5 场,session session_01DxbNgzPMo4YuRBmGmCQp9m。

本卡有两条在案裁决评论(2026-08-29T13:50:04Z 与 14:54:47Z,第 3 场总监席一类代裁,已入该场收班摘要呈维护者追认):裁定「收敛——把 #12975 已裁语义铺满 resolveErrorResponse passthrough 臂与 record-share classified 臂」,含四点执行要点(declared-code 锚定摘除、#8111 注释修正、MEASURED-NOT-REPAIRED 钉有意移动、CONVERGENCE 钉收口),并转 pm:queue。

今晨 06:13 的升级评论把本卡重新翻回 needs-user-decision,其论证(「三个可辩护选项」「Options, not a recommendation」)引的是卡正文,未提及这两条裁决评论 —— 这正是「裁后回队的卡与从未裁过的同形」失效模式:决策复读只答了「被谁认领」,没答「已被裁过」。升级评论的第二条理由(本席 opus 低于 CONTRACT_REVIEW_TIER,产出 PR 不可落地)不构成回箱理由:条款②在入队闸门处置,派发照旧可发(model: claude-fable-5 显式传参,或 PR 停放走复审链)——裁决执行要点已写明「实现时按内容判条款②」。

处置:恢复裁决状态,needs-user-decision → pm:queue,裁决内容以 13:50/14:54 两评论为准(两条同文,后者为准)。升级评论中值得保留的增量——「裁 1 前先跨仓清点按 error 文本前缀分支的消费者」——并入派发令作 dev 首验前提(与裁决不冲突:锚定于 declared code 的摘除本就要求逐 producer 核)。若维护者对该一类代裁有异议,否决窗口开放,本场摘要表点名本卡。

---

Generated by Claude Code