@sema-agent/server 7.43.0 → 7.44.0

package/USAGE.md

@@ -805,6 +805,24 @@ curl -N http://<host>:8090/v1/tasks/stream -H 'content-type: application/json' \
 > 今天仍有效的预防旋钮 = **在开放 `settings.hooks.PreToolUse` 的部署上不依赖后台子代的 durable 审批**
 > (或用 `REQUIRE_PRINCIPAL` 关掉该面),同样只对**此后**新铸的行生效。
 >
+> **🔧 升级到 7.44.0 前:`PERMISSION_RULES_ENABLED=true` 的部署必须删库重建 `permission_rule_approval`
+> 表(BREAKING)。** #340 的卡编辑面(自由文本规则臂)给这张表新增 `command`/`edited_json` 两列,而三条
+> 记录语句(`get`/`create`/`cas`)无条件引用它们。本服务的 schema 契约 = 启动 DDL 是唯一真源、不发
+> `ALTER` 增量 seam,建表语句是 `CREATE TABLE IF NOT EXISTS` ⇒ 对已存在的旧表**一字不改**:新两列不在,
+> 升级后**整条审批记录面**(包括修前就有的候选臂)在这台机器上是坏的——不是「少一个新功能」。
+> 为此本版加了一道**拒启**探针(不是 warn):启动时对该表探两个新列,可证缺列 ⇒ 拒绝启动,错误文案
+> 逐字指路 `DROP TABLE permission_rule_approval;`,重启后 schema 在 boot 时按新 DDL 重建。代价有界:
+> 这张表只装**审批记录**(谁在何时同意了哪条候选的审计事实),丢的是在飞的 CC 导入预览(可重新跑一遍)
+> 与历史记录轨迹;真正持久化的规则本身在 `permission_rule` 表,不受影响、不需要重建。
+> 探针只在规则车道真被装配时跑(`PERMISSION_RULES_ENABLED=false` 的部署一次都不碰这张表,不受影响)。
+>
+> **同批顺带:场景旧名 `team` / 工具旧名 `run_team` 退役(#342,BREAKING)。** #273 过渡窗的别名层
+> (`SCENARIO_ALIASES`)整体撤销:请求体里显式传 `scenario:"team"` 从「静默归一到 `discuss`」变成
+> **未知名响亮 400**(`scenario_unknown`);指派/部署配置里悬空写着的旧名走**现有**
+> unknown→default 回退(与任何其他未知名同待遇,不是新逻辑)。prompts 里写死旧工具名 `run_team` 的
+> 部署 ⇒ 模型看到「工具不存在」。滚版前把请求面/配置面/prompts 里的旧名换成现役主名
+> `discuss` / `run_discussion`。
+>
 > **🔧 升级到 7.10.0 前:必须删库重建(BREAKING,两条同窗)。** ① pg 侧 memory 两表的
 > `agent_memory_engine_entry.scope/slug` 与 `agent_memory_engine_cursor.scope` 由 `text` 收窄为
 > `varchar(190)` / `varchar(512)`(与 MySQL-protocol 方言同宽);② 七个 epoch-BIGINT 列补 `_ms` 后缀,

package/dist/adoption/plan.js

@@ -1,46 +1,5 @@
-/**
- * design/183 §4.3 —— **form b 收编的迁移计划表**(server 半场细设计;183 §1 明写「表级细设计归 server」)。
- *
- * 这张表是本车的**单一真源**:phase 0 的目的地冲突 preflight、phase 3 的行迁/桶迁、回执里的 `legs`
- * 三者全部由它派生 —— 三处各抄一份表正是「preflight 说没冲突、迁移腿却撞 UNIQUE」这类分家的温床。
- *
- * ── 判定轴(183 §4.1 身份轴三形,落到本仓真 schema)────────────────────────────────────────────────
- *  · **形Ⅰ 行迁**(`row-rewrite`):数据里有 owner/principal 结构位,且该位**不在任何唯一键里**
- *    ⇒ 一条 `UPDATE … SET col = :to WHERE col = :from` 即可,重跑改到同值 = 零行变化(幂等),
- *    且**不可能撞唯一键**(`residualKey: undefined` 就是这句话的机器形)。
- *  · **形Ⅱ 桶迁**(`bucket-rebind`):键是 scope,而本部署的 scope 词表把身份编进去(server durable
- *    scope ≡ principal 的恒等涟漪)。scope 若**在**唯一键里,重绑就可能与目的地已有的同逻辑键撞
- *    ⇒ `residualKey` 记下「唯一键去掉身份轴之后剩下的列」,preflight 按它查重叠。
- *  · **形Ⅲ 无身份轴**:键=session/ref/内容寻址(session_event / task_event / task_active /
- *    checkpoint_ctx / tool_result / snapshot_manifest / snapshot_blob / approval_batch /
- *    task_list_* / workflow_completion_inbox 的 session_id 那一半 …)⇒ **零改写**:归属随它挂靠的
- *    资产(会话 / run / 内容)一起走,本表不列它们,也不该列 —— 列了就是给「跟着 session_id 走的行」
- *    再造一个第二真源。
- *
- * ── 一张表两根身份轴的处置(agent_roster / background_agent)────────────────────────────────────
- * 逐轴各一条腿,各带**自己**的 `residualKey`(= 该表唯一键去掉这根轴)。两条腿在**同一个事务**里
- * 顺序跑;preflight 是按迁移**前**的库态逐轴算的,理论上仍存在一个跨轴的组合形撞唯一键
- * (A 行只动 owner、B 行只动 scope 后同键)—— 那一形由 phase 3 事务里的唯一键违例**响亮拒 + 整体
- * 回滚**兜住(两侧字节零变更),而不是靠 preflight 声称自己算全了。fail-closed,不 fail-open。
- *
- * ── 为什么腿的集合比小票逐字点名的多(**如实登记,候属主裁**)────────────────────────────────────
- * 小票 §行迁/桶迁 点名的是 `session_meta.owner` / `session_policy` / checkpoint / mailbox / workflow /
- * background-agent / snapshot / memory。本表在此之外还迁了 `task_run.owner`、`resume_anchor.owner`、
- * `sendfile_link.scope`、`task_attachment.owner`、`approval_ask.owner`、`agent_roster` 两轴、
- * `workflow_completion_inbox.owner` / `workflow_inbox_fence.owner` / `workflow_notify_journal.principal`、
- * `sandbox_image_index.tenant_id`。判据不是「多迁点保险」,是小票自己写的那条**类判据**:
- * 「形Ⅰ = owner/principal 结构位」「形Ⅱ = scope ≡ principal 分区面」—— 上面每一列都逐字落在这两句里,
- * 且每一列都是**活的授权/可见性轴**(不是史实字段):`session_meta.owner` 迁了而 `task_run.owner` 没迁,
- * 结果就是「会话看得见、它的 run 历史读不到」= 183 §6 明令要防的第一病形「owner 变了调用方够不着」。
- * 反向的「不该迁」一律进 {@link NOT_MIGRATED_BY_DESIGN}(D1/D2 裁决号在案),不进本表。
- */
 import { formatUserScope, encodeScopeSegment, SCOPE_SEGMENT_MAX_ENCODED } from "@sema-agent/core";
-/**
- * 全部重绑腿。**次序即执行序**(同一事务内顺序跑):同表两轴相邻,workflow 家族相邻
- * (183 §4.3「run + journal 同事务」在本车是「**全部腿同一个事务**」的更强形)。
- */
 export const REBIND_LEGS = [
-    // ── 形Ⅰ:owner/principal 结构位,不在任何唯一键里 ⇒ 结构性无冲突 ────────────────────────────
     {
         leg: "session_meta#owner",
         table: "session_meta",
@@ -49,15 +8,10 @@ export const REBIND_LEGS = [
         columns: ["owner"],
         matchColumn: "owner",
         encoding: "verbatim",
-        residualKey: undefined, // PK(session_id) 不含 owner
+        residualKey: undefined,
         why: "会话归属主列(183 §4.3 形Ⅰ 首项;存量 `anon:shell-live` 哨兵行同走此腿——它只是一个 principal 字面量,不需要 ad hoc 分支)",
     },
     {
-        // #292(core 5.48 placement 分区,身份轴普查门在合并树首跑即逮到——门的存在理由):core 契约明写
-        // placement.scope = "Tenant key, same source as the durable agent row's scope" ⇒ 形Ⅱ(scope ≡
-        // principal 分区面),与 background_agent.scope 同判。**活的可见性轴**:listPlaced 按它过滤
-        // (pg/tidb 店的 WHERE placement_kind+placement_scope),不迁则收编后子代转录对新身份枚举不到、
-        // 对旧身份被 owner 门拒 = 双盲。placement_scope 只在 placed 行非 NULL,谓词天然只碰 placement 分区。
         leg: "session_meta#placement_scope",
         table: "session_meta",
         kind: "bulk-rebind",
@@ -65,7 +19,7 @@ export const REBIND_LEGS = [
         columns: ["placement_scope"],
         matchColumn: "placement_scope",
         encoding: "verbatim",
-        residualKey: undefined, // PK(session_id) 不含它;idx_session_meta_placement 非唯一
+        residualKey: undefined,
         why: "placement 分区键(core 5.48 SessionPlacement.scope=tenant key,与 durable agent 行 scope 同源)——子代转录的枚举可见性轴,不迁=收编后 listPlaced 对新旧身份双盲",
     },
     {
@@ -76,7 +30,7 @@ export const REBIND_LEGS = [
         columns: ["owner"],
         matchColumn: "owner",
         encoding: "verbatim",
-        residualKey: undefined, // PK(task_id)
+        residualKey: undefined,
         why: "run 列表/属主门的过滤列(GET /v1/runs 与 trace 属主门读它)——不迁 = 会话迁了它的 run 历史读不到",
     },
     {
@@ -87,7 +41,7 @@ export const REBIND_LEGS = [
         columns: ["owner"],
         matchColumn: "owner",
         encoding: "verbatim",
-        residualKey: undefined, // PK(session_id, event_id)
+        residualKey: undefined,
         why: "E18 anchor 的单库舰队纵深防御列(与 session 同生命周期)",
     },
     {
@@ -98,7 +52,7 @@ export const REBIND_LEGS = [
         columns: ["scope"],
         matchColumn: "scope",
         encoding: "verbatim",
-        residualKey: undefined, // PK(id)
+        residualKey: undefined,
         why: "SendUserFile 台账的租户列(DDL 行内注:scope = VERIFIED principal verbatim)= 逐租户 list/revoke 句柄",
     },
     {
@@ -109,7 +63,7 @@ export const REBIND_LEGS = [
         columns: ["owner"],
         matchColumn: "owner",
         encoding: "verbatim",
-        residualKey: undefined, // PK(id)
+        residualKey: undefined,
         why: "D-1 附件面的属主列(auth principal ?? default)",
     },
     {
@@ -120,7 +74,7 @@ export const REBIND_LEGS = [
         columns: ["owner"],
         matchColumn: "owner",
         encoding: "verbatim",
-        residualKey: undefined, // PK(ask_id);UNIQUE(task_id, idempotency_key) 不含 owner
+        residualKey: undefined,
         why: "#151 流内审批 ask 行的租户列(读面按它过滤)。**decision_actor / decision_note 不动** —— 那是史实(D2)",
     },
     {
@@ -131,17 +85,10 @@ export const REBIND_LEGS = [
         columns: ["tenant_id"],
         matchColumn: "tenant_id",
         encoding: "verbatim",
-        residualKey: undefined, // PK(id);UNIQUE(repo, digest) 不含 tenant_id
+        residualKey: undefined,
         why: "镜像可见性的租户列(tenant-scoped 镜像只对该 principal 可见)—— 活的可见性轴,不是史实",
     },
     {
-        // #193 车4 件1 同批:`leader_run` 这张表一落地,收编的身份轴普查门(adoption-db-integration)当场逮到
-        // 它的 `owner` 列未表态 —— 正是那道门的存在理由。判定=**活的可见性轴**(GET /v1/leader/:id 的 404
-        // 属主门读它),与 `task_run#owner` 同形,故真迁而不是登记进 declared。
-        // 🔴 `idem_key` 不随迁(也无腿):它是 `sha256(owner \x1f 调用方原始键)`,重绑后旧行的哈希对新身份
-        // 不再命中 ⇒ 提交幂等窗在收编那一刻失效(重投会起一条新 run)。这是**有意的**:收编按 183 I1 要求
-        // 停机进行,窗内没有在飞的重投;而反过来去重算哈希会把「这行当初是用哪个键提交的」这条史实改写,
-        // 且新旧哈希不等 ⇒ 结构上也撞不了 UNIQUE(故 residualKey 仍是 undefined)。
         leg: "leader_run#owner",
         table: "leader_run",
         kind: "bulk-rebind",
@@ -149,7 +96,7 @@ export const REBIND_LEGS = [
         columns: ["owner"],
         matchColumn: "owner",
         encoding: "verbatim",
-        residualKey: undefined, // PK(leader_run_id);UNIQUE(idem_key) 不含 owner
+        residualKey: undefined,
         why: "leader run 的属主列(GET /v1/leader/:id 的 404 属主门读它)—— 不迁 = 收编后这些 run 对新身份全部读作「不存在」",
     },
     {
@@ -160,7 +107,7 @@ export const REBIND_LEGS = [
         columns: ["owner"],
         matchColumn: "owner",
         encoding: "verbatim",
-        residualKey: undefined, // PK(session_id, run_id)
+        residualKey: undefined,
         why: "workflow 完成收件箱的属主列(投递门读它)",
     },
     {
@@ -171,7 +118,7 @@ export const REBIND_LEGS = [
         columns: ["owner"],
         matchColumn: "owner",
         encoding: "verbatim",
-        residualKey: undefined, // PK(session_id, kind, run_id)
+        residualKey: undefined,
         why: "收件箱围栏行的属主列(与 inbox 同轴,漏迁 ⇒ 围栏对新身份失效)",
     },
     {
@@ -182,13 +129,10 @@ export const REBIND_LEGS = [
         columns: ["principal"],
         matchColumn: "principal",
         encoding: "verbatim",
-        residualKey: undefined, // PK(run_id)
+        residualKey: undefined,
         why: "notify 日志的投递身份列(未 ack 的通知按它重投)",
     },
     {
-        // 🔴 这条腿是**普查门逮出来的**(2026-08-10 建门当天):本表有 `principal` 与 `scope` **两根**身份轴,
-        // 初版只迁了 principal。漏掉 scope 的后果是恢复扫描按 `WHERE scope = <新身份>` 一条都捞不到,
-        // 未 ack 的通知对新身份永久不可见 —— 而 principal 那半迁了,黑盒上看起来「迁过了」。
         leg: "workflow_notify_journal#scope",
         table: "workflow_notify_journal",
         kind: "bulk-rebind",
@@ -196,11 +140,10 @@ export const REBIND_LEGS = [
         columns: ["scope"],
         matchColumn: "scope",
         encoding: "verbatim",
-        residualKey: undefined, // PK(run_id) 不含 scope
+        residualKey: undefined,
         why: "notify 日志的 scope 分区(与 workflow run/journal 同轴同事务;principal 是投递身份、scope 是租户分区,两根轴各迁各的)",
     },
     {
-        // 两根轴(scope_key / owner)都可能带旧身份 ⇒ 匹配面必须是它们的**并**,否则只在 owner 上带旧值的行找不到。
         leg: "background_agent#record_json",
         table: "background_agent",
         kind: "blob-rewrite",
@@ -220,11 +163,10 @@ export const REBIND_LEGS = [
         columns: ["owner"],
         matchColumn: "owner",
         encoding: "verbatim",
-        residualKey: undefined, // PK(scope_key, handle) 不含 owner
+        residualKey: undefined,
         why: "后台代理行的 default-deny 谓词两根轴之一(owner);另一根 scope 见下面的桶迁腿",
     },
     {
-        // 🔴 载荷腿排在同表的列腿**之前**:改写要按**旧**身份值找行,列一旦换掉就再也找不到了。
         leg: "checkpoint#checkpoint_blob",
         table: "checkpoint",
         kind: "blob-rewrite",
@@ -232,7 +174,7 @@ export const REBIND_LEGS = [
         columns: ["scope"],
         matchColumn: "scope",
         encoding: "verbatim",
-        residualKey: undefined, // 逐行按 PK 回写,不可能撞唯一键
+        residualKey: undefined,
         blob: { column: "checkpoint", pk: ["token"], fields: ["scope"], revColumn: "rev" },
         why: "core `Checkpoint.scope`(类型注:Multi-tenant isolation key)住在 blob 里 —— 只迁 `scope` 列会让载荷里的隔离键留在旧身份",
     },
@@ -244,7 +186,7 @@ export const REBIND_LEGS = [
         columns: ["scope"],
         matchColumn: "scope",
         encoding: "verbatim",
-        residualKey: undefined, // PK(token) 不含 scope ⇒ 桶迁语义、结构性无冲突
+        residualKey: undefined,
         why: "durable HITL 检查点的租户分区列(scope = `principal ?? \"_\"`)——不迁 ⇒ 新身份 resume 不了自己的挂起任务",
     },
     {
@@ -267,7 +209,7 @@ export const REBIND_LEGS = [
         columns: ["scope"],
         matchColumn: "scope",
         encoding: "verbatim",
-        residualKey: undefined, // PK(id)
+        residualKey: undefined,
         why: "workflow run 行的 scope 分区(scope = `principal ?? \"default\"`)。183 §4.2 D4:不变量属 update 动词面,存储层迁移豁免",
     },
     {
@@ -278,10 +220,9 @@ export const REBIND_LEGS = [
         columns: ["scope"],
         matchColumn: "scope",
         encoding: "verbatim",
-        residualKey: undefined, // PK(run_id, ordinal)
+        residualKey: undefined,
         why: "resume 重放日志的 scope 守卫列 —— 与 run 行**同事务**(错配会让 load 守卫拒掉整条 resume)",
     },
-    // ── 形Ⅱ:身份轴**在**唯一键里 ⇒ residualKey 非 undefined,preflight 必须逐族查重叠 ──────────
     {
         leg: "workflow_resume_claim#scope",
         table: "workflow_resume_claim",
@@ -290,7 +231,7 @@ export const REBIND_LEGS = [
         columns: ["scope"],
         matchColumn: "scope",
         encoding: "verbatim",
-        residualKey: ["source_run_id"], // PK(source_run_id, scope)
+        residualKey: ["source_run_id"],
         why: "跨副本 resume 准入租约(与 run/journal 同族同事务)",
     },
     {
@@ -301,7 +242,7 @@ export const REBIND_LEGS = [
         columns: ["scope_key", "scope"],
         matchColumn: "scope_key",
         encoding: "verbatim",
-        residualKey: ["handle"], // PK(scope_key, handle)
+        residualKey: ["handle"],
         why: "信箱行的 scope 分区。`scope_key`(字节列)与 `scope`(可读列)存的是同一个值,必须一起改",
     },
     {
@@ -312,7 +253,7 @@ export const REBIND_LEGS = [
         columns: ["scope_key"],
         matchColumn: "scope_key",
         encoding: "verbatim",
-        residualKey: ["handle", "seq"], // PK(scope_key, handle, seq)
+        residualKey: ["handle", "seq"],
         why: "未投递通知 = 183 [3265] A 类资产(消息体随信箱同迁;本表无 `scope` 可读列)",
     },
     {
@@ -323,7 +264,7 @@ export const REBIND_LEGS = [
         columns: ["scope_key", "scope"],
         matchColumn: "scope_key",
         encoding: "verbatim",
-        residualKey: ["handle"], // PK(scope_key, handle)
+        residualKey: ["handle"],
         why: "后台代理行的 scope 分区(default-deny 谓词的第二根轴)",
     },
     {
@@ -334,7 +275,7 @@ export const REBIND_LEGS = [
         columns: ["owner_key", "owner"],
         matchColumn: "owner_key",
         encoding: "verbatim",
-        residualKey: ["name_key", "scope_key"], // PK(name_key, owner_key, scope_key)
+        residualKey: ["name_key", "scope_key"],
         why: "花名册行的 owner 轴(core 1.365 起 owner/scope 双轴必填 = default-deny 谓词的两根轴)",
     },
     {
@@ -345,10 +286,9 @@ export const REBIND_LEGS = [
         columns: ["scope_key", "scope"],
         matchColumn: "scope_key",
         encoding: "verbatim",
-        residualKey: ["name_key", "owner_key"], // PK(name_key, owner_key, scope_key)
+        residualKey: ["name_key", "owner_key"],
         why: "花名册行的 scope 轴(与 owner 轴同表两根轴,逐轴各一条腿——见顶注「一张表两根身份轴」段)",
     },
-    // ── 形Ⅱ(memory 族):scope 是 core 的 v2 typed 键,身份在**段**里 ⇒ 值对由 DISTINCT 扫描解出 ──
     {
         leg: "agent_memory_engine_entry#scope",
         table: "agent_memory_engine_entry",
@@ -357,7 +297,7 @@ export const REBIND_LEGS = [
         columns: ["scope"],
         matchColumn: "scope",
         encoding: "memory-scope",
-        residualKey: ["slug"], // UNIQUE(scope, slug)
+        residualKey: ["slug"],
         why: "记忆条目盘(user:/proj:/userproj: 三形键的 tenant 段 = principal)",
     },
     {
@@ -368,7 +308,7 @@ export const REBIND_LEGS = [
         columns: ["scope"],
         matchColumn: "scope",
         encoding: "memory-scope",
-        residualKey: [], // PK(scope) —— 唯一键**就是**身份轴:两侧各有一行即冲突
+        residualKey: [],
         why: "记忆盘游标(每 scope 一行)",
     },
     {
@@ -379,7 +319,7 @@ export const REBIND_LEGS = [
         columns: ["scope"],
         matchColumn: "scope",
         encoding: "memory-scope",
-        residualKey: ["peer"], // PK(scope, peer)
+        residualKey: ["peer"],
         why: "记忆同步的 per-peer 游标",
     },
     {
@@ -390,7 +330,7 @@ export const REBIND_LEGS = [
         columns: ["scope"],
         matchColumn: "scope",
         encoding: "memory-scope",
-        residualKey: undefined, // PK(id)
+        residualKey: undefined,
         why: "记忆推送队列(未推完的条目随盘走)",
     },
     {
@@ -401,64 +341,34 @@ export const REBIND_LEGS = [
         columns: ["scope"],
         matchColumn: "scope",
         encoding: "memory-scope",
-        residualKey: undefined, // PK(id, rev)
+        residualKey: undefined,
         why: "记忆修订史的 scope 列(随盘走;`op`/`snapshot` 是内容不是身份)",
     },
-    // ── 唯一一条要逐行重算主键的腿 ────────────────────────────────────────────────────────────────
     {
         leg: "session_policy#principal",
         table: "session_policy",
         kind: "session-policy-rekey",
         action: "row-rewrite",
-        columns: ["principal"], // policy_key 由 (session_id, principal) 重算,不是等值搬运
+        columns: ["principal"],
         matchColumn: "principal",
         encoding: "verbatim",
-        residualKey: ["session_id"], // policy_key = sha256([session_id, principal]) ⇒ 同 session 的目的地行即冲突
+        residualKey: ["session_id"],
         why: "E6 逐会话逐 principal 的工具收紧规则:身份在**主键的 hash 原像**里,等值 UPDATE 够不着 ⇒ 逐行读出→重算 policy_key→改写",
     },
-    // ── 规则桶的整桶改键(A-010.4 / A-010.16 / A-010.22)────────────────────────────────────────────
     {
         leg: "permission_rule#owner_key",
         table: "permission_rule",
         kind: "rule-owner-rekey",
         action: "bucket-rebind",
-        // 两列同腿:`owner_key` 是**派生**的桶键、`principal` 是它的明文原像列(店按前者寻址、运维按后者读)。
-        // 只改一列 = 库里两份身份说法不一致,而寻址用的那份与人读的那份互相矛盾。
         columns: ["owner_key", "principal"],
         matchColumn: "owner_key",
         encoding: "rule-owner-key",
-        // PK(owner_key) ⇒ 唯一键**就是**这根轴本身 ⇒ 目的地已有桶即冲突(退化成两侧各有任意一行)。
-        // 与 agent_memory_engine_cursor 的 PK(scope) 同形,故 `[]` 而不是 undefined。
-        //
-        // 🔴 连带的一条真语义(真双库上实测出来的,不是推的):**迟到桶清扫不掉,而这是对的**。
-        // 终态之后旧身份下若又长出一只桶(= 部署配置没随迁,还在按旧身份导规则),改键式清扫会撞上新身份
-        // 已经占住的那把 PK ⇒ 腿抛 ⇒ `sweepLate` 捕获 + 响亮 warn,残留读数继续报非零。
-        // 不给它加「合并」臂:两只桶合并是一次 **CRDT 语义 join**(core `applySyncJoin` 的管辖面),
-        // 收编弧自己发明一个 join 就是在放行面上编语义 —— 本车的既定口径是「不做逐表 merge,拒比合安全
-        // 且可重来」。运维侧的可行动信号是三处同时指向同一个真因:一行 warn + 不肯归零的
-        // `residualSourceRows` + 非空的 `outstandingConfigs`。
         residualKey: [],
         why: "#154 车二的**常驻放行桶** —— 一条 allow 规则就是「这个人对这条命令的持久同意」,是本仓最直白的**活授权轴**。" +
             "core 5.23.0 form a 把 permission rules 列为身份轴重绑腿之首(A-010.4:server form b 此前与它有实质分歧);" +
             "#203 把 `PERMISSION_RULES_ENABLED` 默认翻 ON 之后,不迁 = 收编完成而**旧身份名下仍躺着一桶活着的放行规则**",
     },
 ];
-/**
- * server 侧**按设计不迁**的面(183 §12 裁决号在案)。这份清单进回执的 `notMigratedByDesign`,
- * 让「按设计不迁」与「漏了没迁」在黑盒上可分(183 §10.5)。
- *
- * 🔴 D1 三员为什么同族:它们全是**按对齐窗口分桶的治理瞬态计数**(usage_window / cost_quota /
- * rate_limit),窗口语义与身份绑在一起搬过去要跨窗口对齐,复杂度与价值不成比例;清零重计的代价是
- * 新身份在当前窗口拿到一份新额度 —— 一次性部署级动作里这是可接受的,而且**方向偏松不偏紧**,
- * 不会把人锁在门外。
- * 🔴 D2 三员为什么不改:它们是**谁在什么时候做了什么**的史实字段。改写史实 = 伪造审计。
- */
-/**
- * 🔴 本数组的成员集合必须与 {@link NOT_MIGRATED_FACES}(冻结词表)**全等** —— 词表说有而这里没有
- * 就是一条下游按名写了断言、回执里却永远不出现的幽灵成员。等式由 `test/adoption-arc.test.ts` 钉住。
- * (建表时真发生过:`outcome-ledger` 一度只进了词表 —— 它压根没有身份轴,属于「无可迁」而不是
- * 「按设计不迁」,两者混在一起会让 D2 的语义从「史实不改写」滑成「凡是没迁的都算设计」。)
- */
 export const NOT_MIGRATED_BY_DESIGN = [
     { face: "usage-window", ruling: "D1", reason: "deployment token-governance window (usage_window): a windowed governance transient — not carried, recounted from zero" },
     { face: "cost-quota", ruling: "D1", reason: "per-window cumulative spend counter (cost_quota.scope_key) — same windowed-transient class as usage-window" },
@@ -466,12 +376,6 @@ export const NOT_MIGRATED_BY_DESIGN = [
     { face: "approval-exemption-grantor", ruling: "D2", reason: "approval_exemption.granted_by is a historical fact (who granted this exemption), not a live authorization axis" },
     { face: "approval-ask-decision-actor", ruling: "D2", reason: "approval_ask.decision_actor / decision_note record who decided — historical audit fields, never rewritten" },
     { face: "image-bake-requested-by", ruling: "D2", reason: "image_bake.requested_by records who requested the build — historical audit field" },
-    // 🔴 A-010.22:规则店族的**分家表态**。同一族三张表,三个不同的结局,回执必须逐个说清楚:
-    //  · `permission_rule`(活桶)         → **真迁**,见 REBIND_LEGS 的 `permission_rule#owner_key` 腿;
-    //  · `permission_rule_approval`(审批史)→ D2,下面这一员;
-    //  · `permission_rule_ticket`(导入票)  → D1,下面那一员。
-    // 判据与既有 D1/D2 六员逐字同源,不是为这一族新造的标准:改写「谁批准过哪条规则」= 伪造审计;
-    // 分钟级 TTL 的一次性导入票是治理瞬态,过期即死,搬过去没有任何可兑付的价值。
     {
         face: "permission-rule-approval-history",
         ruling: "D2",
@@ -490,29 +394,11 @@ export const AFFECTED_CONFIG_TEMPLATES = [
     { deployment: "env", key: "REQUIRE_PRINCIPAL", requiredValue: "true (multi-tenant posture must stay on)" },
     { deployment: "core-decl", key: "localOwnerRules", requiredValue: "(withdraw — the declaration resolves to the adopted principal after adoption)" },
 ];
-/**
- * 目的地身份值的**列宽约束**(codex 对抗复审 R1-F3,亲核属实)。
- *
- * 🔴 病:请求面收 ≤190 字符的 principal,而迁移腿要把它写进**最窄**只有 `VARCHAR(64)` 的列
- * (`sandbox_image_index.tenant_id`),两根键列还是 `VARBINARY(190)`(**字节**,不是字符),memory scope
- * 更是在 principal 外面再套前缀 + 百分号编码(非 ASCII 膨胀约 9 倍)。于是一个**合法**请求可以跑到腿的
- * 中途才被库以截断/超宽打回 —— 那时 phase 停在 INTENT,每次重发与每次 boot 扫描都会再撞一次同样的墙。
- *
- * 🔴 姿势:在**铸行之前**按最窄真列校验并 typed 拒(fail-closed)。**不**在这里加自动截断——截断身份
- * 就是把 A 的数据交给 B。
- *
- * 另一条可选解是把 `tenant_id` 拓宽到与其它身份列同宽(183/codex 的「统一身份契约」建议)。本车不动
- * 别的特性的 schema:那是一次跨车道的列变更,该由镜像面属主拍。此处如实登记这条不对称。
- */
 export const IDENTITY_WIDTH_LIMITS = [
     { what: "sandbox_image_index.tenant_id VARCHAR(64)", unit: "chars", max: 64 },
     { what: "owner/principal/scope columns VARCHAR(190)", unit: "chars", max: 190 },
     { what: "mailbox/background_agent/agent_roster key columns VARBINARY(190) (MySQL: bytes, not characters)", unit: "bytes", max: 190 },
 ];
-/**
- * core 的段编码器对超长/不可编码的段是**抛错**而不是返回。这里把那个异常**转成调用方的拒绝理由**
- * (错误本身被带出去,不是吞掉换个默认值)—— 拒绝理由要能指着具体是哪一侧、为什么装不下。
- */
 function scopeSegmentRejection(label, principal) {
     let encoded;
     try {
@@ -525,30 +411,7 @@ function scopeSegmentRejection(label, principal) {
         ? `${label} does not fit core's memory scope-segment limit (${SCOPE_SEGMENT_MAX_ENCODED} encoded characters; percent-encoding expands non-ASCII ~9x)`
         : undefined;
 }
-/** memory scope 列宽(两方言 VARCHAR(190) 同宽;段编码后才是真长度)。 */
 export const MEMORY_SCOPE_MAX_CHARS = 190;
-/**
- * 收编身份的**键空间卫生门**(A-010.15,验真后修)。纯函数、零 I/O ⇒ 在铸任何行之前判。
- *
- * ── 病 ──────────────────────────────────────────────────────────────────────────────────────────
- * `adoption_log.from_principal` 上的 UNIQUE 是 183 D7「同一个源不许被收编两次」的**数据库强形**,
- * 而这张表的 MySQL 臂是 `VARCHAR(190) … COLLATE utf8mb4_bin`。`utf8mb4_bin` 虽然是 binary collation,
- * **却仍然是 PAD SPACE 的**(MySQL 只有 `utf8mb4_0900_*` 族是 NO PAD)—— 等值比较与唯一键检查会把两侧
- * 右填充到等长。于是 `"user:a"` 与 `"user:a "` 在 MySQL 腿上是**同一个键**,在 PG 腿(`COLLATE "C"`,
- * 无填充)上是**两个键**。同一份代码、同一个请求,两个后端上结局不同:
- *  · MySQL:第二次收编被 `adoption.source_already_bound` 拒 —— 一个运维完全看不懂的 409;
- *  · PG:落第二行,弧照跑,却**一行都迁不到**(别的表里没有任何列存着带尾空格的那个身份)。
- *
- * ── 为什么修在边界而不是把列改成 VARBINARY(本仓已有的字节孪生形)─────────────────────────────
- * 本仓对**同一族**问题已经裁过一次,逐字在 `plugins/approval-ask-store-sql.ts` 的
- * `assertIdempotencyKeyShape` 头注里:「在边界上 fail-loud 拒掉,方言分歧面整个消失(比把列改
- * VARBINARY 更窄、且对三形同时成立)」。这里的判据比那次还硬一层 —— **带首尾空白的 principal 在本仓
- * 根本不可能是一个真身份**:`security.ts` 的 `principalFrom` 读头时逐字 `.trim()`,所以没有任何
- * owner/scope 列里存得下带尾空格的值。收编一个这样的源身份,能迁到的行恒为零。
- * 拒 = 把一个注定空转(或注定撞出误导性 409)的请求在**入库之前**变成一句说得清的 400。
- * 改列则要动 schema + 基线 + 双库,却只把 MySQL 腿对齐到 PG 腿,对「这个值本来就不是合法身份」这件事
- * 一个字都没说 —— 那才是治标。
- */
 export function checkAdoptionPrincipalShape(fromPrincipal, toPrincipal) {
     for (const [label, p] of [["fromPrincipal", fromPrincipal], ["toPrincipal", toPrincipal]]) {
         if (p.trim() !== p) {
@@ -557,52 +420,28 @@ export function checkAdoptionPrincipalShape(fromPrincipal, toPrincipal) {
     }
     return undefined;
 }
-/**
- * 目的地身份能不能被每一根被写列容纳?返回**人可读的拒绝理由**,`undefined` = 可以。
- * 纯函数(零 I/O),所以校验发生在任何库动作之前。
- */
 export function checkAdoptionWidths(fromPrincipal, toPrincipal) {
-    // 🔴 判据的**次序**有讲究(不是随手排):先查「写进列装不装得下」,再查「core 的段编码上限」。
-    // 反过来排的话,段上限(64 个**编码后**字符)对任何带 `:` 的 principal 都比 `tenant_id VARCHAR(64)`
-    // 更早触发 ⇒ 列宽那条臂**永远走不到**(一条摆着好看的死支;本仓有过「变异打在不可达死支上」的判例)。
     const bytes = Buffer.byteLength(toPrincipal, "utf8");
     for (const limit of IDENTITY_WIDTH_LIMITS) {
         const got = limit.unit === "bytes" ? bytes : toPrincipal.length;
         if (got > limit.max)
             return `toPrincipal is ${got} ${limit.unit}, but ${limit.what} caps it at ${limit.max}`;
     }
-    // **两侧都要查**(本车自测逮到,与 codex R3-F3 同族):`from` 不写进任何列,但它要经
-    // `encodeScopeSegment` 铸出 memory 扫描的前缀,而 core 对**段**的上限是 64 个编码后字符且是**抛错**。
-    // 只查 `to` 的话,一个超长的源身份会让弧在 phase 0 的扫描里抛一个未分类异常:意图行已经落库、
-    // phase 停在 INTENT,此后每次重发与每次 boot 续跑都确定性地再抛一次 —— 一条永远跑不完的弧。
     for (const [label, p] of [["fromPrincipal", fromPrincipal], ["toPrincipal", toPrincipal]]) {
         const rejection = scopeSegmentRejection(label, p);
         if (rejection !== undefined)
             return rejection;
     }
-    // 派生的 memory scope 键(前缀 + 段编码)也要能装下 —— 非 ASCII 在这里膨胀最猛。
     const derived = formatUserScope(toPrincipal);
     if (derived.length > MEMORY_SCOPE_MAX_CHARS) {
         return `the derived memory scope key for toPrincipal is ${derived.length} characters (percent-encoding expands non-ASCII ~9x), but the scope column caps it at ${MEMORY_SCOPE_MAX_CHARS}`;
     }
     return undefined;
 }
-/** `proj:` / `userproj:` 键的 tenant 段前缀(值对由 DISTINCT 扫描按前缀解出)。 */
 export const MEMORY_PROJECT_SCOPE_PREFIXES = ["proj:", "userproj:"];
-/** `verbatim` 轴的值对(纯数据,零 I/O)。 */
 export function buildVerbatimPair(fromPrincipal, toPrincipal) {
     return { from: fromPrincipal, to: toPrincipal };
 }
-/**
- * memory scope 键的重写(纯函数,给扫描出来的每个 scope 值算新值)。
- *  · `user:<enc(from)>` ⇒ `user:<enc(to)>`(逐字等值);
- *  · `proj:<enc(from)>/…` / `userproj:<enc(from)>/…` ⇒ 只换 tenant 段,项目段原样;
- *  · 其它(`org:` 组织盘、无前缀的旧不透明键)⇒ `undefined` = **不属这个 principal,不动**。
- *
- * 🔴 为什么不用 `LIKE '<prefix>%'`:段是**百分号编码**的(`user%3Aweb-demo`),`%` 在 LIKE 里是通配符,
- * 不逐字符转义就会误命中一大片。用「DISTINCT 扫 + 纯函数判前缀」把这道坑整个绕开:判定在 JS 里做,
- * 落到 SQL 的永远只有**等值**谓词。
- */
 export function rewriteMemoryScope(scope, fromPrincipal, toPrincipal) {
     const fromUser = formatUserScope(fromPrincipal);
     if (scope === fromUser)