@sema-agent/server 7.148.0 → 7.150.0

package/MIGRATION.md

@@ -4,10 +4,553 @@
 > (内部多 AI 协作节奏,当日通告+实解)。**生产部署请锁精确版本**;GA 后 2.0 起严格 semver
 > (BREAKING → major)。本文件只记录会影响存量部署行为的变更。
 >
-> ⚠️ 完整清单在仓库根 `CHANGELOG.md`——它**不随 npm tarball 出包**(本文件随包)。看完整迁移窗的
-> 权威姿势是源码 tag diff:`git diff v<旧>..v<新>`(每版都推 `v<版本>` tag);npm 包页也镜像 CHANGELOG。
+> ⚠️ 升级要做的动作都在本文件里:从哪一版升到哪一版,就把中间每一版的节从上往下读完(每节的「升级前做」「出路」「回滚」就是那一版要你做的)。
+> 本文件只记会影响存量部署行为的变更:某一版没有节,即那一版没有记入这里的升级动作;完整的变更流水账(修复、文字订正、内部重构)是内部记录,不随 npm 包出。
 > 文中的「契约 §N」「契约附录 X」指服务端 wire 契约的节号(内部记录,不随包),只作查证坐标。
 
+## 7.150.0 —— 1–12 条见下
+
+**升级清单(本节唯一的一张;下面各条只讲为什么,不再各自重述升级步骤)** —— 一次读清本版对一只存量部署要做的全部动作。每版同形:① 手工 DDL(逐表逐句,两方言各一份)② 起服自建与一次性迁移 ③ 停-迁-起 ④ 顺序;后续每版的段头照此写,新增一句 `ALTER`、一条一次性迁移、一条停-迁-起时,先改这里,再写条目。
+已发各节(7.149.0 及以前)逐字只读,不在原处补汇总 —— 跨过它们的部署读下面「跨过 7.149.0」一块。起服拒句是同一张清单的运行期形:缺列拒、单表探针拒、一次性迁移的判活拒,每一句都带「这只库此刻还差哪些 `ALTER`、哪些迁移要先停光旧副本、先后顺序」,一次起服读全,不必补一句再试一次。
+
+- **从 7.149.x 升级到本版**:
+  - 手工 DDL:**无**。
+  - 起服自建(运维零手工):`replica_registration` · `serving_requirement`(两张新表,`CREATE TABLE IF NOT EXISTS`;第 7 条「副本能力登记与起服准入两张常设表」)。
+  - 一次性迁移:M52 停-迁-起证据读法的心跳一半(不改库;同一条)。
+  - 到期移除的一次性迁移:**M12**(停驻行模式词读法记号的拒臂;7.122.0 引入,窗 2026-11-08 关)本版删码(第 1 条「一次性迁移 M12 退役」)—— 从 ≤ 7.121.x(M12 起始版 7.122.0 之前)直升本版的部署,**须先经过含 M12 的版本**(7.122.0–7.149.x 任一版)起服并让那几版上停驻的 run 走完或决掉,再升本版;直升的话,`AUTONOMY=plan` 部署上 7.121.x 及以前写下、此刻仍停驻的行不再被拒,按体里的原词续跑。从 7.122.0–7.149.x 升级的部署零动作。
+  - 停-迁-起:**无新增**,本版条目没有一条要求停光旧副本。已有几条(M40 · M41 · M42 · M51)的守卫证据本版改读「判活窗内心跳过、持有者没登记为知道这条迁移的 `running` run」(同一条);停光旧副本这一步不变,仍是运维的第一道。
+  - device 车道(`REMOTE_EXEC=device`):**先把设备执行器升到声明设备协议修订 5 的版本,再换服务端版本** —— 本版只受理修订 5,声明 4 及以下的执行器在 hello 被拒、连不上(第 12 条)。
+  - 顺序:① 备份 ② device 车道先升执行器 ③ 换版本(可滚动)。
+- **跨过 7.149.0(从 ≤ 7.148.x 直升本版)另加 7.149.0 节段头升级清单的全部动作**(那一张已含「跨过 7.148.0」一块):手工 DDL、停光旧副本与起服顺序照那一张做;守卫的证据按本版的读法判(上一块「停-迁-起」一行)。
+
+1. **一次性迁移 M12 退役:续跑重放不再问「停驻行有没有模式词读法记号」;`AUTONOMY=plan` 的部署上,7.121.x 及以前写下、此刻仍停驻的行不再被拒,按体里的原词续跑(持久数据面;行为变更;运维日志的 `kind` 少一个取值;wire 零新键、零新码,`checkpoint.unsupported_version` 少一个自铸臂;嵌入方包根导出无变化;部署零动作,除非 `AUTONOMY=plan` 的部署上还留着这类停驻行)**:
+    7.122.0 引入的一条一次性迁移,窗(发布日 2026-10-09 + 30 天)于 2026-11-08 关,本版删了它的码:模式词读法记号的判据与拒臂(那句「this task was suspended by an earlier server version that re-applied this deployment's AUTONOMY on every resume …」不再出现)、提交入口与 `plan_review` / 在飞切档两处写回对记号的写、续跑上下文上的记号位。
+    旧形:7.122.0–7.149.x 每一次新的持久化写都在续跑上下文上盖记号;本部署设了 `AUTONOMY=plan`、而行上没有记号(7.121.x 及以前写下)、体的生效词被地板钳会变 ⇒ 续跑重放前 409 `checkpoint.unsupported_version`(行字节不动,运维行 `resume_refused_stored_body` 带 `kind: "permission_mode_reading"`)。
+    新形:不再问这一句。续跑照体里的词读:本版写下的行,体词在提交入口已盖过地板,读到的就是它;7.121.x 及以前写下的停驻行体里是请求原词,运维的 plan 不再被按段重钳 —— 不经 `plan_review` 的续跑腿(`/decide` · `/resume` · `/wake`)上 `acceptEdits` / `bypassPermissions` 一类原词直接生效(`plan_review` 的驳回仍由引擎留在 plan,写撞 plan 门)。存量行上已写下的记号键原样留着、无人读;新写的行不再带它。没有响亮的起服臂。
+    谁需要:无。**谁受伤**:`AUTONOMY=plan` 的部署上仍有 7.121.x 及以前写下的停驻行(把 `APPROVAL_TERMINAL_BACKSTOP_MS` 调长的部署,或从 ≤ 7.121.x 直接升到本版的库)—— 这类行续跑时不再被拒,按原词重放;按那句 409 或 `kind: "permission_mode_reading"` 做告警的运维。
+    补偿:升级前把这些停驻的 run 决掉 / 取消,或升级窗内设 `AUTONOMY=read-only`(按段的只读围栏);常规从 7.149.x 升级的部署无须动作。回滚(本版 → 7.122.0–7.149.x):本版写下、体词已被 `plan_review` 批准松开的行不带记号,在回滚后设了 `AUTONOMY=plan` 的部署上会被那一版的模式词问拒(409 `checkpoint.unsupported_version`;出路 = 取消后作为新任务重提)。
+
+2. **项目上下文继承:提交的 run 从本部署的项目登记簿继承项目简报与工作目录,只在登记带中心内容证明 `contentAttestedAt` 时生效(能力位 `projectInheritance`;行为加性;wire 加性:能力位一键、两类拒的坐标并集多 `projectId`;零新码;部署零动作)**:
+    规则:继承读这条腿交给引擎的项目(提交带的 `projectId`,否则会话行上声明过的)。登记对提交者在 `GET /v1/projects/:id` 读得到(同一只可见性判)且带内容证明 ⇒ `goal` / `notes` / `note` 条目折成一段项目简报,进系统提示的追加折叠(序 `appendSystemPrompt` → 简报 → `settings.outputStyle`,共一只 16384 帽);能力位 `projectContext` 为真的部署(单主 host)上另列 `folder` / `file` 条目的名字(只列名字,不读、不附),第一条 `folder` 填缺席的请求 `cwd`。新提交时判一次,随 run 落进续跑重建输入,续跑只重放。契约 §G.9g.1。
+    谁受伤与出路:① 端已自行把项目内容拼进 `appendSystemPrompt` ⇒ 重复 —— 读到 `projectInheritance: true` 就停拼;② 请求自带的追加段接近 16384 ⇒ 加上简报超帽,400 `request.field_conflict`(`reason: "system_prompt_fold"`,`fields` 含 `projectId`)—— 缩短追加段、带 `projectMemory: "disabled"`,或在中心缩短登记的 goal / notes;③ 升级前写下的项目内容不带内容证明 ⇒ 不生效,直到在中心按 publisher 角色重存一次;④ 多租部署上可见性只认 `registeredBy`,团队成员拿不到管理员登记的项目的简报;⑤ 改登记 ⇒ 之后提交的系统提示前缀变一次;⑥ 会话先前显式给过 `cwd`、这一次提交不带 ⇒ 这一次落到项目的第一条 folder —— 每次提交都带 `cwd`;⑦ 继承来的 `cwd` 落在会话 scratchpad ⇒ 400 `request.field_conflict`(`reason: "scratchpad_root"`,`fields` = `["projectId"]`)—— 提交带一个 scratchpad 之外的 `cwd`,或把登记的第一条 folder 挪出来。
+    回滚(本版 → 上一版):续跑重建输入多一格 `projectContext`;上一版开它时原样保留、不读 ⇒ 本版停驻的 run 在上一版上续跑没有项目简报,继承来的工作目录也不重登记(新进程上落到部署缺省目录)。续跑照跑、不拒。要它们带着项目上下文续跑完,先在本版上排空停驻再回滚。
+
+3. **服务租约围栏:心跳答复没有 `capabilities` 键(老中心 `{ ok: true }`、网关 / 维护页 `{}`)不再读成「中心不宣告」—— 已授予的租约照旧、钟照走;只有中心的显式声明对象才开关围栏(依赖 settings-schema 25.0.0;行为收紧;wire 零变化;部署零动作,除非心跳打到不带键的后端)**:
+    旧形:这样的答复读成 `undeclared` ⇒ 交「没宣告」⇒ 已授予 / 已过期的租约当拍回到 `none`(零续租、零 503),outage 钟随之失效 —— 一个指错的活性基址或回滚前的中心就能解除围栏。
+    新形:它与读不出的答复(空体 / 截断 / 非对象 / 形坏的 `capabilities`)同一只臂 —— 不是读数,租约的状态与钟原样(到期之前 `granted`,过期后 `expired`,满 `FLEET_LEASE_OUTAGE_MAX_MS` 后新工作 503 `state.lease_expired`),每拍计 `server.fleet.announce-reply-unreadable`,一段连拍一行 warn `fleet_announce_reply_unreadable`(`why: capabilities-absent`)。中心显式声明而不带 `servingLease`(`{ capabilities: {} }`)⇒ 照旧回到 `none`。从没收到过声明的成员见第 6 条(起步即推定在围栏内)。
+    补偿:让心跳路径答到带 `capabilities` 键的中心(升级它,或修正 `SEMA_WEB_ADMIN_LIVE_URL`);不要围栏的成员去掉 `FLEET_GENERATION`。
+
+4. **会话历史里的 MCP 授权记录只剩 `{ reason }`;授权记录的每一个投影面同读一张处置表**(安全轴收窄;行为变更;部署零动作)
+    改了什么:`GET /v1/sessions/:id`(整读 / `?tail` / `?before` / `?blobCap` / `?message=N`)里,工具结果卡 `details` 是 MCP 授权失败卡(`code: "unauthorized"` 且带 `authorization`)时,
+    `authorization` 只剩 `{ reason }`(词出闭集 ⇒ 这一位缺席);远端 MCP 服务器在 401 / 403 挑战头里自报的 `resourceMetadataUrl` 不再回显。卡上其余成员照旧。
+    `tool_end.structured` 上挂着授权记录的自注册卡同读。状态行 / 重拨回执 / 面板 / 能力面 / 通告上这条记录本来就只有 `reason`,不变。
+    谁需要:读会话历史的一切客户端与运维 —— 不再把一只远端选的地址摆到人面前。
+    谁受伤:从会话历史 `details.authorization` 读 `resourceMetadataUrl` 的消费方;在 `code: "unauthorized"` 卡上放别义 `authorization` 的自注册工具(被按授权记录窄读)。
+    补偿:那只地址远端在每次挑战里都会再答;没有旋钮(安全轴收窄)。存档字节不动(读口投影);会话同步拉取口照旧逐字复制存档。
+
+5. **AskUserQuestion 的落点只由「这一次投递有没有经这条腿的活面把卡呈出」定(问被上游门放行、到达投递 / 耐久处理之后;`permissionMode: "dontAsk"` 的问在上游门就被拒、到不了投递,自成一形 G):呈出过而窗走完没人答 = 一次失败的问(不停驻、不改道);没呈出 = 没拿到答(durable 部署停驻、可经 decide 补答);续跑腿的新问也先投卡、窗内可答;卡面 `reason` 由 `declined_unavailable` 换 `callback_failed`、coded 码由 `question.human_unavailable` 换 `question.human_channel_failed`(行为变更;wire 零新键、零新帧型、零新码;部署零动作)**:
+    射程:问题席在场(`ASK_QUESTION_ENABLED`;单用户缺省开,多租户显式开的同读)的部署。durable 部署(`DURABLE_APPROVAL=true` + checkpoint 能力的 backend)的落点见「新形」各形;无 durable 的部署:没呈出 ⇒ 自答续跑(一字不变),呈出过而窗走完 ⇒ 同「新形」的失败臂(只换卡面 `reason` / coded 码)。问题席不在场的部署一字不变。带 `permissionMode: "dontAsk"` 的 run 不走落点:见「新形」里的形 G 与其后的 `dontAsk` 一段。
+    旧形(7.149.0 及以前):durable 部署上落点按「判决那一刻这条腿的投递面可不可达」分形 —— 后台腿(`POST /v1/runs`)、连着的 `/v1/tasks/stream`、判决时还连着的 detach 流上,问题工具当场执行,`QUESTION_TTL_MS` 窗到期没人答 ⇒ 模型拿到「没人可问,自己判」的续跑卡继续跑(连着的流上是 coded 工具失败 `question.human_unavailable`),不铸 checkpoint、答案补不回;开帧投不出 / 撞并发帽 / 撞总量帽 ⇒ 同形当场续跑;只有判决时就够不着人的腿(断连已被确认的 detach 流、同步 `/v1/tasks`)停驻;续跑腿上的新问当场停驻、不投卡、`POST /v1/questions/:id/respond` 答 404;principal 带 `forceDurableGate` 的 run 在有上下文的腿上照样当场执行问题工具。无 durable 的部署:卡面 `reason: declined_unavailable` 的自答续跑(posture interactive 的连着的流为 coded `question.human_unavailable`),卡呈出过的也一样。
+    新形:落点只读这一次投递的结局,本服务不在投递前预判「有没有人」。卡先经本腿的人在环传输投出(流腿:有 durable run 行时账本 + 活面,否则只有活面;后台 / 续跑腿:账本),窗内 `POST /v1/questions/:id/respond` 答到即交引擎;窗走完没人答时,由一个事实挑落点 —— 这一次投递有没有经这条腿的活面(直写 SSE)把卡呈出(审批族的呈卡登记读同一位)。呈出过 ⇒ 一次失败的问:不停驻、不交给第二个决断者,run 接着跑;没呈出 ⇒ 没拿到答:durable 部署停驻(`done(suspended)` + `pendingGate`),经 `POST /v1/approvals/:sessionId/decide` 带 `answer` 补答,无 durable 的部署自答续跑。durable 部署 × 问题席在场,各形(只列没在窗内答到的):
+    · 形 A 连着的 `/v1/tasks/stream`:呈出 ⇒ 窗走完抛,不停驻。
+    · 形 B `x-detach-on-disconnect` 流,卡出现时直写面接下、断开发生在其后:呈出 ⇒ 窗走完抛,不停驻。
+    · 形 C `x-detach-on-disconnect` 流,断开发生在卡出现之前(卡只进 run 账本):没呈出 ⇒ 窗走完停驻。
+    · 形 D 后台腿(`POST /v1/runs`)与续跑腿(流式续跑;卡进本腿账本、窗内可 respond):卡只进 run 账本 ⇒ 窗走完停驻。
+    · 形 E 不投卡的形 —— 没有问题上下文的腿(同步 `/v1/tasks`、verify / cascade 的续跑腿)· principal 带 `forceDurableGate` · 开帧投不出 · 撞并发帽(缺省 2)/ 总量帽 · 脱敏后序列化的载荷超 16384 个字符:当场停驻,不等窗。
+    · 形 F 开帧一直悬着、窗先走完:没呈出 ⇒ 停驻;run 取消、非 detach 腿断连、腿退场清扫:腿中止,不停驻、不抛。
+    · 形 G 自成一形、不在落点表内(落点之前:上游门拒,问到不了投递;**不归形 E**:E 是没有卡可答而当场停驻,这一形是拒、没有停驻行):durable 部署上 `permissionMode: "dontAsk"` 的 run —— 见下面 `dontAsk` 一段。
+    抛的那一臂,工具结果在 posture interactive 的流(连着、未声明 `x-detach-on-disconnect`、部署有活体审批席、请求没把 `approvalReach` 声明成 `none` —— 本服务只在这几条都成立时向引擎声明 interactive)上是 coded `question.human_channel_failed`,其余(形 B、不声明 interactive 的连着的流)是「按你的判断继续」的续跑卡 `reason: callback_failed`;两句都引本服务的原话「the question was shown on this run's live stream and nobody answered it within its <窗>s answer window」。`question_complete{unanswered}` 照发;窗走完之后 respond 恒 404。
+    同 ALS 的**同步**委派子代(`Agent` 不带 `run_in_background`)读父腿同一张卡:父腿是形 A / B ⇒ 同一个失败臂(卡面随父腿的姿态);父腿是形 D ⇒ 没有停驻车道(引擎不给同步子代转交 durable 声明):卡照投、窗走完子代得到引擎的拒(工具未执行、拒句让模型按自己的判断继续;子代接着跑、不铸 checkpoint)。此前这两形读的是自答续跑卡(连着的 interactive 流上是 coded `question.human_unavailable`),两版都不停驻。
+    detach 流上断开的先后只通过一件事起作用:卡出现那一刻直写面接没接下(接下 = 形 B,没接下 = 形 C),落点本身只读这一件事;`UNATTENDED_APPROVAL_POLICY` 只管审批问,`deny` 部署上问题照读各形。verify / cascade 组合入口的续跑腿没有人在环上下文(三族同,两版同)。
+    例外(两版同):run 被取消或非 detach 腿断连 ⇒ 腿中止、不停驻;停驻环帽已满 ⇒ 不铸 checkpoint。`question_complete` 是尽力投递的收帧,停驻以 run 的 `suspended` 终局为准(窗到期到停驻铸好之间有一段 respond 已 404、`/v1/approvals` 还没有这一行的空档)。
+    **`permissionMode: "dontAsk"`(形 G,落点表之外;两形之差)**:旧形(7.149.0 及以前):durable 部署上那只服务端预判门放行问题工具,后台腿与连着的流上带 `dontAsk` 的 run 里问题卡照投、窗内可答。新形:预判门撤掉后,问题工具经引擎原形的问答策略答 `ask`,引擎模式表对这一只 `content_question` ask 判拒(hook 自己的 ask 除外)—— 零问题行、零卡、不停驻、不铸 checkpoint,工具未执行,模型读到 `isError` + `notExecuted` 的 dontAsk 拒句。非 durable 部署不变:今天照引擎的 live 问形送卡(live 形里问题工具不铸 ask、执行时直接问问题席,模式表读不到它),随引擎让 live 形也铸 ask 翻面后同答「拒」;本服务不在下游再造一只模式判官。**谁受伤**:durable 部署上在 `dontAsk` 里仍指望问题卡送达的提交方。**出路**:要人答问换 `permissionMode: "default"` / `"acceptEdits"`;不要问题工具带 `interactiveTools: false`;零新旋钮。
+    **谁需要**:durable 部署上的人 —— 后台没在窗内答的问,run 停下等人而不是按猜往下跑;续跑之后的新问也有卡可答;连着的人看过卡、窗内没答的问不再又交给第二个决断者,也不再被说成「没呈给人 / 没人可达」。
+    **谁受伤**:依赖「问了没人答也会接着跑」的无人值守提交方(后台 run、开帧投不出 / 撞帽的腿)—— run 现在停在 `suspended`,要有人去 decide;续跑腿上的新问多等一个窗才停驻;`declined_unavailable` / `question.human_unavailable` 的分诊(壳与告警按它判「窗到期」)在卡呈出过的那一形上读不到这两个词了;同步委派子代的模型读到的工具结果换了(父腿是形 D 时由自答续跑卡换成引擎的拒)。
+    **出路**:不想让问题挡住 run 的提交方在请求体带 `interactiveTools: false`(逐 run;模型根本不问);`QUESTION_TTL_MS` 调窗长(上限 1 小时);要「回头再答」改用 `POST /v1/runs`(卡只进账本 ⇒ 停驻、`GET /v1/approvals` 取回、`decide` 带 `answer` 补答);按码分诊的消费方把 `callback_failed` / `question.human_channel_failed` 读作「呈出过、没拿到答」;部署级不要任何停驻 ⇒ `DURABLE_APPROVAL=false`。
+    **升级前做**:无(零配置、零存储形变化;升级前停驻的问题行照常可赎)。**升级前自查**:durable 部署上提交 `permissionMode: "dontAsk"` 又指望 AskUserQuestion 的卡送达的调用方(7.149.0 的后台腿与连着的流上卡照投)—— 本版起零卡、模型读到拒句,按上面 `dontAsk` 一段的出路改。
+    **回滚**(本版 → 7.149.0):回到「旧形」一段写的 7.149.0 的形 —— 那一版的服务端预判门在这条腿有问题上下文、且直写面此刻可达时放行,窗走完协调器对一切没拿到答的问都答 `unavailable`,引擎自答续跑、不铸 checkpoint:后台腿与连着的流上没人答的问不再停驻、答案补不回;卡呈出过而窗走完的问回到 `declined_unavailable` / coded `question.human_unavailable`;续跑腿的新问回到当场停驻、零卡、respond 404;principal 带 `forceDurableGate` 的 run 在有上下文的腿上又照样执行问题工具。无存储形变化:本版停驻着、还没人 decide 的问题行回滚后仍是停驻行,7.149.0 的赎回腿对这类行同样判 ask、经 decide 带 `answer` 补答。`permissionMode: "dontAsk"` 的 durable run 回滚后回到卡照投、窗内可答(预判门放行)。
+
+6. **fleet 成员起步即在服务租约围栏内(推定),不再因「从没听到中心」而永久不受围栏(只影响设了 `FLEET_GENERATION` 的部署;行为收紧;wire 零新键、零新码 —— 变的是 `leaseState` 的取值时机与 `state.lease_expired` 的触发条件;部署零动作,除非心跳一直到不了带键的中心)**:
+    旧形:心跳从起步起一直得不到中心的能力声明(中心不可达 / 401 / 404 / 400 / 2xx 而不是声明)⇒ `leaseState` 恒 `none`、零续租、零 503(心跳失败零计数;答复不是声明那一形另有一只计数,但成员同样不受围栏)—— 被吊销后重启、换节点而卷不随、没有数据根的实例照常接新工作,永不受围栏。
+    新形:没有任何声明之前按「围栏在、还没授予」处置 —— `leaseState: "expired"`,失联钟从本进程起点算,过 `FLEET_LEASE_OUTAGE_MAX_MS` 新工作 503 `state.lease_expired`(`Retry-After: 60`;取消 / HITL 应答 / 续跑 / 读面照放行,`/readyz` 不翻,在飞不动;拒体与续租不通那一臂逐字同)。推定期不续租。第一条声明定推定:宣告了 `servingLease` ⇒ 照常续租(钟起点仍是本进程起点);声明不带位(`{ capabilities: {} }`)⇒ `none`,与修前同。只有显式的 `capabilities` 声明对象是中心的话;心跳 401 / 404 / 400 / 不可达 / 超时 / 答复没有 `capabilities` 键都是「没听到」,推定照旧。听不到的每一拍计 `server.fleet.serving-lease-unconfirmed`(`why=heartbeat:…`;与续租没确认同一段、同一行 warn `fleet_serving_lease_unconfirmed`,宣告不收尾、续租判决或声明不带位才收尾,一行 `fleet_serving_lease_recovered`,带 `by`)。推定的终结(第一条声明)、续租判决、被拒引起的租约态翻转即刻再公告一拍心跳(首拍心跳因此是 `expired`,数据根记着拒的成员是 `denied`;第一条声明 / 第一次授予一到即刻再报 `none` / `granted`);推定终结之后心跳答复引起的位翻转(新老副本交替答心跳)与授予到期随心跳节拍。
+    谁需要:靠围栏吊销 / 退役 fleet 成员的部署 —— 被吊销后重启的实例也受 `T_max` 定界。
+    谁受伤:① 心跳从起步起一直不通的成员(活性基址错、令牌错、中心拒公告体)过 `T_max`(缺省 24 h)拒新工作(修前静默照接),多租形里额度谈判照通也一样(额度门与围栏门是两只门、两条基址);② 成员首拍心跳报 `leaseState: "expired"`(修前 `none`),答复 / 授予一到即刻再公告 —— 按首拍计数的告警只在一个往返的窗里看到它;③ 每个进程各自一段 `T_max`(钟不跨重启,重启即重计);中心一条显式的「不带位」声明照旧解除围栏、之后不限时;④ 心跳实际打到的路径答没有 `capabilities` 键的 2xx(活性基址单独路由到别的后端、回滚到带键之前的中心、网关 / 维护页答 `200 {}`、手配成员 × 老中心)的成员恒推定,满 `T_max` 拒新工作。
+    补偿:`FLEET_LEASE_OUTAGE_MAX_MS`(缺省 24 h,地板 60 s)定这段容忍;到点之前逐拍计数 + 一段一行 warn(运维行 `fleet_announce_failed` 带中心拒句)+ `/health.leaseState: "expired"`;中心一答即恢复(声明不带位 ⇒ `none`,宣告 + 授予 ⇒ `granted`);让心跳路径答到带 `capabilities` 键的中心;不要围栏的单机形去掉 `FLEET_GENERATION`。
+    嵌入方:`createHttpServer` 收到租约读数 `servingLease` 而 `config.fleetGeneration` 缺席 ⇒ 构造期拒启(「createHttpServer: servingLease is wired but config.fleetGeneration is not: … refusing to start rather than ignore the lease reading」)—— 成员身份只有代际一个开关,读数在、代际不在的装配里读数永远读不到、准入永远不按租约拒(7.149.x 上这一形准入照按租约拒而 `/health` 不报)。补 `config.fleetGeneration`(本实例的代际),或不注入读数;本服务自己的入口只给成员装租约客户端,部署零变化。
+    勘误:7.121.0 节第 4 条「租约只在中心于心跳答复里宣告 `capabilities.servingLease: true` 之后生效;没宣告 ⇒ `leaseState: "none"`」自本版起只对中心读得出的声明成立 —— 从没听到声明的成员是 `expired`(推定);同条「那只文件写不进 ⇒ 重启后在第一次续租答复之前会接单」的窗,在心跳一直不通时以 `T_max` 为界(每个进程一段)。
+
+7. **停-迁-起守卫的旧副本证据改按「持有者知不知道这条迁移」判:副本能力登记与起服准入两张常设表(SQL 后端起服自建);拒因词 `live_runs` 改名 `older_replica`;新拒启码 `config.serving_requirement_unmet`(行为变更;机读词硬断;持久面:两张新表;部署零动作)**:
+    旧形:四只停-迁-起守卫(M40 · M41 · M42 · M51)与撤回出口的启用标记(M43)判「更早版本的副本还在服务吗」只看判活窗(`REAP_RUN_STALE_SEC`)内有没有 `running` run 在心跳,不分持有者 —— 本版副本自己的 run 也被读成「可能是旧副本」,撤回出口的标记在整天有 run 的部署上落不下。
+    新形:每只走 SQL 一次性迁移段的进程(本服务,与走公开序列 `createStoreBackend()` → `ensureSchema()` → `runOneTimeMigrations()` 的嵌入方)在段头、取迁移锁之前往 `replica_registration` 登记一行:进程身份(与它写在 run 行上的持有者、`/health` 的 `instanceId` 同一只)→ 本构建的能力名单 + 发布线 + 主机名 / pid + 起服时刻;只写一次、不续期、停下不删,登记时删掉 90 天前别人的行。
+    守卫的证据只有一只读法:判活窗内心跳过的 `running` run,减去登记为知道该条迁移的持有者 —— 剩下的才挡起服;拒句点名没登记的 run 数,并逐只点名登记了而没有这项能力的持有者(实例 / 发布线 / 主机 / pid)。
+    起服准入:段头锁外读一次 `serving_requirement`、取到迁移锁之后在锁连接上再读一次;库上记着本构建没有的能力(`state` 两词闭集 `pending` / `in_force`,读出别的词按 `in_force`)⇒ 拒 `config.serving_requirement_unmet`(`capability_missing`),一步迁移不跑;两张表不在 ⇒ 同码拒(`table_absent`,拒句点名公开序列)。本版不写 `serving_requirement`(表空 ⇒ 准入恒过):它为之后的停-迁-起迁移预装。
+    机读词硬断:三只拒句的拒因词 `live_runs` 改名 `older_replica`(`config.session_ext_move_refused` / `config.scenario_prefix_switch_refused` / `config.session_deleting_switch_refused`;零别名;`copy_mismatch` / `stored_prefix` 不变)。
+    看不见的边(如实,这一句订正 7.147.0 / 7.148.0 / 7.149.0 节「守卫只看心跳」诸句的射程,不改它们的结论):登记不续期、不观察,**不是围栏**。早于本版的副本不登记 —— 空闲时(零 `running` run)照旧看不见,M40–M51 要防的旧副本全在这一类(终局边界;停光旧副本仍是运维的第一道,见本节段头「停-迁-起」一行);停顿 / 与库断开的旧副本迟到的写,任何观察都关不上。M41 拷贝 → 核对 → 删列三步之间的旧写丢失是 7.147.0 节已披露的边,本版不改。准入挡的是起服者,不挡已在服务的副本。
+    谁需要:多副本滚动升级的 SQL 部署 —— 撤回出口在繁忙部署上终于启用(这一收益只活到 M43 删码:那之后撤回出口无条件启用);之后的停-迁-起迁移有准入可读。谁受伤:按拒因词 `live_runs` 告警或分支的运维规则;跳过 `ensureSchema()` 直接调 `runOneTimeMigrations()` 的嵌入方(拒 `table_absent`);每次起服在迁移段头多两句写(删 90 天前别人的登记行、缺席才落本进程一行)。空闲旧舰队上的滚动升级此后会被写了准入要求的停-迁-起迁移拒启 —— 以前可能「意外滚成」,这是预期行为。补偿:拒句点名持有者;嵌入方按公开序列开店;按升级清单停光再起。回滚:上一版不读这两张表,表与行留着无害。
+
+8. **`listening` 启动行不再随 `LOG_LEVEL` 消失,并多一键 `boundAddress`(行为变更 + wire 加性;部署零动作)**:
+    `listening` 是启动协议行 —— 起本进程的宿主从 stdout 读它取口与实绑地址 —— 档位只滤诊断行,`LOG_LEVEL=warn` / `error` 下这一行照出(每次起服一行,行上 `level` 仍是 `info`)。
+    同一行多一键 `boundAddress` = 内核实际绑上的地址(`::` / `0.0.0.0` / `127.0.0.1` / `::1` 原样),与请求绑的地址 `bindHost`(键名与值不变)分开两格。
+    **谁需要**:自起本机引擎、按「实绑地址 + 口」认归属的宿主,与在任何档位下读口的嵌入方;**谁受伤**:把档位调到 warn / error 并断言 stdout 为空的部署 / 脚本(多这一行),
+    按整行逐字节匹配 `listening` 行的脚本(多一键);**补偿**:按 `level` 字段筛日志的管道照旧筛得掉它(`level` 为 `info`);按键读的消费方零动作;不设关它的旋钮。
+
+9. **起服拒句的升级清单第 2 步按库实况列:只列这只库还欠的停-迁-起迁移;一条都不欠(如起过 7.148.x 的库)⇒ 没有这一步、不说「不可滚动」(运维文案变;守卫的判据、拒码与出路不变;wire 零新键、零新码;部署零动作)**:
+    旧形(7.149.x):缺列拒 / 单表探针拒 / 判活守卫拒句尾的 `Upgrade checklist` 第 2 步按登记表列本构建带的全部停-迁-起迁移(M40 · M41 · M42 · M51)并说 "this release cannot be rolled across replicas of both versions",不判这只库欠不欠(7.149.0 节段头与部署前提文档的升级清单一节如实写了这一保守句)。
+    新形:第 2 步逐条问那条迁移的守卫自己的判据(M42 / M51:标记行在不在;M40:带 `execution_lane` 列的表上还有没有退役词;M41:`session_meta` 上还有没有部署格列),只列还欠的;一条不欠 ⇒ 清单只有「执行语句 → 起服」两步。某一条读不出欠不欠 ⇒ 照列它并在那一行说没读到(多停一次,不漏停)。
+    谁需要:升级运维 —— 只漏了 DDL 的库照第 1 步加列即可滚动,拒句与段头说同一件事。谁受伤:按清单全文或 "cannot be rolled" 字面匹配的脚本。补偿:按码判别(码不变)。回滚:上一版照旧全列。
+
+10. **活卡上的 `rememberRefused` 改读「这一问 + 这条腿」:没有会话的腿、读不出会话住客令牌的腿(会话店不带执行席 —— 引擎缺省的内存会话店)上,活卡帧、呈卡帧的卡、`livePending` 行也带 `rememberRefused`(行为修复;wire:这一位在场的情形变多,键与值域不变;零新码;部署零动作)**:
+    旧形(7.116.0–7.149.x):卡面的 `rememberRefused` 只问这一问本身记不记得住;那两形腿上点 `allow_session` 回执 `rememberApplied:false`(7.149.0 第 37 条),卡面却不带这一位 —— 壳照渲「本会话放行」,点了只放行一次、下一问照样出卡;契约用「本位不管那两形」一句托住。
+    新形:卡面与回执读同一只判官 —— 卡带 `rememberRefused` ⇔ 点 `allow_session` 回执 `rememberApplied:false`(写失败 / 提交歧义是落定之后才知道的,仍只在回执上说)。契约那句例外删。读不出住客的腿上客户端照样发 `allow_session` 时,那一行 warn `session_grant_refused_occupant_unreadable` 照留。
+    谁需要:用引擎缺省内存会话店的嵌入方、无会话的 adhoc 腿上的壳用户。谁受伤:无。补偿:要「本会话放行」生效就给会话店带执行席(`sessionStorage.executionPlacement`;SQL 两方言与 local 后端恒带)。回滚:上一版卡面不带。
+
+11. **订正 7.149.0 节与 7.147.0 节的三处文字(文字订正;零行为变化;wire 零变化;部署零动作;已发节不改字节,本条即订正)**:
+   ① **7.149.0 节第 1 条**把 `/metrics*` 与 `GET /v1/tasks/source-summary` 合写成一句「`401 auth.unauthorized`(运维面句;配了 `METRICS_TOKEN` 时出示它照放,没带它的请求先答 `401`、不先读主体头)」。
+   **订正**:两只只读凭据各认各的口 —— `METRICS_TOKEN` 只开指标口(`/metrics*`),`TRACE_TOKEN` 只开 `GET /v1/tasks/source-summary`,互不通用(出示 `METRICS_TOKEN` 读 `source-summary` 照答 `401`,出示 `TRACE_TOKEN` 读 `/metrics*` 同);
+   「没带它的请求先答 `401`、不先读主体头」是配了 `METRICS_TOKEN` 的 dev-open 部署上指标口的读法,`source-summary` 的判据里没有 `METRICS_TOKEN` 这一格。该条里「报了主体的请求对这两口答 `401 auth.unauthorized`」一句不变,401 句本身(「METRICS_TOKEN for the metrics endpoints, TRACE_TOKEN for the task source summary」)本来就分开写。
+   ② **7.149.0 节第 15 条「升级前自查」**的例句(`E2B_SANDBOX_ENV=GIT_TOKEN`,而 `GIT_TOKEN` 与 `GIT_API_TOKEN` 同值 ⇒ 本版拒启)**只对 `REMOTE_EXEC=e2b` 的部署成立(e2b 车道)**:三只沙箱名单(`E2B_SANDBOX_ENV` / `DOCKER_SANDBOX_ENV` / `K8S_SANDBOX_ENV`)只在自己的车道被选中时才求值,
+   别的车道上它们是无关配置(不校验、不拒启)。host 车道上自查的是 `LSP_ENV_ALLOW` / `HOOK_ENV_ALLOW`(两只在单用户姿态下照判,多租户姿态下名单被忽略)。其余自查与出路不变。
+   ③ **7.147.0 节第 18 条末尾「引擎已知限度(随版发)」一项**里括号点名的三枚短号是引擎的内部编号,读者无从查证、也不需要 —— 三条限度本身的说明都在同一项的正文里;那一节由发版链门逐字守着、字节不改,本条即披露(此后随包文字不再带这一类编号)。
+   **谁需要**:按 ① 配了 `METRICS_TOKEN`、想用它读 `source-summary` 的运维,与按 ② 的例句在 host 车道上自查名单的运维(例句在 host 车道上不会拒启,不必为它改名单)。**谁受伤**:按订正前的句子拿 `METRICS_TOKEN` 读 `source-summary` 的人 —— 实现一直答 `401`,从没放过,没有行为可退。
+   **补偿**:`source-summary` 用 `TRACE_TOKEN`(只读)或不带主体头的 service token(在部署让它代自己说话时);指标口用 `METRICS_TOKEN`。
+
+12. **device 执行器协议修订 5:指令里的路径只锚不折,服务端只受理修订 5 —— 声明修订 4 及以下的执行器在 hello 收 `protocol_version_unsupported`、注册被拒(wire:`deviceExecutor.protocolVersion` 与 challenge 帧的值 4 → 5,受理下沿 1 → 5,`helloReject` 加一键 `message`;零新码;**部署动作:device 车道先升执行器**)**:
+   本版起服务端交给设备的每条路径(`args.path` / `args.paths` / `cwd`)绝对的原样、相对的锚在会话工作目录上,`.` / `..` / 空段一律不折,由设备的文件系统解(协议文档 §2.1 修订号表第 5 行、§3.1、执行器义务第 6 条)。
+   写给修订号 4 及以下的执行器认的是折过的路径(已发的 cli 执行器对 `.` / `..` / 空段一律拒收),所以受理下沿同版抬到 5:它们在 hello 收 `{ "t": "helloReject", "code": "protocol_version_unsupported", "minProtocolVersion": 5, "message": "device protocol revision 4 is below the lowest revision this server accepts (5): since server 7.150.0 every path an instruction carries (args.path, args.paths, cwd) arrives unfolded, with \".\" / \"..\" / empty segments kept for the device's filesystem to resolve; upgrade the executor to one that declares revision 5 or above" }`,
+   服务端同一句进 warn 行 `device_hello_version_rejected`(`declared` / `minProtocolVersion` / `protocolVersion` / `message`)并计 `device_hello_rejected_total{code="protocol_version_unsupported"}`。修订号律随之恢复「语义变更升号」:一处变更旧执行器守不住 ⇒ 同版抬受理下沿,一次响亮拒,不逐调用失败。
+   **谁需要**:device 车道的部署 —— 路径语义变了,旧执行器在注册时就被拒、拒句说清缘由,而不是含 `.` / `..` 的文件工具调用逐个失败(或被按字符串前缀判根的执行器放过 `<root>/../etc`)。
+   **谁受伤**:先升了服务端、执行器还是修订 4 及以下的 device 部署 —— 设备连不上,落在该设备上的 run 读到设备不可用;按 `device_hello_rejected_total` 只看 `auth_failed` 的告警多一个 `code` 取值。
+   **补偿**:先升执行器、再升服务端(协议文档 §1.2:实现修订 5 的执行器对上沿 4 的老服务端声明 4,先升执行器不断连);执行器一时升不了 ⇒ 服务端留在 7.149.x。零旋钮、零折叠臂(下沿不可调:调低 = 把未折路径发给读不了它的执行器)。回滚:回到 7.149.x,修订 5 的执行器照旧按修订 4 连上;无存储形变化。
+
+## 7.149.0 —— 1–40 条见下
+
+**升级清单(本节唯一的一张;下面各条只讲为什么,不再各自重述升级步骤)** —— 一次读清本版对一只存量部署要做的全部动作。每版同形:① 手工 DDL(逐表逐句,两方言各一份)② 起服自建与一次性迁移 ③ 停-迁-起 ④ 顺序;后续每版的段头照此写,新增一句 `ALTER`、一条一次性迁移、一条停-迁-起时,先改这里,再写条目。
+已发各节(7.148.0 及以前)逐字只读,不在原处补汇总 —— 跨过它们的部署读下面「跨过 7.148.0」一块。起服拒句是同一张清单的运行期形:缺列拒、单表探针拒、一次性迁移的判活拒,每一句都带同一张升级清单:这只库此刻还差哪些 `ALTER`(按库实读,全库一次列全)、本构建带的**全部**停-迁-起迁移(M40 / M41 / M42 / M51,按登记表列,不判这只库欠不欠)、先后顺序;一次起服读全 `ALTER`,不必补一句再试一次。
+
+- **从 7.148.x 升级到本版**:
+  - 手工 DDL(SQL 后端 `DB_BACKEND=mysql|pg`;一张表一句,**先升库、再升副本**;在跑的旧副本不受影响 —— 它的语句不提这一列;旧副本**重启**时按「库比构建新」拒启,多出的这一列是它的幽灵列)。语句逐字是起服列册对账拒句打印的那一句(由本构建的建表语句生成),不回填(第 21 条「停驻写只许这条 run 的持有腿落下」):
+    - MySQL 协议:
+      `ALTER TABLE task_run ADD COLUMN leg_id VARCHAR(36) NULL;`
+    - PostgreSQL:
+      `ALTER TABLE task_run ADD COLUMN leg_id VARCHAR(36) COLLATE "C";`
+  - 起服自建(运维零手工):无新表;一次性迁移标记表 `one_time_migration_marker` 改由中央建表语句建(`CREATE TABLE IF NOT EXISTS`,形不变,已有的不动)。
+  - 一次性迁移:本版**无新增**。停-迁-起:**无新增**。本版条目没有一条要求停光旧副本。漏了上面那一句 `ALTER` 的 7.148.x 库起服撞缺列拒,拒句升级清单的第 2 步仍照列本构建带的全部停-迁-起迁移,并说「先停光旧副本、不可滚动」—— 那一步不判这只库欠不欠:起过 7.148.x 的库四条都已走过(M42 / M51 读到标记、M41 读到部署格列已不在 `session_meta`、M40 读到零行旧词 ⇒ 各自不读心跳、零写放行),第 2 步对它是多余的保守句,照第 1 步加列,再按下一行的顺序滚动即可。
+  - 顺序:① 备份 ② 上面那一句 `ALTER`(先升库)③ 换版本(可滚动 —— 缺列拒句清单第 2 步的「不可滚动」对这一跨度不适用,见上一行;滚动窗里不要重启旧副本;新旧副本混跑的窗里「停驻写只许这条 run 的持有腿落下」一条的两项担保不成立,换完即成立)。
+- **跨过 7.148.0(从 ≤ 7.147.x 直升本版)另加 7.148.0 节的全部动作**(库里还留着退役的 `snapshot_manifest` 表或 `checkpoint.pending_steer` 列的跳版库 —— 从没起过 7.74.0–7.125.x 的版本 —— 先撞退役 schema 拒:出路是先用一只 7.125.x 起服一次再升,那一跳不在这张清单里):
+  - 手工 DDL(SQL 后端 `DB_BACKEND=mysql|pg`;四张表十句,**先升库、再升副本**;旧副本不受影响,只在它重启时按「库比构建新」拒启)。语句逐字是起服列册对账拒句打印的那几句(由本构建的建表语句生成);表尚不存在的库(起服自建,建表语句已带新列)那一张零动作:
+    - MySQL 协议:
+      `ALTER TABLE leader_run ADD COLUMN error_code VARCHAR(64) NULL;` · `ALTER TABLE leader_run ADD COLUMN cancel_requested SMALLINT NOT NULL DEFAULT 0;` · `ALTER TABLE leader_run ADD COLUMN identity_source VARCHAR(32) NULL;` · `ALTER TABLE leader_run ADD COLUMN identity_scope VARCHAR(190) NULL;` · `ALTER TABLE leader_run ADD COLUMN identity_principal_inc VARCHAR(64) NULL;`
+      `ALTER TABLE session_ext ADD COLUMN client_writes BIGINT NOT NULL DEFAULT 0;` · `ALTER TABLE session_ext ADD COLUMN deleting_token VARCHAR(36) NULL;`
+      `ALTER TABLE session_meta ADD COLUMN forked_from VARCHAR(64) NULL;` · `ALTER TABLE session_meta ADD COLUMN forked_from_incarnation VARCHAR(64) NULL;`
+      `ALTER TABLE checkpoint ADD COLUMN host_session_id VARCHAR(190) NULL;`
+    - PostgreSQL:
+      `ALTER TABLE leader_run ADD COLUMN error_code VARCHAR(64) COLLATE "C" NULL;` · `ALTER TABLE leader_run ADD COLUMN cancel_requested SMALLINT NOT NULL DEFAULT 0;` · `ALTER TABLE leader_run ADD COLUMN identity_source VARCHAR(32) COLLATE "C";` · `ALTER TABLE leader_run ADD COLUMN identity_scope VARCHAR(190) COLLATE "C";` · `ALTER TABLE leader_run ADD COLUMN identity_principal_inc VARCHAR(64) COLLATE "C";`
+      `ALTER TABLE session_ext ADD COLUMN client_writes BIGINT NOT NULL DEFAULT 0;` · `ALTER TABLE session_ext ADD COLUMN deleting_token VARCHAR(36) COLLATE "C";`
+      `ALTER TABLE session_meta ADD COLUMN forked_from VARCHAR(64) COLLATE "C";` · `ALTER TABLE session_meta ADD COLUMN forked_from_incarnation VARCHAR(64) COLLATE "C";`
+      `ALTER TABLE checkpoint ADD COLUMN host_session_id VARCHAR(190) COLLATE "C";`
+  - 起服自建(运维零手工):`approval_nonce_floor`(7.148.0 节第 21 条)。
+  - 一次性迁移(起服时自跑,运维零手工):M42 场景前缀的切换检查 · M43 撤回出口的启用标记 · M44 run 的 `errorCode` 只读列 · M45 run 行预览列的旧形 · M46 引擎家 `Skill` 会话豁免行 · M47 / M50(`DB_BACKEND=local` 独有)· M48 cli 哨兵属主 · M49 检查点的归属会话回填(要先有 `checkpoint.host_session_id` 这一列,所以排在上面那句 `ALTER` 之后)· M51 会话在删态的切换。
+  - 停-迁-起(SQL 后端):**M42**(更早版本的副本不保留 `_scn:` 前缀)· **M51**(更早版本的副本不读会话的删除中状态);从 ≤ 7.146.x 直升的另有 **M40** · **M41**(7.147.0 节)。四条共用一个守卫谓词:判活窗(`REAP_RUN_STALE_SEC`)内库里还有 `running` run 在心跳 ⇒ 起服拒(`config.scenario_prefix_switch_refused` / `config.session_deleting_switch_refused` / `config.execution_lane_rename_refused` / `config.session_ext_move_refused`,拒句同一段动作),一个字节不写。守卫只看心跳:没有在跑 run 的空闲旧副本它看不见,**停全部旧副本是运维的动作**。
+  - 顺序:① 备份 ② 全部 `ALTER`(先升库)③ **停光**全部旧版本副本,等满判活窗(`REAP_RUN_STALE_SEC`,缺省 120 s,必须大于 30 s 的心跳周期,否则起服拒)④ 起**一只**本版副本(迁移在这次起服里自跑;拒句里的「可再起的时刻」= 最新心跳 + 判活窗)⑤ 再起其余副本。滚动升级在这一跨度上不成立。
+- **数据根高水位(`DB_BACKEND=local`;每次起服的常设不变量)**:`<数据根>/engine-high-water.json` 记下打开过这只根的最高引擎版本。起服准入先判 —— 高于本构建 ⇒ 拒 `config.schema_mismatch`(`newer-engine`),数据根一个字节不动;判过之后、本构建的第一笔受保护写之前,把它抬到本构建的发布线(缺席或更低 ⇒ 写;相等 ⇒ 只证落盘)。所以成功起服之后 marker 恒不高于在跑的版本,带这一臂的更旧构建重开这只根会被拒(保护起点如实:只有旧的那一方带着这一臂才守得住,更早发出的版本改不了)。
+
+1. **没有身份边界(dev-open)的部署上,报了主体的调用方在每一口都是那位主体:会话读面与列表、存续面与键面、run 读面与 `/metrics` 族按主体头钉人,与提交挂接同读(安全收紧;行为变更;wire 零新键、零新码;部署零动作)**:
+    「没有身份边界」= 没声明 `REQUIRE_PRINCIPAL`,且没配 `SERVICE_AUTH_TOKEN(S)`、鉴权桥 issuer(`AUTH_BRIDGE_ISSUER`;接了中心 ⇒ 回退中心基址,同算)、直连门、只读 `TRACE_TOKEN`(`/health.auth.kinds` 为空且后两者都没有)。
+    旧形:这一形上主体头被读成「谁都能自报的标签」—— 每位调用方(带不带头)都持 fleet 资格:会话读面(视图 / head / 事件流 / 记忆状态 / 执行放置)、会话列表、改名置顶、fork、删除、同步族、记忆抹除、后台任务、MCP 重连、
+    规则口、notify、审批豁免、run 的两只按 id 读口(`GET /v1/runs/:id` · `…/events`)、舰队流 / 名册 / trace 列表 / 用量 / 发件链接都不按头钉人,`/metrics*` 与 `GET /v1/tasks/source-summary` 不要凭据;
+    而提交挂接(`POST /v1/tasks` · `/v1/tasks/stream` · `/v1/runs` 带 `sessionId`)一向按头判属主 —— 同一位 `x-agent-principal: mallory` 往 alice 的会话提交答 `404 resume.session_not_found`,同时读得到那只会话的正文。
+    新形:**报了主体的调用方恒是那位主体**(与带主体头的 service 凭据请求早已成立的那一句同读,部署形不改它);只有**不报主体**的调用方在这一形上代部署本人说话(fleet,读写照旧全开)——
+    「不报」= 没有主体头,也没出示一枚这台部署验不过的 Bearer / token 凭据(带了它的请求没有可信身份:不代部署本人,只看得见普通无主行,列表 `401 auth.unauthorized`)。
+    报了主体的调用方对别人的行:会话各口答各自「没有这一行」那一答 —— `404 not_found.session`,体与不存在的会话逐字节同(审批豁免 `404 not_found.session "not found"`;删除 `200 {deleted:false}`;
+    同步推送族 plan / 导入 / blob 上传对别人的会话 404、对不存在的 id 照答它既有的新建那一答,与有身份边界的部署同形);
+    run 的两只按 id 读口 `404 not_found.run`;列表面(会话列表、舰队流 `meta.scoped:true`、名册、trace 列表、用量、发件链接)钉到这位主体,`?owner=` / `?scope=` 不生效;`/metrics*` 与 `GET /v1/tasks/source-summary` 答 `401 auth.unauthorized`(运维面句;配了 `METRICS_TOKEN` 时出示它照放,没带它的请求先答 401、不先读主体头)。
+    无主的委派子代转录行(placed)对它与别人的行同答(只对不报主体的调用方 / 运维开放)。运维律不变:`OPERATOR_PRINCIPALS` 里的主体在运维可越的口(规则口 / notify / 执行放置 / 后台任务 / 审批豁免 / run 的监督口)照放,
+    运维不越的读口(会话视图 / head / 事件流 / run 轮询)与别的主体同答。有身份边界的部署一字不变。
+    **谁受伤**:dev-open 部署上带主体头、靠「读面全开」去读或动别人会话 / run 的调用方与脚本;带主体头抓 `/metrics*` 的采集;带主体头当运维看全舰队的控制台;
+    对没配 service 凭据的部署照样发一枚 Bearer 的客户端(那枚凭据这台部署验不过 —— 此前被静默忽略、照看全舰队,现在没有可信身份:列表 401,只看得见无主行)。
+    **出路**:要看全舰队 ⇒ 请求不带主体头、不带这台部署验不过的 Bearer(dev-open 上不报主体的调用方照旧代部署本人);或给部署配 `SERVICE_AUTH_TOKEN` 并以不带主体头的 service 凭据读(`SERVICE_TOKEN_ACTS_FOR_DEPLOYMENT` 缺省即代部署本人);
+    运维越属主照旧经 `OPERATOR_PRINCIPALS`。dev-open 上主体头仍是自报的,这一条给的是一致的「这次请求为谁」,不是隔离 —— 要按用户隔离照旧给部署接一个身份来源。
+    **升级前做**:无(零配置、零存储形变化)。**回滚**:回到 7.148.x 即回到旧形;无存储形变化。
+
+2. **判坏的停驻卡在三扇决断门上同拒,出路成一只机读词 `wayOut`;订正 7.138.0 节第 19 条 ②、7.146.0 节第 19 条、7.147.0 节第 29 条的出路句(wire 加性:一键;行为零变化;部署零动作)**:
+    旧形:引擎判「本引擎续不了」的停驻卡(例:7.136.x 停驻、本版引擎读作 `requirements_damaged` 的工具门 / 计划门卡)在 `POST /v1/approvals/:id/decide`、`POST /v1/assistant/tasks/:id/plan_review`、
+    `POST /v1/assistant/tasks/:id/resume` 上批 / 拒 / 驳一律 `409`(`retriable: true` = 卡仍 pending),出路只在句子里。
+    新形:码、句子、`retriable` 与各键不变,拒体多一键 `wayOut`(闭集;出路只看判决与这张卡本身,与门的哪一扇、决定词无关):
+    `cancel_run` —— 这张卡在本引擎上不收任何决定(批 / 拒 / 驳 / 改同拒);出路是 `POST /v1/runs/:id/cancel`:它把卡 expire、把 run 驱到取消终局、释放会话,之后另起任务;
+    `newer_worker` —— 更新引擎停驻的行,不低于停驻它那一版的 worker 续得了它,同一决定在那里落得下;卡留 pending(cancel 在这里是放弃它)。
+    判坏而取消动词不会结算这张卡(卡停在已终局的 run 的纯 park 上、run 已终局而卡仍挂着、run 在跑、归属说不出的老行,或没有耐久 run 店)⇒ 键缺席:本服务说不出客户端出路,由运维处置那一行。
+    `/plan_review` · `/resume` 上引擎对这张卡的拒原样过境(行记下的配置词拒的 `field` / `blockedBy` 照在),卡仍 pending 时带 `wayOut`;`/decide` 的这一行自己的拒同。
+    不带 `wayOut` 的拒:决定体那一格的拒(改那一格再决)、部署事实的拒、`POST /v1/sessions/:id/wake`。
+    订正(已发节不改字节):7.138.0 节第 19 条 ② 的出路「拒掉」—— 引擎 7.63.0 起这类行连拒也在认领前被拒;7.146.0 节第 19 条 ①「升级前做」与 ④ 补偿句里的「expire」—— 客户端的那一个动词是 `POST /v1/runs/:id/cancel`;
+    7.147.0 节第 29 条「补偿 / 升级前做」的「出路是作为新任务重提」—— 只重提不离队:卡仍在队里,同一会话上的 run 仍持会话锁(新任务 `409 conflict.session_active_run`),先 cancel。三处的出路一律读拒体 `wayOut`。
+    **谁受伤**:按拒体全键集逐字断言的消费方(多一键)。
+    **出路**:壳按 `wayOut` 渲出路(`cancel_run` ⇒ 只给「取消这条 run」,不给批准 / 拒绝按钮;缺席 ⇒ 提示找运维),不按 `retriable` 渲「再决」;部署零动作。
+
+3. **取消停驻 run 时,卡的属主读店里的属主格、不读行体:行体与店不一致或读不成检查点,取消照样结卡、驱 run 终局;判坏的卡的 `wayOut: cancel_run` 跟着取消动词走;另外四条作废卡的路同读店的属主格(行为修复;wire:取消口两面状态 `409` / `500` → `202`,`wayOut` 在场律放宽;零 DDL;部署零动作)**:
+    旧形:`POST /v1/runs/:id/cancel` 对停在门上的 run,先读那张卡的行体、再拿行体里自带的属主格去 CAS 结卡 —— 而 CAS 的谓词吃的是店里的属主格(路由层的属主门也读它);两份说法一致时读哪份都一样,不一致时只有店里的那一格能让 CAS 命中这一行。
+    两处不一致(被手改 / 外来写者写下的行)时 CAS 打空,取消答 `409 conflict.approval_settled`(「被并发决议了」,与事实不符;卡与 run 都没动);行体读不成检查点时取消答 `500 internal.error`。
+    一条续跑腿被取消之后结算它续的那张卡,读法同(卡留 pending,留给收割)。7.149.0 新增的 `wayOut: cancel_run` 又按载入的行体判「取消落不落得下」,行体坏得越厉害越说不出出路 —— 恰是最需要被指出来的那些卡。
+    新形:取消动词找卡、结算卡只读店的列(归属 run 的会话 × 活 run 的门型找卡,属主格读属主列);行体怎么坏(读不成检查点、属主格丢了或与店不一致、整格 `{}`)都不改变取消落不落得下:
+    卡 expire、run 取消终局、会话锁放开,答 `202`(体与取消停驻 run 的 `202` 同形)。`wayOut` 问取消动词自己那一问:`cancel_run` 当且仅当取消动词会结算这一张卡(有耐久 run 店;卡归属的 run 会话上持着认领的 run 停着;取消动词在那条会话上找到的恰是它)——
+    行体读不成检查点或属主格丢了的坏卡也给;卡是已终局的 run 的纯 park、run 已终局而卡仍挂着(取消口对终局的 run 是空操作)、run 在跑(取消口只挂旗)、归属说不出的老行(升级窗里旧副本写下、回填前的行)、没有耐久 run 店(取消口恒 `501`)⇒ 键缺席。`POST /v1/sessions/:id/wake` 的读行拒仍不带 `wayOut`。
+    取消口一向不读请求体,没有字段被读或被删;这里的「体」指停驻卡存储行里的 JSON 快照。
+    同一读法推广到另外四条「按令牌作废一张卡」的路 —— 全仓「把一张 pending 卡 CAS expire」从此只有一种读法(属主格读店的列、不读行体):① 审批 SLA 拒扫腿对「准入策略挡住」的续跑当场过期该卡;② 会话删除 / 显式结清口(`POST /v1/sessions/:id/children/retire`)带走停驻子代时作废它的卡;③ 停驻写没落定就以失败收场时作废手里那张卡;④ 复活不了的停驻子代被 `deny` 时作废它的卡。
+    这四处此前也是先读行体、再拿行体里的属主格去配:行体与店不一致或读不成检查点时,拒扫腿把「没过期成」记成「输给了并发」而卡留 pending 到收割,结清口 / 删除作废不了那张卡(子代停不净,答未净或读抛),结算作废静默放过或记「卡对不上」/「店读错」(兑现不了的卡留在待决面),`/decide` 的 `deny` 答 `409 decide.gate_moved`。现在这四条路上走得到作废的卡被作废,上列失败随之消失;好卡的结局一字不变。共用读法的次序恒为「先读状态、(要求归属就)再核归属、最后按属主列 expire」,取消口与取消之后的续跑腿结算同此:卡已不在待决面(已结 / 已不在)不再写一次(店写口故障时也不因此失败;取消口此前会答 `500`,现按 run 此刻的真实状态答 `409` / `202`),那一问读行状态、不读行体里的属主格;行体读不成检查点时读不出状态,不当作「已结」,交给吃列的 CAS 判。
+    **已知边界**:① 拒扫腿要先从行体读出待批动作与世代号才去过期,整格 `{}` / 读不成检查点的行认不出这些,不走到过期那一步(修前同);`/decide` 的行形判官先于赎回腿,判坏的行答该行自己的拒 —— 这两处本版未动。② 行体读不成检查点(JSON `null` 字面)的停驻子代,卡被作废,但子代行翻终局要引擎对账读卡状态,而对账读的是行体、读不出就不动它 —— 结清口 / 删除对这一形仍答未净;要对账改读状态列,属引擎侧,本版未做。
+    **谁需要**:用 `POST /v1/runs/:id/cancel` 清停驻坏卡的部署与壳(被手改的行、存储损坏的行);卡行被手改 / 被外来写者写过的部署上的会话删除、结清口与 `/decide` 的 `deny`。**谁受伤**:无 —— 取消此前对这些卡答的 `409` / `500` 本来就是没有落下的取消,那四条路此前的失败同理;
+    依赖「这类取消恒 `409`」的脚本在第一次调用就得 `202`。**出路 / 补偿**:无需动作;零存储形变化。
+
+4. **有身份边界的部署上,存量 cli 哨兵属主行不再零信号:起服时对留着没改的行只数不写,有就一行 warn 给出各面计数;并订正 7.148.0 节第 86 条漏写的约束 —— 判「有没有身份边界」读的是起服那一个进程自己的配置(文字订正 + 日志面加性;行为零变化;wire 零变化;部署零动作)**:
+    旧形(7.148.0 节第 86 条):一次性迁移 M48 只在没有身份边界的部署上把哨兵属主 `anon:shell-live` 改写成无主;有身份边界的部署上零改写、读数 0 —— 起服日志里看不出库里还留着多少行,运维要自己 `SELECT COUNT(*)`。
+    第 86 条没有写明的约束:判「有没有身份边界」读的是**起服的那一个进程**的配置,而改写落在整只库 / 数据根上、不可逆。同一只库 / 数据根被身份配置不同的进程打开
+    (`run-local` 不带服务凭据 / 鉴权桥;嵌入方的起服序列在装配验签器之前先打开店;临时进程连着共享 SQL 库)时,一样身份键都不带的那个进程先起,就会替有身份边界的服务进程把这些行改成无主(改写只在下面五样一样都没有时发生)——
+    **打开同一只库 / 数据根的每个进程,都至少要带一样身份键**(service 凭据、鉴权桥、`REQUIRE_PRINCIPAL`、直连门、只读 trace 凭据,任一即可)。改写之后的行是普通无主行(第 86 条「放给谁」一段照旧适用),不会因为后来起的有边界进程而回来。
+    想刻意收成无主,等价于用没有身份边界的配置起一次(第 86 条的手工一步是同一件事的 SQL 写法)。
+    新形(日志面,加性):有身份边界的部署起服时,M48 对同一批面(SQL:`session_meta` / `task_run` / `leader_run`;`DB_BACKEND=local`:会话元数据格与 run 行)用**与改写同一个逐字节比较**只数不写。
+    留着的行数大于 0 ⇒ 一行 warn `shell_sentinel_rows_retained`:`backend`、`rows`(总数)、`surfaces`(逐面计数,只列非零的面;local 上 `session_meta` = 会话元数据格、`task_run` = run 行)与指向第 86 条手工一步的 `note`;
+    起服迁移读数行多一键 `shellSentinelOwnerRowsRetained`(总行数),汇总行 `one_time_migrations_applied` 在这时是 warn。计数为 0 ⇒ 没有这一行。窗内每次起服都数、每次起服都报,直到有人处置。没有身份边界的部署改写行为不变,不数。
+    **谁需要**:多个进程共用一只库 / 数据根的部署(服务进程与 `run-local` 同根;嵌入方先于验签器装配;临时进程连着共享库)。**谁受伤**:无 —— 多三句(local 为内存里的一遍)只读计数与有行时的一行日志。
+    **已知边界**:这一行说的是「此刻库里属主为这个字面量的行有多少」,不区分存量与新写 —— 有身份边界的部署上主体恰为 `anon:shell-live` 的调用方新写下的行同属这个属主,同样被数进来;它不拦截不带任何身份键的进程:
+    这样的进程先起并改写时,改写那一方的起服日志里是读数 `shellSentinelOwnersCleared`(warn),有边界的进程之后再起读到的是 0。
+
+5. **订正 7.148.0 节第 64 条 ⑦ 与第 115 条的用词:受限技能那一问(配置有没有接已验身份来源)在已发文字里被叫「身份边界」,订正为「已验身份来源」;起服拒句的措辞随之改(文字订正 + 拒句措辞;判据、拒启面、出路零变化;wire 零变化;部署零动作)**:
+    7.148.0 节里「身份边界」一词有两个意思。第 86 条(一次性迁移 M48)与属主门的 dev-open 判据问的是「这台部署有没有身份边界」:声明了 `REQUIRE_PRINCIPAL`、或配置接了任一已验身份来源(服务凭据 / 鉴权桥 / 直连门)、或声明了只读 trace 凭据 ⇒ 有。
+    第 64 条 ⑦ 的「名单的强度 = 部署的身份边界:没有身份边界的部署(没接任何已验身份来源:……;只设 trace 凭据或只开 `REQUIRE_PRINCIPAL` 不算)上写了 `audience` ⇒ 起服拒」与第 115 条旧形句里的「受限技能的身份边界座」问的是另一件事:配置里有没有接**已验身份来源**(只设 trace 凭据或只开 `REQUIRE_PRINCIPAL` 不算)。
+    两问都对,只是不许共用一个词。订正:受限技能这一问只叫「已验身份来源」(括号里的判据本来就是它,事实不变);「身份边界」只答第 86 条那一问。
+    起服拒句首句随之从 `…but this deployment has no identity boundary: it wires no verified identity source (…)` 改为 `…but this deployment has no verified identity source: no service credential, no SSO bridge and no direct-door principal JWT is wired (…)`,
+    句尾的不变量名从 `a2a-audience-identity-boundary` 改为 `a2a-audience-verified-source`;判据(`A2A_SERVE_SKILLS` 写了 `audience` ∧ 配置没接任何已验身份来源 ⇒ 起服拒)、拒启面与两条出路(接一个已验身份来源 / 删掉 `audience`)一字不变。
+    已发的 7.148.0 节不改字节,订正记在这里;USAGE 里的同一句已按新词改。**谁受伤**:无;只把拒句文字做硬匹配的脚本要改匹配串(拒句文字不属 wire 契约)。**出路**:无需动作。**回滚**:不适用(文字 + 拒句措辞)。
+
+6. **嵌入方:验签器席(`ServiceDeps.webAdminJwtVerifier`)多一只必填只读成员 `issuer`,`createHttpServer` 的验签器 × 配置成对座多一判 —— 验签器验的 issuer 必须就是配置读出来的桥 issuer,不一致构造期拒启(嵌入方类型面 + 装配面 BREAKING;服务入口零变化;wire 零变化;部署零动作)**:
+    旧形:席的型是 `{ verify(bearer) }`,成对座只比「在不在」(上一版把两个方向钉在构造期);验签器验 X、配置里的桥写 Y 的嵌入起得来 —— `/health.center.issuer` 报 Y,门收 X 的令牌。
+    新形:席的型多 `readonly issuer: string`(这只验签器验令牌的 issuer);成对座第三判:它与配置读出来的桥 issuer(显式 `authBridgeIssuer` 恒赢,缺席而接了中心 ⇒ 中心基址回退)两侧去尾斜杠后相等才起。
+    不等,或(绕过类型的)验签器没有字符串 `issuer` ⇒ `createHttpServer` 抛,句子以 `createHttpServer: the injected webAdminJwtVerifier verifies issuer` 起头并点名两个值(过 display-safe 铸点,userinfo / query 值不进句子)。
+    **谁受伤**:自己注入验签器的嵌入方 —— 验签器对象没有 `issuer`(TypeScript 编译红;JavaScript 构造抛),或验的 issuer 与配置里写的不是同一个。服务入口(`sema-server` 进程 / 镜像 / chart)与不注入验签器的嵌入方无。
+    **补偿 / 做法**:在自己的验签器对象上加 `issuer: "<它验令牌的 issuer>"`,让配置里的桥(`authBridgeIssuer`;接了中心而没写它 ⇒ 中心基址)写同一个值;两侧只差尾斜杠不算不一致。
+    **升级前做**:嵌入方按上面对齐;服务入口无。**回滚**:无存储形变化。
+
+7. **嵌入方(运行期):`createHttpServer` 对 `peerDesk` 与 `scenarioGate` 两个必填席也在构造期判 —— 绕过类型省掉它们(或传形不对的值)当场拒启并点名席名(行为收紧;类型面、wire、部署零变化)**:
+    旧形:这两席只有型必填。绕过类型(JS / `as` 硬转)省掉 `peerDesk` ⇒ 起得来、监听,每条提交在受理漏斗开宿主租约处读 `undefined.lease`,答 `500 internal.error`;省掉 `scenarioGate` ⇒ 起得来,不带场景头的提交不受影响(它读 `resolveSpec` 自铸的那一只门),`GET /v1/capabilities/mcp` 状态面等读口与带场景头的请求(分派层的在册判问这一席)答 `500 internal.error`。
+    新形:`createHttpServer` 入口在 `runnerFor` / `authorize` / `deploymentMods` 三只拒之后多两只同形的拒:`peerDesk` 缺 `lease` / `declare` / `seat.answer` 任一 ⇒ 抛 `createHttpServer: the peerDesk seat is required — …`;`scenarioGate` 不是函数或没有 `known` ⇒ 抛 `createHttpServer: the scenarioGate seat is required — …`。`runner` / `sideQuery` / `resolveSpec` 仍只有型必填。
+    **谁受伤**:绕过类型省掉这两席(或传形不对的值)的嵌入方 —— 此前起得来,现在起不来;TypeScript 嵌入方此前就是 tsc 红,服务进程入口的部署不经此路,零影响。**出路**:传这两席 —— `createPeerDesk()`(包根,零 IO;它的 `.seat` 同时给每只 Runner 的 `peerSeat`)与 `createScenarioGate({ config, scenarios, principalCaps, logger }, "peek")`(包根);随包的 `scripts/embed-minimal.mjs` 是可运行的写法。
+
+8. **`DB_BACKEND=local`:比本构建新 / 本构建读不出 / 跳过了必经一次性迁移的数据根,拒启时数据根零写(行为修复;wire 零变化;部署零动作)**:
+    旧形:引擎版本高水位与跳版拒启臂在「打开数据根」那一步判、严格边档在起服对账里判;判之前起服已落下保管店的两把新钥匙(`sealed-key/exec-*.json`)、`prompt-epoch/` 店目录、
+    引擎内核取锁时的店目录与两只 0 B 账本,配置根与数据根合一时还有 `config.migration.SS-M11.json`;严格边档那一形连 marker 首写与本服务各店目录都在拒之前。
+    新形:这几种判收进一只只读的数据根准入,HTTP 服务在起服第 1 段(配置根供给之前)、`run-local` 在同一位置、公开序列 `createStoreBackend()` 在打开时取;拒 ⇒ 数据根一个字节不动(不取锁)。
+    拒的码(`config.schema_mismatch`)、读数种别与出路不变;起服形拒句末行改为「拒启没有动数据根」。准入之后、取锁之前另一只引擎碰了这只根(marker、会话元数据边档、存档目录或欠账标记任一变了)⇒ 打开那一步拒(专句,出路 = 重起再判)。准入按物理路径判(经符号链接 / `..` 的数据根路径判的是真目录)。
+    **谁受伤**:无;拒启进程的输出里不再先出现保管店 / 店目录的起服行。**升级前做**:无。**回滚**:回到 7.148.x 即回到「判之前先落钥匙 / 目录 / 空账本」;用 7.148.x 或更早被拒过的根上多出的新钥匙文件与空目录无害(旧构建按 `publicKeyId` 读不到就重铸自己的),可留可删。
+
+9. **跨主体投递口:额度拒的 429 多一键 `retryAfterSec` 与同值 `Retry-After` 头;配额状态文件读不出的拒有了专码 `internal.org_delivery_quota_unreadable`;嵌入方自建配额店的返回形换成判决(嵌入方类型面 BREAKING;wire 加性 + 一码;部署零动作)**:
+    旧形:`POST /v1/principal-inbox/messages` 的额度拒答 `429 org_delivery.rate_limited`,体只有 `error` / `errorCode`、没有 `Retry-After` 头;`DB_BACKEND=local` 的配额状态文件读不出时,每次投递答 `500 internal.error "internal error"`;`OrgDeliveryQuotaStore` 的 `admitAttempt` / `take` 返回 `Promise<boolean>`;`ServiceDeps.orgDeliveryGate` 的型是引擎的 `OrgDeliveryGate`。
+    新形:429 体多 `retryAfterSec`(整数秒,到当前挂钟整点桶结束,向上取整、≥ 1)、响应多同值 `Retry-After` 头,三种额度拒同口径、同一个数;配额文件读不出 ⇒ `500 internal.org_delivery_quota_unreadable` + 固定句(不点名宿主路径),无 `Retry-After`(运维修好或移走坏文件并重启本服务才恢复 —— 店只在起服时读这份文件;移走 = 当前桶计数清零);`OrgDeliveryQuotaStore` 的两个动词返回 `Promise<OrgDeliveryQuotaVerdict>`:放行 `{ granted: true }`,拒 `{ granted: false, retryAfterSec }`(包根导出该型);`ServiceDeps.orgDeliveryGate` 的型换成对引擎契约的子型 `ServerOrgDeliveryGate`(包根导出它与 `ServerOrgDeliveryOutcome`):`rate_limited` 一词的答案必带 `retryAfterSec`,另三词与引擎契约逐字相同。
+    **谁受伤**:自建配额店、或自建 `ServiceDeps.orgDeliveryGate` 的嵌入方(tsc 红即通告);只用 `internal.error` 字面识别「配额文件坏」那一形的消费方(此前它与一切未分类 500 同码)。**出路**:自建店把 `true` 换成 `{ granted: true }`、`false` 换成 `{ granted: false, retryAfterSec }`(秒数 = 店钟到当前窗结束,向上取整、≥ 1);自建门把 `rate_limited` 的答案补上 `retryAfterSec`;按 `internal.` 前缀读 500 的消费方零动作;服务进程部署零动作。
+
+10. **settings hook 的环境多一个来源:部署方 `HOOK_ENV_ALLOW` 点名放回的服务进程变量(新旋钮,缺省空;嵌入方类型面:`ServiceConfig` 多一只必填席 `hookEnvAllow`;`settings.env` 凭据拒的 message 多一句;wire 零新键、零新码;部署零动作)**:
+    旧形:hook 环境(命令钩子的子进程环境与 http 钩子 header 的 `$NAME` 插值同读)= 十二名基础变量 + 请求 `settings.env`;`settings.env` 不收凭据 ⇒ http 钩子 header 里的秘密形 token 没有合法通道,恒为空串。
+    新形:`HOOK_ENV_ALLOW=NAME,NAME` 点到、且服务进程环境里在的变量原样放回 hook 环境;能插哪些名仍是条目 `allowedEnvVars` ∩ `settings.httpHookAllowedEnvVars`(只收窄,请求层授予不了服务进程变量);点名本服务自有凭据 / 名单型旋钮 ⇒ 拒启;值是本服务某一枚凭据的另一个变量同样拒启(本节「本服务凭据换个变量名放着也不出任何出口」一条);`REQUIRE_PRINCIPAL=true` 下忽略并起服 warn。`400 request.env_credential_refused` 的 `message` 在「挪进引擎进程环境」之后多一句:settings hook 要读它,部署方还要在 `HOOK_ENV_ALLOW` 点名(`errorCode` / `field` / `entries` 不变)。
+    **谁受伤**:自建 `ServiceConfig` 的嵌入方(tsc 红即通告);按该拒句 `message` 全文匹配的脚本。**出路**:嵌入方补 `hookEnvAllow: []`(或按需点名);webhook token 放进引擎进程环境,部署方写 `HOOK_ENV_ALLOW=<名>`、钩子条目的 `allowedEnvVars` 列它;壳自起的本机引擎由壳写这只旋钮;读拒句按 `errorCode` 分支。
+
+11. **`REMOTE_EXEC=host` 车道:本服务铸的临时工作区归持有它的执行环境,最后一只放手的删它;同一身份的续跑腿拿回停驻腿的那一只环境(行为修复;wire 零变化;部署零动作)**:
+    旧形:请求不带 `cwd` ⇒ 父 run 的一次性工作区 `<HOST_WORKSPACE_BASE>/sema-host-<id>-<rand>` 在父 run 终局、销毁执行环境时被删,不管落在里面的后台子代是不是还停驻在审批门上;
+    被批准之后续跑腿另铸一只新目录,命令落在已删的那只上(引擎拒句 `the task root directory no longer exists`);同一身份每次调工厂都另铸一只新环境(续跑腿拿到空目录)。
+    新形:同一身份(顶层 run = run 号,委派子代 = 它自己的会话号)还有一只没收场的执行环境 ⇒ 工厂交回它;一次性工作区由落在它里面的执行环境共同持有,最后一只放手的删它
+    (父收场时停驻的子代还持有它 ⇒ 不删;子代最后一条腿收场 ⇒ 删)。带 `cwd` 的形零变(调用方目录永不删)。
+    **谁受伤**:停驻中被取消 / 过期的后台子代持有的一次性工作区活到进程退出(退出兜底删),此前随父收场即删。**出路**:提交时带 `cwd`;进程重起之后才批准的不带 `cwd` 的停驻子代仍落在已删目录上(重起时临时目录已被退出兜底删),同样带 `cwd`。
+    嵌入方类型面(包入口不出口,只影响直接 import 适配器源文件的嵌入方):`hostExecutionEnvFactory(config, legOf?)` 多一只逐腿参数、对同一身份交回同一只环境;`RemoteHostExecutionEnv.destroy()` 第二次调用等同一次收场。
+
+12. **请求体 `a2aPeers[i].headers` 里成员名 `constructor` / `prototype` 起拒:与 `mcpServers[i].transport.headers` / `.env` 同一张保留成员名表、同一个拒形;存盘续跑体里带这样 A2A 头名的停驻任务续跑被拒(行为收紧;wire 零新键、零新码;部署零动作)**:
+    旧形(本版之前):A2A 对端 `headers` 只拒名叫 `__proto__` 的成员;名叫 `constructor` / `prototype` 的成员照收(200),作头名交给对端座、发送时按原字节发出。
+    新形(自本版起):三个保留名(`__proto__` / `constructor` / `prototype`,与 MCP 传输记录同一张表、同一只读法)同拒 —— 新提交 `400 request.field_invalid`,`field` 点名成员级路径(如 `a2aPeers[0].headers.constructor`),原因句与 MCP 面逐字同一句,不回显值;名字大小写敏感(`Constructor`、`X-Prototype` 照收)。
+    续跑重放:存盘的请求体里带这样 A2A 头名的对端,在本部署兑现请求 A2A 时读不出 ⇒ 按「请求成员读不出」那一只判据拒续跑(`409 resume_blocked_by_policy`,`blockedBy` = `request.field_invalid`,`field` = `a2aPeers[i].headers.<名>`),卡 / 任务仍待决、行不动(此前这样的对端照挂,这一名作头名发出)。
+    **谁受伤**:把 `constructor` / `prototype` 当 A2A 头名写进请求体的调用方(极罕见),与升级前停驻、存盘体里带着这样头名的任务。**出路**:改头名;停驻的任务续跑时带合形的 `a2aPeers` 整表(续跑时换表),或取消后按本版的形重提。
+
+13. **`GET /v1/models` 的行多一键 `contextWindowSource`(`declared` / `assumed`);窗口没人声明的模型起服 / 目录落地时各一行 warn `model_context_window_assumed`;`ServiceConfig` 多两只必填席;窗口没人声明时的假定窗由 262144 改为 131072(wire 加性;运维日志加一行;嵌入方类型面 BREAKING;已声明窗口的部署零动作)**:
+    旧形:窗口没人声明(目录条目没写 `contextWindow`、部署没设 `MODEL_CONTEXT_WINDOW`)时本服务落假定值 262144,行上只给数,日志零行。
+    新形:行上 `contextWindowSource` 与 `contextWindow` 同进退(`assumed` = 假定值);模型表定形之后(起服在目录应用之后;运行中每次模型面落地之后),此刻服务的表里窗口是假定的模型各一行 warn `model_context_window_assumed`(字段 `model` / `contextWindow` / `declareAt`;每个模型名每进程一次;在 boot 被目录顶替的 env 模型不说)。**假定值由 262144 改为 131072**(取栈内部署里有人亲手声明过的最小真窗;单点一处改,不按模型族分档):压缩触发点按更小的窗算,工具 schema 延迟阈值(窗的 10% × 每 token 3 字符)由 78 642 降到 39 321 字符;`MODEL_MAX_TOKENS` 缺省仍是 32000。
+    自拼 `ServiceConfig` 的嵌入方:新增必填席 `envModelContextWindowSource`(`"declared" | "assumed"`)与 `contextWindowSources`(与 `models` 同键的目录名 → 来源表),均由 `loadConfig` 一次铸出、中心热应用与 `models` 一起换。
+    **谁受伤**:按 schema 严格校验 `/v1/models` 行的消费方(多一键);告警规则对「起服零 warn」有断言的部署(没声明窗口的部署多一行);自拼 `ServiceConfig` 的嵌入方(tsc 红即通告);真实窗口大于 131072 却没声明窗口的模型(`contextWindow` 读数由 262144 变 131072,压缩提前,工具 schema 延迟阈值降到约 39 000 字符;已声明窗口的部署不受影响)。**出路**:放行该键;声明真实窗口(目录条目 `contextWindow` / 部署 `MODEL_CONTEXT_WINDOW`,cheap 槽 `MODEL_CHEAP_CONTEXT_WINDOW`)即消掉那一行、也即回到真实的大窗(`GET /v1/models` 行 `contextWindowSource:"assumed"` 指出哪几行在吃假定值);嵌入方从 `loadConfig()` 的结果起拼,或按上面的形补两席。
+
+14. **settings 的 `PreToolUse` 钩子:`ask` 带 `updatedInput` 的改写现在生效(行为修复;类型面、wire、部署旋钮零变化)**:
+    旧形:钩子回 `permissionDecision: "ask"` 并带 `updatedInput`(真改写,与它看见的输入不同)时,本服务只记「要问人」,**丢掉改写** —— 审批卡显示模型自己的参数,人批后执行的是模型自己的参数,叠加的 `deny` 规则(如 `Write(protected/**)`)判的也是模型自己的路径;同一份改写换成 `allow` 或不带 `permissionDecision` 则生效。
+    新形:`allow` / `ask` / 不带决定词三形的改写同一条读法 —— 卡上读的、批后执行的、其后的组 / 相(含托管守卫,托管相条目改写则整相按新输入重判一遍)与 `deny` 规则判的,都是改写后的参数(同一组里的条目共用组开始时的那一份载荷,与 `allow` 的改写同)。判词不可信(拿到截断标记 / 超预算按选中)的条目,`ask` 照收、改写不作数,非托管条目此时多一行 warn `hook_verdict_not_honored` 与一帧 `hook_verdict_untrusted`(此前这一形无声)。「放行的是哪一份参数」仍只有 `allow` 才记。
+    **谁受伤**:写了 `updatedInput` 却没打算让它生效的 `ask` 钩子(此前被静默丢掉)现在会生效;只问不改写的钩子结果逐字不变。**出路**:不想改写就不要在 `ask` 里交回与输入不同的值(与看见的输入规范化后相同的值不算改写);运维不需要动任何旋钮。
+
+15. **🔴 本服务凭据换个变量名放着也不出任何出口;名单型旋钮点到这样的变量拒启(安全轴,fail-closed;行为收紧;wire 零新键、零新码;部署零动作,除非服务进程环境里有变量的值等于本服务**任何一枚**凭据而名不同 —— 目录 secret 行的整值、令牌表逐枚、模型 `apiKeyEnv` 指的值;名单型旋钮点到这样的同值别名即拒启)**:
+    旧形:值臂把每个凭据变量的**整值**交给引擎按整串比 —— `SERVICE_AUTH_TOKENS` 表里**一枚**令牌、`APPROVAL_HMAC_KEYS` 里**一把**钥换个变量名放着(同值、另一个名)不扣:`inheritEnv:"all"` 的模型 shell、`LSP_ENV_ALLOW` / `BAKE_ENV_ALLOW` 放回的子进程都拿到它;名单型旋钮只按**名**判自有凭据,沙箱名单点名这个副本照装进沙箱 env。
+    新形:值臂按本服务读它的颗粒把**每一枚**凭据交给引擎(整值总在内,`SERVICE_AUTH_TOKENS` 另加每一枚令牌、`APPROVAL_HMAC_KEYS` 另加每一把钥),每一条宿主腿都扣别名变量(整串比:部分重叠 / 前后缀不同的值照交),被扣的名进既有披露面(`secret_env_scrubbed` 行的 `keys`、`inherit_env.names_withheld` 通告);名单型旋钮点到「名是本服务凭据,或值是本服务某一枚凭据」的变量 ⇒ 起服拒,拒句开头仍是 `env <旋钮>: entry #k of n is this deployment's own credential — `,副本那一形其后多 `a copy under another name …`;模型目录换代时新并进的凭据(名或值)正被某只名单交出去 ⇒ 候选整拒,拒句开头改为 `… a model entry's apiKeyEnv makes a variable a name-list env knob hands on one of this deployment's own credentials (by its name, or by its value under another name) — `;一张令牌表里某一枚不足 8 字符 ⇒ 这一枚不扣、同表其余照扣、该变量一行 `own_credential_value_not_withheld`、能力位 `inherit_env.own_credential_values_withheld` 答 false。
+    **谁受伤**:把服务令牌 / HMAC 钥换个变量名放在服务进程环境里另作他用的部署(那个变量从此不进模型 shell、语言服务器、配方脚本、hook、git / CLI 子进程);名单型旋钮点着一个变量、而它的值等于本服务**任何一枚**凭据的部署(起服拒)—— 不止服务令牌 / HMAC 钥的副本:目录 secret 行的整值(`GIT_API_TOKEN`、`MODEL_API_KEY` …)、令牌表的每一枚、模型 `apiKeyEnv` 指的值都算,7.148.x 的名单只按名判,这样的同值别名照交出去;按模型目录换代拒句开头全文匹配的告警规则;令牌表里有短令牌的部署(多一行 warn、值能力位 false)。**升级前自查**:逐只名单型旋钮(`LSP_ENV_ALLOW` / `HOOK_ENV_ALLOW` / 三只沙箱名单 / bake-runner 的 `BAKE_ENV_ALLOW`)看它点的每个变量的值是不是本服务某一枚凭据 —— 例:`E2B_SANDBOX_ENV=GIT_TOKEN`,而 `GIT_TOKEN` 与 `GIT_API_TOKEN` 同值(一枚 PAT 同时给 repo 工具与沙箱)⇒ 7.148.x 起服、本版拒启 `env E2B_SANDBOX_ENV: entry #1 of 1 is this deployment's own credential — a copy under another name …`。**出路**:要给子进程 / 沙箱一枚凭据 ⇒ 给它铸一把自己的(名与值都不同于本服务的任何凭据)再点那个名;按 `this deployment's own credential — ` 匹配拒句;短令牌换成真随机串。
+
+16. **订正 7.148.0 节漏写的一项行为变化:`cascade: true` 与 `requireExistingSession: true` 同体的提交自 7.148.0 起照跑 —— 7.147.x 上每一级都被引擎拒;本版把「必须已在」盖给谁收成一只按引擎入口的判据(文字订正 + 嵌入方装配器边角的行为变化;wire 零变化;部署零动作)**:
+    旧形(≤ 7.147.x):这样的提交交到引擎,梯子派生每一级时只剥 `sessionId`,「必须已在」随 spec 展开到在引擎现铸的会话里冷跑的级上 ⇒ 每一级以 `resume.session_not_found` 被拒,会话在也拒,梯子以 `exhausted` 收场,一级都没跑。
+    新形(7.148.0 起):梯子的每一级不在提交的会话上取会话,提交的会话只是梯子的宿主,「必须已在」不进梯子的 spec;调用方的要求由本服务判 ——
+    会话不在 ⇒ 受理即 404 `resume.session_not_found`(`requireExistingSession: session does not exist (resume.session_not_found)`,不登记这只 id);带 run 店的部署上受理之后、执行之前被删 ⇒ 404 同码(`the session this run was to start on no longer exists …`),一级都没起;
+    执行已认领 ⇒ 删除答 409 `conflict.session_active_run`,梯子照跑。单腿、验证门(`verify`)与续跑家族不变:引擎在提交的会话上取会话,「必须已在」照旧交给引擎(只接、不建)。
+    **谁需要**:用梯子在一只既有会话上提交、又要求它必须已在的调用方(7.147.x 上这一形一律失败)。**谁受伤**:把 7.147.x 的那一拒读成「会话不在」、或读成「梯子不能与 `requireExistingSession` 同用」的调用方 —— 现在会话在就照跑;
+    嵌入方自带的装配器若在梯子提交的产物上自写 `requireExistingSession`(契约说装配器不写它):本版起这一位在梯子上被剥掉,梯子照跑(此前每一级被拒)。
+    **补偿**:要的若是「会话不在 ⇒ 拒」,在提交体上带 `requireExistingSession: true`,本服务在受理口与执行起点两处照判,同码同状态。**已知边界**:嵌入装配不带 run 店、或 run 店不带根行锁而会话店又不带执行席时,受理之后被删的梯子提交照跑(各级在自己的会话里,不碰提交的会话);三种出厂后端不在此列。
+    **出路**:无需动作(嵌入方:把「必须已在」交给提交体,不写在装配器产物上)。**回滚**:不适用(无存储形变化)。
+
+17. **单用户记忆的项目层按检出的 `.sema/project` 记号键控:带记号的检出键形 `userrepo:<属主段>/m.<24 hex>`,没有记号照旧 `r` / `p` 档(行为变更;持久数据:git 根档条目自动折进记号档,无需动手;开了记忆同步的部署先升中心)**:
+    旧形:项目层只按 git 根键控 —— `r` 档 = `origin` 网络远端 URL 归一后的哈希,`p` 档 = 项目根路径的哈希;检出里的 `.sema/project` 记号不参与。同一项目的两只 fork(两个 origin)是两把键;同一 origin 的两只检出带不同记号是一把键。
+    新形:检出带记号 ⇒ `m` 档 = 记号里项目 id 的 sha256 前 24(在任务根上读记号,与引擎判项目同一读法:linked worktree 读它自己检出里的那一份);没有记号 ⇒ `r` / `p` 逐字照旧;记号读不出(坏记号 / 嵌套在仓根之下 / 读不了)⇒ 这一任务没有项目层,写家落全局层,运维日志 `memory.project_scope_absent`(`reason: unreadable`)与一次 fail-open 留痕 `server.memory.project-marker-unreadable`(计数逐次、每进程一行 warn)。
+    档序 `m > r > p`:检出取最高档,低档里的条目在该项目下一个任务开跑前自动折进当前档(info `memory_project_layer_folded`;常设,不随窗删)—— 已带记号的仓升级后第一个任务就把 `r` / `p` 档的条目折进 `m` 档,同一条记忆照读得到。没有记号的检出上请求体里的 `projectId` 不改项目层的键。
+    **谁受伤**:① 开了记忆同步(`MEMORY_SYNC_*`)、中心还是旧版:旧中心不认 `m` 档,该层每轮一行 warn `memory_sync_layer_failed`(条目在本机,不丢);② 同一远端下还有没带记号的检出(老分支、没拉到记号的机器):它此后写进 `r` 档的条目由下一个带记号检出的任务折走,拉到记号之后才读得到;③ 带坏记号 / 嵌套记号的检出:此前有项目层,现在没有(写全局层);④ 按键里档字母分支的脚本(键按契约不透明)。
+    **出路**:① 先升中心再升客户端;② 让各检出都拉到记号;③ 修好记号(引擎在每条腿上报同一个错:`config.memory_project_marker` / `config.memory_project_marker_nested`),修好后 git 根档自动折进记号档;④ 把键当不透明串读。回滚:回到上一版后带记号的检出回到 `r` / `p` 档,已折进 `m` 档的条目不在旧版的读列表里(盘上不删;再升级即重新可见)—— 要回滚又要保住这段时间的项目记忆,回滚前先别跑带记号检出的任务。
+
+18. **续跑认领之后提交执行放置撞店故障:停驻的 run 回到停驻、卡仍待决,答 `503 state.resume_context_unreadable`(此前 `500 internal.error`,run 落 `failed`)(行为修复;wire:一面 500 → 503,码沿用;零 DDL;部署零动作)**:
+    旧形:决断(批准 / 拒绝)、`/resume`、`plan_review`、应答口的停驻赎回席与 SLA 拒扫在认领停驻的 run 之后、交给引擎之前,提交这条会话的执行放置那一次店往返失败(库断连 / 拒连 / 超时、缺表 / 权限拒、认不出的库错、本服务的程序错)
+    ⇒ run 终结成 `failed`、会话认领与提交幂等键放开,答 `500 internal.error`;卡仍待决,再发同一个决定 ⇒ `200` 不带 `taskId`,引擎照续,但不持会话认领、不落那条 run 的事件账,`GET /v1/runs/:id` 一直是 `failed`。
+    `/wake` 现建的行撞同一形 ⇒ `500`(行终结,卡仍待决)。
+    新形:店故障不是答案 —— 续跑认领的停驻行回到认领之前的停驻词(`suspended`;`plan_review` 为 `needs_review`),会话认领与幂等键留着,卡仍待决,答 `503 state.resume_context_unreadable`(句子:`the stored state of this task could not be read or written just now (the store failed), …`;体只有 `error` / `errorCode`);认领那一笔本身(`markResuming`、`/wake` 现建行)撞店故障同答这一只 503(此前 `500 internal.error`);
+    本服务的程序错 ⇒ `500 internal.error`,run 同样回到停驻。认领窗里已有人取消这条 run(耐久取消旗在)⇒ 不回停驻,按取消收场:卡按取消结算、run 取消终局,答 `200 { …, status: "failed", errorCode: "cancelled" }`。`/wake` 现建的行删掉(它在这次认领之前不存在;认领与幂等键随行去,撤回同下一条 ④),答同一只 `503`。店答出会话不在 / 住客换了 ⇒ `404 resume.session_not_found`,续跑认领的那条 run 照旧终结、`/wake` 现建的行同样删掉(写者在别处、已放在别的车道两形见下一条)。
+    **谁受伤**:依赖「续跑撞故障 ⇒ run 终结、会话放开」的部署 —— 这条 run 现在留在停驻态继续占着会话(同一会话的新提交答 `409 conflict.session_active_run`),直到再决、取消或停驻过期收割;按 `500` 告警的监控在这一形上看到 `503`。
+    **出路**:`503 state.resume_context_unreadable` 一臂 = 稍后原样重发同一请求(一直如此 ⇒ 报运维查库;`plan_review` 的一次性证明已在受理时用掉 ⇒ 换一份新证明再发);不想等它 ⇒ `POST /v1/runs/:id/cancel`。**回滚**:回到上一版即回到旧形;数据零改动。
+
+19. **认领之前到交给引擎之前那一段的店故障在每一面都不再是答案;撤回本请求铸的 run = 删掉它;认领之后读出「本处此刻不能执行」与认领之前同一个命运、同一只答(行为修复;wire:新码 `503 state.run_store_unavailable` + 几面 500 → 503 / 409 + 认领之后两只 409 改答 `resume_blocked_by_policy`;零 DDL;部署零动作)**:
+    旧形:① 续跑腿(决断、`/resume`、`plan_review`、`/wake`、应答口的停驻赎回席与 SLA 拒扫)提交放行之后、把续跑交给引擎之前那一段(排空 workflow 完成、通告口落账)撞店故障 ⇒ 停驻的 run 终结成 `failed`,答 `500 internal.error`;
+    ② 新提交(`POST /v1/tasks` 同步 / 流式、`POST /v1/runs`、A2A)认领这一段(建行认领、执行放置、续跑输入的写、起跑之前的认领复核)、`/decide` 在宿主会话上起的新一跑(含落决定行那一笔)、停驻子代赎回认领之后的执行放置,
+    以及每一面认领之前那一次执行席读撞店故障 ⇒ `500 internal.error`(流式腿的流断掉、没有终帧);落决定行那一笔店答「没落成」⇒ `500`;③ 续跑认领之后提交放置读出 `execution_lane.tree_bound` / `conflict.session_mirror` ⇒ 原码原样 409,
+    停驻的 run 以 `failed` 收尾、卡留着谁也兑不了;宿主新一跑与停驻赎回认领之后同形 ⇒ 原码原样 409;④ 撤回本请求铸的 run 把它终结成 `failed` 留着 —— 自带 `taskId` 的同 id 重发读到它(`202` + `status: failed`,不跑)。
+    新形:① 停驻的 run 回到停驻、卡仍待决,答 `503 state.resume_context_unreadable`(`/wake` 现建的行删掉,同答;认领窗里已挂取消旗 ⇒ 按取消收场,`200 { …, status: "failed", errorCode: "cancelled" }`);
+    ② 新提交答 `503 state.run_store_unavailable`(新码;认领之后的流式腿 = 流的终帧);续跑家族(含 `/wake`、宿主新一跑与它的落决定行)答 `503 state.resume_context_unreadable`;停驻子代赎回答 `503 decide.store_unreachable`(体带 `taskId`;认领那一笔撞店故障也换成这同一句,码与状态不变)
+    —— 认领之前那一读与认领之后同一面同一只答;落决定行答「没落成」⇒ 与起跑之前认领复核答「没持有」同一只三臂答复(`409 conflict.session_active_run` / `404 resume.session_not_found` / `409 conflict.claim_lost`);
+    ③ 停驻的 run 回到停驻(停驻赎回回滚)、卡仍待决,答 `409 resume_blocked_by_policy`(`blockedBy` = 原码,`forkPath` / `boundLane` 随体,`retriable: true`),与认领之前读出同一个事实那一形同一只体,三面同;
+    ④ 本请求铸的行删掉(认领、提交幂等键、事件随行去),同一个 `taskId` / 同一把 `Idempotency-Key` 的重发是新提交、真跑。本服务的程序错各面仍是 `500 internal.error`(认领同样已撤回)。
+    **谁受伤**:把 `500` 读成「已失败、换个法子重投」的调用方与按 `500` 告警的监控(这几面现在是 `503`,稍后原样重发);按 `execution_lane.tree_bound` / `conflict.session_mirror` 码分支的续跑调用方(认领之后那一形改读 `blockedBy`);
+    依赖「认领之后读出别的车道 ⇒ run 终结、会话放开」的部署(run 现在留在停驻占着会话,同一会话的新提交答 `409 conflict.session_active_run` —— 与认领之前读出同一事实那一形同);
+    提交被拒之后按 `taskId` 去读那条 `failed` run 找拒因的调用方(那一行不再有,`GET /v1/runs/:id` 答 `404`;拒因在这一次的答复体 / 终帧里);断连转后台(`x-detach-on-disconnect: true`)而恰在认领这一段断开的流式调用方(`x-task-id` 读到 `404`)。
+    已绑设备的会话上认领之后那一次执行席读撞店故障由 `409 device.not_bound` 改答同一只 `503`(与认领之前那一读同);设备准入 / 首绑 / 再断言上本服务的程序错不再折成 `device.not_bound`,响亮 `500`。
+    **出路**:`503` 各臂 = 稍后原样重发(同 id / 同键重发真跑;撤回那一笔自己也没落、或撤回之前那一行已被收割时,行以 `failed` 留着,同键重发照样真跑、同 id 重发读到它 —— 换一个 id);`409 resume_blocked_by_policy` 读 `blockedBy`;
+    不想等停驻的 run ⇒ `POST /v1/runs/:id/cancel`。**回滚**:回到上一版即回到旧形;数据零改动(删掉的只有从没起跑的行)。
+
+20. **卡已提交之后停驻的簿记撞店故障不再烧掉等审批的 run:店答出的拒是答案,店的故障不是(行为变更;wire 零新键、零新码;嵌入方类型面加宽一处;部署零动作)**:
+    旧形:run 停在要批的门上(卡已在 checkpoint 店里)而记这次停驻的账本行(停驻帧 / 停驻前用量 / 结果到手之后的清单行与缓冲文本)写抛 ⇒ 后台 run 与续跑腿的再停把行收成 `failed`、卡作废(7.141.0 节第 14 条),续跑腿另答 500;
+    run 行的停驻写本身抛 ⇒ 行无心跳地留在 `running`,由失联收割收成 `failed`,卡悬到审批兜底收割;停驻写被店答出「这条行已不是本腿的」(失联收割 / 取消先落了判决)⇒ 无声,卡仍待决。
+    新形:停驻只由 run 行的停驻写提交(后台 / 续跑 / 同步三条腿同一只提交点)。账本行写不下只留痕(`fail_open_total{tag="server.runs.terminal-ledger-write-failed"}`,`arm=park-*` / `resume-park-*`),行照常停驻、认领在、卡可决。
+    行的停驻写抛 ⇒ 不收场(不落 `failed`、不作废卡):当拍再提交一次,仍没答出 ⇒ 每 30 s 再提交,店答出即收。再提交与第一笔同一个形(一笔抛了的写可能已落下):写;店答出「不」⇒ 读行、由行答
+    (怎么答见本节「停驻写只许这条 run 的持有腿落下」一条)。续跑腿的中止句柄认领一赢就登记 —— 此前在执行放置提交放行之后,
+    这一窗里按下的取消现在落在续跑腿上、续跑按取消结算,此前只挂旗、续跑照跑完。上界 = 两个判活窗(`REAP_RUN_STALE_SEC`),到上界停手,交既有出路 —— 失联收割按判活窗把行收成 `failed` 并放认领,审批兜底收割按卡的截止 / 绝对兜底时刻作废卡。
+    每一次失败计 `fail_open_total{tag="server.park.row-commit-deferred"}`(detail `leg=<bg|resume|sync> step=<first|again|retry|gave_up>`)。停驻写被店答出拒、读到 run 已收场 ⇒ 卡跟着作废(行先、卡后;没作废成照旧计 `server.park.held-card-void-failed`,detail 多 `at=park_commit_refused`;取消那一形 `at=park_commit_cancelled`)。
+    取消落在结果到手之后的腿照旧先作废卡、再放认领(7.141.0 节第 14 条的这一半不变)。与续跑认领之后提交撞店故障同一条律(店的故障不收场、卡仍待决)。
+    **谁需要**:共享库偶有抖动的部署 —— 一次写失败不该烧掉等人批的 run、也不该留下「行终局、卡待决」。**谁受伤**:续写期间行停在 `running`,对那张卡的决定答 409 `conflict.not_resumable`,写落下之后再发即受理;
+    只读账本尾帧判停驻的尾随方在那一形里看不到停驻帧(`GET /v1/runs/:id` 与待决列表照说停驻);店一直故障时这条 run 占着会话直到失联收割收走;再提交期间按下的取消答「取消中」,至多一个心跳节拍之后由下一次再提交落成取消终局。
+    **补偿**:决定答 409 时稍后原样重发;看 `step=gave_up` 计数定位交给既有出路的那次停驻;判活窗旋钮同时定续写上界。
+    **嵌入方**:三只 run 店的 `setSuspended` / `setNeedsReview` 返回型由 `Promise<void>` 加宽为 `Promise<boolean>`(`true` ⇔ 行停在这个词上),以 `Promise<void>` 覆写这两只的子类需改;`runInBackground` 多一个必填参(本腿的持有腿 + 判活窗,见本节「停驻写只许这条 run 的持有腿落下」一条)。
+    **回滚**:回到上一版即回到旧形(零数据面、零 DDL)。
+
+21. **停驻写只许这条 run 的持有腿落下、不落在挂着的取消请求上:`task_run` 加一列 `leg_id`(SQL 后端升级前先执行一句 `ALTER`;行为修复;wire 零新键、零新码,两面停驻答复改按收场的行作答;嵌入方类型面 BREAKING)**:
+    **升级前做**:见本节段头升级清单(SQL 后端一句 `ALTER`,先升库;不回填 —— 列之前的行读作「没有持有腿」)。不执行 ⇒ 本版起服列册探针拒启 `config.schema_mismatch`,拒句带同一张清单。
+    `DB_BACKEND=local` 与内存店零动作(`run.json` 缺这一键读作没有持有腿)。
+    旧形:停驻写(`setSuspended` / `setNeedsReview`)的 CAS 只看行在跑(或已停在本词上);「行还是不是本腿的」读行的持有副本与本进程的在飞登记 ⇒ 一笔回执丢了的停驻写之后,续跑腿在同一副本上认领了这条行而还没登记时,
+    旧腿的再提交把在跑的续跑腿的行停回 `suspended`;run 在跑时按下的取消(只置旗)落在第一笔停驻写之前 ⇒ 行照停、卡可决,下一次批准的认领清掉旗、被取消的活照跑。
+    新形:持有腿 = `task_run.leg_id`,每次认领(建行 / 续跑认领)铸一只、交给认领者;停驻写的 CAS 多两件 —— 行的持有腿是本腿的、没挂取消请求;对一条在跑行,取消与停驻恰好一笔赢。
+    店答出「不」⇒ 读行、由行答:已收场 / 不在 ⇒ 卡作废;归别的腿(含没有持有腿的行)⇒ 停驻成立过、卡不碰;归本腿、挂着取消 ⇒ 先作废卡、再落取消终局(码 `cancelled`);店拒而行读来该写 ⇒ 计 `fail_open_total{tag="server.park.row-commit-contradicted"}`,当店故障再提交。
+    认领之后提交没放行时撤回本请求铸的行(删行)读同一只身份:行上的持有腿不是建行交回的那一只 ⇒ 一个字节不动。
+    停驻提交答出 run 已收场时:同步提交 `POST /v1/tasks` 答 200 + 收场那一行的信封(与同键重放同一只:终局行的结果 —— 取消那一形 `terminal.code: "cancelled"`;行上没有结果 ⇒ 回执三键;此前答停驻回执、`status` 为停驻词);续跑腿再停 / 重开答收场那一行的 `status` / `errorCode` / `errorMessage`、不带 `retriable`;
+    引擎在提交前拒、放回停驻答出收场 ⇒ 拒体 `retriable: false`、不带 `wayOut`。流式提交的 `done` 帧在停驻提交之前已上流(既有序),那一形帧上仍是停驻词,`GET /v1/runs/:id` 读收场的行。
+    **混版本窗**:两项担保(持有腿、取消旗)需全部写者在本版 —— 旧副本的停驻写不比持有腿也不看旗,旧副本的续跑认领不铸持有腿(行上留着前一条腿的那一只);本版副本读到没有持有腿、在跑的行(旧副本持有)⇒ 不写、卡不碰。
+    **谁需要**:用审批门(工具门 / 计划门)且共享库偶有抖动的部署,与在 run 停驻前后按取消的用户。**谁受伤**:SQL 后端的部署要先执行一句 `ALTER`;按同步提交 200 体带 `status` 停驻词判「已停驻」的调用方在取消先到的那一形读到终局结果(`terminal.code: "cancelled"`);
+    自建 run 店 / 直调 `runInBackground` 的嵌入方(类型面)。**补偿**:拒句原样给出 `ALTER`;同步提交答终局结果即 run 已收场(卡已作废,不用再去决)。
+    **嵌入方**:`RunRecord` 多必填成员 `legId: string | null`;三只 run 店的 `createRun` 成功形多 `legId`,`markResuming` 返回型 `Promise<boolean>` → `Promise<string | undefined>`(赢 ⇒ 本次认领铸下的持有腿),
+    `setSuspended` / `setNeedsReview` 多必填末参 `legId`(停驻写只许它落下),`withdrawMintedRun` 多必填末参 `legId`(撤回只认它);`runInBackground` 第五位多一个必填参 `parkCommit: { legId, runStaleSec }`(原第五位起的各参后移一位;
+    绕过类型交来的不是一只持有腿 ⇒ 引擎起跑之前按本腿失败收场:行 `failed`、句子点名持有腿);新导出 `mintRunLegId`(持有腿的唯一铸点)。
+    **回滚**:先停光全部本版副本 → `ALTER TABLE task_run DROP COLUMN leg_id;` → 再起上一版(上一版把多出的这一列读成幽灵列、按「库比构建新」拒启,所以这一句要先执行);删了再升本版 ⇒ 重新执行上面那一句。
+
+22. **带 `cwd` 提交的梯子(`cascade: true`)每一级与验证门(`verify: true`)的验证器腿落在提交的目录里,不再落本服务现铸的临时目录(行为修复;用户可见;wire 零变化;部署零动作)**:
+    旧形:host 车道上这两种组合腿跑在引擎现铸的会话里,工厂读不到提交登记的 `cwd`,每一条落在 `HOST_WORKSPACE_BASE` 下一只 `sema-host-*`(那一级收场即删):梯子写的文件不在项目里,停驻续跑的那一级 `pwd` 是临时目录,验证器验的是一只空目录。
+    新形:组合入口把提交的会话登记的 `cwd` 作为交活方的工作目录交给每一条腿(委派子代用的同一臂),每一条腿的工作目录 = 会话登记的 `cwd`(与同一会话上的普通 run 同读);会话从没登记过 `cwd` 的提交照旧落临时目录、收场即删。普通 run 与跑在提交会话上的腿(验证门的实现腿 / 修复腿)读数不变。
+    **谁需要**:在自己项目里用梯子 / 验证门的用户。**谁受伤**:依赖梯子的级落在隔离临时目录的调用方(靠缺陷跑的):失败那一级的改动现在留在提交的目录里,下一级冷跑时看得见。
+    **出路**:要每一级在隔离的目录里跑 ⇒ 用一只从没登记过 `cwd` 的会话提交、且不带 `cwd`(每一级各落一只临时目录、收场即删)—— 只是这次不带 `cwd` 不够:`cwd` 登记粘在会话上,同一会话上之前带过 `cwd` 的,
+    之后不带 `cwd` 的提交照旧在那只目录里跑(普通 run 同读);梯子的级本来就逐级重做副作用,写操作请自带幂等或用结构化输出门在副作用之前判。部署零动作。**回滚**:不适用(无存储形变化)。
+
+23. **读拒规则不按字节守的 run 照跑时,run 事件流多一帧 `engine_notice` `config.read_deny_floor_unkept`、终局结果多一键 `readDenyFloor`;`READ_DENY_FLOOR_REQUIRED=true` 的 409 拒句改为本服务的句子(行为变更;wire 加性:一通告码、结果一键;部署零动作)**:
+    旧形:缺省部署(`READ_DENY_FLOOR_REQUIRED` 未设)上读拒表有行、执行环境不守读拒字节地板(`REMOTE_EXEC` = `host` / `ssh` / `adb` / `device` 恒不守;沙箱三车道今天也不守)的 run 照跑,
+    只有运维日志一行引擎句(点名引擎席名 `readDenyFloorRequired`);run 的流、事件账、run 行、同步 200 体一处都不说。设了 `=true` 的部署上,409 的 `error` 是引擎句。
+    新形:照跑 ⇒ run 事件流一帧 `engine_notice`(`code: "config.read_deny_floor_unkept"`,`detail: { rowCount, sessionId, runId }`),终局结果 `readDenyFloor: { code, message }`(与那一帧逐字同句);
+    句子点名执行环境 `REMOTE_EXEC=<车道>` 与出路 `READ_DENY_FLOOR_REQUIRED=true`,运维 `engine_notice` 日志行同一句。`=true` ⇒ 准备期拒照旧(409,码不变),`error` / run 行 `error` / `done.result.terminal.message` /
+    起服 warn `read_deny_floor_required_unkept` 的 `note` 是同一只组句器的拒起句,零帧、无 `readDenyFloor`。读拒表空、执行环境守地板 ⇒ 都不出。
+    帧投在这条 run 所在的那条 run 腿的流上:cascade 的每一级、verify 的验证器、子代各一帧,落在父 run 的事件流(`detail` 说的是那一条 run);verify / cascade 的续跑腿同样投;
+    停驻中被取消的 run,取消终局带停驻行上那一格;`run-local --json` 的终局带这一格,文字模式 stderr 打同一句。
+    **谁需要**:写了读拒规则(或靠出厂读拒档)、跑在不守地板执行环境上的用户 —— 那些规则命令点名时照拒,但程序打开文件时不拦,字节可以进对话。
+    **谁受伤**:按 `engine_notice` 码闭集或结果全键集逐字断言的消费方;按 409 `error` 原文匹配引擎句的脚本(按 `errorCode` 判)。
+    **出路**:要拒起而不是照跑 ⇒ 设 `READ_DENY_FLOOR_REQUIRED=true`;不想看到这一帧 ⇒ 换守地板的执行环境。部署零动作。
+
+24. **一次性迁移 M46 窗关删码之后的跳版库:起服拒启并给出路,不再让存量 `Skill` 会话豁免行代答同名工具;订正 7.148.0 节第 74 条「窗」一段末句(本版对完好的库行为零变化;持久面:标记表改由中央建表语句建,形不变、零 ALTER;wire 零新键;部署零动作)**:
+    旧形(7.148.0 节第 74 条):「窗关之后第一个 minor 删迁移步与读数键。跳过本版直接升上来的库,存量 `Skill` 行照旧代答「不绑授予」的同名调用」—— 删码之后,从 ≤ 7.147.x 直升的库(SQL 库或 `DB_BACKEND=local` 数据根)里
+    更早版本为「激活某技能」落下的 `(会话, "Skill")` 豁免行一声不响地代答部署自挂的同名工具。
+    **勘误(第 74 条末句)**:删码之后这类库**起服拒启**,不再照旧代答 —— 常设的跳版拒启臂(无窗)在本次起服对这只库的任何写之前判:首次放行早于 `Skill` 豁免截点 T0(T0 缺席 ⇒ 任一)的 `Skill` 行在场 ⇒
+    拒 `config.schema_mismatch`(SQL:`ensureSchema()` 建表之前,具名类 `LegacySkillExemptionsPresentError`,拒句点名行数与截点;`DB_BACKEND=local`:数据根准入,读数种别 `skipped-required-migration`,点名会话数、截点与出路版本),库 / 数据根一个字节不写。
+    出路 =(1)先用一个仍带这条迁移、不低于 7.148.0(`DB_BACKEND=local` 还要不低于拒句里已记的引擎高水位)的版本(服务或 `run-local`)对这只库完整起一次 —— 它落 T0 并删掉那些行 —— 再升;
+    (2)SQL 另可手工 `DELETE FROM approval_exemption WHERE tool_name = 'Skill'`(那些会话的人下一次 `Skill` 调用被问一次)。第 74 条其余各句不变。
+    新形(本版起,常设):T0 = 一只按今天的意思读会话豁免行的构建第一次接管这只库的时刻,每次起服**缺席才落**、先落的那一只赢 —— SQL 由 `ensureSchema()` 建表之后的种子行落进标记表 `one_time_migration_marker` 的 `M46` 行
+    (标记表改由中央建表语句建,两方言同形,与 7.148.0 由迁移自建的那一张逐列相同 ⇒ 零 ALTER;MySQL 协议上新建的那一张与中央各表同钉 `COLLATE utf8mb4_bin`,已建的那一张不动 —— 键是固定的迁移名,列册对账不看排序规则);`DB_BACKEND=local` 由数据根准入的锁内一步(抬引擎版本高水位之前)写 `one-time-migration-M46.marker`。
+    M46 在窗内照旧删 T0 之前的行(读同一个 T0);删码之后全新的库第一次起服就有 T0,其后写下的合法「本会话放行」`Skill` 行不会被判成截点之前的行。
+    **DDL(本版起由起服的中央建表语句发,`IF NOT EXISTS`,已有的表不动;运维零手工)**:MySQL 协议 `CREATE TABLE IF NOT EXISTS one_time_migration_marker (migration_id VARCHAR(16) NOT NULL PRIMARY KEY, marked_at_ms BIGINT NOT NULL) COLLATE utf8mb4_bin`;
+    PostgreSQL `CREATE TABLE IF NOT EXISTS one_time_migration_marker (migration_id VARCHAR(16) COLLATE "C" NOT NULL PRIMARY KEY, marked_at_ms BIGINT NOT NULL)`;建表之后的种子行 `INSERT INTO one_time_migration_marker (migration_id, marked_at_ms) VALUES ('M46', <此刻的毫秒>)`
+    只在缺席时落(MySQL 协议 `ON DUPLICATE KEY UPDATE migration_id = migration_id`,PostgreSQL `ON CONFLICT (migration_id) DO NOTHING`)。这一行此后常设:每只库一行,是这只库的截点。
+    **fail-closed 律(截点的两只读数)**:截点或一行的首次放行时刻读不出时,读作「更早」或拒启,永不读作「此刻」或「没有」——
+    截点行在而读不出时刻(手改成超出时刻范围的数、非数)⇒ 起服拒,在建表之前、带不带 M46 都判(7.148.0 上 M46 对超出范围的值一行不删、零信号),出路 = `DELETE FROM one_time_migration_marker WHERE migration_id = 'M46'` 再起;
+    `DB_BACKEND=local` 的截点文件读不出 ⇒ 数据根准入拒(读不出的那一形,数据根零写;7.148.0 是 M46 的腿在打开数据根之后拒)。
+    `DB_BACKEND=local`:豁免日志里读不出首次放行时刻的记录(缺 `ts` / `ts` 不是时刻;写口从来都写,只有手改或损坏的日志)读作最早 —— 按截点算在截点之前(M46 删它、删码之后的臂拒它);
+    `GET /v1/approvals/:sessionId/exemptions` 上这类行的 `createdAt` 由「本次起服的时刻」改为 `0`。
+    **谁需要**:窗关之后从 ≤ 7.147.x 直升的部署。**谁受伤**:那类直升的运维 —— 起不来,拒句给两条出路;本版里无人(M46 仍在,臂只判不拒)。**补偿**:拒句的出路;升级路径见下。
+    **升级前做**:无(本版零 DDL 要手工执行、零新旋钮)。从 ≤ 7.147.x 升级的部署,在 M46 的窗内(7.148.0 发布日 + 30 天,窗口见 `plugins/one-time-migrations.ts` 登记表)至少用一个带它的版本起一次服,就不会撞上这条拒启。
+    **回滚**:零 DDL、零手工。标记表里的 `M46` 行与数据根里的标记文件对 7.148.x / 7.147.x 无害(7.148.x 读同一个 T0,7.147.x 不读);多出来的标记表 7.147.x 不读。
+    不要为回滚删表或删行:表里还有 M42 / M43 / M51 的标记(删了那几条下一次起服重判);删 `M46` 行 ⇒ 下一次起服以那一刻为新截点,其前写下的 `Skill` 行都算截点之前。
+
+25. **`DB_BACKEND=local` 的店落在易失介质上不再一律拒启:local 店对引擎的声明改由一只读者定 —— 店落在调用方自己的盘上(host 车道单主:壳自起的本机引擎)且数据根易失,或运维写了新旋钮 `LOCAL_STORE_DURABILITY=ephemeral`(闭集只有这一个词)⇒ 会话店与检查点店两半一起声明 `process-local`,照常起服、读面如实、起服 warn 一行;店落在调用方看不见的 worker 盘上而没写这一词 ⇒ 照旧拒 `config.store_not_durable`(行为变更;一只新旋钮;wire 零新键、零新码;引擎静态装配读数在这两形上变;部署零动作)**:
+    旧形(7.148.0 节第 34 条):local 店对引擎的声明是常量 —— 会话店(连同委派分区)与检查点店恒声明 `durable`(活过进程重启);起服布线审计「引擎静态装配报会话店 `declared_durable` ∧ 会话店的介质(数据根)判 `ephemeral` ⇒ 拒启」
+    因此对一切数据根落在容器可写层 / tmpfs / emptyDir 上的 local 部署成立,包括无卷容器(Docker / devcontainer / CI)里壳自起的单用户引擎;想在易失介质上跑 local 店的运维除了挂卷或换 `DB_BACKEND=memory`(店进内存、重启即丢)没有别的写法。
+    新形:拒启判据一字不改,变的是声明从哪来 —— 只有一只读者,按序判:① 写了 `LOCAL_STORE_DURABILITY=ephemeral` ⇒ `process-local`(不论车道与介质);② 店落在**调用方自己的盘**上(`REMOTE_EXEC=host` ∧ 没开 `REQUIRE_PRINCIPAL`;local 上本就不许开)
+    且数据根介质判 `ephemeral` ⇒ `process-local` —— 调用方的工作区、工具与会话史同在那块盘上,部署不替他声明他自己那块易失盘活过替换;③ 其余 ⇒ 店型的设计声明 `durable`(开发机、挂了卷的容器、非 Linux 判不出的介质 —— 壳的笔记本形零变化)。
+    声明降为 `process-local` 时**两半一起降**:会话店顶层与检查点店读同一份(只降一半,引擎的 durable-park 自检会读出「检查点活过、会话不活」的缺口);委派分区(子代转录)的声明不降 —— 它决定后台子代转录档位 `full`,降了它要审批的后台子代就停不住⇒ 引擎静态装配读 `session.store = "process_local"`(接了检查点店〔`DURABLE_APPROVAL`〕时 `parkLane.checkpointDurability = "process_local"`;`fleet.subagentTranscripts` 照旧 `full`),
+    审计「声明不是 `declared_durable` ⇒ 恒过」;起服一行 `wiring_static_warning`(句子写明依据、介质判定与挂卷出路;停驻审批不随替换保留这件事并在这一行里,park 那条告警不再另起)。`GET /v1/capabilities` 的 `store.durability` 与 `/health.store.durability` 照旧按介质如实报(与上一版同一只读数)。
+    拒句的出路从两条变三条:挂持久卷 / `LOCAL_STORE_DURABILITY=ephemeral` / `DB_BACKEND=memory`。`DURABLE_APPROVAL` 的缺省不变(进程重启照旧活过:停驻审批在同一只容器里跨重启续得上)。
+    **新旋钮** `LOCAL_STORE_DURABILITY`(enum,闭集只有 `ephemeral`;缺席 = 店型的设计声明;别的任何词拒启 —— 没有第二个放宽词,也不收 `durable` 这样的反向写法):运维声明这台部署的 local 店易失。
+    **后果**:会话店与检查点店对引擎声明 `process-local`;店里的会话、停驻审批与记忆不随容器 / Pod 替换保留(进程重启照旧活过)。介质持久(挂了卷)时写了也只改声明:读面照旧报 `durable`,起服 warn 一行如实说介质。
+    SQL / memory 后端不读它。**这只旋钮由部署者自己设**:壳 / 编排器 / 安装器不替用户写(替用户写 = 替他放弃这份承诺);壳自起的本机引擎不需要它(②那一臂)。`REMOTE_EXEC=device` 的部署要 SQL 后端(既有不变量),本条与它无关。
+    **谁需要**:在无卷容器里跑壳 / 单用户引擎的人(会话随容器一起删是他们接受的,与参照实现在同一只容器里同形);CI / 预览环境里刻意不挂卷、但要 local 文件店行为的部署(写那一个词)。
+    **谁受伤**:① 把 host 车道单主的 local 部署放在易失介质上、却以为会话会活过替换的人 —— 上一版拒启,本版起服;② 误把生产 local 部署声明成易失的运维 —— 停驻审批与会话不再跨替换;③ 读引擎静态装配(`wiring_manifest` / 诊断面)`session.store` 的消费方:这两形上读到 `process_local`。
+    **补偿**:读面如实(`store.durability` = `ephemeral`)+ 起服 warn 一行(依据 + 挂卷出路);拒码不变;写了词的部署撤掉这一词即回到设计声明(介质易失则照旧拒启)。非 host 车道且没写词的 local 部署零变化。
+    **拒启在任何写之前**:local 店的拒启判挪到起服第 2 段车道合成之后、第一笔往数据根 / 封签钥匙目录的写之前(判据读车道,所以在车道合成之后;保管店铸钥匙、第 3 段开店都在它之后)。
+    7.148.0 在第 9 段布线审计才拒 —— 拒之前已在易失数据根上铸出封签钥匙(日志还叫人把它备份)、建出几十个条目;本版拒的时候数据根上没有本服务的店、封签钥匙目录里没有钥匙。机器码不变(`config.store_not_durable`),
+    拒句头换成「store durability admission failed — refusing to start before any store or sealed key is written」。配置根与数据根重合时(都取缺省 `AGENT_DATA_DIR` / `~/.ai-agent`,或写成同一目录)
+    同样零写:配置根上的一次性迁移 SS-M11 与配置根供给(`SEMA_CONFIG_DIR`)都排在这一判之后(见本节「起服序」一条)。
+    `DB_BACKEND` 没写(缺省推导出 local)、数据根空、易失又建不出店的部署,7.148.0 开店失败会降级成 memory 起服,本版在开店之前就拒。第 9 段布线审计的同码一臂仍在(引擎读到的会话店声明 × 数据根介质的通用对表,也管没有后端的 env-only 形);local 部署走不到那里就已判过。
+    **三只根各管什么**:拒启看**数据根**(会话店与检查点店落在它上面)与**显式写了的**封签钥匙目录(`SEALED_KEY_DIR`,停驻审批耐久时;见本节「起服序」一条)。`/health.store.durability` 与 `GET /v1/capabilities` 的 `store.durability` 报**参与判定的根里最弱的那只**(数据根 / 封签钥匙目录 / file 记忆根 —— 记忆根只在 file 记忆引擎真接了线时参与;逐根明细在 `GET /v1/diagnostics/wiring` 的 `storeDurability.roots`);
+    缺省的封签钥匙目录与 file 记忆根只进读数与起服 warn,不拒启。file 记忆根 = `MEMORY_ENGINE_DIR`,缺省 `AGENT_DATA_DIR`,再缺省 `~/.ai-agent` —— **跟 HOME 走,不跟 `LOCAL_DATA_ROOT`**:接了 file 记忆引擎、只给数据根挂卷而 HOME 在 emptyDir / 容器可写层上 ⇒ 起得来,
+    但 `/health.store.durability` 报 `ephemeral`(记忆随替换而去);要读面报 `durable`,三只根都落到卷上(或把 `MEMORY_ENGINE_DIR` / `SEALED_KEY_DIR` 指到挂进来的卷上)。封签钥匙目录缺省在数据根下(`<数据根>/sealed-key`),只有单独写了 `SEALED_KEY_DIR` 才会与数据根分家 ——
+    分家且落在易失介质上时,替换之后封签的模型钥匙与停驻行封签钥匙(`checkpoint-ctx-keys/`)都没了:停驻审批耐久 ⇒ 拒启(见本节「起服序」一条);停驻关着 ⇒ 读面报 `ephemeral`、起服 warn 一行,不拒。
+    记忆根为什么不进拒启判据:拒启守的是引擎被告知「活过重启」的那两半店(会话与停驻审批 —— 丢了就有一笔已承诺的停驻悬空);记忆丢了是召回变差,不让任何承诺悬空。把它算进拒启 ⇒ 每一个只给数据根挂卷的部署(常见的单卷 Pod 形)升级即拒启,补偿只有再挂一只卷。
+    **订正**:7.148.0 节第 34 条「『运维显式声明 local 店易失』的部署形随后版」即本条;第 34 条本体不改。
+    **已知边界**:会话里给用户看的一行通告(「会话历史不随容器替换保留」)本版没有 —— 它要一枚新的通告码进引擎码册;本版只在读面与起服日志上说。没有起服取证的入口(`run-local`、嵌入方直调 `createStoreBackend`)按介质 `unknown` 读,只有写了词才降声明。
+
+26. **多副本同时起一只 TiDB 库:启动锁的非阻塞探针撞「悲观锁重试上限」读成「别人持着」,不再被当成坏连接(行为修复;运维可见;wire 零变化;零 DDL;部署零动作)**:
+    旧形:SQL 部署(MySQL 协议腿 = TiDB)上 N 个副本同时起,`ensureSchema` 与一次性迁移段取同一把具名锁 `sema_ensure_schema` 的非阻塞探针(`GET_LOCK(name, 0)`)本身会抛 `pessimistic lock retry limit reached`(TiDB 把 `GET_LOCK` 做成内部行的悲观锁,并发探针撞行的重试上限);取锁器把它算进「连续 5 次探针抛错 ⇒ 连接不可用 ⇒ 上抛」,同起的副本约一半以上起服失败(拒句 `lock probe threw 5 times in a row … (last: pessimistic lock retry limit reached)`)。
+    新形:这一句(整句相等)被读成「别人持着」,与 `got = 0` 同一条律:持锁方还在就一直等(按进展每 40 拍 warn 一行)、永不无锁跑,不计入连续 5 次上限、不另设一道钟。放弃的上界仍只有调用方外圈的窗:`ensureSchema` 在 `STORE_LOCK_WAIT_MS` 大于 0 时由外圈窗兜(窗内换池重试、到窗拒启);迁移段与 `STORE_LOCK_WAIT_MS=0` 的 `ensureSchema` 没有外圈,持锁方不放时等不到头(对「别人持着」本来如此,现在对撞上限同形)。其余任何探针错照旧计入连续 5 次上限。PG 腿读法不变。
+    **谁需要**:多副本(≥ 2)同时起、共用一只 TiDB 库的部署(一次性拉起 N 副本、扩容、滚动重启)。**谁受伤**:正常部署无;失去的是一种快速失败 —— 迁移段与 `STORE_LOCK_WAIT_MS=0` 的 `ensureSchema` 上,持锁方卡死(而不是慢)时,等待方此前在连续 5 次撞上限后失败退出,现在一直等并按进展 warn(与持锁方卡死而探针答干净 `0` 时的既有形一致);撞上限的探针不再各写一行 `probe attempt N threw`,等待期改由每 40 拍一行的 `still waiting for GET_LOCK(...)` 说明。要期限的部署用编排器的启动探针兜(`ensureSchema` 一段另可设 `STORE_LOCK_WAIT_MS` 大于 0)。
+    **出路**:不需要动作。仍在旧版本上的部署,多副本冷启建议首副本 ready 之后再起其余(升级序:先升库再升副本不变)。部署零动作。**回滚**:不适用(无存储形变化)。
+
+27. **按问读口 `GET /v1/tool-approvals/:id`:行读不出时本副本上的活卡也答 `404 not_found.ask`(与 7.148.0 节第 29 条同句同码),不再回落登记答 `200 pending`(安全轴,fail-closed;行为收紧;wire 零新键、零新码;部署零动作)**:
+    旧形:有行的问,读口读行那一拍出错(店抛 / 超时)时,本副本自己铸的活卡按登记上记下的属主作答 —— 认调用方 ⇒ `200` `state:"pending"`,否则 `404`(7.136.0 起;7.133.0–7.135.x 的读口对活卡不读行,恒按登记作答)。起服接管的登记一直答 `404`。
+    新形:行读不出 ⇒ 看不见 ⇒ `404 not_found.ask`,与查无 / 不是你的逐字节同,活卡与接管登记同答 —— 7.148.0 节第 29 条「看不见这只问(查无 / 不是你的 / 行读不出 / 本 worker 没有问账)」本来就是这一句,本版起实现与它一致。
+    `POST /v1/tool-approvals/:id/respond` 零变化(属主门那一读读不出 ⇒ 同一句 `404`;决议写失败之后读不回行 ⇒ `500`,第 40 条)。没有行的问(问账没上场 / 旧族腿)照旧按登记作答。
+    **谁受伤**:把店抖动期读口的 `200 pending` 当「问还在」的调用方 —— 现在收 `404 not_found.ask`,按第 29 条的出路会消卡。
+    **出路**:店恢复后重读即回 `pending`(行与在等的 run 都没被动);同一抖动期 `GET /v1/approvals` 的 `livePending` 与 `/v1/approvals/stream` 的 `live_pending` 与读口同隐、恢复同回(见本节「活卡的列表面」那一条)。一直 `404` ⇒ 报运维查库。**升级前做**:无。**回滚**:回到上一版即回到旧形(零数据面)。
+
+28. **缺列拒启的两只判官收成一只出口:单表探针(检查点 · 工具结果 · 文件历史 · 审批问账 · 规则审批记录 · 规则兑付票)的缺列拒启也带 `config.schema_mismatch`(`code` 字段 + 消息首词),与整库列册对账同一只类;订正 7.148.0 节第 84 条「检查点列册探针拒启 `config.schema_mismatch`」在 7.148.0 上不成立、自本版起成立(行为修复;拒句首词加码、其余逐字不变;运维日志面:起服 fatal 行的标题随类名变;部署零动作)**:
+    旧形:存量库缺列时起服先撞见的是单表探针(检查点 · 工具结果 · 文件历史 · 规则审批记录 · 规则兑付票五个先于一次性迁移;审批问账那一个在第 6 段装配协调器之后才跑),它抛不带机读码的裸 `Error`,拒句形如 `checkpoint is missing the column host_session_id — refusing to start. …`;只有整库列册对账(靠后)的拒句首词是 `config.schema_mismatch:`。
+    7.148.0 节第 84 条把检查点探针的拒启写成 `config.schema_mismatch`,在 7.148.0 及更早的构建上这一句对检查点探针不成立(码只出现在整库对账的拒句里)。
+    **勘误(第 84 条括注)**:自本版起成立 —— 缺 `checkpoint.host_session_id` 的库起服拒启 `config.schema_mismatch`,拒句点名 `checkpoint` 与缺的列、逐列打印生成的 `ALTER`、给闭集三条出路(第 84 条的升级动作与回填 M49 不变)。
+    新形:缺列拒启只有一只出口(`SchemaMismatchRefusedError`,`StoreBootRefusalError` 族,`code` = `config.schema_mismatch`,消息码领头):整库对账的三条拒与六个单表探针判点(`checkpoint` 后加列册 · `tool_result` 出处两列与 `ref` 键宽 · `file_history_*` · `approval_ask` · `permission_rule_approval` · `permission_rule_ticket`)都经它抛。
+    谁先判、各判官管哪些列、非缺列故障(连接 / 超时 / 权限 / 表不在)原样透出、拒句正文与闭集三条出路:逐字不变;不新增 DDL、不改任何表。包根导出不变(这只类在包内)。
+    **谁需要**:升级漏了一句 `ALTER` 的运维,以及按码 `config.schema_mismatch` 告警 / 脚本分派的部署。**谁受伤**:按第一个词或 `Error:` 标题逐字匹配探针拒句的脚本 —— 现在首词是 `config.schema_mismatch:`,fatal 行标题是 `SchemaMismatchRefusedError [config.schema_mismatch]: …`(与既有带码拒启同形)。**补偿**:不需要,按码匹配的读者不用改。
+    **升级前做**:无。**回滚**:零 DDL、零数据面;回到上一版,探针的拒句回到不带码的形,其余不变。
+
+29. **收编弧锁并入启动锁的同一只取锁器:多副本同拍收编同一个源主体时,TiDB 的「悲观锁重试上限」读成「别的副本正持着」,不再让收编请求上抛(行为修复;运维可见;wire 零变化;零 DDL;部署零动作)**:
+    旧形:收编弧锁自带一只 `GET_LOCK(name, 0)` 探针(20 次 × 100 ms 的有界轮询);TiDB 上多个副本同拍探同一把锁时探针语句本身会抛 `pessimistic lock retry limit reached`,这只探针第一次抛就上抛 —— `POST /v1/adoption` 答 500,起服扫描把该弧记进 `failed`。
+    新形:弧锁与启动锁(`ensureSchema` / 一次性迁移段)走同一只取锁器(同一套锁语句、同一个答案读法、同一条「撞上限 ≡ 别人持着」的律):撞上限继续轮询,用尽 20 次仍被持着 ⇒ 回「在飞」(与此前同);其余探针错连续 5 次才上抛(此前第一次就上抛);用尽 20 次时最近一次探针若是抛的也上抛(不读成「在飞」)。锁名限定、PG 键空间、`withLock` 签名与「在飞」窗的量级都不变(最后一次探针之后不再多睡一个间隔,约早 100 ms)。
+    **谁需要**:多副本同拍收编同一个源主体的 TiDB 部署。**谁受伤**:无(弧锁探针偶发一次坏答不再立刻失败,最坏多探几拍;预算最后一拍的坏答除外,照样上抛)。**出路**:不需要动作。**升级前做**:无。**回滚**:回到上一版即回到旧形(零数据面;锁不落库,随连接消失)。
+
+30. **起服拒句一次列全:缺列拒、单表探针拒、一次性迁移的判活拒都带同一张升级清单 —— 全库欠的 `ALTER`(逐表)+ 本构建的停-迁-起迁移 + 顺序(拒句措辞;码、判据、拒启面、出路集合零变化;wire 零新键、零新码;部署零动作)**:
+    旧形:一台升级时漏了 DDL 的库,起服路上有三族拒各报各的一段 —— 单表探针(`checkpoint` 等六张表)只列它点名的那一张表的缺列;一次性迁移的判活守卫(M40 · M41 · M42 · M51)只说「停光旧副本再起」;整库列册对账(其余全部缺列)排在迁移段之后。
+    运维按拒句补一句再起,撞上下一族 —— 7.148.0 的升级路径上曾要起四次才读全十句 `ALTER`(缺列拒 → 补列 → 判活拒 → 其余九句)。
+    新形:三族的拒句尾是**同一张清单**(正文只有一份):`Upgrade checklist` 三步 ① 全库欠的 `ALTER` 一次执行(逐表段与语句行由本构建的建表语句生成,两方言各自的那一份)② 本构建带的停-迁-起迁移
+    (登记表里每一条带 `stopThenStart` 的行,一行一句缘由;已走过它们的库不被再问)与那一句动作(停光旧副本、等满 `REAP_RUN_STALE_SEC`、再起)③ 起服。第 ② 步按登记表列、不判这只库欠不欠,动作句的「不可滚动」照出:对已走过这几条迁移的库(如 7.148.x → 本版,见本节段头)它是多余的保守句。单表探针的拒因列的是**整库**的缺列(以前只列探针点名的表);
+    判活守卫的拒句在库还欠列时句尾接同一段(列齐时句子一字不多)。清单只在有语句要执行时出现:库里只有多出的列(库比构建新)时没有语句可给,出路仍是持有那些列的构建;一次性迁移段之前读列册时,待跑迁移自己要删的旧列与自己要建的列(改名 / 加列 / 换表的目标列)不进清单(部署者照句子先加了,迁移的改名反而撞上已存在的目标列)—— 按迁移自己的条件读(与起服列册对账同一只投影,见本段「起服序」一条:改名的源列不在 ⇒ 迁移不会替它建 ⇒ 目标列照列);句尾读列册有期限,读不回来就如实说没读到,拒照出。
+    与本节「缺列拒启的两只判官收成一只出口」一条叠加:那一条只给探针拒句加码(其余逐字不变指它自己的改动);探针拒因的逐表段本条改为整库口径、并加清单,以本条为准。
+    四只守卫的「停光旧副本 → 等满判活窗 → 再起」一段并成一份(M42 的这一句措辞随之与另三条齐一;其余各自的缘由句不变)。
+    不变:码(`config.schema_mismatch` / `config.scenario_prefix_switch_refused` / `config.session_deleting_switch_refused` / `config.execution_lane_rename_refused` / `config.session_ext_move_refused`)、哪些情形拒、一字节不写的保证、
+    闭集三条出路(仍在句尾,逐字不变);起服各步的先后不在本条(本段「起服序」一条把列册对账排到了一次性迁移段之前:漏 DDL 的库第一次起服先撞对账的拒句,清单在那里列全;起服里判活守卫在对账之后,句尾只在库形与迁移登记的声明对不上时才非空;不经起服对账的嵌入方公开序列上守卫可能是第一只拒,句尾照列全)。没有进清单的拒:跳版库的退役 schema 拒、`Skill` 豁免截点拒、M32 的放置切换前提拒(它们的出路各自成句);M42 的 `stored_prefix` 拒仍点名行数,句尾同样接清单。
+    **谁需要**:升级运维 —— 一次读清本版对这只库要做的全部动作,不靠试探起服。**谁受伤**:按拒句全文做字面匹配的脚本(拒句措辞变了;按码判别的不受影响)。**补偿**:按码判别;全文匹配的改读清单标题 `Upgrade checklist`。
+    **升级前做**:无。**回滚**:回到 7.148.x 即回到旧拒句;无存储形变化。
+
+31. **勘误 7.148.0 节第 3 条:「相接 / 重叠的凭据合成一枚记号」只在本服务出口座投影的面成立;终局 `error` 文本与审批卡 `riskDescriptor.summary` 由引擎打码器逐段遮,相接 / 重叠形可留多枚记号与尾段(文字订正;零行为变化;wire 零变化;部署零动作)**:
+    已发节(7.148.0)不改字节,本条即订正。
+    订正对象:7.148.0 节第 3 条的标题与「新形」说每张面一枚段首记号,并把「run 的 `error`」「审批卡」列在合成的面里。实现里的合并律(相交或相接 ⇒ 一段一枚;本服务的脱敏器与出口座)只作用于本服务自己铸的 `«redacted:…»` 这一只记号族,
+    所以成立的面是**本服务出口座投影出来的**那些:结果面(`result`)、账本行、事件重放、活流、审批卡的 `input`。
+    不在其内的两处:**终局 `error` 文本**与**审批卡的 `riskDescriptor.summary`** 的字节,在到达本服务的出口座之前就由引擎的打码器逐段遮过(引擎自己的记号族:`[redacted]` / `[redacted-credentials]` / `[redacted-url]` / `[redacted-path]`);
+    本服务不重写引擎已经打下的记号,所以这两处相接 / 重叠的两枚凭据可以留下多枚记号(例:终局 `error` 面上相接的两枚凭据读作 `[redacted][redacted]`),卡 `summary` 上可以看到两种记号串在一起,也可能留下尾段 —— 与 7.148.0 节第 3 条的「新形」不符。
+    修法在引擎:引擎的打码器按相接 / 重叠合并之后,随提货到本服务,届时本服务再补一条 MIGRATION 更新这两处;在那之前这两处按旧形读。遮住的字节、`redactions_applied_total` 与其余各面(上面列的成立面)不受影响。
+    **谁需要**:按 7.148.0 节第 3 条的字面去断言「每张面恰一枚记号」的消费方与测试。**谁受伤**:在终局 `error` 或卡 `summary` 上按「一枚」解析或断言的消费方(这两处本来就没有合成)。
+    **出路**:把每一处记号(`«…»` 与 `[redacted…]`)当「这里遮了一段」读,不读个数、标签组合与相邻关系(契约原有规定:记号个数不是身份位)。**升级前做**:无。**回滚**:无存储形变化。
+
+32. **活卡的列表面与按问读口同一只店事实读法:`GET /v1/approvals` 的 `livePending[]` 与 `/v1/approvals/stream` 的 `live_pending` / `live_resolved` 列出的每一张卡,按问读口对同一调用方都答 `pending` —— 行读不出 / 行已离开待决的不再列,属主取行上当下的那一位(安全轴,fail-closed;行为收紧;wire 零新键、零新码;嵌入方类型面一处;部署零动作)**:
+    旧形:列表面与推流只遍历本副本的进程内登记,按登记上记下的属主列、不读行。于是店抖动期(按问读口答 `404 not_found.ask`,本节「按问读口」那一条)列表照列这张卡 —— 按第 29 条的出路消卡的壳,下一次列表又会看到它回来;行被别处答掉 / 收走而本副本的登记还没闻讯时照列「待决」,直到这条登记自己结算(悬挂轮询或窗到期);收编在别的副本落定、本副本还没读到行时按前属主列。
+    新形:对每只有行的候选(本副本此刻的登记,一只问一行)点读它的行,与读口、应答口同一只读行入口(读不出 ⇒ 看不见):行读不出 ⇒ 不列;行已离开待决 ⇒ 不列;行上当下的属主不在 scope 内 ⇒ 不列(scope 读法不变)。没有行的问(问账没上场 / 旧族腿)登记记下的属主是唯一可读的属主事实,照登记列。推流是同一只读函数:问账读不出这张卡的行而 checkpoint 队列这一拍读得出时,这张卡一帧 `live_resolved`,恢复后一帧 `live_pending`(队列读本身失败的拍只发错误帧、live 半场保持上一拍)。读行并发发起,一次列表至多等一个读期限(2 s),响应里的 `serverNowMs` 取在等完之后。列表的 scope 比读口窄(具名主体的列表不含无主的卡;运维列表含读口不放行的卡),本条不动:「列出的 ⇒ 读口答 `pending`」成立,反过来不成立。
+    **嵌入方类型面**:`ServiceDeps.toolApproval` 的 `listLivePending` 由同步返回改为返回 `Promise<LivePendingRow[]>`(包根不导出协调器类;自建 `toolApproval` 的嵌入方 tsc 红即通知,零别名)。
+    **谁需要**:读列表再逐卡读(或按卡应答)的壳 —— 抖动期不再「列表有、点开 404」,消卡后不再被列表带回。**谁受伤**:① 把 `livePending` 空数组读成「没有待批」的调用方 —— 空数组不区分「没有」与「此刻读不出」,没有机读位(唯一的运维信号是同一实例第一次读失败时的一行 warn `approval-ask store call failed` 与失败计数);② 按「列表是进程内投影、零 DB 成本」估算店读负载的运维 —— 现在每次列表 / 每个推流拍,本副本上每个有行的不同 ask 各多一次按 id 点读(重复登记共用一次,没有行的问不读;不按调用方 scope 先筛;上界是每个任务 / 每个属主各一个未决帽〔`STREAM_APPROVAL_ADMIT_MAX_PER_TASK` 默认 32、`STREAM_APPROVAL_ADMIT_MAX_PER_OWNER` 默认 256〕加起服接管至多 1000 张,总数没有全局帽;多租户单副本上登记数大时放大随之变大)。
+    **出路**:店恢复后下一次列表 / 下一拍推流即回(推流按「任一非 heartbeat 事件 ⇒ 重取权威 `list()`」姿势接则无需改动);读负载收小就收小那两个未决帽。多副本下候选集仍是本副本的登记(会话粘性要求不变)。**升级前做**:无。**回滚**:回到上一版即回到旧形(零数据面)。
+
+33. **自选会话 id 的创建面成文,且「被占着」只剩一种读法:别的主体的会话在删时,同步推送三口与对活行同答 404;推送族「别人 404 / 不存在新建」的两答与提交挂接、键控 fork 同形,先占者得,反枚举只靠 id 的熵(安全收紧;行为变更;wire:推送三口一面状态改答 404〔登记〕,零新键、零新码;部署零动作)**:
+    旧形:同步推送三口(plan / 导入第一阶段 / blob 上传)的门把「在删的行」(删除围栏已立、尚未删净)读作不在,提交挂接的认领面把它读作仍占着这个 id —— 同一件事两种读法。别的主体的会话在删时,别的主体对它 plan 得 `200 {"relation":"fresh"}`(local 后端)/ 第一阶段 200 带 `stagingId` / blob 上传 204;SQL 后端的导出不看在删态,plan 还答 `200` 带 `stale` / `fork` 关系体(随来源条目与残留条目的包含关系),内含该会话残留的条目 id,第一阶段 `409` 带同一关系体。(既有,非回归。)
+    新形:「这个 id 被占着吗」只有一种读法(活行 ∪ 在删行,三张面同读):别的主体对在删的会话与对活行同答 `404 not_found.session`(体与拉取口对不存在 id 的答复逐字节同);本人 / fleet 对自己在删的会话不变;拉取口仍只认活行。同时把三张让调用方**自选**会话 id 的创建面 —— 会话同步推送、提交挂接(带 `sessionId`)、键控 fork(`forkId`)—— 的同一条律成文:空闲的 id 就地建(落在调用方名下),别的主体占着的 id 答这一面自己的「没有这一行」(推送族 `404 not_found.session`、提交挂接 `404 resume.session_not_found`、键控 fork `404 not_found.session`),先占者得。三张面不保证「别人的 ≡ 不存在」:`session_id` 是全局主键、自选、空闲即建,「这个 id 被占了」对创建者固有可观察,反枚举只靠 id 的熵;server 的 id 门是形门(canonical uuid、任意版本),不是熵门,低熵的 canonical uuid 可被枚举。契约新增「自选会话 id 的创建面」一节。
+    **谁需要**:有身份边界的多主体部署上自选会话 id 的消费方,以及任何有会话正在被删的多主体部署。**谁受伤**:在删窗口里靠推送三口的「新建」答复去探别人会话状态的调用方(靠缺陷,现答 404;本人 / fleet 不受影响);用可预测 id(序号、名字的确定性 uuid、时间戳 uuid)的消费方 —— 别的主体能探出占用并抢先占掉。**出路**:自选 id 用随机 uuid(v4 / v7);要零信号就不自选 id(提交不带 `sessionId`、fork 不带 `forkId`、收编批量导入的云端 id 是 `(adoptionId, clientSessionId)` 的纯函数);会话镜像推送的零信号形得把 id 空间按主体分区(服务端派生 id,或 id 自带主体前缀、查表前先验前缀),是另立设计、本版不承诺。**升级前做**:无(已在用可预测 id 的消费方自行换成随机 uuid)。**回滚**:回到上一版即回到旧读法(零数据面)。
+
+34. **会话同步推送的导入租约按「落点属主格」分键:空闲 id 上各占各的(先提交者得),既有会话上共一把 —— 一个主体的在飞第一阶段不再挡住、也不再透给另一个主体;第一阶段 blob 在场预检核实为真、本版不收(安全收紧;行为变更;wire:导入第一阶段一面 409 改答 200〔登记〕,零新键、零新码;部署零动作)**:
+    旧形:导入第一阶段占的实例级租约键只是会话 id。空闲 id(还没有会话行)上任一主体的在飞第一阶段,让别的主体对同一 id 的第一阶段答 `409 import_in_flight`(带 `retryAfterSec`)—— 既把首推挡到租约陈旧(缺省 600 s),也让「此 id 此刻有人在导」成为可观察位。别人的既有会话上没有这件事(属主门在租约之前,先答 `404 not_found.session`)。(既有,非回归。)
+    新形:租约键 = 落点属主格 + 会话 id。会话行在 ⇒ 行的属主格,属主 / fleet / 存量无主互认共一把(同一份会话上第二份在飞导入,谁发起的都 `409 import_in_flight`);空闲 id ⇒ 这位调用方自己,各占各的,先提交者得,输的那一份在提交前复判答 `404 not_found.session`(与赢家的提交撞在同一刻时由店的属主 CAS 拒、答 `409 conflict`);删除中的会话上属主与 fleet 同样共一把。同一主体自己的两份在飞照旧互斥;只有走到开暂存臂的第一阶段碰租约(`identical` 不碰)。陈旧判成了一条读法:任何第一阶段路过都把闲置 ≥ `SYNC_IMPORT_LEASE_STALE_SEC` 的租约连同暂存登记清掉(`0` = 关,行为不变)。第一阶段的 blob 在场预检读的是全局内容地址表(别的主体传过的 blob 对你也算在场),重放取值口读同一张表 —— 不上传、只在信封里写 hash 的主体可在提交后读到别人传的字节;要让它只认本会话可见的 blob 需要 blob 来历这个持久事实,另裁,契约「自选会话 id 的创建面」一节如实写明(既有,非回归)。
+    **谁需要**:有身份边界的多主体部署上经会话同步推送的主体(镜像推送首推一个新 id 的客户端)。**谁受伤**:靠「同一空闲 id 上第二份 409」当互斥的不同主体 —— 现在各自受理,先提交者得;对 blob 内容有机密要求的多主体部署(blob 面见上,本版未收)。**出路**:自选 id 用随机 uuid(见上一条);同一主体重试遇 409 照 `retryAfterSec`;blob 面本版没有部署侧旋钮(文件历史半族由后端形态定:`capabilities.sessionSyncFileHistory`),在它另裁收口之前,多主体部署上互不信任的主体之间,文件历史内容并不互相保密(知道 hash 即可取)。**升级前做**:无。**回滚**:回到上一版即回到旧读法(租约是进程内存,零数据面)。
+
+35. **目录条目的名字就是一枚凭据形(`sk-…` / `ghp_…` / `AKIA…` / `xoxb-…` 一类,引擎的脱敏器对孤立标识符的读法认得出)⇒ 这条条目不可用:`config.model_entry_invalid`、坏字段 `name`,不进目录、不进 `GET /v1/models`(安全轴;行为收紧;wire 零新键、零新码;目录里没有这种名的部署零动作)**:
+    旧形:条目名是 `@name` 选择把手,`GET /v1/models` 的 `models[].name` 原样回给任何调用方;同一个名字在启动日志里被日志出口接缝遮掉。把密钥误写进模型名的部署,密钥随目录读面对每个调用方公开,日志里却看不到 —— 同一个值两种读法。
+    新形:模型面逐条判据在形判里多问一句 —— 名字是凭据形 ⇒ 这条条目不可用(码 `config.model_entry_invalid`,坏字段 `name`;拒因句点名字段与出路、不带名字的任何字节),与不合 `ModelEntry` 形的条目同律:不进目录、不进 `GET /v1/models`、不当缺省,`@name` 点它拿 400 `request.model_unavailable`,每条一句 warn `web_admin_model_entry_invalid`(`field: "name"`、`modelNameWithheld: true`,名字不进日志字段)。中心下发、`config.d/models.json`、盘上 last-known-good、`run-local` 同走这一只判据,起服与热发布同判。它是目录里仅有的启用条目 ⇒ 这份候选没有缺省模型,模型面整组被拒(`config.default_model_missing`):起服时 env 也没有 `MODEL_ID` 则拒启、有则 env 表继续服务,热发布则上一代继续服务。
+    「凭据形」的读法:名字**就是**一枚凭据 —— 脱敏器对孤立标识符的读法(不是自由文本的读法:词法关键字臂出局,`tokenizer-model-2026-11-08` / `token-introspection-endpoint` 这类标识符不是凭据形),只认强证据,凭据形在串首。典型形:`sk-` / `sk-proj-` / `sk-ant-` + 长体(值 ≥ 20 位且含 ≥ 2 个大写或数字)、`ghp_` / `github_pat_`、全大写的 `AKIA…` / `ASIA…` + ≥ 16 位大写字母数字(AWS 访问钥 ID 的形)、`xoxb-…`、`npm_`、`glpat-`、`ya29.`、`sk_live_`、`hf_` + 够长的体;脱敏器自己的裸形启发式认不出的(`sk-` + 规范 UUID、`sk-proj-` + 全小写长体)不拒。名字里嵌着这些前缀、前面还有别的字的(`mask-rcnn-…`、`prod_<钥>`)不拒。现实模型名(厂商 id、端点 id、日期戳、十六进制串、点分前缀)逐个对照不被误判。
+    同批收同类缺口:`/health.modelRefusals` 与 fleet 心跳的键、拒因 warn 的 `model` 字段、拒因句里的名字位,此前只问契约包的名筛,它读不出 `npm_` / `glpat-` / `ya29.` / `sk_live_` / `hf_` 五族 —— 因别的原因被拒(如无 anthropic 凭据的 `provider:"anthropic"` 条目)又叫这类名的条目,名字会出现在 `/health.modelRefusals` 的键里;现在这三个出口同问一个口(契约包名筛 ∧ 脱敏器),凭据形的名只写码、不上 wire。`request.model_unavailable` 的拒句在调用方只发了上游 id 时带的别名段 `(catalog entry "<名>")` 是配置里的名字,不可披露的名改写成 `(catalog entry (name withheld))`;续跑腿留声 `task_model_unavailable_fallback` 的 `name` 字段同走名字出口(不可披露的名换成 `nameNameWithheld: true`)。
+    **谁需要**:把密钥误写进模型名的部署(目录名字位当成密钥槽用 / 复制粘贴错位)—— 起服 / 发布时就被拒,而不是静默公开。**谁受伤**:目录里有凭据形名字的条目(此前照常服务并公开名字,现在不可用;`sk-Mistral-7B-Instruct-v0.3` 一类以 `sk-` 起头的长名也在内 —— 它就是那种钥的形);读 `/health.modelRefusals` 的消费方 —— 叫这五族名的被拒条目此前在键里、现在不在(不可披露的名既不进键也不计数,与此前其它不可披露的名同律);按「拒句里别名段是条目名」解析 `request.model_unavailable` 的调用方(仅凭据形名的那一条变成 `(name withheld)`)。**未覆盖(如实)**:`MODEL_ID` / `MODEL_CHEAP_ID` 铸的 env 表与条目的上游 `id` 字段不经这一判据(凭据形的 `MODEL_ID` 仍会原样出现在 `GET /v1/models`);被读腿丢掉的条目的 `droppedEntries[].identity` 仍按契约包名筛判;凭据形前面粘着别的字的名字不拒。
+    **出路**:给条目改名(纯标识符:字母 / 数字 / `.` `_` `-`);名字若是从一枚真凭据贴来的,那枚凭据按已泄露处理 —— 它写进过配置文档(与可能的版本库)。**升级前做**:`config.d/models.json` 与中心目录里的条目名过一遍,任何凭据形的名先改名再升级,否则升级后那条条目不可用;若它是目录里唯一的启用条目且 env 没有 `MODEL_ID`,升级后起服拒启。**回滚**:回到上一版即回到旧形(零数据面)。
+
+36. **勘误 7.148.0 节第 49 条:能力位 `sessionReadRedaction` 由布尔改叶名表不是「部署零动作」—— 升级本服务之前,先确认接入它的壳已能按数组形读这一位;旧壳会把 `--resume` 读成未脱敏,会话静默变成一只空白的新会话(文字订正;零行为变化;wire 零变化;部署有前置动作)**:
+    已发节(7.148.0)不改字节,本条即订正。
+    订正对象:第 49 条标题写「部署零动作」。本位的值由 `true` 改成叶名表 `string[]` 之后,按旧读法判本位的壳(`!== true` ⇒ 当作「历史读面没有过脱敏」)
+    会把 `--resume` 读成未脱敏、不续这只会话 —— 用户那一侧看到的是会话静默变成一只空白的新会话,没有报错。
+    改为前置动作:先确认接入的壳已能按数组形读本位(cli ≥ 1.0.164;client-core 的对位版本),再升本服务。
+    **谁需要**:运维(升级顺序)。**谁受伤**:壳还是旧版就先升了本服务的部署 —— 续跑静默落成新会话。**出路**:先升壳、再升本服务。
+    **升级前做**:上面那一条确认。**回滚**:无存储形变化。
+
+37. **进程内「本会话放行」绑会话的这一位住客:会话删了(删除路由 / 留存清理 / 别的副本)再用同一个 id 重登记之后,上一位住客点的放行不再落到下一位身上;读不出住客令牌的腿不记(安全收紧;行为变更;既有缺陷;wire 零新键、零新码;嵌入方类型面三处;部署零动作)**:
+    旧形:活卡上对引擎的问点的「本会话放行」(`allow_session`)记在协调器的进程内表里,键 = (属主,会话 id,能力桶,绑定摘要)。会话 id 由调用方自选,删会话(`DELETE /v1/sessions/:id`)与留存直删清不到这张表(只清耐久豁免店),所以同属主在本进程用同一个 id 重登记之后,新一位住客的第一次调用被上一位点的放行代答、免问。别的副本删了再登记同形。
+    新形:键加会话行上的住客令牌(化身):装配点把执行上下文那一读的住客交给审批席的身份,读写两点取同一格(取出处腿的住客,不取应答那一刻会话行上的)。会话删了再用同一个 id 登记 ⇒ 令牌换了 ⇒ 上一位的放行读不中,新一位的第一次调用出卡;同一位住客内「本会话放行」照旧生效。删除路径不新增任何清表动作(上一位的表项留到容量帽逐出或进程重启;新一位住客的腿算不出它的键,仍在跑的上一位住客的旧腿读自己名下的,不跨住客)。读不出住客令牌的腿(会话店不带执行席 —— 引擎缺省的内存会话店;SQL 两方言与 local 后端恒带)不读也不铸:点 `allow_session` 只放行这一次、回执 `rememberApplied:false`,日志一行 warn `session_grant_refused_occupant_unreadable`。
+    **嵌入方类型面**:`ToolApprovalRunContext`、`boundAsk` / `boundUnattendedAsk` 的身份、`approverSeatFor` 的身份各多可选键 `incarnation`;包根导出的 `runInBackground` 的 `approval` 参数里原来的 `executionLane` 键并进 `origin: { executionLane, incarnation? }`(自建调用的嵌入方 tsc 红即通知,零别名)。
+    **谁需要**:用「本会话放行」又会删会话 / 被留存清理清掉会话的运维与用户(含反复用固定会话 id 的脚本)。**谁受伤**:靠上一位住客的放行给下一位免问的调用方(靠缺陷);用引擎缺省内存会话店的嵌入方 —— 其腿读不出住客,「本会话放行」不再被记住(每次照问)。**出路**:要跨删除保留免问不是这张表的职责(耐久面的 `remember:"session"` 随会话树删除一起清,同样不跨住客);嵌入方要「本会话放行」生效就给会话店带执行席(`sessionStorage.executionPlacement`)。**升级前做**:无。**回滚**:回到上一版即回到旧形(零数据面;进程内表随进程重启清空)。
+
+38. **起服序:每一只拒启判都先于第一笔一次性迁移写与封签钥匙的铸造;显式写了 `SEALED_KEY_DIR` 的钥匙目录在停驻审批耐久时进拒启判据(行为修复;拒启码不变;wire 零新键;部署零动作 —— 只有 `SEALED_KEY_DIR` 指在易失介质上、停驻审批耐久的部署起服被拒)**:
+    旧形:SQL 起服的列册对账(缺列 / 多列 / 可空列 ⇒ `config.schema_mismatch`)、记忆向量指纹门、SQL 引擎姿态(隔离级 / 事务模式复核)、device 审计探针、`REQUIRE_PRINCIPAL=true` × `DB_BACKEND=local` 与云形快照 blob 姿势两道配置判排在一次性迁移段之后:
+    漏跑了升级前 DDL 的库被拒之前,迁移已改写存量(搬格、删列、清行),起服日志打过一行 `one_time_migrations_applied`;运维补完 DDL 再起,迁移读数是零,看上去像什么都没改,而数据已改。
+    配置根与数据根合一(本地配置源)时,配置根上的一次性迁移 SS-M11 的运行记录与决定、配置根供给建出的 `SEMA_CONFIG_DIR` 先于店的持久性准入落盘。
+    `SEALED_KEY_DIR` 指在 tmpfs / 容器可写层上而停驻审批耐久(SQL 检查点店,或声明耐久的 local 店):起服、停驻;下一次替换之后停驻行还在、封它请求凭据的钥匙没了,之前停驻的每一条续跑都答 `key_not_held`。
+    新形:一条律 —— 拒启判排成一段,全部早于第一笔一次性迁移写与钥匙铸造。
+    ① SQL:列册对账排在一次性迁移段之前,比的是「本构建带着的、待跑的迁移跑完之后」的形 —— 迁移要删 / 改名 / 补 / 重建的列不让起服拒(没改过库的正常升级照起),别的缺列 / 多列 / 可空列照拒
+    (改名之后的可空性按方言读:MySQL 协议的改名句带本构建的列定义,PG 的 `RENAME COLUMN` 保留旧列的可空性;重建的旧表缺搬运要读的列 ⇒ 迁移之前拒),
+    拒的时候存量一笔没改、没有迁移读数行;补上拒句给的 DDL 再起,迁移在起得来的那一次跑、读数行如实。发车门 1.10 第三档读同一只投影,读数不变(`migration-pending` / `mismatch`);单表探针的拒因与判活守卫的句尾(本段「起服拒句一次列全」一条的升级清单)读同一只投影。
+    迁移跑完之后同一只对账再跑一次(待跑集为空):只在本构建某条迁移的表形声明与它真落下的形不符时拒 —— 构建缺陷,不是部署状态;部署状态的不符都在迁移之前、零写拒过。
+    ② 配置根:店的持久性准入排在配置根供给、配置根上的一次性迁移 SS-M11、保管店铸钥匙之前 —— 配置根与数据根合一而介质易失、被拒的那一次起服,那只根上没有本服务写下的任何东西。
+    准入之前唯一可能的写是 `config.d` 的一次性迁移(目录里还有 settings-schema 11 之前写法的文档时它改写这些文档:执行车道读的 `remote-exec.json` 是其中一份,准入判的是读它合成出的车道)。
+    `run-local` 同序(它没有店的持久性准入;配置根上的 SS-M11 挪到车道合成之后)。
+    ③ 封签钥匙目录:`SEALED_KEY_DIR` 写了 ∧ `DURABLE_APPROVAL` 在 ∧ 检查点店耐久(SQL 后端恒是;local 随店的声明)∧ 目录介质判 `ephemeral` ⇒ 起服拒 `config.store_not_durable`;数据根那一臂同时不过 ⇒ 一句拒、逐条列出。
+    缺省的钥匙目录(`<数据根>/sealed-key`)不进判据:local 后端由数据根那一臂判;SQL 后端无卷的无状态副本是常形,没写 `SEALED_KEY_DIR` 的部署没有对钥匙目录作过承诺 —— 只进读数(`store.durability`)与起服 warn。
+    判不出的介质(`unknown`)不拒。读面(`/health.store.durability`、caps `store.durability`、`GET /v1/diagnostics/wiring` 的逐根明细)不变。
+    **谁需要**:漏跑升级前 DDL 的 SQL 部署;配置根与数据根合一的本地部署;写了 `SEALED_KEY_DIR`、停驻审批耐久的部署(钥匙目录不活过替换就不起服,不再静默丢停驻)。
+    **谁受伤**:`SEALED_KEY_DIR` 指在易失介质上、停驻审批耐久的部署 —— 上一版起服(停驻的任务在下一次替换之后续不了),本版拒启。
+    `REQUIRE_PRINCIPAL=true` × `DB_BACKEND=local` 的拒挪到开店之前、按声明的后端词判(local 店的 `ensureSchema()` 自带几条 local 一次性迁移):没写 `DB_BACKEND`、缺省推导的 local 数据根空而开不了、
+    上一版静默降级成内存起服的多租户部署,本版拒(出路:SQL 后端;要照旧跑内存就显式写 `DB_BACKEND=memory`)。其余只改顺序,无人受伤。
+    **补偿 / 出路**:拒句逐条给出路 —— 给钥匙目录挂持久卷(每个副本看见同一只目录);或关停驻审批(`DURABLE_APPROVAL=false`,要审批的任务只在活连接上等);local 部署还可声明易失(`LOCAL_STORE_DURABILITY=ephemeral`)。
+    **已知边界**(既有,本条未收):第 2 段铸钥匙(web-admin 运行时)之后,第 3 段开店里的 SQL 判(退役 schema、跳版截点、列册对账)拒启时保管店的钥匙已铸;起服第 6 段之后的拒启判(停驻凭据封签不可用、装配期配置不变量)
+    晚于第 3 段的迁移段;记忆向量指纹门在运维确认重嵌(`MEMORY_EMBEDDER_REEMBED`)时的清列在判官段里。嵌入方的公开序列(`createStoreBackend()` → `ensureSchema()` → `runOneTimeMigrations()`)不跑列册对账。
+
+39. **勘误 7.148.0 节第 35 条:账本里的 `delete` 事件不是本服务写的 —— 本服务自身不写该事件,排空脚本读到的是引擎留存域 / 别的嵌入方写下的账本(文字订正;零行为变化;部署零动作)**:
+    已发节(7.148.0)不改字节,本条即订正。
+    订正对象:第 35 条说引擎自 7.56.0 起在删某个会话的检查点行时写 `delete` 事件,读起来像本服务删会话就会写。`DB_BACKEND=local` 删会话时检查点那一腿只把这只会话的停驻门作废、删掉它的续跑输入文件,账本与快照照样留着终局历史,不写 `delete`。
+    `scripts/drain-check-local.mjs` 认这个事件,是为了读引擎的留存域、或别的嵌入方在同一只数据根上写下的账本;本服务自己写的账本里不会有它。
+    **谁需要**:按第 35 条去本服务的数据根里找 `delete` 事件的运维。**谁受伤**:无。**出路**:无动作;脚本读法不变。**升级前做**:无。**回滚**:无存储形变化。
+
+40. **勘误 7.148.0 节第 78 条:会话记忆抹除口(`POST /v1/sessions/:id/memory/erase`)那一臂「层拒改答 400 `request.memory_layer`」在 wire 上不可达(文字订正;零行为变化;wire 零变化;部署零动作)**:
+    已发节(7.148.0)不改字节,本条即订正。
+    订正对象:第 78 条把会话记忆抹除口列进「层拒改答 400 `request.memory_layer`」。这只面的请求体不收 `scope` 也不收 `select`(两者都答 400 `request.body_shape`),选择子由路径铸成「这只会话」,抹的是部署里每一只店里这只会话的那一份 ——
+    没有「点哪一层」可以点错,所以这一臂从 wire 上构造不出来;映射保留(引擎若对这只面抛层错,答的就是这一形)。同条「旧形:`500 internal.error`」对这只面指的也是引擎抛层错的那一形,同样不能从 wire 构造。其余四口的控制面损坏改答 `500 internal.memory_control_plane_corrupt` 不变。
+    **谁需要**:按第 78 条给会话记忆抹除口写「400 `request.memory_layer`」用例的消费方与测试。**谁受伤**:无。**出路**:这只面要测的拒是 `scope` / `select` ⇒ 400 `request.body_shape`。**升级前做**:无。**回滚**:无。
+
 ## 7.148.0 —— 1–115 条见下
 
 1. **删净一只会话只有一个执行体:SQL 上在线删除与留存同一段事务;删后收尾两者同一只(行为统一;嵌入方类型面 BREAKING;wire 零变化;零 DDL;部署零动作)**:
@@ -5125,7 +5668,7 @@
      `ensureSchema()` 自身先探后建,与本服务自己的起服路径是同一条路;7.126.0 上同一序列遇退役 schema 是在 `runOneTimeMigrations()` 里拒,本版前移到 `ensureSchema()` 里拒(同一只 `RetiredSchemaPresentError`,码 `config.schema_mismatch`,拒之前零 DDL),
      包根不新增也不需要任何别的建连动词;按 `code` / `instanceof RetiredSchemaPresentError` 分派的代码不用改。
    - **补偿**:无需动作,也无旋钮。
-10. **升级顺序的唯一出处(跨仓)**:控制台 / 编排器 / 引擎的升级顺序只在 sema-web-admin 的 `DEPLOYMENT.md` §1「升级顺序(唯一出处)」一张表上(按版本加例外行)。本文件自本版起**不再重述顺序句**;此前各节里的顺序句(7.124.0 第 1 条、7.126.0 节头)是当时的快照,与该表不一致时以该表为准。
+10. **跨组件的升级顺序不由本文件另立一张表**:控制台 / 编排器 / 引擎三者之间谁先升,本服务这一侧对顺序的要求(先停光旧副本、先升读者再放写、先客户端后中心 ……)写在对应那一版的节里 —— 按你要升到的那一版的节读;本文件自本版起**不再重述顺序句**。此前各节里的顺序句(7.124.0 第 1 条、7.126.0 节头)是当时的快照,与较新版本节里的升级序不一致时,以较新的为准。
 
 ## 7.126.0 —— 🔴 会话 id 只收 canonical uuid(提交口 / A2A / run-local;自选名改成自留映射)· 🔴 团队编排面退役(请求键 `council` `debate` / `discuss` 场景 / `councilRuns`,零别名)· 🔴 角色词六个 · 🔴 审批卡词 `contentKind` → `approvalCard` · 🔴 `allowTools` 未知名拒跑 · 存量 SQL 库:`task_run` 加一列(幂等体指纹)+ 新表 `workspace_space_commit`(建表腿自动;期限列随行)· 会话删除 / 留存 sweep 回收空间快照对象(桶生命周期规则只作兜底)· 一次性迁移 M1–M3 退役:从没在 7.125.x 起过服的旧库起服即拒 ⇒ 先过 7.125.x 一次 · `WORKSPACE_PERSIST` 缺省 `off` → `space` · 记忆店根搬家 ⇒ 拒启 · 远端车道相对 `cd` 后删除问人 · 升级序:web-admin 先(council 键退役)、再 server;核心 7.49.5 / settings-schema 12.2.1 两包精确钉
 
@@ -7145,8 +7688,7 @@ wire 面(同步提交撞 park 的 200 体、`GET /v1/runs/:id` 行形、同一
   `mounted: true` ≠ shell 可达。operator 面的 `configFingerprint` **一次性变值**
   (同装配各腿仍相等)—— 持久化 / 钉了指纹的读者会见一次跳变。
 - **`GIT_CONFIG_KEY_<i>` 不再被剥**(core 7.33.1):宿主子进程(host shell / git 腿 / 语言服务器 / bake-runner)里,普通的 git env
-  配置组原样到达;只有某个 KEY 的值带 `<scheme>://<userinfo>@`(令牌 insteadOf)时这一条扣下(7.103.0 是本仓整组扣;7.103.1 起判定全在 core 7.33.6,见本段末条)。🔴 **安全轴披露(core
-  KL-1129a)**:`GIT_CONFIG_VALUE_<i>` **不在** core 的凭据形状判据里 —— 组里 KEY 是 `http.extraHeader`、VALUE 是 `Authorization: Bearer …`
+  配置组原样到达;只有某个 KEY 的值带 `<scheme>://<userinfo>@`(令牌 insteadOf)时这一条扣下(7.103.0 是本仓整组扣;7.103.1 起判定全在 core 7.33.6,见本段末条)。🔴 **安全轴披露(core 的已知限度)**:`GIT_CONFIG_VALUE_<i>` **不在** core 的凭据形状判据里 —— 组里 KEY 是 `http.extraHeader`、VALUE 是 `Authorization: Bearer …`
   这一形会**原样**进宿主子进程(含模型能驱动的 host shell),并在 `isolateConfig` 的 git 腿上作为命令级配置**生效**(`GIT_CONFIG_GLOBAL /
   SYSTEM=/dev/null` 挡不住 env 这一层)。**迁移**:不要把凭据放进服务进程 env 的 git 配置组;要给 git 带凭据,走 credential helper / ssh key /
   写在 `durableRemote` 里。⤷ **7.103.0 已随 core 7.33.2 修掉**(车PA 提货):core 给凭据侧加了**值族表**,
@@ -7158,10 +7700,10 @@ wire 面(同步提交撞 park 的 200 体、`GET /v1/runs/:id` 行形、同一
   其后任意位置有 `@` 或 `%40` 即剥;proxy 地址键下值里有 `@` / `%40` 即剥(密码含未转义 `/`、括号形、单斜杠 `https:/u:t@h`、`ssh://t%40h/…` 等此前
   漏过的写法一并剥 ⇒ 这一对扣下)。**谁受伤**:git env 配置组的键或值里 `:/` 之后带 `@` / `%40` 的(含 `@scope` 包路径写法、`%40` 编码形;不限 URL ——
   scp 绝对路径 `host:/repo@v2.git`、`http.extraHeader = Referer: https://…/@scope`、`includeIf.gitdir:/home/a@corp/.path` 同)那一对不到宿主子进程
-  (多剥,core KL-1129b;7.103.0 是整组不到,7.103.1 起同组其余条目照到)。**出路**(只对不带凭据的这类配置;凭据照旧走 credential helper / ssh key / `durableRemote`,`~/.gitconfig`
+  (多剥,core 的已知限度;7.103.0 是整组不到,7.103.1 起同组其余条目照到)。**出路**(只对不带凭据的这类配置;凭据照旧走 credential helper / ssh key / `durableRemote`,`~/.gitconfig`
   模型可读):不隔离全局配置的腿(host shell / 语言服务器 / bake-runner / leader 推送)读宿主全局 git 配置,写进 `~/.gitconfig` 即可;center-plugins
-  克隆腿每次在新目录克隆、且隔离全局 / 系统配置,这类配置在该腿上**没有替代通道**,只能改写成 `:/` 之后不带 `@` / `%40` 的形,或候 core 收窄
-  KL-1129b;project-memory 只跑 `git log` / `git status`,不读这类配置。不受影响:值里没有 `:/` 的 scp 相对路径(`git@host:org/repo.git`)与 `:/`
+  克隆腿每次在新目录克隆、且隔离全局 / 系统配置,这类配置在该腿上**没有替代通道**,只能改写成 `:/` 之后不带 `@` / `%40` 的形,或候 core 把这条「多剥」
+  收窄;project-memory 只跑 `git log` / `git status`,不读这类配置。不受影响:值里没有 `:/` 的 scp 相对路径(`git@host:org/repo.git`)与 `:/`
   之后没有 `@` / `%40` 的值;7.103.1(core 7.33.6)起 `ssh://` / `git+ssh://` / `git://` 的 userinfo 只是登录名(`ssh://git@github.com/…`,键的子节或整条值)
   也不再扣。
   ⤷ **7.103.1(core 7.33.6 精确提货;车PG 退役本层、车PK 提 7.33.6):git env 配置组的判定全在 core,本仓那一层退役**。7.103.0 的「整组扣」让同组的
@@ -7181,7 +7723,7 @@ wire 面(同步提交撞 park 的 200 体、`GET /v1/runs/:id` 行形、同一
   `secret_env_git_config_pairs_withheld_total` / warn `git_config_pair_withheld` 从未发布、随层删除。
   **点名放回**(`LSP_ENV_ALLOW` / `BAKE_ENV_ALLOW`)按名叠在剥除结果之上:一条被扣的配置把 `GIT_CONFIG_KEY_<i>` 与 `GIT_CONFIG_VALUE_<i>` **两只一并点名** ⇒
   这一条原样交出(COUNT 本就原样,点不点同;v7.103.0 文档写的出路 —— 点名全部 KEY / VALUE —— 照旧成立);只点一只 = 与另一只的占位半条配成一对。
-  **迁移**:凭据照旧不进 env 配置组。KL-1129b 多剥的无凭据配置,core 7.33.5 Pickup 段(git 2.54 真验)给的可用写法:`includeIf.gitdir:` 路径里的 `@` 写成
+  **迁移**:凭据照旧不进 env 配置组。上面「多剥」的无凭据配置,core 7.33.5 Pickup 段(git 2.54 真验)给的可用写法:`includeIf.gitdir:` 路径里的 `@` 写成
   glob `?`;`safe.directory` 写进宿主自有的全局配置文件(`GIT_CONFIG_GLOBAL`;仓库级配置对它无效);`@scope` 包 URL 写进仓库级配置。(把 `@` 写成 `%40`
   同样触发判据 —— 不可用。)**已知边界**(core 7.33.6):① 子进程看得见占位行 `sema.withheld=`(见上);② 运行时才拼出来的口令(`$(…)` / `$VAR` / `read` 取值、
   由展开给出的程序名)core 读不到、照原样交出;③ `http.extraHeader` 下的**非凭据**头(trace / 路由头)照样按键扣,要它到达写进 git 配置文件。