@sema-agent/server 7.12.0 → 7.14.0

package/dist/http/active-run-conflict.js

@@ -13,6 +13,7 @@
  *    (`gate_not_tool_approval`/`gate_not_resumable`/`wake.gate_pending` 的指路句)。三处文案与本表若漂移,
  *    test/session-active-conflict-materials.test.ts 的分门用例会红。认不出的 kind ⇒ null(诚实缺席,不铸假门)。
  */
+import { governanceMandatesShellGateAlways } from "../runtime-governance.js";
 /** 与 runs.ts/tasks.ts 三个 409 位共享的旧文案(byte-frozen:api-error-text-freeze 门认这句)。 */
 export const ACTIVE_RUN_CONFLICT_BASE_TEXT = "session already has an active run — POST /v1/runs/{activeTaskId}/cancel stops it (same-instance interactive runs abort immediately)";
 /** gate.kind → 它的那一个 resume 入口(sessionId/taskId 寻址,无秘密)。 */
@@ -39,6 +40,37 @@ export function resumeEntryForGate(kind, ids) {
             return null; // 未知门型:宁缺毋假 —— 客户端仍有 activeTaskStatus + cancel 这条保底真路
     }
 }
+/**
+ * #220:推「这道门是运维治理层下的吗」。判据是**合取**,两半各管一件事:
+ *
+ *   行上的取证格 `gate.riskDescriptor.shellGateDoctrine === "always"`
+ *   ∧ 本部署的治理层本来就要求 always(`governanceMandatesShellGateAlways`,单一判据属主在
+ *     `runtime-governance.ts`,那里写着为什么单看行不够 —— SUP 路由姿态同样产 `"always"`)
+ *
+ * 第一半:core 在 mint 这道门时把「当时活着的 doctrine」如实写进 `riskDescriptor.shellGateDoctrine`
+ * (2026-08-05 取证裁定;`prepare-task` 只在**被 shell 门铸**的 ask 上写它),所以持久行自己带着证据 ——
+ * park 腿天然跨副本、跨重启,活卡腿那张 ALS 标记表在这里结构上够不着。
+ * 第二半:把「有效档 always」收窄到「治理层是真成因」,否则一条 SUP 路由出来的门会被谎报成治理强制。
+ *
+ * ⚠️ 残留(双向失真的窄在场向 + 根治路径)登记在 `governanceMandatesShellGateAlways` 的顶注,别在这里
+ * 复述;本位只承担「分诊提示」的分量,不参与任何门/CAS/resume 判定。
+ *
+ * 🔴 `"classify"` 档**刻意不标**:那一档由 core 的分类器逐调用裁决,一次 shell ask 可能出自分类器(治理)
+ * 也可能出自 `APPROVAL_REQUIRE` 这类别的门,行上无从分辨 —— 与活卡腿同一条「宁缺毋假」纪律。
+ *
+ * ⚠️ **askId 为什么不在这里**(#220 的另一半,如实记账):待批 ask 的 `askId` 只活在 `approval_ask` 行上
+ * (checkpoint 行没有这一列,core 的 `CheckpointGate`/`PendingAction`/`Checkpoint` 顶层都不带它)。反向
+ * (checkpoint → ask)今天**没有读口**:两条 list 读口都硬过滤 `state='STREAM_PENDING'`,而 park 完的行是
+ * `PARKED`;唯一精确的连接键是 ask 行上的 `gate_token`,要按它反查得给店加一个新读口(SQL 面 = 双库集成
+ * 门)。派生 `deriveAskId(...)` 也不行:它吃 `legKey`(= 上一腿 resume token 的摘要)与 `parentToolCallId`,
+ * 这两维从 checkpoint 行推不出来,二腿/子代形上会算出一个**错**的 id —— 在「等的谁」这条通道上,错 id
+ * 比缺席坏得多(本文件 `resumeEntryForGate` 的 default 臂是同一条纪律)。故本批诚实缺席。
+ */
+function governanceOriginOf(gate, governance) {
+    if (gate?.riskDescriptor?.shellGateDoctrine !== "always")
+        return undefined;
+    return governanceMandatesShellGateAlways(governance ?? {}) ? true : undefined;
+}
 export function toDoneFrameResult(body) {
     return {
         status: "failed",
@@ -75,10 +107,13 @@ export async function buildActiveRunConflict(deps, sessionId, activeTaskId) {
         if (cs?.findPendingTokenBySession) {
             const scope = (await cs.peekPendingScope?.(sessionId)) ?? undefined;
             const token = scope === null ? null : await cs.findPendingTokenBySession(sessionId, scope);
-            const kind = token ? (await cs.get?.(token))?.gate?.kind : undefined;
+            const gate = token ? (await cs.get?.(token))?.gate : undefined;
+            const kind = gate?.kind;
             const decidePath = kind ? resumeEntryForGate(kind, { sessionId, taskId: activeTaskId }) : null;
+            // #220:出身格与出路格**同一次读**里取(不为它多打一次库),`true` 才写键(见 PendingGateMaterial 顶注)。
+            const governanceForced = governanceOriginOf(gate, deps.governance);
             if (kind && decidePath)
-                pendingGate = { kind, decidePath };
+                pendingGate = { kind, decidePath, ...(governanceForced ? { governanceForced } : {}) };
         }
         return {
             ...base,

package/dist/http/routes/adoption.js

@@ -1,6 +1,6 @@
 import { createAdoptionRunner } from "../../adoption/runner.js";
 import { AdoptionRequestSchema } from "../../adoption/wire.js";
-import { checkAdoptionWidths } from "../../adoption/plan.js";
+import { checkAdoptionPrincipalShape, checkAdoptionWidths } from "../../adoption/plan.js";
 import { sendJson, sendError } from "../send.js";
 import { gatedPrincipal, explicitOperatorOk } from "../principal-gate.js";
 const ADOPTION_ID_RE = /^\/v1\/adoption\/([^/]+)$/;
@@ -21,6 +21,11 @@ function sendOutcome(res, out) {
             return;
         // 闭集穷举:`AdoptionRejectCode` 加一个成员而这里没加臂 ⇒ **编译红**(拒绝码是 wire 契约,
         // 不许有一个走到默认臂的静默码)。
+        //
+        // 🔴 A-010.19(验真后修):上面这句话此前是**一句自我声明,不是一道门**。内层 switch 只有两条 case
+        // 而结尾是一个裸 `return;` —— 加第三个拒绝码时 TS 一个字都不会说,请求会走到那个裸 return、
+        // **一个字节都不写**就把响应扔在那里:调用方看到的是一条挂住的连接直到超时,而不是任何错误。
+        // 现在由下面的 `never` 断言真正兑现它:少一条臂 ⇒ `out` 收窄不到 `never` ⇒ 赋值失败 ⇒ 编译红。
         case "rejected":
             switch (out.code) {
                 case "adoption.destination_conflict":
@@ -37,9 +42,19 @@ function sendOutcome(res, out) {
                     });
                     return;
             }
-            return;
+            // 穷举证明:走到这里 `out.code` 必须已经收窄成 `never`。加一个 `AdoptionRejectCode` 成员而不加臂
+            // ⇒ 这一行编译红,红在**加码的那一刻**,而不是在生产上表现为一条永不应答的请求。
+            return assertNoRejectCodeLeft(out.code);
     }
 }
+/** 闭集穷举的落点。**入参类型是 `never`** —— 这就是那道门本身;函数体永远跑不到,写一句响亮抛是为了
+ *  「万一有人用 `as` 把一个未知码塞进来」时仍然 fail-loud(不是静默挂住连接)。
+ *  ⚠️ 形参**刻意不叫 `code`**:`error-code-key-gate` 按 `code:` 的字面形扫全树错误体(3.0.0 起
+ *  `errorCode` 是唯一机器判别键),一个叫 `code` 的形参会被它当成一处 legacy 键站点。名字换掉比放宽
+ *  那道门便宜得多 —— 门宽一分,真站点就可能溜过去。 */
+function assertNoRejectCodeLeft(unhandled) {
+    throw new Error(`adoption: unhandled reject code ${JSON.stringify(unhandled)} — the wire contract's closed set and this switch have drifted apart`);
+}
 export async function handleAdoption(req, res, url, ctx) {
     const miss = { fell: false };
     await handleAdoptionBody(req, res, url, ctx, miss);
@@ -101,6 +116,14 @@ async function handleAdoptionBody(req, res, url, ctx, miss) {
         return;
     }
     const { fromPrincipal, toPrincipal } = parsed.data;
+    // 🔴 键空间卫生在**列宽之前**(A-010.15):带首尾空白的身份在两方言上的唯一键语义不等价
+    // (MySQL utf8mb4_bin 是 PAD SPACE),而它在本仓根本不是一个可能存在的真身份 —— 详见该函数头注。
+    // 排在列宽前面的理由与列宽自己那条次序判据同族:两条都能命中时,报**更根本**的那一个。
+    const badShape = checkAdoptionPrincipalShape(fromPrincipal, toPrincipal);
+    if (badShape !== undefined) {
+        sendError(res, 400, "request.field_invalid", "the adoption principals are not in a portable identity shape", { detail: badShape });
+        return;
+    }
     // 🔴 列宽校验在**铸行之前**(codex R1-F3):合法长度的 principal 也可能装不进最窄的那根被写列,
     // 而那种失败若发生在腿的中途,phase 会永远停在 INTENT —— 每次重发和每次 boot 扫描都再撞一次同样的墙。
     const tooWide = checkAdoptionWidths(fromPrincipal, toPrincipal);

package/dist/http/routes/approvals-assistant.js

@@ -1,7 +1,7 @@
 import { principalFrom, decodeCheckpointScope, PRINCIPAL_TOKEN_HEADER, APPROVAL_MAC_HEADER, APPROVAL_MAC_KID_HEADER } from "../../security.js";
 import { verifyDirectDoorProof } from "../../principal-jwt.js";
 import { MAX_APPROVAL_REASON_CHARS } from "../../approval-hmac.js";
-import { redactedPreview } from "../../trace/redact.js";
+import { redactedPreview, redactSecrets } from "../../trace/redact.js";
 import { fleetRunLabels } from "../../fleet/fleet-bus.js"; // [2069]④ §3 行展示名与 fleet 行同源(见用处的注)
 import { sleep } from "../sse-log.js";
 import { sendJson, sendError, sseHeaders, SSE_MAX_STREAM_MS, SSE_HEARTBEAT_IDLE_MS } from "../send.js";
@@ -68,7 +68,9 @@ async function handleApprovalsAssistantBody(req, res, url, ctx, miss) {
             const scope = operator
                 ? (new URL(req.url ?? "", "http://x").searchParams.get("owner") ?? undefined) // operator: all (or ?owner)
                 : (principal ?? "__none__"); // non-operator: only its own scope (never others' pending)
-            sendJson(res, 200, { pending: await cs.listPending(scope) });
+            // #209 件4:行整只上 wire(键集契约不变),但 `riskDescriptor.shadowedRule` 这一格先脱敏 ——
+            // 理由与 `/v1/approvals/stream` 共用同一个投影函数,见 `redactPendingDisclosures` 顶注。
+            sendJson(res, 200, { pending: (await cs.listPending(scope)).map(redactPendingDisclosures) });
             return;
         }
         // exemptions surface — the UI's "本会话不再询问" state (list) + revoke. Same authz shape as
@@ -659,6 +661,32 @@ async function handleApprovalsAssistantBody(req, res, url, ctx, miss) {
  *  connection runs its OWN poll loop — fine for a handful of operators; a shared fan-out poll is a future
  *  optimization if the operator count grows.) */
 const APPROVALS_STREAM_POLL_MS = 3000;
+/**
+ * 🔴 #209 件4(codex 对抗复审 R3-[high],验真后修)—— **durable 读面的脱敏投影**。
+ *
+ * core 5.25.0 的 `RiskDescriptor.shadowedRule` = 被越级的那条持久规则的**原文**。core 侧只过
+ * `inlineUntrusted`(中和 + 限长),**不**做秘密脱敏 —— 它的 JSDoc 也只承诺中和,不承诺无秘密
+ * (与同结构里的 `summary` 不同:那一格 core 明写「NEVER raw secrets / full args / env」)。
+ * 而规则原文是**人手写的文本**,一条 `Bash(curl -H "Authorization: Bearer …")` 形的规则完全拼得出来。
+ *
+ * 同步路(`tool_approval` 帧 / `card_json`)在铸点就 `redactSecrets` 了;durable 路两条读面
+ * (`GET /v1/approvals` 与 `/v1/approvals/stream`)此前把 `listPending()` 的行**整只**上 wire ⇒
+ * 同一份内容在两条腿上一条脱敏、一条不脱敏,而 operator 的队列是**跨租户**可见的那一条。
+ *
+ * 修在**读面**而不是落库点,理由是本仓成文的分工(同文件 inbox 段那条 `redactedPreview(s.toolInput)` 的
+ * 逐字理由):「core bounds but does NOT redact it — redaction is the consumer's job」。落库点改写会与
+ * core 的属主面打架,而且救不了**别的副本**已经写下的行。
+ *
+ * 🔴 只动这一格,不顺手洗整只 descriptor:`summary` 有 core 的无秘密承诺、`touchedPaths` 是路径,
+ * 两者的现行为不在本批辖域内(要改得走各自的三问)。键集**不变** —— 「整只透传、不按键投影」那条契约
+ * (`test/approval-shadowed-rule-wire.test.ts` §3)照旧成立,变的只是这一格的**内容**。
+ */
+function redactPendingDisclosures(row) {
+    const rd = row.riskDescriptor;
+    if (rd === null || rd === undefined || typeof rd.shadowedRule !== "string")
+        return row;
+    return { ...row, riskDescriptor: { ...rd, shadowedRule: redactSecrets(rd.shadowedRule) } };
+}
 /**
  * GET /v1/approvals/stream (design/80 native push): SSE — pushes pending-approval deltas so the portal
  * SUBSCRIBES ONCE instead of polling GET /v1/approvals every ~10s (better UX: near-real-time + no client poll
@@ -696,7 +724,9 @@ export async function streamApprovals(req, res, cs, scope, pollMs = APPROVALS_ST
     while (!closed) {
         let pending;
         try {
-            pending = await cs.listPending(scope);
+            // #209 件4:与 `GET /v1/approvals` **同一个**投影函数 —— 两条 durable 读面各洗各的就会漂
+            // (SSE 那条恰恰是 operator 常驻订阅的那条,漏掉它等于没修)。
+            pending = (await cs.listPending(scope)).map(redactPendingDisclosures);
         }
         catch {
             // a transient TiDB blip must NOT kill the subscription — heartbeat + retry next tick (fail-soft)

package/dist/http/routes/capabilities.js

@@ -3,6 +3,7 @@ import { cwdHonored } from "../../task-cwd.js";
 import { mcpInjectionHonored } from "../../task-mcp.js";
 import { sendJson, sendError } from "../send.js";
 import { resolveStreamApprovalGate } from "../../tool-approval.js";
+import { gatedPrincipal } from "../principal-gate.js";
 export async function handleCapabilities(req, res, url, ctx) {
     const miss = { fell: false };
     await handleCapabilitiesBody(req, res, url, ctx, miss);
@@ -75,6 +76,14 @@ async function handleCapabilitiesBody(req, res, url, ctx, miss) {
                     : false;
             })(),
             leader: Boolean(deps.leaderEndpoint),
+            // #F1([3397]-5 同族):sandbox-image-pool 的 P1 面(`GET /v1/images`、`/v1/images/:profile`、
+            // `/v1/images/digests/:digest`、`POST /v1/images/select`)。谓词**逐字**是 routes/images.ts 里那条
+            // 挂载合取式的 `deps.imageIndex` —— 缺席时该域整个不挂载,同文件的能力臂回 501
+            // `capability.image_index_required`(此前是与拼错路由同码的 404,消费端只能 trial-by-404)。
+            // local 后端刻意不实现 `imageIndex()`(池是 cloud/fleet-only),所以单机形上这一位诚实为 false。
+            // ⚠️ 辖域**只到 P1**:`/v1/images/bakes*`(P2 烤制控制面)由独立的 `imageBakes` 依赖挂载,
+            // 且是 operator/runner 内部面,不在本位的承诺里。
+            images: Boolean(deps.imageIndex),
             // design/138 S1 (clay 2026-07-08): the legacy MemoryStore surface (GET/DELETE /v1/memory + the MF-30
             // session write verbs) was DEPRECATED with the store itself — the new memory engine is model file skills
             // over the injected memory dir, with NO service HTTP verbs. Hard-coded false so a shell that still knows
@@ -103,7 +112,22 @@ async function handleCapabilitiesBody(req, res, url, ctx, miss) {
             // #154 车二 + #203 §2:规则车道(cc-import 两口 + 撤销面两口 + respond 的 persistRule 兑付口)。
             // 谓词与 `/v1/rules/*` 全族的 501 同源:ruleConsent lane 在场 ⟺ 总开关未被显式关 ∧ 规则店 wired
             // (SQL 双方言,或 #203 起 local 的 File 三面束)。说 yes ⟺ **四口都活**,不是「有一口活」。
-            permissionRules: Boolean(deps.ruleConsent),
+            //
+            // 🔴 A-010.20(验真后修,补第二条合取项):店在场**不等于**这四口活。规则车道是
+            // **principal 寻址**的 —— `routes/rules.ts` 的域头逐字是 `if (principal === undefined) 401`
+            // (无条件,与 `requirePrincipal` 无关),而铸卡侧 `buildRuleLaneMaterial` 与回决侧
+            // `persistRuleAfterDecision` 都有同源的 `owner === null ⇒ 不进车道 / rule_lane_unavailable` 一门。
+            // 于是「装了店、但调用方没有可验证身份」的部署上,旧谓词报 true 而**四口全废**:两口恒 401、
+            // 卡上恒无候选、`persistRule` 恒被拒。#203 给 local 车道接上 File 店之后,「单机 + 无 principal」
+            // 第一次同时满足其余条件 —— 这不再是纸面形。
+            //
+            // 🔴 为什么这一位是**按调用方**算而不是按部署算:`requirePrincipal=false` 的部署上,带 principal
+            // 的调用方与不带的调用方**答案真的不同**(前者四口全活,后者全废),没有任何一个部署级布尔能同时
+            // 对两者不说谎。`/v1/capabilities` 是每请求读面且与 `/v1/rules` 走同一道全局凭证门,所以
+            // 「这一位说 yes」⟺「**你**拿同一份头去打那四口真的能用」——这正是本文件顶注承诺的那条等价。
+            // ⚠️ 与下面的 `permissionRulesRevoke` **刻意不同源**:那一位是**存在性/版本**信号(见其注),
+            // 必须与调用方身份无关,否则老版本探测会把「我没带 principal」误读成「这个 worker 太老」。
+            permissionRules: Boolean(deps.ruleConsent) && gatedPrincipal(req, deps.config) !== undefined,
             // #205 SDK 车上游请托二连(2026-08-10):
             //  · `permissionRulesRevoke` —— 撤销面两口(GET/DELETE /v1/rules)**存在性**的独立信号。谓词与
             //    `permissionRules` 同源,但**在场性**本身就是版本信号:≤7.11.0 的 worker `permissionRules` 已为
@@ -135,8 +159,11 @@ async function handleCapabilitiesBody(req, res, url, ctx, miss) {
             // served this task — the RESOLVED `Model.id`, not the requested `TaskSpec.model` ref … Lets a UI echo
             // 'served by X'". A grep for the identifier `effectiveModel` returns zero hits in core and that was mistaken
             // for "core doesn't have it" (search by SEMANTICS, not by identifier name). It already reaches the wire:
-            // `POST /v1/tasks` returns the TaskResult verbatim (~L1852), the SDK declares `TaskResult.model`, and this
-            // server already consumes it internally for cache-family accounting (~L1843). Pinned by
+            // `POST /v1/tasks` returns the TaskResult verbatim (`routes/tasks.ts` `sendSubmitResult` — the sync submit
+            // leg's one response mouth; design/158 A9 moved the whole sync-submit surface OUT of `http/server.ts`, so the
+            // old `~L1852` anchor into that file is dead), the SDK declares `TaskResult.model`, and this server already
+            // consumes the resolved id internally for cache-family accounting (`budget.ts` `cacheFamilyOfMirror` + its
+            // caller in `routes/side-query.ts`, NOT `http/server.ts`). Pinned by
             // `test/effective-model-echo-wire.test.ts` (real HTTP: resolved id echoed, absent key stays absent) so a
             // future projection/whitelist on this leg can't silently drop it — the `toolEndEventData`-label bug class.
             // Nothing is advertised as a capability BIT here because an additive result field needs no gate
@@ -330,9 +357,12 @@ async function handleCapabilitiesBody(req, res, url, ctx, miss) {
             //    `workflowsCapability(deps)` (hardened script runner ∧ governance), boot-computed in main.ts. Falls back
             //    to the `Boolean(workflowRunStore)` proxy when the boot flag isn't wired (older callers / tests).
             //  • `workflowsList` = can durably LIST workflow runs = `Boolean(workflowRunStore)` (GET /v1/workflows* 501s
-            //    without it — list AND detail/stream, see the store gate ~L731).
+            //    without it — list AND detail/stream, see the store gate in `routes/workflows.ts`, the
+            //    `if (!deps.workflowRunStore)` → 501 `capability.self_orchestration_required` arm).
             // ⚠️ In the CURRENT service wiring these two COINCIDE: `workflowRunStore` is built IFF self-orchestration is on
-            // (InMemoryWorkflowRunStore when WORKFLOW_RUN_STORE=memory, else File — main.ts ~L527), the SAME gate that
+            // (InMemoryWorkflowRunStore when WORKFLOW_RUN_STORE=memory, else File — built in
+            // `boot/workflow-orchestration.ts`, which design/158 A10 split out of main.ts; main.ts itself no longer
+            // mentions InMemoryWorkflowRunStore at all, so the old `main.ts ~L527` anchor is dead), the SAME gate that
             // wires the safe script runner `workflowsCapability` checks → `Boolean(workflowRunStore)` ≡ `workflowsCapability`
             // always today. So this split is core's FORWARD-LOOKING orthogonal-axes CONTRACT, NOT a fix for a live
             // divergence (the earlier "memory backend → no store → divergence" framing was WRONG — InMemory IS a store;

package/dist/http/routes/images.js

@@ -490,6 +490,24 @@ async function handleImagesBody(req, res, url, ctx, miss) {
             return;
         }
     }
+    else if (url === "/v1/images" || url.startsWith("/v1/images/")) {
+        // 🔴 #F1([3397]-5 同族缺口):索引缺席时**整个域不挂载**,请求此前一路落到全局路由表尾的
+        // `404 not_found.route` —— 与「路由拼错了」同一个码,消费端结构上分不出「这个部署没接这个面」
+        // 与「我 URL 写错了」(trial-by-404 的最坏形:两种成因的处置完全相反)。改成诚实的能力拒。
+        //
+        // 谓词与上面那条挂载合取式**同一个符号**(`deps.imageIndex`),所以 `/v1/capabilities` 的 `images`
+        // 位(同一谓词)说 yes ⟺ 这条臂不触发 ⟺ 目录读面真能用。
+        //
+        // ⚠️ 判据是**按段**的(`=== "/v1/images"` 或 `"/v1/images/"` 前缀),不是上面挂载式那个裸前缀:
+        // `/v1/imagesfoo` 是**拼错的路由**,不是本域的路径,它该继续拿 404(索引在场的部署上它本来就落 404
+        // —— 两种部署形对同一个手滑给出不同的码,那正是本臂要消灭的那种含糊)。
+        //
+        // ⚠️ bake 子面**不误伤**:`deps.imageBakes` 在场时 `/v1/images/bakes*` 已在本函数最上面的域里应答
+        // 并 `return`,走不到这里;两者都缺席时(local 后端的真实形态——两个工厂它都不实现)本臂如实
+        // 回答「这个部署没有 sandbox-image-pool」,那对 bakes 路径也是真话。
+        sendError(res, 501, "capability.image_index_required", "the sandbox-image-pool requires a SQL store backend (DB_BACKEND=mysql|pg) — the local backend wires no image index");
+        return;
+    }
     miss.fell = true;
 }
 /** The image_bake SSE (P2.2/P2.8) — the SAME pump, with the run-trace-SSE-shaped bake frame

package/dist/http/routes/runs.js

@@ -161,11 +161,27 @@ async function streamRunEvents(req, res, deps, runStore, taskId, staleMs) {
         // 「开关关 = 逐字零变化」(§6.5/§7.2)当场破。谓词同时省掉了关闭态每次开流的一次 store 往返
         // 与那份 store 故障暴露面。钉:场景9(零帧 **且** 零 store 读 —— 只钉零帧会放过「读了但没投」)。
         preamble: async (signal) => {
-            if (!deps.config.streamApproval.enabled)
+            // 🔴 A-010.7(验真后修):谓词是**上场门**,不是裸开关。
+            // 原式是 `if (!config.streamApproval.enabled) return []` + 一个 `backend?.approvalAsk()` 兜底,
+            // 那是本仓早就收编掉的「局部合取式」形(见本文件 askDecision 口的头注:车4 落地时的临时判据,
+            // 交接条件写死了「换成消费**那一个**谓词」)。两处不同源的后果在 `STREAM_APPROVAL` 默认翻 ON
+            // 之后才显形:上场门是**五**项合取(还要 toolApproval 在场、账本非易失 `kind !== "local"`、
+            // park 设施在场),而这里只看了两项 ⇒ 一个协议**没有上场**的 SQL 部署
+            // (典型:`TOOL_APPROVAL_ENABLED=false`,或没开 `DURABLE_APPROVAL` ⇒ 无 park 设施)
+            // **每一次开流都照打一次库** —— 一次纯白打的 `listPendingByTask`,外加那份 store 故障暴露面,
+            // 而它按契约永远只能投出零帧(协议没上场 ⇒ 没有任何一条 `STREAM_PENDING` 行是本协议铸的)。
+            // 换成单一谓词后,「能力面说 false」⟺「本腿零 store 往返」是结构成立的。
+            const gate = resolveStreamApprovalGate({
+                toolApprovalEnabled: Boolean(deps.toolApproval),
+                streamApprovalEnabled: deps.config.streamApproval?.enabled === true,
+                backend: deps.backend,
+                parkFacility: deps.checkpointStore !== undefined,
+            });
+            // 协议未上场 ⇒ 零帧**且零 store 读**(场景9 的钉打的就是这两件事,不只是零帧)。
+            // env-only worker(无 durable backend)在 `no_backend` 那条臂上一并收掉:无 ask 账 ⇒ 无对账基准。
+            if (!gate.active)
                 return [];
-            const store = deps.backend?.approvalAsk();
-            if (!store)
-                return []; // env-only worker(无 durable backend)= 无 ask 账 ⇒ 无对账基准,诚实缺席
+            const store = gate.askStore;
             const rows = await store.listPendingByTask(taskId, signal);
             const { frames, skipped, dropped } = buildApprovalPreamble(rows, Date.now(), deps.config.streamApproval.replayMax);
             if (skipped > 0)
@@ -284,7 +300,7 @@ async function handleRunsBody(req, res, url, ctx, miss) {
                     return { status: 202, body: { taskId: clientTaskId, sessionId, status: "running" } };
                 }
                 // [2255]① 真出路材料:activeTaskStatus + parked 时 pendingGate{kind,decidePath}(best-effort,失败退旧形)
-                return { status: 409, body: await buildActiveRunConflict({ runStore, checkpointStore: deps.checkpointStore }, sessionId, created.activeTaskId) };
+                return { status: 409, body: await buildActiveRunConflict({ runStore, checkpointStore: deps.checkpointStore, governance: deps.config }, sessionId, created.activeTaskId) };
             }
             // Durable F4: persist the resume rebuild inputs (sessionId-keyed) so an operator can resume from any
             // replica even after this worker is gone — core's checkpoint blob can't carry service scenario context.

package/dist/http/routes/tasks.js

@@ -219,14 +219,26 @@ async function handleTasksBody(req, res, url, ctx, miss) {
             // 有界(2s)+ fail-open:store 抛或挂起都只记一次 warn、零卡继续开流(§5.3)。
             // 🔴 开关谓词与 runs.ts 同源同理由(codex 复审第二轮 high:回滚下表里可能有残留 STREAM_PENDING
             // 行,无谓词会破「开关关 = 逐字零变化」;顺带省掉关闭态每次开流的一次 store 往返)。钉:场景9。
-            const replaySessionId = deps.config.streamApproval.enabled ? prepared.spec.sessionId : undefined;
+            //
+            // 🔴 A-010.7 随修(**兄弟扫查**:台账只点名了 runs.ts 那一处,这里是同形的第二处):谓词是
+            // **上场门**不是裸开关。五项合取(协调器在场 / 开关真 / backend 在场 / 账本非易失 / park 设施在场)
+            // 里少查三项 ⇒ 一个协议根本没上场的 SQL 部署,每次开流仍要白打一次库;回滚时更坏 —— 别的副本
+            // 落下的残留 `STREAM_PENDING` 行会被无门的重放腿照常投上 wire。换成与协调器注入 / 能力面 /
+            // 回决 501 口**同一个**谓词,「说没上场」⟺「零帧且零 store 读」才是结构成立的。
+            const replayGate = resolveStreamApprovalGate({
+                toolApprovalEnabled: Boolean(deps.toolApproval),
+                streamApprovalEnabled: deps.config.streamApproval?.enabled === true,
+                backend: deps.backend,
+                parkFacility: deps.checkpointStore !== undefined,
+            });
+            const replaySessionId = replayGate.active ? prepared.spec.sessionId : undefined;
             if (replaySessionId) {
                 const replayOwner = gatedPrincipal(req, deps.config) ?? null;
+                const askStore = replayGate.active ? replayGate.askStore : undefined;
                 const preambleFrames = await collectSsePreamble(async (signal) => {
-                    const store = deps.backend?.approvalAsk();
-                    if (!store)
+                    if (!askStore)
                         return [];
-                    const rows = await store.listPendingBySession(replaySessionId, replayOwner, signal);
+                    const rows = await askStore.listPendingBySession(replaySessionId, replayOwner, signal);
                     const { frames, skipped, dropped } = buildApprovalPreamble(rows, Date.now(), deps.config.streamApproval.replayMax);
                     if (skipped > 0)
                         deps.logger?.warn?.("approval_preamble_row_skipped", { sessionId: replaySessionId, skipped, face: "tasks.stream" });
@@ -307,7 +319,7 @@ async function handleTasksBody(req, res, url, ctx, miss) {
                     if (created.ok)
                         deps.sessionTitler?.maybeTitle(prepared.spec.sessionId, prepared.spec.objective, typeof prepared.spec.model === "string" ? prepared.spec.model : prepared.spec.model?.id); // fire-and-forget; in-titler dedupe;model 跟 turn([1992]②)
                     if (!created.ok) {
-                        const conflict = await buildActiveRunConflict({ runStore: deps.runStore, checkpointStore: deps.checkpointStore }, prepared.spec.sessionId, created.activeTaskId); // [2255]① 真出路材料
+                        const conflict = await buildActiveRunConflict({ runStore: deps.runStore, checkpointStore: deps.checkpointStore, governance: deps.config }, prepared.spec.sessionId, created.activeTaskId); // [2255]① 真出路材料
                         // Headers are already SSE — encode the rejection as the stream's terminal event; the 409 in
                         // the returned resp is for a deduplicated concurrent caller (and is never idem-cached).
                         // done 帧 additive 携带同一份材料 —— 形状铸在 toDoneFrameResult(有名字有类型),不在这行内联挑键。
@@ -1225,7 +1237,7 @@ async function handleTasksBody(req, res, url, ctx, miss) {
                     const tid = uuidv7();
                     const created = await deps.runStore.createRun(tid, prepared.spec.sessionId, principal ?? null, deps.instanceId ?? "default", runMeta(prepared, source));
                     if (!created.ok)
-                        return { status: 409, body: await buildActiveRunConflict({ runStore: deps.runStore, checkpointStore: deps.checkpointStore }, prepared.spec.sessionId, created.activeTaskId) }; // [2255]① 真出路材料
+                        return { status: 409, body: await buildActiveRunConflict({ runStore: deps.runStore, checkpointStore: deps.checkpointStore, governance: deps.config }, prepared.spec.sessionId, created.activeTaskId) }; // [2255]① 真出路材料
                     deps.sessionTitler?.maybeTitle(prepared.spec.sessionId, prepared.spec.objective, typeof prepared.spec.model === "string" ? prepared.spec.model : prepared.spec.model?.id); // fire-and-forget;model 跟 turn([1992]②)
                     durableTaskId = tid;
                 }

package/dist/http/routes/trace-usage.js

@@ -255,6 +255,11 @@ async function handleTaskArtifacts(res, runStore, taskId) {
  *    trace 的 tool-result 块与本判据读的是同一份日志,所以「trace 上看得见 ⇒ 这里读得到」成立;
  *    同 session 里**别的 task** 的 ref(或日志已过保留窗被逐出的)按 404 同形拒,请到那条 task 上读。
  *
+ *    🟢 **两条残余已随 core 5.26.0 #119 销账**(下面原文保留作病历)。core 按当年这里写的方向动了刀:
+ *    `put` 带出处落库 + `ownerOf` 读回,读面改用出处判定(实现见 ②-a),于是 (a) 合成 id 铸的 ref 不再
+ *    读不到、(b) 拼接非单射的越权面结构上消失(ref 铸法本身也换成 `~` 四段单射)。日志重铸只剩**存量
+ *    兜底**一条腿(无出处的旧行),新写入一律经出处。
+ *
  *    ⚠️ 两处**已知残余**,都要 core 侧动刀才能消,写在明处而不是让下一个人自己撞(codex 复审 R3):
  *
  *    (a) **覆盖面**:core 除了「按工具调用 id 卸载」这条主路,还从**合成 id** 铸 ref ——
@@ -315,22 +320,46 @@ ref, query) {
     const run = ownedRun ?? (await runStore.getRun(taskId));
     if (!run)
         return notFound();
-    // ② 精确成员判定(见头注):本 task 耐久日志作证过的 toolCallId,经 core 同一个铸造点变成 ref 集合。
-    // 成本口径:整份日志一读一扫,与同域的 `/turns`、`/artifacts` 同款(不是本面引入的新量级);分页读会
-    // 逐页重扫 —— 真消要一张 (task, ref) 出处索引,与上面 (a) 是同一件 core/store 侧的活。
-    const events = await runStore.getEvents(taskId, 0);
-    let attested = false;
-    for (const ev of events) {
-        // 取键姿势与同域的 `trace/artifacts.ts` 逐字同款(同一份日志、同一个字段,读法不该有第二种)。
-        const { toolCallId: id } = (ev.data ?? {});
-        // 逐条比对而不是先建全集:命中即停,长日志上不必把整份集合物化。
-        if (typeof id === "string" && id.length > 0 && buildToolResultRef(run.sessionId, id) === ref) {
-            attested = true;
-            break;
+    // ②-a 出处判定(#119,core 5.26.0 —— 上面 (a)/(b) 两条残余的**正解到货**)。
+    // 店里现在自己记着「这枚 ref 属于谁」(`put` 的第三参落库,`ownerOf` 读回),读面拿**自己已知的字段**
+    // 比对即可:零解析、零段转义规则复制,合成 id 铸的 ref 与拼接歧义两条残余同时消失。
+    //
+    // 🔴 为什么必须改而不是"锦上添花":5.26.0 起 offload ref 是四段单射形(内容坐标进 ref),服务端手里
+    // 没有内容 ⇒ 下面那条重铸判据**重铸不出来** ⇒ 每一枚真 offload ref 都会 404。读面整死。
+    //
+    // ⚠️ 辖域(有意的口径变化,写在明处):出处的粒度由 core 定 —— offload/budget/projection 三个写点只声明
+    // session,把 taskId 钉在那里会把「一个 session 的两条 task 共用一枚 ref」这个**设计内**的共享形变成拒绝
+    // (core d.ts 逐字裁过)。所以有出处时的判据是「同 session,且出处**若点名了** task 则必须是本 task」——
+    // 相对旧的「本 task 日志作证过」是**放宽到同 session**。放宽的边界仍在 owner 之内(run 归属门在本函数
+    // 之前已过,session 的属主就是这个 caller),换来的是这条读面在 5.26.0 上还活着。
+    const owner = store?.ownerOf ? await store.ownerOf(ref) : undefined;
+    const ownedByThisCaller = owner !== undefined && owner.sessionId === run.sessionId && (owner.taskId === undefined || owner.taskId === taskId);
+    // ②-b 无出处兜底:**没声明属主**的行按老判据走 —— 本 task 耐久日志作证过的 toolCallId,经 core 同一个
+    // 铸造点变成 ref 再精确相等。unowned 本身不是授权(core:读面对 unowned 一律 fail-closed),日志作证才是。
+    //
+    // ⚠️ 这条**不是**「读得到升级前的存量行」(codex 复审 medium,已核真并改口):5.26.0 的
+    // `buildToolResultRef` 铸的是 `~` 分隔形,重铸不出旧引擎的 `tr_<sid>_<call>`,而按旧规则手写一个 legacy
+    // 编码器 = 复制上游规则(本文件头注自己禁掉的那件事)。真正的处置在别处 —— 本批要求**删表重建**
+    // `tool_result`(见 CHANGELOG),所以升级后库里根本没有旧行。这一支覆盖的是「5.26.0 引擎写下、但写点
+    // 没声明出处」的行(core 自家的 offload 写点都带出处,所以现实里几乎为空),留着是纵深不是承诺。
+    // 成本口径:整份日志一读一扫,与同域的 `/turns`、`/artifacts` 同款;有出处时**根本不读日志**。
+    if (!ownedByThisCaller) {
+        if (owner !== undefined)
+            return notFound(); // 出处在,但不是这位 —— 不给第二次机会(日志重铸绕不过出处)
+        const events = await runStore.getEvents(taskId, 0);
+        let attested = false;
+        for (const ev of events) {
+            // 取键姿势与同域的 `trace/artifacts.ts` 逐字同款(同一份日志、同一个字段,读法不该有第二种)。
+            const { toolCallId: id } = (ev.data ?? {});
+            // 逐条比对而不是先建全集:命中即停,长日志上不必把整份集合物化。
+            if (typeof id === "string" && id.length > 0 && buildToolResultRef(run.sessionId, id) === ref) {
+                attested = true;
+                break;
+            }
         }
+        if (!attested)
+            return notFound();
     }
-    if (!attested)
-        return notFound();
     if (!store)
         return notFound(); // durable store 缺席:404 同形,不 501(不泄露部署形)
     const slice = await store.get(ref, { ...(offset !== undefined ? { offset } : {}), ...(limit !== undefined ? { limit } : {}) });

package/dist/http/server.d.ts

@@ -511,23 +511,49 @@ export declare function validateUserSkills(skills: unknown): string | null;
  *   POST /v1/runs             → async: 202 {taskId, sessionId, status}, runs in background (S1)
  *   GET  /v1/runs/:id         → run status + result (poll)
  *   GET  /v1/runs/:id/events  → SSE replay from Last-Event-ID, then tail to terminal (S2)
- *   POST /v1/sessions/:id/wake→ 501 (resume is implicit: re-issue a task with the same sessionId)
+ *   POST /v1/sessions/:id/notify → inject an out-of-session event (design/144 §2): live stream ⇒ core
+ *                                  `TaskStream.notify()`; idle ⇒ parked in the session inbox, drained
+ *                                  as a `task_notification` on the next stream open
+ *   POST /v1/sessions/:id/wake   → wake a `task_done` pure park with a message and resume it
+ *                                  (design/144 §3). NOT a gate decision — a pending gate is refused
+ *                                  (`wake.gate_pending`). Goes through `resumeWake`, which reuses the
+ *                                  resume family's lease/CAS/run-log leg, so it BURNS MODEL TOKENS and
+ *                                  is subject to the billable-submit gates (`SESSION_WAKE_RE`).
+ *   (both live in `http/routes/notify-wake.ts` — design/158 A9 domain split)
  */
 export declare function createHttpServer(rawDeps: ServiceDeps): http.Server & {
     denyExpiredApprovals: (now: number) => Promise<void>;
 };
-/** SSE: replay durable events after Last-Event-ID, then tail until the run is terminal (or stale). */
-/**
- * The differences a concrete log (task_run | image_bake) feeds the ONE resumable SSE reader (P2.8). Everything
- * the reader does — Last-Event-ID/`?from=` resume, the 416 retention boundary, the per-poll concurrent
- * status+events read, the terminal re-fetch (the terminal event lands in the gap before the status flips), the
- * stale fallback, the 15-min cap, the 15s idle heartbeat — is provider-agnostic and lives in `streamSseLog`.
- * 🔴 The task_run provider MUST keep the existing wire bytes EXACTLY (center's relay + 730+ tests depend on it).
- */
 /** POST endpoints that trigger BILLABLE work — the fail-closed auth guard must cover ALL of them (council: the
  *  guard's inline list had drifted from the handlers and missed `/v1/approvals/:id/decide`, which resumes a run
  *  via resumeCheckpoint/store.decide → paid tokens). Keep this in sync when adding a billable POST route. */
 export declare function isBillableSubmitPath(url: string): boolean;
+/**
+ * A-010.23(#209 件5)—— **改写门**:不烧模型、但在**没有任何 service credential** 的部署形下必须与
+ * billable / bake 两族一样 fail-closed 的写门。谓词与 `isBillableSubmitPath` **刻意分开**:这几扇门
+ * `billable=false`(零模型工作),塞进那张名单会让它们连带吃 drain 与 model-roster-pending 两道 503 ——
+ * 而收编与规则读写在排空期/roster 未落时做完全无害。
+ *
+ * 判据(两个合取项,缺一不进本表)= 「授权的唯一输入是 principal 头」∧「动作是**持久改写**」:
+ *  · `POST /v1/adoption` —— operator-only 的一次性部署级动作,把一个 principal 名下**每一行**重写到另一个
+ *    身份;授权判据 `explicitOperatorOk(gatedPrincipal(...))`。
+ *  · `POST /v1/rules/cc-import/*` —— principal lane 的**持久 allow 规则**铸造口;一条持久 allow 规则对后续
+ *    同命令的 classify 档 ask 常驻消音(core #144 之后仍然如此,只是不再消 mandated 的那些)。
+ *  · `DELETE /v1/rules` —— 同一个规则店的**撤销**口。方向相反(收紧)但同样是持久改写,而且它多一条
+ *    operator 越权域(`?principal=` / body 的 `principal` 让 operator 收回**任一**租户的规则)⇒ 伪造一个
+ *    列在 `OPERATOR_PRINCIPALS` 里的头,就能把每一位租户的规则一次清空。
+ * 无 service token 的部署上 `verifiedPrincipal` 走的是「BFF/gated:头已由上游验过」那一支,而这一形恰恰
+ * 是**没有**那个上游 —— 于是伪造一个头就能收编别人、替任意租户种下常驻放行、或替他们全删。bake 门当年
+ * 补的就是同一句话,`isDestructiveSessionWrite` 从逐条路由白名单改成族判定也是同一句话(那次的措辞逐字是
+ * 「a forged principal header alone could **tighten/DoS** a session's tools」——撤销口落的正是 DoS 那一半)。
+ *
+ * 🔴 **方法感知**(codex 对抗复审 R2-[high],验真后修):撤销走的是 `DELETE`,而本门最初只挂在 `POST` 的
+ * 合取里 —— 于是一个自称「持久改写」的谓词把爆炸半径最大的那条动词漏在门外,正是 `isDestructiveSessionWrite`
+ * 当年被抓到的同一形。签名因此收方法,与那只谓词逐字同形。
+ * 🔴 读面不进本表:`GET /v1/adoption/:id` 与 `GET /v1/rules` 各有自己的属主/operator 门,本门只拦写。
+ * 行为面钉:`test/rewrite-door-service-token-gate.test.ts`(四扇门各一正一反 + 逃生口格 + 读面负控)。
+ */
+export declare function isCredentialGatedRewrite(method: string, url: string): boolean;
 /** Stable, low-cardinality route label for metrics/logs (ids collapsed to `:id`).
  *  [#104] 字面量**先于**模式:此前模式先查,五条精确路由被形状桶吞掉(`/v1/approvals/stream`
  *  落 ":id"、`/v1/images/{bakes,select,register}` 落 ":profile"、`/v1/images/bakes/claim` 落