@sema-agent/server 7.5.0 → 7.7.0

package/dist/leader/diffout.js

@@ -1,6 +1,18 @@
-const DEFAULT_MAX_DIFF_BYTES = 5 * 1024 * 1024;
+/**
+ * 一次 diff 的字节帽(pull 腿与 push/上行腿**共用同一个数**)。
+ *
+ * 🔴 exported 是判据的一部分(2026-08-08,#176 二轮扫描 finding):`diffup.ts` 原先另抄了一份同值常量,
+ * 而它**本就已经** `import { safeRev } from "./diffout.js"` —— 依赖边在,共享零成本。两份手抄的后果不是
+ * 「多写一行」,是**单边改值后上行/pull 两腿对同一个 diff 的过/拒判定分家**:同一份补丁在一条腿上过、
+ * 另一条腿上被截断,而两处都「按自己的常量」正确工作,没有任何一处会报错。
+ * (同族先例:`checkpoint-store-sql.ts` 的 `export const TERMINAL_GRACE_MS`。)
+ */
+export const DEFAULT_MAX_DIFF_BYTES = 5 * 1024 * 1024;
 const DEFAULT_READ_TIMEOUT_MS = 30_000;
-/** A safe git rev token: sha, branch/tag name, or `A..B`. No shell metacharacters, no leading dash. */
+/** A safe git rev token: sha, branch/tag name, or `A..B`. No shell metacharacters, no leading dash.
+ *  🔗 近亲判据:`leader/planner.ts` 的 branch 校验用同一套字符类 + 同一个 200 上限 + 同样拒前导 `-`,
+ *  只在 `..` 上有意分家(这里要放行 `A..B` 区间形,那边全拒)。差异与候裁说明写在 planner 那处
+ *  (#176 二轮扫描 finding)——单边加字符类成员时,请两处一起看。 */
 const SAFE_REV = /^[A-Za-z0-9._/-]{1,200}$/;
 export function safeRev(rev) {
     return SAFE_REV.test(rev) && !rev.startsWith("-") && !rev.includes("..--");

package/dist/leader/diffup.js

@@ -14,9 +14,10 @@
  * A worker that skips the upload surfaces as `{ok:false}` → merge quarantines it (honest failure, no hang).
  * pullDiff stays as the compat path for static (leader-owned) envs — M2 降兼容.
  */
-import { safeRev } from "./diffout.js";
+// 字节帽与 `safeRev` 同源取自 pull 腿(理由见 diffout.ts 的 DEFAULT_MAX_DIFF_BYTES 顶注:同值双抄一旦
+// 单边改值,上行/pull 两腿对同一个 diff 的过/拒判定就分家,且两边都「按自己的常量」静默正确)。
+import { safeRev, DEFAULT_MAX_DIFF_BYTES } from "./diffout.js";
 import { OBJECT_STORE_IO_TIMEOUT_MS } from "../plugins/blob-backend.js";
-const DEFAULT_MAX_DIFF_BYTES = 5 * 1024 * 1024;
 /** The staged upload script. `repoDir`/`workDir` are deployment config; `baseSha` is interpolated into a
  *  shell line, so it is re-validated HERE (fail-closed) — callers should already have applied diffout's
  *  safeRev rules, but this function is the last line before the shell. The patch is written OUTSIDE the repo

package/dist/leader/planner.js

@@ -91,6 +91,13 @@ export function validateSubtasks(arr, opts = {}) {
         const branch = typeof e.branch === "string" && e.branch.trim() ? e.branch.trim() : `worker/${workerId}`;
         // Reject a leading "-" (would be parsed as an option by `git checkout -b <branch>`), ".." (ref escape), and
         // an over-long ref (git rejects it anyway; cap keeps the value tidy). The char set is shell-safe.
+        //
+        // 🔗 近亲判据(2026-08-08,#176 二轮扫描 finding):`leader/diffout.ts` 的 `safeRev` 用**同一套**字符
+        // 类 `[A-Za-z0-9._/-]`、**同一个** 200 长度上限、**同样**拒前导 `-`。唯一的真差异在 `..`:safeRev 只拒
+        // `..--`(rev 要支持 `A..B` 区间形),这里全拒 `..`(branch **名**里 `..` 无合法用途,git 自己也拒)
+        // —— 是**有意收紧**,不是抄漏。两处此前零互指、无共享基元、无跨处钉;单边加一个字符类成员时另一边
+        // 不会有任何提示。是否抽一个共享基元(比如 `refToken(s, { allowRange })`)属结构面决定,候裁;本批
+        // 只把「近亲关系 + 差异所在」两侧成文。
         if (branch.length > 200 || !/^[A-Za-z0-9._/-]+$/.test(branch) || branch.startsWith("-") || branch.includes("..")) {
             throw new Error(`sub-task ${workerId}: invalid branch`);
         }

package/dist/main.js

@@ -1,7 +1,7 @@
 import { readFileSync } from "node:fs";
 import { homedir } from "node:os";
 import { join } from "node:path";
-import { Runner, TtlSessionStore, uuidv7, defaultTaskRegistry, combinePolicies, createAllowDenyPolicy, workflowsCapability, createWebFetchSummarizer, resolveTaskModel as coreResolveTaskModel, probeSearchBackend, describeStaticWiring } from "@sema-agent/core";
+import { Runner, InMemoryToolResultStore, TtlSessionStore, uuidv7, defaultTaskRegistry, createAllowDenyPolicy, workflowsCapability, createWebFetchSummarizer, resolveTaskModel as coreResolveTaskModel, probeSearchBackend, describeStaticWiring } from "@sema-agent/core";
 import { createSessionTitler } from "./session-titler.js";
 import { posIntEnv } from "./session-watch.js";
 import { selectEnvironmentTool } from "./capabilities/select-environment-tool.js";
@@ -14,10 +14,11 @@ import { ensureChildSessionDurableWithPromotion } from "./plugins/session-store.
 import { ForkRoutingSessionStore } from "./plugins/fork-routing-session-store.js";
 import { webSearchConfigFromEnv, createWebSearchBackend, setWebSearchBadPayloadObserver, shouldProbeWebSearchOnBoot } from "./plugins/web-search.js";
 import { createAuthorizer, encodeCheckpointScope } from "./security.js";
-import { assertGateIntentServiceable, createDurableAskPolicy, hasOperatorGateIntent } from "./approval.js";
+import { assertGateIntentServiceable, hasOperatorGateIntent } from "./approval.js";
 import { loadSkills } from "./capabilities/skills.js";
 import { GiteaClient } from "./capabilities/repo-tools.js";
 import { buildScenarios, builtinScenarioDetails } from "./capabilities/scenarios.js";
+import { createHandsLaneRegistry, pickHandsRunner, withoutExecutionEnv } from "./capabilities/hands-lane.js";
 import { createLogger } from "./observability/logger.js";
 import { createToolTracer, createPermissionDeniedMeter } from "./observability/tool-trace.js";
 import { createRegistryJwtVerifier } from "./auth-bridge.js";
@@ -38,7 +39,8 @@ import { createHookLlm } from "./hooks/hook-llm.js";
 import { startFleetClientFromEnv } from "./fleet-client.js";
 import { reclaimOrphansAtBoot } from "./boot-reclaim.js";
 import { createConfigCenterRuntime } from "./boot/config-center.js";
-import { createDurableQuestionGate, createResolveSpec } from "./boot/resolve-spec.js";
+import { createResolveSpec } from "./boot/resolve-spec.js";
+import { createParkedReviveInheritedGate } from "./boot/parked-revive-gate.js";
 import { startReapers } from "./boot/reapers.js";
 import { openStores } from "./boot/stores.js";
 import { createBudgetAndTracing } from "./boot/budget-tracing.js";
@@ -192,16 +194,54 @@ async function main() {
     const { principalCaps, centerRuntimeCapsResolver, runtimeCapsResolver } = createRuntimeCaps({ config, logger });
     // design/170 件A(#148 件3③):org 记忆准入装配(目录源三态选择+C12 能力探测,坏配置在此拒启动)。
     const orgMemoryAdmission = createOrgMemoryAdmissionWiring({ config, logger, metrics });
+    // 🔴 codex 复审(#196 finding-2b):`toolResultStore` 在**无 backend** 形下是 undefined,而 core 的
+    // Runner 构造函数会在缺席时**每只各自私建**一份 `RunnerSharedToolResultStore`(runtask.js
+    // `if (!this.deps.toolResultStore)`)。本部署有多只 Runner(主 / subRunner / hookAgent / #196 的两只无手
+    // 孪生),私建 ⇒ 每只一个独立店 ⇒ A 车道 offload 出去的 `ReadToolResult` 引用在 B 车道解引用不到
+    // (fork 子任务跨 runner 读父的 offload 是既有可达形,#196 的车道分家又多了一条)。这里显式铸**一份**
+    // 共享兜底(参数与 core 私建那只逐字相同:`RunnerSharedToolResultStore` 是 `InMemoryToolResultStore`
+    // 的空子类,cap 64M chars),只喂 Runner 侧。
+    // ⚠️ 刻意**不动** `toolResultStore` 本身:那个键的「present ⇔ durable 后端在场」语义还管着 E21 purge、
+    // reaper 清扫、leader 装配与 /health 的接线自述(改它会让无 backend 的部署自述成 "shared(sql)" = 谎)。
+    const runnerOffloadStore = toolResultStore ?? new InMemoryToolResultStore({ maxTotalChars: 64_000_000 });
     // design/158 A10:RunnerDeps 装配段搬到 src/boot/runner-deps.ts(逐字;runStore 晚绑改取值,见该文件头注)。
     const runnerDeps = createRunnerDeps({
         config, logger, metrics, localRoot, promptSource: configCenter.promptSource, rosterStore, backgroundAgentStore, mailboxStore, usageWindowStore, brain,
         pricing, tracer, outcomeSink, elicitation, question, toolApproval, sessionStore, memoryEngine,
-        memorySyncRunner, toolResultStore, sessionPolicyStore, runtimeCapsResolver, fileSnapshotStore,
+        memorySyncRunner, toolResultStore: runnerOffloadStore, sessionPolicyStore, runtimeCapsResolver, fileSnapshotStore,
         executionEnvFactory, lspManager, fleetBus, deploymentHooks, workflowRunStore, workflowJournalStore,
         workflowAgentRegistry, workflowNotifyGate, workflowCompletionInbox, deliverWorkflowCompletion, orgMemoryAdmission,
         getRunStore: () => runStore,
     });
     const runner = new Runner(runnerDeps);
+    // #196:`runner` 的无手孪生 —— 同 deps 同实例(sessionStore/toolResultStore/checkpointStore… 全共享,
+    // `Runner.sessions` 就是传进去的那只 store,两只 Runner 不会各持一份会话缓存),唯独不挂
+    // `executionEnvFactory`。core 的 `handsEnabled = ownedEnv || deps.executionEnv` 是 **per-Runner** 合同,
+    // 单 runner 服务全场景时结构上无法逐场景兑现 —— 这只孪生就是兑现它的那一半(设计小票 §2a)。
+    // 声明 hands:"none" 的场景(scan / code-review 两腿 / team / center overlay)在 HTTP 执行点被路由到这里。
+    //
+    // 🔴 两条**已知边界**(codex 复审 2026-08-09 两轮提出,逐条亲验 core dist 后如实记账;两条的部署条件
+    //     互不相同 —— 不要把它们并成一句)。
+    //
+    //  ① 会话锁是 **per-Runner** 的(core runtask.js 的 `sessionLocks` Map,每只 Runner 一份)。
+    //     **条件:无 store backend 的部署形**。有 runStore 时同会话并发提交被服务端的 run 认领挡成 409
+    //     (routes/tasks.ts:317 / routes/runs.ts:335 的 `createRun` 认领),两车道并发结构上不可达;无
+    //     backend 的部署没有那道认领,同一 sessionId 上「一条 full + 一条 none」并发就失去了修前由单
+    //     Runner 提供的串行化。同类缺口本就存在(subRunner 经 ForkRoutingSessionStore 也会碰宿主会话),
+    //     本件让它多一条可达路径。补偿:配任一 backend(含 `DB_BACKEND=local`)即恢复认领。
+    //
+    //  ② 升级窗的旧 checkpoint。**条件恰恰相反:必须有 checkpointStore**(= 有 backend + DURABLE_APPROVAL),
+    //     且部署在 REMOTE_EXEC 车道上 —— 修前建立的 hands=none 场景 durable checkpoint 会带 workspaceHandle
+    //     (可挂起 env 的快照形,以及**非**可挂起远端 env 的 `restoreMode:"park_only"` 形,两者都算;审批 park
+    //     与 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 感知的续跑选路或启动期预检。
+    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
     // DEFERRED to restart (see appliedPlaneEff / applyEffective deferModelPlane). Captured HERE, at the same
@@ -320,7 +360,7 @@ async function main() {
     // (子会话住私有 TTL 店,park 前整树拷进 host durable 店——只查不迁的 1.263 形在拆店生产形下恒
     // 否决 park,cli 真机 14ms~2s expired 即此)。
     const subRunnerSessions = new ForkRoutingSessionStore(sessionStore, new TtlSessionStore({ defaultTtlDays: 1 / 24 }));
-    const subRunner = new Runner({
+    const subRunnerDeps = {
         // [1543]§三族A 结构性根治(design/158 冲刺尾件):与主 runnerDeps 重复的 ~15 键统一走
         // createSharedRunnerDeps 展开——「双点挂载」从人工纪律变结构性保证(新共享键漏配其一=不可能,
         // 基座只有一份)。差异键在展开后显式列出,每个都有为何不同的理由(见 boot/runner-deps.ts 头注)。
@@ -336,7 +376,7 @@ async function main() {
             mailboxStore,
             rosterStore,
             deploymentHooks,
-            toolResultStore,
+            toolResultStore: runnerOffloadStore,
             sessionPolicyStore,
             usageWindowStore,
             orgMemoryAdmission,
@@ -358,7 +398,13 @@ async function main() {
         // TaskStop on parked 走 expire CAS 仲裁(1.389 F-1);/decide 可赎回。行为钉 =
         // test/subagent-park-wiring.test.ts(SOURCE PIN + park 全链 + 旧形反向控制)。
         checkpointStore: checkpointStore ? checkpointStore : undefined,
-    });
+    };
+    const subRunner = new Runner(subRunnerDeps);
+    // #196:`subRunner` 的无手孪生(同一份 deps 字面量摘掉 executionEnvFactory —— 差异面只有这一处,
+    // 结构上不可能漂移)。council 的 lens/arbiter、team 的成员/synthesizer 走它:那些子任务的人格声明
+    // 里一件工具都没有,却在修前照拿全量可写手(设计小票 §1 里最意外的一支)。
+    // ⚠️ 与主 subRunner 共享 `subRunnerSessions` 与 `checkpointStore` 同实例 —— park/fork 的行是同一批。
+    const handslessSubRunner = new Runner(withoutExecutionEnv(subRunnerDeps));
     // S6: resolve identity + owned session from the authenticated channel (never the body).
     const authorize = createAuthorizer(config, sessionStore);
     // S1/S2: durable async run registry + replayable event log (TiDB-backed).
@@ -597,7 +643,7 @@ async function main() {
     // design/158 S4:标注 `: ScenarioDeps` —— 无标注的字面量连自己的键名都不校验(打错/多写一个键
     // 只是多一个没人读的属性,编译期无声),这是 1.304 落错家那一族的另一半土壤。
     const scenarioDeps = {
-        runner, subRunner, model: "default", skills, repoClient, requirePrincipal: config.requirePrincipal,
+        runner, subRunner, handslessSubRunner, model: "default", skills, repoClient, requirePrincipal: config.requirePrincipal,
         webSearch: webSearch ? webSearch : undefined, metrics, logger, webFetchSummarize,
         // core 1.364 写半场:与 RunnerDeps.backgroundAgentStore 同实例(组装区注释;半接=静默死特性)。
         backgroundAgentStore: backgroundAgentStore ? backgroundAgentStore : undefined,
@@ -629,29 +675,12 @@ async function main() {
     // checkpointStore 同实例天然成立;per-request 项如 webSearch 对 revive 无关——objective 在 core
     // driveParkedResume 里被丢弃)。checkpointStore/agentStore 任一缺席 = park 本就不可达,分支不接线。
     const parkedReviveTool = checkpointStore && backgroundAgentStore ? scenarios.default?.({})?.tools.find((t) => t.name === "Agent") : undefined;
-    // [1596]/[1597] 跨进程父约束重供席工厂:host 任务的 toolPolicy 解析槽按部署配置**同参重建**
-    // (resolveSpec durableEnabled 分支的同款折叠:durableQuestion + durableAsk 四旋钮),单层链
-    // count=1,durableMandate=true(host 有 durableApproval 且 durable 车道无 live onAsk 的恒形)。
-    // exempt 探针锚 = row.rootSessionId——与 parked decide 的 remember grant 锚同键([1591] 候裁②),
-    // 重建链上的豁免语义与原链一致。重建不出(无 root 锚)= 不供席 = core pre-CAS 门诚实拒(现状)。
-    // #152 复审 A2:「同参重建」是本工厂自述的不变式,所以 question 门必须调 resolve-spec 的**同一个**
-    // 工厂并传同一个活体面,不能自折 core 原形——分腿改动只落一侧就是两份拷贝开始漂移的那一刻。
-    // 赎回腿今天无 question ALS ctx(/decide 路由触发,core driveParkedResume 内驱动)⇒ 判 ask,与原形同判。
+    // [1596]/[1597] 跨副本父约束重供席工厂:host 任务的 toolPolicy 解析槽按**当前**部署配置重建
+    // 「部署 ⊇ 操作员」两层完整链(design/181 件二收编;实现与全部理由在 boot/parked-revive-gate.ts,
+    // 提出去的唯一理由是 main.ts 顶层 `void main()` 让那条腿的运行期语义在原地一格都钉不住)。
+    // 构造条件逐字保持:裸 Agent 工具在场 ∧ 部署真开了 durable 审批。
     const parkedReviveInheritedGate = parkedReviveTool && config.durableApproval
-        ? (row) => ({
-            parentConstraints: [{
-                    policy: combinePolicies(createDurableQuestionGate(question), createDurableAskPolicy({
-                        requireApproval: config.approvalRequire, deny: config.approvalDeny, autoBudget: config.approvalAutoBudget, neverAuto: config.approvalNeverAuto,
-                        ...(approvalExemptionStore && row.rootSessionId
-                            ? {
-                                exempt: (toolName) => approvalExemptionStore.has(row.rootSessionId, toolName),
-                                onExempted: (toolName, rawToolName) => logger.info("approval_exempted", { sessionId: row.rootSessionId, toolName, rawToolName, leg: "parked_revive" }),
-                            }
-                            : {}),
-                    })),
-                    durableMandate: true,
-                }],
-        })
+        ? createParkedReviveInheritedGate({ config, question, approvalExemptionStore, logger, localRoot })
         : undefined;
     // 场景详情:内建 details 必须在 overlay 合并【前】构建(探针要打纯内建工厂,不是被 center 顶掉的);
     // center details 随 overlay 同判定源盖同名——source 语义与 selectScenario 实际取用永一致(约定①)。
@@ -779,6 +808,10 @@ async function main() {
         // Undefined-safe: the env-only/no-backend worker 501s the routes.
         backend: backend ? backend : undefined,
     };
+    // [3193] 病理1:fleet 快照的 recovery 屏障(deferred 形,声明先于 deps 装配、落定在下方 recover 块——
+    // 对装配顺序鲁棒;无 notify gate 的部署在 recover 块 else 臂立即落)。
+    let resolveFleetRecovery;
+    const fleetRecoveryDone = new Promise((r) => { resolveFleetRecovery = r; });
     /** 进程内活体协调面(本副本 only,重启即空:HITL 协调器/可 steer 句柄注册表/总线/收件箱) */
     const coordinators = {
         elicitation: elicitation ? elicitation : undefined, // E23: live-only inbound-elicitation coordinator (respond route + ALS wraps)
@@ -788,6 +821,7 @@ async function main() {
         subagentSteerRegistry, // C2 (core 1.219): steerable Task-subagent handle registry (POST /v1/runs/:id/subagents/:target/steer)
         workflowCompletionInbox: workflowCompletionInbox ? workflowCompletionInbox : undefined, // P1 ①②: drain → workflow_complete frame on stream-open
         fleetBus,
+        fleetRecoveryDone, // [3193] 病理1:快照组装的有界等待信号(recover 块落定)
         // [1196] session 级 SSE 订阅:watch registry(N 订阅共享一条探针,自适应拍距,无订阅即停)。谓词与
         // /head 探针同门(getLeafId+ownerOf);缺 store 面不建=路由 501+capabilities.sessionEvents=false。
         sessionWatch: sessionWatchRegistry ? sessionWatchRegistry : undefined, // [1196] 建于 purgeSession 之前(delete 即 dropSession 的同副本围栏)
@@ -909,8 +943,12 @@ async function main() {
         // 帽只在 watch 面在场时才有意义(缺席时路由 501,读不到它)——保持与原条件段同门,不单独接线。
         sessionEventsMaxConnections: sessionWatchRegistry ? posIntEnv(process.env.SESSION_EVENTS_MAX_CONNS, 256, 100_000) : undefined,
     };
+    // #196:hands lane 登记簿 —— resolveSpec 登记本请求场景的表态,HTTP 执行点凭 spec 取回选 Runner。
+    // 两处**同一实例**(交给 createResolveSpec 与 runnerFor 闭包),配对由这一行结构性保证。
+    const handsLanes = createHandsLaneRegistry();
     // design/158 A10:resolveSpec 段搬到 src/boot/resolve-spec.ts(逐字;两处活引用改取值,见该文件头注)。
     const resolveSpec = createResolveSpec({
+        handsLanes,
         config, logger, metrics, localRoot, scenarios, principalCaps, centerRuntimeCapsResolver,
         getCenterPrompts: () => configCenter.getCenterPrompts(),
         getKeyResolver: () => configCenter.getKeyResolver(),
@@ -921,7 +959,9 @@ async function main() {
         sessionEnvSelection,
         liveQuestionFace: question, // #152:活体问答面在场 ⇒ durable question 门按活流分腿(见 ResolveSpecCtx 注)
     });
-    const server = createHttpServer({ runner, config, resolveSpec, stores, coordinators, seams, observability, governance, deployment, knobs });
+    // #196:执行点选路。resolveSpec 已按场景判别位登记 lane;`full` 恒回主 runner(修前行为逐字不变)。
+    const runnerFor = (spec) => pickHandsRunner(handsLanes.laneOf(spec), { full: runner, handsless: handslessRunner });
+    const server = createHttpServer({ runner, runnerFor, config, resolveSpec, stores, coordinators, seams, observability, governance, deployment, knobs });
     // D-D SLA-timer: wire the server's deny-sweep into the reaper holder declared above (the reaper is defined
     // before the server, so it calls through this late-bound reference).
     runDenySweep = server.denyExpiredApprovals;
@@ -1040,10 +1080,17 @@ async function main() {
     // sweep throw is logged, never fatal.
     if (workflowNotifyGate) {
         // [2995]/[2999] opts 单点合成在 workflow-orchestration(可见性回灌 + replica-local 形 boot 孤儿判死)。
+        // [3193] 病理1:recover 收官(成败皆算)即落 fleet 快照屏障——「serving 不等 recovery」对**提交请求**
+        // 仍成立,但 fleet 快照组装现在对它做有界等待(routes/fleet.ts,3s cap):SIGKILL 后壳重连不再
+        // 与 boot 判死赛跑(cli [3193] 插桩实证的竞态)。
         void workflowNotifyGate
             .recover(workflowRecoverOpts)
             .then((tally) => logger.info("workflow_notify_recovered", tally))
-            .catch((err) => logger.warn("workflow_notify_recover_failed", { err: String(err) }));
+            .catch((err) => logger.warn("workflow_notify_recover_failed", { err: String(err) }))
+            .finally(() => resolveFleetRecovery());
+    }
+    else {
+        resolveFleetRecovery();
     }
     // design/158 A10:收尾段搬到 src/boot/shutdown.ts(逐字)。⚠️ 调用点必须留在 listen 之后 —— 位置即契约,
     // 理由(信号注册时点/三信号相对次序/clearInterval 先于 server.close)见该文件头注。

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

@@ -37,6 +37,10 @@ export declare const FAIL_OPEN_TAGS: {
         readonly cls: "F";
         readonly note: "已验签的提示词工件回填本地缓存失败。工件本身已返回给调用方;代价是下次同 digest 还要再取一次网络。";
     };
+    readonly "server.fleet.snapshot-terminal-window-unavailable": {
+        readonly cls: "F";
+        readonly note: "`/v1/fleet/stream` 连接时快照的**近期终态行窗**(#189:引擎重启后 boot 判死的 workflow 行,pull 自 durable store)读失败或超预算(2s)⇒ 本次快照少这几行历史。放行的最坏后果=面板首屏看不到刚结束的 workflow(与本修之前的行为等同,不是新损失);真源不受影响(`GET /v1/workflows` 照常)。方向刻意 fail-open:一次慢查询不该把整条 SSE 的握手拖住——少几行是难看,连不上流是坏掉。";
+    };
     readonly "server.fleet.subscriber-callback-threw": {
         readonly cls: "F";
         readonly note: "fleet bus 某订阅回调抛错 ⇒ 该回调本帧作废,其余订阅方与发布方不受影响。隔离是承重的:扇出同步,修前异常会传回发布方 put/update 投影点,core 持久化 catch{} 且不推进 storeRev ⇒ durable 行冻在 running 而 notify 已 ack(#183 复审 R3 HIGH)。丢的只是一个消费方的一帧渲染,故 F 类;但必须留痕——静默吞掉等于订阅方病灶永不显形。";

package/dist/observability/fail-open.js

@@ -60,6 +60,10 @@ export const FAIL_OPEN_TAGS = {
         cls: "F",
         note: "已验签的提示词工件回填本地缓存失败。工件本身已返回给调用方;代价是下次同 digest 还要再取一次网络。",
     },
+    "server.fleet.snapshot-terminal-window-unavailable": {
+        cls: "F",
+        note: "`/v1/fleet/stream` 连接时快照的**近期终态行窗**(#189:引擎重启后 boot 判死的 workflow 行,pull 自 durable store)读失败或超预算(2s)⇒ 本次快照少这几行历史。放行的最坏后果=面板首屏看不到刚结束的 workflow(与本修之前的行为等同,不是新损失);真源不受影响(`GET /v1/workflows` 照常)。方向刻意 fail-open:一次慢查询不该把整条 SSE 的握手拖住——少几行是难看,连不上流是坏掉。",
+    },
     "server.fleet.subscriber-callback-threw": {
         cls: "F",
         note: "fleet bus 某订阅回调抛错 ⇒ 该回调本帧作废,其余订阅方与发布方不受影响。隔离是承重的:扇出同步,修前异常会传回发布方 put/update 投影点,core 持久化 catch{} 且不推进 storeRev ⇒ durable 行冻在 running 而 notify 已 ack(#183 复审 R3 HIGH)。丢的只是一个消费方的一帧渲染,故 F 类;但必须留痕——静默吞掉等于订阅方病灶永不显形。",

package/dist/observability/tool-trace.d.ts

@@ -25,6 +25,19 @@ export declare function createPermissionDeniedMeter(metrics: Pick<Metrics, "inc"
  *
  * Pure observation: every hook returns `undefined`, so it never rewrites args, never gates, never alters
  * the result (and per core's hooks invariant a hook's `allow` can't bypass the policy gate anyway).
+ *
+ * 🔴 core 5.20.0 起这条「纯观察」性质必须**声明**出来(`preToolUseObservational`),不能只写在注释里:
+ * core 5.19.0 的委派折叠按「PreToolUse 席位在不在」把父的 screening 面折进子代的祖先约束链——它分不出
+ * 诊断 tracer 与真裁决者。后果是**这个默认关的诊断旋钮**一开,该部署所有 hook-wired 父的 parked 子代
+ * checkpoint 就记 `parentConstraintCount=2`,而跨副本赎回腿(`boot/parked-revive-gate.ts`)恒供 1 ⇒
+ * core pre-CAS 响亮拒、行永久 pending(层数 park 时写死,事后关旋钮/重批/回滚都不改)。
+ * 声明之后该面不铸链条目,count 回到 1,病路消灭。
+ * ⛔ 打这个标的前提是**真的一条裁决都不出**:core 对声明了却返回判词的面是「拒绝采纳 + onError 告警」
+ * (classification `observational-hook-verdict-ignored`),即判词被静默丢弃——把标打到会裁决的面上比原
+ * 缺陷更坏。本文件三个 pre/post 回调恒返 `undefined`,`permissionDenied` 本就是 void 观察槽。
+ * 📎 连带的**可观测**变化(不是回归):core 的「可写工具面无 effect-aware 门」启动告警此前把本 tracer
+ * 算作一道门而被抑制;声明之后它不再算,于是「没配任何 policy 层 + 开着 TOOL_TRACE」的部署升级后会
+ * 多出那行告警。方向正确——tracer 从来没有门住任何东西,原先的抑制本身就是一次静默 fail-open。
  */
 export declare function createToolTracer(logger: Logger): Hooks;
 //# sourceMappingURL=tool-trace.d.ts.map

package/dist/observability/tool-trace.js

@@ -33,9 +33,23 @@ export function createPermissionDeniedMeter(metrics) {
  *
  * Pure observation: every hook returns `undefined`, so it never rewrites args, never gates, never alters
  * the result (and per core's hooks invariant a hook's `allow` can't bypass the policy gate anyway).
+ *
+ * 🔴 core 5.20.0 起这条「纯观察」性质必须**声明**出来(`preToolUseObservational`),不能只写在注释里:
+ * core 5.19.0 的委派折叠按「PreToolUse 席位在不在」把父的 screening 面折进子代的祖先约束链——它分不出
+ * 诊断 tracer 与真裁决者。后果是**这个默认关的诊断旋钮**一开,该部署所有 hook-wired 父的 parked 子代
+ * checkpoint 就记 `parentConstraintCount=2`,而跨副本赎回腿(`boot/parked-revive-gate.ts`)恒供 1 ⇒
+ * core pre-CAS 响亮拒、行永久 pending(层数 park 时写死,事后关旋钮/重批/回滚都不改)。
+ * 声明之后该面不铸链条目,count 回到 1,病路消灭。
+ * ⛔ 打这个标的前提是**真的一条裁决都不出**:core 对声明了却返回判词的面是「拒绝采纳 + onError 告警」
+ * (classification `observational-hook-verdict-ignored`),即判词被静默丢弃——把标打到会裁决的面上比原
+ * 缺陷更坏。本文件三个 pre/post 回调恒返 `undefined`,`permissionDenied` 本就是 void 观察槽。
+ * 📎 连带的**可观测**变化(不是回归):core 的「可写工具面无 effect-aware 门」启动告警此前把本 tracer
+ * 算作一道门而被抑制;声明之后它不再算,于是「没配任何 policy 层 + 开着 TOOL_TRACE」的部署升级后会
+ * 多出那行告警。方向正确——tracer 从来没有门住任何东西,原先的抑制本身就是一次静默 fail-open。
  */
 export function createToolTracer(logger) {
     return {
+        preToolUseObservational: true,
         preToolUse(toolName, input, ctx) {
             logger.info("tool_trace", { phase: "pre", id: ctx.toolCallId, tool: toolName, arg: summarize(input) });
             return undefined;

package/dist/orchestration/workflow-notify-journal.d.ts

@@ -1,5 +1,5 @@
 import type { WorkflowRun, WorkflowRunStore, WorkflowRunStatus, WorkflowRunSummary } from "@sema-agent/core";
-import type { FleetEventBus } from "../fleet/fleet-bus.js";
+import { type FleetEventBus } from "../fleet/fleet-bus.js";
 /** A workflow completion notification's terminal payload — the bounded, redacted shape core's notifier seam
  *  carries, re-derivable from a durable {@link import("@sema-agent/core").WorkflowRun} on the recovery path. */
 export interface WorkflowCompletionPayload {

package/dist/orchestration/workflow-notify-journal.js

@@ -41,8 +41,8 @@
  */
 import { mkdirSync, readFileSync, existsSync, openSync, writeSync, fsyncSync, closeSync } from "node:fs";
 import { join } from "node:path";
-import { deriveAgentDisplayStatus } from "@sema-agent/core";
-import { redactSecrets } from "../trace/redact.js";
+import { buildFleetWorkflowRow } from "../fleet/fleet-bus.js";
+import { isTerminalWorkflowRowStatus, seedTerminalWorkflowRow } from "../fleet/fleet-terminal-window.js";
 /** Build a bounded + redacted completion summary from a durable run's terminal state (the recovery path — the
  *  live path uses core's own `boundedSummary`). We never have the raw result here (the run store keeps the run,
  *  not the originator's payload), so we synthesize a conservative one: status + the run's already-bounded error.
@@ -500,43 +500,23 @@ export class JournalingWorkflowRunStore {
     publishFleet(id, run) {
         if (!this.fleetBus)
             return;
-        const agents = run.agents ?? [];
-        // [2336] doneCount 与 failedCount **不相交**:done 只数 completed。契约以此为前提(fleet-bus.ts
-        // startedCount 注的回退式 done+failed ≤ started);把 failed 也计进 done 会让全失败 workflow 的
-        // 终帧渲成 "N done"(cli 4.1.3 实测 done=2 failed=2 started=2)。
-        const done = agents.filter((a) => a.status === "completed").length;
-        const failed = agents.filter((a) => a.status === "failed").length;
-        // cli [1726] 二①:CC 规模告警的分母是 **started**(已启动),而 `totalCount`(= agents.length)是**计划总数**
-        // (含排队中)。判别口径走 core 导出的 `deriveAgentDisplayStatus` —— 一个 agent 已在 `run.agents` 里但
-        // `startedAt` 未置就是排队中。**不自己写 `startedAt !== undefined`**:那是 core 的显示契约,两端各写一遍
-        // 必然漂移(本仓刚在 coarse 门镜像上吃过同款),用它的函数则 core 一改、两端同时跟随。
-        const started = agents.filter((a) => deriveAgentDisplayStatus(a, run.status) !== "queued").length;
-        const terminal = run.status === "completed" || run.status === "failed";
+        // A-002.3(#194 病族 F1 同源性断裂):终态判据走 fleet-terminal-window 的共享谓词(其穷举表对
+        // core WorkflowRunStatus 编译期闭合)——此前手写两值比较是第二份独立定义,core 加终态词时穷举表
+        // 红、这里恒 false ⇒ 行既不 seed 进终态窗也不 removeWorkflow,面板留幽灵 running 行。
+        const terminal = isTerminalWorkflowRowStatus(run.status);
         // 撤行**不挂在发帧成功上**(复审第 2 轮 MEDIUM):「终态行必须离场」是不变量、发终帧是尽力而为。
         // try/finally ⇒ 发布本体抛错照样撤行(异常仍向上抛,不吞:吞了就是一条未登记的 fail-open 臂)。
         // 订阅方抛错已在 fleet bus 的 subscribe 隔离层被吞并记 fail-open——本 finally 守的是发布机器本身
         // 的抛错(理论缝级,fresh 复审盘点后判近死防御但保留:防未来发布本体改动回退)。两腿一处收口。
+        // 行投影本体 = {@link buildFleetWorkflowRow}(#189:快照的终态行窗与本写路径共用同一份投影,
+        // 单源不漂;本函数的发布/撤行语义逐字不变)。
+        // [3156] 轮2 修:终态行**写路径顺手 seed** 进程内终态窗缓存——重启-重连剧本里(boot recover 判死),
+        // fleetWide 连接的 durable pull 没有正确的查询键可用(caller principal ≠ 引擎铸行 scope),seed 是
+        // 唯一同源可达径。放在 publish 之前:seed 是纯内存 push,不会抛;终态行入窗与发帧同拍。
+        if (terminal)
+            seedTerminalWorkflowRow(buildFleetWorkflowRow(id, run));
         try {
-            this.fleetBus.publishWorkflow({
-                id,
-                // [WF2-A parity] redact the workflow label surfaces for parity with the run + subagent-child names (fleet-bus.ts):
-                // a tool-launched (LLM-authored) workflow's meta.name/description is task-controlled and could carry a secret shape.
-                name: redactSecrets(run.name ?? "Dynamic workflow"),
-                ...(run.description ? { description: redactSecrets(run.description) } : {}),
-                scope: run.scope,
-                // codex-6 F2:sessionId 必须随行——streamFleet 对无 sessionId 的行按「同 principal 全会话可见」
-                // 兜底,漏发=A 会话的 workflow 名/进度/token 泄进 B 会话的 ?session= 过滤流。
-                ...(run.originatingSessionId ? { sessionId: run.originatingSessionId } : {}),
-                status: run.status,
-                doneCount: done,
-                totalCount: agents.length,
-                failedCount: failed,
-                startedCount: started,
-                tokens: (run.stats?.tokens ?? 0) + (run.stats?.nested?.tokens ?? 0),
-                // [1294]:跑动中也带时长(1.232 只在 endedAt 后带——clay 验收轮实锚面板恒显 0s)。终态用
-                // endedAt 定格,活跑用 now-startedAt(每次 put/update 观察点刷新,壳侧读帧即当前时长)。
-                elapsedMs: (run.endedAt ?? Date.now()) - run.startedAt,
-            });
+            this.fleetBus.publishWorkflow(buildFleetWorkflowRow(id, run));
         }
         finally {
             if (terminal)

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

@@ -297,6 +297,39 @@ export declare const APPROVAL_BATCHES_TABLE = "approval_batches";
  *
  * SCHEMA POLICY 同 `tidb-pool.ts` 头注:纯 CREATE,禁 ALTER 增量 seam,改列直接改这里 + 重建库
  * (`docs/schema/baseline-mysql.sql` 是由这些文本机器录制出的**产物**,永不手改)。
+ *
+ * ── 列宽的**测量依据**(#192 A10;U2 逐列取证在档)──────────────────────────────────────────────────
+ * 本表家族原先一律 VARCHAR(255),是"先建表后想"的产物。按"每列的值到底由谁铸、有没有入口上限"重新裁:
+ *
+ *  收窄(有硬上限背书,证据即上限本身):
+ *   · `ask_id` / `batch_id` / `bound_ask_id` → 64:`deriveAskId`/`deriveBatchId` 恒是 sha256 hex 取前
+ *     64 字符(`approval-ask-machine.ts` deterministicId),按构造不可能更长。
+ *   · `task_id` → 64:入口 `UUIDV7_RE`(`security.ts:134`)只放行 36 字符的规范 uuidv7;与兄弟列
+ *     `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/scope 轴都是 190,此前 255 同样是无依据偏离。
+ *   · `gate_token` → 120:它抄的是 checkpoint 的 token(core `mintCheckpointToken` = 16 字节 hex = 32 字符),
+ *     取与**被抄那一列** `checkpoint.token VARCHAR(120)` 同宽 —— 同一个值在两张表上宽度必须一致,
+ *     否则抄的那一步就是一道静默截断。512 是原先的 16 倍冗余。
+ *
+ *  🔑 上面四条收窄之所以**不引入任何新暴露面**,靠的不是入口断言而是一条更硬的事实:同一个 session_id /
+ *     task_id / owner **早就**同时躺在 `session_meta.session_id VARCHAR(64)` / `task_run.task_id VARCHAR(64)` /
+ *     `task_run.owner VARCHAR(190)` 里。任何长到能撑爆本表新宽度的值,在写到那几张**更中心**的表时就已经
+ *     先炸了 —— 本表此前的 255 从来不是一道额外的安全余量,只是一处与全仓不一致的偏离。
+ *     ⇒ 收窄的风险上界 = 0;真正要担心的是反过来:留着 255 会让人误以为这里可以存更长的 id。
+ *
+ *  🔴 **刻意不收窄**(测量结果不支持,记在这里免得下一个人以为是漏了):
+ *   · `source_task_id` / `tool_call_id` / `parent_tool_call_id` / `gate_bound_call_id` —— 这四列的值是
+ *     **模型/引擎铸的原始 id**,服务端在写行这一步**没有任何长度断言**(`approval-card.ts` 的
+ *     `MAX_IDENT` 只裁了给人看的那份 card 投影,不是本列)。没有入口上限就收窄 = 把"存不下"这件事
+ *     推迟到 INSERT 才炸(MySQL 更糟:静默截断),换来的只是几十字节。要收窄,先补入口断言
+ *     (照 `assertPrincipalShape`/`assertIdempotencyKeyShape` 的姿势),那是另一件事。
+ *   · `bound_input_hash` / `gate_bound_input_hash` —— 按约定是 sha256 hex(64),但 `readBoundInputHash`
+ *     只校验"非空字符串",没校长度/字形 ⇒ 同上,先有断言再谈收窄。
+ *   · `idempotency_key` —— 255 **正是**入口断言的上限本身(zod `.max(255)` + 店内 `assertIdempotencyKeyShape`
+ *     双执法),宽度与上限同源,恰好正确,动它反而制造截断面。
  */
 export declare const TIDB_APPROVAL_ASK_STATEMENTS: readonly string[];
 /** {@link TIDB_APPROVAL_ASK_STATEMENTS} 的遍历壳——生产路径走 `tidb-pool.ts` 的中央 `ensureSchema`

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

@@ -71,13 +71,46 @@ export const APPROVAL_BATCHES_TABLE = "approval_batches";
  *
  * SCHEMA POLICY 同 `tidb-pool.ts` 头注:纯 CREATE,禁 ALTER 增量 seam,改列直接改这里 + 重建库
  * (`docs/schema/baseline-mysql.sql` 是由这些文本机器录制出的**产物**,永不手改)。
+ *
+ * ── 列宽的**测量依据**(#192 A10;U2 逐列取证在档)──────────────────────────────────────────────────
+ * 本表家族原先一律 VARCHAR(255),是"先建表后想"的产物。按"每列的值到底由谁铸、有没有入口上限"重新裁:
+ *
+ *  收窄(有硬上限背书,证据即上限本身):
+ *   · `ask_id` / `batch_id` / `bound_ask_id` → 64:`deriveAskId`/`deriveBatchId` 恒是 sha256 hex 取前
+ *     64 字符(`approval-ask-machine.ts` deterministicId),按构造不可能更长。
+ *   · `task_id` → 64:入口 `UUIDV7_RE`(`security.ts:134`)只放行 36 字符的规范 uuidv7;与兄弟列
+ *     `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/scope 轴都是 190,此前 255 同样是无依据偏离。
+ *   · `gate_token` → 120:它抄的是 checkpoint 的 token(core `mintCheckpointToken` = 16 字节 hex = 32 字符),
+ *     取与**被抄那一列** `checkpoint.token VARCHAR(120)` 同宽 —— 同一个值在两张表上宽度必须一致,
+ *     否则抄的那一步就是一道静默截断。512 是原先的 16 倍冗余。
+ *
+ *  🔑 上面四条收窄之所以**不引入任何新暴露面**,靠的不是入口断言而是一条更硬的事实:同一个 session_id /
+ *     task_id / owner **早就**同时躺在 `session_meta.session_id VARCHAR(64)` / `task_run.task_id VARCHAR(64)` /
+ *     `task_run.owner VARCHAR(190)` 里。任何长到能撑爆本表新宽度的值,在写到那几张**更中心**的表时就已经
+ *     先炸了 —— 本表此前的 255 从来不是一道额外的安全余量,只是一处与全仓不一致的偏离。
+ *     ⇒ 收窄的风险上界 = 0;真正要担心的是反过来:留着 255 会让人误以为这里可以存更长的 id。
+ *
+ *  🔴 **刻意不收窄**(测量结果不支持,记在这里免得下一个人以为是漏了):
+ *   · `source_task_id` / `tool_call_id` / `parent_tool_call_id` / `gate_bound_call_id` —— 这四列的值是
+ *     **模型/引擎铸的原始 id**,服务端在写行这一步**没有任何长度断言**(`approval-card.ts` 的
+ *     `MAX_IDENT` 只裁了给人看的那份 card 投影,不是本列)。没有入口上限就收窄 = 把"存不下"这件事
+ *     推迟到 INSERT 才炸(MySQL 更糟:静默截断),换来的只是几十字节。要收窄,先补入口断言
+ *     (照 `assertPrincipalShape`/`assertIdempotencyKeyShape` 的姿势),那是另一件事。
+ *   · `bound_input_hash` / `gate_bound_input_hash` —— 按约定是 sha256 hex(64),但 `readBoundInputHash`
+ *     只校验"非空字符串",没校长度/字形 ⇒ 同上,先有断言再谈收窄。
+ *   · `idempotency_key` —— 255 **正是**入口断言的上限本身(zod `.max(255)` + 店内 `assertIdempotencyKeyShape`
+ *     双执法),宽度与上限同源,恰好正确,动它反而制造截断面。
  */
 export const TIDB_APPROVAL_ASK_STATEMENTS = [
     `CREATE TABLE IF NOT EXISTS ${APPROVAL_BATCHES_TABLE} (
-    batch_id VARCHAR(255) NOT NULL,
-    task_id VARCHAR(255) NOT NULL,
+    batch_id VARCHAR(64) NOT NULL,
+    task_id VARCHAR(64) NOT NULL,
     state VARCHAR(32) NOT NULL,
-    bound_ask_id VARCHAR(255) NULL,
+    bound_ask_id VARCHAR(64) NULL,
     version INT NOT NULL DEFAULT 0,
     created_at_ms BIGINT NOT NULL,
     updated_at_ms BIGINT NOT NULL,
@@ -85,12 +118,12 @@ export const TIDB_APPROVAL_ASK_STATEMENTS = [
     KEY idx_batch_task (task_id)
   ) COLLATE utf8mb4_bin`,
     `CREATE TABLE IF NOT EXISTS ${APPROVAL_ASKS_TABLE} (
-    ask_id VARCHAR(255) NOT NULL,
-    task_id VARCHAR(255) NOT NULL,
+    ask_id VARCHAR(64) NOT NULL,
+    task_id VARCHAR(64) NOT NULL,
     source_task_id VARCHAR(255) NOT NULL,
-    session_id VARCHAR(255) NOT NULL,
-    owner VARCHAR(255) NULL,
-    batch_id VARCHAR(255) NOT NULL,
+    session_id VARCHAR(64) NOT NULL,
+    owner VARCHAR(190) NULL,
+    batch_id VARCHAR(64) NOT NULL,
     tool_call_id VARCHAR(255) NOT NULL,
     -- leg_key: 车3 §3.2′ 身份轴——sha256(resume checkpoint token) 的 hex(64 字符),首腿存空串。
     -- 取代原来的数值 leg 列:一腿一凭据,零 DDL 依赖 task_run、零 markResuming 改动。NOT NULL(空串
@@ -110,7 +143,7 @@ export const TIDB_APPROVAL_ASK_STATEMENTS = [
     decision_note TEXT NULL,
     decided_at_ms BIGINT NULL,
     denied_reason VARCHAR(64) NULL,
-    gate_token VARCHAR(512) NULL,
+    gate_token VARCHAR(120) NULL,
     gate_bound_call_id VARCHAR(255) NULL,
     gate_bound_input_hash VARCHAR(255) NULL,
     idempotency_key VARCHAR(255) NULL,
@@ -141,10 +174,10 @@ export async function ensureTiDBApprovalAskSchema(pool) {
 }
 export async function ensurePgApprovalAskSchema(q) {
     await q(`CREATE TABLE IF NOT EXISTS ${APPROVAL_BATCHES_TABLE} (
-    batch_id VARCHAR(255) NOT NULL,
-    task_id VARCHAR(255) NOT NULL,
-    state VARCHAR(32) NOT NULL,
-    bound_ask_id VARCHAR(255),
+    batch_id VARCHAR(64) COLLATE "C" NOT NULL,
+    task_id VARCHAR(64) COLLATE "C" NOT NULL,
+    state VARCHAR(32) COLLATE "C" NOT NULL,
+    bound_ask_id VARCHAR(64) COLLATE "C",
     version INT NOT NULL DEFAULT 0,
     created_at_ms BIGINT NOT NULL,
     updated_at_ms BIGINT NOT NULL,
@@ -152,33 +185,33 @@ export async function ensurePgApprovalAskSchema(q) {
   )`);
     await q(`CREATE INDEX IF NOT EXISTS idx_batch_task ON ${APPROVAL_BATCHES_TABLE} (task_id)`);
     await q(`CREATE TABLE IF NOT EXISTS ${APPROVAL_ASKS_TABLE} (
-    ask_id VARCHAR(255) NOT NULL,
-    task_id VARCHAR(255) NOT NULL,
-    source_task_id VARCHAR(255) NOT NULL,
-    session_id VARCHAR(255) NOT NULL,
-    owner VARCHAR(255),
-    batch_id VARCHAR(255) NOT NULL,
-    tool_call_id VARCHAR(255) NOT NULL,
+    ask_id VARCHAR(64) COLLATE "C" NOT NULL,
+    task_id VARCHAR(64) COLLATE "C" NOT NULL,
+    source_task_id VARCHAR(255) COLLATE "C" NOT NULL,
+    session_id VARCHAR(64) COLLATE "C" NOT NULL,
+    owner VARCHAR(190) COLLATE "C",
+    batch_id VARCHAR(64) COLLATE "C" NOT NULL,
+    tool_call_id VARCHAR(255) COLLATE "C" NOT NULL,
     -- leg_key: 车3 §3.2′ 身份轴——sha256(resume checkpoint token) 的 hex(64 字符),首腿存空串
     -- (空串是首腿的真值,不是缺席,故 NOT NULL)。MySQL 侧 twin 逐字同形。
-    leg_key VARCHAR(64) NOT NULL,
-    parent_tool_call_id VARCHAR(255),
+    leg_key VARCHAR(64) COLLATE "C" NOT NULL,
+    parent_tool_call_id VARCHAR(255) COLLATE "C",
     -- bound_input_hash(车5 §9 C2)——MySQL twin 逐字同形(宽度/语义见那侧注)。
-    bound_input_hash VARCHAR(255),
-    state VARCHAR(32) NOT NULL,
+    bound_input_hash VARCHAR(255) COLLATE "C",
+    state VARCHAR(32) COLLATE "C" NOT NULL,
     -- clay 批 TINYINT(1) 归一先例:PG 侧统一 SMALLINT 0/1(此前本家族用过 BOOLEAN,已裁弃).
     provisional SMALLINT NOT NULL DEFAULT 0,
     version INT NOT NULL DEFAULT 0,
-    decision VARCHAR(16),
-    decision_actor TEXT,
-    decision_note TEXT,
+    decision VARCHAR(16) COLLATE "C",
+    decision_actor TEXT COLLATE "C",
+    decision_note TEXT COLLATE "C",
     decided_at_ms BIGINT,
-    denied_reason VARCHAR(64),
-    gate_token VARCHAR(512),
-    gate_bound_call_id VARCHAR(255),
-    gate_bound_input_hash VARCHAR(255),
-    idempotency_key VARCHAR(255),
-    card_json TEXT NOT NULL,
+    denied_reason VARCHAR(64) COLLATE "C",
+    gate_token VARCHAR(120) COLLATE "C",
+    gate_bound_call_id VARCHAR(255) COLLATE "C",
+    gate_bound_input_hash VARCHAR(255) COLLATE "C",
+    idempotency_key VARCHAR(255) COLLATE "C",
+    card_json TEXT COLLATE "C" NOT NULL,
     schema_version INT NOT NULL,
     expires_at_ms BIGINT NOT NULL,
     created_at_ms BIGINT NOT NULL,