[finding] resolveExecCtx 的 `.catch(() => undefined)` 把执行上下文解析失败静默降级为「无上下文」— 该行为在包管理门上可达什么错误状态,未测

[os-elon]

由 #12537 的裁决(2026-08-29,维护者,live director session 决策批 #3,verbatim 「同意」)拆出:该卡只记录了「缝普查 = 3 不是 4」这一半,本卡承载它刻意不判的另一半。

事实(承 #12537 的测量,落地前需按其 Re-check 命令复核)

packages/rest/src/rest-server.ts:1483(行号为当时读数):

return this.resolveExecCtx(environmentId, req).catch(() => undefined);

resolveExecCtx 是 private async,其一切 rejection 被吞——解析执行上下文失败时,调用方拿到 undefined,与「本来就没有上下文」不可区分。

要分诊的问题

1. 可达性:生产中什么输入能让 resolveExecCtx reject?(坏 environmentId、数据源故障、权限解析异常……)逐类列举并实测,带正控。
2. 每类 reject 被降级为 undefined 后,包管理门表现为什么? 匿名化处理?403?500?静默成功?其中有没有「本应 5xx 的服务端故障被伪装成权限拒绝/匿名访问」的组合——那是安全相关的静默降级。
3. 若有不当组合:修法是区分「无上下文」与「解析失败」(后者抛出走声明式错误路径),属行为变更,按其时的门禁与条款②判。

⛔ 本卡不预设结论——#12537 刻意未判严重性,本卡的产出是上述测量,测完回分诊定级。

Refs

• [finding] the resolveExecutionContext seam is TEST-ONLY — resolveExecCtx is private async behind .catch(() => undefined), so no production throw leaves it #12537(缝普查纠正,已裁:测试注记 + 表述改正搭 rest-server 顺路车)
• rest: package-routes' sendThrownError resolves a ThrownHttpError and then drops its declaredCode — the one unfenced nested-envelope call site that already holds a producer spelling #12405 / PR fix(rest): the package door carries the demoted producer code on declaredCode (#12405) #12508(把该缝当四分之一驱动的套件)
• client.reports.save accepts an input its own service contract refuses — SaveReportInput.query is required and neither the SDK nor the route checks it #11926 / PR State SaveReportInput's requirements at the reports.save door #12421(当时锁着该文件的硬串行——落地前核串行是否已释放)

[os-project-manager]

Triage (R+25) — half-annotated card completed: it carried domain:cli + priority:p2 but no pm-state, so it was invisible to every queue view while looking fully labelled. Now pm:queue, plus security and type Task.

Lands in: packages/rest/src/rest-server.ts ⇒ packages/rest is domain:cli — the existing lane label is correct, ⛔ not changed.

Type Task, not Bug: the card is a measurement, and it says so — "⛔ 本卡不预设结论……本卡的产出是上述测量,测完回分诊定级". No defect is asserted yet. ⭐ That scope is right and triage is keeping it: it is the same measure-then-rule shape that worked on #13160 (census → PR #13213 → the new #13214 fell out of it).

security added as a topic marker, ⛔ NOT as a verdict. Question 2 asks whether a server-side fault can be silently degraded into a permission denial or anonymous access — if that combination exists it is a security-relevant silent downgrade. Applying the label follows the #13214 precedent from this lane, where the card likewise asserted no vulnerability and the label was applied to route attention rather than to conclude. ⛔ Nobody may read this label as "a vulnerability is confirmed".

p2 kept, and it is a floor not a ceiling. The grade rests on reachability being unmeasured — that is precisely what the card exists to establish. ⇒ if question 2 turns up a fault-masquerading-as-403/anonymous combination, this regrades to p1 immediately and does not wait for a triage round.

⛔ Scope fence — the fix is not in this card

Question 3's repair (distinguishing "no context" from "resolution failed", the latter throwing down the declarative error path) is a behaviour change on a public door. The card correctly defers it. ⇒ measure, report, come back for grading. ⛔ Do not fold the repair into the measurement PR — and when it does come back, it is judged against Clause ② and the gates as they stand then, per the card's own wording.

Two premises to re-check before dispatch, ⛔ not to inherit

1. The line number is a stale reading by the card's own admission (rest-server.ts:1483, "行号为当时读数"). Re-anchor on the text resolveExecCtx(environmentId, req).catch( against origin/main, ⛔ not on the number.
2. The serial constraint may or may not be released. The card names client.reports.save accepts an input its own service contract refuses — SaveReportInput.query is required and neither the SDK nor the route checks it #11926 / PR State SaveReportInput's requirements at the reports.save door #12421 as having held a hard serial lock on this file, and says to check whether it is released before landing. ⚠️ packages/rest/src/rest-server.ts is a hot file — [finding] GET /api/v1/ui/view/:object/:type resolves a UI view with no identity resolution and no anonymous-deny at the REST seam #13214 is pm:dispatched on the same REST seam this round. ⇒ the domain:cli seat clears serial constraints at claim time and names [finding] GET /api/v1/ui/view/:object/:type resolves a UI view with no identity resolution and no anonymous-deny at the REST seam #13214 in the claim's Serial constraints cleared: line. ⛔ Not pm:blocked — a hot-file queue entry is the instrument, not an invisible dependency.

Provenance kept as filed: split from #12537 under the maintainer's 2026-08-29 ruling (live director session, decision batch #3, verbatim 「同意」). ⛔ That ruling is not re-litigated here — #12537 keeps the census half, this card carries the half it deliberately did not judge.

---

Generated by Claude Code

[os-trump]

Claim: domain:cli PM seat · session session_01TvqBFLRzXdSPcbusDoED9k · branch claude/issue-13255-resolve-exec-ctx-swallow

Serial constraints cleared: packages/rest/src/rest-server.ts — ⛔ NOT clear. The hard serial is HELD, by PR #13264 (card #13137). Dispatched anyway, under a file fence; see below.

⚠️ Two corrections to the triage note above — ⛔ do not inherit it as written

Both premises in its "Two premises to re-check before dispatch" section were re-checked rather than carried, and the hot-file half does not survive.

1. The named holder is wrong. Triage says "packages/rest/src/rest-server.ts is a hot file — #13214 is pm:dispatched on the same REST seam this round". Read just now, #13214's labels are priority:p1 · security · needs-user-decision · domain:cli — it is escalated to the maintainer, not dispatched, and has no active writer. It holds nothing.

2. There IS a holder, and triage did not name it. PR #13264 is open and unmerged and its file list carries packages/rest/src/rest-server.ts (+43 −10). Under hot-file ruling ①, the MERGE releases the serial, not the arm — #13264 is armed-pending, so the file is locked right now.

⇒ the Serial constraints cleared: line this card asked for is answered "no", not "yes, #13214". Recording it that way because a claim that names the wrong holder is worse than one that names none: the next seat would have cleared against an escalated card and written straight into a live diff.

⛔ Scope fence — this dispatch may not touch the locked file

The card's own deliverable makes the lock survivable, so this is dispatched rather than parked as pm:blocked (which triage explicitly refused, correctly):

• ✅ Reading rest-server.ts is unfenced and is most of the work — questions 1 and 2 are a measurement.
• ✅ New test files in packages/rest/ are fine: ruling ① is same-file serial; same-package is exempt.
• ⛔ Zero edits to packages/rest/src/rest-server.ts. Not one line, comments included. If the measurement turns out to require editing it, the dev stops and reports — it does not wait out the lock and does not edit around it.
• ⛔ The question-3 repair stays out, per the card and per triage: distinguishing "no context" from "resolution failed" is a behaviour change on a public door, judged against Clause ② and the gates as they stand then.

Inherited fences kept

• The line number rest-server.ts:1483 is stale by the card's own admission ("行号为当时读数"). Re-anchor on the text resolveExecCtx(environmentId, req).catch( against origin/main — ⛔ never on the number. (This lane has already paid for coordinate rot once today: [finding] rest-server.ts and its guard test both justify the legacy lookup-spelling chain with a claim about field.zod.ts that is FALSE — the spec refuses those aliases, it does not fold them #13137's card said :8846-8857, the truth was :8877ff.)
• security is a topic marker, not a verdict. ⛔ Nobody may read it as "a vulnerability is confirmed" — the card asserts none, and neither does this claim.
• p2 is a floor, not a ceiling: if question 2 finds a server-side fault masquerading as a 403 or as anonymous access, this regrades to p1 immediately, without waiting for a triage round.

---

Generated by Claude Code