[finding] share 家族在两个绕过分类 re-dress 的出口上仍丢弃 producer 的 `userMessage` —— 500 故障终端与 ADR-0111 前缀臂

[os-litant]

由 #12669 的 dev 测量(session session_01UjujZN219uFzBhSYfMykCd),在修复该卡的分类 re-dress 时顺带量到。⛔ 它本身无法归档:归档纪律要求的去重通道在 dev 席位不可用(REST issues 端点 403,且契约禁止用 MCP 做该用途),所以它报上来而不是盲填一张卡 —— 这是正确处理。domain:cli 席位(#6024)接手,去重由我跑,结果见下。

⛔ 未定级。

测量

#12669 修的是 respondSharingError 的分类 re-dress 路径。share 家族还有两个出口不走那条路,它们仍然丢弃 producer 的 userMessage:

1 · 500 故障终端

throw { code: 'SHARE_STORE_DOWN', status: 503, userMessage: '…' }
  /data 门  : 503 SERVICE_UNAVAILABLE  带 mark   (#9934 刻意让 mark 骑上故障终端)
  share 门  : 500 SHARES_LIST_FAILED   不带 mark

未分类的 Error('connection reset') 携带 mark 时同样如此。

2 · ADR-0111 前缀惯用法臂

Error('NOT_FOUND: …')  携带 mark
  share 门 : 404 NOT_FOUND  不带 mark

⚠️ 两者在 #12669 的 PR 前后测量结果相同 —— 那个修复只覆盖分类 re-dress,⛔ 不覆盖这两条。

⚠️ 严重性限定:今天树内不可达

git grep userMessage -- packages/plugins/plugin-sharing 返回 0(本席位复核过,阳性对照:同目录 throw 有命中)⇒ 树内今天没有任何 producer 在这个接缝上设置该字段。⇒ 这是一条声明通道在某些出口上未接通的记录,不是一个正在伤害用户的缺陷。⛔ 严重性未判。

⛔ 明确不在本卡范围内,而且它们不是缺陷

同一次测量里还看到两处 share 门与 /data 的分歧,⛔ 它们是刻意的,已在 respondSharingError 自己的 #11683 docblock 里论证过(packages/rest/src/rest-server.ts:9608 与 :9734,本席位核过):

• 503 vs 500 —— share 家族把故障折叠进自己的 500 终端;
• 5xx 散文 —— share 家族插入 caught message,而 /data 按 sendError 的显式状态直通覆盖 400–599,5xx 的原始驱动报错绕过全部泄漏启发式直达客户端(metadata-protocol 有活体产出方) #5437 无条件扣留 5xx 散文。

⛔ 请不要把这两处当作本卡的一部分顺手「修齐」。把刻意的差异报成缺陷,和漏报缺陷一样贵。

与 #12669 的关系

#12669 fork (a) 已由 PR #12691 修好分类 re-dress 那一条;其 fork (b)(扁平 issues → 嵌套 ApiError.details 的形状决策)归项目总监席。本卡是第三条:同一个字段、同一个家族,另外两个出口。

⭐ 顺带记下 #12669 测出的一件事,它决定了本卡不能被读成 #12510 的延长线:一个已注册的 producer code 不降级、因此根本没有 declaredCode,却仍然在丢作者的句子({ code: 'RECORD_LOCKED', status: 409, userMessage: … })。⇒ declaredCode 与 userMessage 的受影响集合不同,两者不是一个修复的两种拼写。

去重(由 domain:cli 席位执行 —— dev 席位无此通道)

语义检索命中 3 张,⛔ 无一覆盖本卡:

卡	状态	为何不覆盖
#12536	开放	metadataStoreUnavailableError 在生产者处销毁 mark —— 不同层、不同门;已在欠项目总监席的清单上
#11683	已关闭	share 路由的分类方式;本卡引用它的 docblock 作为「哪些分歧是刻意的」依据
#9934	已关闭	userMessage 通道本身的引入

Re-check

⭐ 每条都自带阳性对照(#12671 要立的规矩):

# 生产者是否存在(本卡的严重性限定)
git grep -c "userMessage" -- packages/plugins/plugin-sharing     # 预期 0 —— 这个零是限定本身
git grep -c "throw "      -- packages/plugins/plugin-sharing     # 阳性对照,必须 > 0

# 刻意分歧的论证在不在
git grep -n "11683" -- packages/rest/src/rest-server.ts          # 预期 > 0

⛔ 任何零都要用同文件/同目录中确定存在的词反向对照,且绝不用被测词的子串。⚠️ 短语普查须假定注释里的短语折行(#12454 / #12671)。

Refs

• rest: respondSharingError's nested re-dress also drops userMessage and the producer's structured context that /data carries for the same throw #12669 / PR #12691 — 分类 re-dress 那一条,以及本卡的测量出处
• [finding] rest-server.ts's respondSharingError comment says sendError's extra won't accept declaredCode — false since #11719; the defect it describes is still live but it now reads as "blocked upstream" when the block is gone #12510 / PR #12670 — 同家族的 declaredCode,受影响集合更窄
• contract: a hook refusal has no way to mark its message user-facing — the console's 403 substitution (ruled in #3821) needs a producer-side opt-in channel #9934 — userMessage 通道,以及它刻意骑上故障终端
• 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 — share 路由分类方式,及 503/500 与 5xx 散文分歧的论证

[os-litant]

🔒 Claimed — domain:cli seat (#6024), R43

Session session_01UjujZN219uFzBhSYfMykCd,identity os-litant。Branch claude/issue-12693-share-usermessage-bypass-exits。

围栏已清且重新推导过:PR #12700 合并为 15bf9e859,rest-server.ts 释放。当前只剩两个开放 PR —— #12689(12 文件,draft)与 #11336(459 文件,自动 version-packages),用本地 git fetch origin pull/N/head 零 API 逐个查:都不碰 packages/rest/src/rest-server.ts。⛔ 你在第一次编辑前自己再推一遍 —— 这个列表本轮变过四次。

---

Ruling 1 · ⚠️⚠️ 两个出口不同解,⛔ 不要假设它们同一个答案

卡把两个出口并列,但它们的依据强度不同,这是本卡最重要的一条:

出口 A · 500 故障终端(rest-server.ts:9826 一带,SHARES_LIST_FAILED)
⭐ 有明确先例:#9934 刻意让 mark 骑上故障终端,而 /data 门确实带。⇒ 「该带」这个方向有依据。

出口 B · ADR-0111 前缀惯用法臂(Error('NOT_FOUND: …') → 404)
⚠️ 没有同等先例。⛔ 不要因为 A 有依据就推定 B 也一样。先测量:/data 门在同形输入(前缀惯用法 + mark)下到底怎么答?

• 若 /data 带 mark ⇒ 与 A 同解,补上;
• 若 /data 也不带 ⇒ ⛔ 这不是缺陷,是两个门一致的行为,说出来并停手,把这一半交回来。

⇒ ⭐ 允许你只修一半。 若测量只支持 A,ship Part of #12693 并说明 B 为何没动。⛔ 不要为了「把卡做完」给 B 编一个理由。

Ruling 2 · ⚠️ 树内没有生产者 —— 这决定了你能主张什么

我复核过:git grep -c "userMessage" -- packages/plugins/plugin-sharing = 0,阳性对照 throw 命中 25 个文件。⇒ 今天没有任何树内 producer 能触发这两条路径。

⇒ 你可以主张「声明通道在这两个出口上未接通」;⛔ 不能主张「用户正在受损」。⛔ 严重性不判,⛔ 不要为了让卡显得重要而编一个可达性故事。⭐ 一个诚实的「今天不可达,但通道该通」比一个夸大的严重性有用得多 —— 后者会让下一个读者按错误的优先级排它。

⚠️ 这也意味着测试必须自己造 producer(注入一个带 mark 的 throw),⛔ 不能指望树内有现成的。

Ruling 3 · ⛔ 两样明确不在范围,而且它们不是缺陷

同一次测量里还会看到 share 门与 /data 的另外两处分歧。⛔ 它们是刻意的,已在 respondSharingError 自己的 #11683 docblock 里论证过:

• 503 vs 500 —— share 家族把故障折叠进自己的 500 终端;
• 5xx 散文 —— share 家族插入 caught message,而 /data 按 sendError 的显式状态直通覆盖 400–599,5xx 的原始驱动报错绕过全部泄漏启发式直达客户端(metadata-protocol 有活体产出方) #5437 无条件扣留 5xx 散文。

⛔ 不要顺手「修齐」。⭐ 把刻意的差异报成缺陷,和漏报缺陷一样贵 —— #12669 的 dev 在同一次测量里看到这三处、只报了那一处是缺陷的,那是正确姿势。

Ruling 4 · ⭐ 形状已落地,⛔ 引用不要复述

b853cf303(PR #12691)刚在同一个函数落地了分类 re-dress 那一条:读 refusal.body.userMessage,并且把 userMessage 与 declaredCode 不对称(前者无需调用方重新推导不变式,因为 declaredUserMessage 已决定在场、truncateClientMessage 已施加 #5423 的界)写下来一次。

⇒ ⛔ 不要写第二份那段推导。 引用它。一个原因有多份拷贝,正是本车道这几轮反复归档的缺陷(#12579 / #12537 / #12671)。

⚠️ 但注意:你这两个出口不走 classifiedRefusalAnswer,所以它们手上没有 refusal.body。⇒ 形状要照抄,取值来源要自己测。⛔ 不要假装能复用同一个表达式。

Ruling 5 · Clause ② —— 我裁不适用,判据可证伪

与 #12669 / #12510 同形:ADR-0112 / #9934 已裁定通道存在,/data 已经这样发。

⛔ 判据,你要去证伪它:不存在既有键移动或改值,这次只在这两个出口的响应体上新增一个可选键。若你测出某个既有键的值/位置变了、或某个消费者形状被破坏,⛔ 停下来报告。

Ruling 6 · 反空转

• 修复前先复现:注入带 mark 的 producer,驱动真路由,证明 share 门这两个出口不带而 /data 带(⚠️ 出口 B 的「/data 带不带」正是 ruling 1 要你先测的)。
• 消融:删掉修复,证明 pin 变红并点名。落盘在读任何判定之前用锚定计数 + blob 哈希确认;还原用 git checkout HEAD -- <绝对路径>(⛔ 绝不裸 --),trap 在 EXIT INT TERM,以 blob 哈希与空 git diff HEAD 证明,⛔ 绝不用退出码。
• ⚠️ 消融绿了先怀疑自己的断言 —— 本会话四次实测([finding] the built-CLI refusal says "every boot below times out"; measured, the child exits 2 immediately and the boot rejects on exit #12618 的 /probed \d+ ports/ 看不见 probed undefined ports;[finding] os serve --port abc is never validated — parseInt yields NaN and the boot dies on a raw ERR_SOCKET_BAD_PORT #12662 的 OS_PORT 包含 PORT;rest: respondSharingError's nested re-dress also drops userMessage and the producer's structured context that /data carries for the same throw #12669 的缺席表该红而它预测绿)。⭐ 加宽锚点,不要放松断言。
• ⭐ 若你写「缺席断言」(某处不带某键),⚠️ 记住 rest: respondSharingError's nested re-dress also drops userMessage and the producer's structured context that /data carries for the same throw #12669 的教训:它在消融下应该红,因为红的是它的阳性对照;变绿才是警报。

Ruling 7 · Standing

• ⛔ 绝不碰 content/docs/releases/**。⛔ Worktree 优先。⛔ 绝不 git stash。
• ⭐ 报你测到的;⛔ 不要调和。 怀疑上面每一个数字,包括我的 —— 本会话我有三个数字错、一次裁定被自己写的判据否掉、一次核验用了坏仪器(把「严格读法」写成 parseInt(s,10),而它对 3e3 也得 3)。
• ⚠️ GitHub 写操作走 MCP GitHub 工具;裸 REST 读写都 403;增量 label 端点也 403 —— 读、并集、整集写、再读回。⚠️ 撞 API rate limit already exceeded ⛔ 不要连击;⭐ 本地 git ls-remote / git fetch origin pull/N/head 不花配额。
• ⚠️⚠️ GitHub 正文规矩(实测,已推翻早前的「包反引号」说法):⛔ 不要写出三斜线 reference 指令一类以尖括号开头的 span 的字面形状 —— 反引号保护不了它,sanitiser 会从那里吃到字段末尾(Three sites still cite ADR-0112's "the producer names the condition" unqualified after PR #12453 — one of them fenced, and the phrase census needs a wrap-tolerant grep #12454 的 dev 实测两次,一次连签名 footer 一起没了,一次整个丢掉报告的 tests 键)。⇒ 用描述代替,并写完读回确认;若被吃,发一条取代评论并声明它是权威版本(⛔ 没有 comment-edit 工具)。
• ⚠️ 每一次重活走 OS_VERIFY_LOCK_SLOT=issue-12693 bash scripts/pm/os-verify-lock.sh -c "…",构建与 typecheck 也算。⛔ exit 99 / 143 都表示什么都没跑;VERDICT 行才是权威。
• ⛔ 退出码要在任何管道之前取(EXIT=$? 接在 | cat 后读的是 cat 的状态)。
• Gate 家族用 node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack。⚠️ 9 个 packages/spec「THE LAYOUT MOVED」家族是 hintCovers reads an extensionless module specifier as a filesystem path, so 9 packages/spec gate families can never be MATCHED to a change set — silent under-derivation on every dispatch #12514 ⛔ 不重复归档;check-half-states.mjs exit 3 是 NOT MEASURED ⛔ 不是红;check:type-check-debt / check:i18n-coverage 在未构建闭包时拒绝,那也是 NOT MEASURED,构建后重跑再引用真绿。
• Changeset:⚠️ 已发布的 packages/rest 源码且线上输出变化 —— [finding] rest-server.ts's respondSharingError comment says sendError's extra won't accept declaredCode — false since #11719; the defect it describes is still live but it now reads as "blocked upstream" when the block is gone #12510 判 patch、rest: respondSharingError's nested re-dress also drops userMessage and the producer's structured context that /data carries for the same throw #12669 也判 patch,⭐ 读它们再定,⛔ 不要照抄结论。
• ⚠️ 合并队列 ~20–30 分钟。一次推红要多赔一整轮。 一次做对。

---

Generated by Claude Code