@sema-agent/client-core 0.96.0 → 0.97.1

package/CHANGELOG.md

@@ -49,6 +49,116 @@
 > 挡住 ⇒ 本批把它机械化——④a0 对 `pending` 行**要求段头已是日期形**(`(未发布)` 直接红),阶段一
 > commit 漏转在发布前就红,不再靠人记。
 
+## 0.97.1(2026-10-14)
+
+> 主题:代理工具清单只投这一跑里可能有工具应答的名(CC-729)· 本跑声明的 MCP 服务器读口与 run 级 `excludeTools` 判官(CC-730)。服务端 7.126.0(引擎 7.49.x)起,代理定义的 `tools` / `disallowedTools` 或 run 级 `excludeTools` 点名了一个这一跑里没有任何工具应答的名,整发请求在开跑前被拒(`config.agent.unknown_tool` / `config.tool_face_control`,原因 `unknown_name`);引擎 7.48 及以前只告不拒。
+
+### Fixed
+
+- **代理定义点名未声明的 MCP 服务器的工具时,每一发请求都被拒**(CC-729;接入文档 **§125 AD-1**):`tools` / `disallowedTools` 里的 `mcp__<server>…` 条目(含整服务器形 `mcp__<server>` 与 deny 的内容形)原样投进 `agents[].allowTools` / `denyTools`,服务器不在这一跑的声明里时引擎拒整发 —— 不带代理参数的请求也一样拒(代理定义随每一发上 wire)。现在宿主交了 `toolDirectory`(见下)时,服务器不在本跑声明里的条目省掉并披露一行(`agents wire: agent "<name>" <list> entry "<entry>" names no tool this deployment answers to — omitted: …`):deny 省掉 = 没有东西可藏,allow 省掉 = 没有东西可给,这一跑里任何一腿能用的工具都不变。声明了但没连上的服务器照投(引擎按声明受理,重连后它的工具真会出现)。allow 清单省到一条不剩时发 `allowTools: []`(什么都不给),不回落成缺席(缺席 = 继承全部工具)。宿主没交读数(或读数读不出)时照投,每条 `mcp__` 条目披露一行「could not be checked」。普通名与 `a2a__` 名不判、照投(引擎的全集还含它自己的整份工具目录与委派池,客户端在提交前没有这两份)。
+- **代理 `tools` 里的旧拼法 / 大小写孪生条目让每一发请求都被拒**(CC-729;**§125 AD-2**):引擎 7.49.0 起 allow 清单里没有工具应答的拼法(`Task` / `KillShell` / `bash`,或与已挂工具只差大小写)同样整发拒,而本包此前只告警照投。现在引擎工具名判官判得出的这几类 allow 条目省掉并披露(告警句改成「no tool answers to this entry; it is omitted」);判官判不出(值级端口没装)的照投、原告警不变;deny 侧的拼法问题仍由 `withholdRefusedDenyLists` 处置(省掉会放宽:`bash` 要藏的 `Bash` 真在)。拼法预判读数 `toolListFlaws` 不变。
+
+### Added
+
+- **`engineToolDirectoryOf(source)`**(CC-730;**§125 AD-3**):本跑声明的 MCP 服务器读口,三态 `not_landed` / `unreadable` / `{ state: 'directory', mcpServerPrefixes }`(前缀由引擎自己的命名函数铸出,冻结集;空集 = 本跑一只都不声明)。`source` 两半:`requestMcpServers`(本请求自带的 `mcpServers`)与 `deploymentMcpServers`(部署自己声明的服务器 —— `readMcpCapabilities` 读出的 `face.servers` 行可原样交;宿主自己起、没给它配 MCP 的引擎交 `[]`);任一半缺席 ⇒ `not_landed`。
+- **`excludeToolsAgainstDirectory(exclude, directory)`**(CC-730;**§125 AD-4**):run 级 `excludeTools` 的判官,返回 `{ send, omitted, verdict: 'directory_absent' | 'filtered', disclosure? }` —— 服务器不在本跑声明里的 `mcp__` 名省掉(排除一只挂不上的工具是无操作),别的一律照发;`exclude` 不是数组 ⇒ `TypeError`。本包不改请求装配口的 `excludeTools` 语义。
+- **`ProjectAgentsDeps.toolDirectory`**(可选;CC-729):`projectAgentsForWire` 读它做上面那条过滤;与 `excludeToolsAgainstDirectory` 交同一份读数。
+
+### Gates
+
+- 新门 1 道(包侧投影门三件:门 / gates-manifest 登记 / README Guards 行):`run-agents-wire-directory-test.mjs`(AD1 读口三态 · AD2 代理 × 读数在手 × deny / allow 逐形 · AD3 读数不在手照投 + 未核行 · AD4 空读数 · AD5 方向 · AD6 allow 侧拼法问题 · AD7 excludeTools 判官 · AD8 真 sdk 形正控 · AD9 公面 · AD10 与安装着的引擎判官逐条对拍:省掉 ⟺ 引擎答无应答拒)。公面运行期导出 1639 → 1641。
+- 负控套:影子豁免登记表 `entries` 为空时,「挑一行活行改判」的两枚负控(`layering-shadow-export-proof-wiring` / `layering-shadow-export-review-hash`)按 N/A 报进总结行(表上再有活行即自动恢复演练);表非空却挑不到合格行仍响亮抛。0.97.0 发布树上该表随终端 1.0.148 删尽同名声明后清空,这两枚曾因此中断整套。
+- `run-fleet-view-keys-test.mjs`:壳「声明了、包已不产」的两条过渡台账行(`FleetTask.queuedCount` / `FleetWorkflow.errorCode`)随终端 1.0.148 删掉声明与读臂后收账,两表回空(等值门 E1 / E3 点名;删行期限按成文 = 终端删掉声明之后的下一个本包版本)。
+
+## 0.97.0(2026-10-14)
+
+> 主题:清账 + 提货 —— 支持底线抬到服务端 7.126.0 / 引擎 7.49.5 / sdk 21.1.0(团队编排四键删、审批卡词 `approvalCard`、提交幂等码、终局失败详情四臂、`allowTools`、目录候选被整拒读口;引擎改名表退役)· 单一真源收口余项(CC-688 / 689 / 696 / 704 / 705)· 座位契约余项(CC-699 / 703)· 能力位(CC-690 / 692)· 中心配置告示句与影子 models 文档(CC-693 / 702 / 708 / 719)· 舰队账本(CC-700)· 决断拒收判官取位与抛出物读法(CC-706 / 709 / 712)· 审批已结一处存(CC-632 / 710)· 展示封长记号(CC-707)· 工具卡退化空卡(CC-697)· 传输失败分类读口(CC-698);两同义行(`projectEngineRuleNames` / `describePrintLaneAllowKept`)在终端删掉壳侧实现之后删行。
+
+### Removed
+
+- **Support for servers below 7.126.0 (engine below 7.49.5) and SDK below 21.1.0 is withdrawn**(CC-715;接入文档 **§124 PK-1**):支持底线三件同批抬到服务端 **7.126.0** / 引擎 **7.49.5** / sdk **21.1.0**,peer 地板 `>=20.0.0` → **`>=21.1.0`**。只为底线以下而存在的读法同批退役(下面三条)。
+- **引擎改名词的两代读法删除**(CC-715;退役登记 RL-123;**§124 PK-2**;🔴 型面 BREAKING:公面型 `ApprovalMandateWord` 少一员 `write_protection_unresolved`):支持范围内的服务端只发现名 `target_unresolved` / `config.path_view_unresolved`。旧词 / 旧码到达读成表外 —— 强制词读口答缺席、理由句落中性句;自动答判定对带旧词的强制卡答 `unknown`;放行原因落通用句;旧通告码不在码册、受众按 `operator`。本版早先那一条「理由句口也经改名表读」(**§124 WR-1**)随改名表一起收回(未发版,同版内改口)。
+- **根入口删除名 `ASK_PARK_GATE_KINDS`**(CC-715;退役登记 RL-135;**§124 PK-4**;🔴 型面 BREAKING,零别名):审批腿门种的手写副本。读成员表改读根入口转口的 sdk 常量 `APPROVAL_DECIDE_GATE_KINDS`;判「一行 / 一道门归哪只决断口」读 `durableDecideLegOf`。同名 `PLAN_REVIEW_GATE_KINDS` 仍在根入口,但现在就是 sdk 21.1.0 那一只(同值;型由 `readonly string[]` 收窄成 sdk 的字面元组 —— 以任意串调 `.includes` 的地方编译红,改读 `durableDecideLegOf`)。
+- **请求装配口的团队编排四键 `council` / `debate` / `rounds` / `lenses` 删除**(CC-715;退役登记 RL-134;**§124 PK-8**;🔴 型面 BREAKING):服务端 7.126.0 起对这四键答 `400 request.body_shape`(场景透传键只剩 `repo`)。入参型删这四键(带着它们的对象字面量编译红);运行期带着 ⇒ 装配期按不认识的键 `TypeError` 拒,不再上 wire。
+- **根入口删除名 `isFsApprovalGate`(0.97.0 退出公面)**(CC-696;退役登记 RL-129;接入文档 **§124 HT-1** / §2z;🔴 型面 BREAKING,根入口运行期导出 1629 → 1628):这只谓词的首行把门种位 `tool_approval` 当审批门、放行任意工具名 —— 那个词是审批门的 pending 种,不是门种,wire 的门种位上从不出现;它与待决行的「门种 → 耐久决断腿」一张表(`durableDecideLegOf`)回答同一问却前提不同。停驻门归哪条审批臂现在只有一条读法(见 `### Fixed` HT-2),公面读法 `isToolApprovalGate`;只问工具名是不是 fs 写用 `toolNameIsFsWrite`。🔴 硬破坏三句:① 按名 import 或原名转出它的端编译红(终端一处转出 + 测试);② 运行期没有替身(零别名);③ 改读 `isToolApprovalGate(gate)`(停驻门是不是工具审批停驻)或 `toolNameIsFsWrite(name)`(名字族),断言「门种位 `tool_approval` 进」的测试格作废。
+- `isEngineRefusedToolName` (root entry). Read `ruleToolNameVerdictOf(name).kind` instead: neither `current` nor `unknown` means the engine refuses the name; `unknown` means it cannot be told here. (CC-688)
+- Known limit KL-158 (a name retired by a newer engine than the build-time table judged writable): the table is gone, the check is the one the host installs, and a session-rule write naming a refused tool is refused by the server before anything is stored. KL-183 is rewritten for the same reason: an entry already in a record is only missed when the connected engine is newer than the engine the host installs. (CC-689)
+- **判定口输入 `ReplayPendingBasis.settled`(0.95.0 加的可选键)退役**(CC-632;退役登记 RL-133;接入文档 **§124 RP-2**;🔴 型面 BREAKING:可选输入键删除,三端零读点):「这一问已有结局」现在只有一处存 —— 进程级已结表,判定口第 0 条自己读它;宿主自备映射交入是同一事实的第二存处,对象上带着这一键也不读、不抛、不改判。同批删已知限制 KL-744(「已见结局」只记流内帧腿自己见到的结局,悬挂 ask 腿与宿主问车道那一路不进账)。
+- **座位请求「Always allow (this session)」那一档改由判官派生:`ToolPermissionRequest.sessionRow?: true` 取代 0.96.0 的座位位 `rememberRefused`;过境口 `toolPermissionRequestAskBits(card, requestId?)` 多第二参**(CC-699;接入文档 **§124 HT-3** / §124y;🔴 型面 BREAKING + 行为变):0.96.0 座位只过境引擎的「记不住」声明(严格 `true`),座位卡按「不是 true ⇒ 照渲」读 —— 那一位读不出(非 `true` 值 / 读就抛 / 卡上读不出的证据含它)、只在原型链上、或座位的决断口带不走会话放行时,卡上判官 `standingRowsOf` 说不给而座位照渲(按了也只放行这一次)。现在过境口按判官会话行的同一前提(引擎没说记不住、那一位读得出、卡读得出)∧ 第二参 `requestId` 的域带得走(`live:` / `durable:`;`question:` / `elicit:` / `plan:` 带不走)铸 `sessionRow: true`,座位卡只读 `sessionRow === true`;第二参缺席 ⇒ 不铸;入参本身是座位请求(自带 `requestId` 键)⇒ 不铸(判决只在铸请求时做一次,座位卡直接读请求上的这一位);输入上自带的 `sessionRow` 一律不搬。`TOOL_PERMISSION_REQUEST_KEYS` 换一员(−`rememberRefused` +`sessionRow`);卡入参 `ApprovalCardRequest.rememberRefused` 与读口 `readApprovalRememberRefused` 不动。🔴 硬破坏三句:① 读座位请求 `rememberRefused` 位或按 `Pick<ToolPermissionRequest, …, 'rememberRefused'>` 取型的端编译红;② 宿主不给过境口补第二参 ⇒ 座位请求不带 `sessionRow` ⇒ 改读它的座位卡不再渲那一档(闭合失败);③ 铸座位请求时把本请求的 `requestId` 作第二参传给过境口,座位卡改读 `sessionRow === true`。
+
+### Added
+
+- **提交幂等「同键换体」的拒绝:码 `CONFLICT_IDEMPOTENCY_PAYLOAD_MISMATCH` + 判定 `isIdempotencyPayloadMismatchCode(code)` + 措辞 `idempotencyPayloadMismatchContent()`**(CC-715;**§124 PK-5**;根入口运行期导出 +3):服务端 7.126.0 起同一把 `Idempotency-Key` 再投一个不同的请求体答 `409 conflict.idempotency_payload_mismatch`(不回放、不新建)。三条提交腿同一只判定:抛错的腿取 `classifyTurnWireError(err).errorCode`,开流之后才被拒的那一腿取终局读数的码;结果帧的错误行在服务端原句之后补本包那一句(「重试就原样重发同一份请求;要发另一个请求就换一把新键」)。本包的提交路径不自带幂等键,撞上它的是自带键而前后两次体不同的调用方。
+- **审批卡词读口 `readApprovalCardWord(carrier)` + 卡请求位 `ApprovalCardRequest.approvalCard`**(CC-715;**§124 PK-7**;根入口运行期导出 +1):服务端 7.126.0 起活卡帧与待决行带引擎铸的卡词 `approvalCard`(八词闭集,问答卡 = `question`),取代按工具名回推的 `contentKind`(本包从未读过它)。读口只认 sdk 闭集里的词,缺席 / 表外 / 坏形一律缺席(不编 `generic`);活卡帧与待决行两条腿同一把读法上卡,v1 呈卡帧不带。只作展示 / 分诊,不参与决断。
+- **请求体 `allowTools`**(CC-715;**§124 PK-9**):引擎的可用性选择器(只给点名的工具),交互与无人值守两条车道照发,`[]` = 什么都不给(照发,不当缺席);名单在读到的那一拍就定下(之后入参对象上别的取值器改原数组,发出去的仍是那一拍的名单);不是串数组 ⇒ 装配期 `TypeError`;side-channel 车道无座。名字对不对由服务端判(`400 config.tool_face_control`)。
+- **在线目录「最近一份配置候选被整拒」读口:`modelCandidateRejectedOf(catalog?)` + 措辞 `modelCandidateRejectedContent(reading)`**(CC-715;**§124 PK-11**;根入口运行期导出 +2):服务端 7.126.0 `GET /v1/models` 的 `candidateRejected`;三态 `not_reported`(不说「没拒」)/ `rejected`(被拒的配置域、时刻、来源)/ `unreadable`;回体读口原样过境这一位。
+- **根入口转口 sdk 21.1.0 的两只决断口门种常量 `APPROVAL_DECIDE_GATE_KINDS` / `PLAN_REVIEW_GATE_KINDS` 与成员型 `ApprovalDecideGateKind` / `PlanReviewGateKind`**(CC-715;**§124 PK-4**):就是 sdk 那两个对象(引用相等);本包门种判官的两张表由它们的构建期生成物派生。
+- **`isSdkRunParked(status)` / `SDK_PARKED_RUN_STATUSES` 上根入口**(接入文档 **§124 SR-1**;根入口运行期导出 +2,型面零变):sdk 停驻 run 的两词(`suspended` / `needs_review`)与谓词此前只在包内(`terminalStatuses`,0.95.0 起单源),终端壳自持一份并集;现在上根,壳侧并集随换钉退役。
+- **整份能力位读数上根入口:`engineCapsLandingOf(baseUrl)` + 型 `EngineCapsLanding`**(CC-690;接入文档 **§124 CL-1**;根入口运行期导出 +1):宿主要「这台引擎的 `/v1/capabilities` 说了什么」的整份对象(列能力表、交给本包的投影)时,此前只能自己再取一发存第二份,并自定缺键怎么算。现在读本包落地那一份:三态 —— `landed`(带 `caps`:落地那一拍回体的快照,深冻结,与能力位读器、按键读口读的是同一只;同一次落地两读同一只记录)/ `not_landed`(没探 / 在飞 / 失败 / 回体不是对象 / 被作废 / 地址不是非空串;要分在飞与失败,先等 `engineCapsSettled`)/ `unreadable`(探测交回的回体根读不出)。🔴 缺键极性只在这一处成文:`caps` 上一位不是自有数据位 = 引擎没报 = 不知道,既不是 `true` 也不是引擎明说的 `false`(`engineCapState` 答 `absent`、`engineCapTrue` 答 `false`);在 `caps` 上写「不是 `false` 就算开」是第二条读法。它也是包内取落地的唯一读法:按键读口、嵌套口、能力位读器与 `observedEngineAnswer` 都改从它派生(读数逐字不变,行为差只在下面 Fixed 一行)。
+- **同一台引擎换探测闭包时更新重探登记而不失效:`rotateEngineCapsProbe(baseUrl, probe)` + 型 `EngineCapsProbeRotation`**(CC-692;**§124 CL-3**;根入口运行期导出 +1;KL-753 删行):令牌轮换后重建客户端、而该地址的能力回体已经落地时,新闭包交给 `kickEngineCapsProbe` 会被幂等闸挡回、不更新重探登记 ⇒ 之后「回体已落地而某一位读不成形」的重探(文件检查点收紧闸经它)仍调首探那只闭包,旧令牌失效则恒败、关了检查点的用户一直被拒。新口三态:`started`(没有落地也没有在飞 ⇒ 与 kick 同,起跑)/ `registered`(已有落地或在飞 ⇒ 不起跑、不失效、不推进代际、零请求,只把之后的重探换成这一只)/ `ignored`(地址不是非空串或探测不是函数 ⇒ 什么都不做)。普通 kick 被闸挡回仍不改登记;引擎换人仍走两参 `invalidateEngineCaps`。
+- `ruleToolNameVerdictOf(name)` and its type `RuleToolNameReading` on the root entry: the engine's tool-name check read as `current` / `retired` (with `currentName` when the engine names one) / `unprefixed_namespace` / `unmintable_segment` / `unknown` (check not installed, threw, or answered outside those four words). Never throws. Neither `current` nor `unknown` means the engine refuses the name. (CC-688)
+- `AgentToolListFlawKind` gains `unmintable_segment` (a protocol name whose server or peer segment the engine never mints — engines refuse such a deny-list entry when they can list every tool) and `unjudged` (the engine's tool-name check is not installed or gave no clear answer for that entry). A switch over the flaw kinds needs the two new arms. (CC-688)
+- `SessionPolicyRemovalOutcome` gains `{ kind: 'judge_failed' }`: the engine's tool-name check is not installed, or gave no clear answer for an entry the removal had to judge — nothing is removed and nothing is written (it is not reported as `nothing_to_remove`). `sessionPolicyRemovalNotice` has its own sentence. A switch over the outcome kinds needs the new arm. (CC-688)
+- **工具结果卡结局读口 `readToolCardOutcome(record)`(CC-697;根入口 +1 函数、+2 型 `ToolCardOutcomeReading` / `ToolCardDegradedCause`)**:转录里的工具结果卡此前只有标记 —— 信封 `_sema_degraded`(没有引擎送来的正文,`content` 是空串占位)与 `_sema_not_executed`(引擎明说没执行)—— 和 `is_error`;端只看 `is_error` / `content` 就把占位卡渲成成功的空结果,网页端为此各自铸了句子。现在一只读口:三态 + 成因 + 一句话 —— `normal`(真结果,成败照旧看 `is_error`,读口不改写)/ `degraded`(`not-executed` 引擎没执行,与 `is_error` 正交且先于占位成因;`error-without-detail` 引擎报了错但没给正文;`no-result` 没有结果、记录看不出它跑没跑〔占位卡上的 `is_error: false` 是占位,不是成功〕;`unrecognised` 别的包版本写的标记,不猜成因)/ `unreadable`(不是工具结果记录,或占位标记位读不出 —— 读不出不读成 `normal`)。入参是整条 user 工具结果记录(交互转录行与 `-p` 帧同键同形、两车道同答);全程自有数据位、访问器不执行、永不抛。句子不分工具族、不含内部名;`no-result` 的一句对「轮末收扫」与「真 `tool_end` 无正文」两种成因同为真,所以不说运行停了。
+- **`CloudModelRefIssue.reason` 闭集多一员 `unvouched`**(CC-708;接入文档 **§124 RO-1**;型面只增、additive,运行期导出零变):只出现在 `roles` 键下(`at` = 角色键、带 `target`),意思是「角色点名的模型在目录里,但宿主没有注入本机条目判定口,本包担保不了本机引擎收不收那一条 ⇒ 这个角色没投」;`cloudEffectiveNotices` 为它多一类 `warn` 句(点名角色与模型,说缺的是判定口)。对该联合做穷尽分支的宿主要补这一员(三端无穷尽读点,见 §124d)。
+- **测试钩 `__resetSettledApprovalsForTests()`**(CC-632;**§124 RP-3**;测试钩 59 → 60):清进程级已结表(不动在途持有、卡口与同调用卡账本)。已结表跨用例存活 —— 复用固定 approvalId 的测试用例之间要清;真部署上 approvalId 是服务端铸的唯一 id,不会撞。
+- **mcp 条目的 `toolAxes` 随请求过境**(接入文档 **§124 PK-13**;入参型 `McpConfigLike` +1 可选成员 `toolAxes?: unknown`,运行期导出零变):本地 `.mcp.json` 腿(`mcpConfigToSpec` / `mcpConfigsToSpecs`)与中心配置腿(`cloudMcpToSpecs`)把条目上的按工具效果轴覆盖原样带到请求面 `McpServerSpec.toolAxes` —— 在场且不是 `undefined` ⇒ 同一个值原样过境,缺席不铸;不校形,坏形的处置归服务端(只收认得的轴词)。与服务端 7.126.0 中心腿投影同一读法;此前这一键在两条腿上都被丢掉。
+
+### Changed
+
+- **终局失败详情 `RunTerminalFailureDetail` 收成按 `kind` 分臂的联合**(CC-715;**§124 PK-6**;🔴 型面 BREAKING;服务端 7.126.0 / sdk 21):四臂 —— `provider_rejected`(`status` 承重;`code` / `providerCondition` / `providerConditionSource` 照旧,新增 `providerResetAtMs` 与 `route`)/ `coded`(带码失败的结构化详情,JSON 纯值冻结快照;自引用那一枝略去,超总量预算整只缺席)/ `model_output_invalid`(`cause` 两词 + `outputLimit` 输出上限事实)/ `unrecognized`(表外种类只带原词)。修前是单形 `{ kind: string; status?; code?; … }`,表外种类原样带回连同 `status` / `code`;现在只进 `unrecognized`。承重位坏 ⇒ 整只缺席,可选位坏只省那一位。「普通对象」按跨 realm 形认(原型为 `null` 或原型自己的原型为 `null`):别的 realm(vm 上下文 / iframe)解析出来的同一份 JSON 与本 realm 同答。
+- **开发依赖 sdk `^20.0.0` → `^21.1.0`**(CC-715;**§124 PK-1**):sdk 21 删 `TaskRequest.council` / `debate` 与 `contentKind`(本包零读点)、加 `allowTools` / `approvalCard` / 终局失败详情三臂联合 / 两只门种常量。
+- **开发依赖引擎 core 7.49.1 → **7.49.5**(接入文档 §124 CK 行;型面零变、行为零变)**:7.49.2 – 7.49.5 的 wire 清单合计三项,本包零读点 —— `SHELL_READ_FINDINGS` +`unanswered`(7.49.2)、`ReadCandidate` +`device` / `through` 与 `ShellReadRedirect` +`fd`(7.49.3,均可选位);7.49.4 / 7.49.5 清单为空(7.49.5 = Windows 规则文件店平台谓词,本包不读)。生成物 `src/generated/*.ts` 按 7.49.5 重生,逐字节与盘上对账(门 `upstream-tables`)。
+- **续跑 / 停驻 / 分型读口读抛出物的机读位与决断拒收判官同一条读法:只认自有数据位**(接入文档 **§124 EX-2**;行为面收紧,公面导出名与型零变):`resumeReopenFromError` / `refusedParkFromError` / `resumeRefusalFromError` / `resumeRetryLaterFromError` 与 `classifyTurnWireError` / `isWireTransportError` / `isPreStreamDrainingReject` / `drainingRetryDelayMs` 读 `errorCode` / `status` / `retryAfterSec` / `retryAfterMs` 此前沿原型链普通取值 —— 同一对象判官说「已决」,读口却说「仍待决可续读」或「等 30 秒可再试」;自有访问器在读口里被执行,抛错的取值器让 `resumeRefusalFromError` 外抛。现在只在原型链上 ⇒ 当没带,自有访问器 ⇒ 读不出(取值器不执行;续跑 / 停驻读口答 `null`,分型读口落 0.97.0 起的读不出态)。真 sdk 错误上这些位都是实例自有数据位,读数不变。`message` / `name` / `cause` 照旧(内建错误的 `name` 在原型上)。
+- **能力位读器族多一态 `unreadable`:落地在手而这一位读不出,不再答「没观测」**(CC-704 ①;接入文档 **§124 CP-1**;🔴 型面 BREAKING:29 只读数型联合各 +1 臂 `{ kind: 'unreadable' }`,公面导出名零变;行为变):`observedXxx(baseUrl)` 此前对「这一地址没有落地」与「落地在手,而这一位是自有访问器 / 读描述符就抛 / 值不是这只读器认的形」同答 `{ kind: 'unobserved' }`,而按键现读的 `engineCapValue` 对同一只访问器位答 `unreadable` —— 同一份回体两种答法;下游据「没观测」去等探测、去重探,而重探修不好一个读不出的位。现在两态由读器工厂一处铸、按「有没有落地」二分:没有落地 ⇒ `unobserved`;落地在手而投影没给出读数 ⇒ `unreadable`(每次新铸)。各读器的 doctor 句多一句(回报到了、这一项本端读不了、照这样报再探也不会变);`sql` 读器的 `store` 座在场而读不出改答 `unreadable`(此前 `not_reported`;`store` 缺席仍 `not_reported`)。各判据口(`fileHistoryCaptureMode` 等)对 `unreadable` 与 `unobserved` 同答「不知道」;唯一分开答的是 `rewindSpecForMode('both', …, reading)` 的 `restoreFiles` 键:没观测 ⇒ 照发(不替引擎断言,与此前同),读不出 ⇒ 不发(与「读不懂」同臂,收紧方向;此前读不出被当成没观测 ⇒ 照发)。🔴 硬破坏三句:① 对这 29 只读数型写穷举 `switch` + `never` 的宿主编译红一次,补 `unreadable` 一臂(三端 origin/main 零命中);② 按 `reading.kind === 'unobserved'` 分支的宿主,「落地在手而读不出」那一形此后走另一臂 —— 收紧方向的判定(「判不出就拒」)要把 `unreadable` 一并算进「判不出」,或改调本包的判定口(接入文档 §124y 点名读点);③ 用 `project*Capability(caps) ?? { kind: 'unobserved' }` 自铸读数的宿主,回体在手时可改铸 `{ kind: 'unreadable' }`。29 只读数型:`ApprovalDecidedByReading` / `ApprovalsStreamLiveReading` / `AttachmentSeatReading` / `CallerCwdReading` / `CenterWiringReading` / `DeviceExecutorManagementReading` / `ExecutionLaneReading` / `FileHistoryCaptureReading` / `McpProbeReading` / `MemoryComplianceReading` / `MemoryOriginReading` / `OutputStyleSeatReading` / `PeerLaneReading` / `PermissionModesReading` / `PermissionRulesWriteReading` / `PermissionsAllowGrantReading` / `RewindArchiveReading` / `SealedKeyReading` / `SessionPolicyReading` / `SessionReadRedactionReading` / `SessionSyncFileHistoryReading` / `SkillToolListsReading` / `SqlEngineReading` / `SteerPriorityReading` / `StorePostureReading` / `UserInvokedSkillsReading` / `WebSearchBackendReading` / `WorkflowsJournalReading` / `WriteProtectionReading`。
+- **文件历史收紧闸的拒句按成因分三句**(CC-704 ①;接入文档 **§124 CP-2**;行为变,判定词闭集 `FILE_HISTORY_TIGHTEN_VERDICTS` 不变):`fileHistoryUnjudgedRefusal` / `judgeFileHistoryTighten` 在 `unjudged` 时此前一句通吃(「Try again in a moment」),对「读到了而读不出 / 引擎没报 / 不认识的词」也叫用户稍后再发,而再发永远是同一个结局。现在按读数选句:还没读到(`unobserved`,或手里没有用得上的读数)⇒ 稍后再发;落地在手而这一位读不出(`unreadable`)⇒ 本端读不了,照这样报再发不会变;引擎没报 / 不认识的词 ⇒ 引擎没说,再发不会变。三句都说「没发出去」与同一条出路(打开文件检查点,这一次照常记录)。重探照旧每次 `unjudged` 起一发(请求数不变)。按句子文本分支的宿主(不该有)会读到三句。
+- **能力回体的可落地判据只剩一只:首探与刷新都只收普通记录**(CC-704 ②;接入文档 **§124 CP-3**;行为变,型面零变):总缓存的首探此前收任何非 `null` 对象(数组 / 类实例 / `Date` / `Map` / 读描述符就抛的代理照落),重探刷新只收普通记录 —— 同一只回体两条路两个结局(首探落下的类实例,读器还读得出值;刷新拒同一只)。现在唯一的落地写点先过同一只判据:非普通记录 ⇒ 不落地,与探测失败同一处置(不缓存、下一次 kick 再来;读器 `unobserved`、`engineCapState` 答 `unprobed`)。线上回体恒是 JSON 对象,三端的探测闭包都原样交回 sdk 的回体 ⇒ 零行为差;只有宿主自造非普通对象当回体时看得到差别。子代尾随 / 子代终报的包内读口在没有身份键时探的那一发回体同样过这一只判据(非普通记录 ⇒ 不认,与有身份键时同答;此前类实例 / 数组 / `Map` 回体照读出能力位)。
+- **后台视图不再自探能力位;「assistant 面挂没挂」只看路由自己的 501**(CC-705;接入文档 **§124 CP-4**;行为变,型面零变):`createBackgroundView(client)` 此前首轮自调 `client.capabilities()`、读 `approvals` 位存进视图私有一格(不随 `invalidateEngineCaps` 换代),当「面没挂」的第二个答者。支持底线服务端(7.125.0)上 `approvals` 为假时 `/v1/assistant/*` 先于任何帧答 501 `capability.checkpoint_store_required`(同一只谓词铸),视图既有的 501 ⇒ `not-configured` 臂已覆盖。现在视图零能力请求,assistant 源与 fleet 源同一只判官、同一个先后(501 ⇒ `not-configured`、401 ⇒ `unauthorized`、其余 ⇒ `unavailable`)。行为差只在边角:面未配时 assistant 腿这一轮恰好瞬断 / 5xx ⇒ `unavailable`(此前若能力已探到假则 `not-configured`;下一轮 501 回来即改正);面未配 ∧ 凭据被拒 ⇒ `unauthorized`(与 fleet 源同判);支持底线以下、面未配时路由答 404 的服务端 ⇒ `unavailable`。
+- **One reading for "does the engine accept this rule tool name" (CC-688 / CC-689).** The session-rule deliverability check (`sessionPolicyDeliverable`), the refused-entry removal (`removeRefusedSessionRules`), the sub-agent tool-list pre-check (`agentToolListFlaws` / `projectAgentsForWire`) and the request-body assembly (`permissionsDeclaration` / `permissionsDeclarationReport`) now all ask the engine's own tool-name check — the `judgeRuleToolName` value port, read through `ruleToolNameVerdictOf` — and nothing else; the build-time retired-name table and the hand-written four-name successor table are gone. What changes for a caller: (a) the deliverability check asks it for every name that survives the plain-text steps, not only for protocol names — an ordinary name the installed engine has retired since this package was built is withheld as `legacy_tool_name` (with the engine's `currentName`), and when the check is not installed or cannot answer, a deny batch with such a name is unreadable (it was answered from the build-time table); (b) the request-body assembly rewrites a retired tool name to the current name the engine gives in the deny and ask buckets — now also `KillBash`, `bash`, `read_file`, … (reported in `rewritten[]`) — and keeps every retired name in the allow bucket as `retired_tool_name` (`Task` / `KillShell` / `AgentOutputTool` / `BashOutputTool` in allow were rewritten and granted before); a retired name the engine gives no current name for, and a retired tool part of a content-form rule, stay kept as before; (c) the sub-agent tool-list pre-check judges case twins only against a supplied roster (without one it compared against the current names from the retired-name table), and no longer passes an entry it cannot check: an entry the engine's check calls `unmintable_segment`, or cannot answer for, is reported (see Added) and, with `withholdRefusedDenyLists`, holds back that agent's definition like any other deny-list problem.
+- **云配置里被丢弃的 MCP 服务器条目现在有告示句(CC-693)**:此前 `projectEffectiveBody` 的 `droppedMcpServers` 只在投影读数里,用户只看到那台服务器的工具不见了。现在给人看的句子并进云配置唯一的措辞出口 `cloudEffectiveNotices(projection)`(其入参型多一个必填键 `droppedMcpServers`,`projectEffectiveBody` 的产物本就带它;公面导出名零增删):有条目被丢弃时,每个出现的成因一句并点名那几条 —— 缺必需设置、传输本端不支持、同时设了 `principalHeader` 与 `assertionHeader`、超过传给引擎的条数上限(32)为 `warn`;面板里关掉的为 `info`;成因词表外与读不出的行并入一句兜底 `warn`(不猜成因),清单本身读不出一句 `warn`;键不在或清单为空不出句。名单封 5 个(`+N more`)、同名只点一次、读不出名字的行计数;次序「降级告警 → 目录引用 → 被丢弃条目 → 预算 → 能力上限」。终端的开机横幅与状态命令都经这一只函数,换钉即显示(零改码)。
+
+### Fixed
+
+- **影子 models 文档:与 `models.default` 同指一个模型的 `roles.default` 不再被判 `shadowed`,它自己的旁键原样保留**(CC-702;接入文档 **§124 WR-2**;只在老控制面〔仍发 settings-schema 10 形 `default` 键〕的回体上可达):修前判据是整只对象 `JSON.stringify` 全等 —— 同指一个模型、却多一个旁键(`effort` 一类;不在 settings-schema 12.2.1 的 `RoleTarget` 契约里:契约只有 `{model}` 与 `{select:{tier,needs,prefer}}` 两形,别的键本机读法一律剥掉)的 `roles.default` 被记一条 `shadowed`、整只丢掉,旁键无痕消失,用户还读到「该角色被缺省模型设置盖住」(两位指向同一个模型,这句话说不通)。现在判据只比模型指向(`model` 位,精确字节):同指 ⇒ 没有被盖住的东西,这一位原样带上(与 11 形 `roles.default` 的原样过境同一条读法;`{default:b, roles:{default:{model:b, effort:…}}}` 与 `{roles:{default:{model:b, effort:…}}}` 两代回体产出逐字节同);指向不同(含 `select` 形 / 无 `model` 位 / 非对象)⇒ 照旧整只记 `shadowed`,旁键不挪给胜出的那一位。与上游一次性迁移 SS-M9「同名 ⇒ 不算被压过」同判据(差分格对迁移收据核过);带旁键的影子文档经本机读法会报一条 `unknown-keys-dropped`(整域不降级;服务端候选门把这类告警当整树拒收的理由——未知键一律是候选门错误,与 11 形回体里同样带旁键的角色、与其它 role 的旁键同律)。
+- **回体根读不出时能力位读器同答未观测(CC-690;**§124 CL-2**;行为修正)**:探测交回的回体根读不出(陷阱会抛的代理)时,`observedSqlEngine` 此前答 `{ kind: 'not_reported' }`(「读到了能力表、没报 SQL」),同族其余读器答未观测。现在这一形(非普通记录)过不了可落地判据、不落地(CP-3),全部能力位读器答 `unobserved`;可落地判据过了而快照途中根读不出的落地记作 `unreadable`,读器族不投影、答 `unreadable`(CP-1 同词);线上 JSON 回体到不了这一形。
+- **座位入站判官的键读法与载体种类收口(CC-703;接入文档 §124 OD-1;行为面收紧,成文改口)**:`checkSendMessageRequest` / `checkSessionRowPatchRequest` 与它们里面的三只嵌套闭形(`rewind` / `settings` / `retainSubagentSessions`)原先用 `Object.keys` 枚举键、用 `isObject` 判载体 —— 不可枚举的自有键(哪怕值是坏的、哪怕是表外键)不进循环,门对它零判(`{ sessionId, pinned: true }` 上挂一个不可枚举的自有 `title: 5` 返回 `true`);`Date` / `Map` / `Set` 挂上自有位也过门,而结构化克隆对内建对象只带内建的那部分,门读到的与送出去的不是同一份。现在键只有一条读法(`Reflect.ownKeys` 的串键,每键经座位门既有的唯一取值口读过一遍:不可枚举的自有键拒并点名那一键,放什么值都一样),载体只有一条判法(`isPlainRecord`:原型是 `Object.prototype` 或 `null`;`Date` / `Map` / `Set` / 类实例 / 自定义原型的载体拒),取值落在 `null` 原型的袋里(`Object.prototype` 上被污染的同名键不会被读成这一位);符号键照旧不算载荷键。公面导出名 / 型 / 常量零变;三端 origin/main 上这两只判官零调用点(桌面端 `sendMessage` 入口自写入站门),真部署零影响。成文改口:接入文档 §123a PB-4 / §123c G-PB1 里「不可枚举位 / 只在原型链上的位不算带了」与座位入站判官「自定义原型的载体过门」两句,以本条为准(门 `seat-session-patch` PS8 / `seat-carriers` C8)。
+- **决断拒收判官的机读位只读自有数据位(CC-706;接入文档 §124 OD-2;行为面收紧,成文改口)**:`decisionRefusalAskReading`(及它派生的 `isAlreadyResolvedFailure`、`classifyDecisionRefusal().standing`、包内中断撤卡判定口)读失败对象上的 `unreadable` 标记 / `kind` / `code` / `safetyCode` / `name` / `errorCode` / `status` / `reason` 原先按普通取值 —— 一只自有访问器 `name` 回 `AskDecidedError`、或原型链上放一个 `errorCode: 'conflict.ask_decided'` / `status: 410`,就能把一发未决的拒收读成 `settled`(取值器被执行),而同一判官读 404 成因位早已按自有数据位,同一只判官两条读法。现在这几位与 404 成因位同一条读法:自有数据位 ⇒ 值;只在原型链上 ⇒ 缺席(没有这条证据);自有访问器 / 代理陷阱抛 ⇒ `unreadable`,这些位的取值器一次都不执行。判官的另两种入参形 —— 活卡结局便签(`readToolApprovalRespondRefusal` 的 `status` / `errorCode`)与决断腿拍平结局(`errorCode` 经机读码三态读口 `readWireErrorCodeReading` / 铸口 `readWireCodes`)—— 是铸点从抛出物上读来的,铸点同样只认自有数据位:否则抛出物原型链里的 `errorCode: 'conflict.ask_decided'` 被洗成便签 / 拍平结局上的自有数据位再喂判官,判官的读法就形同虚设(门 `decision-refusal-standing` HJ10 端到端过真耐久决断腿)。sdk 真错误类实例的 `name` / `errorCode` / `status` 本就是实例自有数据位(构造里赋值;唯一的原型取值器是 `extra`,仍经 `readThrownExtra` 读),所以真 sdk 错误上读数逐位同修前(门 `decision-refusal-standing` HJ9 把这一前提钉在 sdk 真实例的描述符读数上)。公面导出名 / 型零变;失败文字的转换 `String(失败对象)` 与 `retriable` 位的读法不变(它们从不出 `settled`);404 成因位经 `extra` 的读法(沿原型链,因 sdk 的 `extra` 是类上的取值器)不在本条射程,见接入文档 §124 包侧缺口 ③。成文改口:此前门里「原型上的访问器(sdk 错误类形)照读」一格由「原型取值器不是证据」取代。
+- **真 wire 上门种 `human` / `irreversible_ask` + 名单外工具(WebFetch、MCP 工具、Monitor 等)的停驻帧,流内不出审批卡**(CC-696;接入文档 **§124 HT-2**):停驻帧归哪条审批臂此前由门种词 `tool_approval`(wire 上不出现)∪ fs 写名 ∪ Bash 名判,真 wire 的审批门种对名单外工具答「不是停驻」—— 流内不出卡,run 停在门上等下一条消息的自愈腿。现在门种读「门种 → 耐久决断腿」同一张表(`durableDecideLegOf`):门种归审批腿 ⇒ 问答工具进问答臂、其余任意工具进工具审批臂(卡形由端的卡口按工具名分发);门种读不出 ⇒ 按名字族(与修前名字腿逐字同);计划门 / 其余门种 / 闭集之外的词 / 读门种就抛 ⇒ 两臂都不进。wire 上不可达的形随之收紧:门种位 `tool_approval`、计划门 + fs 写名、非门种词 + `AskUserQuestion` 此前进臂,现在不进。工具审批腿取件的回落腿(停驻的调用身份缺席或在待决表里没命中时按工具挑行)随之按停驻门自己的工具挑:门的工具属 fs 写 / shell 族 ⇒ 两族(与修前同);族外工具 ⇒ 只认同名行,不拿同 task 先排着的 fs 写 / Bash 行顶替;`surfaceFsApprovalAndDecide` 多一个可选第六参 `parkToolName`(不传 = 修前行为)。`isToolApprovalGate` 签名不变,答法随之变。已知限制 KL-591 第 ② 处(「停驻能否在流上被认出看门本体名」)随之销 —— 调用方工具以名字表里的名字作别名时(如 `MyShell` 别名 `Bash`)停驻照样出卡。门:durable-decide-leg DL6(门种表逐格 / 真 wire 形端到端 / 同词旧形不进臂)· permission-denial-projection O5(真引擎 Runner 读数)。
+- `removeRefusedSessionRules` removes entries whose server or peer segment the engine never mints (`mcp__srv__`, `mcp__`, `mcp__github.com__x`, a segment with a space, …): engines from 7.48.0 refuse to start a run over them, and the removal answered `nothing_to_remove` before. (CC-688)
+- **错误分型口对读不出的字段不再外抛**(CC-698):`classifyTurnWireError` / `isWireTransportError` 的头注一直写「纯判定,永不抛」,但抛出物上的 `status` / `errorCode` / `message` / `cause` / `name` 任何一格是读就抛的取值器(或已撤销的代理),或把整只对象转成字符串的钩子抛(含无原型对象),异常都会原样外抛 —— 而这两个口通常正是在 `catch` 里被调用的,异常会替换原抛出物。修后五格各自受保护、恰读一次;**读不出是显式一态**(不是异常,也不折成缺席):`status` 读不出 ⇒ 无从排除「引擎答过了」⇒ 不判 `http`、也不判 `transport`(`isWireTransportError` 答 `false`),也不认领 park 信号(park 的「流断在候人决断、不是故障」同样预设引擎没应答),落 `internal`;其余格读不出 ⇒ 当没带(`errorCode` 键缺席、`message` 退到 `String(err)`、`cause` 不算在场、`name` 不进 park 臂),别的格不连坐;`String(err)` 本身抛 ⇒ `message` / `detail` 落固定句 `the call failed with an error this client could not render`;`internal.name` 在 `name` 读不出时取 `typeof` 标签。http 臂的码相关附加位(`storedRowWhere` / `sessionUnreadable` / `leaseUnavailable`)从同一份 `errorCode` 快照出发、不再另读一遍(读不出就是读不出,不会被随后又读成功的一次读重新认领)。两个口的传输判据收成同一只判官(此前各写一遍)。同族三只读口读同样几格,同形收口:`isPreStreamDrainingReject` 读不出 ⇒ `false`;`drainingRetryDelayMs` 的 `retryAfterMs` 读不出 ⇒ 当缺席走退避梯;`resumeRetryLaterFromError` 的 `errorCode` 读不出 ⇒ `null`。普通形(含 `null` / 原始值 / Error 实例)的答案与 0.96.0 逐一相同。接入文档 §124。
+- **展示封长不再劈开遮盖记号**(CC-707):按长度截断已洗过的文本时(`displayUntrusted({ max })` / `displayUntrustedMarks` / `capForDisplay` / `cutForDisplay`〔`noticePrintLine` 的句界截断〕/ 点名坏轮句 `toolHistoryBadTurnSentence` 的前 60 码点预览 / 审批决断备注 `readDecisionNoteAudit` 的 200 码元尾截),截点落进一枚遮盖记号 `«redacted:…»` 内部,屏上会留下 `«reda` 这种既不是记号也不是字的残片。修后记号当原子:截点落进记号内部 ⇒ 退到记号之前(整枚去,不劈),记号恰好放得下 ⇒ 整枚留;只认完整闭形(`«redacted»` / `«redacted:词»` / `«redacted:词:词»`,词为 1 – 16 个小写字母或连字符),未闭合 / 夹空格 / 超长词不是记号、照旧可截。射程:修前的残片里没有任何值(**无秘密外露**),被劈开的是「这里被遮过」的标志本身,按记号闭形识别遮盖的读者认不出残片。「结果恒 ≤ `max`」的承诺不变(避让可能让结果更短,与代理对 / 转义 token 的避让同)。`noticePrintLine` 的 8000 字防御栏在洗法里预截断的余量同步改为按封长最大退让量派生(修前固定余量 2,记号整枚退让后会让超栏文本静默变短且不带截断记号)。接入文档 §124。
+- **影子 models 文档:所有 `{model: 串}` 形角色过同一只受理闸;没有注入 `entryAccepted` 时这一形角色不投、各记一行 `unvouched`,不再因点名一条本机引擎会剔掉的条目而拖整个 models 域落默认**(CC-708;接入文档 **§124 RO-1**;行为变,只对没有注入 `entryAccepted` 的调用方):修前 `cloudModelsToDoc` / `projectEffectiveBody` 没有判定口时,`roles` 按目录名字判 —— 点名一条本机引擎会剔掉的条目(例:`provider: "anthropic"` 却没配 `api: "anthropic-messages"`)的角色原样写进影子文档,本机读法随后整域落默认(实测 `domain-defaulted`、目录 0 条,整份云端目录消失),所有角色(含 11 形 `roles.default`)一视同仁地受害;而同一个缺省模型在 10 形回体里(`default` 键)没有判定口时是不投的(也不记)—— 同一件事两条相反的读法。现在 `{model: 串}` 形引用(11 形 `roles.*`、10 形 `default` 投成的 `roles.default`)只走一只受理闸:读不出 / 不在目录 ⇒ 剔并记账(`unreadable` / `dangling`,名字就判得出,用不着判定口);在目录且注入的判定口收 ⇒ 带上;注入的判定口拒 ⇒ 只丢点名它的角色并记 `rejected`(点名好条目的角色留);在目录而没有判定口可担保 ⇒ 不投,**每个没投的角色记一行 `unvouched`**(点名角色键与模型名;缺的是判定口,不是角色或条目有错 —— 目录健康也一样,因为包不知道哪条会被本机引擎剔掉;缺席不等于没发生,读 `modelRefIssues` 的宿主要看得见「这些角色因为没给判定口而没投」)。10 形 `default` 此前没有判定口时连悬空也不记,现在与 11 形一致(`default` 胜出而没投 ⇒ 一行 `unvouched`,被它盖住的同位 `roles.default` 同指不双记、异指记 `shadowed`)。`{select}` 形不指向目录条目,照投。两代回体(10 形 `default` ⇄ 11 形 `roles.default`)没有判定口时也产出逐字节同的影子文档与问题账。注入 `entryAccepted` 的宿主读数零变。旁键 / 畸形角色目标仍原样过境(由本机读法自己说话),不在本条范围。
+- **fleet 台账:task 帧与快照帧同一条尾段规则,前代读数忽略**(CC-700;接入文档 **§124 FL-8 / FL-9**;行为修正,公面导出名与型零变;0.96.0 起既有):同一后台任务的行读数(裸 id 与 `<runId> <id>` 复合 id 共享尾段)此前两臂各判 —— task 帧臂按到达序入账,同尾段还有在飞别名时到的终态行照进留存池(两行并存;随后同代 completed 终态通知把在飞那条退休,展示面一条 failed 一条 completed);两臂的入账口都不比周期:迟到的前代 running 帧复活行并撤掉新一代的终态证据,同代 completed 通知随即把 failed 洗成 completed,同 id 的前代终态帧把新一代在飞行结掉。现在规则只在唯一入账口一处:周期早于这一尾段已知最高周期的读数忽略(快照的整体替换也不抽走这一尾段原有的在飞行);更新一代的读数让更早一代的别名离场;同代或判不出先后时在飞胜;否则终态结算尾段、双生收敛成一条 —— 同一组读数经两臂、任意到达序同答(快照仍是整体替换:快照里没有的行按已离场处理,与此前同)。前代通知(按同一只尾段判官)整段不动状态面:不退休在飞行、不改写留存条目、不入事实台账,在飞行自己的最新一帧没报周期时也一样(此前照退休,过窗即从在飞读面消失);尾段周期的有界记录不再挤掉仍有在飞行 / 留存条目的尾段。0.96.0 本条目「同尾段双生行收敛成一条」只对快照臂成立,勘误见 §124z。
+- **已答 / 已收口的审批不再在别的路上再开一张卡:「审批已有结局」在一个进程里只记一处**(CC-632 / CC-710;接入文档 **§124 RP-1 / RP-4 / RP-5**,勘误 **§124z** 回指 §122d FX 行;行为修正,型面零变):修前它是每只桥自己的台账,换桥(新 turn)/ 悬挂 ask 腿 / 宿主自己的问车道都看不见;公开持有口 `joinApprovalHolder` 在活卡持有者放手之后恒答 `free`(与同一进程里帧腿台账记着的 `answered` 相反)—— 宿主问车道据此为已答的问再开一张耐久卡、再发一次耐久决断(续流实测;壳认领闸先吞掉重复帧、或续流上只来 `approval_request` 两形宿主补记也接不住)。现在:写点只两处(活卡持有者落定那一拍 —— 答复送达并拿到语义答复 / 中断拒绝被引擎收下;引擎收口帧,带转停驻位),帧腿判定口第 0 条、活卡入口(流内帧腿与悬挂 ask 腿共用)、`joinApprovalHolder`、包内停驻行腿都读这一处:持有者放手之后 `joinApprovalHolder` 对已结的问答 `joined`(转停驻仍答 `free`,停驻那一问照常要停驻卡);活卡入口对已结的问零卡零发、交回那一只结局 + `joinedInFlight`。答复回 404 / 宿主撤卡 / 编辑被拒仍不记(KL-745)。🔴 成文改口:「中断拒绝落定后同键再来 = 新决断(第二张卡)」作废 —— 中断拒绝被收下的问在本进程已结;`interrupted` 的写点从「发起」挪到「被收下」(发送失败 / 202 停驻中 ⇒ 不记,放手后照常再呈卡)。
+- **抛出物的 `extra` 与其余机读位同一条读法:对象自有的数据位照读,不是自有位时只认 sdk 错误类的类形(CC-709;接入文档 §124 EX-1;行为面收紧,成文改口)**:`extra`(404 成因 `cause`、写口 / 撤销口 `committed`、续跑折叠 `blockedBy`、拒体 `field` 与各体源结构位都经它到达)此前沿原型链普通取值 —— `Object.create({ extra: { cause: 'run_cancelled' } })` 加自有 `status: 404` 就被 `decisionRefusalAskReading` 读成 `settled`(`isAlreadyResolvedFailure` 为真、`classifyDecisionRefusal().standing` 为 `settled-elsewhere`、中断撤卡不出告警),原型上别家类的取值器与对象自有的访问器也被执行。现在:对象自有的数据位 ⇒ 读;对象自有的访问器 ⇒ 读不出(不执行);不是自有位 ⇒ 原型链上最近持有 `extra` 的节点自己是某个类的原型、链上有内建 `Error` 类的原型(按结构认,不按本 realm 的 `Error.prototype` 恒等,也不读持有者类的名字 —— 生产包压缩后 sdk 的类名会被改写)、那一位是取值器(sdk 错误类的类形)⇒ 按对象自己的取值读,即 sdk 在 `toApiError` 给这一只对象盖的章;其余(链上的数据位、别家类的取值器、`Object.prototype` 上的植入、同名而不继承内建 `Error` 的类 —— 含宿主自造的 `class Error {}` 及其子类)⇒ 缺席;「内建 `Error`」按内建真实性认(构造函数是引擎内建的 `Error`、原型带内建三位),不只按名字。跨 sdk 模块实例、跨 realm 照读(宿主或测试里同时有两份 sdk、或 sdk 错误铸在另一个 realm 时不丢;把取值转发给原对象的代理包装同样读得出)—— 否则 503 `committed: 'unknown'` 会落成缺席、撤销腿放宽成可重发。伪造面:任何继承**内建** `Error` 的类在原型上放一只 `extra` 取值器都会被执行 —— 与在对象上直接放自有数据位 `extra` 同权,不多给读数。同族四处并到同一读法:安全停码只认实例自有数据位 `code`(决断腿把它铸成拍平结局的 `safetyCode` / `code`;修前原型链上的 `code: 'no_pending'` 被洗成自有位、判官读拍平结局答 `settled`)、拒体 `retriable` 只认自有数据位(自有访问器修前在判官里被执行,现在读数 `unreadable`)、409 分码 `conflict` 的 `errorCode` / `name` / `field` 只认自有数据位(修前同一只分类结果里 `errorCode` 缺席而 `conflict` 在场);失败文字的转换只出续读提示、从不出 `settled`(读法不变)。sdk 真实例与自有数据位的重建形读数逐位同修前(门对冻结的旧读法逐形对拍);公面导出名 / 型零变。
+- **「码自己说清了处置」先于「已决」:可等 / 拒在认领之前 / 卡仍待决的续跑拒绝不再经失败文字读成门已决(CC-712;接入文档 §124 EX-2;行为面收紧,公面谓词答案变)**:`isAlreadyResolvedFailure`(停驻解析的「门已决」判据,端的重开挂点也读它)对**没有状态码**的失败形 —— 决断腿拍平结局、无状态码的抛出物 —— 只要机读码不被判官认领,就去扫失败文字的「门早已决」词表;`resume.preflight_rejected`(带等待窗时明说可等)、`resume.usage_window_exhausted`、`resume.placement_mismatch`、续跑 reopen 族带 `retriable: true`(卡仍待决)这几码判官都不认,失败文字恰含 already / not found 就答真,端据此撤卡,而同一对象 `resumeRefusalFromError` / `resumeRetryLaterFromError` / `resumeReopenFromError` 说的是「仍待决 / 稍后可重试」。现在「码自己说清了处置」只有一只谓词 `isCodeClassifiedGateFailure`,成员加上续跑拒绝的两张码表本身(`RESUME_RETRY_LATER_CODES` ∪ `RESUME_REFUSAL_CODES`),`isGateStandingErrorCode` 加上 reopen 族 ∧ `retriable: true`;`decisionRefusalAskReading` 把这一判挪到一切「已决」证据之前(码说清了处置 ⇒ 未决,不看状态码、不扫文字)。「已决」只剩终局证据:本地 `no_pending`、`conflict.ask_decided`、`gone.ask`、410(非 `gone.ask_parked`)、404 ∧ 结束成因、码缺席时 `AskDecidedError`;无码无状态码的老形照旧扫词续读。公面导出名 / 型零变;`isCodeClassifiedGateFailure` 对上面三码、`isGateStandingErrorCode` 对 reopen 族 ∧ `retriable: true` 从 `false` 改答 `true`;门还在的码(如 `corrupt`)遇到 410 / 404 结束成因这类自相矛盾的回体时,修前读作已决,现在读作未决。
+- **影子 models 文档:注入 `entryAccepted` 时 `tierGroups` / `activeTierGroup` 读不出不再让整个调用外抛**(CC-719;接入文档 **§124 RO-2**;行为修正,公面导出名与型零变):models 文档在这两位上读描述符就抛(代理陷阱)或取值器抛时,`projectEffectiveBody` / `cloudModelsToDoc` 此前整个外抛(`tierGroups` 取值器抛时连不注入也外抛)。现在两位只在注入判定口时读、各读一次;读不出 ⇒ 该位不投,`modelRefIssues` 记 `{ key, at: 'models', reason: 'unreadable', outcome: 'dropped' }`(与整份文档读不出的另两行同一形)并各出一句 `warn`,别的位照常。JSON 回体上不可达。
+- **请求装配口:入参上不可枚举的已知键不再被当成缺席**(接入文档 **§124 PK-9**;行为修正,型面零变):装配口此前只收入参上可枚举的键,一个以 `Object.defineProperty` 挂上的 `allowTools: []` 被读成「不选择」(这一次运行挂上全部工具)、`allowTools: 'bad'` 绕过坏形拒。现在装配口认识的顶层键自有即在场、不看可枚举:不可枚举的数据位照读(`[]` 照发、坏形照拒),不可枚举的访问器与可枚举的同一读序、同一拍物化;不认识的键仍只看可枚举(宿主框架挂的不可枚举标记位不当表外键拒)。
+- **决断拒收判官在压缩过的消费端包里认得出码缺席的重建形**(接入文档 **§124 OD-2**;行为修正,公面导出名与型零变;0.96.0 起既有):码被剥掉、只带 `name` 的跨包重建形此前按 sdk 类的 `.name` 比 —— 消费端生产包经压缩器改写类名后,`{ name: 'AskDecidedError' }` 读成未决(`ApprovalStaleError` 的「门已挪走」、`ParkedResumeStartupError` 的「未决」同失)。现在按字面协议名比(`AskDecidedError` / `ApprovalStaleError` / `ParkedResumeStartupError`),压缩与否同答;真 sdk 错误带 `errorCode`、走码臂,读数不变。
+
+### Gates
+
+- 新门 1 道(包侧投影门三件:门 / gates-manifest 登记 / README Guards 行):`run-server-7126-pick-test.mjs`(I 幂等 409 三腿一判 · C 卡词读口与两腿上卡 · D 终局详情四臂 · G 门种表转口引用相等 · T 编排四键退役与 `allowTools` · M 候选被拒三态 · F 服务端 7.126.0 发布字节)。
+- 支持底线 / 地板换代按新律改格:support-floor-projection SF1f / SF1g / CT1a · sdk-floor `FLOOR` + ②d-6 地板线见证 · gate-negative-controls sdk-floor 锚(21.1.0 → 21.1.1)· server-7122-pick F0 与地板线见证取法(同 major 且不低于地板)· server-7125-pick P0 · server-7119-fixture ≥7.126.0 档(评审团腿文件不在)· server-7114-fixture H2(拒体 detail 多 `reason`)· server-7124-pick V 段(样本读者抬到 7.126.0)· hook-matcher-verdict 新档 ≥7.126.0 / 7.125.x(服务端 7.126.0 起编不过 / 求值超过时限的正则 matcher 整请求拒,登记 `rej-form`;文档逐代表换到 §124 G-PK8)· engine-account-keys-projection F6(`coded` 臂补承重位)· 会话 id 只收 uuid 的三只夹具腿(disable-skills-wire / request-uplift / server-7115-fixture)。
+- 改名表退役(RL-123)同批改口:gate-vocabulary M1 / M1b / M4 / M8 / M9 / M10 · upstream-tables A3 / G19-3 – G19-5 · automatic-answer-verdict A5b · mode-release-projection D1c · print-permission-outcome R0c · engine-notice-catalog G11d / G11e · durable-card-display-keys ⑯ · hitl-gate-honesty F17m。
+- 团队编排四键退役(RL-134)与门种表转口(RL-135)同批改口:task-request-omission-receipt · disable-skills-wire G-DS7(语料去四键,摘要用 0.89.0 发布产物重取、本树逐字节同)· client-core-pure B4 / B7 / F6 · server-7119-fixture Z1b · durable-decide-leg DL1 / DL1b / DL5 · selfheal-reopen G2⓪ / G8①e · sdk-wire-transit 值级 / 型级名单 · approval-frame-keys(镜像 +`approvalCard`)· durable-card-display-keys ⑦ · terminal-cause-projection G-PR4(表外种类改读 `unrecognized`)/ G-BD7e(与上一发布产物对拍的登记类)。
+- **gate-vocabulary**:M4 改口 ——「两代同一事实的两个词也各一句」作废,改为本表只一代、现役六词逐字互异;M10 改口 —— 改名表模块不在(源码与构建产物)、句表键 == 强制词闭集、句口函数体里零折名调用(本版早先「退役词读成现名那一句」的格随改名表退役收回)。**upstream-tables** A3 两格改口(句表键型 = 现役词、字面量自己 `satisfies`;成员集取冻结词表、不再取句表的键)。**cloud-effective-projection**:+S8a 一对(同指带旁键的两代回体逐字节同)与 S8a2⑥b – ⑥p(同指带旁键不丢 / 不出盖住句 / 整条投影同读数 / 差分对迁移收据 / 本机读法读回恰一条 `unknown-keys-dropped` / 写出的是数据副本、不与入参共享引用;反钉:指向不同与 `select` 形 / 非对象仍 `shadowed`、非 default 角色旁键过境、精确字节比较;设计反钉:11 形 `roles.default` 不加第二道受理闸,与其它 role 同属原样过境)。
+- 新门 1 道(包侧投影门三件:门 / gates-manifest 登记 / README Guards 行):
+  - `run-engine-caps-landing-projection-test.mjs`:整份能力位读数三态(未落地各成因 / 快照深冻结且宿主改写看不见 / 根读不出)· 缺键极性(规格字面:按键读口的读数 = 门内规格判官作用在整份读数上,多地址 × 多键)· 能力位读器从整份读数派生(`not_landed` ⇒ `unobserved`、`unreadable` ⇒ `unreadable`)· 轮换口三态与时序(落地后轮换 ⇒ 重探调新闭包、旧闭包零次,经包内重探口与文件检查点收紧闸各一格;普通 kick 不改登记的对照;在飞首探 / 在飞刷新 / 同步重入 / 连续轮换 / 失效两形)· KL-753 已删行。
+- 新门 2 道(包侧投影门三件:门 / gates-manifest 登记 / README Guards 行):
+  - `run-cloud-mcp-dropped-notice-test.mjs`:🆕 0.97.0 CC-693 —— 被丢弃的 MCP 条目告示句:五成因各恰一句并点名(真 `cloudMcpToSpecs` 产出五成因各一行)、`disabled` 为 `info` 其余 `warn`、句子零内部成因词、次序钉在降级告警与预算之间、名单封顶与去重、成因词表外 / 坏行(`null` · 字符串 · reason 非串 · 取值器抛 · `constructor` · `__proto__`)兜底不连坐、清单读不出一句 `warn` / 键不在与空清单不出句,产物声明里成因联合恰五词、句子表声明在该联合上。
+  - `run-tool-card-outcome-test.mjs`:🆕 0.97.0 CC-697 —— 工具结果卡结局读口:真管线产物(转录 user 行与 `-p` 帧)上八形矩阵(有正文成功 / 失败 / 空串 / 无 output 成功 / 无 output 失败 / `notExecuted` 三形)读数、收扫卡与「无 output 的真 tool_end」卡读数逐字同、两车道同答;读不出矩阵(入参十形、占位位访问器 / 代理 / 原型链 / 非包常量值、`notExecuted` 非字面 true 六形与访问器、`is_error` 读就抛、已撤销代理)不抛且不读成 `normal`;四句互不相同零内部名、`no-result` 不说运行停了;源码(词法器剥注释)句子表绑成因联合、`notExecuted` 经既有严格真标记读口、占位常量不重写字面,产物里四句各恰一处铸点。
+- **cloud-effective-projection**:🆕 CC-708 S8k 20 格 —— 没有判定口时 `{model}` 形角色不投并各记一行 `unvouched`、同一份经本机读法读回整域不落默认;告示句一格;注入判定口时一好一坏角色的反钉(好的留、坏的恰一条 `rejected`);两代回体(10 形 `default` ⇄ 11 形 `roles.default`)没有判定口时也逐字节同(文档与问题账各五对);悬空 / 空名角色照旧剔并记账、在目录里的不投并各记 `unvouched`;万能格 144 种(坏 / 健康目录 × 有 / 无判定口 × `default` × `subagent` × 六种位态)逐格精确比对影子文档的 `roles` 与问题账、本机读法零次整域作废;10 形 `default` 与 `roles.default` 同在 24 种;健康目录 + 没有判定口的取舍钉;S5k′ / S8a2⑥k 两格改口(修前:没有判定口时 `roles.default → a` 原样写出 / 「按目录名字判,已知射程:整域落默认」)。
+- **fleet-terminal-retain**:+R 段 50 格(CC-700):两臂 × 全部到达序同答(8 组)· 逐形时序(前代 running / 前代终态 / 新一代终态顶替别名 / 通知与行帧同一条周期轴 / 前代通知不退休最新一帧没报周期的在飞行 / 快照前代读数保住在飞行、同尾段带当代读数时照常替换)· 并发(有界尾段记录在 520 条别的尾段压力下保住有行尾段的周期)· 失败分类(坏形周期位按缺席、尾段为空串)。**panel-reduce**:PR-C3 周期源尺子跟着账本换名(尾段账 `.gen` 读、`raiseTailGen` / `isFormerGeneration` 形参)+ 尺子自检格 PR-C3′ⁱ。
+- 新门 1 道(包侧投影门三件:门 / gates-manifest 登记 / README Guards 行):`run-approval-settled-single-source-test.mjs`(19 格:宿主问车道读同一处 / 转停驻负控 / 悬挂 ask 腿写读同一处 / 换桥 / 判定口单一读法 / 不记的三形与写在答复落定那一拍 / 中断拒绝只在被收下时记(404 / 同步抛 / 202 / 转停驻先到四形不记)/ 有界 4096);**approval-respond-parking** G-PK8b 成文改口(停驻体读口在持有者体里两处:答复 + 中断拒绝落定)。**hitl-wave2** G-HW2-1t / G-HW2-6d 成文改口(落定后同键再来 ⇒ 已结、零卡零发);**replayed-approval-disposition** RS0 / RS1 / RS3 / RS4c / RC3 种子改走真写路径(活卡答复送达 / 卡被中止 / 收口帧),RS1d 改钉「交入的映射不读」;复用固定 approvalId 的门经 `_gate-lib.mjs` 的 `freshSettledApprovalsPerCardPort`(每装一次卡口 = 新宿主进程)或逐格清表。
+- **decision-refusal-standing**:+HJ11 段(CC-709):前提格钉 sdk 真实例的描述符读数(`extra` 不是实例自有位、最近持有者是 `APIError.prototype` 的取值器、继承 `Error`;类名不是判据输入;`retriable` 是实例自有数据位)· 类名改写与真压缩包(esbuild minify,sdk 与本包同一 bundle)两枚钉· 原型链伪造各形(数据位 / 别家取值器 / 自有访问器 / 中间插层 / 覆写取值器的子类 / 代理 / `Object.prototype` 植入的数据位与取值器 / `Error.prototype` 植入的取值器 / 同名不继承 `Error` 的负控)四个出口都不是 `settled` 且取值器零执行 · 跨 sdk 模块实例正控与伪造面成文格 · 与冻结旧读法 23 形逐形对拍 · 同族四处(安全停码含耐久决断腿端到端、`retriable`、409 分码、失败文字)· 源码名册。**server-7124-pick** XR8b / XR8c 改口(键名字面量只在常量声明一处、那只常量只在逐层读自有描述符一处引用)。**resume-refusal-copy / rules-legacy-tool-name-projection / server-7119-fixture / workflow-decide-refusal / wire-refusal-copy / resume-retry-later** 各 +2 格(另一份 sdk 模块实例铸的错误读得出 / 同名不继承 `Error` 的类读不到);成文改口:这几道门与 **client-core-pure**、**refusal-machine-reads** 里用对象自有的 `get extra()` 或自造类「模拟」sdk 错误的夹具改用 sdk 的 `toApiError` 铸(读口不再执行自有访问器),原本靠展开取值器得到的自有数据位形改写成显式的自有数据位;13.1.0 手搭形的类名照原样叫 `APIError`。
+- **decision-refusal-standing**:+HJ12 段(CC-712):无状态码的可等预检拒四形(拍平结局 / 抛出物 × 窗在头 / 在体)不是已决 · 同表别码与 reopen 族(带 / 不带 `retriable`)· 码先于状态码 · 公面码认领谓词逐员 · 生成池 2160 形对拍(「仍待决 / 可等 / 拒在认领之前」五只读口任一认得 ⇒ 判官不答已决、停驻解析不续读)· 终局拒收正控 · 耐久决断腿端到端 · 源码名册(码认领在第一条「已决」证据之前、恰一处);HJ5 全形对拍的独立期望成文改口(`corrupt` 遇 410 / 404 结束成因读作未决)。
+- 本版修复批改格:**cloud-effective-projection** +S10 段(CC-719:models 文档 `tierGroups` / `activeTierGroup` 读抛不外抛,两种入参 × 验收读数原形 / 取值器抛 / 一位读不出不连坐 / 取值器恰跑一次 / 告示句)· **server-7126-pick** +T8 段(不可枚举的已知键:`allowTools` 数据位 `[]` / 坏形 / 访问器 / 数据阶段物化、`excludeAllTools`、不可枚举表外键负控、可枚举与不可枚举逐值同答)与 +D7 段(终局失败详情三臂在另一 realm 解析的同一份 JSON 上逐值同答,类实例两 realm 照拒)· **decision-refusal-standing** HJ11a +3 形(祖先是同名自造 `Error` 类)、HJ11h 源码名册改口(内建 `Error` 按内建真实性认)、HJ11c +压缩包里码缺席的重建形三名与 sdk 类名同值格、+HJ13 段(续跑 / 停驻 / 分型读口的机读位与判官同一条读法:票面两形、生成池、分型四格、真 sdk 实例正控)· **client-core-pure** F3E-cc698r / cc698s / cc698s2 改口(`errorCode` 自有访问器读不出、不执行)· **additive-key-passthrough** G7 段:`toolAxes` 由记账不透传改为透传(G7g 两腿在透传集、G7g″ 两传输 × 九值形同一引用过境、G7h 与服务端 7.126.0 中心腿投影逐值同答)· **engine-caps-single-source** +G-SB2b / G-SB2c(无键一发路过同一只可落地判据)与 **engine-cap-snapshot-readers** G-CR45 两格 / G-CR51b 改口(无地址一发路与有地址同答;判据调用点恰两处、各在其位)· **server-7113-fixture** B 段按代际分向(<7.113.0 / 7.113.0 – 7.125.x / ≥7.126.0 有身份边界与 dev-open 两向)。
+
+### Known limits(本版新增)
+
+- KL-758:fleet 台账同一尾段、同一周期(或判不出先后)的两条双生终态行终态词不同(如 failed + completed)时末到者胜 —— 尾段规则顺序无关性的唯一例外,两臂同答(CC-700;§124 FL-8)。服务端一个周期只封一个终态,真引擎未见此形;真 wire 一旦出现即改成「终态词冲突 ⇒ 记冲突、不洗账」。
+
 ## 0.96.0(2026-10-13)
 
 > 主题:终端 1.0.148 对接版 —— 支持底线三件同号(server 7.125.0 / core 7.48.0 / sdk 20.0.0)与 settings-schema 12 提货;清账与单一真源收口(规则工具名判官 / 门种一张表 / 计划审阅结局判法 / 总缓存落地写点 / hooks matcher 契约读法 / 文件历史没搬句与收紧闸 / 探针两位判序 / 凭据网三形);座位改名置顶与最近目录;服务商拒收分类词。净值(相对 0.95.0):根入口运行期导出 1587 → 1629(+55 / −13),测试钩 73 → 59,门清单 232 → 256,退役登记在册 31 / 已退役 62。提货 —— server 7.125.0(CC-636)/ sdk 20.0.x(CC-633)/ settings-schema 12.2.1(CC-655);影子 models 文档改出 settings-schema 11 形(CC-637);404 成因读法与座位门 / 能力位读器成文例外收口(CC-638 / CC-639);`CONFIG_REFUSAL_CODES` 退役(CC-560 ②)。