@sema-agent/server 7.134.0 → 7.136.0

package/MIGRATION.md

@@ -7,6 +7,202 @@
 > ⚠️ 完整清单在仓库根 `CHANGELOG.md`——它**不随 npm tarball 出包**(本文件随包)。看完整迁移窗的
 > 权威姿势是源码 tag diff:`git diff v<旧>..v<新>`(每版都推 `v<版本>` tag);npm 包页也镜像 CHANGELOG。
 
+## 7.136.0 —— 中心登录令牌必须带 `scope`,不带的令牌验证不过(安全;行为面收紧,BREAKING;另含嵌入方 `webAdminJwtVerifier` 类型面) · anthropic 车道两把凭据同设起服拒(`ANTHROPIC_API_KEY` 与 `ANTHROPIC_AUTH_TOKEN`;行为收紧) · 一次性迁移 M5 退役(持久数据面;行为变更;嵌入方 `OneTimeMigrationReport` 去两键〔BREAKING,类型面〕;跳过 7.104.0–7.135.x 直升的库补列与铸令牌要自己做) · `GET /v1/assistant/inbox` 行的 `objective` 改成 run 行的目标预览(wire 值变更) · 审批卡信封多一个键 `approvalCard`(整队一次滚完;回滚到 7.135.x 时待决卡按 fail-safe 出口收场) · k8s 工作区快照桶起服时核存在性:没建桶的部署起服拒(行为收紧;升级前确认桶在) · `WORKSPACE_SNAPSHOT_PREFIX` 成为 `/` 分隔的闭集路径:不合形起服拒、未配快照存储也核(行为收紧;同时放宽到多段) · 子进程的命令行停驻时只以封签落盘(安全;零动作,升级序与回滚要留意:先停光 7.135.x 副本再起第一个 7.136.0 副本)
+
+1. **中心登录令牌必须带 `scope` —— 不带的令牌自本版起验证不过(安全;行为面收紧,BREAKING;另含嵌入方类型面)**:鉴权桥(`SEMA_WEB_ADMIN_URL` 在位默认开,或 `AUTH_BRIDGE_ISSUER`)
+   验过签名之后按 settings-schema 的唯一读法 `readTokenScope` 读令牌的 `scope`:缺、空串、不是字符串 ⇒ 拒,拒因 `scope_claim_missing`(日志 `auth_bridge_rejected` 的 `error`、
+   计数 `auth_bridge_verify_total` 的 `outcome`),处置与验签不过同一条 —— 不设任何身份,配了 service 凭据的部署答 `401 auth.unauthorized`(通用体,不说拒因)。不读成缺省 scope `global`。
+   此前这类令牌被当作已验证身份受理、角色照读。
+   **升级序**:先把全部签发点(web-admin 各副本;split 部署里 `AUTH_BRIDGE_ISSUER` 指向的签发方)升到每一枚访问令牌都带 `scope` 的版本,**再过 ≥ 1 小时**
+   (访问令牌寿命上限 3600 秒,存量的无 `scope` 令牌到期自愈),然后升本服务。做不到就接受:窗口里拿着旧令牌的调用方验证不过,刷新或重登即恢复(刷新换出的访问令牌恒带 `scope`)。
+   没有过渡旋钮。升级后看 `auth_bridge_verify_total{outcome="scope_claim_missing"}`:非零 = 仍有签发点不打 `scope`,或调用方拿着旧令牌没刷新。
+   **嵌入方**(只影响自己给 `ServiceDeps.webAdminJwtVerifier` 写验证器的;部署零动作):`verify` 成功返回的 `identity.scope` 必填(非空串),失败返回的 `error` 多一个词
+   `scope_claim_missing` —— 你的验证器读不出 scope 就答失败;tsc 红即是提示,零别名。交出 `scope` 为空串(JS 侧:缺省 / 非串)的成功身份
+   在装身份之前同样被 `readTokenScope` 拒,与验证失败同答。
+
+2. **anthropic 车道两把凭据同设 ⇒ 起服拒(行为收紧;另含子路径端口的行为)**:`ANTHROPIC_API_KEY` 与 `ANTHROPIC_AUTH_TOKEN` 都非空的部署(7.135.x 照起、只发 `Authorization: Bearer`,
+   `x-api-key` 被丢弃)升级后起服拒,拒句带 `[config.anthropic_credential_conflict]`、点名两键、不回显值。**升级前做**:二选一 —— 端点要 Bearer 就只留 `ANTHROPIC_AUTH_TOKEN`
+   (与 7.135.x 实际发出的头相同,线上字节不变),原生 Anthropic API 只留 `ANTHROPIC_API_KEY`;空串仍算未设(compose 透传的 `${VAR:-}` 不算同设)。
+   自拼 `ServiceConfig` 的嵌入方:`anthropic` 同时带非空 `apiKey` 与 `authToken` ⇒ `createBrain` 构造即抛同一句(此前 Bearer 胜出)。读子路径 `@sema-agent/server/model-route-env` 的
+   `laneAndEndpointFor`:两把同设的 env 上抛同一句(此前答 `apiKeyEnvName: "ANTHROPIC_AUTH_TOKEN"`)—— 在引擎起之前调它的壳先按上面二选一收好 env,或接住这一抛。
+
+3. **一次性迁移 M5 退役:会话表的化身列不再由起服补加、空化身的行不再由起服铸令牌(持久数据面;行为变更;嵌入方 BREAKING,类型面)**:7.104.0 引入的启动期迁移 ——
+   给 `session_meta` 补 `incarnation` 列、给每一行空化身(`''`)铸一只互不相同的随机令牌 —— 窗(发布日 + 30 天)于 2026-10-28 关,本版提前于窗关删了它的码(窗内从 ≤ 7.103.x 直跳的库起服拒:先升到 7.104.0–7.135.x 任一版补列、起服一次,再升本版;「谁受伤」与「做法」写了顺序),
+   以及起服日志行 `one_time_migrations_applied` 里的两个读数字段 `sessionIncarnationColumn` / `sessionIncarnationsBackfilled`(同一行里 `removableAfter` 读数的 `M5` 键随登记行消失,`note` 不再叙述它)。
+   按这两个字段做告警或看板的规则要删。新库照旧由建表语句建出这一列,`DB_BACKEND=local` 的令牌在数据根边档里,这条迁移从来不碰。
+   - **嵌入方(类型面)**:`StoreBackend.runOneTimeMigrations()` 的返回型 `OneTimeMigrationReport`(经包根导出的 `StoreBackend` 可达,本身不在包根导出名里)去掉 `sessionIncarnationColumn` 与 `sessionIncarnationsBackfilled`;
+     读它们的代码、把值标成 `OneTimeMigrationReport` 再写这两键的对象字面量 tsc 红;自实现该方法、未标注类型就直接返回含这两键的字面量的代码 tsc 不报(多出的键没有人读),也请一并删掉。
+   - **谁受伤**:从 ≤ 7.103.x 直接跳到本版、中间没在 7.104.0–7.135.x 任一版起过服的 SQL 库(含升级后仍有 ≤ 7.103.x 旧副本混跑、写下空化身行的库)。两种形,都是响亮的,没有静默错答:
+     ① `session_meta` 没有 `incarnation` 列 ⇒ 起服列册对账拒启 `config.schema_mismatch`,拒句里的 `ALTER TABLE session_meta ADD COLUMN incarnation …` 由建表语句生成,照句补列即可起服 ——
+     **补列之后立刻会落进第 ② 种**(新列对每个存量行都是缺省空串);② 列在、行上是空化身 ⇒ 那条会话取不出来(`acquire` 响亮拒 `session.incarnation_missing`),要一位活住客的读者(parked 决定腿)同拒,记忆座退回按 id 绑定并 warn;
+     `session.incarnation_missing` 是内部错误码,日志可见,wire 上是通用 500。起过 7.104.0–7.135.x 任一版的库、新库、`DB_BACKEND=local` 与内存形零影响。
+   - **做法**(只在受伤时,二选一):**先在 7.104.0–7.135.x 任一版上对这只库起服一次**(那几版的起服迁移补列并逐行铸令牌),再升到本版;
+     或在本版上按 ① 的拒句补列后,给每个空化身的行填一只互不相同的随机令牌(不透明串,至多 64 个字符,UUID 即可;只改 `incarnation = ''` 的行,已有令牌的行一个字节不动),或删掉那些会话。
+     令牌不上 wire、不进模型上下文、日志只打前 8 位。
+
+4. **`GET /v1/assistant/inbox` 行的 `objective` 改成 run 行的目标预览(wire 值变更;键名与可空性不变)**:此前是停驻上下文里存着的任务目标**原文**(不截断、不脱敏),
+   本版起是门所属 run 的 `objectivePreview`(写入时已脱敏、约 120 字符,与 `GET /v1/assistant/tasks` 同一列;委派子代的门读派它的那条 run);没有 run 账本的部署 ⇒ `null`。
+   **消费方动作**:把 inbox `objective` 当完整目标用的(全文展示、按全文匹配),改读 run 详情面;盯运维计数 `server.assistant-inbox.objective-ctx-corrupt` 的看板改盯
+   `server.assistant-inbox.objective-preview-unreadable`(旧 tag 退役,不再计数)。
+5. **审批卡信封多一个键 `approvalCard`(滚动升级 / 回滚)**:本版写下的待决审批卡(`approval_ask.card_json`)带卡词,7.135.x 及更早的二进制读不动这类行
+   ⇒ 那张卡在旧副本上开流重放时跳过、同一只问幂等重入改走耐久停驻(人仍可经耐久决断口补批;不会被当成拒绝)。**动作**:整队一次滚完,不留长期混版窗;
+   回滚到 7.135.x 时,7.136.0 写下的待决卡按上面那条 fail-safe 出口收场,升回即自愈。
+
+6. **k8s 工作区快照桶起服时核存在性 —— 没建桶的部署起服拒(行为收紧;运维前置)**:`REMOTE_EXEC=k8s` 且配了对象存储(`MINIO_ENDPOINT` / `MINIO_ACCESS_KEY` / `MINIO_SECRET_KEY`)的部署,
+   起服时 server 对 `WORKSPACE_SNAPSHOT_BUCKET`(缺省 `workspaces`)指的桶做一次列举探针 —— 与会话快照桶(`SESSION_SNAPSHOT_BUCKET`)同一只探针、同一条规则:`404 + NoSuchBucket` ⇒ 在 `STORE_LOCK_WAIT_MS` 窗内重试、
+   到窗**起服拒**,拒句点名桶名、`WORKSPACE_SNAPSHOT_BUCKET` 与 `MINIO_ENDPOINT` 的显示安全形(不带密钥)。**server 不建桶**。7.135.x 上这种部署照起,之后每条 run 读 `latest` 得 404,
+   被当成「空间第一条 run」从空目录起,run 末保存失败(`workspace_snapshot_failed`)。连不上 / 403 / 5xx 这类证明不了缺桶的答复**不**拒启,走已登记的 fail-open 兜底口 `server.snapshot-bucket.presence-unproven`。
+   起服之后桶才没的(被删):读 `latest` 得 `404 NoSuchBucket` ⇒ 该 run 以 `connect_failed` 拒,句子与运维日志行 `workspace_snapshot_bucket_missing` 的 `code` 都是 `snapshot_bucket_missing`,不再读成新空间。
+   **升级前做**:确认 `workspaces` 桶(或你的 `WORKSPACE_SNAPSHOT_BUCKET`)存在 —— `mc mb <别名>/workspaces`,或把 `WORKSPACE_SNAPSHOT_BUCKET` 指向已有的桶。sema-up 的三条路径一直建 `workspaces`,不在受伤面。
+   不用工作区快照的 k8s 部署也在此列:对象存储三键一配,这只桶就是停驻挂起与跨轮保留共用的店,拒启的出路只有建桶 / 改指,没有关掉这次探针的旋钮。建桶晚于 server 起的编排:`STORE_LOCK_WAIT_MS` 窗内会重试。
+
+7. **`WORKSPACE_SNAPSHOT_PREFIX` 成为 `/` 分隔的闭集路径 —— 不合形起服拒(行为收紧;同时放宽到多段)**:前缀是一段或多段普通 key 段(`kata`、`libA/ws`),每段以字母或数字开头,其后字母、数字、`.` `_` `-`;
+   空段(前导 / 尾随 / 连续的 `/`)、`.` / `..`、其它字符 ⇒ **起服拒**,码 `config.workspace_snapshot_prefix_invalid`,句子点名第几段。🔴 **未配快照存储(`MINIO_*` 缺)也核**:此前这个值没有存储时根本不读,
+   拼错的值一直潜伏;现在 `REMOTE_EXEC=k8s` 的部署不论配没配存储,起服即核(别的车道不读这个值,杂散的值不拒)。配了存储的部署:7.135.x 对不合形的值在第一次连沙箱时才以
+   `unsafe snapshot key segment (keyPrefix)` 拒(只落在那一条 run 上),现在起服就拒;多段值(`libA/ws`)是新放宽,7.135.x 上同样在运行期被拒。合法的单段旧值行为不变。
+   **升级前做**:核 `WORKSPACE_SNAPSHOT_PREFIX` 的值,不合形的改成合形的;改前缀 = 换了一个 key 空间,旧前缀下的存量快照与 `latest` 不再被读 —— 要保留已有的快照就别改合形的旧值。
+8. **子进程的命令行停驻时只以封签落盘(安全;零动作,升级序与回滚要留意)**:stdio MCP 传输与 command hook 条目的 `command` / `args`(`args` 整只数组一个值)进凭据位,
+   与 env 同一条判据;续跑开封后逐字交执行器,调用方零改动。升级前停驻过的这类任务,命令行明文已经在库 / 盘(及其备份)里 —— 起服的一次性迁移在窗内(至 2026-11-20)把仍在的行原地封好,
+   已落过盘的字节改不回来:**轮换**这些命令行里出现过的密钥。
+   **多副本升级**:会停驻带 stdio MCP 或 command hook 任务的部署,先停光 7.135.x 副本再起第一个 7.136.0 副本(两版混跑时:7.135.x 副本续跑 7.136.0 停驻的这类任务 ⇒
+   整行 `409 conflict.checkpoint_ctx_unsealable`(`reason:"unrecognized_seal"`,`field:"credentialSlotGeneration"`);7.135.x 副本新写的这类行在 7.136.0 上续跑 ⇒ `409`(`reason:"plaintext"`),
+   直到下一次 7.136.0 起服的一次性迁移把它封好 —— 只在窗内)。**回滚到 7.135.x 之前**:用随包排空检查的 `sealed-credentials-rollback` 判据把带封签的停驻任务决掉或取消(这一类在候选里)。
+   三只拒句(`conflict.checkpoint_ctx_unsealable` 两句与装配期拒启)改成规则形,按句子字面匹配的脚本改按 `errorCode` / `field` / `reason` 读。
+
+## 7.135.0 —— 请求自带 MCP 的 `transport.url` 不得带凭据(新提交 400;安全) · `SANDBOX_PKG_SOURCE=custom` 的地址带凭据名参数起服拒(安全) · 嵌入方:技能的来处必填(`loadSkills` 第二参 `{ source }` 与 `LoadedSkill.source`;BREAKING,类型面) · 引擎 7.55.0:会话规则行的升级序(先升全部读者再放写) · 整协议名 `mcp__*` 在限制表上读成全部工具 · 属主收回自己加的会话规则条目 · 订正 7.134.0 节第 4 条:审批 `feedback` 拒改答 `resume_outcome_invalid`(原 `approval_binding_mismatch`) · 会话店接口只剩头读 `headOf`(嵌入方 BREAKING) · 文件历史读不全 ⇒ `503 state.file_history_unreadable` · journal 坏行 ⇒ `500 workflow.journal_incompatible` · MCP 工具结果两只新码 · `WebFetch(domain:<host>)` 的 deny / ask 按主机生效、参数不属于该工具的 deny / ask 规则受理口 422 / 续跑 409(安全;行为收窄) · `settings.hooks` 组 / 条目上读者不读的键新提交 `400 request.body_shape` · command hook 条目的 `plugin.options` 停驻时只以封签落盘(安全;回滚到 7.134.x 前先结掉带选项的停驻任务) · 耐久事件流开流不再读续跑输入判审批帧族(7.133.x 写下的在飞待决卡照重放;从 7.133.x 直升先停光旧副本) · SQL 后端 `permission_rule` 加一列 `grammar`(🔴 升级前先 `ALTER TABLE` 加列;持久数据,不能删表重建) · 会话 fork 不带在飞的 assistant 轮 · 技能条目自带的 `allowedTools` / `disallowedTools` 开始生效(升级序:先升全部读者,再在管理面写名单;放行免问是放宽方向,先审已有条目) · 请求自带的 `a2aPeers` 对端 / http 钩子 / 搜索后端地址带凭据(新提交 400;安全) · 设备车道有效工作目录非绝对路径的拒带终局码 `config.device_cwd_invalid`(续跑失败终局码多一词) · SQL 后端 `checkpoint` 加一列 `approval_card`(🔴 升级前先 `ALTER TABLE` 加列;表里是在飞的停驻,不能删表重建;嵌入方 `OneTimeMigrationReport` 多三键〔BREAKING,类型面〕) · 一次性迁移 M4 退役(行为变更;起服日志行 `one_time_migrations_applied` 少一个读数字段;嵌入方 `OneTimeMigrationReport` 去一键〔BREAKING,类型面〕;跳版升级的库含旧审计字节的那一页读不出,手工语句见第 22 条) · 嵌入方:审批决议的店接口 `ApprovalAskStore.decideAsk` 第三位插入必填 `owner`(BREAKING,类型面;部署零动作)
+
+1. **`mcpServers[i].transport.url` 带凭据 ⇒ 新提交 `400 request.field_invalid`**(安全;行为面收紧):url 带 userinfo,或带名字在凭据名表里的 query / fragment 参数
+   (`?api_key=` · `?key=` · `?token=` · `?access_token=` · `#access_token=` …;全表与读法见契约附录 A `request.field_invalid` 行)⇒ 新提交三腿与探测口 400,体带
+   `field: "mcpServers[i].transport.url"` 与 `reason`(`url_userinfo` | `url_credential_param`)。**升级前做**:调用方把这类凭据改写进 `transport.headers`
+   (如 `"Authorization": "Bearer …"`);只认 query 鉴权的服务端改在部署面(中心 / `config.d`)声明那台 MCP。按 `reason` 穷举分支的消费方多两个词。
+   升级前已停驻的任务照常续跑(重放存量请求不判),它们续跑上下文里那条 url 仍是原字节 —— 介意的部署把它们结掉后轮换那几枚凭据。
+2. **`SANDBOX_PKG_SOURCE=custom` 的六只地址带凭据名参数 ⇒ 起服拒**(安全):`SEMA_APT_MIRROR` / `SEMA_PIP_INDEX` / `SEMA_UV_INDEX` / `SEMA_UV_PY_MIRROR` / `SEMA_NPM_REGISTRY` /
+   `SEMA_NODE_MIRROR` 里有 `?token=` 一类参数的部署(7.134.x 照起、参数进沙箱环境)。**升级前做**:同 7.133.0 第 1 条 userinfo 的出路 —— 地址改成不带凭据的形,凭据走包管理器自己的通道;
+   源不需要认证就去掉那个参数。拒句点名 env 名与参数名,只回显 `scheme://host[:port]`。
+3. **嵌入方:技能的来处必填**(BREAKING,类型面;只影响自己装配 `ScenarioDeps.skills` 的嵌入方,部署零动作):场景卡新带技能清单 `skills[].source`(`"factory"` | `"center"`),
+   来处由铸技能的那条装载腿写下 ⇒ 包根导出的 `loadSkills(dir, opts)` 第二参必填且带 `source`,`LoadedSkill` 多一个必填成员 `source`。**升级时做**:
+   `loadSkills(dir)` 改成 `loadSkills(dir, { source: "factory" })`(读的是你自己的技能目录;读配置源 / 插件交来的技能写 `"center"`);手写 `LoadedSkill` 字面量的补上 `source`。tsc 红即是提示,零别名。
+4. **引擎 7.55.0:会话规则行的升级序 —— 先升全部读者,再放写(零 DDL)**:本版写下的每一行会话规则带文法戳 `4`(7.134.x 写的是 `2`)与一格 operator 部分 `operatorRules`。
+   7.134.x 及更早的副本读不了这样的行:整行拒(`500 corrupt` / 读不出),那条会话上的每一次工具调用都拒,直到该副本升级或排空 —— 它不把新行读成「更少的规则」。
+   **升级序**:先把读同一只会话规则店的**全部**副本升到本版,再放会话规则的写(`PUT /v1/sessions/:id/policy`、2c 同步导入);做不到就先排空旧副本。单进程部署零动作。
+   **回滚**:本版写下的行旧版读不了(同上的整行拒),而且在本版上重写一遍没有用 —— 本版的写口判官照样盖戳 `4`;旧版的 `PUT` 也改不了它(写前先读那一行,读不出 ⇒ `500 corrupt`)。
+   要回滚,这些会话在旧版上只有两种结局:每一次工具调用都拒(失效关闭),或删会话(规则随之删)。**不要**在库里把戳改回 `2`:同一条目在文法 2 里意思不同
+   (`toolDeny` 的 `mcp__*` 在文法 2 里什么也不拒),改戳 = 静默放宽。混版实测读数与部署前置写在仓库的部署前置清单(不随包)7.135.0 节。
+   **人的持久规则(同一件事的另一只店)**:引擎 7.55.0 起持久规则桶带文法戳,新文法写下的 deny(Bash 中段 `*` 的模式形、`Agent(<类型>)`)在 7.54.x 上**什么也不拒**
+   (旧引擎不读戳,把模式形读成「无形」)—— 同一份规则目录(`DB_BACKEND=local`)或同一只库不要混跑两版,先升全部进程;**降级到 7.55.0 之前**:先把这类 deny 改写成覆盖它的前缀 deny
+   或整工具 deny,或不降。SQL 持久规则店自本版起也写 / 读这只戳(`permission_rule` 加一列,见第 16 条),且**戳算进桶的完整性指纹**:本版副本读到更晚文法写下的桶整桶拒、每次调用问人;7.134.x 副本(引擎 7.54.1)不读戳,
+   但读到带戳的桶时指纹对不上、同样整桶拒(响亮),不会把新文法的 deny 读成「无形」而放行 —— 这扇窗在 SQL 后端上已关。同一只库仍不要混跑两版、先升全部进程(旧副本在被本版写过的桶上整桶拒,直到升级或排空)。人的持久规则店读不出(损坏,或由更新的引擎写下)时,
+   除引擎自己的问答 / 结构化输出 / 阻塞报告之外每一次工具调用都要问人,无人值守的运行拒 —— 修店或升级即恢复。
+5. **整个协议的名字 `mcp__*` / `mcp__*__*`(与 `a2a__*`)在限制表上是这一协议的每一只工具(行为变化,收紧方向)**:会话规则的 `toolDeny`、请求的 `settings.permissions.deny` / `ask`、
+   `excludeTools` / 子代 `denyTools`、运维 `APPROVAL_DENY` / `APPROVAL_REQUIRE` / `APPROVAL_NEVER_AUTO` 与中心下发的 `approvalRequire` 都按「这一协议的全部工具」读它
+   (此前:会话规则与请求的两桶、三张运维名表拒写,存量行里的 `mcp__*` 什么也不拒)。**升级前核**:存量会话规则行里写着 `toolDeny: ["mcp__*"]` 的会话,升级后拒每一只 MCP 工具,
+   而升级前存下的行整行都是 operator 的(见第 6 条),会话属主自己删不掉,只有 operator 重写。放行表(`APPROVAL_GRANT`、请求的 `settings.permissions.allow`、`allowTools`)照旧不收它。
+6. **会话规则:属主收得回自己加的条目;收不回 operator 写下的(行为变化;wire 加性键 `operatorRules`)**:行记下自己的 operator 部分(`GET` / `PUT` 回包与同步导出的 `rules.operatorRules`;
+   缺席 = 整行归 operator,含升级前存下的每一行 —— 存量行的读法不变)。非 operator 的写只能收回非 operator 写加上去的条目;动到 operator 部分 ⇒ `403 loosen_forbidden`,
+   句子换成 `a non-operator session-rule write may not loosen what an operator wrote; refused: …`(此前 `… may only tighten …`)—— 按句子匹配的脚本改读码。
+   客户端改规则时不要回传 `operatorRules`(与 `rev` / `gen` / `grammar` 同)。
+7. **订正 7.134.0 节第 4 条「话里带 `<system-reminder>` 标签 ⇒ `409 approval_binding_mismatch`」(引擎 7.55.0 起不再成立)**:这条拒现在带判别位,本服务答
+   **`409 resume_outcome_invalid` + `field: "feedback"`**(`retriable: true`,卡留 pending;出路 = 改那段话或去掉再决)。按 `errorCode` / `field` 分支的消费方加一臂;
+   7.134.x 的 worker 仍答旧码(混合舰队期间两形并存)。
+8. **会话店接口只剩头读 `headOf`(嵌入方 BREAKING,类型面)**:自建装配里实现 `OwnerAwareSessionStore`(或交给 `CachingSessionStore` 当内层店)的会话店,
+   按 id 读一行改实现 **`headOf(id)`** —— 一次读答 `{ owner, incarnation, leafId }`(属主 `null` = 匿名;没有这一行 = `undefined`;读故障就抛,不答「没有」)。
+   头答自会话**行**:只是会话条目(内容)读不出时,照答属主与住客 —— 本服务的授权门与各路由的属主门只读这两格,内容的故障留给门放行之后读内容的那一位
+   (头整只抛 = 谁来问都答 `500`,连门拒的调用方也读得出「这个 id 在、而且坏了」)。
+   `ownerOf` / `incarnationOf` / `sessionFaceOf` / `getHead` / `getLeafId` 五只读口不再被读(删掉;引擎 7.55.0 的会话店接口也不再有前两只)。
+   缺 `headOf` 的店:会话授权器在多租户部署答 `403`(不带码;单用户部署不设这道门),后台任务 / 唤醒通知 / MCP 重连三口答 `501 capability.session_ownership_required`(句子点名 `sessionStorage.headOf`),会话事件订阅 / 回卷 / 会话同步等能力位答 `false`。
+   用本服务自带会话店(SQL 两只、local、内存)的部署零动作。
+9. **会话同步拉取口新码 `503 state.file_history_unreadable`**:`GET /v1/sessions/:id/sync/manifest` / `…/sync/history/blobs/:hash` 遇到文件历史读不全(撕裂 / 读不出的边界)⇒ 503 +
+   `permanence`(`transient` 稍后重拉;`terminal` 先修店),此前当成「没有历史」答 200(同步零条 rewind 历史)。按状态码分支的同步脚本加一臂。
+   推送侧(同一条文件历史店契约):对 `capabilities.sessionSyncFileHistory` 为 `false` 的端点(`DB_BACKEND=local`)推引用 blob 的 `fileHistory` ⇒ 第一阶段 `422 missing_blob`(零暂存、零提交;7.134.x 先 `200`、对话提交后才 `422`),按能力位办事(`false` 的端点不带 `fileHistory`)的客户端不受影响;
+   `422` 重放臂的 `adopt_failed` 体多一个键 `permanence`(`transient` 稍后重试同一形;`terminal` 不重试、查 / 修云端文件历史店;没有该键稍后再推一次,仍红查店),预检后取不到的 blob 同样答 `missing_blob`。
+10. **`GET /v1/workflows/:id/journal` 坏行 ⇒ `500 workflow.journal_incompatible` + `ordinal`**:此前这几类行照常读回 200(文件后端跳过读不出的行、SQL 把读不出的行画成「超尺寸」存根)。
+   三个后端判的范围同一个:这条 journal 里任何一行(不论落在哪一页、不论多大;超 64 KiB 的行页里仍只出尺寸存根,但照样被判)被引擎的判官判坏 ⇒ 每一页都答本码,`ordinal` 点名按序数升序的第一条坏行 —— 与续跑的整次拒同判。
+   SQL 后端因此每次读面请求都分块读整份 journal(内存按块有界,量级不超过一次续跑的 `load`):对大 journal 反复轮询的脚本,看进度改用 `GET /v1/workflows/:id`(状态)或 `…/stream`,journal 读面留给翻历史。
+   local 车道的运维计数 tag `server.workflow-journal.corrupt-record-skipped` 撤线(文件 journal 店对坏行改整只拒,不再跳过),按它告警的改看逐命中 warn `workflow_journal_refused`。
+11. **MCP 工具结果多两只码 + 丢会话的读法**:`tool_end.errorCode` 可能是 `mcp.tool_declaration_changed` / `mcp.tool_listing_unreached`(引擎重拨后这只工具的声明变了 / 没被列到,
+   发出之前拒;出路 = `POST /v1/sessions/:id/mcp/reconnect`)。按封闭表穷举工具结果码的消费方加两词。服务器丢了会话(404)的那一次失败仍是 `http_status` + `delivered: "unknown"`
+   —— **不是**「可安全重试」(引擎已自己重拨并重发一次)。
+12. **`WebFetch(domain:<host>)` 的 deny / ask 按主机生效;参数不属于该工具的 deny / ask 规则被拒**(安全;行为收窄;随引擎 `@sema-agent/core` 7.55.0):
+    - 请求 `settings.permissions.deny` / `.ask` 里的 `WebFetch(domain:<host>)` / `WebFetch(domain:*.<域>)` 从「受理但从没生效」变成按调用实际到达的主机拒 / 问。
+      **升级前做**:过一遍写着主机形 deny / ask 的请求模板、壳设置与技能,确认这些拒 / 问仍是想要的(升级后它们开始拦);要整只拒取数写 `WebFetch`(不带括号)。
+      会话规则 `toolDeny`、技能 `disallowedTools`、`POST /v1/rules` 的 deny / ask 此前对主机形答 400,现在受理并生效 —— 无需动手。
+    - 同两桶里参数不属于该工具的 deny / ask(`WebFetch(foo:…)`、`WebSearch(domain:…)`、`TodoWrite(foo:…)`;判据是引擎目录里该工具能按规则读的参数)此前受理、永不命中,
+      现在新提交 `422 request.unprocessable`(句子带 `unsupported.param_unknown` 与该工具能写的参数),停驻任务的存量体带它们续跑 `409 resume_blocked_by_policy`(任务仍停着)。
+      **升级前做**:按句子删掉或改写这些条目(改成该工具自己的参数,或写整只工具);升级前停驻、存量体里带着它们的任务,升级后取消,按改好的设置重提。
+      自挂了与引擎内建同名的工具、在它多出的参数上写 deny / ask 的部署:给那只工具换一个引擎目录里没有的名字。
+13. **`settings.hooks` 的匹配组 / 条目上带 hooks 读者不读的键 ⇒ 新提交 `400 request.body_shape`**(行为面收紧;此前静默剥掉):体带 `unknownKeys`(全坐标,如
+   `settings.hooks.PreToolUse.0.hooks.0.onFailure`)。读者读的键:组上 `matcher` / `hooks` / `source`;command 条目上契约字段加 `plugin` / `args`;其余条目类型上各自的契约字段。
+   **升级前做**:原样投影宿主设置文件的调用方,投影前剥掉读者不读的键(参照实现 2.1.296 的 `onFailure` 等;用同一只契约分类器比对它携带的键即可),并告诉用户这个键不跑;
+   或升级后按拒体 `unknownKeys` 删键重提。续跑重放存量请求不判(这些键照旧剥掉)。
+14. **command hook 条目的 `plugin.options` 停驻时只以封签落盘**(安全;零动作):与 `settings.env` 同属凭据位,可以放敏感值(7.133.0 第 19 条「只放非敏感值」的约束随之退役)。
+   **回滚到 7.134.x 之前**:先把带插件选项的停驻任务决掉或取消 —— 7.134.x 不认这一位上的封签,续跑时那份 hooks 整只不采纳;随包排空检查的 `sealed-credentials-rollback` 判据把它们列为候选(超集)。
+   **多副本升级**:会停驻带插件选项的任务的部署,先停光 7.134.x 副本再起第一个 7.135.0 副本(两版混跑时:7.134.x 副本续跑 7.135.0 停驻的这类任务 ⇒ hooks 整只不采纳;
+   7.134.x 副本新写的这类行在 7.135.0 上续跑 ⇒ `409 conflict.checkpoint_ctx_unsealable`(`reason:"plaintext"`),直到下一次 7.135.0 起服的一次性迁移把它封好 —— 这只迁移只在 M28 窗内(至 2026-11-20)跑,窗外这类行停在 `409` 不再补封)。不带插件选项的任务不受影响。
+15. **耐久事件流开流不再读续跑输入判审批帧族;7.133.x 写下、仍在飞的待决卡照重放**(行为变化;升级序):本版起开流只按本 worker 的呈卡族重放(卡的存在本身证明这条 run 声明过该族,「卡作证」),7.134.0 那一读专为升级窗口里 7.133.x 在飞卡而设的过渡判退役。只影响从 7.133.x **直升**本版、且客户端渲染不了 `approval_request` 的部署:升级序 = 先停掉全部 7.133.x 副本(含它们宿主 run 名下仍在跑的后台子代),等它们写下的待决卡按各自的窗 / 悬挂窗到期并被对账收场,再放新客户端开流;经 7.134.x 中途升级的部署零动作。
+16. **SQL 后端:`permission_rule` 表加一列 `grammar`(🔴 升级前先加列;持久数据,不能删表重建)**:引擎 7.55.0 起人的持久规则桶带规则文法戳,SQL 两方言的店把它存在 `permission_rule.grammar`
+   (TiDB `INT NULL` / PG `INTEGER`)。本服务不发 `ALTER`:存量库缺这一列 ⇒ 起服列册对账拒启(`config.schema_mismatch`),拒句带可直接粘贴执行的语句。
+   **升级前做**:`ALTER TABLE permission_rule ADD COLUMN grammar INT NULL;`(PostgreSQL 写 `grammar INTEGER`)。已有的桶列读 NULL = 戳存在之前写下的桶,照读,下一次写盖戳。
+   **顺序**:先升库(加列)、再升副本 —— 加完列之后,仍是 7.134.x 副本(引擎 7.54.1)**再启动**会对多出的列拒启(只挡重启;已在跑的副本继续运行,它们不选这一列:本版写过(盖了戳)的桶它们读到指纹不符、整桶拒(响亮),
+   仍无戳的桶两版都照读照写,它们的写不盖戳、下一次本版的整桶回写盖章)。戳列与指纹同一条语句写;存量无戳行的指纹与升级前逐字节相同,升级不重写任何存量桶。**不要**手改 `grammar` 列(指纹对不上,桶整桶拒)。
+   **不要**删表重建 `permission_rule`:桶里是人的持久规则。`DB_BACKEND=local` 与内存后端零动作(文件后端的桶由引擎自己盖戳)。本版 SQL 副本读到晚于自己的戳整桶拒(码 `permission_rules.later_grammar`),
+   将来某一版文法再修订后,把库回滚到本版的运维会撞见这一拒:升级引擎即恢复。
+   **回滚到 7.134.x:只回退二进制不可行**(MySQL 协议与 PG 皆然)—— 加过列的库上,7.134.x 的起服列册对账把多出的 `grammar` 读成幽灵列、起服拒(`config.schema_mismatch`,拒句点名 `UNKNOWN column(s) grammar`、不给 ALTER),
+   失败发生在起服期,还没到下面「带戳桶整桶拒」那一步。回滚 = ① 先停光全部 7.135.0 副本(它们的 SQL 读写点名这一列,列没了而它们还在跑会在规则读写上报错);② 手工 `ALTER TABLE permission_rule DROP COLUMN grammar;`(两方言同一句);③ 再起 7.134.x —— **本版还加了 `checkpoint.approval_card`(第 21 条)这第二枚幽灵列**:只摘这一枚,7.134.x 仍被另一枚拒启;两条回滚段的 ①② 合起来做一遍(停光副本一次、两句 `DROP COLUMN` 都执行)再起旧版。
+   **DROP 会丢掉列里的戳**:戳在桶的指纹里,丢了之后带戳的桶在任何版本上指纹都对不上 —— 想保住日后升回本版的可能,在**停光全部 7.135.0 副本之后、DROP 之前**把戳存进一张表(停光之前存的不算:存完之后仍在跑的 7.135.0 副本再盖的戳会随 DROP 永久丢失,那只桶在任何版本上都整桶拒):
+   `CREATE TABLE permission_rule_grammar_stash (owner_key VARCHAR(190) NOT NULL PRIMARY KEY, grammar INT NOT NULL);`(PostgreSQL:`owner_key VARCHAR(190) COLLATE "C" NOT NULL PRIMARY KEY, grammar INTEGER NOT NULL`),
+   再 `INSERT INTO permission_rule_grammar_stash SELECT owner_key, grammar FROM permission_rule WHERE grammar IS NOT NULL;`。升回时先照「升级前做」加列,**写回放在加列之后、起第一个 7.135.0 副本之前**(这时没有写者):
+   MySQL 协议 `UPDATE permission_rule p JOIN permission_rule_grammar_stash s ON s.owner_key = p.owner_key SET p.grammar = s.grammar WHERE p.grammar IS NULL;`,
+   PostgreSQL `UPDATE permission_rule p SET grammar = s.grammar FROM permission_rule_grammar_stash s WHERE s.owner_key = p.owner_key AND p.grammar IS NULL;`;
+   `grammar IS NULL` 只补还没有戳的行(这些桶在 7.134.x 上整桶拒;桶体与指纹没有写者改过〔取 dot 的计数器可能前移,它不在指纹里〕)。写回之前起的 7.135.0 副本对这些桶整桶拒(指纹对不上;响亮、无害),写回后恢复;核对无误后 `DROP TABLE permission_rule_grammar_stash;`。
+   DROP 之后:本版写过的桶(带戳)7.134.x 读不了、整桶拒(它不读戳,指纹对不上;响亮)—— 留在本版或更新;没被本版写过的桶(列 NULL)两版照读照写。
+17. **会话 fork 只拷已提交的叶(行为修正)**:`POST /v1/sessions/:id/fork` 与 Fork 工具经宿主会话店铸的孩子会话不再带源会话在飞的 assistant 轮(带一个还没有结果的工具调用的那一轮)—— 孩子从它的父开始;
+   已结的轮整份拷。此前三只会话店拷整份日志,孩子唤醒时被补一条 `[INTERRUPTED]` 结果。零动作;按「fork 一定含在飞轮」写脚本的(未见)改读孩子的实际条目。
+18. **技能条目自带的两只工具名单 `allowedTools` / `disallowedTools` 开始生效(行为变化;升级序;零 DDL)**:配置源 —— 中心的技能域或 `CONFIG_PROVIDER=local` 的 `config.d/skills.json` —— 里技能条目写着这两个键的,
+   此前本服务的 worker 不把它们交给引擎(静默无效),本版起交:`allowedTools` 是该技能被激活的那一 run 的 allow 规则来源(免问;deny / ask、plan 模式、组织上限与强制提问照旧站着),
+   `disallowedTools` 是 deny 规则来源,拒侧引擎读成空的条目(例:`*`)⇒ 那次激活不发生(`userInvokedSkills` 按名点用的:终局 `failed`、码 `config.skill_deny_unreadable`;模型自己调 `Skill` 工具的:那一次调用被拒、错误结果回给模型)。缺席 ⇒ 没有;在场 ⇒ 整只原样(`[]` 引擎读作未声明)。
+   **升级前做**:① 过一遍已经写着这两个键的技能条目,确认它们现在生效是想要的(放行免问是放宽方向,先审);② **升级序**:先把读这条链的每一跳都升上来(本服务各副本,以及其它读 `/effective` 技能域的读者,例如 client-core 的云端腿),再在管理面给技能写名单 ——
+   没升的读者静默丢这两位,丢 `disallowedTools` 就是比作者所写更松。不想让某条技能带名单就删掉这两个键。
+19. **`a2aPeers[i].url` / `.cardUrl`、`settings.hooks` 的 http 钩子 `url`、`settings.webSearch.endpoint` 带凭据 ⇒ 新提交 `400 request.field_invalid`**(安全;行为面收紧;第 1 条同一条规则的另三座):
+   URL 带 userinfo,或带名字在凭据名表里的 query / fragment 参数(全表与读法见契约附录 A `request.field_invalid` 行)⇒ 新提交三腿 400,体带 `field`
+   (`a2aPeers[i].url` | `a2aPeers[i].cardUrl` | `settings.hooks.<事件>[g].hooks[h].url` | `settings.webSearch.endpoint`)与 `reason`(`url_userinfo` | `url_credential_param`)。
+   **升级前做**:调用方把凭据挪进同一条目的已封签位 —— 对端 / 钩子条目的 `headers`(`"Authorization": "Bearer …"`;钩子的 `headers` 可用 `$NAME` + `allowedEnvVars` 让配置本身不带密钥值),搜索后端的 `apiKey`;
+   只认 query 鉴权、不收请求头的服务端(含 searxng 实例:searxng 腿不发鉴权头)改在部署面声明。搜索后端地址的 userinfo 形此前已是 400,句子不变,体多 `field` / `reason`。
+   续跑重放存量请求不判(升级前停驻的任务照常续跑,续跑上下文里的 URL 仍是原字节 —— 介意的部署把它们结掉后轮换那几枚凭据);部署面声明的地址(中心 / `config.d` / 部署 env)不判。按 `field` 坐标或 `reason` 穷举分支的消费方多认这四个坐标。
+   **同批的行为变化**:一次提交的 `a2aPeers` 超过 32 条(读器的挂载上限)⇒ 新提交 `400 request.field_invalid`,`field:"a2aPeers"` · `reason:"over_cap"` · `count` · `cap`(此前 200,第 33 条起丢弃、只在运维 warn 里点名):界外的尾项从不挂载,但提交体整份落盘,上面那条判官要么看过每一条对端的 `url` / `cardUrl`、要么这份体不收。升级前把一次提交的对端数压到 32 以内。
+20. **设备车道:有效工作目录不是绝对路径的拒带终局码 `config.device_cwd_invalid`**(7.134.0 节第 8 条「工厂的其余几只拒同样带机读码」漏了这一只,本版补齐):会话 cwd / 委派链父 cwd / 入籍时落库的 `workspaceRoot` 任一来源不是绝对路径
+   (入籍口收紧之前落库的相对根,或引擎交来的相对父 cwd)⇒ 续跑失败的终局码 `config.device_cwd_invalid`(修前这一形抛裸错误,终局码不带它;句子不变,多一段 `[config.device_cwd_invalid]`)。
+   按终局码匹配续跑失败的读者(运维看板 / 重试规则)把它与 7.134.0 节列的四个词一并认进去;它是装配 / 数据错误,重试无益 —— 出路是修有效工作目录的来源(重新入籍给绝对路径)。
+21. **SQL 后端:`checkpoint` 表加一列 `approval_card`(🔴 升级前先加列;持久数据,不能删表重建;嵌入方 BREAKING,类型面)**:检查点店写行时把门上的审批卡词照存进这一列(引擎 7.55.0 的行事实派生),
+   到期两条腿(收割作废 / SLA 拒扫)与运维待批队列行的卡读它。本服务不发 `ALTER`:存量库缺这一列 ⇒ 起服列册对账拒启(`config.schema_mismatch`),拒句带可直接粘贴执行的语句。
+   **升级前做**:`ALTER TABLE checkpoint ADD COLUMN approval_card TEXT NULL;`(PostgreSQL 写 `ALTER TABLE checkpoint ADD COLUMN approval_card TEXT COLLATE "C";`)。
+   升级前停驻、升级时还挂着的行由起服的一次性迁移按同一只派生补上这一列(待决的审批门行;文档读不出的行留空,起服日志 `one_time_migrations_applied` 的 `parkedApprovalCardsBackfilled` /
+   `parkedApprovalCardRowsUnreadable`(条数),并一行 warn `parked_approval_card_row_unreadable` 点名会话;卡词超过列容量 —— MySQL 协议 `TEXT` 65,535 **字节**、PG 无上限 —— 的行同一个报法:留空、计数在 `parkedApprovalCardRowsTooLong`,并一行 warn `parked_approval_card_row_too_long` 点名会话(另带字节数),起服不挡:引擎铸的卡词是短词,超长只会是手改的行)。**顺序**:先升库(加列)、再升副本 —— 加完列之后,仍是 7.134.x 的副本**再启动**会对多出的列拒启;同一只库不混跑两版(与第 4 / 16 条同一升级序):
+   已在跑的 7.134.x 副本写下的问答停驻行不带这一列,在下一次本版起服之前到期会进 SLA 拒扫(引擎拒收,行停到绝对兜底)而不是作废;7.136.0 起这些行在拒扫选行里排在带卡词的审批行之后,不再挤占后者的取行窗(卡列同为空的审批行之间仍按到期序,先停光旧副本再起新仍是规避)。
+   **不要**删表重建 `checkpoint`:表里是在飞的停驻(待批的卡、待审的计划)。`DB_BACKEND=local` 与内存后端零动作(停驻行在引擎自己的文件店里,卡从文档读)。
+   **回滚到 7.134.x:只回退二进制不可行**(MySQL 协议与 PG 皆然)—— 加过列的库上,7.134.x 的起服列册对账把多出的 `approval_card` 读成幽灵列、起服拒(`config.schema_mismatch`,拒句点名 `UNKNOWN column(s) approval_card`、不给 ALTER)。
+   回滚 = ① 先停光全部 7.135.0 副本(它们的停驻写与待批队列读点名这一列,列没了而它们还在跑会报错);② 手工 `ALTER TABLE checkpoint DROP COLUMN approval_card;`(两方言同一句);③ 再起 7.134.x —— **本版还加了 `permission_rule.grammar`(第 16 条)这第二枚幽灵列**:只摘这一枚,7.134.x 仍被另一枚拒启;两条回滚段的 ①② 合起来做一遍(停光副本一次、两句 `DROP COLUMN` 都执行)再起旧版。
+   DROP 只丢这一列(派生数据):停驻行自己的文档(卡词在门上)一个字节没动,7.134.x 照旧从文档读卡;再升回本版时先照本条加列,窗内 M29 把待决的审批门行重新回填。
+   **嵌入方(类型面,BREAKING)**:`StoreBackend.runOneTimeMigrations()` 的返回型 `OneTimeMigrationReport` 多三个必填键 `parkedApprovalCardsBackfilled`(条数)/ `parkedApprovalCardRowsUnreadable` /
+   `parkedApprovalCardRowsTooLong`(后两者是点名行的数组),`NO_SQL_MIGRATIONS` 同步多三键(local 车道恒 `0` / `[]` / `[]`)。自实现 `runOneTimeMigrations()` 的代码(实现 `StoreBackend` 的店,或标了这只返回型的函数)tsc 红 —— 补上三键;
+   只读这份报告的代码不受影响(多出的键没有人读)。部署零动作。
+22. **一次性迁移 M4 退役:审计明细里的 JSON 文本 `null` 不再由起服改写(持久数据面;行为变更;嵌入方 BREAKING,类型面)**:7.93.5 引入的启动期迁移 ——
+   把设备审计表 `device_audit` 的 `detail` 列里 JSON 文本 `null`(7.93.4 及更早的写腿对显式 `detail: null` 落下的旧字节)改成 SQL NULL —— 窗(发布日 + 30 天)已关,本版删了它的码,
+   以及起服日志行 `one_time_migrations_applied` 里的读数字段 `auditDetailJsonNullRows`(同一行里 `removableAfter` 读数的 `M4` 键随登记行消失,`note` 不再叙述它)。按这个字段做告警或看板的规则要删。
+   - **嵌入方(类型面)**:`StoreBackend.runOneTimeMigrations()` 的返回型 `OneTimeMigrationReport`(经包根导出的 `StoreBackend` 可达,本身不在包根导出名里)去掉 `auditDetailJsonNullRows`;读它的代码、把值标成 `OneTimeMigrationReport` 再写这一键的对象字面量 tsc 红;自实现该方法、未标注类型就直接返回含这一键的字面量的代码 tsc 不报(多出的键没有人读),也请一并删掉。
+   - **谁受伤**:从 ≤ 7.93.4 直接跳到本版、中间没在 7.93.5–7.134.x 任一版起过服的库(含升级后仍有 ≤ 7.93.4 旧副本混跑写入的库)—— 设备审计表里留着 `detail` 为 JSON 文本 `null` 的行时,
+     含这种行的那一页 `DeviceStore.listAudit()` 读不出来(整页拒,拒句点名行 id;刻意不逐行跳过 —— 跳过会把「这一页少了一条」与「本来就没有」变成同形)。本服务自带的 HTTP 面没有路由读这张表,读它的是嵌入方与运维脚本。
+     起过 7.93.5 及以后任一版的库、新库、`DB_BACKEND=local` 与内存形(没有设备审计表)零影响。
+   - **做法**(只在受伤时):要么先在 7.93.5–7.134.x 任一版上对这只库起服一次(迁移跑完)再升;要么在本版上手工跑下面一句(幂等,可重复跑;只碰 JSON 文本 `null` 的行,真有明细的行与本来就是 SQL NULL 的行一个字节不动):
+     - TiDB / MySQL 协议:`UPDATE device_audit SET detail = NULL WHERE detail IS NOT NULL AND CAST(detail AS CHAR) = 'null';`
+     - PostgreSQL:`UPDATE device_audit SET detail = NULL WHERE detail IS NOT NULL AND detail::text = 'null';`
+23. **嵌入方:审批决议的店接口 `ApprovalAskStore.decideAsk` 第三位插入必填 `owner`**(BREAKING,类型面;部署零动作):经包根导出型 `StoreBackend` 的 `approvalAsk()` 成员可达的问答账本店,
+   人答臂的签名由 `decideAsk(askId, batchId, decision)`(7.134.0)改成 **`decideAsk(askId, batchId, owner, decision)`** —— `owner: string | null` 必填、无缺省,是这次决议的门**判过的**那位属主
+   (门读到的行上 `owner` 列;不是调用方的主体:运维代决别人的问,传的是那个别人;`null` 只等于属主为 `null` 的行)。tsc 红即是提示,零别名。
+   **升级时做**:① 调用 `decideAsk` 的嵌入方代码补上第三参;② 自实现该店(自建 `StoreBackend`,`approvalAsk()` 返回你自己的店)的嵌入方,把「行上的属主列逐字等于 `owner`」并进单赢者 CAS 的谓词
+   (与问 / 批 / 仍待决并列;MySQL 协议侧按字节比,尾空白不算同一位属主):行此刻不带这位属主(门读行之后被 `POST /v1/adoption` 改写)⇒ 不决、零写,答
+   `{ ok: false, reason: "ask_not_pending", row: null }` —— 输者读数里该行读作缺席(不交出别人的行),这一判排在幂等键唯一性之前(出域的那一笔不碰键)。两扇决议门把它读成缺席,与「不存在 / 不是你的」同体同码:
+   耐久回决口 `404 not_found.ask`、live 应答口 `404`(`cause: unknown_or_other_replica`)。本服务自带三店(SQL 两方言、local、内存)已是这个读法,用它们的部署零动作。
+
 ## 7.134.0 —— 停驻任务续跑上下文里的请求凭据只以封签落盘(安全;BREAKING,嵌入方自建 ServiceDeps 带 checkpointStore 必须带 checkpointCtxSealing,否则 createHttpServer 拒启;保管目录建不了的耐久审批部署起服拒;保管目录跨重启持久、多副本共享;先停光 7.133.x 再起 7.134.0,两版不能混跑;一次性迁移 M28) · 引擎 7.53.0 → 7.54.1 提货:先升所有会续跑的 worker(停驻行多两只要求词) · 设备车道发射闸的三条部署前置 · 决定体 `feedback`(人的放行带的话;拒决 / 策略上 400、直连门 400) · `APPROVAL_AUTO_BUDGET` 的放行改记成策略答的放行 · `mcpServers[].toolFaces` / `startupTimeoutMs` 坏形新提交 400 · 请求侧 `toolAxes` 写 `boundaryFlow` 被拒 · 设备车道文件失败码 `target_unavailable` 与换绑后的续跑拒 · placed 会话准入拒句换成引擎的句子 · 带主体头的 service 凭据请求在 fleet 面上就是那位主体(安全;BREAKING:行为面收窄(多租前端带主体头的运维脚本不再看全舰队,升级前核)+ 类型面(嵌入方自实现的会话店暂存导入)) · 审批卡只发给声明认得这一族的客户端(请求面 `settings.approvalFrameFamilies`;没声明的任务遇审批当场停驻 / 拒;BREAKING,wire;客户端先升,见位才发)
 
 1. **停驻任务续跑上下文里的请求凭据只以封签落盘**(安全;BREAKING,嵌入方自建 ServiceDeps 带 checkpointStore 必须带 checkpointCtxSealing,否则 createHttpServer 拒启):开了耐久审批的部署(`DURABLE_APPROVAL`;单用户 + 有耐久店时缺省开,含 `DB_BACKEND=local`),任务提交体里 `mcpServers[].transport.headers` / `transport.env` 的值、
@@ -22,7 +218,7 @@
    - **升级序:7.133.x 与 7.134.0 不能混跑**。**先停掉全部 7.133.x 副本,再起第一个 7.134.0 副本**(一次性迁移 M28 在它起服时跑,把升级前停驻行里的明文原地封好:不删行、不动续跑时钟;
      起服 info 一行 `checkpoint_ctx_credentials_sealed`;M28 的窗 = 发布日 + 30 天,窗外不扫)。多副本:先起一个 7.134.0 副本、等它起好再起其余副本(耐久审批开着时它起好即打出上面那一行)——
      停驻封签的钥匙在新子目录 `sealed-key/checkpoint-ctx-keys/` 里,升级后第一个起服的 7.134.0 副本生成它(`sealed-key/` 早已共享好也一样:那是模型钥匙的那一层);
-     同时起多个副本会各建一把,互相答 `key_not_held`,直到各自重启一次(钥匙只在起服时读目录里的全部文件)。混跑时 7.133.x 副本续跑一条已封签的行(M28 封过的,或 7.134.0 副本新写的)会把凭据位当空值 ——
+     同时起多个副本可能各建一把:钥匙创建是先读目录、没读到可用的钥匙文件才生成并写入,没有互斥 —— 只有两个副本在同一个目录上同时首启、都没读到可用的钥匙文件时才各建一把;各建了就互相答 `key_not_held`,直到各自重启一次(钥匙只在起服时读目录里的全部文件);等第一个副本起好再起其余,其余副本读到的就是它写下的那一把。混跑时 7.133.x 副本续跑一条已封签的行(M28 封过的,或 7.134.0 副本新写的)会把凭据位当空值 ——
      MCP 的 `headers` / `env` 整键不交(server 照挂)、A2A 对端不挂、`settings.env` 不采纳、WebSearch 不挂、`settings.hooks` 整份不采纳(同一份里的 command hook 一起)—— 任务无凭据照跑、不报错
      (只有运维日志各一行 warn);7.133.x 的续跑读者没有对封签值的拒臂,新版本改不到它。反过来,7.133.x 副本新写的明文行在 7.134.0 副本上续跑答 409 `reason:"plaintext"`。
    - **回滚**:降级到 7.133.x 之前先把带凭据的停驻行结掉(决定或取消);已封签的行在 7.133.x 上同样是无凭据续跑、不报错。随包排空检查的 `sealed-credentials-rollback` 判据列出它们: