@sema-agent/server 7.52.1 → 7.54.0

package/dist/orchestration/hardened-vm-runner.d.ts

@@ -40,7 +40,7 @@ import { type WorkflowScriptRunner, type WorkflowPrimitives } from "@sema-agent/
  *   timer nor the abort listener fires → it hangs the process. The worker-isolated runner (`terminate()`)
  *   pre-empts that — use it for genuinely-untrusted multi-tenant scripts where resource isolation matters.
  *
- * 🔴 Silent-hang class ([1818]§二, clay live incident 2026-07-26): a script whose promise graph can NEVER settle
+ * 🔴 Silent-hang class ([ref]§二, clay live incident 2026-07-26): a script whose promise graph can NEVER settle
  *   (an un-awaited `phase(...)` whose body returns its own promise) used to burn the full totalTimeoutMs blind
  *   and then blame the timeout. The quiescence detector in {@link runHardened} fail-fasts it with a diagnosis:
  *   inside the membrane the bridge is the ONLY async host seam, so bridge-quiescent + both queues drained +
@@ -62,20 +62,20 @@ export interface HardenedVmLimits {
      *  A script exceeding it OOMs the WORKER (killed), never the shared main process. Default 128. */
     maxHeapMb?: number;
 }
-/** [5434]①(clay 亲机四 run 三次恰在 600s 整点全灭):workflow 总超时默认与旋钮的**单点**。
+/** [ref]①(clay 亲机四 run 三次恰在 600s 整点全灭):workflow 总超时默认与旋钮的**单点**。
  *  旧默认 600_000(10 分钟)对真实 workflow(验证 agent 逐条重跑清单/任何带审批等待的车)结构性不够——
  *  默认抬到 **1 小时**;部署经 `WORKFLOW_TOTAL_TIMEOUT_MS` 显式配,域 [60_000, 86_400_000](1 分钟..24h),
- *  坏值**响亮拒**(#210 立律:旋钮坏值禁静默回默认)。0/负数不是「禁用」:无界 runaway 脚本会吞掉共享
+ *  坏值**响亮拒**([ref] 立律:旋钮坏值禁静默回默认)。0/负数不是「禁用」:无界 runaway 脚本会吞掉共享
  *  副本的事件循环/堆,禁用臂刻意不提供——要更久就把值配大。模块加载时读一次(坏 env = boot fail-loud)。
- *  超时终态分型(partial vs failed,[5434]① 后半)涉 wire status 语义,与 core workflow 终态形另批对表。 */
+ *  超时终态分型(partial vs failed,[ref]① 后半)涉 wire status 语义,与 core workflow 终态形另批对表。 */
 export declare function workflowTotalTimeoutMsDefault(): number;
 /**
  * The realm test itself, exported so there is exactly ONE ruler for "did this rejection come from an untrusted
  * script?" in the process. A promise minted INSIDE a vm context fails `instanceof` against the HOST `Promise`
  * (different intrinsic per realm) — that is the whole judgement.
  *
- * 🔴 Why it is exported (A-070 二轮重扫, lifecycle-pairing, double-opus CONFIRMED): the guard below is NOT the
- * only `unhandledRejection` listener in a real boot. `src/boot/shutdown.ts` installs one at boot (#320① crash
+ * 🔴 Why it is exported ([ref] 二轮重扫, lifecycle-pairing, double-opus CONFIRMED): the guard below is NOT the
+ * only `unhandledRejection` listener in a real boot. `src/boot/shutdown.ts` installs one at boot ([ref]① crash
  * last words) that exits(1); Node walks EVERY listener for the event, so containment cannot be expressed by
  * one listener returning early — whoever exits wins regardless of registration order. The containment DECISION
  * therefore lives in the boot handler, and it must use this same ruler rather than minting a second one.

package/dist/orchestration/hardened-vm-worker-runner.d.ts

@@ -1,7 +1,7 @@
 import { type WorkflowScriptRunner } from "@sema-agent/core";
 import { type HardenedVmLimits } from "./hardened-vm-runner.js";
 /**
- * Worker-isolated S8 hard runner (design/98 v2). Runs the hardened-vm membrane inside a `worker_thread`, adding
+ * Worker-isolated S8 hard runner ([ref] v2). Runs the hardened-vm membrane inside a `worker_thread`, adding
  * RESOURCE isolation on top of the in-process {@link import("./hardened-vm-runner.js").createHardenedVmRunner}'s
  * BOUNDARY isolation:
  *   - HEAP cap (`resourceLimits.maxOldGenerationSizeMb`): a runaway-allocation script OOMs the WORKER (an `error`

package/dist/orchestration/subagent-steer.d.ts

@@ -1,6 +1,6 @@
 import type { SubagentSteerHandle } from "@sema-agent/core";
 /**
- * C2 (core 1.219) + design/122 (core 1.225) — the SERVICE-side registry for
+ * C2 (core 1.219) + [ref] (core 1.225) — the SERVICE-side registry for
  * STEERING and RESUMING a Task SUB-AGENT (a sync delegation spawned by the `Agent` tool), the sibling of
  * {@link import("./workflow-agent-steer.js").WorkflowAgentRegistry} for workflow agents.
  *
@@ -10,7 +10,7 @@ import type { SubagentSteerHandle } from "@sema-agent/core";
  * Delivery is replica-local (the handle is an in-memory bridge, like `steerableRuns`); a cross-replica
  * steer/resume is an honest 409, never a silent drop.
  *
- * 🔴 LIFECYCLE (design/122 item ③ — the "不改必踩" change): handles are NO LONGER evicted on child settle.
+ * 🔴 LIFECYCLE ([ref] item ③ — the "不改必踩" change): handles are NO LONGER evicted on child settle.
  * `resume` is only legal AFTER the child settled (core rejects `steering.still_running` before), so a
  * settle-evicted registry would make resume structurally unreachable. Instead:
  *   - one handle PER parentToolCallId, NEWEST WINS (core D2: each resume re-emits a FRESH handle under the
@@ -41,7 +41,7 @@ export declare class SubagentSteerRegistry {
     /** Register a child handle under its parent run. SAME parentToolCallId replaces (core D2: a resume
      *  re-emits a fresh handle for the revived run — newest wins). Returns an IDENTITY-GUARDED unregister
      *  thunk: it removes the entry only while it still holds THIS handle (a fresh sibling-leg registration
-     *  under the same id survives the old leg's teardown). Call it at LEG END, not on settle (design/122 ③). */
+     *  under the same id survives the old leg's teardown). Call it at LEG END, not on settle ([ref] ③). */
     register(runId: string, handle: SubagentSteerHandle): () => void;
     /** Resolve `runId` + `target` to its handle on this replica. Exact `parentToolCallId` match wins (unique —
      *  newest-per-id by construction → count is 0|1); otherwise match by `agentName` (count may be >1 →

package/dist/orchestration/workflow-agent-steer.d.ts

@@ -34,7 +34,7 @@ export declare class WorkflowAgentRegistry {
  *   · **「被截断过」仍有信号**:超界时正文段尾出现 `…`(未超界时不出现)⇒ 消费方能判断"这不是全文";
  *   · **「截了多少」不再披露**:`[+N chars]` 在**所有**档位都没有了(实测 +1 / +10 / +100 / +5000 / +50000
  *     全部无披露,输出长度恒 4103)。所以一个超出 5 万字符的输入与只超 1 个字符的输入,**外观完全相同**。
- *  ⚠️ core [1707]⑤ 的措辞是「**刚过界**的输入现在是裸 `…` 结尾」,而实测是**全档位**都没有披露 —— 范围比
+ *  ⚠️ core [ref]⑤ 的措辞是「**刚过界**的输入现在是裸 `…` 结尾」,而实测是**全档位**都没有披露 —— 范围比
  *  它描述的宽。已带实测数据上黑板问 core 这是否是有意的(可能只是描述省略,也可能是它没注意到)。
  *  在得到答复前**不改行为**:core 的截断器是它那侧的安全件,server 不该自己在外面补一层"+N chars"去顶
  *  ——那会变成两处各说一套。 */

package/dist/orchestration/workflow-completion-inbox.d.ts

@@ -69,7 +69,7 @@ export declare const PURGE_FENCE_MS: number;
  *  to swallow any realistic notify lag incl. a boot-recovery re-fire racing a fresh poll; per-runId scoped, so
  *  it can never starve a DIFFERENT workflow's push. In-memory only (see {@link PURGE_FENCE_MS} rationale). */
 export declare const SERVED_FENCE_MS: number;
-/** design/144 §4 server 折叠键:`JSON([域, taskId, RAW status])[#seq]`。域=external 帧独立 lane(task_id 是
+/** [ref] §4 server 折叠键:`JSON([域, taskId, RAW status])[#seq]`。域=external 帧独立 lane(task_id 是
  *  调用方自由串,不分域可预占内部帧键把真实子代 settle 帧吞掉)/其余内部帧统一 "task" 域。
  *
  *  三路复审修1(MED):status 保留 RAW,不再归一 completed/failed —— 归一让同 id 无 seq 的两条 external
@@ -91,15 +91,15 @@ export declare function taskNotificationFoldKey(n: {
     status: string;
     seq?: number;
 }): string;
-/** design/144 stream 侧去重键(core [784]④a + codex 1.189 前双审 F2)= `域:taskId:status[#seq]`。
+/** [ref] stream 侧去重键(core [ref]④a + codex 1.189 前双审 F2)= `域:taskId:status[#seq]`。
  *  与 {@link taskNotificationFoldKey} 同族,域二分也一致(codex F2 HIGH:external 通知的 task_id 是
  *  POST /v1/sessions/:id/notify 调用方自由串——同一条腿上,drain 出的 external 帧可与内部任务帧同形
  *  `task_id:status:seq` 撞键互吞,per-leg 键集并不豁免这个面,旧注释「没有跨调用方预占面」判错);
  *  仍与 fold key 有意不同的一点:status 保留 RAW(killed/cancelled/event 不归一 failed)——归一会让同
  *  task 的 Monitor event 批与 failed 终态在一条腿上互吞;wire 去重要的是逐帧身份,不是 inbox 的双终态列。
  *  `seq` 折入 = 停→唤→停的第二周期同 status 帧各自成键(core 1.283 起 background_agent 四腿 notify 铸
- *  cycleSeq;缺 seq 时旧键曾把二周期 completed 帧在 observer 臂反向吞掉——core [784]④a);无 seq 的帧
- *  (bash/monitor terminal/retain 降级)保持单周期旧键=同键第二帧吞,诚实语义。[2373]B-10:core 4.0.0 起
+ *  cycleSeq;缺 seq 时旧键曾把二周期 completed 帧在 observer 臂反向吞掉——core [ref]④a);无 seq 的帧
+ *  (bash/monitor terminal/retain 降级)保持单周期旧键=同键第二帧吞,诚实语义。[ref]B-10:core 4.0.0 起
  *  task_type 是必填闭合枚举——`task_type?` 可选性**不再对应旧 core 帧**,它活着只为家族前缀构造
  *  (server.ts fleet 腿 `taskNotificationFoldKey({task_id,status})` 同款用法);缺席归 "task" 域的语义
  *  只在前缀用途下生效。external 帧三来源齐备(notify 端点 core 铸 / inbox entry extras 存 / drain 帧
@@ -257,7 +257,7 @@ export declare function taskNotificationInboxEntry(sessionId: string, owner: str
         edits: number;
     }>;
     resumable?: boolean;
-    /** core 1.353([1412]):诊断槽(journal 坐标+教句,引擎值单源)——park 透传,drain 帧原样带。 */
+    /** core 1.353([ref]):诊断槽(journal 坐标+教句,引擎值单源)——park 透传,drain 帧原样带。 */
     diagnostics?: string;
 }, enqueuedAt: number, 
 /** lead-b (dual-ID audit): the PARENT run's durable taskId (the uuid the shell's footer rows
@@ -265,7 +265,7 @@ export declare function taskNotificationInboxEntry(sessionId: string, owner: str
  *  parent row without a side lookup. */
 parentTaskId?: string, 
 /**
- * design/373 §3.6(core 5.61.0,#366 / codex R1[high]):core 在 `onTaskNotification` 的**第二参**上报的
+ * [ref] §3.6(core 5.61.0,[ref] / codex R1[high]):core 在 `onTaskNotification` 的**第二参**上报的
  * 投递档位。park 是**跨 run** 的那条投递路径 —— 不带过去,档位就在最常走的一条路上恒缺席。
  *
  * 🔴 只在 core **真的给了**档位时传:缺席原样缺席(与 live 投影同一条「缺席≠later」纪律)。

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

@@ -152,7 +152,7 @@ export declare class WorkflowNotifyGate {
      *
      * BOTH abandoned arms (boot-orphan + stale-past-grace) flip the DURABLE row to `failed` FIRST (CAS on rev),
      * so the run store, the fleet panel and the delivered notify give ONE answer — previously the notify said
-     * `failed` while `/workflows` kept saying `running` forever ([2999]: republishing without finalizing would
+     * `failed` while `/workflows` kept saying `running` forever ([ref]: republishing without finalizing would
      * have turned "panel empty" into "panel shows a row that never moves"). A lost CAS means the run moved under
      * the sweep (e.g. its real terminal landed concurrently) — skip this pass; the entry stays pending and the
      * next sweep handles the NEW state.
@@ -175,14 +175,14 @@ export declare class WorkflowNotifyGate {
         /** Replica-local (File/in-memory) journal ONLY: a pending entry recorded BEFORE this timestamp belongs to
          *  a previous incarnation of THIS process — workflow executors are in-process, so they died with it and a
          *  still-`running` run is a boot-orphan: finalize it NOW instead of leaving the user's "Waiting for
-         *  workflow" pointed at a run that can never finish for the whole grace window ([2995] 顺带①/[3000]§二).
+         *  workflow" pointed at a run that can never finish for the whole grace window ([ref] 顺带①/[ref]§二).
          *  NEVER pass this for a cross-replica (SQL) journal — there a pending running run may be genuinely alive
          *  on another replica, and age (`orphanGraceMs`) is the only sound orphan proxy.
          *  ⚠️ This wall-clock cutoff is a NECESSARY, not sufficient, condition — {@link recordedThisIncarnation}
          *  is the authoritative one (a clock rollback after boot would otherwise stamp THIS process's own new
          *  entries below the cutoff and finalize live runs). */
         finalizeStartedBeforeMs?: number;
-        /** Retire a fleet row for a run this sweep just finalized ([2995]/[2999]): called ONLY with a TERMINAL run,
+        /** Retire a fleet row for a run this sweep just finalized ([ref]/[ref]): called ONLY with a TERMINAL run,
          *  so the {@link JournalingWorkflowRunStore} projection publishes the final frame and then removes the row —
          *  the store, the panel and the notify end up saying the same thing. Never called with a `running` run (see
          *  the single-writer invariant above). Late-bound because the wrapper is constructed after this gate. */
@@ -264,7 +264,7 @@ export declare class InMemoryWorkflowNotifyJournalStore implements WorkflowNotif
  */
 export declare class JournalingWorkflowRunStore implements WorkflowRunStore {
     private readonly inner;
-    /** [1262] optional since the fleet decoupling: undefined ⇒ no start-time journal (ephemeral memory
+    /** [ref] optional since the fleet decoupling: undefined ⇒ no start-time journal (ephemeral memory
      *  backend has nothing to recover), the FLEET half still publishes — the panel is replica-local UI
      *  state and must not be gated on the durable-notify machinery (the regression that emptied clay's
      *  workflow panel on memory-backend deployments). */
@@ -273,7 +273,7 @@ export declare class JournalingWorkflowRunStore implements WorkflowRunStore {
      *  point as the notify journal). Optional — undefined ⇒ no fleet publish. */
     private readonly fleetBus?;
     constructor(inner: WorkflowRunStore, 
-    /** [1262] optional since the fleet decoupling: undefined ⇒ no start-time journal (ephemeral memory
+    /** [ref] optional since the fleet decoupling: undefined ⇒ no start-time journal (ephemeral memory
      *  backend has nothing to recover), the FLEET half still publishes — the panel is replica-local UI
      *  state and must not be gated on the durable-notify machinery (the regression that emptied clay's
      *  workflow panel on memory-backend deployments). */
@@ -284,7 +284,7 @@ export declare class JournalingWorkflowRunStore implements WorkflowRunStore {
     /** Derive + publish the MF-Fleet workflow row from a WorkflowRun (doneCount/totalCount from agents, tokens from
      *  stats); a terminal workflow LEAVES the fleet (publish terminal then remove), a running one stays/updates. */
     private publishFleet;
-    /** [2995] recovery projection seam: the same fleet projection as the put/update observation points, exposed so
+    /** [ref] recovery projection seam: the same fleet projection as the put/update observation points, exposed so
      *  the recovery sweep can RETIRE a row for a run it just finalized (terminal input ⇒ final frame, then remove).
      *  Wire it as `recover`'s `publishTerminalFleetRow` hook — and only ever hand it a TERMINAL run: a `running`
      *  row published from outside the wrapper's own write path has no guaranteed retirement (see the invariant on

package/dist/parent-watch.d.ts

@@ -1,5 +1,5 @@
 /**
- * #219(黑板 [3617]):引擎 **parent 监视**。
+ * [ref](黑板 [ref]):引擎 **parent 监视**。
  *
  * ## 防的是什么
  *

package/dist/parked-decide.d.ts

@@ -1,6 +1,6 @@
 /**
  * 件3d `/decide` 消费 parked 后台子代——server 半场辅件(设计稿:sema-internal
- * server/docs/DECIDE-PARKED-DESIGN.md;黑板 [1587];core 裁定 [1574]/[1584])。
+ * server/docs/DECIDE-PARKED-DESIGN.md;黑板 [ref];core 裁定 [ref]/[ref])。
  *
  * 本模块先落判别器:`POST /v1/approvals/:sessionId/decide` 路由在既有 session→token 映射拿到
  * pending checkpoint 后,用它判定该 cp 是否属于一个 parked 后台子代——命中则走 claim →
@@ -37,18 +37,18 @@ export interface ParkedDecideDeps {
     /** 与 reaper/scenarios 同一个 registry(claim/rollback 的 CAS 与 in-memory handle 收敛在同处)。 */
     registry: Pick<TaskRegistry, "claimParkedAgent" | "rollbackParkedClaim">;
     /** boot 期从生产装配(buildScenarios)取的裸 Agent ToolSpec——与 spawn 用同一装配路径,
-     *  subRunner/bg opts/checkpointStore 同实例天然成立([1587] 设计稿 §4)。 */
+     *  subRunner/bg opts/checkpointStore 同实例天然成立([ref] 设计稿 §4)。 */
     reviveTool: ToolSpec;
-    /** revive args 的 `subagent_type` 成员性判定集([1588] Q1 修正:非 roster 成员必须省略,否则
+    /** revive args 的 `subagent_type` 成员性判定集([ref] Q1 修正:非 roster 成员必须省略,否则
      *  unknown subagent_type 拒;字面比对 general-purpose 在 roster 撞名时会错省)。缺省空集=恒省略。 */
     knownAgentTypes?: ReadonlySet<string>;
-    /** [1596]/[1597] 跨进程父约束重供席:按部署配置**重建的同语义**父策略链工厂(host 任务的 toolPolicy
+    /** [ref]/[ref] 跨进程父约束重供席:按部署配置**重建的同语义**父策略链工厂(host 任务的 toolPolicy
      *  解析槽一条,单层链;exempt 探针锚= row.rootSessionId,与 remember grant 锚同键)。core 1.396 起
      *  `parkedResume.inheritedGate` 席位把它透传进 resume 的官方重供通道——不供 = 重启后带
      *  requiresParentConstraint 的 checkpoint 恒被 pre-CAS 门拒(retryable 假话,永不可赎回)。链长形状
      *  校验在 core(fail-closed,供错链长照拒)。
      *
-     *  ⚠️ **async**(A-010.1):重建条目的第三位决议链元数据 `autoModeArmed` 与 `durableMandate` 的
+     *  ⚠️ **async**([ref]):重建条目的第三位决议链元数据 `autoModeArmed` 与 `durableMandate` 的
      *  `forceDurableGate` 项都要按**本行的 principal** 现解 entitlement(`RunnerDeps.runtimeCapsResolver`
      *  本身就是 sync-or-async 的座),理由全在 `boot/parked-revive-gate.ts`。本腿一直就在 async 里,
      *  「席位必须同步」是那个文件此前自设的约束、不是结构事实。 */
@@ -64,7 +64,7 @@ export interface ParkedDecideRequest {
     /** cp.pendingAction 原样(outcome 铸造的 persisted 回落源,与 legacy 腿 D-1 姿势逐字同形)。 */
     pendingAction: unknown;
     decision: "approve" | "deny";
-    /** #204 件6③ core `ApprovalSettledBy`:**这次结算的出处**,由调用方命名(必填,理由与 legacy 腿
+    /** [ref] 件6③ core `ApprovalSettledBy`:**这次结算的出处**,由调用方命名(必填,理由与 legacy 腿
      *  `resumeCheckpoint` 的同名参数逐字同源 —— 本函数分辨不出谁在叫它,漏报要是编译错而不是假出处)。
      *  今天唯一的调用方是 `server.ts` 的人为 `/decide`(那道门写着 `req !== undefined`,而内部 D-D SLA
      *  deny-sweep 恰是 req 缺席的那条腿,它对 parked 行另有静默跳过臂)⇒ 恒 `"human"`。 */
@@ -77,14 +77,14 @@ export interface ParkedDecideRequest {
         boundInputHash?: string;
         updatedInput?: unknown;
     };
-    /** body 带了 `remember:"session"` 时路由传入的 grant 执行器([1591] 候裁② 的 server 侧修,经两轮
+    /** body 带了 `remember:"session"` 时路由传入的 grant 执行器([ref] 候裁② 的 server 侧修,经两轮
      *  行为探针实证):豁免必须锚在**行的 root/host 会话 id**——部署侧三个豁免探针(policy 层/fs-write
      *  门/workflow 门)的闭包统一捕获 host 会话键且签名不携身份(1.393 seam 亲读:`sourceTaskId` 只在
      *  onAsk 层的 AskRequest,durable 车道无 onAsk),grant 落子代会话则键永不相交(G-F4 原案);落
      *  root 会话则宿主键闭包立即命中,复活子代的后续同工具 ask 被短路(探针 v2 实证),语义与同步车道/
      *  宿主任务的「本会话不再询问」一致(= host 会话树全域)。行无 root 锚(病态形)⇒ claim 前诚实 400。 */
     grantRemember?: (rootSessionId: string) => Promise<void>;
-    /** RB-459(core 5.7.0,F6 翻案):AskUserQuestion 的 approve 携操作员答案——原样透传进
+    /** [ref](core 5.7.0,F6 翻案):AskUserQuestion 的 approve 携操作员答案——原样透传进
      *  `ResumeOutcome.answer`(形状校验在路由层 isQuestionAnswer;header 逐字匹配等语义校验在 core,
      *  server 不预判)。core 拒绝形:同步腿 409 invalid_outcome field:"answer",parked 腿经 drive 失败
      *  面 422 parked_resume.startup_failed。 */
@@ -98,16 +98,16 @@ export interface ParkedDecideResult {
     body: Record<string, unknown>;
 }
 /**
- * `/decide` parked 赎回腿(design/153 件3d server 半场;[1574]/[1584]/[1588] core 裁定形)。
+ * `/decide` parked 赎回腿([ref] 件3d server 半场;[ref]/[ref]/[ref] core 裁定形)。
  *
  * 返回 `undefined` = 该 pending checkpoint 不属于任何 parked 后台子代——调用方走既有任务级
  * resumeCheckpoint 腿(零回归);返回结果对象 = 赎回腿已受理/已拒,调用方直接回 HTTP。
  *
  * 链:判别(findParkedAgentForCheckpoint)→ `claimParkedAgent`(access = 行镜像双轴
- * `{scope: row.scope, owner: row.owner}`,[1588] Q3)→ outcome 铸造(D-1 echo/persisted 回落)
+ * `{scope: row.scope, owner: row.owner}`,[ref] Q3)→ outcome 铸造(D-1 echo/persisted 回落)
  * → 裸 `reviveTool.execute(args, ctx.reviveClaim)`。execute 一旦发起 drive,rollback 全在 core 内
  * (driveParkedResume);server 只在「claim 成功但 drive 从未发起」窗口补 `rollbackParkedClaim`
- * ([1588] Q2:isError 入参级早退 + throw 两形,已核幂等/双滚=无害 lost)。
+ * ([ref] Q2:isError 入参级早退 + throw 两形,已核幂等/双滚=无害 lost)。
  *
  * 200 是**受理**语义(drive 是 core 内 fire-and-forget):失败经行/notification 面 + REOPENED
  * re-park 诚实可见,操作员可再决。

package/dist/plan-cache-probe.d.ts

@@ -1,6 +1,6 @@
 /**
  * Plan-cache recurrence probe — INSTRUMENT-FIRST (search AI → service, 团队/给service-AI.md [1];
- * core design/42). Zero-LLM, zero-dependency, pure in-memory.
+ * core [ref]). Zero-LLM, zero-dependency, pure in-memory.
  *
  * Measures the **per-scope recurrence rate of task objectives**: the unproven "省钱" premise behind a
  * proposed core *plan-caching* feature (store a successful run's generalized plan → a similar new task

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

@@ -1,5 +1,5 @@
 /**
- * design/183 I2(form b 位)—— **SQL 收编日志**:phase 真源与被迁的行**同库**。
+ * [ref] I2(form b 位)—— **SQL 收编日志**:phase 真源与被迁的行**同库**。
  *
  * 🔴 为什么 phase 必须住 SQL 而不是一个 sidecar 文件(183 r3 按 codex r2-F2):发起收编的那个 pod 在两条
  * 腿之间被摧毁时,进程本地的标记会与已经半迁移的 SQL 状态**分家** —— 接棒副本读不到「迁到哪了」。
@@ -118,7 +118,7 @@ export declare function ensurePgAdoptionLogSchema(q: (text: string, params?: unk
  */
 export declare function adoptionLockName(fromPrincipal: string): string;
 /**
- * 把弧锁名限定到**一个库**的键空间(A-010.13,验真后修)。
+ * 把弧锁名限定到**一个库**的键空间([ref],验真后修)。
  *
  * 🔴 病:两条腿的锁键空间**不等价**。MySQL/TiDB 的 `GET_LOCK` 名字是**服务器实例全局**的
  * (`performance_schema.metadata_locks` 里就是一个进程级命名空间,与你连的是哪个 schema 无关);
@@ -199,7 +199,7 @@ export declare class SqlAdoptionLogStore implements AdoptionLogStore {
     /** 目的地冲突 ⇒ rejected 终态(源/目的地两侧字节零变更;phase 停在 INTENT)。 */
     finalizeRejected(adoptionId: string, code: AdoptionRejectCode, detail: string, nowMs: number, exec?: SqlExec): Promise<boolean>;
     /**
-     * 本连接所在**数据库**的名字 = 弧锁的键空间限定符(A-010.13,理由见 {@link qualifyAdoptionLockName})。
+     * 本连接所在**数据库**的名字 = 弧锁的键空间限定符([ref],理由见 {@link qualifyAdoptionLockName})。
      *
      * 在**交出来的那条连接**上问(不向池要第二条 —— 弧全程单连接,见 `AdoptionLogStore.getById` 的注),
      * 结果缓存在店上:库名在一条驱动的生命周期里不会变,而每次取锁多打一个往返是白付的。
@@ -217,7 +217,7 @@ export declare class SqlAdoptionLogStore implements AdoptionLogStore {
      * 返回 `undefined`,调用方按「在飞」应答 —— **不假装成功,也不无限等**。
      *
      * 🔴 入参 `name` 是**逻辑**锁名(`adoptionLockName(fromPrincipal)`);真正发给引擎的是它被
-     * {@link qualifyAdoptionLockName} 限定到本库之后的形(A-010.13:两方言键空间不等价)。限定发生在
+     * {@link qualifyAdoptionLockName} 限定到本库之后的形([ref]:两方言键空间不等价)。限定发生在
      * **这里**而不是调用方,因为「键空间是每库还是每实例」是**存储层**的知识,协议层(runner)不该知道。
      */
     withLock<T>(name: string, fn: (conn: SqlTxConn) => Promise<T>, attempts?: number, sleepMs?: number): Promise<T | undefined>;

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

@@ -1,5 +1,5 @@
 /**
- * `InMemoryApprovalAskStore` —— #151 车1,`ApprovalAskStore` 的语义真源(twin 对拆基准)+ LOCAL
+ * `InMemoryApprovalAskStore` —— [ref] 车1,`ApprovalAskStore` 的语义真源(twin 对拆基准)+ LOCAL
  * 车道占位(File 形不在本车,见设计定稿 §7)。单进程内两个 `Map`,方法体全同步(不含 `await` 中断点)——
  * Node 单线程下这就是天然原子:`Promise.all` 发起的并发调用不会在方法体内部交错执行,与
  * `approval-ask-store-sql.ts` 的 CAS UPDATE 语义逐字段一致(SQL twin 对拆套件的基准就是这份实现）。

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

@@ -105,12 +105,24 @@ export class InMemoryApprovalAskStore {
                 }
             }
         }
+        let encodedUpdatedInput;
+        if (decision.updatedInput !== undefined) {
+            const text = JSON.stringify(decision.updatedInput);
+            if (text === undefined)
+                throw new Error("approval-ask-store(memory): updatedInput is not JSON-encodable (encodes to nothing) — the SQL twin cannot hold it either");
+            const decoded = JSON.parse(text);
+            encodedUpdatedInput = decoded;
+        }
         batch.rev += 1;
         batch.updatedAtMs = now;
         ask.state = "DECIDED";
         ask.decision = decision.decision;
         ask.decisionActor = decision.decisionActor ?? null;
         ask.decisionNote = decision.decisionNote ?? null;
+        if (decision.updatedInput === undefined)
+            delete ask.updatedInput;
+        else
+            ask.updatedInput = encodedUpdatedInput;
         ask.decidedAtMs = now;
         ask.idempotencyKey = decision.idempotencyKey ?? null;
         ask.rev += 1;

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

@@ -1,6 +1,6 @@
 /**
- * 流内审批协议(design/172 v3.1 §3.0/§3.1/§3.2)持久层 —— #151 车1,`ApprovalAskStore` 双方言实现
- * (`TiDBApprovalAskStore` / `PgApprovalAskStore`,SINGLE-FILE DUAL-DIALECT,design/158 A12 形——照
+ * 流内审批协议([ref] v3.1 §3.0/§3.1/§3.2)持久层 —— [ref] 车1,`ApprovalAskStore` 双方言实现
+ * (`TiDBApprovalAskStore` / `PgApprovalAskStore`,SINGLE-FILE DUAL-DIALECT,[ref] A12 形——照
  * checkpoint-store-sql.ts:一个 `SqlApprovalAskStore` 类接 `SqlDriver`,两个薄 ctor 子类落方言绑定)。
  *
  * 两张表:`approval_ask`(每个流内工具调用一行,ask 级 6 态状态机)+ `approval_batch`(同一决策点的
@@ -19,7 +19,7 @@
  *    对被更新行本身恒是 current read,不受 REPEATABLE READ 快照影响),所以走普通 `begin()`,不需要
  *    `beginPessimistic()`。
  *
- * ── 方言差异(显式写在每个调用点,design/158 A12 doctrine)──────────────────────────────────────────
+ * ── 方言差异(显式写在每个调用点,[ref] A12 doctrine)──────────────────────────────────────────
  *   - `?` 占位符(位置序)vs `$n`(显式编号)——动态列清单(`transitionAsk`/`resolveProvisional`,列集合
  *     依 patch 内容变化)靠 `ph(dialect, n)` 生成两种占位符文本,与 background-agent-store-sql.ts 的
  *     `updateIf` guard 占位符构造同精神(那里也是「列集合动态、占位符文本仍显式按方言生成」)。
@@ -60,7 +60,7 @@ export interface AskRow {
      * 与下面 PARKED 坐标里的 `gateBoundInputHash` 是**两件不同的东西**,别混:
      *   - `boundInputHash`(本列)= ask **铸行时**的入参摘要,一次写定永不改;对账收敛器判据 1 用它跟
      *     checkpoint 行的同名列做**硬相等**——它是**身份三元组之外的第二道等式**,身份本身是
-     *     (`sourceTaskId`, `toolCallId`, 因果下界)三维(#168 件1 换轴,判据属主 = `approval-reconciler.ts`
+     *     (`sourceTaskId`, `toolCallId`, 因果下界)三维([ref] 件1 换轴,判据属主 = `approval-reconciler.ts`
      *     的 `classifyGateMatch`;本注上一版写的「identity 四元组」是换轴前的旧口径,`sessionId` 从来不是
      *     内存判据维)。任一侧缺席 ⇒ 判据 1 **不命中**;归因看走到哪一层:身份先判(候选集非空却没有同身份
      *     的一条 ⇒ `identity_miss`),身份这层还够得着时缺席才记 `single_mint`(禁「能取到时才比」的可选谓词
@@ -78,6 +78,24 @@ export interface AskRow {
     /** 171 ActorAssertion JSON(车4 才消费,列先在——JSON.parse 后的裸值,类型未知)。 */
     decisionActor: unknown | null;
     decisionNote: string | null;
+    /**
+     * [ref]([ref] / [ref] 收口):人批准时带的 **ctrl+g 编辑实参**(wire `updatedInput`),与决议**同一条
+     * UPDATE** 原子落列 `updated_input`。语义三态,读法**严格**:
+     *  · `undefined`(列 NULL)= 这次决议**没带**编辑 —— 回放腿交裸 `true`,core 按原始实参执行;
+     *  · 任何其它值(**含 `null`**,列存 JSON 文本 `"null"`)= 带了编辑的**字面值**,回放腿交
+     *    `{ allow: true, updatedInput }`,core 按它执行。「编辑成 null」与「没编辑」在 wire 上是两回事
+     *    (`hasUpdatedInput` 读的是键在场),店面照此分家;消费端**禁**用 `?? ` / `== null` 折叠。
+     *  · deny 行恒 `undefined`:deny 带 `updatedInput` 的成文语义是「宽收后忽略」,写口不落。
+     *
+     * 为什么必须是行上的一列(census 第 31 行 P-DEBT 的终局件):行派生的 approve 回放(幂等重入 / 收敛臂 /
+     * 店报错臂 / 迟到受理 / 悬挂轮询 / HTTP 观察者,六站点)此前只能交裸 `true` ⇒ core 的
+     * `d.updatedInput === undefined` 分支落回**原始未改写**实参执行 —— 人批的是改写后的命令、真跑的是原
+     * 命令 = 执行面宽于人所批准。列在,行即真源,六站点从行上读同一份编辑。
+     *
+     * 🔴 LONGTEXT/TEXT 存 JSON 文本(与同表 `decision_actor` / `card_json` 同款,`dialectJsonEncoder` 编码、
+     * `parseJsonColumn` 读回):编辑实参是整只工具入参,与 `card_json` 同量级,VARCHAR 会造静默截断面。
+     */
+    updatedInput?: unknown;
     decidedAtMs: number | null;
     deniedReason: string | null;
     /** PARKED 坐标三件。 */
@@ -95,7 +113,7 @@ export interface AskRow {
     /** 重放腿的帧载荷(args 已帽已洗后的投影)。 */
     cardJson: unknown;
     /**
-     * #363 —— **规则车道素材**两列之一:这只 ask 被裁决的**命令**(已过基础脱敏,见 `tool-approval.ts`
+     * [ref] —— **规则车道素材**两列之一:这只 ask 被裁决的**命令**(已过基础脱敏,见 `tool-approval.ts`
      * 的落盘点)。`null` = 这只 ask 从没进过规则车道(治理档 / 无属主 / 引擎没铸候选 / args 读不出命令),
      * 或它由**加这两列之前**的构建落的行。
      *
@@ -109,8 +127,8 @@ export interface AskRow {
      */
     ruleCommand: string | null;
     /**
-     * #363 —— 规则车道素材两列之二:**授权发生地**的 project root(`ruleScopeRootFor` 在**铸卡时**咨询
-     * 的那一份,#295 F-1 的快照语义)。`null` = 解析不出 root ⇒ 兑付时**不铸 scope**,core 落 global
+     * [ref] —— 规则车道素材两列之二:**授权发生地**的 project root(`ruleScopeRootFor` 在**铸卡时**咨询
+     * 的那一份,[ref] F-1 的快照语义)。`null` = 解析不出 root ⇒ 兑付时**不铸 scope**,core 落 global
      * (= live 腿逐字同形;绝不在坐标系不明时编一个 root)。
      */
     ruleScopeRoot: string | null;
@@ -134,17 +152,17 @@ export interface NewAskRow {
     /** 车5 §9 C2 的对账 join 键(语义见 `AskRow.boundInputHash`)。缺席 ⇒ 该行结构上永不满足判据 1。 */
     boundInputHash?: string | null;
     cardJson: unknown;
-    /** #363 规则车道素材(语义与「为什么是行上的列」见 {@link AskRow.ruleCommand})。缺席 ⇒ 列 NULL ⇒
+    /** [ref] 规则车道素材(语义与「为什么是行上的列」见 {@link AskRow.ruleCommand})。缺席 ⇒ 列 NULL ⇒
      *  这条行上的迟到决议对 `persistRule` 响亮拒(`rule_material_absent`),绝不猜命令。 */
     ruleCommand?: string | null;
-    /** #363 授权发生地(语义见 {@link AskRow.ruleScopeRoot})。 */
+    /** [ref] 授权发生地(语义见 {@link AskRow.ruleScopeRoot})。 */
     ruleScopeRoot?: string | null;
     schemaVersion: number;
     expiresAtMs: number;
     createdAtMs: number;
 }
 /**
- * `ensureAsk` 的产出 —— 行 **+ 这一次调用到底插没插**(#168 件2)。
+ * `ensureAsk` 的产出 —— 行 **+ 这一次调用到底插没插**([ref] 件2)。
  *
  * 🔴 为什么判别位必须由**店**给:`ensureAsk` 是幂等 upsert(`askId` 是确定性派生,重试 / failover /
  * 闭包再入天然指向同一行),所以「拿到一条 STREAM_PENDING 行」有两种成因 —— 本次插的,或幂等命中了
@@ -180,6 +198,10 @@ export interface DecideAskInput {
     decisionNote?: string | null;
     /** 车4 §12-E:回决幂等键,赢 CAS 时随决议一起落列(见 `AskRow.idempotencyKey`)。缺席 ⇒ 列保持 NULL。 */
     idempotencyKey?: string | null;
+    /** [ref]:ctrl+g 编辑实参,与决议同一条 UPDATE 落列(语义三态见 {@link AskRow.updatedInput})。
+     *  缺席 / `undefined` ⇒ 列 NULL(没带编辑);**`null` 是值**(编辑成 null),照存 JSON `"null"`。
+     *  调用方纪律:deny 不传(店不替调用方判决议方向,写什么存什么)。 */
+    updatedInput?: unknown;
 }
 /**
  * `idempotency_conflict`(车4 §12-E):同一 (task_id, idempotency_key) 已被**另一条** ask 的回决占用。
@@ -206,7 +228,7 @@ export type DecideResult = {
  */
 export declare function assertIdempotencyKeyShape(key: string): void;
 /**
- * #151 车3 刀 3b(§14.2 遗留记账):两条**重放读口**被调用方的 deadline 掐断时抛的具名错误。
+ * [ref] 车3 刀 3b(§14.2 遗留记账):两条**重放读口**被调用方的 deadline 掐断时抛的具名错误。
  *
  * 具名类而不是「按 message 文本判别」:错误文案是给人看的,拿它当控制流 = 上游改一句人话下游静默失效
  * (#90 工程规范 v3 门②)。调用方(开流 preamble)对它的处置与其余读错误一样 —— fail-open、零卡、一次
@@ -323,7 +345,7 @@ export declare const APPROVAL_BATCH_TABLE = "approval_batch";
  * SCHEMA POLICY 同 `tidb-pool.ts` 头注:纯 CREATE,禁 ALTER 增量 seam,改列直接改这里 + 重建库
  * (`docs/schema/baseline-mysql.sql` 是由这些文本机器录制出的**产物**,永不手改)。
  *
- * ── 列宽的**测量依据**(#192 A10;U2 逐列取证在档)──────────────────────────────────────────────────
+ * ── 列宽的**测量依据**([ref] A10;U2 逐列取证在档)──────────────────────────────────────────────────
  * 本表家族原先一律 VARCHAR(255),是"先建表后想"的产物。按"每列的值到底由谁铸、有没有入口上限"重新裁:
  *
  *  收窄(有硬上限背书,证据即上限本身):
@@ -363,8 +385,8 @@ export declare const TIDB_APPROVAL_ASK_STATEMENTS: readonly string[];
 export declare function ensureTiDBApprovalAskSchema(pool: MySqlPool): Promise<void>;
 export declare function ensurePgApprovalAskSchema(q: PgQueryFn): Promise<void>;
 /**
- * #363 升级前置断言 —— **拒启**,不是 warn(形照 #340 的 `assertPermissionRuleApprovalSchema` /
- * #119 的 `assertToolResultProvenanceSchema` 两条先例)。
+ * [ref] 升级前置断言 —— **拒启**,不是 warn(形照 [ref] 的 `assertPermissionRuleApprovalSchema` /
+ * [ref] 的 `assertToolResultProvenanceSchema` 两条先例)。
  *
  * 病:本仓不发 `ALTER TABLE`(SCHEMA POLICY:改列就改 CREATE + 删库重建)。于是一台**没删表**就升上来
  * 的部署,`CREATE TABLE IF NOT EXISTS` 对存量 `approval_ask` 是空操作 —— 本车新加的
@@ -373,11 +395,11 @@ export declare function ensurePgApprovalAskSchema(q: PgQueryFn): Promise<void>;
  *  · 每一只 ask 的 `ensureAsk` 撞 unknown column ⇒ 被 `noteStoreError` 吞掉 ⇒ 整只 ask 退回 park 路由
  *    (卡不落库、`GET /v1/approvals` 的重放面恒空、迟到决议腿恒 404);
  *  · 而 `/v1/capabilities` 的 `streamApproval` 仍然报 active ⇒「says yes ⟺ route works」整句为假。
- * 没有这道断言,运维得不到**任何**「这次升级必须重建表」的信号 —— 正是 #157「禁静默降级」要挡的形。
+ * 没有这道断言,运维得不到**任何**「这次升级必须重建表」的信号 —— 正是 [ref]「禁静默降级」要挡的形。
  *
  * 判据 = **能力探测**(恒空的 `WHERE 1=0` 读)+ **方言的缺列错误码**(判据属主 `sql-errors.ts` 的
  * {@link isMissingColumnError});其余错误**原样 rethrow**,一个字都不加工 —— 一句破坏性的
- * 「去 DROP TABLE」指路比它要挡的缺陷更贵(#340 那两轮收窄的结论逐字继承)。
+ * 「去 DROP TABLE」指路比它要挡的缺陷更贵([ref] 那两轮收窄的结论逐字继承)。
  *
  * 🔴 位置与两条先例同款:**不在** `ensureSchema` 里(那条通道的契约是「只发 CREATE」,有运行时门看着),
  * 放在 DDL 之后、任何路由装配之前;且**只在流内审批协议真会上场时**跑(判据 = 与协调器同一个符号
@@ -392,7 +414,7 @@ export declare class SqlApprovalAskStore implements ApprovalAskStore {
     constructor(db: SqlDriver);
     private q;
     private json;
-    /** 唯一键冲突判别 —— 判据属主 = `sql-errors.ts`(A-032 P1-①)。`decideAsk` 用它把 `(task_id,
+    /** 唯一键冲突判别 —— 判据属主 = `sql-errors.ts`([ref] P1-①)。`decideAsk` 用它把 `(task_id,
      *  idempotency_key)` 撞键翻成 typed 的 `idempotency_conflict` 臂,不让驱动错误对象漏给消费层;
      *  旧形 tidb 臂只认 errno,只带 `code` 的驱动错误会漏判成"真障碍"。 */
     private isDupKey;

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

@@ -71,6 +71,10 @@ export const TIDB_APPROVAL_ASK_STATEMENTS = [
     decision VARCHAR(16) NULL,
     decision_actor TEXT NULL,
     decision_note TEXT NULL,
+    -- updated_input(S-26 / #304,A-054.15 收口):人批准时带的 ctrl+g 编辑实参,JSON 文本,与决议同一条
+    -- UPDATE 原子落列;NULL = 没带编辑(与 JSON "null" = 编辑成 null 分家)。LONGTEXT 照 card_json 先例:
+    -- 编辑实参是整只工具入参,VARCHAR/TEXT 会造静默截断面。语义三态与读法见 AskRow.updatedInput 顶注。
+    updated_input LONGTEXT NULL,
     decided_at_ms BIGINT NULL,
     denied_reason VARCHAR(64) NULL,
     gate_token VARCHAR(120) NULL,
@@ -140,6 +144,8 @@ export async function ensurePgApprovalAskSchema(q) {
     decision VARCHAR(16) COLLATE "C",
     decision_actor TEXT COLLATE "C",
     decision_note TEXT COLLATE "C",
+    -- updated_input(S-26 / #304)—— MySQL 孪生逐字同形(语义/类型理由见那侧行内注;PG TEXT 无长度上限)。
+    updated_input TEXT COLLATE "C",
     decided_at_ms BIGINT,
     denied_reason VARCHAR(64) COLLATE "C",
     gate_token VARCHAR(120) COLLATE "C",
@@ -165,15 +171,16 @@ export async function ensurePgApprovalAskSchema(q) {
 }
 export async function assertApprovalAskRuleMaterialSchema(query, dialect) {
     try {
-        await query(`SELECT rule_command, rule_scope_root FROM ${APPROVAL_ASK_TABLE} WHERE 1=0`);
+        await query(`SELECT rule_command, rule_scope_root, updated_input FROM ${APPROVAL_ASK_TABLE} WHERE 1=0`);
     }
     catch (err) {
         if (!isMissingColumnError(err, dialect))
             throw err;
-        throw new Error(`${APPROVAL_ASK_TABLE} is missing the #363 rule-material columns (rule_command / rule_scope_root) — refusing to start. ` +
+        throw new Error(`${APPROVAL_ASK_TABLE} is missing the #363 rule-material columns (rule_command / rule_scope_root) and/or the S-26 edited-input column (updated_input) — refusing to start. ` +
             `A parked approval's late decision can now carry \`persistRule\` ("don't ask again"), and the row is where the ` +
-            `adjudicated command and the project root of the authorization site live; every ask-row write and read names ` +
-            `both columns unconditionally, so on this table the whole in-stream approval protocol degrades silently (no card ` +
+            `adjudicated command and the project root of the authorization site live; a decision's edited input (ctrl+g) is ` +
+            `persisted on the row too, so a replica that does not hold the waiting leg replays the approved bytes; every ask-row ` +
+            `write and read names these columns unconditionally, so on this table the whole in-stream approval protocol degrades silently (no card ` +
             `is persisted, the replay list stays empty, late decisions 404) while /v1/capabilities still reports it active. ` +
             `This repository ships no ALTER TABLE migrations, so the table must be recreated: run ` +
             `\`DROP TABLE ${APPROVAL_ASK_TABLE}; DROP TABLE ${APPROVAL_BATCH_TABLE};\` on the ` +
@@ -185,7 +192,7 @@ export async function assertApprovalAskRuleMaterialSchema(query, dialect) {
     }
 }
 const ASK_COLS = "ask_id, task_id, source_task_id, session_id, owner, batch_id, tool_call_id, leg_key, parent_tool_call_id, bound_input_hash, state, " +
-    "provisional, rev, decision, decision_actor, decision_note, decided_at_ms, denied_reason, gate_token, " +
+    "provisional, rev, decision, decision_actor, decision_note, updated_input, decided_at_ms, denied_reason, gate_token, " +
     "gate_bound_call_id, gate_bound_input_hash, idempotency_key, card_json, rule_command, rule_scope_root, schema_version, expires_at_ms, " +
     "created_at_ms, updated_at_ms";
 const BATCH_COLS = "batch_id, task_id, state, bound_ask_id, rev, created_at_ms, updated_at_ms";
@@ -219,6 +226,7 @@ function mapAskRow(r) {
         decision: strOrNull(r.decision) ?? null,
         decisionActor: r.decision_actor == null ? null : parseJsonColumn(r.decision_actor),
         decisionNote: strOrNull(r.decision_note),
+        ...(r.updated_input == null ? {} : { updatedInput: parseJsonColumn(r.updated_input) }),
         decidedAtMs: numOrNull(r.decided_at_ms),
         deniedReason: strOrNull(r.denied_reason),
         gateToken: strOrNull(r.gate_token),
@@ -368,7 +376,16 @@ export class SqlApprovalAskStore {
             }
             let askRes;
             try {
-                askRes = await conn.query(this.q(`UPDATE ${APPROVAL_ASK_TABLE} SET state='DECIDED', decision=?, decision_actor=?, decision_note=?, decided_at_ms=?, idempotency_key=?, rev=rev+1, updated_at_ms=? WHERE ask_id=? AND state='STREAM_PENDING'`, `UPDATE ${APPROVAL_ASK_TABLE} SET state='DECIDED', decision=$1, decision_actor=$2, decision_note=$3, decided_at_ms=$4, idempotency_key=$5, rev=rev+1, updated_at_ms=$6 WHERE ask_id=$7 AND state='STREAM_PENDING'`), [decision.decision, decision.decisionActor == null ? null : this.json(decision.decisionActor), decision.decisionNote ?? null, now, decision.idempotencyKey ?? null, now, askId]);
+                askRes = await conn.query(this.q(`UPDATE ${APPROVAL_ASK_TABLE} SET state='DECIDED', decision=?, decision_actor=?, decision_note=?, updated_input=?, decided_at_ms=?, idempotency_key=?, rev=rev+1, updated_at_ms=? WHERE ask_id=? AND state='STREAM_PENDING'`, `UPDATE ${APPROVAL_ASK_TABLE} SET state='DECIDED', decision=$1, decision_actor=$2, decision_note=$3, updated_input=$4, decided_at_ms=$5, idempotency_key=$6, rev=rev+1, updated_at_ms=$7 WHERE ask_id=$8 AND state='STREAM_PENDING'`), [
+                    decision.decision,
+                    decision.decisionActor == null ? null : this.json(decision.decisionActor),
+                    decision.decisionNote ?? null,
+                    decision.updatedInput === undefined ? null : this.json(decision.updatedInput),
+                    now,
+                    decision.idempotencyKey ?? null,
+                    now,
+                    askId,
+                ]);
             }
             catch (err) {
                 if (this.isDupKey(err)) {

package/dist/plugins/approval-payload-fingerprint.d.ts

@@ -0,0 +1,23 @@
+/**
+ * [ref] 件1(codex R2-[high] 一)—— 决议载荷的比对指纹:`[updatedInput, answer, reason]` 三件的规范串。
+ *
+ * 为什么是指纹而不是把三件原样交出来:`updatedInput` 可能携人写的命令原文/密钥形字节,而本读口的
+ * 契约是「窄读、非凭据面」—— 交指纹够比对,也不给任何调用点把它误投上 wire 的机会。
+ *
+ * 🔴 **必须是 canonical(键序无关)**,不是裸 `JSON.stringify`(codex R3-[high] 二,验真后修):行侧那份
+ * 载荷是从 `JSON`/`JSONB` 列**回读**的,而 **PG 的 jsonb 不保留输入键序**(它按自己的规则重排)⇒ 客户端
+ * 逐字重发原 body 时,请求侧按原键序、行侧按库的键序,裸 stringify 出来的两串不等 ⇒ 一次**合法重试**
+ * 被误拒成 404。方向虽保守(不是谎报成功),但那正是本件要修的那个场景,所以指纹按**递归键排序 +
+ * 数组保序**铸(见 {@link canonicalFingerprintJson})。
+ *
+ * 缺席一律折 `null` 哨兵(不是省位):`{updatedInput: undefined}` 与「没有这个键」在本比对里是同一件事。
+ * ⚠️ 调用方**必须**按 outcome 铸点的在场规则喂参(`updatedInput` 只在 approve 上、`reason` 走真值判)——
+ * 铸点丢掉的字节行上就没有,请求侧多喂一件会把一次合法重试误判成「不同的决议」。
+ * 序列化失败(循环引用/BigInt 等)⇒ `null` = 判别不出,调用方据此拒绝回放(fail-closed)。
+ */
+export declare function approvalPayloadFingerprint(v: {
+    updatedInput?: unknown;
+    answer?: unknown;
+    reason?: string;
+}): string | null;
+//# sourceMappingURL=approval-payload-fingerprint.d.ts.map