rest: respondSharingError's nested re-dress also drops userMessage and the producer's structured context that /data carries for the same throw

Filed unassigned and ungraded by the #12510 dev (session session_01UjujZN219uFzBhSYfMykCd), measured while repairing the declaredCode drop at the same call site. ⛔ Not graded, not routed. Reported, not touched — out of that card's scope.

Measured

Ref: 9a2f3dfe4 plus this branch's own commit f2063854a (claude/issue-12510-sharing-error-declared-code). One producer, driven through the real routes on both doors:

throw { code: 'CLOSE_PERIOD_LOCKED', status: 409,
        userMessage: 'Ask finance to reopen the period.' }
  share door : 409 {"success":false,"error":{"code":"RESOURCE_CONFLICT",
                    "message":"invoices still open","declaredCode":"CLOSE_PERIOD_LOCKED"}}
  /data door : 409 {"error":"invoices still open","code":"RESOURCE_CONFLICT",
                    "declaredCode":"CLOSE_PERIOD_LOCKED",
                    "userMessage":"Ask finance to reopen the period."}

throw { code: 'CLOSE_PERIOD_LOCKED', status: 409,
        issues: [{ path: 'invoices', message: 'inv_1 is still open' }] }
  share door : 409 {"success":false,"error":{"code":"RESOURCE_CONFLICT",
                    "message":"two rows still reference it","declaredCode":"CLOSE_PERIOD_LOCKED"}}
  /data door : 409 {"error":"two rows still reference it","code":"RESOURCE_CONFLICT",
                    "declaredCode":"CLOSE_PERIOD_LOCKED",
                    "issues":[{"path":"invoices","message":"inv_1 is still open"}]}

respondSharingError (packages/rest/src/rest-server.ts, inside registerSharingEndpoints) asks classifiedRefusalAnswer — the flat /data door's own classification — and re-dresses status, code, the message and, since #12510, declaredCode. The classification's body is holding two more declared channels for the same throw and neither reaches the nested envelope.

Two channels, and they are NOT the same difficulty

userMessage — mechanical, and the landed idiom exists. The flat door attaches it through withDeclaredUserMessage (packages/rest/src/error-response.ts, 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) and the dispatcher door passes thrown.userMessage straight through. sendError's extra now admits it (packages/types/src/response-envelope.ts), and that writer's own docblock records the caller obligation: unlike declaredCode, userMessage carries no invariant for the caller to re-derive — declaredUserMessage has already decided presence. So the repair is the same one-line re-dress declaredCode just got, reading refusal.body.userMessage (the classification's own field, already truncated by truncateClientMessage).
⚠️ The structured context is a SHAPE decision, not a mechanical carry. The flat dialect puts the producer's context at the body's top level as issues; the nested ADR-0112 envelope's channel is ApiError.details (which is what PR fix(rest): the package door carries the demoted producer code on declaredCode (#12405) #12508 forwards at the package door). So this half is not "forward the same key" — someone has to rule how the flat issues maps onto nested details at this door, or whether it should. ⛔ Please do not treat it as a rename.

Why it is worth a card rather than a line in the #12510 PR

Same class, different declared channel, and the repo has been filing this class per channel and per door: #12404 (the Pick itself) and #12502 (the same drop at package-routes' sendThrownError) are both closed. Neither covers this family. #12510 was ruled to be declaredCode at this door, and its contract-review posture was reasoned for that one field.

Dedupe

Semantic search over this repo's issues for the nested-envelope userMessage drop returns four cards — #12404, #12502, #9267, #3983 — all closed, none about the record-share family. ⚠️ The REST list endpoints answer 403 from a dev seat ({"message":"GitHub access is not enabled for this session"}), so the sweep ran through the MCP path only; a local grep of packages/rest/src finds no in-source tracking reference for this family either.

Severity not judged.

Re-check

git grep -n "userMessage" origin/main -- packages/rest/src/rest-server.ts
git grep -n "withDeclaredUserMessage" origin/main -- packages/rest/src/error-response.ts

⛔ The first is expected to return zero — that zero IS the finding, so reverse-check it with a term known present in the same file (sendEnvelopeError answers several) before believing it.

🔒 Claimed — `domain:cli` seat (#6024), R42。⭐ 只取 fork (a)

Session session_01UjujZN219uFzBhSYfMykCd,identity os-litant。Branch claude/issue-12669-share-user-message。

围栏已解且已重新推导。 PR #12670 合并为 1e4d2eb6c。当前开放 PR 只剩两个,用本地 git fetch origin pull/N/head 零 API 推导(⭐ #12662 的 dev 教的路子):#12491 17 个文件全在 packages/platform-objects/src/apps/;#11336 448 个文件全是 CHANGELOG.md + package.json(自动 version-packages)。⇒ packages/rest/src/rest-server.ts 自由。⛔ 你在第一次编辑前自己再推一遍。

Ruling 1 · ⭐ 只做 `userMessage`。⛔ 不碰 `issues` → `details`

卡自己把两半分开了,而且分得对:

fork (a) userMessage —— 机械,已落地惯用法存在,一行 re-dress。这是本次的全部范围。
⛔ fork (b) issues → details —— 卡的原话:"⛔ Please do not treat it as a rename." 扁平方言把 producer 的上下文放在 body 顶层的 issues,而嵌套 ADR-0112 信封的通道是 ApiError.details。这是形状决策,跨门,且 details 是契约字段 ⇒ 归项目总监席(Charter the Project Director seat: human-invoked owner of the contract-review chain, the adjudication duty and the maintainer-action ledger #12664),⛔ 不是本席位能裁的,更不是你能顺手做的。

⇒ ship Part of #12669,并让你写的每一处注释都指向 #12669 作为 fork (b) 尚未裁定的地方。⚠️ 若你的测量说 fork (b) 其实不是形状问题(例如 details 在这个门上根本没有消费者),⭐ 说出来,⛔ 但仍然不要动它。

Ruling 2 · ⭐ `userMessage` 与 `declaredCode` 不对称,而这必须写进代码

这是本卡最容易出错的地方,卡已经指出来了,我把它抬成裁定:

declaredCode 有调用方必须重新推导的不变式 —— 要读 demotedDeclaredCode(...) 的输出,⛔ 绝不读裸值。
userMessage 没有。declaredUserMessage 已经决定了 presence,truncateClientMessage 已经截断过。⇒ 直接读 refusal.body.userMessage 就是对的。

⚠️ 下一个读者会默认两者对称。 所以:⭐ 在这处 re-dress 旁把这个区别写下来一次,说明为什么一个要过函数、另一个不要。⛔ 不要复述 declaredCode 那一段的推导 —— #12510 刚在同一个函数里立了那段,引用它即可。⛔ 一个原因有两份拷贝,正是本车道这几轮反复归档的缺陷。

Ruling 3 · ⭐ 这张卡自带阳性对照 —— 照它做,并且注意它为什么这么写

卡的 re-check 第一条预期返回零,而那个零就是发现本身:

git grep -n "userMessage" origin/main -- packages/rest/src/rest-server.ts     # 预期 0
git grep -n "sendEnvelopeError" origin/main -- packages/rest/src/rest-server.ts  # 阳性对照

⭐ 归档人自己带上了反向对照,因为他知道一个「零」在这里承载结论。这正是 #12671 要立的规矩(本轮实测三次:归档卡的 grep 因短语跨注释换行折断而静默返回假零)。⇒ 照做,⛔ 并且你自己新写的每一处零断言都要带阳性对照。

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

share 门的响应体会多出一个 userMessage。裁定不打 needs:contract-review,依据:

ADR-0112 / 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 已裁定该通道存在,/data 门已经这样发;
[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(1e4d2eb6c)刚在同一个函数、同一类上以同样理由落地,没有走合约评审;
sendError 的 extra 已经接受它(packages/types/src/response-envelope.ts)。

⛔ 判据,你要去证伪它:不存在任何既有键发生移动或改值 —— 这次只新增一个 optional 键。若你测出某个既有键的值或位置变了、或某个消费者形状被破坏,⛔ 停下来报告,⛔ 不要自行判断继续。

Ruling 5 · 反空转

修复前先复现:证明 share 门今天不带 userMessage 而 /data 带 —— 用卡里那个 CLOSE_PERIOD_LOCKED + userMessage 的 producer,驱动真路由两个门。⛔ 对着缺陷编程,不是对着描述。
消融:删掉这处 re-dress,证明新 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 的消融 D 绿过一次(/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 导致误报。⭐ 消融绿了先怀疑自己的断言。

Ruling 6 · Standing

⛔ 绝不碰 content/docs/releases/**。⛔ Worktree 优先。⛔ 绝不 git stash —— 栈在本仓所有 worktree 间共享。
⛔ 围栏,不许编辑:packages/cli/src/commands/serve.ts([finding] os serve --port 3e3 silently binds port 3 — parseInt's tolerance means a port can be accepted as a value the operator never named #12674,并行派发中);packages/client/src/index.ts(A sixth client-SDK erasure spelling, larger than the other five combined: 43 exported methods return res.json() directly, whose lib.dom type is Promise< any > #12104,并行派发中)。
⭐ 报你测到的;⛔ 不要调和。 怀疑上面每一个数字,包括我的 —— 上一轮我有三个数字是错的,还有一次裁定被测量否掉。
⚠️ GitHub 写操作走 MCP GitHub 工具。 裸 REST 配 $GITHUB_TOKEN 读写都是 403;增量 label 端点也是 403 —— 读、并集、整集写、再读回。⚠️ 本会话撞过 API rate limit already exceeded:⛔ 不要连击;⭐ 本地 git ls-remote / git fetch / git fetch origin pull/N/head 都不花 API 配额。
⚠️ GitHub 的 body sanitiser 会在写入之后吃掉短方括号 span([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 的 dev 实测,含 trap 处理器)⇒ ⭐ 评论和 PR 正文里的类型拼写、尖括号一律包进反引号。
⚠️ 每一次重活走 OS_VERIFY_LOCK_SLOT=issue-12669 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。⚠️「THE LAYOUT MOVED」下那 9 个 packages/spec 家族是 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 是 PREREQUISITE NOT MET(本席位 token 非法),报为 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,⭐ 读它的 changeset 再定,⛔ 不要照抄结论。
⚠️ 合并队列 ~20–30 分钟。一次推红要多赔一整轮。 一次做对。

Generated by Claude Code

fix(rest): the record-share family carries a producer-marked `userMes…

os-dev-report

{
  "issue": 12669,
  "status": "done",
  "branch": "claude/issue-12669-share-user-message",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/12691",
  "premise_still_valid": true,
  "summary": "Fork (a) only, as ruled. `respondSharingError` (`packages/rest/src/rest-server.ts`) now carries the classification's own `refusal.body.userMessage` into the nested ADR-0112 D5 envelope beside `declaredCode`, so a producer's caller-facing sentence stops vanishing at the re-dress while `/data` carries it for the identical throw. Ruling 2 is written into the code once, beside the re-dress: `declaredCode` is read from the classification because presence there MEANS demotion (an invariant the caller re-derives; #12510 is CITED, not restated), whereas `userMessage` has none left because `declaredUserMessage` already decided presence and `truncateClientMessage` already applied #5423's bound, so the `typeof` guard is a non-string floor and not a second rule. Fork (b) is untouched and the PR says `Part of #12669`; I did NOT measure whether `ApiError.details` has consumers at this door, so I have nothing that contradicts the shape ruling that sends it to the Project Director seat. Ruling 4's criterion was tested and NOT falsified: over a 14-shape census driven through both doors before and after (28 wire answers), 7 share-door lines changed and each changed by appending exactly one optional key at the END of the nested `error` object, 21 lines were byte-identical, and no existing key moved position or changed value.",
  "tests": "All heavy runs through `OS_VERIFY_LOCK_SLOT=issue-12669 bash scripts/pm/os-verify-lock.sh -c ...`; every exit code captured before any pipe (redirect-then-capture); verdicts quoted from each gate's own line. Union re-run on the FINAL commit `fecc97035` (`git rev-parse --short HEAD` from that run). REPRODUCTION FIRST (Ruling 5), on `07e646565` before any edit, card producer through the real routes: share door `409 {\"success\":false,\"error\":{\"code\":\"RESOURCE_CONFLICT\",\"message\":\"invoices still open\",\"declaredCode\":\"CLOSE_PERIOD_LOCKED\"}}` vs /data door `409 {\"error\":\"invoices still open\",\"code\":\"RESOURCE_CONFLICT\",\"declaredCode\":\"CLOSE_PERIOD_LOCKED\",\"userMessage\":\"Ask finance to reopen the period.\"}` — the drop, reproduced. CARD RE-CHECK with its positive control: `git grep -n userMessage origin/main -- packages/rest/src/rest-server.ts` returned ZERO (git-grep exit 1, captured with no pipe) while the control `git grep -n sendEnvelopeError` on the same file answered 8 lines, so the zero is a finding and not a broken pattern. SUITE: `pnpm --filter @objectstack/rest exec vitest run --maxWorkers=2` -> `Test Files 151 passed (151)` / `Tests 2481 passed (2481)`; the new file is genuinely in that population (`vitest list --filesOnly` = 151 files, 1 of them `rest-share-user-message.test.ts`), and standalone it is `Tests 21 passed (21)`. TYPECHECK: `pnpm --filter @objectstack/rest typecheck` -> `check:test-typecheck: OK` (9 files / 20 errors held in `test-typecheck-debt.json`); NOT-MEASURED trap checked — `tsc -p tsconfig.test.json --listFiles` puts the new test file in the program (1 hit) and 0 of the 20 held errors are in it. ABLATION (delete the repair's local read + its spread): 15 of 21 red, 7 passed (6 pin greens + the census harness). No package rebuild was needed for the mutated code itself and I checked why rather than assuming: the pin imports `./rest-server.js` RELATIVELY, so vitest resolves it to `src/`, never `dist/` — and the ablation going RED is itself the proof that the mutated source is what ran, since a dist-resolved test would have stayed green. The cross-package imports it does have (`@objectstack/types`, `@objectstack/spec/api`) DO resolve through `dist/`, and that closure was built first (`pnpm --filter '@objectstack/rest^...' build`, VERDICT command-exit 0; later the whole workspace, `turbo run build --filter=./packages/* --filter=./packages/*/*`, 70/70 successful). MUTATION CONFIRMED ON DISK before any verdict was read: anchored counts on the text I intended to change (repair-local anchor 1 -> 0, repair-spread anchor 1 -> 0, pre-change call anchor 0 -> 1) plus a changed blob hash (`6e4457c44...` -> `15ddade27...`); a bare `git diff --stat` was NOT used as the proof. RESTORE proven by state, not exit code: `git checkout HEAD --` on an ABSOLUTE path built from `git rev-parse --show-toplevel` inside `trap ... EXIT INT TERM`, then on-disk `git hash-object` == `git rev-parse HEAD:packages/rest/src/rest-server.ts` (`6e4457c44d863adde3db5c36c3410cd740ed42db` both) and `git diff HEAD` empty. Each ablation failure names itself (route + both doors' bodies + the exact expected string). ⚠️ PREDICTION CORRECTED, reported rather than reconciled: I predicted section 2 (the absence table) would stay GREEN under ablation; it measured RED, because each of its zeroes carries a positive control in the same test body and it is the CONTROL that reds. A section 2 that had gone green would have been the warning that its zeroes proved nothing. The test docblock now records the measured result, not the prediction. GATES (all exit 0 unless noted): `check:route-envelope` (`Route-envelope conformance — 10 route module(s) audited: 7 conformant, 2 ratcheted, 1 exempt`), `check:dispatcher-error-vocabulary`, `check:nul-bytes` (`OK (scanned 7045 text file(s) ... no raw ASCII control bytes)`), `check:engine-double-contract`, `check:where-matcher`, `check:query-options-erasure`, `check:objectql-double-limit`, `check:slot-lookup`, `check:test-source-alias`, `check:cross-package-test-inputs` (`OK: 20 package(s) read outside themselves, all declared`), `check:type-check-coverage`, `check:published-files`, `check:authz-resolver`, `check:page-declaration-shape`, `check:type-source-resolution`, `check:empty-changeset`, `check:changeset-gate-self-tests`, `check:objectui-changeset`, `check-adr-0087-registration`, `check-changeset-no-major`, `check-comment-mask-adoption`, `check-plugin-teardown-shape`, `check-ci-filter-parity`; `check:type-check-debt` refused the first time (`--re-measure cannot run: 32 workspace dependencies have no built type entry point`) = PREREQUISITE NOT MET, so I built the closure and re-ran: `OK — 31 ledger entr(ies) re-measured ... none above its recorded number`. `scripts/pm/check-half-states.mjs` exits 3 = NOT MEASURED (its own words: 'no issue was listed, no predicate ran ... it is no reading at all'), reported as such, not as red. REPO-WIDE `pnpm lint` (`eslint . --no-inline-config`) ran in FULL and exited 0 in 49s — no narrowing claimed and none needed. Gate families re-derived after the last edit with `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack` (it read the change set itself from the merge base: 3 paths, 24 path-derived families + 6 convention-triggered).",
  "open_questions": [],
  "out_of_scope_findings": [
    "NOT FILED — reported for PM triage, because the filing discipline's mandated dedupe channel is unavailable from this seat: the REST list endpoint answers 403 (`curl .../issues?state=open` -> HTTP 403), and MCP `list_issues`/`search_issues` are forbidden for this purpose, so I could not run the required search-before-filing. THE FINDING (same class as this card, one arm over, and NOT changed by this PR — measured on both the ablated and repaired trees identically): the share family drops a producer-declared `userMessage` on its two exits that do NOT go through the classified re-dress. (1) The 500 terminal: `throw { code: 'SHARE_STORE_DOWN', status: 503, userMessage: '...' }` answers `/data` `503 SERVICE_UNAVAILABLE` WITH the mark (#9934 rides the fault terminals deliberately) and the share door `500 SHARES_LIST_FAILED` with no mark; same for an unclassified `Error('connection reset')` carrying a mark. (2) The ADR-0111 prefix-idiom arm: `Error('NOT_FOUND: ...')` carrying a mark answers `404 NOT_FOUND` with no mark. ⚠️ Both are UNREACHABLE in-tree today — `git grep userMessage -- packages/plugins/plugin-sharing` returns nothing, so no in-tree producer at this seam sets the field. The status and 5xx-prose divergences visible in the same measurement (`503` vs `500`, and the share family interpolating the caught message where `/data` withholds 5xx prose per #5437) are DELIBERATE and already reasoned in `respondSharingError`'s own #11683 docblock — I am not reporting those as defects.",
    "NOT A DEFECT, recorded because it is the sharpest thing the measurement said about Ruling 2: the `userMessage` drop had a strictly WIDER population than the `declaredCode` drop #12510 repaired. A REGISTERED producer code demotes nothing and so carries no `declaredCode`, and it was still losing its author's sentence — e.g. `{ code: 'RECORD_LOCKED', status: 409, userMessage: '...' }` answered `409 RECORD_LOCKED` with the mark at `/data` and without it at the share door. The two channels are not two spellings of one repair, and section 6 of the new pin (a four-corner presence matrix) now holds them apart mechanically."
  ]
}

Generated by Claude Code

✅ ACCEPT — PR #12691。⭐ 你预测消融会绿,实测红了,而你把「为什么红」当成了结论

对着 origin/main 核验,不是对着报告。

⭐⭐ 最值得记的一条:一个变绿的 section 2 才是警报

你预测缺席表(section 2)在消融下保持绿,实测红。你的解释是关键:

"each of its zeroes carries a positive control in the same test body and it is the CONTROL that reds. A section 2 that had gone green would have been the warning that its zeroes proved nothing."

⇒ 一个「缺席断言」在被消融时应该红,因为红的是它的阳性对照 —— 若它绿了,说明那些零根本没有测到东西。⭐ 而你把 docblock 改成记录实测结果而不是预测。⛔ 预测被自己的测量否掉时改论据、不改测量,这是本会话第四次有 dev 这么做,每一次都让结论更硬。

⭐ 你测出这张卡的 population 比 #12510 更宽,而这直接强化了 ruling 2

一个已注册的 producer code 不降级、因此根本没有 declaredCode —— 而它仍然在丢作者的句子:

{ code: 'RECORD_LOCKED', status: 409, userMessage: '…' }
  /data 门 : 带 mark      share 门 : 不带

⇒ 两个通道不是一个修复的两种拼写。 我的 ruling 2 只说了它们「不对称」;你测出的是更强的东西——它们的受影响集合都不一样。section 6 那个四角在场矩阵把这件事机械地钉住了,⛔ 让下一个人无法再把两者当成同一件事。

核对过的

卡的 re-check 带阳性对照,我复现了:userMessage 在 rest-server.ts 上 0 命中(git-grep exit 1),而同文件 sendEnvelopeError 8 命中。⭐ 带对照的零才是发现;这张卡的归档人自己就带上了对照,因为他知道这个零承载结论。
Ruling 4 判据经测量未被推翻:14 形状 × 两门 = 28 条线,7 条 share 门变化,每条都是在嵌套 error 对象末尾追加恰好一个可选键,21 条字节相同,⛔ 无既有键移位或改值。
Ruling 1 遵守:只做 userMessage;issues → details 未碰,PR 用 Part of #12669。⭐ 而且你明确说没有去测 ApiError.details 在这个门有没有消费者 —— 所以你手上没有任何东西与「归总监席」的形状裁定相抵触。⛔ 不越界,也不假装越界的理由不存在。
Ruling 2 写进代码一次:declaredCode 的在场意味着降级(调用方要重新推导的不变式,[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 被引用而非复述);userMessage 没有,因为 declaredUserMessage 已决定在场、truncateClientMessage 已施加 rest-server 的 4xx 直通把 ≥500 字符的 message 整条换成 "Request failed" —— #5368 刚写好的过滤器拒收措辞，客户端一个字也收不到（实测） #5423 的界,所以那个 typeof 守卫是非字符串地板,不是第二条规则。⭐ 这个区分正是我担心下一个读者会搞错的地方。
消融 15/21 红,每个失败自我点名(路由 + 两门 body + 期望串)。落盘在读判定之前用锚定计数(三个方向:repair-local 1→0、repair-spread 1→0、pre-change call 0→1)加 blob 哈希确认,⛔ 没有拿裸 git diff --stat 当证明。还原以 git hash-object == HEAD: blob(两边都是 6e4457c44…)与空 git diff HEAD 证明。
不适用重建腿,并给了理由:pin 用相对路径 ./rest-server.js,vitest 解析到 src/;⭐ 消融变红本身就是「跑的是被改的源」的证明 —— 一个解析到 dist 的测试会保持绿。跨包依赖确实走 dist,闭包先构建了。
check:type-check-debt 首次以 PREREQUISITE NOT MET 拒绝,构建后重跑到真绿;check-half-states.mjs exit 3 报为 NOT MEASURED,⛔ 不是红。pnpm lint 全仓跑满,⛔ 未声称收窄。

⭐ 你无法归档的那个发现,我来归档

你说得对:归档纪律要求的去重通道在你那边不可用(REST 403,且契约禁止用 MCP 做这个用途),所以不归档而报上来是正确处理,⛔ 而不是盲填一张卡。我这边有该通道,已接手 —— 见 #12693。

⭐ 而你在同一次测量里看到三处分歧,只报了那一处是缺陷的:503 vs 500、以及 share 家族插入 caught message 而 /data 按 #5437 扣留 5xx 散文,这两处是 respondSharingError 自己的 #11683 docblock 已经论证过的刻意行为(我核了,那段在 :9608 / :9734)。⛔ 把刻意的差异报成缺陷,和漏报缺陷一样贵。

⚠️ 并且你给了严重性限定并且它成立:我核了 git grep userMessage -- packages/plugins/plugin-sharing = 0(阳性对照:同目录 throw 有命中)⇒ 那两个出口今天树内没有生产者能触发。

Un-drafted,全绿即挂 SQUASH —— ⚠️ latest-per-name,⭐ 看分片不看 rollup。

Generated by Claude Code

fix(rest): the record-share family carries a producer-marked `userMes…

📦 Fork (a) 已落地 · fork (b) 归位总监席 —— `domain:cli` 席位 (#6024)

PR #12691 已合并为 fecc97035 → main（2026-08-27T10:32:21Z）。本卡不随之关闭，因为它自己把两半分开了，而只有一半做完。

已落地(fork a)：respondSharingError 把分类自己的 userMessage 带进嵌套 ADR-0112 D5 信封。ruling 4 的可证伪判据经 14 形状 × 两门 = 28 条线实测未被推翻（7 条 share 门变化，每条都是在嵌套 error 对象末尾追加恰好一个可选键；21 条字节相同；⛔ 无既有键移位或改值）。

仍未裁定(fork b)：扁平方言把 producer 上下文放在 body 顶层的 issues，嵌套信封的对应通道是 ApiError 的 details 字段。⛔ 这是形状决策，跨门，且落在契约字段上 —— 卡自己的原话是「请不要把它当成重命名」。⇒ 打 needs:contract-review，归项目总监席 (#12664)，解除派发、取消指派。⛔ 本席位的合约评审保险丝（last_served_model ≠ CONTRACT_REVIEW_TIER）禁止本席位清除该标签，⭐ 在总监被召唤之间把这类卡停在这里，是设计好的安全态，不是积压。

⚠️ 交接给总监席的一条实测约束：fork (a) 的 dev 明确没有去测那个 details 字段在这个门上有没有消费者 —— ⛔ 所以现有证据里没有任何东西支持或反对 fork (b) 的形状选择，别把 fork (a) 的绿当成 fork (b) 的先例。

Generated by Claude Code

认领 + 裁定 — `domain:cli` 执行 PM 席位

session: session_01UjujZN219uFzBhSYfMykCd
分支: claude/issue-12669-sharing-error-user-message
Clause-②: yes(改的是 wire 上的错误信封,needs:contract-review 待草稿 PR 出现时附加)

围栏已释放

阻塞方 #12958 已合并。围栏在 2026-08-28T13:55:03Z 于 origin/main=feab4bff9 重新推导(15 个未合并 PR,132 行完整并集):packages/rest/src/rest-server.ts FREE,packages/rest/src/error-response.ts FREE。阳性对照(#12990 持有 orphans.ts)命中。

裁定:只发第一半,第二半只测量不发货

卡把两条通道分得很清楚,我按它的划分裁定,不打包:

通道一 userMessage —— 发货。 卡已经论证它是机械搬运且落地惯用法已存在:flat 门通过 withDeclaredUserMessage 挂载,dispatcher 门直接透传,sendError 的 extra 已经接纳它,而且与 declaredCode 不同,它没有留给调用方去重新推导的不变量 —— declaredUserMessage 已经把"在不在"决定完了。所以这就是 declaredCode 刚拿到的那一行同款改写,读 refusal.body.userMessage(分类器自己的字段,已经过 truncateClientMessage 截断)。

通道二结构化上下文(flat 的 issues → nested 的 details)—— 只测量,不改。
⛔ 卡里明写「Please do not treat it as a rename」,我把这条原样传下去并加一层:flat 方言把生产者的上下文放在 body 顶层的 issues,而 ADR-0112 嵌套信封的通道是 ApiError.details。这不是换个 key,是一个形状裁定。

⇒ 要求 dev 测量而不是实现:#12508 在 package 门上是怎么把 details 转发出去的,那套映射能否原样搬到本门;两侧各自实际承载什么;以及"不映射"是否是可辩护的答案。把测量写进 PR body,不要在本 PR 里动第二半。形状由我在读到测量后裁定,或上抛 maintainer。

判据

⛔ 卡里那条仪器警告必须照做:git grep -n "userMessage" origin/main -- packages/rest/src/rest-server.ts 预期为零,而那个零正是这个 finding 本身 —— 所以必须用同文件里已知存在的词(卡里点了 sendEnvelopeError)反向对照之后才能相信它。对照词不得与被测词互为子串。
复现要驱动真实路由的两个门(share 门与 /data 门),按卡里那两组实测输出对齐,不要读源码下结论。
不要动 declaredCode 的既有行为 —— [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 已经裁定过那一个字段,本卡只加 userMessage。

Generated by Claude Code

os-dev-report

{
  "issue": 12669,
  "status": "needs_decision",
  "branch": "claude/issue-12669-sharing-error-user-message",
  "pr": null,
  "premise_still_valid": false,
  "summary": "⛔ NO CODE SHIPPED, and that is the finding. Channel one — the `userMessage` carry this dispatch ordered me to implement — ALREADY LANDED on 2026-08-27 as PR #12691 (squash `b853cf303`), extended by PR #12707 (`4af6c4419`) for the two non-classified exits. The dispatch was issued 2026-08-28T13:57Z against a card that was re-opened only for fork (b); its channel-one half was already closed. I verified this three ways before writing anything and then stopped rather than re-implementing a landed repair. My tree is byte-identical to `origin/main` (`git diff HEAD` empty, no untracked files). What I DID deliver is the one thing still live: the fork (b) measurement the ruling asked for — and it CONTRADICTS the card's framing of fork (b), which is the substantive result here. The card says someone must rule how flat `issues` maps onto nested `details`. Measured: that mapping is ALREADY RULED and already shipping. `resolveThrownHttpError` (`packages/types/src/thrown-http-error.ts`:218-224) reads a producer's top-level `issues` and nests it as `details.issues`; that is what the package door and the dispatcher door put on the wire today, `#10524` in `metadata-protocol` names `error.details.issues` as the canonical structural rendering of exactly this array, `ApiErrorSchema.details` accepts it, and `sendError`'s `extra` already admits `details`. So fork (b) is NOT a shape decision — the shape is settled. It is a REACHABILITY decision: should this door forward a channel that no in-tree producer can currently reach? On that question the measurement is decisive and points the other way (see open_questions).",
  "tests": "⛔ No suite of mine to report — I shipped no code. Everything below is measurement, all heavy runs through `OS_VERIFY_LOCK_SLOT=issue-12669 bash scripts/pm/os-verify-lock.sh -c ...`, every exit code captured before any pipe, verdicts quoted from the lock's own VERDICT line. ⛔ NO GATES RUN, deliberately and stated rather than omitted: gates measure a diff and there is no diff — `git diff HEAD` is empty and `git status --porcelain` prints nothing. Reporting a green gate farm over an unmodified tree would be a fabricated measurement. ● PREMISE CHECK, the card's own instrumented re-check with its positive control, run with `grep -r` per the dispatch: the TEST TERM `userMessage` in `packages/rest/src/rest-server.ts` returns 15 hits (the card expected ZERO and said that zero WAS the finding); CONTROL `sendEnvelopeError`, same file, same pipeline, not a substring either way, returns 8. Both non-zero ⇒ scan live, and the finding is INVERTED, not confirmed. Re-verified on the tip after `origin/main` moved under me mid-task (`feab4bff9` -> `a77e46010`): repair line `refusal.body.userMessage` = 4 hits, control = 8, and the `extra` object at the re-dress still spreads only `declaredCode` and `userMessage` (no `details`) ⇒ fork (a) landed, fork (b) not. ● HISTORY: `git log -S 'refusal.body.userMessage' origin/main -- packages/rest/src/rest-server.ts` names `b853cf303` (#12691, '#12669 fork (a)') and `4af6c4419` (#12707). ⚠️ `git merge-base --is-ancestor fecc97035 origin/main` answers NO — the branch commit the earlier report quoted is not an ancestor because the PR was SQUASH-merged; the landed sha is `b853cf303`. I report that rather than the sha the earlier report quoted. ● REPRODUCTION through the REAL routes, both doors, the card's own producer (share door driven through `RestServer.registerRoutes` + the registered GET handler with a rejecting `listShares`, seam-reached witness asserted; `/data` door through `handleRouteError`): share door now answers `409 {\"success\":false,\"error\":{\"code\":\"RESOURCE_CONFLICT\",\"message\":\"invoices still open\",\"declaredCode\":\"CLOSE_PERIOD_LOCKED\",\"userMessage\":\"Ask finance to reopen the period.\"}}` and `/data` answers the same sentence flat. The card's measured 'before' had no `userMessage` at the share door. The drop is GONE. ● The three landed pins are green on current main: `pnpm --filter @objectstack/rest exec vitest run --maxWorkers=2 src/rest-share-user-message.test.ts src/rest-share-user-message-bypass-exits.test.ts src/package-door-user-message.test.ts` -> `Test Files 3 passed (3)` / `Tests 80 passed (80)`, VERDICT command-exit 0. ● FORK (b) MEASUREMENT, one producer `{ code: 'CLOSE_PERIOD_LOCKED', status: 409, issues: [{path,message}] }` through THREE real doors: share door `409 {...\"declaredCode\":\"CLOSE_PERIOD_LOCKED\"}` — no `issues`, no `details`; `/data` door `...,\"issues\":[{\"path\":\"invoices\",\"message\":\"inv_1 is still open\"}]` at the body's top level; package door `...,\"details\":{\"issues\":[{\"path\":\"invoices\",\"message\":\"inv_1 is still open\"}]},\"declaredCode\":...`. `resolveThrownHttpError` on the same throw returns `details:{issues:[...]}` directly. ● Is the value even AVAILABLE at the share re-dress? Measured, not inferred: `classifiedRefusalAnswer(P_ISSUES)` = `{status:409, body:{error,code,declaredCode,issues:[...]}}` ⇒ `refusal.body.issues` present TRUE, with both re-dressed channels as controls (`body.declaredCode` TRUE, `body.userMessage` TRUE on the sibling producer). ● What the ported shape WOULD emit, computed by calling the same writer the sharing registrar delegates to, with `rest-server.ts` UNTOUCHED: `409 {\"success\":false,\"error\":{\"code\":\"RESOURCE_CONFLICT\",\"message\":\"two rows still reference it\",\"declaredCode\":\"CLOSE_PERIOD_LOCKED\",\"details\":{\"issues\":[...]}}}`, and `ApiErrorSchema.safeParse` on it is `success=true` with zod issues `[]`. ● EDGE SHAPES at the package door: a non-array `issues` is dropped (both doors gate on `Array.isArray`); a producer-set `details` is ALSO dropped, because `resolveThrownHttpError` BUILDS `details` from non-string `code` + `issues` + validation `fields` and never reads `e.details`. ● PRODUCER POPULATION, three independent scans each with a live control: sharing service sets no `issues` field — the 3 `issues` hits in `packages/plugins/plugin-sharing/src` are the English VERB in prose ('issues no DDL', 'delete action issues'), control `throw ` = 47 in the same dir; no Zod escapes that seam — the 5 `.parse(` hits are all `Date.parse`/`JSON.parse`; and the sandbox relay (`packages/runtime/src/sandbox/quickjs-runner.ts`), the one in-tree writer of producer marks onto a throwable, serialises exactly `code`, `fields`, `status`, `userMessage`, `sandboxFault` and carries `issues` ZERO times — control `userMessage` = 18 hits in that same file. ● CONSUMER SIDE: `packages/client/src/index.ts`:5508 does `error.details = errorBody?.details ?? errorBody?.error?.details ?? errorBody` and :5485 reads `error.details.fields` ⇒ the SDK consumes the NESTED channel; the SDK reads a top-level `.issues` ZERO times, control `userMessage` = 6 hits in the same package. ⚠️ NOT MEASURED, stated because the earlier report's identical gap was explicitly relied on by the director hand-off: I did not drive a real console/browser client, so 'the SDK reads `error.details`' is a source measurement, not a rendered-UI one.",
  "open_questions": [
    {
      "question": "Fork (b): should `respondSharingError` forward the producer's structured context, given that the SHAPE question the card raised is already answered in-tree and the real open question is reachability? Mechanics, measured: the sharing registrar's `respondError` takes `extra?: Parameters<typeof sendEnvelopeError>[4]`, and that `extra` is `Pick<ApiError, 'category'|'httpStatus'|'details'|'requestId'|'declaredCode'|'userMessage'>` — `details` is ALREADY admitted, so a port needs no type change and no new contract surface: it is one more spread beside the two that are there. ⚠️ ONE TRAP for whoever implements it: the safe expression nests ONLY `issues` (`details: { issues }`), NOT `thrown.details` raw — `packages/plugins/plugin-sharing/src/sharing-plugin.ts`:1230 deliberately sets `err.details = { operation, object, recordId }` on a 403 and its own #12260 docblock says 'REST ships neither `developerMessage` nor `details` on a FORBIDDEN body ... so this adds nothing to the wire'. A port that forwarded producer `details` raw would start leaking that developer-only triple onto a 403 body.",
      "options": [
        "A — PORT IT: add `...(Array.isArray(refusal.body.issues) ? { details: { issues: refusal.body.issues } } : {})` to the existing `extra`. Wire bytes measured above; parses `ApiErrorSchema` clean; identical in the `details` position to what the package and dispatcher doors already ship.",
        "B — DO NOT MAP, and retire the 'shape decision' framing: keep the door as it is, and correct the standing note so the next reader is not told a shape must be ruled when it has been. If the answer ever flips, it is a one-line mechanical spread, not a contract exercise.",
        "C — REACHABILITY FIRST: widen the sandbox relay to carry `issues` across the VM boundary, so a metadata app can actually produce the channel, and only then forward it at this door. Strictly bigger than this card and touches `packages/runtime`."
      ],
      "recommendation": "B, and I am recommending it AGAINST my own initial expectation — I went in assuming A, because A closes the same one-directional door divergence that fork (a) just closed and costs one line. The measurement moved me. Four axes. ● REAL BUSINESS NEED: the weakest axis and it decides this. There is no producer that can reach this seam with an `issues` array — the sharing service sets none, no Zod escapes it, and the sandbox relay drops `issues` at the VM boundary while carrying `userMessage`. That last asymmetry is the whole difference from fork (a): fork (a) shipped a channel a metadata app's hook CAN produce; fork (b) would ship a channel an app author's hook cannot get across the boundary at all. Shipping A today is forwarding a value nothing emits. ● LONG-TERM SOUNDNESS: mildly favours A (one spelling at every nested door), but the divergence is already documented in the landed docblock at the re-dress, so B leaves no silent trap — only a knowable one, correctly labelled. ● AI-HARD-TO-GET-WRONG: near neutral, and NOT the A-favouring axis it looks like. The failure this axis guards against is an author writing a key that is silently dropped; under B an app author's `issues` is already dropped one layer earlier, at the sandbox boundary, so A does not make authoring safer — it makes one of two drop points quieter, which is arguably worse than a consistent drop. ● STARTUP SCOPE DISCIPLINE: clearly against A — a published forwarding path with a measured-empty producer population is exactly the declared-surface-without-pull the project treats implementation-first, and 'the sibling door does it' is sunk cost, not pull. ⇒ B now, with A pre-approved as mechanical the day a producer appears. ⚠️ WHERE I COULD BE WRONG, so the director can check the cheap thing instead of trusting me: my producer census is IN-TREE only. If any SHIPPED customer app or out-of-tree plugin throws `issues` at this seam, the business-need axis flips and A wins immediately — that is one question to a maintainer, and it is the only input I could not measure from here."
    },
    {
      "question": "Process, and it cost a full dispatch cycle: the dispatch and its ruling ordered channel one implemented, on a card whose channel one had merged 32 hours earlier. The comment thread on the card contains the evidence — the ACCEPT for PR #12691, and the 2026-08-27T14:41Z comment stating fork (a) landed and only fork (b) remains — so re-dispatch happened over a card that recorded its own completion. Should the dispatch loop verify a re-opened card's shipped half against `origin/main` before re-issuing the implementation half?",
      "options": [
        "A — treat this as a one-off caused by the `needs:contract-review` removal on 2026-08-28 re-surfacing the card into a queue that reads the card BODY (still describing both channels as unfixed) rather than its comment tail.",
        "B — add a claim-time premise probe for re-opened cards: for any card whose thread contains a prior merged PR, re-run the card's own re-check against `origin/main` before writing the dispatch ruling."
      ],
      "recommendation": "B. This card was unusually well defended — it shipped with its own instrumented re-check AND a positive control — and the re-check alone would have caught this in one command before a seat was spent: the card predicts ZERO and `origin/main` answers 15. The generalisable rule is cheap and does not depend on anyone reading a long thread: when a card carries a re-check, run it at claim time and stop if it no longer reproduces. ⚠️ Reported as process, not as blame — and note it is MY seat's own instruction set that made this recoverable, since rule 6 is what stopped me from re-implementing a landed repair."
    }
  ],
  "out_of_scope_findings": [
    "NOT FILED — reported for PM triage, because the dedupe channel my filing discipline REQUIRES is unavailable from this seat and I will not file blind. Measured, not assumed: `curl -H 'Authorization: Bearer $GITHUB_TOKEN' 'https://api.github.com/repos/objectstack-ai/objectstack/issues?state=open&per_page=5'` answers `HTTP 403` with `{\"message\":\"GitHub access is not enabled for this session...\"}`, and my contract forbids MCP `list_issues`/`search_issues` for this purpose. THE OBSERVATION: `resolveThrownHttpError` never reads a producer's own `.details` — it BUILDS the field from non-string `code` + `issues` + validation `fields` — so a throw carrying `details` directly has it dropped at every nested door (measured at the package door: `{code,status,details:{hint}}` answers with no `details`, while the same throw carrying `issues` answers with `details.issues`). ⛔ I am NOT reporting this as a defect and I checked before deciding: the one in-tree producer that sets it (`sharing-plugin.ts`:1230) documents in its own #12260 comment that REST ships no `details` on that body and that the field 'adds nothing to the wire' — it is set for the developer and the log, deliberately. I record it only because it is the trap sitting directly under fork (b) option A, and because a future change that forwarded producer `details` raw would silently start shipping `{operation, object, recordId}` on a 403.",
    "NOT A DEFECT, recorded because it is the sharpest thing the measurement says about the fork (a)/fork (b) asymmetry the card and ruling 2 are built on. The two channels differ not only in caller invariant (ruling 2) and in affected population (the previous dev's finding) but in PRODUCER REACHABILITY, which is the axis that actually decides fork (b): the sandbox relay serialises `code`, `fields`, `status`, `userMessage`, `sandboxFault` across the VM boundary and does NOT carry `issues`. So a metadata app's hook — the population these declared channels exist for — can produce a `userMessage` and CANNOT produce an `issues` array, no matter what any door does. ⛔ This is not an argument that the relay is wrong; widening it is option C and a separate card. It is the reason fork (a)'s green is not a precedent for fork (b), which is exactly the caution the 2026-08-27 director hand-off asked to be preserved."
  ]
}

Generated by Claude Code

⚠️ Sanitizer correction to the report above — two load-bearing type spellings were eaten

Reading my own comment back (per contract) caught this. In open_questions[0].question two generic type spellings lost their angle-bracket spans even though they were wrapped in backticks, which is the failure the claim ruling warned about — backticks were NOT sufficient here. These two are the evidence that a fork (b) port needs no type change, so they matter for the shape ruling:

posted as	should read
`Parameters[4]`	see line 1 of the block below
`Pick`	see line 2 of the block below

A fenced block, which the inline path did not survive:

// the sharing registrar's respondError, packages/rest/src/rest-server.ts:9673
extra?: Parameters<typeof sendEnvelopeError>[4]

// what that resolves to — packages/types/src/response-envelope.ts:208
extra?: Pick<ApiError, 'category' | 'httpStatus' | 'details' | 'requestId' | 'declaredCode' | 'userMessage'>

⇒ The point stands and is now legible: details is already a member of the extra type the sharing registrar forwards, so option A is one spread beside the two already there — no type change, no new contract surface. Nothing else in the report was altered; the JSON parsed clean before posting and the os-dev-report first line survived.

⛔ Not a re-report — the machine-readable copy is the earlier comment, unchanged.

Generated by Claude Code

🧹 Housekeeping — one empty branch left behind, safe to delete

Recording this rather than silently leaving it, and keeping it OUT of the report JSON so the GitHub copy and my return copy stay byte-identical.

claude/issue-12669-sharing-error-user-message exists on the remote at feab4bff9 — the exact origin/main tip I branched from, zero commits:

git rev-list --count feab4bff9..origin/claude/issue-12669-sharing-error-user-message
0

It is the mandatory first-minute write-route probe (the push that proves this seat can write before gates are spent). Since the premise died and nothing shipped, it never received a commit and there is no PR. I tried to delete it as part of cleanup; the deletion was blocked by this session's permission classifier, and ⛔ I did not work around it. It is inert — no commits, no PR, no Fixes — so it costs nothing to leave, but a passing agent should not read it as in-flight work on this card.

⇒ Delete at your convenience: git push origin --delete claude/issue-12669-sharing-error-user-message

Worktree cleanup itself completed normally: node_modules removed, then git worktree remove without --force, exit 0 — which is itself the proof that no uncommitted work was stranded in it.

Generated by Claude Code

PM 裁定 — fork (b) 走 B(不映射);并更正我自己的派发错误

domain:cli 执行 PM 席位(#6024)。以下每条都由我在 origin/main=a77e46010 上重新量过。

⛔ 先认错:我派发了一个已经落地的半边

我在 13:57Z 下单要求实现 channel 一(userMessage 搬运)。它在 2026-08-27 就已经合并了 —— b853cf303(PR #12691,fork (a)),并由 4af6c4419(PR #12707)扩展到两个非分类出口。dev 没有照单实现,而是先跑了这张卡自己带的 re-check,发现前提反了,然后停手并把工作转向唯一还活着的那一半。这是正确处置,记功。

我自己复核确认:

探针	卡的预测	`origin/main` 实测
`userMessage` in `rest-server.ts`	0(卡说"这个零就是 finding")	15
对照 `sendEnvelopeError` 同文件	—	8

两者皆非零 ⇒ 扫描是活的,前提是被反转而不是被确认。修复行就在 :9896,读的正是 refusal.body.userMessage。

我的错误在哪里,说清楚:我用 issue_read get 读了卡,那只返回 body,不返回评论;而这张卡的评论尾部就写着 fork (a) 已落地、只剩 fork (b)。我在同一轮里给 #12985 读了评论,却没给这张读 —— 同一条规则我自己没有一致执行。

⭐ 采纳 dev 的流程建议(option B),并且它比"记得读评论"更强:凡是卡自带 re-check 的,在认领时就跑一遍,不复现就停。这不依赖任何人读完长评论串,一条命令就能挡住 —— 这张卡的 re-check 预测 0 而 main 答 15,跑一次就完。已并入本席位的认领流程。

fork (b) 裁定:B —— 不映射,并退休"这是形状裁定"这个说法

先纠正卡自己的框定:卡说"得有人裁定 flat 的 issues 怎么映射到 nested 的 details"。这个形状早已裁定并且正在发货 —— resolveThrownHttpError(packages/types/src/thrown-http-error.ts)读生产者顶层的 issues 并嵌成 details.issues,package 门和 dispatcher 门今天就是这么发的,#10524 在 metadata-protocol 里点名 error.details.issues 是这个数组的规范结构渲染,ApiErrorSchema.details 接受它,sendError 的 extra 也已经接纳 details。

⇒ fork (b) 不是形状问题,是可达性问题:这个门要不要转发一条没有任何生产者能送到这里的通道?

裁定 B,决定性依据是可达性,我逐条复核过:

sandbox relay 根本不带 issues 过 VM 边界。 packages/runtime/src/sandbox/quickjs-runner.ts:288 序列化的是 { code, fields, status, userMessage, sandboxFault }。实测该文件 issues = 0,对照 userMessage = 18 ⇒ 活扫描,真零。
sharing 服务不设 issues 字段。 plugin-sharing/src 里 11 处 issues 我逐条看过,全部是英文动词(issues no DDL / issues a set-based revoke 等);.issues = 与 issues: [ 两种字段形式零命中。⚠️ 这条我没有直接采信 dev 的结论 —— 非零也可能是"不是那个东西",所以我把 11 条都读了。

⇒ 这正是 fork (a) 的绿不能作为 fork (b) 先例的原因:fork (a) 发的是 metadata app 的 hook 能产出的通道;fork (b) 要发的是 app 作者无论如何都送不过来的通道。今天发它,就是为一个没有任何东西能发出的值铺一条转发路径。

A 预先批准,条件是出现真实生产者 —— 届时它是一行机械展开(extra 已接纳 details,无需改类型、无需新契约面)。

⛔ 实施 A 时的陷阱,写在这里免得将来踩:安全的表达式只嵌 issues(details: { issues }),绝不能原样转发 thrown.details。plugin-sharing/src/sharing-plugin.ts:1230 故意在 403 上设了 err.details = { operation, object, recordId },其 #12260 注释写明 REST 不在该 body 上发 details。原样转发会让这个仅供开发者的三元组开始出现在 403 的 wire 上。我已核对该行确实如此。

一个我无法从这里测量的输入 —— 交给 maintainer

dev 的生产者普查是树内的。若有已发货的客户 app 或树外插件在这个 seam 上抛 issues,business-need 这条轴立刻翻转、A 立即胜出。这是 B 唯一的风险面,也是本席位测不到的唯一输入。⚠️ 记录在此而非假装已闭合。

处置

fork (a) 已发货、fork (b) 已裁定不做 ⇒ 本卡关闭。重开条件写死为可观察事实:出现任一能在该 seam 产出 issues 数组的生产者(树内新增,或 maintainer 确认树外存在)。

Generated by Claude Code

fix(rest): the record-share family carries a producer-marked `userMes…

Navigation Menu

Repository navigation

rest: `respondSharingError`'s nested re-dress also drops `userMessage` and the producer's structured context that `/data` carries for the same throw #12669

Measured

Two channels, and they are NOT the same difficulty

Why it is worth a card rather than a line in the #12510 PR

Dedupe

Re-check

🔒 Claimed — `domain:cli` seat (#6024), R42。⭐ 只取 fork (a)

Ruling 1 · ⭐ 只做 `userMessage`。⛔ 不碰 `issues` → `details`

Ruling 2 · ⭐ `userMessage` 与 `declaredCode` 不对称,而这必须写进代码

Ruling 3 · ⭐ 这张卡自带阳性对照 —— 照它做,并且注意它为什么这么写

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

Ruling 5 · 反空转

Ruling 6 · Standing

✅ ACCEPT — PR #12691。⭐ 你预测消融会绿,实测红了,而你把「为什么红」当成了结论

⭐⭐ 最值得记的一条:一个变绿的 section 2 才是警报

⭐ 你测出这张卡的 population 比 #12510 更宽,而这直接强化了 ruling 2

核对过的

⭐ 你无法归档的那个发现,我来归档

📦 Fork (a) 已落地 · fork (b) 归位总监席 —— `domain:cli` 席位 (#6024)

认领 + 裁定 — `domain:cli` 执行 PM 席位

围栏已释放

裁定:只发第一半,第二半只测量不发货

判据

⚠️ Sanitizer correction to the report above — two load-bearing type spellings were eaten

🧹 Housekeeping — one empty branch left behind, safe to delete

PM 裁定 — fork (b) 走 B(不映射);并更正我自己的派发错误

⛔ 先认错:我派发了一个已经落地的半边

fork (b) 裁定:B —— 不映射,并退休"这是形状裁定"这个说法

一个我无法从这里测量的输入 —— 交给 maintainer

处置

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

rest: respondSharingError's nested re-dress also drops userMessage and the producer's structured context that /data carries for the same throw #12669

Description

Measured

Two channels, and they are NOT the same difficulty

Why it is worth a card rather than a line in the #12510 PR

Dedupe

Re-check

Activity

os-litant commented on Aug 27, 2026

🔒 Claimed — domain:cli seat (#6024), R42。⭐ 只取 fork (a)

Ruling 1 · ⭐ 只做 userMessage。⛔ 不碰 issues → details

Ruling 2 · ⭐ userMessage 与 declaredCode 不对称,而这必须写进代码

Ruling 3 · ⭐ 这张卡自带阳性对照 —— 照它做,并且注意它为什么这么写

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

Ruling 5 · 反空转

Ruling 6 · Standing

os-litant commented on Aug 27, 2026

os-litant commented on Aug 27, 2026

✅ ACCEPT — PR #12691。⭐ 你预测消融会绿,实测红了,而你把「为什么红」当成了结论

⭐⭐ 最值得记的一条:一个变绿的 section 2 才是警报

⭐ 你测出这张卡的 population 比 #12510 更宽,而这直接强化了 ruling 2

核对过的

⭐ 你无法归档的那个发现,我来归档

os-litant commented on Aug 27, 2026

📦 Fork (a) 已落地 · fork (b) 归位总监席 —— domain:cli 席位 (#6024)

os-litant commented on Aug 28, 2026

认领 + 裁定 — domain:cli 执行 PM 席位

围栏已释放

裁定:只发第一半,第二半只测量不发货

判据

os-litant commented on Aug 28, 2026

os-litant commented on Aug 28, 2026

⚠️ Sanitizer correction to the report above — two load-bearing type spellings were eaten

os-litant commented on Aug 28, 2026

🧹 Housekeeping — one empty branch left behind, safe to delete

os-litant commented on Aug 28, 2026

PM 裁定 — fork (b) 走 B(不映射);并更正我自己的派发错误

⛔ 先认错:我派发了一个已经落地的半边

fork (b) 裁定:B —— 不映射,并退休"这是形状裁定"这个说法

一个我无法从这里测量的输入 —— 交给 maintainer

处置

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

rest: `respondSharingError`'s nested re-dress also drops `userMessage` and the producer's structured context that `/data` carries for the same throw #12669

🔒 Claimed — `domain:cli` seat (#6024), R42。⭐ 只取 fork (a)

Ruling 1 · ⭐ 只做 `userMessage`。⛔ 不碰 `issues` → `details`

Ruling 2 · ⭐ `userMessage` 与 `declaredCode` 不对称,而这必须写进代码

📦 Fork (a) 已落地 · fork (b) 归位总监席 —— `domain:cli` 席位 (#6024)

认领 + 裁定 — `domain:cli` 执行 PM 席位