@sema-agent/server 7.12.0 → 7.14.0

package/dist/http/server.js

@@ -26,7 +26,10 @@ import { redactSecrets } from "../trace/redact.js";
 import { IdempotencyCache, scopedIdempotencyKey } from "./idempotency.js";
 export { scopedIdempotencyKey };
 import { streamSseLog } from "./sse-log.js";
-import { clampVerifyRounds, verifyRoundsFromBody } from "./verify-rounds.js"; // design/97 R9: the shape's neutral leaf (route-ctx.ts type-imports VerifyRoundsSpec from here, not from this file)
+// design/97 R9: the shape's neutral leaf (route-ctx.ts type-imports VerifyRoundsSpec from here, not from this file).
+// `clampVerifyRounds` used to be re-exported from here for the tests; that re-export was deleted (8566348) and the
+// import sat on as a dead name — tests import it from `verify-rounds.js` directly, which is the single owner.
+import { verifyRoundsFromBody } from "./verify-rounds.js";
 import { handleCapabilities } from "./routes/capabilities.js";
 import { handleObservability } from "./routes/observability.js";
 import { handleDiagnostics } from "./routes/diagnostics.js";
@@ -135,7 +138,14 @@ function isCheckpointReopenedFailure(r) {
 // named alias so the existing call sites read clearly; the JWT logic now lives in one place that createAuthorizer
 // shares, so spec.principal (governance + cost) and these observability/owner sites can never drift apart again.
 /** design/158 A9 装配表(顺序 = 拆分前 `handle()` 里各域出现的先后,逐行同序;真正的 `return` 在 handle 内,
- *  这里只做**签名一致性**的编译期钉:任何域入口漂了形,是编译红,不是运行时静默 404)。 */
+ *  这里只做**签名一致性**的编译期钉:任何域入口漂了形,是编译红,不是运行时静默 404)。
+ *
+ *  🔴 A-010.24(验真后修):上面那句「逐行同序」此前是**一句自述,没有任何东西执法**,而它已经不成立 ——
+ *  `handleDiagnostics` 从来没进过这张表,车二着陆后 `handleRules` / `handleSharedMemory` 的先后也反了。
+ *  类型钉不住这两类漂:少一个成员、调换两个成员,`RouteHandler[]` 全都收下。而这张表是评审时唯一会被
+ *  当成「域全集 + 域次序」来读的清单(新域该插哪儿、某域在谁之后才可达),它给错答案是要害。
+ *  执法面现在真的有了:`test/route-shape-roster.test.ts` 的**层D**从 `handle()` 的真源码抽出域调用序,
+ *  与本表**逐项**对拍 —— 漏员或乱序都指名道姓地红。改 handle() 的次序时,这张表要跟着改。 */
 const ROUTE_DOMAINS = [
     handleTraceUsage,
     handleWorkflows,
@@ -150,10 +160,11 @@ const ROUTE_DOMAINS = [
     handleImages,
     handleApprovalsAssistant,
     handleObservability,
+    handleDiagnostics,
     handleAdoption,
     handleMemoryPolicy,
-    handleSharedMemory,
     handleRules,
+    handleSharedMemory,
     handleSessionsList,
     handleSessions,
     handleSessionSync,
@@ -169,7 +180,15 @@ void ROUTE_DOMAINS;
  *   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 function createHttpServer(rawDeps) {
     // design/158 A8:分组装配 → 平铺视图。**分组是装配面的形,不是消费面的形**——下面 ~700 处 `deps.x`
@@ -528,10 +547,16 @@ export function createHttpServer(rawDeps) {
         // The bake door (POST /v1/images/bakes*) is build-host-RCE-capable and authed by the Bearer-token-no-cookie
         // model (§P2.4b) — it MUST also refuse when no service token is configured (else a forged principal header
         // alone could reach an operator-gated RCE door).
-        if (req.method === "POST" &&
-            !anyServiceAuth &&
+        // A-010.23 (#209 件5) adds the same sibling arm for the REWRITE doors (`isCredentialGatedRewrite`:
+        // adoption + rules/cc-import + rules revoke) — same sentence, same threat, different verbs: one rekeys every
+        // row a principal owns, one mints that principal's DURABLE allow rules, one deletes them. They stay OUT of
+        // `isBillableSubmitPath` on purpose (billable=false; see that predicate's twin comment), and that family is
+        // METHOD-AWARE (its revoke verb is DELETE) so it is evaluated OUTSIDE the POST conjunct — same shape as
+        // `isDestructiveSessionWrite` below.
+        if (!anyServiceAuth &&
             !deps.config.allowUnauthedWrites &&
-            (isBillableSubmitPath(url) || url.startsWith("/v1/images/bakes"))) {
+            ((req.method === "POST" && (isBillableSubmitPath(url) || url.startsWith("/v1/images/bakes"))) ||
+                isCredentialGatedRewrite(req.method ?? "", url))) {
             sendError(res, 503, "auth.service_token_required", "this worker requires a service auth token (set SERVICE_AUTH_TOKEN) before accepting task submissions");
             return;
         }
@@ -2187,9 +2212,13 @@ export function createHttpServer(rawDeps) {
                     return { status: 200, body: { taskId, sessionId, status: "failed", errorCode: "cancelled" } };
                 }
                 // We flipped the row to `running` (claimedRow). Two CheckpointError classes diverge here (D-1, core 1.101):
-                //  • TERMINAL (already_resolved / not_found / gate_mismatch / unsupported_version): the checkpoint is
+                //  • TERMINAL (already_resolved / not_found / gate_mismatch): the checkpoint is
                 //    consumed or gone — drive the row terminal now (releasing task_active) instead of leaving a zombie
                 //    `running` row for reapStale to mislabel and hold the session lock for ~runStaleSec. (Original case.)
+                //    ⚠️ `unsupported_version` USED to sit in this bullet unconditionally (its checkpoint does NOT go
+                //    away — that was the registered orphan debt). As of #209 / core 5.25.0 it SPLITS on
+                //    `detail.reason`: a recognised worker-swap word joins the retriable class below; an absent /
+                //    unrecognised word stays TERMINAL. Read the block under the closed set before touching it.
                 //  • RETRIABLE PRE-CAS (invalid_outcome = binding mismatch / reopen_revote = env_failed must replay the
                 //    persisted winner / reopened_concurrently = a concurrent resolve-reopen advanced the rev): the
                 //    checkpoint STAYS pending and the operator re-fetches + re-/decides. Driving the row terminal would
@@ -2207,7 +2236,34 @@ export function createHttpServer(rawDeps) {
                     // 会释放 task_active 并孤儿化那条仍 pending 的卡 —— 一张还能点的卡当场变死件。
                     e.code === "resume.constraint_rejected" ||
                     e.code === "resume.constraint_unprojectable" ||
-                    e.code.startsWith("wake."); // design/144:wake 拒绝(gate_pending/nothing_to_deliver)全是 PRE-CAS,checkpoint 保持 pending——驱 terminal 会孤儿化仍在等的 park
+                    e.code.startsWith("wake.") || // design/144:wake 拒绝(gate_pending/nothing_to_deliver)全是 PRE-CAS,checkpoint 保持 pending——驱 terminal 会孤儿化仍在等的 park
+                    // 🟢 **`checkpoint.unsupported_version` 的一臂精确 retriable**(#209 件2,core 5.25.0 提货批
+                    // [3443];取代 #205 件4② 那条「维持 TERMINAL + 孤儿代价在案」的登记账)。
+                    //
+                    // 旧账的形状(留着,因为它解释了为什么这条臂长这样):该码在 core 上有**三个** PRE-CAS 铸点
+                    // (版本超上限 / org 治理行落到无 `permissionRuleOrg` 的 worker / 带 remote `workspaceHandle` 的行
+                    // 落到无 `executionEnvFactory` 的 Runner),三形卡一律留 pending 但**可恢复性不同**,而 core 当时
+                    // 同码同 `detail`(都不带)⇒ 下游只剩「按报文文案猜」或「按 checkpoint 形状反推」两条路,两版修法
+                    // 各被一轮 codex 对抗复审验伪(blanket-retriable 让无手臂永挂 task_active;按 `gate.realApproval`
+                    // 分流不健全 —— core 把该位放 gate、`workspaceHandle` 放 state,同一条行可以两样都带)。按宪法
+                    // 「源头修复,禁下游旁路」全回退,并把判别式列成上游请托([3434] 请托 1)。
+                    //
+                    // 请托已兑现:core 5.25.0 起三个铸点各带 `detail.reason`(`runtask.js:3706/3721/3733` 亲读),
+                    // d.ts 逐字说三者都是「retryable on a newer / factory-wired / org-wired worker」。⇒ 本臂**读词表**
+                    // (`WORKER_SWAP_REDEEMABLE`,闭集、新词 tsc 红),不做任何形状推断:
+                    //  · 认得的三个词 ⇒ retriable:行重新 park suspended,那条仍 pending 的卡不再被孤儿化
+                    //    (旧账里「行 failed 而卡活着、下一次 /decide → 404、只能等 `terminal_at_ms`」的代价至此销掉)。
+                    //  · 词缺席 / 认不得 ⇒ **维持 TERMINAL**(旧行为逐字保留)。这不是保守的装饰:旧引擎的裸抛与
+                    //    将来某个我们还没读过的新臂都落在这一支,而把它们默认成 retriable 会把一条**真的没救**的行
+                    //    永久 park 在 suspended 上攥着 task_active —— 那正是 codex R1-[high] 验伪掉的那一版。
+                    // 🔴 形③(`env_factory_missing`)按 core 的词判 retriable,而不是按 #205 那条「选 Runner 由
+                    // `handsLanes.laneOf(spec)` 按场景判,重投永远同样失败」的推断:那条推断说的是**同一份部署配置下**
+                    // 重投无用,而 core 的词说的是「接上 `executionEnvFactory` 的 worker 兑得掉」—— 那是一次运维动作,
+                    // 与 `governed_unwired` 要求接 `permissionRuleOrg` 完全同族。两者都不是「换个副本再点一次」。
+                    // 期间行停在 suspended 攥着会话锁,与它 park 时的状态**逐字相同**(这条腿只是没能把它推进),
+                    // 而 TERMINAL 那一支要用「释放锁」换「卡变死件」,方向更坏。
+                    // 行为面钉:`test/durable-resume-http.test.ts` 的「#209 件2」三正格 + 三反极格。
+                    (e.code === "checkpoint.unsupported_version" && checkpointRowRedeemableElsewhere(e.detail?.reason));
                 if (claimedRow && taskId && deps.runStore) {
                     // Re-park on the SAME gate family the outcome targeted: a plan_review retry must re-park `needs_review`
                     // (keep the row's review status + the lock), not `suspended` — else GET /v1/assistant/tasks mislabels it.
@@ -2798,14 +2854,19 @@ export function createHttpServer(rawDeps) {
     // value AS an http.Server — listen/close/etc. — while main.ts's reaper reads server.denyExpiredApprovals).
     return Object.assign(server, { denyExpiredApprovals });
 }
-/** 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).
- */
+const WORKER_SWAP_REDEEMABLE = {
+    version_newer: true,
+    env_factory_missing: true,
+    governed_unwired: true,
+    real_approval_damaged: false,
+    real_approval_forged: false,
+    constraint_chain_missing: false,
+};
+/** 判别符缺席(旧引擎裸抛)或词表不认得 ⇒ **false**,即维持修前的 TERMINAL 归属。fail-closed 的方向在
+ *  这里是「不宽容默认」:一个我们还没读过的新臂不该因为一个 `?? true` 被悄悄改判成「重试吧」。 */
+function checkpointRowRedeemableElsewhere(reason) {
+    return reason !== undefined && WORKER_SWAP_REDEEMABLE[reason] === true;
+}
 /** 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. */
@@ -2827,6 +2888,39 @@ export function isBillableSubmitPath(url) {
         SESSION_WAKE_RE.test(url) ||
         url.startsWith("/v1/approvals"));
 }
+/**
+ * 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 function isCredentialGatedRewrite(method, url) {
+    const m = method.toUpperCase();
+    if (m === "POST")
+        return url === "/v1/adoption" || url.startsWith("/v1/rules/cc-import/");
+    if (m === "DELETE")
+        return url === "/v1/rules";
+    return false;
+}
 // ⚠️ SSE 帧纪律(2026-07-12):center BFF 中继凭「data 无 type 字段」识别心跳帧并吞掉
 // (AgentEvent 是 closed oneof 全带 type,故可控)。**未来新增任何 SSE data 帧必须带 type 字段**,否则会被
 // 中继当心跳吞掉、永远到不了前端。heartbeat 帧(`event: heartbeat` + `data: {}`)是唯一豁免。

package/dist/http/wire-types.d.ts

@@ -287,7 +287,12 @@ export interface TaskRequestBody {
     /** MF-30 memory PAUSE (shell-host contract, option B per-request — clay 2026-06-27): `false` makes THIS run
      *  read-only over long-term memory (`TaskSpec.memory.writeScope:null` — the design/138 memory ENGINE materializes/
      *  reads but its harvest commits nothing). Absent/`true` ⇒ normal read+write. The shell's `/memory` pause carries
-     *  this per request (no stored per-session flag). Re-applies on resume (rides in the persisted body). */
+     *  this per request (no stored per-session flag). Re-applies on resume (rides in the persisted body).
+     *  ⚠️ **NOT the same axis as the deployment's `MEMORY_PERSISTENCE_CAPABLE:false`** (core 5.27.0 / [3612] F2):
+     *  that one declares the SESSION restricted — materialize/search/harvest serve the committed account and
+     *  unbacked disk divergence is refused (`restricted_divergence`). A `writeScope:null` PLANE keeps its ordinary
+     *  adopt-on-read semantics: a paused run still sees the user's hand-edits and git-pull drops, it just commits
+     *  nothing. Restriction is the session's DECLARATION, never the plane's structure. */
     memoryWrite?: boolean;
     /** 142-S4 projectId 线程化(design/142 §2):这个 run 归属的项目(center 登记簿键,generic lowercase
      *  UUID — core S1 `resolveProjectId` marker 或 S3 无仓 mint 的产物;客户端只透传,零铸造权威)。是「哪个

package/dist/main.js

@@ -189,6 +189,23 @@ async function main() {
     // 🔴 总开关在最前(codex round7 [high] 一):关 ⇒ 整条车道根本不装配(店/车道/帧键/两口一起消失)。
     const permissionRuleStores = config.permissionRulesEnabled && backend ? backend.permissionRule() : undefined;
     const ruleConsent = permissionRuleStores ? createRuleConsentLane(permissionRuleStores) : undefined;
+    // 🔴 A-010.10(验真后修):**旋钮开着却上不了场 ⇒ 打一行**,与同族旋钮 `STREAM_APPROVAL_ENABLED` 的
+    // `stream_approval_disabled` 一行(`boot/coordinators.ts`)对称。
+    // 此前这一格全程静默:`PERMISSION_RULES_ENABLED=true` 的部署若没有 backend、或 backend 没实装规则店,
+    // 车道就悄悄整条不装配 —— 运维看到的是「设了旋钮,可 `/v1/rules` 恒 501、卡上恒无候选」,而启动日志
+    // 里一个字都没有。判据逐字照那条先例:①**info 不是 warn**(这是合法部署形,不是配置错误);
+    // ②旋钮本来就没开的部署**不打**(显式关掉的人自己知道为什么,一行噪音零信息);
+    // ③原因写成机读位(哪一项不成立),不是一句人话。
+    // 与紧随其后的 `auditDormantPermissionRules` 是两件事、互不遮蔽:那条说的是「车道上了场,并且库里有
+    // 既有桶被默认 ON 唤醒」,这条说的是「车道压根没上场」——两者的合取恒假,永远只会打其中一行。
+    if (config.permissionRulesEnabled && permissionRuleStores === undefined) {
+        logger.info("permission_rules_lane_unavailable", {
+            knob: "PERMISSION_RULES_ENABLED",
+            reason: backend === undefined ? "no_backend" : "backend_has_no_rule_store",
+            backendKind: backend?.kind ?? null,
+            note: "PERMISSION_RULES_ENABLED is on but no permission-rule store is wired — /v1/rules/* answer 501, approval cards carry no rule suggestions, and respond's persistRule is refused with rule_lane_unavailable",
+        });
+    }
     // #203 §3(设计稿 v2 F4 残余):默认 ON 会把**既有**规则桶一并唤醒 —— 在启动日志里把它说出来。
     // 三条判据(店缺席 / 零桶 / 运维显式表过态 ⇒ 都不打行)与失败方向(数不出来只 warn,绝不拒启、
     // 也绝不编一个 0)逐字见 `boot/permission-rules-audit.ts`。
@@ -240,8 +257,15 @@ async function main() {
     // ⚠️ 刻意**不动** `toolResultStore` 本身:那个键的「present ⇔ durable 后端在场」语义还管着 E21 purge、
     // reaper 清扫、leader 装配与 /health 的接线自述(改它会让无 backend 的部署自述成 "shared(sql)" = 谎)。
     const runnerOffloadStore = toolResultStore ?? new InMemoryToolResultStore({ maxTotalChars: 64_000_000 });
+    // 交接件⑤:commit 尾注署名座**算一次**,主/sub 两只 Runner 经共享基座同源。
+    // [931]① clay 拍(core 1.300 BREAKING:缺省不署 Co-Authored-By,署名=产品身份资产归部署):
+    // branded 形态(local provider = Sema 产品线,scenarios brandIdentity 同判据)commit 尾注接 Sema 署名;
+    // 非 brand 部署维持 core 新缺省(不署)。判据逐字不变,变的只是它现在**也**喂给 subRunner ——
+    // 一个被委派的子代提交进的是同一个仓、代表同一个部署,它的 commit 少一行 trailer 没有理由。
+    const commitHands = config.configProvider === "local" ? { commitCoAuthor: "Sema <noreply@vivi-ai.com>" } : undefined;
     // design/158 A10:RunnerDeps 装配段搬到 src/boot/runner-deps.ts(逐字;runStore 晚绑改取值,见该文件头注)。
     const runnerDeps = createRunnerDeps({
+        hands: commitHands,
         config, logger, metrics, localRoot, promptSource: configCenter.promptSource, rosterStore, backgroundAgentStore, mailboxStore, usageWindowStore, brain,
         pricing, tracer, outcomeSink, elicitation, question, toolApproval, sessionStore, memoryEngine,
         memorySyncRunner, toolResultStore: runnerOffloadStore, sessionPolicyStore, runtimeCapsResolver, fileSnapshotStore,
@@ -274,11 +298,26 @@ async function main() {
     //     与 resource suspend 都会写),续跑时被路由到这只无手 Runner,core 在 **CAS 之前**抛
     //     `CheckpointError("checkpoint.unsupported_version", "checkpoint has a remote workspaceHandle but no
     //     RunnerDeps.executionEnvFactory is wired to rebuild the env")`(runtask.js:3704)。
-    //     本仓的分类表把该码归 **TERMINAL**(http/server.ts 的 CheckpointError 分支):run 行被 `setTerminal`
-    //     成 failed 并**释放** task_active,响应 409 携带该 errorCode —— 会话**不会**被占住到 TTL,运维重提该
-    //     任务即可。故这是**响亮的、有界的**升级窗代价,不是静默损坏;但它是行为面的升级注记,发车说明必须写。
-    //     ⚠️ 未覆盖登记:本形需要「真 durable 店 + 带 workspaceHandle 的旧 checkpoint」才能驱动,本批未建格
-    //     (属真双库/迁移测试面)—— 移交主会话裁定是否要做 checkpoint 感知的续跑选路或启动期预检。
+    //     🟢 **裁定已翻新(#209 件2,core 5.25.0 提货批 [3443]):本形现在归 RETRIABLE。**
+    //     沿革留档(免下次重开同一个问题):该码在 core 上共三个铸点 —— 本形 / 版本超上限 / org 治理行
+    //     落到无 `permissionRuleOrg` 接线的 worker —— 三形都是 PRE-CAS、卡一律留 pending,但**可恢复性
+    //     不同**;#205 当时 core **不给判别式**(同码、`detail` 同样缺席),两版下游修法各被一轮 codex
+    //     对抗复审验伪(①三形一律 retriable ②按 `gate.realApproval` 分流),按「源头修复禁下游旁路」全
+    //     回退、维持 TERMINAL,并把判别式列成上游请托([3434] 请托 1)。
+    //     请托已兑现:core 5.25.0 给三个铸点各带 `CheckpointError.detail.reason`,本形 = `env_factory_missing`,
+    //     d.ts 逐字「retryable on a factory-wired worker」。⇒ `http/server.ts` 的分类表现在**读词表**判
+    //     (`WORKER_SWAP_REDEEMABLE`,闭集、core 加词 tsc 红),不做形状推断;本形的行**重新 park
+    //     suspended**、那条仍 pending 的卡不再被孤儿化(#205 登记的孤儿代价至此销账)。
+    //     ⚠️ 与旧裁定的差别在**代价的方向**,如实说清:修前拿「释放 task_active」换「卡变死件(下一次
+    //     /decide → 404,只能等 `terminal_at_ms`)」;修后行停在 suspended 攥着会话锁,与它 park 时逐字
+    //     相同,直到运维给这条车道接上 `executionEnvFactory`(或把该场景路由回有手 Runner)。#205 当年
+    //     驳掉 blanket-retriable 的那条理由(`handsLanes.laneOf(spec)` 按场景判 ⇒ 换副本重投必同样失败)
+    //     仍然成立,但它说的是「换个副本再点一次没用」,而 core 的词说的是「接上 factory 的 worker 兑得掉」
+    //     —— 那是一次**运维动作**,与 `governed_unwired` 要求接 `permissionRuleOrg` 完全同族。
+    //     升级窗仍是**响亮的**(409 + 该 errorCode + `retriable: true`),不是静默损坏;发车说明照写。
+    //     论证与钉:`http/server.ts` 分类表下方那段 + `test/durable-resume-http.test.ts` 的「#209 件2」六格。
+    //     ⚠️ 未覆盖登记(原样保留):本形需要「真 durable 店 + 带 workspaceHandle 的旧 checkpoint」才能
+    //     驱动,真店端到端仍属真双库/迁移测试面,未建。
     const handslessRunner = new Runner(withoutExecutionEnv(runnerDeps));
     // codex R10: TRUE ⇒ the Runner just froze a PRIVATE tier-expanded catalog copy (core runtask.js constructor,
     // dist-read) — in-place model-plane mutation no longer reaches it, so refresh-time plane changes must be
@@ -404,6 +443,7 @@ async function main() {
         // 基座只有一份)。差异键在展开后显式列出,每个都有为何不同的理由(见 boot/runner-deps.ts 头注)。
         ...createSharedRunnerDeps({
             config,
+            hands: commitHands, // 交接件⑤:与主 runner 同一个值(基座保证同源)
             brain,
             pricing,
             tracer,
@@ -758,7 +798,7 @@ async function main() {
         config, logger, metrics, localRoot, backend, subRunner, runStore, checkpointStore,
         rateLimiter, costQuota, toolResultStore, fileSnapshotStore, taskAttachmentStore, imageBakes, worktreeReap,
         workflowNotifyGate, workflowRecoverOpts, workflowJournalStore, sqlWorkflowRunStore, workflowNotifyJournal, rosterStore,
-        backgroundAgentStore, mailboxStore, toolApproval,
+        backgroundAgentStore, mailboxStore, toolApproval, permissionRuleStores,
         getRunDenySweep: () => runDenySweep,
     });
     // Optional OTLP/HTTP metrics export (1.37). Periodically pushes the registry to an OTel collector;

package/dist/observability/fail-open.d.ts

@@ -57,6 +57,10 @@ export declare const FAIL_OPEN_TAGS: {
         readonly cls: "F";
         readonly note: "fleet bus 某订阅回调抛错 ⇒ 该回调本帧作废,其余订阅方与发布方不受影响。隔离是承重的:扇出同步,修前异常会传回发布方 put/update 投影点,core 持久化 catch{} 且不推进 storeRev ⇒ durable 行冻在 running 而 notify 已 ack(#183 复审 R3 HIGH)。丢的只是一个消费方的一帧渲染,故 F 类;但必须留痕——静默吞掉等于订阅方病灶永不显形。";
     };
+    readonly "server.run-store.stale-claim-quarantine-unremoved": {
+        readonly cls: "F";
+        readonly note: "#213 陈旧 claim 接管:claim 已 rename 进 tmp/ 隔离名(接管本体已完成、正确性不受影响),但隔离件 rmSync 失败留在 tmp。放行的最坏后果 = tmp 里多一个死文件(不在 activeDir,hydrate 永不把它当 claim 复活);故 F 类。必须留痕:反复删不掉 = tmp 权限/fs 病灶,静默吞掉会让 tmp 无声膨胀。";
+    };
 };
 /** 词表键推导的闭集类型——未登记的 tag 传不进 {@link recordFailOpen}(编译期拒)。 */
 export type FailOpenTag = keyof typeof FAIL_OPEN_TAGS;

package/dist/observability/fail-open.js

@@ -80,6 +80,10 @@ export const FAIL_OPEN_TAGS = {
         cls: "F",
         note: "fleet bus 某订阅回调抛错 ⇒ 该回调本帧作废,其余订阅方与发布方不受影响。隔离是承重的:扇出同步,修前异常会传回发布方 put/update 投影点,core 持久化 catch{} 且不推进 storeRev ⇒ durable 行冻在 running 而 notify 已 ack(#183 复审 R3 HIGH)。丢的只是一个消费方的一帧渲染,故 F 类;但必须留痕——静默吞掉等于订阅方病灶永不显形。",
     },
+    "server.run-store.stale-claim-quarantine-unremoved": {
+        cls: "F",
+        note: "#213 陈旧 claim 接管:claim 已 rename 进 tmp/ 隔离名(接管本体已完成、正确性不受影响),但隔离件 rmSync 失败留在 tmp。放行的最坏后果 = tmp 里多一个死文件(不在 activeDir,hydrate 永不把它当 claim 复活);故 F 类。必须留痕:反复删不掉 = tmp 权限/fs 病灶,静默吞掉会让 tmp 无声膨胀。",
+    },
 };
 /**
  * 断流丢帧该记哪个 tag —— **按帧型分类**,纯函数(与写流的那条闭包解耦,才单测得动)。

package/dist/plugins/adoption-log-sql.d.ts

@@ -117,6 +117,31 @@ export declare function ensurePgAdoptionLogSchema(q: (text: string, params?: unk
  * (PG 那条腿本来就走 hash 出来的 int4 对象键,这里只是把 MySQL 腿补齐到同一姿势。)
  */
 export declare function adoptionLockName(fromPrincipal: string): string;
+/**
+ * 把弧锁名限定到**一个库**的键空间(A-010.13,验真后修)。
+ *
+ * 🔴 病:两条腿的锁键空间**不等价**。MySQL/TiDB 的 `GET_LOCK` 名字是**服务器实例全局**的
+ * (`performance_schema.metadata_locks` 里就是一个进程级命名空间,与你连的是哪个 schema 无关);
+ * PG 的 advisory lock 是**每数据库**的(`pg_locks` 的 database 列参与身份)。而锁名此前只 hash 了
+ * `fromPrincipal`、前缀写死 `sema_adoption:` —— 于是同一台 MySQL 上并存的两套部署
+ * (`aiagent_prod` / `aiagent_staging`,同一个源身份)会**互相抢同一把锁**:一边正在跑弧,另一边
+ * 取不到锁、按「在飞」回一份 `stalled` 回执 —— 一个与它自己的库状态完全对不上的答复。切到 PG 同样
+ * 两套部署却各跑各的。同一份代码、同一份配置,两个后端上语义不同 = 方言不等价。
+ *
+ * 🔴 姿势:限定符 = **当前数据库名**(MySQL `DATABASE()` / PG `current_database()`),与 principal
+ * 一起进 hash 原像。于是 MySQL 腿被收窄到与 PG 腿同一个键空间语义(每库一把),而不是把 PG 放宽到
+ * 实例全局(放宽的那个方向会让**同库**的两副本以为各自持锁,那是真丢互斥,方向错得多)。
+ *
+ * 🔴 为什么仍然 hash 而不是 `${db}/${name}` 直接拼:`GET_LOCK` 的名字上限是 **64 字符**,而库名没有
+ * 本仓能保证的上限。拼接形会让一个长库名的部署在**取锁那一步**才失败,而那时意图行已经落库 ——
+ * 每一次重发、每一次 boot 续跑都确定性地再撞一次同一堵墙(与 `adoptionLockName` 自己头注里那条
+ * codex R3-F3 是同一个病)。hash 后定长 46 字符,与库名长度无关。
+ * 分隔符取 **NUL**(源码里写成转义 `\u0000`,不落裸控制字节 —— 那会让 grep 把整个文件当二进制):
+ * 库名可以含 `/`、空格这类字符(MySQL 反引号标识符 / PG 双引号标识符都允许),拿它们当分隔符时
+ * `(db="a", name="b/c")` 与 `(db="a/b", name="c")` 会铸出**同一个原像** —— 弱分隔符拼接的经典撞形。
+ * NUL 在两种引擎的标识符里都不合法,所以它是真的不可能出现在任何一段里。
+ */
+export declare function qualifyAdoptionLockName(database: string, name: string): string;
 /**
  * 收编日志店(单文件双方言,SqlDriver 形——checkpoint-store / approval-ask-store 同款)。
  *
@@ -173,12 +198,27 @@ export declare class SqlAdoptionLogStore implements AdoptionLogStore {
     finalizeAdopted(adoptionId: string, expectPhase: number, reportJson: string, nowMs: number, exec?: SqlExec): Promise<boolean>;
     /** 目的地冲突 ⇒ rejected 终态(源/目的地两侧字节零变更;phase 停在 INTENT)。 */
     finalizeRejected(adoptionId: string, code: AdoptionRejectCode, detail: string, nowMs: number, exec?: SqlExec): Promise<boolean>;
+    /**
+     * 本连接所在**数据库**的名字 = 弧锁的键空间限定符(A-010.13,理由见 {@link qualifyAdoptionLockName})。
+     *
+     * 在**交出来的那条连接**上问(不向池要第二条 —— 弧全程单连接,见 `AdoptionLogStore.getById` 的注),
+     * 结果缓存在店上:库名在一条驱动的生命周期里不会变,而每次取锁多打一个往返是白付的。
+     *
+     * 读不出来 ⇒ **响亮抛**,不回落到未限定的旧名字:那正是本条要消灭的形,静默回落等于「修了个寂寞」
+     * 且只在多部署共库的那台机器上才发作(安全轴禁静默 fail-open 的同族判据)。
+     */
+    private lockKeyspace?;
+    private resolveLockKeyspace;
     /**
      * 收编弧的 advisory 锁(183 I1 的 form b 形:「与任何活写互斥」在 SQL 侧 = 一次只有一个副本在推这条弧)。
      *
      * **非阻塞取 + 有界轮询**(tidb-pool 的 `acquireEnsureSchemaLock` 同款判据:阻塞式 GET_LOCK 会把并发
      * 调用方全部park 在 TiDB 的悲观锁行上,既耗它的重试预算又饿死应用自己的 FOR UPDATE 路)。取不到 ⇒
      * 返回 `undefined`,调用方按「在飞」应答 —— **不假装成功,也不无限等**。
+     *
+     * 🔴 入参 `name` 是**逻辑**锁名(`adoptionLockName(fromPrincipal)`);真正发给引擎的是它被
+     * {@link qualifyAdoptionLockName} 限定到本库之后的形(A-010.13:两方言键空间不等价)。限定发生在
+     * **这里**而不是调用方,因为「键空间是每库还是每实例」是**存储层**的知识,协议层(runner)不该知道。
      */
     withLock<T>(name: string, fn: (conn: SqlTxConn) => Promise<T>, attempts?: number, sleepMs?: number): Promise<T | undefined>;
 }

package/dist/plugins/adoption-log-sql.js

@@ -92,6 +92,33 @@ function pgLockObjectKey(name) {
 export function adoptionLockName(fromPrincipal) {
     return `sema_adoption:${createHash("sha256").update(fromPrincipal).digest("hex").slice(0, 32)}`;
 }
+/**
+ * 把弧锁名限定到**一个库**的键空间(A-010.13,验真后修)。
+ *
+ * 🔴 病:两条腿的锁键空间**不等价**。MySQL/TiDB 的 `GET_LOCK` 名字是**服务器实例全局**的
+ * (`performance_schema.metadata_locks` 里就是一个进程级命名空间,与你连的是哪个 schema 无关);
+ * PG 的 advisory lock 是**每数据库**的(`pg_locks` 的 database 列参与身份)。而锁名此前只 hash 了
+ * `fromPrincipal`、前缀写死 `sema_adoption:` —— 于是同一台 MySQL 上并存的两套部署
+ * (`aiagent_prod` / `aiagent_staging`,同一个源身份)会**互相抢同一把锁**:一边正在跑弧,另一边
+ * 取不到锁、按「在飞」回一份 `stalled` 回执 —— 一个与它自己的库状态完全对不上的答复。切到 PG 同样
+ * 两套部署却各跑各的。同一份代码、同一份配置,两个后端上语义不同 = 方言不等价。
+ *
+ * 🔴 姿势:限定符 = **当前数据库名**(MySQL `DATABASE()` / PG `current_database()`),与 principal
+ * 一起进 hash 原像。于是 MySQL 腿被收窄到与 PG 腿同一个键空间语义(每库一把),而不是把 PG 放宽到
+ * 实例全局(放宽的那个方向会让**同库**的两副本以为各自持锁,那是真丢互斥,方向错得多)。
+ *
+ * 🔴 为什么仍然 hash 而不是 `${db}/${name}` 直接拼:`GET_LOCK` 的名字上限是 **64 字符**,而库名没有
+ * 本仓能保证的上限。拼接形会让一个长库名的部署在**取锁那一步**才失败,而那时意图行已经落库 ——
+ * 每一次重发、每一次 boot 续跑都确定性地再撞一次同一堵墙(与 `adoptionLockName` 自己头注里那条
+ * codex R3-F3 是同一个病)。hash 后定长 46 字符,与库名长度无关。
+ * 分隔符取 **NUL**(源码里写成转义 `\u0000`,不落裸控制字节 —— 那会让 grep 把整个文件当二进制):
+ * 库名可以含 `/`、空格这类字符(MySQL 反引号标识符 / PG 双引号标识符都允许),拿它们当分隔符时
+ * `(db="a", name="b/c")` 与 `(db="a/b", name="c")` 会铸出**同一个原像** —— 弱分隔符拼接的经典撞形。
+ * NUL 在两种引擎的标识符里都不合法,所以它是真的不可能出现在任何一段里。
+ */
+export function qualifyAdoptionLockName(database, name) {
+    return `sema_adoption:${createHash("sha256").update(`${database}\u0000${name}`, "utf8").digest("hex").slice(0, 32)}`;
+}
 /**
  * 收编日志店(单文件双方言,SqlDriver 形——checkpoint-store / approval-ask-store 同款)。
  *
@@ -221,19 +248,59 @@ export class SqlAdoptionLogStore {
         const res = await exec.query(this.q(`UPDATE ${ADOPTION_LOG_TABLE} SET state = 'rejected', reject_code = ?, reject_detail = ?, updated_at_ms = ? WHERE adoption_id = ? AND state = 'in_flight'`, `UPDATE ${ADOPTION_LOG_TABLE} SET state = 'rejected', reject_code = $1, reject_detail = $2, updated_at_ms = $3 WHERE adoption_id = $4 AND state = 'in_flight'`), [code, detail, nowMs, adoptionId]);
         return res.affected === 1;
     }
+    /**
+     * 本连接所在**数据库**的名字 = 弧锁的键空间限定符(A-010.13,理由见 {@link qualifyAdoptionLockName})。
+     *
+     * 在**交出来的那条连接**上问(不向池要第二条 —— 弧全程单连接,见 `AdoptionLogStore.getById` 的注),
+     * 结果缓存在店上:库名在一条驱动的生命周期里不会变,而每次取锁多打一个往返是白付的。
+     *
+     * 读不出来 ⇒ **响亮抛**,不回落到未限定的旧名字:那正是本条要消灭的形,静默回落等于「修了个寂寞」
+     * 且只在多部署共库的那台机器上才发作(安全轴禁静默 fail-open 的同族判据)。
+     */
+    lockKeyspace;
+    resolveLockKeyspace(conn) {
+        // 🔴 缓存的是**这一次尝试**,而失败的那一次必须从缓存里消失(codex 对抗复审 R1 [medium],验真后修)。
+        // 病:`??=` 把 promise 本身钉住,于是**一次瞬时**的 `SELECT DATABASE()` 失败(连接抖动、库短暂不可
+        // 达)会被永久缓存 —— 此后每一条弧都复用那个已拒的 promise、连库都不再问一次。而意图行是在取锁
+        // **之前**就落库的,所以首条弧永远停在 in_flight、每次 boot 续跑再撞同一堵墙,整台副本的收编面
+        // 直到重启为止都是死的。一次抖动升级成一次停机,方向完全反了。
+        // 修:只有**解析成功**的读数留在缓存里;拒绝时清掉,下一次真的重问。
+        const attempt = (this.lockKeyspace ??= (async () => {
+            const res = await conn.query(this.q("SELECT DATABASE() AS db", "SELECT current_database() AS db"));
+            const db = res.rows[0]?.db;
+            if (typeof db !== "string" || db === "") {
+                throw new Error("adoption: could not resolve the current database name, so the arc lock's key space cannot be qualified — refusing to take an UNQUALIFIED lock (on MySQL, GET_LOCK names are server-instance global: an unqualified name would collide with any other deployment sharing this server)");
+            }
+            return db;
+        })());
+        // 清缓存要**认准这一次**(`=== attempt`):否则一次迟到的失败会把别人刚缓存好的成功读数抹掉。
+        return attempt.catch((err) => {
+            if (this.lockKeyspace === attempt)
+                this.lockKeyspace = undefined;
+            throw err;
+        });
+    }
     /**
      * 收编弧的 advisory 锁(183 I1 的 form b 形:「与任何活写互斥」在 SQL 侧 = 一次只有一个副本在推这条弧)。
      *
      * **非阻塞取 + 有界轮询**(tidb-pool 的 `acquireEnsureSchemaLock` 同款判据:阻塞式 GET_LOCK 会把并发
      * 调用方全部park 在 TiDB 的悲观锁行上,既耗它的重试预算又饿死应用自己的 FOR UPDATE 路)。取不到 ⇒
      * 返回 `undefined`,调用方按「在飞」应答 —— **不假装成功,也不无限等**。
+     *
+     * 🔴 入参 `name` 是**逻辑**锁名(`adoptionLockName(fromPrincipal)`);真正发给引擎的是它被
+     * {@link qualifyAdoptionLockName} 限定到本库之后的形(A-010.13:两方言键空间不等价)。限定发生在
+     * **这里**而不是调用方,因为「键空间是每库还是每实例」是**存储层**的知识,协议层(runner)不该知道。
      */
     async withLock(name, fn, attempts = 20, sleepMs = 100) {
         const conn = await this.db.connect();
         let held = false;
+        // 🔴 在 try **之外**声明:释放腿(finally)必须用**取锁时用过的那一个**名字。第一版把它 const 在
+        // try 里,于是 finally 只能回头用未限定的 `name` —— 取的是 A、放的是 B,锁会一直持到连接回收。
+        let lockName = "";
         try {
+            lockName = qualifyAdoptionLockName(await this.resolveLockKeyspace(conn), name);
             for (let i = 0; i < attempts && !held; i += 1) {
-                const res = await conn.query(this.q("SELECT GET_LOCK(?, 0) AS got", "SELECT pg_try_advisory_lock($1, $2) AS got"), this.db.dialect === "tidb" ? [name] : [PG_ADOPTION_LOCK_CLASS, pgLockObjectKey(name)]);
+                const res = await conn.query(this.q("SELECT GET_LOCK(?, 0) AS got", "SELECT pg_try_advisory_lock($1, $2) AS got"), this.db.dialect === "tidb" ? [lockName] : [PG_ADOPTION_LOCK_CLASS, pgLockObjectKey(lockName)]);
                 const got = res.rows[0]?.got;
                 held = got === 1 || got === true || got === "1";
                 if (!held)
@@ -248,7 +315,7 @@ export class SqlAdoptionLogStore {
         finally {
             if (held) {
                 try {
-                    await conn.query(this.q("SELECT RELEASE_LOCK(?) AS released", "SELECT pg_advisory_unlock($1, $2) AS released"), this.db.dialect === "tidb" ? [name] : [PG_ADOPTION_LOCK_CLASS, pgLockObjectKey(name)]);
+                    await conn.query(this.q("SELECT RELEASE_LOCK(?) AS released", "SELECT pg_advisory_unlock($1, $2) AS released"), this.db.dialect === "tidb" ? [lockName] : [PG_ADOPTION_LOCK_CLASS, pgLockObjectKey(lockName)]);
                 }
                 catch (releaseErr) {
                     // 锁在连接关闭时会自动释放,所以释放失败不该盖掉真正的结果 —— 但同样不空吞:

package/dist/plugins/approval-ask-store-sql.d.ts

@@ -308,7 +308,8 @@ export declare const APPROVAL_BATCH_TABLE = "approval_batch";
  *     `task_run.task_id VARCHAR(64)` 同宽(此前 255 是本家族独有的偏离,无依据)。
  *   · `session_id` → 64:提交入口硬拒 >64(`http/server.ts` "sessionId must be at most 64 characters"),
  *     与 `session_meta`/`task_run` 同宽。
- *   · `owner` → 190:`assertPrincipalShape` 的 `PRINCIPAL_MAX_LENGTH = 190`(`security.ts:350`)硬拒更长者;
+ *   · `owner` → 190:`assertPrincipalShape` 的 `PRINCIPAL_MAX_LENGTH = 190`(`security.ts` 的同名导出常量,
+ *     刻意不钉行号 —— 旧注写的 `security.ts:350` 已随该文件编辑漂走)硬拒更长者;
  *     全仓每一根 owner/scope 轴都是 190,此前 255 同样是无依据偏离。
  *   · `gate_token` → 120:它抄的是 checkpoint 的 token(core `mintCheckpointToken` = 16 字节 hex = 32 字符),
  *     取与**被抄那一列** `checkpoint.token VARCHAR(120)` 同宽 —— 同一个值在两张表上宽度必须一致,

package/dist/plugins/approval-ask-store-sql.js

@@ -82,7 +82,8 @@ export const APPROVAL_BATCH_TABLE = "approval_batch";
  *     `task_run.task_id VARCHAR(64)` 同宽(此前 255 是本家族独有的偏离,无依据)。
  *   · `session_id` → 64:提交入口硬拒 >64(`http/server.ts` "sessionId must be at most 64 characters"),
  *     与 `session_meta`/`task_run` 同宽。
- *   · `owner` → 190:`assertPrincipalShape` 的 `PRINCIPAL_MAX_LENGTH = 190`(`security.ts:350`)硬拒更长者;
+ *   · `owner` → 190:`assertPrincipalShape` 的 `PRINCIPAL_MAX_LENGTH = 190`(`security.ts` 的同名导出常量,
+ *     刻意不钉行号 —— 旧注写的 `security.ts:350` 已随该文件编辑漂走)硬拒更长者;
  *     全仓每一根 owner/scope 轴都是 190,此前 255 同样是无依据偏离。
  *   · `gate_token` → 120:它抄的是 checkpoint 的 token(core `mintCheckpointToken` = 16 字节 hex = 32 字符),
  *     取与**被抄那一列** `checkpoint.token VARCHAR(120)` 同宽 —— 同一个值在两张表上宽度必须一致,