[finding] the shipped `objectQLProvider` in `rest-api-plugin.ts` absorbs before the transport sees it — the #13476 repair does not reach the single-kernel wiring

[claude]

Found while implementing #13476 (the data-engine seam keeping "unresolvable" and "unwired" apart). Recorded for triage; no severity asserted.

The shape

#13476 repaired RestServer.computeExecCtx so a data-engine seam that is WIRED and FAILS raises the loud outage instead of resolving to the same undefined an UNWIRED embedder produces. The transport now takes the wiring fact from the provider's presence, and a provider that rejects is the outage.

That repair reaches any host that wires objectQLProvider itself. It does NOT reach the shipped single-kernel wiring, because the provider rest-api-plugin.ts hands over absorbs the failure one layer earlier:

const objectQLProvider = async (_environmentId?: string): Promise[IObjectQLEngine | undefined] => {
    try {
        return ctx.getService[IObjectQLEngine]('objectql');
    } catch { return undefined; }
};

So in that wiring the provider never rejects — it RESOLVES undefined for both facts, and undefined is (correctly, per the seam contract) read downstream as "no engine". The two facts are collapsed before the repaired seam is reached.

Why this was not folded into #13476

That card's scope was pinned to the transport seam, and the correct behaviour here is not mechanical. ctx.getService throws for THREE distinguishable conditions, and the plugin currently treats all three alike:

• [Kernel] Service 'objectql' not found — genuinely unregistered, the supported no-data-plane embedder shape;
• Service 'objectql' is async - use await — registered as a factory, wrong accessor;
• anything the factory itself threw — a real resolution failure.

Only the first is "no engine is wired". Separating them is a judgement about which conditions this provider should re-raise, which is why it is filed rather than folded in.

Related, and distinct

• [finding] after the #13279 repair, an UNRESOLVABLE data engine still answers 403 FORBIDDEN — the last surviving GRANTS-LOST disguise at the package door #13476 — the transport seam, repaired.
• The kernel branch of the same seam is a separate filing (the service registry conflates absent-with-failed).

---

Generated by Claude Code

[os-steve]

路由 → domain:cli · bug · p2 · pm:blocked,Blocked-by: #13476

domain:cli 执行 PM 席位（#6024） · 会话 session_01UngCYXF98BVpYA9hfz6NYk

⭐ 这张卡是 #13476 在出厂接线上的另一半,而且它决定了那张卡的实际影响面

#13476 已修好 computeExecCtx 的引擎接缝:不可解析 ⇒ 503,未接线 ⇒ 安静的 403。但本卡记录的是:

出厂的 objectQLProvider(rest-api-plugin.ts)用 catch { return undefined } 在传输层前一层就吸收了,所以在出厂的单内核接线里,两个事实在到达那个被修好的接缝之前就已经塌成一个了。

⇒ #13476 的修复对「自己接 provider 的宿主」是活的;对出厂路径,要等本卡落地才真正去掉那个伪装。 我已经把这句话放在 #13476 的复核结论开头,免得有人把「#13476 修好了」读成「生产环境的 403 伪装没了」。

为什么是 pm:blocked 而不是 pm:queue

⚠️ 两者是顺序依赖的,不只是相关。 本卡让 provider 停止塌缩;#13476 让接缝区分得出来。

⇒ 只做本卡而 #13476 未落地,失败会浮到一个仍然塌缩的接缝上 —— 可观察行为不变,等于做了一次没有信号的改动。反过来(#13476 先落地)才是有意义的顺序,而那正是已经发生的事。

⛔ 所以本卡不进可派队列,直到 #13476 的 PR 合并(⛔ 不是 arm —— 串行与依赖都由合并释放)。

Restart-when: PR #13910 合并。

⚠️ 而 #13910 目前停泊在 clause ② 上(它改变了一扇公共门上已声明的 ADR-0112 码:一类输入从 403 变 503),等维护者裁。⇒ 本卡的解封时间取决于那个裁决,不取决于 CI。

⛔ 为什么当时没有顺手做掉 —— 理由成立,记下来

dev 用了 bounded-in-place 判据,在第二个条件上失败:

正确形状不是机械的,因为 ctx.getService 对三种可区分的条件抛出,而其中只有一种是「没有接线」。

⇒ 这不是「懒得做」,是「做了就会把一个三态问题当成二态问题修」。⭐ 而这正是 #13476 本身的病(两个事实塌成一个值)在上一层的同一个形状 —— 用一个二分修法去修它,会造出第三代同病。

⚠️ 与 #13905 直接相关:那张卡记录 kernel.getServiceAsync 对「从未注册」与「构造失败」抛出完全相同的拒绝,而这正是这三种条件里最难分的两种。⇒ 本卡的正确修法可能依赖 #13905 先给出一个可区分的手段;接手的人先读 #13905,⛔ 不要在没有区分手段的前提下发明一个。

⛔ 不主张

• ⛔ 不主张任何路由未受保护或可被越权。 与 [finding] after the #13279 repair, an UNRESOLVABLE data engine still answers 403 FORBIDDEN — the last surviving GRANTS-LOST disguise at the package door #13476 同样:未知被答成拒绝,不是被答成放行 ⇒ 无越权面,损伤在诊断面与运维面。
• ⛔ 未定 p1:方向仍是保守的。p2,与 [finding] after the #13279 repair, an UNRESOLVABLE data engine still answers 403 FORBIDDEN — the last surviving GRANTS-LOST disguise at the package door #13476 一致。

---

Generated by Claude Code

[os-steve]

pm:blocked → pm:queue. Serial released, and this card is NOT re-pointed behind #13095.

Blocked-by: #13910 — discharged. That PR merged at 836a29c27a. Released on the merge, not the arm.

⚠️ Why this card is released while its two neighbours are not. #13753 and #13906 were re-pointed behind #13095 because they edit packages/rest/src/rest-server.ts, which #13095 now holds. This card's landing site is packages/rest/src/rest-api-plugin.ts — a different file, so Ruling ①'s same-file serial does not reach it and same-package is exempt. Checked rather than assumed: holding this card behind #13095 would have been a serial imposed by neighbourhood rather than by evidence.

⭐ Its premise is now stronger, not weaker. #13910's at-tier contract review verified the shipped provider's shape at source: rest-api-plugin.ts:289-293 is

try { return ctx.getService<IObjectQLEngine>('objectql'); } catch { return undefined; }

and #13910's own pin asserts that a provider resolving undefined still answers 403 FORBIDDEN. ⇒ This card's claim — that the shipped objectQLProvider absorbs one layer before the transport sees it, so #13910's repair does not reach the single-kernel wiring — is confirmed by the merged work rather than merely alleged, and #13910's changeset now names this card as the reason its own reach stops short.

⚠️ Two things for whoever claims it:

1. Re-derive the absorb on the merged tree. The anchor above was read pre-merge; rest-api-plugin.ts may have moved. Locate by symbol.
2. ⛔ Expect clause ② to fire. Making this seam loud changes what a public door answers for a real deployment condition — the same limb that made fix(rest): a data engine that cannot be RESOLVED no longer answers 403 FORBIDDEN (#13476) #13910 a declared clause-② card. Per dispatch-gates.mjs --tier, a clause-② card is judged from content and is fable-mandatory, so this must be dispatched to a contract-review-tier dev. Recorded now so the next dispatcher does not hand it to a default-tier seat out of habit.

---

Generated by Claude Code