@sema-agent/server 7.43.0 → 7.44.0

package/dist/adoption/sql.js

@@ -1,122 +1,48 @@
-/** 第 `i` 个占位符(1-based)。TiDB `?` / PG `$i` —— 这是本文件唯一的方言分岔点。 */
 export function ph(dialect, i) {
     return dialect === "tidb" ? "?" : `$${i}`;
 }
-/**
- * 目的地冲突探针(phase 0,**任何 UPDATE 之前**)。
- *
- * 判据 = 「to 侧已有的行,与 from 侧的行,是否共享同一个**逻辑键**」。逻辑键 =
- * `leg.residualKey`(该表最紧的唯一键**去掉身份轴**之后剩下的列):
- *  · `undefined` ⇒ 没有唯一键含这根轴 ⇒ 结构性无冲突,本函数不该被调用(调用方按 `undefined` 短路);
- *  · `[]`        ⇒ 唯一键**就是**这根轴(PK(scope))⇒ 两侧各有任意一行即冲突,退化成笛卡尔计数;
- *  · 非空        ⇒ 逐列相等的自连接计数。
- *
- * 参数序:`[toValue, fromValue]`。
- */
 export function buildConflictProbeSql(dialect, leg) {
     const on = (leg.residualKey ?? []).map((c) => ` AND a.${c} = b.${c}`).join("");
     return (`SELECT COUNT(*) AS n FROM ${leg.table} a, ${leg.table} b` +
         ` WHERE a.${leg.matchColumn} = ${ph(dialect, 1)} AND b.${leg.matchColumn} = ${ph(dialect, 2)}${on}`);
 }
-/**
- * 桶迁/行迁的等值 UPDATE。`columns` 里的每一列都被设成**同一个**新值(字节孪生 `*_key` 与可读列一起走),
- * 谓词打在 `matchColumn` 上。参数序:`[...新值 × columns.length, 旧值]`。
- *
- * 幂等性来自谓词本身:重跑时旧值已经不在库里 ⇒ 零行匹配 ⇒ 零行变化。
- */
 export function buildRebindSql(dialect, leg) {
     const sets = leg.columns.map((c, i) => `${c} = ${ph(dialect, i + 1)}`).join(", ");
     return `UPDATE ${leg.table} SET ${sets} WHERE ${leg.matchColumn} = ${ph(dialect, leg.columns.length + 1)}`;
 }
-/**
- * memory 族的 scope 值扫描:把「属于这个 principal 的 scope 键」从库里**读出来**,而不是用 LIKE 去猜。
- *
- * 🔴 为什么不是 `LIKE '<前缀>%'`:scope 的 tenant 段是**百分号编码**的(`user%3Aweb-demo`),而 `%` 在
- * LIKE 里是通配符 —— 不逐字符转义就会误命中别的租户的盘(**跨租户误迁**,不是性能问题)。`LEFT(col, n) = ?`
- * 是纯等值比较,没有元字符面,两方言同形。
- *
- * 参数序:`[userScope, projHead.length, projHead, userProjHead.length, userProjHead]`。
- */
 export function buildMemoryScopeScanSql(dialect, table) {
     return (`SELECT DISTINCT scope FROM ${table}` +
         ` WHERE scope = ${ph(dialect, 1)}` +
         ` OR LEFT(scope, ${ph(dialect, 2)}) = ${ph(dialect, 3)}` +
         ` OR LEFT(scope, ${ph(dialect, 4)}) = ${ph(dialect, 5)}`);
 }
-/**
- * 残留计数:某条腿上**仍挂在旧身份名下**的行数。参数序:`[fromValue]`。
- *
- * 用途见 wire.ts 的 `current.residualSourceRows`:收编不给普通写者上栅栏(183 I1 = 运维前提「引擎先停」),
- * 所以「终态之后旧身份下又长出行」是一个真实可能的形 —— 这条查询把它变成可见读数,而不是靠祈祷。
- */
 export function buildResidualCountSql(dialect, table, matchColumns) {
-    // 🔴 **一张表一条 COUNT**,谓词是该表全部身份轴的**并**(codex R3-F4):逐腿各数一次会把一条
-    // 两根轴都还带旧身份的行数成 2(background_agent 甚至能数成 3),而字段名承诺的是「行数」。
     const where = matchColumns.map((c, i) => `${c} = ${ph(dialect, i + 1)}`).join(" OR ");
     return `SELECT COUNT(*) AS n FROM ${table} WHERE ${where}`;
 }
-/**
- * `blob-rewrite` 腿的扫描:按**旧**身份值把行连同 JSON 载荷读出来。
- * 匹配面 = `matchColumn` 与 `blob.alsoMatch` 的**并**(同表两根轴都可能带旧值)。
- * 参数序:`[fromValue × (1 + alsoMatch.length)]`。
- */
 export function buildBlobScanSql(dialect, leg) {
     const blob = leg.blob;
     if (blob === undefined)
         throw new Error(`buildBlobScanSql: leg ${leg.leg} has no blob spec`);
     const cols = [...blob.pk, blob.revColumn, blob.column].join(", ");
-    // 🔴 匹配面同时收**旧值与新值**两个桶(codex R2-F1 的可见性半):投影列已经迁了、载荷还停在旧身份的
-    // 那种「劈开」行(列腿与载荷腿之间插进来的写、或上一轮扫描漏掉的行),只按旧值找是**永远找不到**的
-    // ——而那正是最危险的一类残留:黑盒上看起来已迁移。载荷里真带旧身份才会被改写,所以多扫一个桶零副作用。
     const cells = [leg.matchColumn, ...(blob.alsoMatch ?? [])];
     const match = [...cells.map((c, i) => `${c} = ${ph(dialect, i + 1)}`), ...cells.map((c, i) => `${c} = ${ph(dialect, cells.length + i + 1)}`)].join(" OR ");
     return `SELECT ${cols} FROM ${leg.table} WHERE ${match}`;
 }
-/**
- * `blob-rewrite` 腿的逐行回写。参数序:`[新载荷文本, ...pk 值]`。
- *
- * 幂等性:重跑时载荷里的身份字段已是新值 ⇒ 调用方算出的新载荷与库里逐字节相同 ⇒ 语义无操作
- * (行数可能仍报 1,故回执的行数按「**内容真变了**才计」在调用侧收窄)。
- */
 export function buildBlobWriteSql(dialect, leg) {
     const blob = leg.blob;
     if (blob === undefined)
         throw new Error(`buildBlobWriteSql: leg ${leg.leg} has no blob spec`);
     const where = blob.pk.map((c, i) => `${c} = ${ph(dialect, i + 2)}`).join(" AND ");
-    // 🔴 `AND rev = ?` = 乐观并发守卫(codex R2-F1):这三张表的正常写路径都用 rev 做 CAS,收编不许绕过。
-    // 读到的 rev 与写时不符 ⇒ `affected === 0` ⇒ 调用方响亮抛、整事务回滚,而不是把别人刚写的载荷盖掉。
-    // 🔴 `SET rev = rev + 1` 同样是承重的(codex R3-F1):只**读**不**推**这把守卫,一个在收编写入**之前**
-    // 就读到 rev=N 的正常写者,在收编提交之后仍然能以 rev=N 的 CAS 写成功,把刚迁好的载荷原样盖回旧身份
-    // —— 收编那时已经报 adopted。推进 rev 才让那些「站在过去」的写者按 OCC 的本意输掉并重试。
     return `UPDATE ${leg.table} SET ${blob.column} = ${ph(dialect, 1)}, ${blob.revColumn} = ${blob.revColumn} + 1 WHERE ${where} AND ${blob.revColumn} = ${ph(dialect, blob.pk.length + 2)}`;
 }
-/**
- * 规则桶的**整桶改键**(A-010.16)。参数序:`[newOwnerKey, toPrincipal, oldOwnerKey]`。
- *
- * `owner_key = sha256("principal:" + principal)` —— 身份在**键的 hash 原像**里,与 session_policy
- * 同族。差别在于这把键**不含逐行变量**(session_policy 的原像里还有 session_id),所以不必逐行扫出来
- * 重算:一对 (旧键, 新键) 算一次,一条等值 UPDATE 走完全表。
- *
- * `principal` 列跟着同改:它是 owner_key 的**明文原像列**(店按前者寻址、`GET /v1/rules` 的回执与运维
- * 的 `WHERE principal = …` 排查按后者读)。只改一列,库里就有两份互相矛盾的身份说法。
- *
- * 幂等性来自谓词:重跑时旧桶键已经不在库里 ⇒ 零行匹配 ⇒ 零行变化。
- * `owner_kind = 'local-owner'` 的那只桶天然不受影响 —— 它的 owner_key 是 `sha256("local-owner")`,
- * 与任何 principal 派生的键都不相等,所以**匹配不到**(不需要额外的 owner_kind 谓词来护住它)。
- */
 export function buildRuleOwnerRekeySql(dialect, leg) {
     return (`UPDATE ${leg.table} SET owner_key = ${ph(dialect, 1)}, principal = ${ph(dialect, 2)}` +
         ` WHERE owner_key = ${ph(dialect, 3)}`);
 }
-/** session_policy 重键腿的扫描:拿到 from 侧每一行的 `(policy_key, session_id)`。参数序:`[fromPrincipal]`。 */
 export function buildSessionPolicyScanSql(dialect) {
     return `SELECT policy_key, session_id FROM session_policy WHERE principal = ${ph(dialect, 1)}`;
 }
-/**
- * session_policy 的逐行重键改写。`policy_key = sha256(JSON.stringify([sessionId, principal ?? null]))`,
- * 身份在**主键的 hash 原像**里 ⇒ 等值 UPDATE 够不着,必须读出来重算再改写。
- * 参数序:`[newPolicyKey, toPrincipal, oldPolicyKey]`。
- */
 export function buildSessionPolicyRewriteSql(dialect) {
     return (`UPDATE session_policy SET policy_key = ${ph(dialect, 1)}, principal = ${ph(dialect, 2)}` +
         ` WHERE policy_key = ${ph(dialect, 3)}`);

package/dist/adoption/wire.js

@@ -1,62 +1,24 @@
-/**
- * design/183 §6 —— 收编回执的**唯一包络**(form b:纯身份重绑,数据已在 SQL、承运腿为零)。
- *
- * 🔴 为什么 schema 在这里而不是散在路由里(clay 最高宪法「边界必 schema 禁裸 as-cast」):这份包络是
- * **跨仓 wire 契约** —— 下游(cli / web-admin / 围栏 E2E)要按字段名逐字钉围栏。请求体在入口 zod 解析,
- * 响应体从这里的类型铸出,于是「路由改了字段名而围栏不知道」是编译红而不是运行期静默漂移。
- *
- * ── 与 183 §6 的**逐条差异**(如实登记,不假装同形)────────────────────────────────────────────────
- *  ① `AdoptionReport.credentials` **缺席**。183 的那一格服务的是 form a「云铸新身份 ⇒ 凭据领取位」;
- *     form b 的 `toPrincipal` 是**运维在请求体里点名的既存身份**,本车不铸任何凭据 ⇒ 给一个 `ref` 就是
- *     凭空发明一个兑取不到的 claim(而 183 §4.3 恰恰要求该 ref 是 durable 可重复兑取的)。缺席是诚实,
- *     假字段是谎。form a 承运车落地时由那台车补这一格。
- *  ② `AdoptionReceipt.current.quarantined` **恒 0**。隔离位是承运腿(对端拒收行)的概念,form b 零承运
- *     ⇒ 结构位在场、读数恒 0。保留字段是为了 form a 上车时包络不变形(下游围栏不用改)。
- *  ③ `notMigratedByDesign` 是 **v2 小票新增**的机读位(183 只在散文里说「按设计不迁」)。成员标识符
- *     ({@link NotMigratedFace})与字段名一样是**冻结的机读词表**,下游按它写正向断言(§10.5:把「按
- *     设计不迁」与「漏了没迁」在黑盒上分开)。加成员=加行为面,减成员=下游围栏红。
- *
- * `immutableReport` 逐字节恒同 = 幂等判据(183 §8):它在 phase 6 一次性落库,此后任何重跑原样回放,
- * **绝不重算**。`current` 反过来每次现算(配置账未见证项、隔离计数),两半各钉各的(§10.6)。
- */
 import { z } from "zod";
-/** 收编来源(form b 只有具名 principal 一形;`local-owner` 是 form a 的形,本车不产出也不接受)。 */
 export const AdoptionSourceSchema = z.object({ kind: z.literal("principal"), principal: z.string().min(1) }).strict();
-/** per-store 腿的动作词(183 §6 闭集;form b 只会产出前两个 + `none`)。 */
 export const AdoptionLegActionSchema = z.enum(["bucket-rebind", "row-rewrite", "carried", "none", "reset"]);
 export const AdoptionLegSchema = z
     .object({
-    /** 腿的稳定标识 = `<表名>#<身份轴列>`(下游按它对账;表名/列名都是本仓 schema 的真名)。 */
     store: z.string().min(1),
     action: AdoptionLegActionSchema,
-    /** 本次真改了几行。**重跑恒 0**,而 `immutableReport` 里冻的是**首次**的读数(史实)。 */
     rows: z.number().int().nonnegative().optional(),
     quarantined: z.number().int().nonnegative().optional(),
 })
     .strict();
-/**
- * 受影响部署配置清单(183 §6 表)。`migrated` 对 server 半场**恒 false**——这些配置全在别的部署单元
- * (BFF / cli / env / core 声明位),收编动作**够不到**它们,而 183 §3.3 的明令是「改不到的配置,不假装
- * 改了」。清单在场 + `migrated:false` + 配置账不清 = 下游围栏「配置不迁如实红」的凭据(§10.4)。
- */
 export const AdoptionConfigEntrySchema = z
     .object({
     deployment: z.string().min(1),
     key: z.string().min(1),
     requiredValue: z.string(),
     migrated: z.boolean(),
-    /** 运维表态位(只作记录,**不清账**——183 r3 按 codex r2-F6:手写布尔可以把账清成假绿)。 */
     ack: z.boolean(),
-    /** 消费端运行时真读回 requiredValue 的 typed 回执时刻。**null = 未见证 = 未清账**。 */
     witnessedAtMs: z.number().int().nonnegative().nullable(),
 })
     .strict();
-/**
- * **机读词表**:server 侧按设计不迁的面,逐项挂 183 的裁决号。
- *
- * 🔴 这是**冻结的闭集**(下游按成员名写正向断言)。改名/删员 = wire 破坏;新增 = 新行为面,要先过三问。
- * 判据形见 183 §10.5:「按设计不迁」与「漏了没迁」在黑盒上必须可分,所以它是**正向声明**而不是沉默。
- */
 export const NOT_MIGRATED_FACES = [
     "usage-window",
     "cost-quota",
@@ -64,26 +26,19 @@ export const NOT_MIGRATED_FACES = [
     "approval-exemption-grantor",
     "approval-ask-decision-actor",
     "image-bake-requested-by",
-    // A-010.22(台账 P1)—— 规则店族此前对回执**零表态**:`permission_rule` 那只**活桶**现在真迁了
-    // (`permission_rule#owner_key` 腿),但同族另外两张表按 D2/D1 刻意不迁,而「刻意不迁」与「漏了没迁」
-    // 在黑盒上必须可分(§10.5)。少了这两员,运维读到的回执是:`notMigratedByDesign` 里没有规则店的影子、
-    // `residualSourceRows` 又把它们数成 0 —— 一份「什么都没落下」的**假声明**。
     "permission-rule-approval-history",
     "permission-rule-import-ticket",
 ];
 export const AdoptionNotMigratedSchema = z
     .object({
     face: z.enum(NOT_MIGRATED_FACES),
-    /** 183 §12 的裁决号(`D1` = 配额窗清零重计;`D2` = 史实字段不改写)。 */
     ruling: z.enum(["D1", "D2"]),
     reason: z.string().min(1),
 })
     .strict();
-/** 终态快照(**不可变史实**,phase 6 一次落库,逐字节恒同 —— 183 I4 + §8 幂等判据)。 */
 export const AdoptionReportSchema = z
     .object({
     adoptionId: z.string().min(1),
-    /** 本车只做 form b;`form` 显式在场是为了 form a 上车后回执可分辨(下游不必按缺席位推断)。 */
     form: z.literal("b"),
     from: AdoptionSourceSchema,
     toPrincipal: z.string().min(1),
@@ -93,48 +48,19 @@ export const AdoptionReportSchema = z
     notMigratedByDesign: z.array(AdoptionNotMigratedSchema),
 })
     .strict();
-/**
- * 唯一回执包络。**首次成功与一切幂等重跑同形**(183 §6 r7);别处不得另造第二种回执。
- *
- * `status`:`adopted` = 终态在;`stalled` = 在飞(锁被别的副本持着 / 崩溃后尚未续完)。
- * **`rejected` 不在这个闭集里**:被拒的收编从来不产出回执,POST 与 GET 一律以 typed 409 应答
- * (`adoption.destination_conflict` / `adoption.source_already_bound`),否则「拒」与「成」共用一个 200
- * 包络,消费端要靠读字段猜——那正是 183 §7.3「拒绝可判别」要消灭的形。
- */
 export const AdoptionReceiptSchema = z
     .object({
     status: z.enum(["adopted", "stalled"]),
     immutableReport: AdoptionReportSchema,
     current: z
         .object({
-        /** 配置账里 `witnessedAtMs === null` 的项(`<deployment>:<key>`)。空 = 账已清。 */
         outstandingConfigs: z.array(z.string()),
-        /** form b 恒 0(零承运 ⇒ 无拒收行);字段在场见本文件顶注差异②。 */
         quarantined: z.number().int().nonnegative(),
-        /**
-         * **仍挂在旧身份名下的行数**(每次现算,跨全部迁移腿求和)。
-         *
-         * 🔴 为什么这一格是承重的(codex 对抗复审 R1-F1,采纳其可检测半):收编**不**给普通写者上栅栏
-         * ——183 I1 的口径是「引擎必须先停」,那是**运维前提**,不是机器保证。于是一个还在按旧身份注入的
-         * 调用方(配置未随迁 ⇒ `outstandingConfigs` 非空)会在终态之后继续往旧身份下写行,而终态 + 幂等
-         * 短路会让回执一直说「adopted」。
-         *
-         * 这一格把那件事**变成可见的读数**:`>0` = 这个部署仍在往旧身份写,配置随迁没做完。
-         * 每次 **POST**(写动词)会顺带把这些迟到行扫进新身份并重报此数;**GET** 只读不扫。
-         * `immutableReport` 是史实、不受影响 —— 史实与现势各住各的字段(183 §6)。
-         */
         residualSourceRows: z.number().int().nonnegative(),
     })
         .strict(),
 })
     .strict();
-/**
- * 库里那三个 JSON 文本列(`legs` / `configs` / `reject_detail`)读回内域时的 schema。
- *
- * 🔴 为什么不是「解析完直接裸铸形」(clay 最高宪法 §2 + `boundary-cast-gate`):DB 行与 HTTP body 同属
- * **进程外数据**。裸 `as` 是「库里的字节直接冒充内域类型」—— 一次手改库/一次旧版本残留行,坏形就会带着
- * 一个说谎的类型annotation 流进回执,而回执是下游围栏的判据源。
- */
 export const AdoptionLegsSchema = z.array(AdoptionLegSchema);
 export const AdoptionConfigsSchema = z.array(AdoptionConfigEntrySchema);
 export const AdoptionRejectDetailSchema = z
@@ -143,13 +69,7 @@ export const AdoptionRejectDetailSchema = z
     conflicts: z.array(z.object({ leg: z.string(), table: z.string(), overlapping: z.number().int().nonnegative() }).strict()),
 })
     .strict();
-/**
- * 拒绝码的**闭集**(与附录 A 的 `adoption.*` 族逐字同名)。住在 wire 契约里而不是实现里,因为落库的
- * `adoption_log.reject_code` 与 wire 上的 `errorCode` 必须是**同一个词表** —— 两处各写一份字符串字面量,
- * 就是「库里记了一个 wire 上不存在的码」这类漂移的入口。路由的 switch 对它穷举:加成员即编译红。
- */
 export const ADOPTION_REJECT_CODES = ["adoption.destination_conflict", "adoption.destination_unrepresentable"];
-/** `POST /v1/adoption` 的请求体。`.strict()` = 写面纪律:多余键是调用方错误,当场 400(不静默吞)。 */
 export const AdoptionRequestSchema = z
     .object({
     fromPrincipal: z.string().min(1).max(190),

package/dist/approval-ask-machine.js

@@ -1,42 +1,6 @@
-/**
- * 流内审批协议(design/172 v3.1 §3.0)持久层状态机 —— #151 车1。纯函数,零 IO:态词表 + 合法转移表 +
- * 判定函数 + 确定性 id 派生。所有落库/网络/时钟一律不在本文件——store 层(approval-ask-store-*.ts)消费
- * 这里的 `canAskTransition`/`canBatchTransition` 做 SQL 前置合法性判定,`deriveAskId`/`deriveBatchId`
- * 做身份键计算。
- *
- * ── 态词表(闭集)────────────────────────────────────────────────────────────────────────────────
- * ask 级 6 态:STREAM_PENDING(流内待决)| DECIDED(已回决)| PARKING(窗到期中选、正在转投递面)|
- *   PARKED(已绑定投递坐标,等待走 gate)| DENIED(已拒)| VOID(非中选兄弟收敛/撤卡终态)。
- * 批级 4 态:OPEN(接受回决)| ROUTING_UNBOUND(已转投递面,尚未绑定具体 ask)|
- *   ROUTING_BOUND(bind-once 后已绑定)| ABORTED(整批撤卡)。
- *
- * ── 合法转移表(design/172 §3.0 图,逐字照抄,全枚举——本文件是唯一真源)────────────────────────
- * ask:  STREAM_PENDING → DECIDED | PARKING | VOID
- *       PARKING        → PARKED | DENIED | VOID(VOID = 非中选兄弟收敛)
- *       其余(4 个终态)  → ∅ —— 唯一例外是 §3.0/§4 的 provisional 版本化补偿:那条路径专走
- *       store 的 `resolveProvisional`(WHERE …AND provisional=1…),故意**不**经过这张表——
- *       补偿允许终态→终态,而这张表把终态定义为「无出边」,两者不矛盾(不同的门,不同的谓词)。
- * 批:  OPEN            → ROUTING_UNBOUND | ABORTED
- *       ROUTING_UNBOUND → ROUTING_BOUND | ABORTED
- *       其余(2 个终态)  → ∅
- *
- * 🔴 施工纪律:表驱动,禁 if 链——`canAskTransition`/`canBatchTransition` 只做一次数组查找,新增/
- * 删除一条转移只需要改上面两张 `Record<State, readonly State[]>` 字面量,不需要碰判定函数本体。
- */
 import { createHash } from "node:crypto";
-/** ask 侧终态集合(无出边的 4 态)——store 层 CAS 谓词与 reap/对账扫描复用这份闭集,不许各自重列。 */
 export const ASK_TERMINAL = new Set(["DECIDED", "PARKED", "DENIED", "VOID"]);
-/** 批侧终态集合(无出边的 2 态)。 */
 export const BATCH_TERMINAL = new Set(["ROUTING_BOUND", "ABORTED"]);
-/**
- * #229:回决理由(`AskRow.decisionNote` → `decision_note` 列)的字符上限,**两条回决腿共用一个常量**。
- *
- * 🔴 为什么住在这个模块:两个消费者分别是 durable 腿的 zod 体(`http/routes/runs.ts` 的
- * `AskDecisionBodySchema`)与 live 腿的手写 parser(`tool-approval.ts` 的 `parseToolApprovalResponse`),
- * 两处都在 ask 状态机的**同一张行**上写同一列。上限各写一份字面量 = 同一列上两个口径,而分歧只会在
- * 「一条腿收下、另一条腿 400」的那天才被发现。本模块是两腿唯一的共同上游(askId/batchId 铸造与转移表
- * 都在这里),放这里不引新依赖边。
- */
 export const MAX_DECISION_NOTE_CHARS = 2048;
 const ASK_TRANSITIONS = {
     STREAM_PENDING: ["DECIDED", "PARKING", "VOID"],
@@ -52,59 +16,20 @@ const BATCH_TRANSITIONS = {
     ROUTING_BOUND: [],
     ABORTED: [],
 };
-/** ask 转移合法性(表驱动,含拒绝同值自环——STREAM_PENDING→STREAM_PENDING 不在表里,故 false)。 */
 export function canAskTransition(from, to) {
     return ASK_TRANSITIONS[from].includes(to);
 }
-/** 批转移合法性,同形。 */
 export function canBatchTransition(from, to) {
     return BATCH_TRANSITIONS[from].includes(to);
 }
-// ─────────────────────────────────────────────────────────────────────────────────────────────────
-// 确定性 id 派生(design/172 §3.1 / 本车设计定稿 §5)
-// ─────────────────────────────────────────────────────────────────────────────────────────────────
-/**
- * 分隔符用 NUL(U+0000)而非任何可打印字符:各 id 部件(sourceTaskId/toolCallId/…)是外部系统给的
- * 不透明字符串,不能假设它们不含冒号/空格/其他候选分隔符——黑板有 sessionId 用单字符分隔拼接被
- * 注入撞键的既往 finding(同族修法),NUL 是唯一一个这些部件字段实际上不会自然出现的字节,
- * 所以拼接后不同的 (parts) 元组不可能被撞成同一条 pre-hash 字符串。
- */
 const ID_SEPARATOR = "\u0000";
-/** parts 用 NUL 拼接 + sha256 定长——哈希输出恒 64 hex 字符,`.slice(0, 64)` 是防御性写法而非实际截断
- *  (VARCHAR(255) 列宽远超过 64,这里的「截 64」纯粹是把长度收拢到一个恒定值,不依赖 sha256 实现细节)。 */
 function deterministicId(prefix, parts) {
     const joined = [prefix, ...parts.map((p) => p ?? "")].join(ID_SEPARATOR);
     return createHash("sha256").update(joined, "utf8").digest("hex").slice(0, 64);
 }
-/**
- * 🔴 身份元组的两条轴(车3 设计稿 §3.2′,2026-08-06 换轴,原轴 `(sourceTaskId, toolCallId, leg:number)`
- * 被推翻)—— 这段注释是「为什么是这五个部件」的唯一书面记录:
- *
- * ── `runId`(新增轴,封死跨 run 复用)────────────────────────────────────────────────────────────────
- * core 给 `AskRequest.sourceTaskId` 填的是 **sessionId**(`prepare-task.js:2595` 的 `askSourceIdentity`),
- * 不是 wire run id。而原轴给每条新 run 的首腿都重置 `leg=0` ⇒ 同一会话的**下一次全新提交**若撞上同一
- * `toolCallId`(design/172 定稿 §3.1 记录了部分网关按**请求编号**而非全局编号铸它)会整组重现,
- * `ensureAsk` 的幂等 upsert 于是命中上一 run 已 `DECIDED(approve)` 的旧行并把它回放成 `true` ——
- * 静默复用一次早已过去的人类同意。这不是低概率碰撞,是可确定复现的路径(§10 钉 C-1)。
- * `runId` = 本 run 的 wire id(durable 腿 = 真 run uuid;adhoc 腿 = 该腿一次性 uuid):每次全新提交必是
- * 新值,同一腿内恒定(重试/failover/闭包再入不变)⇒ 幂等仍成立。
- *
- * ── `legKey`(取代数值 `leg`,一腿一凭据)─────────────────────────────────────────────────────────────
- * = `sha256(resume checkpoint token)` 的 hex,**首腿 = 空串**。一次 park→resume 的 token 就是这条腿的
- * 天然身份:同 token 重投 = 同一腿(幂等,正确);新 park ⇒ 新 token ⇒ 新腿 ⇒ 新 askId。
- * 取摘要而非原始 token 是因为 token 是能力凭据(本仓有 `stripCheckpointToken` 专门把它从可重放账本里
- * 剥掉),而 `askId` 是 wire 可见值 ⇒ **只存/只喂摘要**。用它当轴顺带消掉了原裁需要的 `task_run` 加列
- * 与 `markResuming` 返回加宽(后者有第二个调用点 `http/routes/runs.ts:463`,加宽会误杀已成功 resume 的
- * running run)。残留边界:同一 run 内**不经 checkpoint token** 的重入形若未来出现会得到同一 legKey ——
- * 今天不存在这种腿(run 内每次重入都必须经 checkpoint resolve),故不设兜底。
- */
-/** ask_id = sha256('ask' ⊕ sourceTaskId ⊕ runId ⊕ toolCallId ⊕ legKey ⊕ parentToolCallId).slice(0,64)。
- *  确定性:同参数元组(含重试/failover/闭包再入)永远派生同一个 id——这是 ensureAsk 幂等 upsert 成立的前提。 */
 export function deriveAskId(sourceTaskId, runId, toolCallId, legKey, parentToolCallId) {
     return deterministicId("ask", [sourceTaskId, runId, toolCallId, legKey, parentToolCallId]);
 }
-/** batch_id = sha256('batch' ⊕ sourceTaskId ⊕ runId ⊕ legKey).slice(0,64)。同一 (sourceTaskId, runId,
- *  legKey) 恒派生同一批——批 = 同一决策点的兄弟 ask 集合,故不掺 toolCallId。 */
 export function deriveBatchId(sourceTaskId, runId, legKey) {
     return deterministicId("batch", [sourceTaskId, runId, legKey]);
 }