@sema-agent/server 7.150.0 → 7.151.0

package/MIGRATION.md

@@ -8,6 +8,191 @@
 > 本文件只记会影响存量部署行为的变更:某一版没有节,即那一版没有记入这里的升级动作;完整的变更流水账(修复、文字订正、内部重构)是内部记录,不随 npm 包出。
 > 文中的「契约 §N」「契约附录 X」指服务端 wire 契约的节号(内部记录,不随包),只作查证坐标。
 
+## 7.151.0 —— 1–22 条见下
+
+**升级清单(本节唯一的一张;下面各条只讲为什么,不再各自重述升级步骤)** —— 一次读清本版对一只存量部署要做的全部动作。每版同形:① 手工 DDL(逐表逐句,两方言各一份)② 起服自建与一次性迁移 ③ 停-迁-起 ④ 顺序;后续每版的段头照此写,新增一句 `ALTER`、一条一次性迁移、一条停-迁-起时,先改这里,再写条目。
+已发各节(7.150.0 及以前)逐字只读,不在原处补汇总 —— 跨过它们的部署读下面「跨过 7.150.0」一块。
+
+- **从 7.150.x 升级到本版**:
+  - 手工 DDL(SQL 后端 `DB_BACKEND=mysql|pg`;一张表一句,**先升库、再升副本**;旧副本只在它重启时按「库比构建新」拒启,多出的这一列是它的幽灵列)。语句逐字是起服列册对账拒句打印的那一句(由本构建的建表语句生成),存量行不回填(第 1 条「客户端放置的子代会话」):
+    - MySQL 协议:
+      `ALTER TABLE session_ext ADD COLUMN session_kind VARCHAR(32) NULL;`
+    - PostgreSQL:
+      `ALTER TABLE session_ext ADD COLUMN session_kind VARCHAR(32) COLLATE "C";`
+    其余各条零 DDL:停驻问的决定记在问表既有的列上(第 2 条),workflow 停驻卡的决定行同列同形(第 3 条),续跑上下文多的一格随既有的上下文列存(第 4 条)。`DB_BACKEND=local` 零 DDL。
+  - 起服自建(运维零手工):索引 `idx_session_ext_kind`(新版起服自建:MySQL 协议在线 `ADD INDEX`,PG `CREATE INDEX CONCURRENTLY`,两遍表扫、不挡写,`session_ext` 行数大的库起服变慢;第 1 条)。无新表。
+  - 一次性迁移:**M53**(SQL 两方言;起服自跑,运维零手工;第 5 条「SQL 店的失败对外只说」):换句之前落盘的后台子代行(`background_agent.record_json` 的 `error`,及 `summary` 里逐字含它的那一段)与 run 事件里 `tool_end` 子代卡的 `errorMessage` 换成对外句(改写的后台子代行按本表写律 `rev` 抬 1);读数 `storeFaultSentencesRewritten`(起服日志 `one_time_migrations_applied`);窗 = 本版发布日 + 30 天,窗内每次起服再扫(滚动升级窗里旧副本新写的旧句下一次起服接住);`DB_BACKEND=local` 恒 0。另:停-迁-起证据读法不再登记为一次性迁移 M52,改为常设、没有删除日期(第 7 条)。
+  - 停-迁-起:**无新增**,本版条目没有一条要求停光旧副本。已有几条(**M40** · **M41** · **M42** · **M51**)本版起:守卫一律在迁移段第一笔写之前一起判;放行的那一条在它自己的第一笔改动之前往 `serving_requirement` 记一行 `in_force`(只在还欠它的库上;起过 7.148.x 的库零写);停光旧副本这一步不变,仍是运维的第一道(第 7 条)。
+  - 引擎换钉:`@sema-agent/core` 7.66.0 → 7.66.1(精确钉,`@sema-agent/primitives` 随之;随包到货,零 DDL、零新旋钮、运维零动作):行为面只一处 —— 没有耐久授权声明的腿(同步委派子代)没人答的问不再停驻,读引擎的拒(第 19 条;被中心强制耐久门的主体除外,见第 22 条);本服务自己的根腿与带转交声明的后台子代照旧停驻。
+  - 升级前自查(不改库;每条一行,出路在各条里):`BAKE_ENV_ALLOW` 不点 `BAKE_RUNNER_TOKEN`、不点与它同值的变量(第 11 条,点到 ⇒ bake-runner 拒启)· 直接 `helm` 的部署在 values 里写下 `server.operatorSingleUser` 或 `server.requirePrincipal`,先 `helm template` 同一份 values(第 20 条;经 `sema-up` 装的部署零动作)· 同一只引擎上 `SEMA_WEB_ADMIN_ASSERTION_TOKEN` 与 `_FILE` 只留一个(第 9 条,两键都有值 ⇒ 拒启)· fleet 成员上按旧日志数一数 `scope` 与本 worker `FLEET_SCOPE` 不等的登录令牌调用方(第 8 条,升级后它们 403)· 只接鉴权桥、没配 service 凭据的部署核告警脚本对 503 `auth.service_token_required` 的读法(第 10 条)· 用 `config.d/remote-exec.json` 选车道的机器 `env | grep -E '^(DOCKER|HOST)_'`(第 15 条,同车道 env 旋钮从此生效)· `AUTONOMY=plan` 的部署数一数此刻停驻的 run(第 13 条:续跑时体上的权限模式词照现地板钳进 plan;要按原词走完 ⇒ 升级前决完)· 按 `connect_failed` 告警桶缺、准入拒、恢复不回、家目录 / 主机密钥不符的规则改认 `env.*` 码,按 `auth_failed` 告警配额 403 的改认 `connect_failed`;读本版 wire 清单求交的消费方注意自铸登记 `refusalSentenceForm` 退出了一个句型键 `connect_failed(run 失败终局)#snapshot_bucket_missing`(本版清单 breaking 的唯一来源;同一句改由 `env.snapshot_bucket_missing#snapshot_bucket_missing` 入册,句型与码以外的机读位不变)(第 17 条)· 日志采集留住店边界那一行 `at=store`(第 5 条:库驱动的原话从子代卡 / 通告 / 回读 / 文件历史失败句挪到 worker 日志)· `HOST_WORKSPACE_BASE` 与调用方送的 `cwd` 里有没有 `..` / `.` 段(第 16 条,有就改写成规整绝对路径)· 接中心的部署盘点中心上关了 fork(`allowFork:false`)或开了强制耐久门(`forceDurableGate:true`)的主体(第 22 条:它们的委派子代此后同受这两位;强制门主体的同步子代没人答的问停驻成决不了的卡)。
+  - 顺序:① 备份 ② 上面那一句 `ALTER`(SQL 后端,先升库)③ 换版本(可滚动 —— 滚动窗里不要重启旧副本,它按「库比构建新」拒启;新旧副本混跑窗内的差别见第 1 条「滚动升级窗」与第 3 条「混跑窗」,全部副本升完即消失)。
+- **跨过 7.150.0(从 ≤ 7.149.x 直升本版)另加 7.150.0 节段头升级清单的全部动作**(那一张已含「跨过 7.149.0」一块)。
+
+1. **客户端放置的子代会话:提交体 `sessionKind: "sidechain"`(能力位 `sessionKinds`)—— 这种会话不进 `GET /v1/sessions` 的缺省视图与 `ListAgents`、最后活动之后过 `BG_AGENT_RETENTION_MS` 由维护拍删除;SQL 部署升级前手工 DDL 一句(持久数据面;行为加性;wire 加性;没有一次性迁移)**:
+   客户端可以把一次提交建的会话声明为子代对话:提交体 `sessionKind: "sidechain"`(只在建这只会话的那一笔提交里写下,此后终身不改)。这种会话不进 `GET /v1/sessions` 的缺省列表(`?sessionKind=sidechain` 单列它们)、不进 `ListAgents`、不能作 `SendMessage` 的跨会话收件人;最后活动之后过 `BG_AGENT_RETENTION_MS`、且没有在跑的 run / 待决的审批 / 在跑的子代或 workflow 挂着它时,由维护拍删除;按 id 的读写与普通会话相同。不带键的提交、存量会话与老壳零变化(存量行即顶层对话,无回填)。
+   **升级前做(SQL 部署;先升库再升副本)**:起新版之前执行这一句(起服列册对账对缺列的库拒启,拒句里逐字打印同一句):
+   - MySQL 协议(TiDB / MySQL):`ALTER TABLE session_ext ADD COLUMN session_kind VARCHAR(32) NULL`
+   - PostgreSQL:`ALTER TABLE session_ext ADD COLUMN session_kind VARCHAR(32) COLLATE "C"`
+   索引 `idx_session_ext_kind` 由新版起服自建(MySQL 协议在线 `ADD INDEX`;PG `CREATE INDEX CONCURRENTLY`,两遍表扫、不挡写,`session_ext` 行数大的库起服变慢)。local 部署零动作。没有一次性迁移、没有停-迁-起:旧副本不会写出违反新律的行(它补旁表行时种类为 NULL = 顶层)。
+   **滚动升级窗**:旧副本答的列表里仍带属主自己的 sidechain(只对属主 / 运维可见,不跨租户);旧副本不老化(新副本老化,删除围栏防双删);旧副本对带键提交答 400 `request.body_shape`(`unknownKeys:["sessionKind"]`)—— 客户端先读能力位 `sessionKinds`。
+   **谁受伤**:按列表全集断言的消费方;只被读、不再续话的 sidechain 过视界即删(读不是活动)。**补偿**:`?sessionKind=sidechain`;`BG_AGENT_RETENTION_MS` 调长(后台子代行的保留期一起变长)。
+   **回滚**(本版 → 7.150.x):旧构建的列册对账对多出的列拒启 ⇒ 先 `DROP INDEX idx_session_ext_kind`(MySQL 协议:`ALTER TABLE session_ext DROP INDEX idx_session_ext_kind`;PG:`DROP INDEX idx_session_ext_kind`)再 `ALTER TABLE session_ext DROP COLUMN session_kind`;已建的 sidechain 会话从此是普通会话(进列表、不再按 `BG_AGENT_RETENTION_MS` 老化)。local:会话元数据格多了一位,旧构建的严格边档整只拒(与客户端写计数同一回滚拒形)—— 回滚之前先用本版删掉 sidechain 会话。
+
+2. **耐久决断口 `POST /v1/tasks/:taskId/asks/:askId/decision` 受理已转停驻的问;停驻卡的决定记在它的问行上(行为变更;wire:一面状态翻转 + 加性;持久数据面:问表既有列在 `PARKED` 行上也落值、local 后端问账账本多一个动词;部署零动作)**:
+    旧形:问一转停驻,决断口答 `410 gone.ask_parked` + 三件坐标,指路耐久审批门 `POST /v1/approvals/:sessionId/decide`;live 应答口 `POST /v1/tool-approvals/:id/respond` 的停驻臂受理之后不在问行上留记录(副本内一小时的进程内回执)。
+    新形:非直连门部署上,决断口对门仍开着的停驻形交与 live 应答口停驻臂同一只赎回 —— 受理 `200`(`accepted:"parked_redeemed"`),门上已站着一次决定 ⇒ 同 `idempotencyKey` `200` 回放首决、否则 `409 conflict.ask_decided`;停驻赎回的拒(`429` 成本配额 + `Retry-After` / `503` / `409 approval_stale` …)原样。两扇门受理之后都把决定(决议向 · 署名 · 理由 · 回决幂等键 · 出处)写到这只问仍 `PARKED` 的行上(态不变;问表既有的 `decision` / `decision_actor` / `decision_note` / `idempotency_key` / `settled_by` / `decided_via` / `decided_at_ms` 列)。直连门部署(决定要签名信封)上门仍开着的停驻形照旧 `410 gone.ask_parked`(门上已站着决定的那一形同样改答 `409 conflict.ask_decided`)。显式运维(`OPERATOR_PRINCIPALS`)代决别人的停驻卡与活卡同放(此前停驻形不放)。
+    **谁需要**:经决断口回决审批卡的壳 / SDK —— 停驻之后不必再读 410 换口、换身份,重发按同一把幂等键在两形上同答,跨副本成立。
+    **谁受伤**:按 `410 gone.ask_parked` 判「窗已关、去别处答」的壳(非直连门部署上同一请求现在直接被受理,或得到首决回显的 `409`);对 `PARKED` 问行的 `decision` 列做「为空 = 没人决过」判断的旁读者(本服务自己的读面不这么读:已决读法只认 `DECIDED` 行与停驻门本身)。
+    **出路**:壳把 `200 accepted:"parked_redeemed"` 读作「已受理、续跑开始」,把 `409 conflict.ask_decided` 读作「已有首决」(与活问同一套处置);旁读者对 `PARKED` 行读停驻门的状态(按问读口 `GET /v1/tool-approvals/:id` 的 `state`),不读 `decision` 列。live 应答口与呈卡帧的 `approvalId` 下一版退役 —— 现在就改用决断口。
+    **升级前做**:无。**回滚**(本版 → 7.150.x):SQL 后端(`mysql` / `pg`)照读 —— `PARKED` 行上多出来的列值上一版不读;`DB_BACKEND=local` 上问账账本(`<数据根>/approval-asks/asks.jsonl`)里一旦有本版写下的停驻落行记录(新动词 `recordParkedDecision`),上一版**启动即拒启**并点名(「a newer server wrote it」)—— 回滚步骤:① 停接新任务,等审批收敛(`GET /v1/approvals` 的 `pending` / `livePending` 都空);② 让本版继续跑到账本到阈压实(压实后只剩行快照,上一版读得动),或停机把 `asks.jsonl` 移开(已收敛的部署上只丢已决历史);③ 再启上一版。
+
+3. **workflow 子代停驻卡:持有它的 run 仍在跑时,每一次决断先落成一条耐久决定行(落在那条 run 的记录行锁里,同一张卡先受理的决定立住,另一个决定答 `decide.claim_lost`);不持有它的副本不再起宿主一跑,由持有副本在一个维护周期(`REAP_INTERVAL_SEC`)内交给那条 run,run 先收场则经 run 的完成送达交给宿主会话的下一跑(行为变更;单副本上三处角落的答复变;wire 零新键、零新码;无 DDL、无迁移步;部署零动作)**:
+    旧形(7.148.0–7.150.x):`/decide` 只在跑那条 run 的进程里把决定交给它;别的副本上的决断走续跑车道 —— 答 200(`taskId` = 宿主新一跑)、起宿主一跑,那一跑的 `Workflow({resumeFromRunId})` 被引擎以「记录仍在跑」拒,`parked: true` 挂到 run 在持有副本上自己收场;同一张卡的两个不同决定落在两只副本上时,可能一个答过 200、引擎用了另一个。
+    新形:持有这张卡的 run 的记录读作 `running`(任一副本读)⇒ 决断先在那条 run 的记录行锁里落行(记录仍持有这张卡才落;先受理的决定立住、之后不被取代),答 200 `{ taskId: <workflow run id>, status: "resuming", decision }`,不起宿主一跑;跑那条 run 的进程当场(决断恰落在它)或下一个维护拍把行交给引擎;run 先收场 ⇒ 完成送达(至少一次,失败在维护拍上重投)把行交给宿主会话的下一跑 —— 这一跑由服务端起:以卡属主为主体,宿主停在 `task_done` 卡上时那张卡须同属主,付费方两门(费用额度 / 服务租约)照判、拒即不起(一行 `workflow_park_handoff_refused`,行留着、卡可再决)。记录已不读作 `running` ⇒ 续跑车道,与上一版同。
+    单副本上也变的三处角落:引擎此刻读不出这张卡 —— 503 `decide.store_unreachable` → 200;run 此刻不在这张卡上等(正在收场)—— 409 `decide.gate_moved` → 200;run 正在挂起 —— 200 体由续跑车道那一形(`taskId` = 宿主新一跑)变成活臂那一形(`taskId` = workflow run id)。带 `mcpServers` / `a2aPeers` 决、记录读作 `running` ⇒ 照旧 400 `decide.parked_restatement_unsupported`,但不再先探引擎(上一版卡恰离开 pending 时答 409)。其余成功形与拒码不变。
+    **谁需要**:SQL 后端 ≥ 2 副本、负载均衡不按子会话粘的部署 —— 决定在一个维护周期内生效,不再挂到 run 自己收场,也不白烧一次模型调用;单副本上恰在 run 收场那一窗里的决断。**谁受伤**:① 跨副本决定生效延迟 ≤ 一个维护周期(每拍至多 64 条,超出的轮到下一拍);② run 带着已受理的决定收场时,宿主会话上多一条服务端起的 run,计费给卡属主;③ 按那两处 503 / 409 角落做重试、或按 200 体 `taskId` 去轮 `GET /v1/runs/:id` 的端(活臂那一形的 `taskId` 不在 run 店里,读 `GET /v1/workflows/:taskId`);④ 持有进程死掉、或 run 收场了而终态记录没写进去(记录仍读作 `running`)⇒ 行等孤儿窗(`WORKFLOW_ORPHAN_GRACE_MS`,缺省 24 h)翻 `failed` 后才交出,其间 `parked: true` 挂着;`WORKFLOW_RUN_STORE=memory` 没有完成日志 —— 要重投的转交(宿主会话正忙等)不重投,一行 `workflow_park_handoff_not_redelivered`,完成照常推进会话,决定由宿主会话的下一跑带,或再决一次。
+    **补偿 / 出路**:要更短的跨副本生效延迟就调低 `REAP_INTERVAL_SEC`(同一拍的其余维护各腿一起变快、库读一起变多);收场转交那一跑就是这条已受理决定的去处(上一版要人再决一次),没有关掉它的旋钮;费用额度超顶 / 服务租约耗尽、属主不一致、宿主续跑输入已被回收 ⇒ 不起、一行 `workflow_park_handoff_refused` + 计数 `workflow_park_handoff_total{result}`,行留着、卡可再决;会话正忙、服务租约中心不可达、库瞬态 ⇒ 下一个维护拍重投。没有新旋钮。
+    **升级**:本条在段头升级清单之外零动作 —— 本条零手工 DDL(决定行的列不变:记录栅栏落的行 `delivered_task_id` 写 workflow run id,同宽同列)、一次性迁移无、停-迁-起无,可滚动,任何换版顺序都不比上一版差。**混跑窗**(新旧副本并存):跨副本决断仍按上一版的行为 —— 新副本落行、答 200,持有那条 run 的若是旧副本 ⇒ 没有拉取、没有收场转交,决定挂到 run 收场后宿主下一跑或再决;旧副本对读作 `running` 的记录照旧整行取代决定行,可能盖掉新副本按「先受理者立」落下的那一个。全部副本升完后新行为生效。**回滚**(本版 → 7.150.x):记录栅栏落的行旧版照读(同列同形);旧版的回执幂等判对 workflow run id 读不到在跑的一跑 ⇒ 照起一跑,与上一版同。
+
+4. **登记簿默认读层(项目登记的 `defaultScopes` 作一条 run 记忆面的额外读层)只取提交者看得见的登记;判出的种子(哪只项目 + 判出它的那一位观者)随 run 冻结,续跑以冻结的观者重判 —— **升级前已停驻、带 `projectId` 的 run 续跑不带默认读层(运维 warn 一行 `resume_memory_seed_unjudged`);要默认读层,重提交**(安全轴,fail-closed;行为收紧;续跑上下文多一格服务端写的兄弟键;wire 零变化;部署零动作)**:
+    射程:接了配置中心(有项目登记簿)且记忆面点亮的部署;多租 / 多登记者部署上提交别人登记的项目 id 的调用方;升级时仍停驻、升级后续跑的 run。
+    旧形:默认读层按提交体的 `projectId` 直接查登记簿,不判这只登记对提交者可不可见(读面 `GET /v1/projects/:id` 答 404 的项目,它声明的 scope 词照样进这位调用方的读层;`org:` 键进记忆准入、目录不给时拒句点名它);停驻后续跑按存体的 `projectId` 现查一次。
+    新形:新提交腿判一次 —— 默认读层只取对提交者可见的那只提交项目(与读面同一只判:fleet 调用方看全部,带验过主体的调用方只看 `registeredBy` 是自己的),看不见与未登记同答(没有默认读层、不拒、拒句不点名);判出的种子随 run 写进续跑上下文(兄弟键 `memorySeed`:项目 id + 那一位观者;提交带了 `projectId` 而判不出 ⇒ `null`「判过,无」),续跑以冻结的观者经同一只判读此刻的登记(改了词 ⇒ 新词;删了、换了主人、不再对他可见 ⇒ 没有默认读层);本版之前写下的停驻行没有这一格 ⇒ 续跑不取默认读层(不回填:那时没有判过可见性),存体带 `projectId` 的每一条续跑腿记运维 warn 一行 `resume_memory_seed_unjudged`(`sessionId` + `projectId`,不带 scope 词;判过的、不带项目的续跑不记);这一格形不对 ⇒ 续跑答 500 `corrupt`(`where` 点名 `memorySeed`)。不经 HTTP 直调装配器的嵌入方没有观者 ⇒ 没有默认读层。
+    **谁需要**:多租 / 多登记者部署(一位调用方不该经默认读层读到别人登记的项目声明了什么)。
+    **谁受伤**:提交别人登记的项目 id 的调用方(默认读层没了,`org:` 键不再进准入);升级时仍停驻的 run(续跑少了默认读层,不拒、不报错);直调装配器的嵌入方;团队成员用管理员登记的项目(与读面同答,放宽可见性是另一件设计)。
+    **升级前自查**(一行):要默认读层跨过升级仍生效的停驻 run ⇒ 升级前决掉,或升级后作为新任务重提(升级后按 `resume_memory_seed_unjudged` 一行找出是哪几条)。**出路**:由登记人本人或 fleet 调用方(不报主体的 service 凭据,部署没声明 `SERVICE_TOKEN_ACTS_FOR_DEPLOYMENT=false` 时)提交。**回滚**:回到上一版即回到旧形(上一版不读这一格、原样带着,续跑按存体的 `projectId` 现查);零配置、零库形变化。
+
+5. **SQL 店的失败对外只说「原码 + 稳定句」,而且在店边界就换句:子代结算卡、后台子代通告、子代回读、父模型读到的子代失败文本、文件历史与记忆补丁的失败句不再带库驱动的原话(行为变更;安全;运维面:库的原话挪到 `at=store` 日志行;只带数字错误号的驱动错终局码变;一次性迁移 M53)**:
+    射程:`DB_BACKEND=mysql|pg` 的部署;本地文件后端(`DB_BACKEND=local`)的店不拨 SQL、不在射程内(它们的 fs 错照旧)。
+    旧形:run 终局自 7.148.0 起是「<类别句> [original code: <码>]」,但子代结算卡 `errorMessage`、后台子代 `<task-notification>` 摘要、`GET /v1/runs/:id/subagents/:handle/output` 的 `content` / `output`、父模型读到的子代报告行、文件历史逐文件失败句、记忆补丁冲突 `reason`(经记忆同步回给对端)逐字带库驱动的原句(库账号 / 内网地址 / 表名 / 约束名);只带数字错误号、没有符号码的驱动错(TiDB 自有号)终局 `terminal.code` 缺席、`message` 是库的原句;检查点行太大的 `store.row_too_large` 与提交腿的 413 句括号带库的原句。
+    新形:这些面与 run 终局同一句(驱动没给码时只有类别句);只带数字错误号的那一形原码取那个数字的十进制串,`terminal.code` 是 `internal.store_error`;413 句不再带库的原句(墙由 `wallSource` / 错误的 `wall` 说)。会话店的 `storage` 失败码、撞键 / 死锁 / 行太大的判决与引擎的语义码不变。库的原话在 worker 日志的店边界那一行:`[terminal] outward_failure_code_folded … at=store site=<店>.<方法> class=<类别> message=<JSON 串>`(经出口座脱敏、有界),计数 `store_boundary_fault_total{site,class}`;`at=exit` 那一行的 `message=` 已是对外句。
+    存量:一次性迁移 M53 改写有结构标记的两格(见本节升级清单);父转录、卡外的 `output` 报告行、workflow 节点句等自由文本**不改写**(改写用户转录是数据完整性风险)—— 本版之前落盘的这些面仍可能带库的原话,出路 = 按留存清理,或运维手删那些行。
+    **谁需要**:多租户部署里读子代卡、通告、回读与父模型内容的人与集成方。
+    **谁受伤**:按这些面上的库原话排障的运维;按失败句文本分支的消费方;文件历史 rewind / restore 在工作区读写失败(权限拒、文件不在)时的逐文件失败句也换成类别句;按码形分支、没见过纯数字原码的消费方。
+    **出路**:判别一律读码;要库的原话读 `at=store` 那一行(按 `original=` 与时间对 `at=exit` / `request_error` 行);工作区失败的路径在同一条目的 `path` 上。
+    **升级前做**:无。**回滚**:回到上一版即回到旧形(本版 M53 改写过的格保持对外句,旧版照读,不拒)。
+
+6. **会话附随物绑住客:推送落定之后的文件历史 / 会话规则 / 回退锚 / 行两位、运行腿的回退锚、自动标题、规则写口,只写在判过的那一位住客(属主 + 化身)上;拉取 / 推送口门后复判住客;暂存提交按住客 CAS;规则店 / 文件历史店 / 回退锚店只经后端读、一只后端各一只实例(安全轴;行为收紧;嵌入方类型面硬破坏三处;wire 零新键、零新码,新增可达的既有答复四处;零 DDL;部署零动作)**:
+    规则:附随物只经落定段写 —— 段首锁会话根行与旁表行,用行格写原语的同一只判官比住客(行在 ∧ 非在删 ∧ 非委派分区 ∧ 属主与化身整对同),同一事务写;不是那一位 ⇒ 零字节写。读侧:门读到住客 ⇒ 门后每个非故障出口发出之前复判;门判空闲 id ⇒ 门后不读这只 id。
+    **嵌入方(自建 `StoreBackend`)**:`StoreBackend.landedAttendants()` 改为必选成员(类型面硬破坏,编译红即通告;包根导出 `LandedAttendantSeat` 及其参数 / 结局型)。它交回落定席位:在锁住会话根行、判过落定住客的段里写一次推送的文件历史、会话规则、回退锚与 `PUT …/policy` 的规则(随包 SQL 两方言与 local 后端都已带)。JavaScript 后端缺这一员 ⇒ 第一次推送 / 规则写在写下任何字节之前抛(500)。同一处的会话店签名随之变(同为编译红):`exportEntriesStream(id, { afterSeq?, batchSize?, recheck })` 的 `recheck` 必带(每页交出之前调一次,抛 ⇒ 流结束);`setTitleIfNull(id, title, landed)` 多一个落定住客(行不是那一位 ⇒ `false`、零写);暂存提交的选项 `expectedOwner` 换成 `expectedOccupant`(属主 + 化身;门判「无此会话」⇒ 缺席)。`ResumeAnchorStore` 读面不再带 `put`,锚只经席位写。**附随店只有一条读法**:`ServiceDeps` 删 `sessionPolicyStore` / `fileHistoryStore` / `resumeAnchorStore` 三键(编译红即通告)—— 服务面(规则口、能力位、同步族、rewind 口)读 `ServiceDeps.backend` 的 `sessionPolicy()` / `fileHistory()` / `resumeAnchor()`;后端对这三只与 `landedAttendants()` 各恒交同一只实例,席位写的就是读口交出的那一只(自建后端同守:写经一只、读经另一只 ⇒ `PUT …/policy` 答 200 而 `GET` 与引擎读不到这条收紧)。`StoreBackend.sessionPolicy()` 不再收 logger:SQL 规则店的封键 warn 经 `createStoreBackend(config, onWarn, …)` 的 `onWarn`(缺席 ⇒ 日志出口接缝的缺省 logger)。出路:删掉这三键(它们原就是后端的投影,带 `backend` 即可);要换店,换后端交的那一只。
+    **客户端**:推送在条目已提交之后可能答 `409 conflict`(`sync conflict`,不带 `relation`)—— 其间会话被删、或同 id 被重建(含同一属主);与其它同步冲突同一出路:从第一段重来。拉取可能答 `404`(与「门后被删」同体)、或 `entries` 流无尾行结束(读作截断),原因同上;重拉。暂存提交只落在第一段判过的那一位住客(属主 + 化身)上,不再只问属主 ⇒ 同一属主在条目流式上传期间删建同 id,提交答 `409 conflict`。在删会话上的 `PATCH`(标题 / 置顶)答 `404`;规则写口 `PUT /v1/sessions/:id/policy` 门后会话被删 / 重建答 `404`。
+    **谁受伤**:在删建竞态里推拉的客户端新碰到上面几只既有答复;自建后端的嵌入方编译红。自建 `ServiceDeps` 的嵌入方:上面三键编译红;没带 `backend` 的 `ServiceDeps` ⇒ 能力位 `sessionPolicy` / `restoreFiles` / `resumeAt` / `rewindFilesTo` 读作假、`GET` / `PUT /v1/sessions/:id/policy` 两口答 501 `capability.session_store_required`、会话同步族答 501(此前注入了店就照常):附随店只经后端读写;随包装配里这几只店本就只在有后端时才铸、HTTP 面拿到的是同一只后端,所以随包的部署形够不到这一形 —— 出路是交 `ServiceDeps.backend`。**出路**:见上(全是既有出路);运维按 warn `session_sync_landed_occupant_gone` 与计数 `session_sync_landed_occupant_gone_total` 分诊。
+    **存量数据**:本版之前已经落下的迟到写(推来的历史发布进了重建的会话、空闲 id 上留下的行)与常规行分不开,原样保留。
+    **混版窗**:还在上一版的副本照上一版的行为写;旧副本全部下线之后本条的保证才成立。
+    **已知限制**:fork 子会话第一次跑时从源会话承接文件历史,不问源会话此刻还是不是 fork 时的那一位(这一半归引擎,本版不闭)。
+    **升级前做**:无。**回滚**:回到上一版即回到旧形;无存储形变化。
+
+7. **停-迁-起迁移:守卫一律先于一切写、放行时记一条起服要求;证据读法常设(行为变更;持久面:`serving_requirement` 开始有写者、存词闭集只剩 `in_force`;wire 零新键、零新码;部署零动作)**:
+    旧形:几只停-迁-起守卫各在自己那条迁移的步里判证据 —— 排在后面的守卫拒启时,前面的迁移可能已经改了库(例:M40 已把退役车道词改名,M51 的守卫才拒,拒句仍说「Nothing was changed」)。`serving_requirement` 只有读者(起服准入),本服务不写;存词两词 `pending` / `in_force`(`pending` 从没有写者)。停-迁-起证据读法(判活窗内心跳过、持有者没登记为知道该条迁移的 `running` run)登记为一次性迁移 M52,窗 2026-12-09 关,关后删除 —— 删的是守卫唯一的证据。
+    新形:每条停-迁-起迁移在登记表里声明围栏类 —— `structural`(第一步改表,让更早副本点名旧对象的写当场失败)/ `per-write`(更早至少一版发出的写句自己读要求)/ `accepted`(成文的残余);本版的四条(M40 · M41 · M42 · M51)都是 `accepted`。起服时,迁移锁内、准入复核之后、第一步迁移之前,本构建所有还欠的停-迁-起迁移按登记序(M40 → M41 → M42 → M51)逐条判证据,任一有 ⇒ 拒启(码与句是那一条自己的),迁移段一字节不写;都没有 ⇒ 各条在自己的第一笔改动之前记 `(<迁移名>, in_force)`。之后缺这项能力的构建(本服务 7.150.0 起)起服拒 `config.serving_requirement_unmet`(`capability_missing`);起服拒句的升级清单在 `ALTER` 一步之前多一步,点名这只库要求而本构建没有的能力,并写明照清单补语句不会让缺能力的构建变安全(给蓄意回滚的删行语句)。证据读法不再是一次性迁移、没有删除日期:早于副本登记的副本持有的在跑 run 在任何日期之后都仍算证据。存词 `pending` 退役:读到它按 `in_force` 拒、拒句点名原词;`in_force` 那半句改成「a build that has it was admitted on this database and may have changed data for it」。M42 的 `older_replica` 拒句改成不再断言「没有存量身份带保留前缀」(守卫在扫描之前判):「this version reserves the prefix … and checks stored identities for it once before recording a marker, but … Nothing was scanned or changed and no marker was written.」
+    看不见的边(不变,如实):没有在跑 run 的空闲旧副本看不见;停顿 / 与库断开的旧副本迟到的写,任何观察都关不上;准入挡起服者,不挡已在服务的副本,也不挡过了准入、放锁之后才开服的那一只;早于 7.150.0 的构建不读这张表。
+    谁需要:多副本滚动升级的 SQL 部署的运维 —— 守卫拒启一定是零写的拒;一条停-迁-起迁移放行之后,缺这项能力的构建(回滚、滚动里晚到的上一版)起服即拒;此后引入的停-迁-起迁移仍看得见忙着的旧副本。谁受伤:滚动升级中仍有旧副本在跑的部署 —— 新形下同一只库可能先看到另一条的拒(按登记序第一条欠且有证据的那一条;例:同时欠 M40 与 M42 时先见 `config.execution_lane_rename_refused`);同时有以保留前缀 `_scn:` 起头的存量身份与在跑旧副本的库,先看到的拒因从 `stored_prefix` 变成 `older_replica`(全停之后再起,下一次起服才点名命中);跳版直升、还欠 M40 / M41 / M42 / M51 的库在本版第一次起服多落一行要求(7.150.0 起的构建都带这四项能力,照常起);蓄意回滚到缺某项能力的构建要先按拒句删那一行;按拒句全文匹配的脚本。补偿:拒启响亮、拒句点名能力与删行语句;停光旧副本再起(不变);按码分支,不按句子分支。
+    **升级前做**:无(段头升级清单)。**回滚**(本版 → 7.150.x):7.150.0 认得这四项能力,准入照过,记下的要求行无害地留着;更早的版本不读这张表。
+
+8. **fleet 成员只收本空间签发的登录令牌:令牌验过签而 `scope` 不是本 worker 所绑的 `FLEET_SCOPE`(缺席 = 缺省 scope)⇒ 整次请求 403 `auth.scope_mismatch`;非 fleet 成员不比对(安全轴,fail-closed;行为变更;wire 新码;零旋钮)**:
+    旧形:登记中心的登录令牌只要验过签就挂上身份,不论它是哪个空间签发的;`FLEET_SCOPE` 只被排空口读。
+    新形:本 worker 是 fleet 成员(设了 `FLEET_GENERATION`)时,登录令牌的 `scope` 必须等于 `FLEET_SCOPE`(没写 `FLEET_SCOPE` ⇒ 缺省 scope),否则整次请求 403 `auth.scope_mismatch`(先于其余各门;`GET /health` 不拒,这枚令牌按没出示凭据分档;拒句不带本 worker 的 scope),运维日志一行 warn `auth_bridge_scope_refused` 带令牌的 scope、本 worker 的 scope 与主体;起服行 `auth_bridge_enabled` 多一格 `scopeAdmission` 说比不比。没设 `FLEET_GENERATION` 的引擎(手接、壳起的个人引擎)不比对,读法不变。同一枚 Bearer 恰好也是本部署的 service 凭据 ⇒ 按 service 凭据读,不答 403。
+    谁需要:按用户停用 / 移出空间停他名下工作的停止面 —— 本 worker 上每一条登录身份从此都属于它所绑的空间;多空间部署的租户边界。**谁受伤**:给 fleet 成员发别的空间登录令牌的部署(用户在 A 空间登录、手配了 B 空间 worker 的地址;一台 worker 有意服务多个空间);手写 `FLEET_GENERATION` 却没写 `FLEET_SCOPE` 的非缺省空间 worker(本空间的令牌也 403;编排器渲的受管引擎恒带两键,碰不上)。
+    补偿:令牌按本 worker 的空间签(登录到那个空间,或把请求发给令牌所在空间的 worker);手写成员 env 的补写 `FLEET_SCOPE`;不要比对的引擎去掉 `FLEET_GENERATION`。没有旋钮。
+    **升级前自查**(一行):在 fleet 成员上对旧版本的运维日志数一数 `auth_bridge_principal_accepted` 里 `scope` 不等于该 worker `FLEET_SCOPE`(没写即缺省 scope)的行 —— 非零 ⇒ 那些调用方升级后 403,先按上一条补偿处置;升级后看 `auth_bridge_scope_refused` 是否归零。
+
+9. **web-admin 断言令牌的两键与主凭证同一只判官:`SEMA_WEB_ADMIN_ASSERTION_TOKEN` 与 `SEMA_WEB_ADMIN_ASSERTION_TOKEN_FILE` 都设 ⇒ 拒启;值键进本服务自有凭据的扣留名单,宿主子进程环境里不再有它(安全轴;行为变更:一条新拒启;wire 加性:`GET /health` 的 `center.assertionToken`、配置目录两行;部署零动作,除非两键都设)**:
+    旧形:本服务不读这一对键 —— 两键都设照常起服;值键不在配置目录里,`all` 继承的宿主子进程(容器 / 设备 CLI)拿得到它的值。
+    新形:接了中心(`SEMA_WEB_ADMIN_URL`)时按主凭证同一条二选一读这一对键(两键都设 ⇒ 拒启,拒句点名两键、不回显值);只读声明,不读文件内容、不向中心出示;`GET /health` 的 `center.assertionToken` 答 `declared` / `absent`,起服日志一行 `center_assertion_token`;值键是本服务自有凭据,子进程环境里扣掉。
+    谁需要:编排器与运维核受管引擎拿没拿到断言令牌;web-admin 生命周期事件的消费半(以它鉴权)。**谁受伤**:两键都设的部署(升级即拒启);在 `all` 继承的宿主子进程里读这只变量的脚本。
+    补偿:两键只留一个(编排器注入值键;手接引擎用文件键);子进程要的凭据经部署自己的按名放回通道给。
+    **升级前自查**(一行):`env | grep -cE '^SEMA_WEB_ADMIN_ASSERTION_TOKEN(_FILE)?=.'` 等于 2(两键都有非空值)的引擎,升级前删掉其中一个。
+
+10. **写门问请求:只接了鉴权桥、没配 service 凭据的部署上,出示已验登录令牌的计费提交 / 改写门 / 破坏性会话写受理;没带过门凭据的请求照旧 503 `auth.service_token_required`,拒句改述(行为变更;安全轴不松;零新码、零旋钮)**:
+    旧形:fail-closed 写门只看部署配没配 `SERVICE_AUTH_TOKEN(S)` —— 没配就对每一个请求 503,哪怕请求带着鉴权桥验过的登录令牌;拒句「this worker requires a service auth token (set SERVICE_AUTH_TOKEN) before accepting …」。
+    新形:写门看这次请求 —— 带着 service 凭据或鉴权桥验过的登记中心登录令牌就过(直连门审批 principal 令牌不算),否则 503(`ALLOW_UNAUTHED_WRITES=true` 照旧放行;配了 service 凭据的部署上这样的请求照旧先吃全局凭据门的 401);拒句「this worker requires a service auth token (set SERVICE_AUTH_TOKEN) or a verified registry sign-in token before accepting …」。只接了鉴权桥的部署上,这类受理的 run 行 `source` 是 `sso`。全局凭据门不变(仍只由 service 凭据武装);没接任何过门来源的部署(零凭据 / 只开 `REQUIRE_PRINCIPAL` / 只配 trace 凭据 / 只开直连门)行为不变。
+    谁需要:用登记中心登录令牌认人、不配 service token 的部署。**谁受伤**:把这一码读成「worker 没配 service token」的告警脚本(只接鉴权桥的部署上它不再对已验调用方出现);按字面匹配旧拒句的消费方。
+    补偿:按码分支(码与状态不变);部署收哪几类凭据读 `GET /health` 的 `auth.kinds`(含 `sso` ⇒ 已验登录令牌过写门)。
+    **升级前自查**(一行):部署 env 里 `SERVICE_AUTH_TOKEN` / `SERVICE_AUTH_TOKENS` 都没值、而 `AUTH_BRIDGE_ISSUER` 或 `SEMA_WEB_ADMIN_URL` 有值 ⇒ 本条对它生效:先核告警 / 健康脚本有没有把 503 `auth.service_token_required` 当「没配 service token」用,改成按 `GET /health` 的 `auth.kinds` 判。
+
+11. **🔴 bake-runner 的 bearer `BAKE_RUNNER_TOKEN` 是本包的自有凭据:`BAKE_ENV_ALLOW` 点到它或装着同一个值的另一个变量 ⇒ bake-runner 拒启;名单型旋钮的原文不再被当凭据值比(短名单的假警消失)(安全轴,fail-closed;行为收紧 + 告警订正;wire 零变化;部署零动作,除非 `BAKE_ENV_ALLOW` 点着 runner 令牌)**:
+    射程:bake-runner 进程(`BAKE_ENV_ALLOW`、它起的每一只子进程组);服务进程与 `run-local` 里装着 `BAKE_RUNNER_TOKEN` 的部署(与 bake-runner 同机、共用一份 env 文件);配了名单型旋钮(`LSP_ENV_ALLOW` / `HOOK_ENV_ALLOW` / 三只沙箱名单)的部署。
+    旧形:自有凭据声明只从配置目录派生,`BAKE_RUNNER_TOKEN` 不是目录行 ⇒ 缺省只靠形状剥不交给配方脚本,`BAKE_ENV_ALLOW=BAKE_RUNNER_TOKEN` 照解析、照放回给 `build.sh` 与主机命令,同值换名的副本照交;名单型旋钮的原文被当一枚凭据交引擎比值 ⇒ 不足 8 字符的名单(如 `LSP_ENV_ALLOW=GOPATH`)起服一行 `own_credential_value_not_withheld`、值能力位 `inherit_env.own_credential_values_withheld` 答 false。
+    新形:`BAKE_RUNNER_TOKEN` 与配置目录的 secret 行在同一份自有凭据声明里(三个进程同一份),按名与按值扣 ⇒ `BAKE_ENV_ALLOW` 点到它,或点到值等于它的另一个变量 ⇒ 拒启,`bake_runner_fatal` 一行 `env BAKE_ENV_ALLOW: entry #k of n is this deployment's own credential — …`(与点名别的自有凭据同一个开头,不回显值);任何子进程组都拿不到它与它的副本(副本那一半只对引擎收作凭据的值成立:短令牌 / 占位词只按名扣,见本段末句)。服务进程里装着它时同样不进模型驱动 shell(`inheritEnv:"all"`),五只服务侧名单点到它拒启,请求 `settings.env` 带这个键 ⇒ `400 request.env_credential_refused`(升级前停驻、存体里带这一键的任务续跑时由既有的一次性迁移窗剥掉照续,窗关之后同拒)。名单型旋钮原文只按名扣(旋钮变量照旧不进任何子进程),不再交引擎比值 ⇒ 短名单不再告警、值能力位如实;另一个名下装着同一串名单原文的变量不再被扣;名单型旋钮变量若被某条模型条目的 `apiKeyEnv` 指着(被当成密钥读),它的值照旧按凭据扣。runner 令牌不足 8 字符或是占位词 ⇒ bake-runner 起服多一行 `own_credential_value_not_withheld { name: "BAKE_RUNNER_TOKEN" }`(名照扣、不拒启)。
+    **谁需要**:跑 bake-runner 且配了 `BAKE_ENV_ALLOW` 的部署(runner 令牌不再能被放回配方脚本);配了短值名单型旋钮、被假警与 false 位困扰的部署。
+    **谁受伤**:`BAKE_ENV_ALLOW` 里写了 `BAKE_RUNNER_TOKEN`,或写了一个值与 runner 令牌相同的变量的部署(拒启);服务进程环境里也放着 runner 令牌、并让模型 shell / 名单 / `settings.env` 用到它的部署;按 `own_credential_value_not_withheld { name: "<名单型旋钮>" }` 计数的告警(这一形不再出现)。
+    **升级前自查**(一行):`BAKE_ENV_ALLOW` 不点 `BAKE_RUNNER_TOKEN`、不点与它同值的变量。**出路**:配方脚本要一枚凭据 ⇒ 给它铸一把自己的(名与值都不同于 runner 令牌)再点那个名;配方本来不读 runner 令牌,删掉那一段即可。**回滚**:回到上一版即回到旧形;零配置、零存储形变化。
+
+12. **`cascade: true` 与 `rewindFilesTo` 同体的新提交在受理口答 `400 request.field_conflict`(`reason: "cascade_verify"`,`fields: ["rewindFilesTo","cascade"]`),此前受理(`POST /v1/tasks` 答 `200`、`POST /v1/runs` 答 `202`)而文件回退无处落地(行为收紧;wire 加性一面:状态 2xx → 400;部署零动作)**:
+    射程:`POST /v1/tasks`、`POST /v1/runs` 上,体里同时带 `cascade: true` 与非空串 `rewindFilesTo` 的**新提交**。`POST /v1/tasks/stream` 上带 `cascade` 的提交本来就答 400(同码);`verify: true` 与 `rewindFilesTo` 同体照旧受理(验证门的实现腿跑在提交的那只会话上);空串 `rewindFilesTo` 不是回退请求,不算同体。续跑腿一字不变(续跑重建本来就把 `rewindFilesTo` 整族剥掉)。
+    旧形:同体提交被受理,梯子起跑 —— 梯级每一级在引擎现铸的会话里跑、不带提交的那只会话,这只会话的历史不在梯级手里,文件回退无处落地;引擎视版本要么拒掉梯级,要么丢掉这一键、梯子照常跑完(后一种下场里调用方以为文件回到了旧边界,实际没有,也没有信号)。
+    新形:受理时 `400`,体根上 `{ reason: "cascade_verify", fields: ["rewindFilesTo", "cascade"] }`,句子 `rewindFilesTo is not supported with cascade (every rung starts a fresh session, so there is no history to restore files from)`;拒在任何副作用之前:不铸会话、不建 run 行、梯子一级都不起。未配梯子的部署上,同体提交(三口都算,含 `POST /v1/tasks/stream`)此前答 `400 request.precondition_unmet`,现在先答本拒(与 `resumeAt` × `cascade` 同序:请求形的冲突先于部署事实)。配了梯子的部署上,`POST /v1/tasks/stream` 上同体提交的 `400` 体根上 `fields` 由 `["cascade"]` 变 `["rewindFilesTo","cascade"]`,码与状态不变。
+    **谁需要**:用 `cascade` 提交、同时想让文件回到某条旧提问边界的调用方 —— 现在当场知道这一发做不到。**谁受伤**:同体提交者(此前 `200` / `202`,现在 `400`)。**出路**:去掉其一 —— 不要梯子就去掉 `cascade`,不要回退就去掉 `rewindFilesTo`;要先把文件回到旧边界再起梯子的,能力位 `sessionRewindFiles` 为真的部署上先走 run 外口 `POST /v1/sessions/:id/rewind-files`,再提交梯子。
+    **升级前做**:无(零配置、零存储形变化)。**回滚**:回到上一版即回到旧形(同体提交重新被受理);无存储形变化。
+
+13. **续跑重放过现入口地板:`AUTONOMY=plan` 的部署上,停驻 run 被续跑之前体上的权限模式词照此刻的地板钳 —— 提交之后才改成 plan 的部署,与 7.121.x 及以前写下的停驻行,`bypassPermissions` / `auto` / `dontAsk` / 无词在下一次续跑钳成 `plan`;`plan_review` 批准写下的 `default` / `acceptEdits` 原样(安全轴,失效关闭;行为变更;wire 零新键、零新码;部署零动作)**:
+    旧形(7.122.0 起):`AUTONOMY=plan` 只在受理时盖进提交体,热改 / 重启时改档只影响之后提交的任务;停驻 run 的续跑(`/decide` · `/resume` · `/wake` · `plan_review`)照体里写下的词跑。7.150.0 上,7.121.x 及以前写下、体里是请求原词的停驻行同样按原词续跑。
+    新形:续跑之前体上的词过与受理同一只入口一步、读此刻的 `AUTONOMY`;被钳 = 钳到 `plan` 放行(不拒),钳过的词随续跑写回、之后照它读;那一腿的生效词看 `wiring_manifest.permissionMode`(钳制通告 `permission.entry_mode_clamped` 只在受理门发)。被钳进 plan 的 run 下一拍在 plan 里:写撞 plan 门,模型交计划后经 `plan_review` 批准出 plan(`permissionModeAfter` 照收)。体顶层写着地板的出口词(`default` / `acceptEdits`,批准写回只写顶层)⇒ 原样 —— 批过的计划不会被拉回 plan;只在 bundle `settings.permissions.defaultMode` 里的同字词照钳。
+    谁需要:设了(或事后改成)`AUTONOMY=plan`、有存量停驻 run 的运营者。**谁受伤**:改严之前以 `bypassPermissions` / `auto` / `dontAsk` 或不带词提交、此刻停驻的 run —— 续跑不再按原词放行,改在 plan 里继续;依赖「热改只影响之后提交的任务」的 HTTP 车道运维流程。leader 车道不变:那条车道的入口在 leader run 出生时读一次地板,停驻的 leader worker 续跑照写下的体重放(与 7.150.0 同读)。
+    补偿:不新增旋钮。要某条 run 按原词走完 ⇒ 改严之前把它决完 / 取消,或暂时改回原档位;leader 车道在飞的 run(含停驻的 worker)照出生时的词走完;要它们也停 ⇒ 取消那条 leader run。顶层的 `default` / `acceptEdits` 与批准写回同字、读不出是谁写的,照原样续跑;要它们也收紧 ⇒ `AUTONOMY=read-only`(按段只读)。回滚(本版 → 7.150.0):被钳过的行体词是 `plan`,7.150.0 照它读(仍在 plan 里,经 `plan_review` 出口),零动作。
+
+14. **被拒的提交不再把它的工作目录、shell 环境、继承策略留在会话上(行为修复;wire 零变化;嵌入方 `ServiceDeps` 一键换名;部署零动作)**:
+    旧形:请求带的 `cwd`(或从项目登记簿继承来的第一条 `folder`)与 `settings.env` 在装配的第二步就登记到会话上;之后才被拒的提交(未知 / 不可用的历史锚、设置编译 422、会话被占 409、建行 409、执行放置拒、引擎在受理输入之前的拒 …)把它们留下,同一会话下一条不带 `cwd` 的提交在被拒那一条的目录里、带着它的 shell 变量跑。7.150.0 节「项目上下文继承」一条把继承来的 folder 这一半列为已知限制,本版起不再成立。
+    新形:三格(工作目录 · shell 环境 · `inheritEnv`)只在 run 认领之后、起跑之前写一次,工作目录写的是这条腿跑在的那一枚(请求带的 ?? 继承来的 ?? 会话上已登记的 —— 与它装配期的 hooks / 写门基准同一枚);写了之后引擎没有受理这次输入就收场的提交,在终局应答之前撤回这一笔(只抽掉这一笔,别的提交的写原样)。拒的码、句、状态、机读位逐字不变。
+    **谁受伤**:按「被拒的那一条也登记了 cwd」写过逻辑的客户端(每条提交照常带 `cwd` 即不受影响);自建 `ServiceDeps` 并传 `bindSessionInheritEnv` 的嵌入方 —— 该键退役(零别名),换成 `sessionBindings`(写一笔、按回执撤回或落定一笔的写座;缺席 = 没有登记簿,与旧键缺席同义)。
+    **升级前做**:无。**回滚**:回到 7.150.x 即回到旧形;登记簿是每副本进程内的,不涉及存储形。
+
+15. **`config.d/remote-exec.json` 选定 host / local-docker 车道时,env 里同一车道的参数不再被无声丢弃:块 = env 读数 ∪ 文件格,同名格文件赢,文件与 env 在同一格上给了不同的值 ⇒ 一行 warn `remote_exec_file_overrides` 点名那一格的 env 键(行为变更:此前无声不生效的旋钮开始生效;wire 零新键、零新码;部署零动作,除非文件选车道的机器上设着本车道的 env 旋钮)**:
+    旧形(≤ 7.150.x):文件在场即终结车道选择,而文件腿只用文件里的格铸块 —— local-docker 只取 `image` / `mountPath`(或 `workdir`)/ `memory` / `cpus` / `network`,host 只取 `workdir` / `commandTimeoutMs`。env 里同一车道的其余参数(`DOCKER_MAX_CONTAINERS` · `DOCKER_PIDS_LIMIT` · `DOCKER_DROP_CAPS` · `DOCKER_COMMAND_TIMEOUT_MS` · `DOCKER_SANDBOX_ENV` · `DOCKER_PATH` · `DOCKER_HOST`、`HOST_COMMAND_TIMEOUT_MS`)不进块、不报:设了容器帽或 pids 限额,日志里一个字都没有,运行期无效。
+    新形:文件只定「哪条车道」。最终车道是 host / local-docker 时,块 = 该车道的 env 读数 ∪ 文件格,同名格文件赢(`image` ↔ `DOCKER_IMAGE`、`mountPath`|`workdir` ↔ `DOCKER_MOUNT_PATH`、`memory` ↔ `DOCKER_MEMORY`、`cpus` ↔ `DOCKER_CPUS`、`network` ↔ `DOCKER_NETWORK`;host:`workdir` ↔ `HOST_WORKSPACE_BASE`、`commandTimeoutMs` ↔ `HOST_COMMAND_TIMEOUT_MS`)。文件与 env 在同一格上给了**不同**的值 ⇒ 文件赢,运维日志一行 warn `remote_exec_file_overrides { provider, root, keys, note }` 点名被盖的 env 键(只点键名、不印值);同值复述、env 没设的格 ⇒ 零行。env 读数与 env 声明路径是同一只读者:同一条车道上坏值的处理与 `REMOTE_EXEC=local-docker` 逐句相同(容器帽小数 / 名单形错 ⇒ 拒启;`DOCKER_PIDS_LIMIT` 一类软旋钮的坏值 ⇒ warn 后回默认)。本步不为没被选中的车道读 env(文件选 `none` 或隔离车道时不求值 `DOCKER_*` / `HOST_*`;`REMOTE_EXEC` 声明的车道照旧在加载配置时求值,早于文件,那里的拒启不变)。`remote_exec_from_file` 与 `remote_exec_lane_preempted_by_file` 两行不变。
+    谁需要:用 `config.d/remote-exec.json` 选车道、又靠 env 调车道参数的 turnkey / 单用户部署。**谁受伤**:① 设了本车道 env 旋钮而一直被文件盖掉的部署 —— 升级后它们生效:容器帽满了新容器被拒(工具调用拿到 `limit.rate_exceeded` · `sandbox_capacity`),pids 限额与丢全部 capability 收紧沙箱,单命令超时生效,`DOCKER_HOST` 指向的守护进程被用;② 这些旋钮里有坏值而此前因不求值起得来的部署 —— 现在硬拒的坏值拒启、软旋钮 warn;③ 被文件换了车道之后环境里还残留旧车道之外的 `DOCKER_*` / `HOST_*` 的部署 —— 同样按最终车道读。
+    补偿 / 出路:升级前在文件选车道的机器上 `env | grep -E '^(DOCKER|HOST)_'` 自查;不要某只旋钮生效 ⇒ 从 env 去掉那个键;要 env 的值生效 ⇒ 删文件里同名的可选格(`image` 是文件里的必填格,只能改值)或让两处同值(同值不报);覆盖行点名的就是文件盖掉的 env 键。回滚(本版 → ≤ 7.150.x):旋钮重新被文件腿无声丢弃,回滚前先确认没有靠这些 env 旋钮兜底的安全限额。
+
+16. **host 车道的工作区座只锚不折、托管判按内核答:`HOST_WORKSPACE_BASE`、请求的 `cwd`、委派给子代的工作目录里写的 `..` / `.` 不再先按字面折叠,由文件系统解(行为变更;wire 零变化;部署零动作,除非工作区座里写了 `..` / `.` 段)**:
+    射程:`REMOTE_EXEC=host` 的部署。工作区座 = 起服时的 `HOST_WORKSPACE_BASE`、单用户 host 部署上请求带的 `cwd`、委派子代沿用的父工作目录。
+    旧形:构造工作区时这三只座先按字面折叠(`<D>/bridge/../next` 读成 `<D>/next`,不管 `bridge` 是不是指到别处的链接);委派子代的目录落没落在父铸的临时根里,先按字面比、再按「先折后 realpath」比 —— 经链接 + `..` 拼进根里的子代目录可能被判成调用方自有目录(父收场时那只根被删),拼到根外的又可能被判成共持。
+    新形:座按写的原样(相对的锚在服务进程工作目录上),`..` 在走过链接之后由文件系统解 —— 与执行环境方法读路径同一种读法;托管判只按内核的 realpath。座是规整绝对路径(没有 `..` / `.` 段、没有重复或尾随分隔符)的部署,读到的工作区一字不变;win32 的盘相对座(`C:work`)照旧锚在那只盘的工作目录下。
+    **谁需要**:host 车道上委派后台子代、子代停驻在审批上等人批准后续跑的部署。**谁受伤**:工作区座写了 `..` / `.` 段、中间经过符号链接、依赖字面折叠落在字面那一只目录的部署 —— 现在落在链接那一边;座写了尾随分隔符 / 重复分隔符 / `.` 段的,交回的工作目录按原样带着这些字符;本机语言服务器找项目根那一步仍按字面折,这类座上可能选到字面孪生那一边的项目。
+    **升级前做**:自查 `HOST_WORKSPACE_BASE` 与调用方送的 `cwd` 里有没有 `..` / `.` 段;有就改写成要的那只目录的规整绝对路径(`realpath <座>` 的答案)。**回滚**:回到 7.150.x 即回到字面折叠;无存储形变化。
+
+17. **远端执行车道:执行环境记住的拒改拼引擎可重试表之外的码(`env.*` 族加四码),会自愈的三形改拼可重试码;`connect` 幂等(行为变更;wire:错误码目录加四码、续跑腿恢复失败记录的 `code` / `retryable` 换;零新键;无 DDL、无迁移步;部署零动作,按码告警的运维改告警)**:
+    旧形(≤ 7.150.x):一只执行环境此后每次连接都答同一句的拒(k8s 快照桶不在、快照归档在桶里却取不回、集群在准入时拒了 pod、成员凭据中继建不起来、会话行不带住客令牌;k8s / e2b / local-docker 工作区填充的立定拒;k8s / e2b / local-docker / adb 环境答了自己的 `$HOME` 而与主张不符;ssh 主机密钥过不了钉的判)码都是 `connect_failed`;k8s 建 pod 撞配额(403 `exceeded quota`)与 adb 设备在重启 / 刷机途中的态是 `auth_failed`。已连的 k8s / adb / device 环境上再显式 `connect` ⇒ 第二只 pod / 再握手一遍 / 再准入一遍。
+    新形:立定的拒依次是 `env.snapshot_bucket_missing` / `env.sandbox_refused`(归档取不回、准入拒、中继建不起、填充立定拒)/ `env.occupant_missing` / `env.home_unconfirmed`(与 host 车道同一码)/ `env.host_key_rejected`,拒句逐字不变(只一处例外:会话行不带住客令牌那一形的拒句改点名它自己的出路 —— 给行补令牌或删会话);配额 403 与 adb 的 `bootloader` / `recovery` / `sideload` / `rescue` / `connecting` / `authorizing` 是 `connect_failed`(车道在自己的重试界内再试);device 生命周期面的 `device.claim_conflict` 是 `connect_failed`。已连的环境上再 `connect` 答当下的把手、什么都不建。从快照恢复的续跑腿遇上立定的拒:引擎不再重试这次恢复,失败记录 `remoteEnvFailures[].code` 是 `env.*` 码、`retryable: false`、`attempts: 1`;终局码仍是 `resume.env_failed`。ssh 主机密钥被拒:每只环境握手一次(此前每次操作重试满 `retry.maxAttempts` 轮)。
+    **谁需要**:接引擎准备期建立座的部署(引擎按可重试表判「立定」:不改拼,桶缺的 run 照起、每个工具都撞同一拒,配额 403 的 run 永远拒开,每个委派子代多一只 pod);读 `remoteEnvFailures[].retryable` 决定要不要再续跑的端。**谁受伤**:按 `connect_failed` 告警桶缺 / 准入拒 / 恢复不回 / 家目录不符 / 主机密钥不符的运维;按 `auth_failed` 告警配额 403 的运维;把 `remoteEnvFailures[].code` 当引擎词表闭集读的端。
+    **补偿 / 出路**:告警改按新码(或按拒句 —— 除上面那一处例外句子逐字不变,按 `snapshot_bucket_missing` / `SysctlForbidden` / `fingerprint mismatch` 之类的字面 grep 照旧命中);`env.*` 一族全部 deterministic、同步提交腿 409,出路在拒句里。没有新旋钮。
+    **升级**:段头升级清单就是全部动作,可滚动。**回滚**(本版 → 7.150.x):码回到旧拼法,零存储形变化。
+
+18. **沙箱 / adb / 设备车道上的 path 附件附上内容;设备执行器可以实现一条新指令 `openBound`(行为变更,放宽;设备协议修订号 5 → 6,受理下沿仍 5;部署零动作)**:
+    射程:`REMOTE_EXEC` 为 e2b / k8s / local-docker / adb / device 的部署上(ssh 本版不变,见下),提交体 `userAttachments` 的 `{ path }` 条目。
+    旧形:这些车道上 path 条目照收,结局恒 `not_attached`(帧注 "cannot bind a read")。
+    新形:e2b / k8s / local-docker / adb 四条远端车道每一次读都重新打开并向目标的内核核对仍是判过的那只对象,对上了才附上内容;Linux 以外的远端目标、没挂 `/proc` 或缺 `timeout` / `readlink` / `stat` / `head` / `base64` 的目标照旧 `not_attached`。设备车道:执行器声明修订号 ≥ 6(`hello.protocolVersion`)**且**在 `hello.supports` 声明 `openBound` 才附上 —— 声明修订号 5 的执行器照旧受理,只是收不到这条指令、这一面缺席(四个 `op`、结局形与拒法见协议文档 §3.7;错误码只用你声明的修订号已有的词);**不要**用 `fileInfo` + `readBinaryFile` 仿真它 —— 不实现 ⇒ 该设备上 path 附件照旧不附。
+    **谁需要**:云上沙箱、adb 与设备部署上带 path 附件的会话。**谁受伤**:这些车道上 path 附件的内容进第一次请求 —— 带一批大文件的提交可能被整席拒「超出一次请求」(与 `host` 同律);每条附件多 2–3 次往返;读到一半变了大小的文件被拒;目录里有名字带换行的条目 ⇒ 这只目录列不出(整答拒)。
+    **ssh 车道本版不装绑定读(不变)**:ssh 部署上 path 附件照旧 `not_attached`。原因:ssh 目标可以是给不出那一次核对的 macOS / BSD 机器,这一面在场就答 `not_supported`,而 core 7.66.0 的计划文件读口把它当成读不了 —— 装上它,那类部署的计划模式会读不出计划文件。修在 core 一侧,随 core 7.68.0 到货后 server 下一版装回;本版部署零动作。
+    **出路**:少附、附小一点,或让模型自己用 Read 读;非 Linux 目标与 ssh 车道照旧。**升级前做**:无(零配置、零存储形变化)。**回滚**:回到上一版即回到旧形(path 条目恒 `not_attached`);无存储形变化;实现了修订号 6 的设备执行器对上一版按它 challenge 里的修订号声明 5,照旧受理。
+
+19. **后台 run 里同步委派子代的问不再停驻(随引擎 7.66.1);7.150.x 期间已停驻下的子代问题卡决不了,可忽略、到期收走(行为修复;持久数据面:存量行不迁移、不改写;wire 零新键、零新码;部署零动作)**:
+    旧形(7.150.x,执行车道挂着 shell 或带出网工具的部署):`POST /v1/runs` 里父模型派 `Agent{run_in_background:false}`、子代问 AskUserQuestion、窗走完没人答 ⇒ 子代停驻,父收「status: suspended」,`GET /v1/approvals` 多一行子代的问题卡,对它 decide 带答或拒都答 409 `conflict.resume_context_unavailable`、行留着。
+    新形:同一构造子代读引擎的拒(`isError` + `notExecuted`)、接着跑,零新行;父 run 拿到子代真跑完的报告。父腿自己的问、连着的流上的同步子代、不可逆 / 出网调用的停驻都不变。
+    **存量行**:7.150.x 上停驻下的这类行 —— `toolName: "AskUserQuestion"`、`gateKind: "irreversible_ask"`、`taskId: null`、`sessionId` 是子代会话(不是任何一条 run 的会话)—— 没有续跑座,升级后仍决不了(带答 / 拒都 409、行不消);子代那一步早已随父 run 收场结束,被问的动作从未执行。它们可安全忽略:到行上的 `deadline`(建行 + 30 天,无人值守缺省)由检查点店的过期收割收走(既有收割器;`APPROVAL_TERMINAL_BACKSTOP_MS` 兜底同窗);不必手工删。
+    **谁需要** / **谁受伤** / **补偿**:同 CHANGELOG 本版同名一条(零新旋钮)。**升级前做**:无。**回滚**:回到 7.150.x ⇒ 挂 shell / 出网工具部署上的同步子代问重新停驻成决不了的卡(新停驻;已有的行两版同读)。
+
+20. **随包 helm 图表不再替部署派生 `OPERATOR_SINGLE_USER`:单用户声明是显式 values 键 `server.operatorSingleUser`(布尔),它与 `server.requirePrincipal` 都没设 ⇒ 渲染即拒;`server.requirePrincipal` 缺省由 `"false"` 改为不设,图表只读它设没设、不再判词(部署面 BREAKING;安全轴收紧;图表 0.4.0 → 0.5.0;零服务端代码、零 wire;直接 `helm` 的部署升级前补一行 values,经 `sema-up` 装的部署零动作)**:
+    旧形(7.147.0–7.150.x):图表从 `server.requirePrincipal` 派生 `OPERATOR_SINGLE_USER`(未开 ⇒ `"true"`,开 ⇒ `"false"`),而 `requirePrincipal` 缺省 `"false"` ⇒ 什么都不写的 values 渲出「每个调用方都是运维」;`requirePrincipal` 只认 `"true"` / `"false"` 两词。服务端拒句里「不止一个人调用 ⇒ 设 `REQUIRE_PRINCIPAL=true`」那一道人判,对用图表的人永远不出现(MIGRATION 7.147.0 节第 3 条「谁受伤」③ 的形,图表绕过了拒句):忘设 `requirePrincipal` 的团队集群 `helm upgrade` 之后每个调用方成运维 —— 运维 / 记忆治理 / diagnostics / outcomes / 跨属主审批队列由 7.146.x 的人人 501 变人人可用。
+    新形:「谁是运维」是部署写的声明,图表不替它写 ——
+    · values 多一把显式键 `server.operatorSingleUser`(布尔 `true` / `false`;不设 ⇒ 不渲 `OPERATOR_SINGLE_USER`;设了 ⇒ 逐字渲给主 worker 与 v4pro 变体);字符串(含 `"false"`:模板里字符串恒为真)渲染即拒并点名那个值;
+    · `server.operatorSingleUser` 与 `server.requirePrincipal` 都没设 ⇒ `helm template` / `install` / `upgrade` 渲染即拒,拒句取服务端拒句的两条出路:一个人用 ⇒ `server.operatorSingleUser=true`;被不止一个人调用 ⇒ `server.requirePrincipal=true`;不静默二选一;
+    · `server.requirePrincipal` 缺省不再是 `"false"`:值原样渲给 `REQUIRE_PRINCIPAL`(没设仍渲服务端缺省 `"false"`),图表不再判它的词 —— `yes` / `1` / `on` 不再被图表拒,原样交服务端读;`operatorSingleUser=true` 与 `requirePrincipal=true` 同写才互斥,仍由服务端起服拒(不变量 `operator-single-user`),图表不抄那一判;`operatorSingleUser=false` 逐字渲(服务端读 `false` 与缺席同判),给自己 env 补了具名运维名单 `OPERATOR_PRINCIPALS` 的部署用它表态「我不声明单人」;
+    · `sema-up` 的 kube 两条 helm 路径(`kube-up` 与 `STACK_ENGINE=helm` 的 `cluster-up`)按 `--users` 把 `operatorSingleUser` 写进它生成的 values(single ⇒ `true`、multi ⇒ `false`):经 `sema-up` 装的部署渲出的 `OPERATOR_SINGLE_USER` 与上一版逐字相同,重跑 `sema-up` 即落新图表;compose 路径与 cluster 静态清单路径不变。
+    谁需要:被不止一个人调用的团队集群 —— 忘设租户词不再静默变成人人运维;一切直接 `helm` 的部署 —— 声明归部署。谁受伤:① 直接 `helm upgrade` 且没设 `server.requirePrincipal` 的单人部署:升级即渲染拒,补一行 `server.operatorSingleUser=true`(或命令行 `--set`);② values 里已有显式 `server.requirePrincipal: "false"`(手写的,或沿用上一次 release 值而带进来的)而没有新键的部署:渲染通过,但不再渲 `OPERATOR_SINGLE_USER`,单人 worker 起服拒(服务端拒句即出路),滚动更新停在第一只新 pod;钥匙卷是 `ReadWriteOnce` 时 Deployment 用 `Recreate` 策略,旧 pod 先停 ⇒ 补上这一键之前没有副本 —— 升级前先 `helm template` 同一份 values;③ 把 `server.requirePrincipal` 写成 `yes` / `1` / `on` 的部署:上一版渲染拒,本版放行并交服务端读成多租;④ 对着渲出清单做 diff 的工具:直接 `helm` 的多租部署的 `OPERATOR_SINGLE_USER` 由 `"false"` 变成缺席(服务端读 `false` 与缺席同判);经 `sema-up` 装的不变。补偿:渲染时的拒句就是出路,一行 values;经 `sema-up` 装的部署零动作。升级前做:直接 `helm` 的部署在 values 里加一行(单人 `server.operatorSingleUser: true`,多人 `server.requirePrincipal: true`),先 `helm template` 同一份 values 读结果(随包的 `values-full-single.yaml` 只是覆盖文件,示例命令行已带 `--set server.operatorSingleUser=true`,声明仍由你写)。回滚:回到上一版图表 ⇒ 仍从 `requirePrincipal` 派生,补的 `server.operatorSingleUser` 键上一版不读(无害);无持久数据。
+
+21. **勘误(7.147.0 起的行为,该节漏写一条):会话驻留的后台子代理单步静默超过停滞窗 `BG_AGENT_STALL_MS` 就被引擎收成 `killed`(归因 `system`)、run 中止 —— ≤ 7.146.x 从不收(行为变更:杀掉在跑的工作;旋钮 `BG_AGENT_STALL_MS` 只许拉大;wire 零新键、零新码;部署零动作,除非部署里有单步静默得比窗长的后台子代理;已发的 7.147.0 节不改字节)**:
+    旧形(≤ 7.146.x):任务表里一直是 `running` 的后台子代理没有人收 —— 它只在干完、被停止、或随引擎受控退时结束;一次再长的 MCP 调用、一次再长的前台嵌套委派,只要引擎活着就一直等。
+    新形(自 7.147.0 起):每一次读在飞数(判停的每一拍、`GET /health`、崩溃遗言)之前,引擎先把**最后一次工具活动**距今超过窗的会话驻留后台子代理收成 `killed`、归因 `system`,它的 run 中止,运维日志一行 `background_agent_stall_reaped { reaped, stallMs }`;停驻的、随腿的、终态的行不收;多租户形(`REQUIRE_PRINCIPAL=true`)没有会话驻留的后台子代理,收割恒 0 行。
+    窗的算法:缺省 = 下限 = `max(600 s, max(STREAM_ASK_WINDOW_MS, UNREACHED_ASK_TTL_MS, QUESTION_TTL_MS, MCP_ELICITATION_TTL_MS) + 单命令上限)`,单命令上限 = 引擎解析出的 Bash 单命令上限(缺省 600 s;`BASH_MAX_TIMEOUT_MS` 抬高它,`BASH_DEFAULT_TIMEOUT_MS` 抬到它之上时它跟着抬)。窗取**四个等人窗里最长的那个**加单命令上限 —— 只调小其中一个,窗只缩到次长的那个:单用户形缺省 24 h 10 min(活审批卡窗 24 h);把 `STREAM_ASK_WINDOW_MS` 调到 60 s,窗缩到 1 h 10 min 就停了(没人在场时铸的审批卡窗 `UNREACHED_ASK_TTL_MS` 缺省 1 h 成了最长的);四个窗都在 60 s 以内才缩到 11 min(`UNREACHED_ASK_TTL_MS` 下限 60 s,`QUESTION_TTL_MS` / `MCP_ELICITATION_TTL_MS` 下限 1 s,`STREAM_ASK_WINDOW_MS` 可到 0),这也是缺省单命令上限下窗的最小值(`UNREACHED_ASK_TTL_MS` 低于 60 s 拒启)。`BG_AGENT_STALL_MS` 只许拉大:写得比这个下限小(含 `0`)⇒ 钳到下限并起服 warn 点名,没有「关」这一档;`GET /v1/config/catalog` 的 `BG_AGENT_STALL_MS` 行回显此刻的生效值。
+    「静默」的算法:只按子代**直属**的工具开始 / 结束算,每一次一拍,引擎按墙钟量。在审批卡 / 问答卡上等人、一轮很长的模型输出、一条很长的工具调用,在窗内都只是静默;等人的窗盖在派生里,所以一次等人本身不会越窗 —— 越窗的是单步里别的东西。
+    **谁需要**:共用一只本机引擎的部署(壳退后引擎要为还在干活的后台子代理留着,又不能被一只僵尸子代理永远留着)。**谁受伤**:单步静默得比窗长的合法子代理 —— 一次长 MCP 调用(引擎对它的时限缺省约 27.8 h,调用中的进度通知不算一拍)、一次前台嵌套委派(子委派里的工具活动与等人都不给这一行打拍,整段对这一行是一次静默)、一轮极长的模型输出;墙钟前跳或整机睡眠超过窗,醒来第一次读就把睡前之后再没打拍的子代理收掉。缺省读数(单用户形 24 h 10 min)下只有极端的长调用够得着窗;把四个等人窗调小的部署,窗缩到分钟级,十来分钟的 MCP 调用或嵌套委派就被收:run 中止、行落 `killed`,那一步不会续跑。
+    **补偿 / 出路**:把 `BG_AGENT_STALL_MS` 拉大到比部署里最长的一步更长(只许拉大;不必动四个等人窗);要让僵尸收得更快才调小那四个等人窗(没开审批 / 问答的部署,它们本来不起作用)。被收的子代理的 run 已中止、不会自动重试:引擎只拒绝续用用户停止的行,`killed` / `system` 的行不在其内 —— 有耐久行的命名子代理(或会话保留着的)可由模型 `SendMessage` 续用,其余重新起一只。每次收了几只读运维日志 `background_agent_stall_reaped` 的 `reaped` 字段;`GET /health` 的 `inflightBreakdown.backgroundAgents` 是收完之后还在跑的数,不是收掉的数。**升级前做**:盘点部署里有没有静默得比窗长的后台 MCP 调用或嵌套委派,有就先拉大旋钮。**回滚**:回到 ≤ 7.146.x 即回到不收。
+
+22. **委派子代腿受中心按主体的收紧位约束:子腿与根腿问同一只按主体的运行期准入(安全轴收紧;行为变更;wire 零新键、零新码;部署零动作,接中心的部署见「升级前做」;第 19 条「新形」对被强制耐久门的主体不成立)**:
+    旧形(7.150.x 及以前,接中心且非 dry-run 的部署):中心按主体下发的运行期准入只在根腿生效;Agent 工具派的同步 / 后台子代、fork、复活的后台子代与观察者跑在另一只执行器上,那只执行器不问准入 —— 同一个主体在子腿上「不限」:fork 照起、强制耐久门不强制、观察者恒关;父腿跑着时中心收回的 bypass / auto 到不了此后派的子代;中心取数硬失败的 fail-closed 降级项(拒自编排 / fork / auto / bypass)到不了子腿。
+    新形:子腿与根腿问同一只准入,按同一个主体(子腿的主体从父腿继承)答 —— 中心对这个主体关掉的位在子腿上同样关;中心硬故障的降级窗里子腿同样拒;中心授予的观察者(或单用户部署 `EXPERIMENTAL_OBSERVER_AGENTS=true`)在子腿上也开。hook 子代理不变(服务自己的 run,不带主体)。没接中心或 dry-run 的部署上子腿只多本地合成层那几位(单用户 `EXPERIMENTAL_OBSERVER_AGENTS=true` ⇒ 子腿观察者开;`PERMISSIONS_DISABLE_AUTO_MODE=true` ⇒ 子腿 auto 拒;SQL 后端的记忆 opt-out 授权表每条子腿多读一次),都没开 ⇒ 零变化。leader 车道(`POST /v1/leader`)的执行器本版不在此列。
+    **谁需要** / **谁受伤** / **补偿**:同 CHANGELOG 本版同名一条(零新旋钮)。**升级前做**:盘点中心上对哪些主体关了 fork(`allowFork:false`)或开了强制耐久门(`forceDurableGate:true`):这些主体的子代此后同样被拒 fork、问按强制耐久门判(后台子代的问不先试连着的审批人、直接停驻,可 decide);⚠️ 被强制门的主体在持久审批部署上,**同步**子代没人答的问会停驻成一张决不了的卡(decide 409 `conflict.resume_context_unavailable`,到期收走)—— 这类主体让父腿自己问,或改派后台子代;要子代照旧,在中心给这个主体放开。**回滚**:回到 7.150.x ⇒ 子腿重新不问准入(上面「旧形」)。
+
 ## 7.150.0 —— 1–12 条见下
 
 **升级清单(本节唯一的一张;下面各条只讲为什么,不再各自重述升级步骤)** —— 一次读清本版对一只存量部署要做的全部动作。每版同形:① 手工 DDL(逐表逐句,两方言各一份)② 起服自建与一次性迁移 ③ 停-迁-起 ④ 顺序;后续每版的段头照此写,新增一句 `ALTER`、一条一次性迁移、一条停-迁-起时,先改这里,再写条目。