@sema-agent/server 7.149.0 → 7.151.0

package/MIGRATION.md

@@ -4,10 +4,309 @@
 > (内部多 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.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`、一条一次性迁移、一条停-迁-起时,先改这里,再写条目。
+已发各节(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`、一条一次性迁移、一条停-迁-起时,先改这里,再写条目。
@@ -5554,7 +5853,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 两包精确钉
 
@@ -7574,8 +7873,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 给凭据侧加了**值族表**,
@@ -7587,10 +7885,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 的「整组扣」让同组的
@@ -7610,7 +7908,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 配置文件。

package/README.md

@@ -210,7 +210,7 @@ The server is configured entirely through environment variables. The most import
 
 | Variable | Default | What it does |
 |----------|---------|--------------|
-| `PORT` | `8090` | HTTP listen port. `0` = let the OS pick one: the `listening` log line (stdout, info level) and `/health.port` report the port actually bound |
+| `PORT` | `8090` | HTTP listen port. `0` = let the OS pick one: the `listening` startup line (stdout, one JSON line at info level; a startup protocol line, not filtered by `LOG_LEVEL`) and `/health.port` report the port actually bound; the same line's `boundAddress` is the address the kernel actually bound |
 | `BIND_HOST` (alias `HOST`) | see note | Listen address. An explicit `BIND_HOST` **always wins**. Default: `127.0.0.1` when the write face is unauthenticated (`ALLOW_UNAUTHED_WRITES=true` **and** no service token configured), otherwise all interfaces — deployments with a token are unaffected. Since 3.15.0 the `HOST` alias is **not** fully equivalent: shells commonly set `HOST` to the machine name without the operator knowing, so when the narrowing condition above holds it wins over an inherited `HOST` (logged as `bind_host_from_HOST_env_overridden`). To expose the write face, configure a service token — on a single-user deployment (`REQUIRE_PRINCIPAL` off) an explicit non-loopback `BIND_HOST` with an unauthenticated write face refuses to boot (invariant `single-user-anonymous-boundary`); on a multi-tenant deployment an explicit `BIND_HOST` still exposes it. |
 | `MODEL_GATEWAY_BASEURL` | **no default** | OpenAI-compatible gateway base URL (without `/chat/completions`). **No factory default**: every route that rides the openai-compatible lane must resolve to an explicit endpoint — the model's own catalog `baseUrl`, or this knob — else the server refuses to boot, naming the models and printing the explicit local spelling (`MODEL_GATEWAY_BASEURL=http://127.0.0.1:8000/v1`). An Anthropic-only deployment may leave it unset. Setting `MODEL_GATEWAY_FALLBACK_URLS` without it is refused too |
 | `MODEL_ID` | **required unless a catalog supplies the default** | Default model id — **no factory default since 3.0.0**. Since 7.101.0 the check runs **after** the catalog is applied: `MODEL_ID` **or** a usable catalog default (`config.d/models.json` / the web-admin) is enough; with neither the server refuses to boot (`config.default_model_missing`, naming both ways out). A catalog that is adopted replaces the env model table, so `MODEL_ID` is then not served: the boot is not refused (even with no gateway, when the catalog entries carry their own `baseUrl`) and logs one `config_env_set_but_ineffective` line naming the catalog default that serves (exactly once, at the moment the catalog is first adopted — at boot, or later when it arrives after the boot fetch budget / on a refresh). The old baked-in default was an internal-only model name, so every external deployment failed later and further from the cause: a gateway `400` plus a cascade of title-hook warnings |

package/README.zh-CN.md

@@ -164,7 +164,7 @@ curl -s localhost:8090/v1/tasks -H "Authorization: Bearer <SERVICE_AUTH_TOKEN>"
 
 | 变量 | 默认 | 说明 |
 |------|------|------|
-| `PORT` | `8090` | HTTP 监听端口。`0` = 让 OS 分一个:`listening` 日志行(stdout,info 级)与 `/health.port` 报实际绑到的口 |
+| `PORT` | `8090` | HTTP 监听端口。`0` = 让 OS 分一个:`listening` 启动行(stdout 一行 JSON,info 级;启动协议行,不随 `LOG_LEVEL` 滤掉)与 `/health.port` 报实际绑到的口;同一行的 `boundAddress` 是内核实际绑上的地址 |
 | `BIND_HOST`(别名 `HOST`) | 见说明 | 监听地址。显式 `BIND_HOST` **恒生效**。缺省:写面无鉴权时(`ALLOW_UNAUTHED_WRITES=true` **且**未配任何 service token)= `127.0.0.1`,否则全接口——配了 token 的部署不受影响。自 3.15.0 起 `HOST` 别名**不再完全等效**:shell 常把 `HOST` 设成机器名而 operator 并不知情,于是上述收窄条件成立时,收窄压过继承来的 `HOST`(告警事件 `bind_host_from_HOST_env_overridden`)。要暴露写面,配一个 service token —— 单用户部署(`REQUIRE_PRINCIPAL` 未开)上写面无鉴权时显式非回环 `BIND_HOST` 起服拒(不变量 `single-user-anonymous-boundary`);多租部署上显式 `BIND_HOST` 照旧暴露。 |
 | `MODEL_GATEWAY_BASEURL` | **无缺省** | OpenAI 兼容网关地址(不带 `/chat/completions`)。**无出厂缺省**:每一条落 openai 兼容腿的路由都必须解析到显式端点 —— 目录条目自己的 `baseUrl`,或本键 —— 否则拒启,拒因点名模型并给出本机写法(`MODEL_GATEWAY_BASEURL=http://127.0.0.1:8000/v1`)。anthropic 单路由部署可不设。只设 `MODEL_GATEWAY_FALLBACK_URLS` 不设本键同拒 |
 | `MODEL_ID` | **必填(目录给出缺省时可省)** | 缺省模型 id ——**3.0.0 起无出厂缺省**。7.101.0 起判据挪到目录应用**之后**:`MODEL_ID` **或**目录里一条可用的缺省(`config.d/models.json` / 配置控制面)任一在场即可;两者皆无 = 拒启(码 `config.default_model_missing`,指路二选一)。目录一旦被采纳就整张换掉 env 表,`MODEL_ID` 此时不服务:起服不拒(目录条目自带 `baseUrl` 时没有网关也能起),并说一行 `config_env_set_but_ineffective` 点名在服务的目录缺省(目录第一次被采纳的那一拍恰好说一次 —— 启动时,或目录晚到 / 刷新时才第一次采纳)。旧的烤死缺省是内网模型名,外部部署必炸且炸在离根因最远处:网关 `400` + 标题 hook 连环告警 |