@agentunion/fastaun 0.5.34 → 0.5.36

package/_packed_docs/sdk/Ownership2.1-SDK/345/274/200/345/217/221/344/270/216/347/247/273/346/244/215/346/214/207/345/215/227.md

@@ -4,13 +4,13 @@
 
 ## 1. 实现边界与角色
 
-关系事实来自 sub 在 NS 的 `agent.md` 和 owner 在本人 Storage 的 `owner.md`，由 NS 验收并锁定。sub 自签自传，owner 自签自传；owner 登录态不能代上传普通 sub 名片。SDK 不维护 Ownership 持久任务、WAL、审批账本或后台恢复，也不调用 decisions 接口。
+关系事实来自 sub 在 NS 的 `agent.md` 和 owner 在本人 Storage 的 `owner.md`，由 NS 验收并锁定。普通 sub 自签自传，owner 自签自传；owner 登录态不能代上传普通 sub 名片，现代 Group/Org 例外边界见下文。SDK 不维护 Ownership 持久任务、WAL、审批账本或后台恢复，也不调用 decisions 接口。
 
 未锁定时，以最后成功上传的 sub 声明为准；NS 比较 owner、sub、关系版本和有效授权等归属事实，不以消息 ID、声明 UUID 或时间判断归属冲突。拒绝只通知对方，不删除或回滚候选。锁定后新的 accept/reject 不能改变归属，必须走释放或转移；锁定前不保证多设备决定只能作出一次。
 
 普通名片解析、外层验签与关系验证分层。正文更新保留全部关系材料的存在性、类型和值及原 CAS，不以前置共识或 owner Storage 可用为条件；关系字段变更仍执行双文件授权。
 
-Group/Org 作为 sub 使用专属生命周期：通用关系编排抛出 `not_applicable`，共识返回同名结果；它们仍可按普通 owner 规则作为 owner。现代实体名片由实体主签、当前 owner token 上传，可选 owner 附签且全部验证，详见协议 §2.5。
+现代 Group/Org 作为 sub 同样支持配对 owner.md／agent.md 声明与通用共识；创建、绑定、转让和解散仍由专属生命周期驱动，普通 bind/release/transfer 关系编排抛出 `not_applicable`。NS 仅对缺少 ownership 的历史实体保留该标记，SDK 以实际返回 status 为准，不将 owner-only 视为共识。作为 owner 仍须遵守各入口的类型限制，local 编排的 owner 仅接受 human/agent。SDK 先写 owner.md，再以实体私钥主签、当前 owner token 发布 agent.md 并确认共识；不再要求旧 entity_cert_fingerprint 或主签 signer_aid，可选 owner 附签且全部验证，详见协议 §2.5。
 
 ## 2. 分层与最小依赖接口
 
@@ -57,7 +57,7 @@ YAML frontmatter＋可选 Markdown＋连续尾签块。首签前 payload 最多
 
 | 文件 | Schema 和身份 |
 | --- | --- |
-| `agent.md` | 基础字段 `aid/name/type/version`；owner 与 ownership 同时出现／省略，含完整 statement；主签者和认证上传者均为 sub。human 不得声明 owner。 |
+| `agent.md` | 基础字段 `aid/name/type/version`；owner 与 ownership 同时出现／省略，含完整 statement；普通主体由 sub 主签并本人上传，现代 Group/Org 由实体主签、当前 owner token 上传。human 不得声明 owner；历史实体格式另按兼容规则读取。 |
 | `owner.md` | 顶层恰为 `owner_aid/sub_aid/ownership`；路径 `owner_aid:/sub_aids/{sub_aid}/owner.md`；ownership 含 statement/action，仅 transfer_owner 另含 transfer。 |
 
 statement 恰含 `version/declaration_id/owner_aid/sub_aid/relation_version/declared_at`。action 为 `declare/release/transfer_owner`；transfer 恰含 `new_owner_aid/target_relation_version/expires_at`，绑定 `v+1`。文件角色取自资源上下文，不取自签名 TAG；不为 owner.md 伪造名片字段。
@@ -78,7 +78,7 @@ ECDSA P-256/SHA-256；签名为严格标准 Base64 的 ASN.1 DER，不能直接
 | 全文 SHA-256 | 包含全部签块的完整性与提交确认。 |
 | NS 原 ETag | 原样用于 If-Match，不能用本地摘要替代。 |
 
-agent／owner 默认 TAG 为 `AGENTMD-V2/OWNERSHIP-V2`，兼容标签以协议为准。普通两类文件主块禁止 signer_aid；附签必填，实体主块显式为实体 AID。已有附签全部验，数学失败不能降级成单签；末端删签不保证可检测。
+agent／owner 默认 TAG 为 `AGENTMD-V2/OWNERSHIP-V2`，兼容标签以协议为准。普通 agent.md、owner.md 与现代实体 agent.md 主块均禁止 signer_aid；附签必填，历史实体主块按原格式兼容验证。已有附签全部验，数学失败不能降级成单签；末端删签不保证可检测。
 
 `AIDStore.sign/verify`、agent.md 和 owner.md 复用唯一通用签验 core，业务 Schema／当前授权在外层校验。TS/JS 公共签验为 `Promise<Result>`；文件输入显式 `inputType: 'file'`，document 成功后才可原地写回。参数见 [API 手册](06-API手册.md#通用-sign--verify)。
 
@@ -376,7 +376,7 @@ await daemonClient.transferLocalSubaid(subClient, nextOwnerClient);
 
 - 普通名片失败稿留本地；显式重试先检查保存的条件，再回源。缺条件不能因远端同字节而清待办；正文更新保留完整关系材料。重连不自动 PUT 普通 pending。
 - 实体 pending 保存完整多签原文、原 CAS、固定 owner 和实体证书代际，应用显式重试；转移／rekey／解散后停止旧待办。现代上传取消额外 V2 授权，旧入口按协议 §2.5 隔离兼容；专属 create/transfer checkpoint 恢复不变。
-- fresh 实体 GET 同时发 Check、no-cache、multi-v1，验证全部签块及当前实体代际，仍为 not_applicable。独立 AIDStore 的 Python／Go 实体上传需注入权威 owner resolver，TS／JS 默认经 fresh NS／PKI 核对。
+- fresh 实体 GET 同时发 Check、no-cache、multi-v1，验证全部签块及当前实体代际；现代实体参与双文件共识，NS 对缺少 ownership 的历史实体保留 not_applicable 标记，SDK 按实际返回状态处理。独立 AIDStore 的 Python／Go 实体上传需注入权威 owner resolver，TS／JS 默认经 fresh NS／PKI 核对。
 - 普通 agent 注册 owner 可选；初始名片不写关系，有 owner 时注册当次使用专属短连接立即发起绑定并 finally close，不等后续 connect 恢复。部分 SDK 仍保留 registration_intent 元数据用于注册信息或兼容读取，不再据此恢复 Ownership 任务；注册成功不等于关系完成。
 - 支持原 2.1 的旧 NS，普通首次绑定、local bind 和新 owner 文件先齐的 local transfer 正常路径仍可用。完整支持双方任意到达顺序、转移候选隔离、Stage 交错重试及同事实重签，需要本轮 NS；旧 NS 在 sub 先接受 transfer 时可能报错，或因 owner SHA 基线导致已齐文件持续 pending、同事实重签被拒绝。
 - 新 SDK 不调用 decisions；仍依赖该接口的过渡 SDK 在接口删除后会遇到 404。旧 proof 或 metadata 不当作 unbound 或当前授权，不能借升级清空锁。不能把 Rust 的旧任务恢复或 Stage 限制当成本轮四 SDK 的行为。

package/_packed_docs/sdk/Ownership2.1/350/257/246/347/273/206/350/256/276/350/256/241.md

@@ -8,13 +8,13 @@
 
 ## 1. 设计边界
 
-通用 Ownership 2.1 排除 `group/org`：其 owner 来自专属服务的创建、解散、转移事实，不创建 owner.md、通用关系版本、锁、NS Ownership 账本或审批任务。通用 Facade 在副作用前直接返回 `not_applicable`、`retryable=false`，共识 `status/code=not_applicable`，不自动转调用其它方法。新 SDK 的实体名片分支以权威类型和生命周期为准；owner 必填、禁止通用 ownership/proof/release，实体私钥主签、owner token 上传并可选 owner 附签，上传校验实体当前证书代际及完整文件原字节；NS 旧客户端实体 token 与当前实体自签的受限旧格式入口见 [协议 §2.5](../protocol/Ownership协议定义2.1.md#25-grouporg-名片的实体主签与-owner-上传)。
+自 SDK 0.5.31 起，现代 `group/org` 与其他非 human 主体统一使用配对的 `owner.md`／`agent.md`、`ownership.statement`、关系版本及双文件共识；生命周期 owner、active 状态和当前证书仍是实体授权约束，不另建 Ownership 事实账本。绑定、释放、转移仍由专属生命周期自动编排，普通管理 Facade 在副作用前返回 `not_applicable`、`retryable=false`，不自动转调用其它方法；该限制不适用于现代声明与共识查询。实体名片含当前 owner 及配对声明，清除旧 entity_cert_fingerprint，不带 signer_aid 的实体主签由当前 owner token 上传；owner.md 由 owner 本人签署发布。历史实体格式及旧客户端上传边界见 [协议 §2.5](../protocol/Ownership协议定义2.1.md#25-grouporg-名片的实体主签与-owner-上传)。
 
-实体 fresh GET 同时携带 X-AUN-Ownership-Check: 1、Cache-Control: no-cache 和 X-AUN-Signature-Format: multi-v1，触发 NS 绕 LRU 全块新鲜验证，仍为 not_applicable、不进入通用账本；GET/HEAD 按 multi-v1 协商完整／首签表示，返回对应 ETag；current/stale、权威 owner/指纹与 missing/unavailable 边界遵循协议 §2.5。verified 下载全块验证历史证书及原始字节，不因当前 owner 或代际变化拒绝历史有效文件，历史成功不代表当前权限。上传仍新鲜校验当前生命周期及证书，不扩展 gateway.resolve。独立 AIDStore 的实体上传接线存在语言差异：Python／Go 须显式注入权威 entity owner resolver；TS／JS 默认通过 fresh NS 与 PKI 核对当前 owner 和实体证书指纹，不能假定四端均自动调用实体服务。
+实体 fresh GET 同时携带 X-AUN-Ownership-Check: 1、Cache-Control: no-cache 和 X-AUN-Signature-Format: multi-v1，触发 NS 绕 LRU 新鲜验证。现代声明进入通用双文件共识；仅缺少 ownership 的历史实体格式保留 not_applicable 及适用的实体响应头，不能用该兼容分支否定现代实体共识。GET/HEAD 按 multi-v1 协商完整／首签表示及对应 ETag；missing 为 404，权威依赖 unavailable 不伪装缺失。verified 下载全块验证历史证书及原始字节，历史成功不代表当前权限。Client 生命周期编排和访问补齐须另核对当前 owner、active 状态及本地实体签名材料；不能把独立 AIDStore 的注入方式等同于四端 Client 均自动调用实体服务，详见协议 §2.5。
 
-旧实体文件按历史读取规则保留；历史 relation/evidence/checkpoint 元数据不参与当前关系判定，也不是普通名片可用性的前置条件。当前实体上传按权威类型、生命周期、当前证书及新 Schema 验收。
+旧实体文件按历史读取规则保留，owner-only 不构成双文件共识，不能覆盖或降级现代关系；旧 entity_cert_fingerprint／signer_aid 按相应历史格式校验，特定旧 Group 的无指纹豁免不适用于 Org。历史 relation/evidence/checkpoint 元数据不参与当前关系判定，也不是普通名片可用性的前置条件。当前实体上传按配对声明、权威类型、生命周期、当前证书及现代 Schema 验收。
 
-Ownership 是 agent.md 之上的关系功能，不能因新增 Ownership 2.1 导致原有 agent.md 上传、下载、历史验签、展示或通信不可用。2.1 关系事实只由数据库中持久化的 sub_aid `agent.md` 与 owner_aid 自有 Storage 规范路径中的 `owner.md` 共同确认；数据库事务和 CAS 只负责完整 `agent.md` 的原子更新，不引入独立的第二份 2.1 关系事实。旧 SDK owner RPC 的 Auth JSONL 与 NS `ownership_proof` 是隔离的 legacy 兼容状态，不写 2.1 双文件，不构成 2.1 授权、lock/version/consensus，也不得覆盖已存现代声明。若数据库保留 owner_aid、关系版本或锁等索引列，它们只能服务于 `agent.md` 的 CAS 和查询，不能脱离两份文件单独判定 2.1 关系。只有需要当前 owner 关系的共识、授权和关系操作才执行 2.1 新鲜检查；关系缺失、legacy、stale 或关系依赖 unavailable 时，仅这些功能降级或拒绝授权，不能把普通读取兼容当作 current／consensus，也不能清空既有保护。
+Ownership 是 agent.md 之上的关系功能，不能因新增 Ownership 2.1 导致原有 agent.md 上传、下载、历史验签、展示或通信不可用。2.1 关系声明由数据库中持久化的 sub_aid `agent.md` 与 owner_aid 自有 Storage 规范路径中的 `owner.md` 共同确认，Group/Org 授权还须核对当前生命周期及实体证书；数据库事务和 CAS 只负责完整 `agent.md` 的原子更新，不引入独立的第二份 2.1 关系事实。旧 SDK owner RPC 的 Auth JSONL 与 NS `ownership_proof` 是隔离的 legacy 兼容状态，不写 2.1 双文件，不构成 2.1 授权、lock/version/consensus，也不得覆盖已存现代声明。若数据库保留 owner_aid、关系版本或锁等索引列，它们只能服务于 `agent.md` 的 CAS 和查询，不能脱离两份文件单独判定 2.1 关系。只有需要当前 owner 关系的共识、授权和关系操作才执行 2.1 新鲜检查；关系缺失、legacy、stale 或关系依赖 unavailable 时，仅这些功能降级或拒绝授权，不能把普通读取兼容当作 current／consensus，也不能清空既有保护。
 
 后续审查和验收必须同时覆盖下面的兼容矩阵；四 SDK 与 NS 按同一边界检查，不能只验收新增关系流程：
 
@@ -105,7 +105,7 @@ NS 下列路径以 [Go 服务根目录](../../../extensions/services/nameservice
 | --- | --- | --- |
 | `internal/httpserver/agentmd.go`：`get`、`put` | 有 LRU、writeGen 和名片 CAS；没有完整的 2.1 关系验收。get 会把部分 DB 故障映射为 404。 | 引入统一关系检查入口；新鲜 GET/HEAD 绕过缓存并先确认释放；PUT 无论有无检查头都执行基于 agent.md CAS 的保护。 |
 | 同文件：`validateAgentMDUpload`、`enforceStoredOwner` | 完整文件验签已有；锁主要依据旧名片 owner/proof。 | 拆开本身份验签和关系验收；原 owner 从持久化 agent.md 的 ownership 字段及旧名片确定，不能取待上传目标。 |
-| 同文件：`authorizeAgentMDUploader`、`verifyOwnerAgentMDAuthorization`、`verifyOwnershipProof` | 支持旧 proof、owner 授权头和群 owner 代理分支。 | 普通 2.1 本身份上传，旧分支不得覆盖已有关系。Group/Org 按权威类型分流到当前生命周期、实体主签、全块验签及 owner token 上传校验，不落通用账本，不允许自声明改类型绕锁。 |
+| 同文件：`authorizeAgentMDUploader`、`verifyOwnerAgentMDAuthorization`、`verifyOwnershipProof` | 支持旧 proof、owner 授权头和群 owner 代理分支。 | 普通 2.1 本身份上传，旧分支不得覆盖已有关系。现代 Group/Org 进入通用声明／共识及 CAS，同时校验权威类型、当前生命周期、实体主签、完整签名链和 owner token；不另建关系事实账本，不允许自声明改类型绕锁。 |
 | `internal/httpserver/agent_md_schema.go` | `aidParseTailStrictAt`、`validateStrictAgentMDMeta`、旧 ownership 校验。 | 复用严格解析，补 TAG、statement/action、文件角色和当前证书验证。 |
 | `internal/repository/mysql.go`：`CompareAndSwapAgentMD` | CAS 范围只有名片内容、摘要和更新时间。 | 让 ownership 字段随完整 `agent.md` 一起原子提交；不增加独立关系事实表或证据表。 |
 | `internal/httpserver/agentmd_cache.go` | 当前名片缓存。 | 继续供普通展示；不能作为最终授权依据。 |
@@ -184,7 +184,7 @@ TS/JS 的 [cert-utils.ts](../../ts/src/cert-utils.ts)、[JS 对应文件](../../
 
 owner.md 不具备名片必填的 name/type/version，不能直接复用“必须是 agent.md”校验。复用底层签名容器，在各模块内分别实现两种角色 schema；NS 不依赖 SDK 的包。
 
-当前证书材料通过既有权威查询获取，精确核对 AID、证书 DER 指纹、实际 `active_signing`、完整证书链及签名 OCSP。OCSP 绑定本次链选定的直接 issuer，核对 CertID serial、issuer name/key hash 与 ResponderID，只接受该 issuer 亲签及同一 issuer 内嵌证书，不接受委派 responder；链获取和 OCSP 接收后用当时当前时间检查新鲜度，末尾再次核对链有效期。未知签名身份类型时省略 `key_purpose`，不得将 owner.md 的签名者一律视为普通 signing 身份。Group/Org 主签证书属于实体并匹配 frontmatter 指纹，owner 可另附签，附签同样必须验证；已知群实体证书查询使用 `group_identity`。CA `observed_at` 与 OCSP `ThisUpdate` 距当前时间不得超过 30 秒，`ProducedAt` 不得超过 90 秒，三者未来偏差均不得超过 5 秒；`NextUpdate` 严格晚于当前时间和 `ThisUpdate`。CA 的 Go OCSP 签发器按分钟截断 `ProducedAt`，因此其窗口包含取整误差，其它当前状态窗口不变。NS 在最终提交前按当时的服务端时间重新核对；材料不可确认返回 unavailable，已知坏签名、无效链或吊销返回 invalid。
+当前证书材料通过既有权威查询获取，精确核对 AID、证书 DER 指纹、实际 `active_signing`、完整证书链及签名 OCSP。OCSP 绑定本次链选定的直接 issuer，核对 CertID serial、issuer name/key hash 与 ResponderID，只接受该 issuer 亲签及同一 issuer 内嵌证书，不接受委派 responder；链获取和 OCSP 接收后用当时当前时间检查新鲜度，末尾再次核对链有效期。未知签名身份类型时省略 `key_purpose`，不得将 owner.md 的签名者一律视为普通 signing 身份。现代 Group/Org 主签证书属于实体，以尾签指纹核对当前证书代际，不要求旧 frontmatter 指纹；owner 可另附签，附签同样必须验证；已知群实体证书查询使用 `group_identity`。CA `observed_at` 与 OCSP `ThisUpdate` 距当前时间不得超过 30 秒，`ProducedAt` 不得超过 90 秒，三者未来偏差均不得超过 5 秒；`NextUpdate` 严格晚于当前时间和 `ThisUpdate`。CA 的 Go OCSP 签发器按分钟截断 `ProducedAt`，因此其窗口包含取整误差，其它当前状态窗口不变。NS 在最终提交前按当时的服务端时间重新核对；材料不可确认返回 unavailable，已知坏签名、无效链或吊销返回 invalid。
 
 ### 4.2 五个内部文件方法
 
@@ -321,11 +321,11 @@ Storage 当前完整原文复核与 NS 提交之间没有跨服务一致快照
 
 内部编排器与消息处理器推进同一任务；sub-first 及 transfer 的历史 ready 通知不得再次创建绑定任务，owner-first 无需 owner.ready。普通名片更新仍使用现有名片 API，但必须完整保留锁定的关系字段。
 
-普通 `agent` 注册的 owner 可选；指定 owner 时，owner 意图先与 SDK 生成的固定 operation_id 一起持久保存；初始名片不写 owner 或旧 proof，并以条件创建提交。连接后用该 ID 进入绑定编排，响应丢失或重连都读取原任务，不另建操作、不默认批准；未指定 owner 时只初始化普通名片，不创建关系任务。NS 不可用时保留已有意图；已有关系或未知旧待上传文件不能由初始化路径覆盖。Group/Org 身份准备不生成通用注册意图；创建自动 owner 绑定，owner 持有实体材料，用实体私钥主签并以本人 token 上传，可选追加本人附签。专属 pending 保存实体命名空间、固定 owner、实体证书指纹、原完整多签文件及原 CAS，恢复不补造条件或跨 owner/rekey 代际重签。
+普通 `agent` 注册的 owner 可选；指定 owner 时，owner 意图先与 SDK 生成的固定 operation_id 一起持久保存；初始名片不写 owner 或旧 proof，并以条件创建提交。连接后用该 ID 进入绑定编排，响应丢失或重连都读取原任务，不另建操作、不默认批准；未指定 owner 时只初始化普通名片，不创建关系任务。NS 不可用时保留已有意图；已有关系或未知旧待上传文件不能由初始化路径覆盖。Group/Org 身份准备不生成这类通用注册意图；其创建由当前 owner 先条件发布本人签名的 owner.md，再用实体私钥签署含配对 statement 的 agent.md、以 owner token 条件上传，最后强制确认 owner 和关系版本的共识。创建／转移检查点保留可接续阶段，历史首次补齐默认 v=1，同 owner 的匹配声明复用当前版本；转移须核对旧 owner 的有效目标授权并使用 v+1，不补造条件或跨 owner/rekey 代际重签旧稿。
 
 普通显式上传与注册初始化分别保存待办。普通名片候选在本地 schema 和外层签名验证通过后、首次远端 preflight 前，先独立保存到既有元数据的私有 `local_draft_content`，不覆盖已确认的远端 content/ETag；自有且持有本地私钥的身份默认 resolve 优先返回该稿，标记 unverified、in_sync=false、source.agent_md_fetched=false。显式 download／forceRefresh 仍读取远端权威内容并保留草稿，只有服务端确认对应候选提交成功才清稿。重连不自动重传普通失败稿，普通注册 initial 失败稿同样需要应用显式重试；即使存在普通 pending 也不隐式 PUT。Ownership 2.1 任务及注册意图的既有恢复不能替代失败稿的显式重试。取得可靠 NS 原条件后，仍在 PUT 前持久保存完整签名字节、原 If-Match／If-None-Match 及关系快照；显式重试既有 pending 时先核原条件，缺失则保留原元数据及原错误，不因远端同字节而清除。2.1 正文更新核对原 owner、完整 statement、relation_version 和 lock。已有普通 legacy owner/proof 或 2.0 关系仅允许更新正文，完整保留 owner、ownership、ownership_proof、ownership_release 的存在性、类型和值；新 metadata 和外签执行当前规则，不自动迁入 2.1。该分支持久保存原全文、摘要、原 ETag 及完整关系快照，重试核对 base/candidate/remote 和原条件；全文及提交 ETag 均对应原提交时只观察确认，否则仅按仍成立的原条件重传原 blob，不刷新 CAS、不重签、不补造上下文。其它缺原上下文的旧待办仅允许版本 0 / unlocked 的初始关系；实际关系变更由对应 Ownership 任务恢复。
 
-Group/Org 名片失败稿及 pending 保留实体命名空间中的完整多签原文、原 CAS、固定 owner 和实体证书指纹，由应用显式重试，post-connect／重连不隐式 PUT。重试先验证完整原件及当前 owner、状态和证书代际，原条件完整且同代际原文／ETag 已确认提交时只观察完成。转移、rekey 或解散后停止旧代际待办，不更换身份、指纹或条件重签。新 SDK 现代上传不再保存、刷新或检查额外 V2 授权及过期窗口；旧 V2 兼容入口仍按协议 §2.5 校验；普通文件签名与当前证书检查保留。专属 create/transfer 自身 checkpoint 恢复机制不变。
+Group/Org 名片失败稿及 pending 保留实体命名空间中的完整签名原文、原 CAS、固定 owner 和签名证书代际，由应用显式重试；重试核对完整原件及当前 owner、状态和证书，原条件完整且同代际原文／ETag 已确认提交时只观察完成。转移、rekey 或解散后不更换身份、证书或条件重签旧稿。生命周期 create/transfer 检查点恢复与访问补齐另行保留：按当前身份、成功连接代际和单实体合并一次检查，缺本地实体材料直接停止；可用的本地共识匹配 owner 时结束，否则确认 active 生命周期 owner 后查询共识，仅在具备本人及实体私钥时补齐缺失声明。失败不在同一连接自动反复重试，真实重连后可重查；不在启动时遍历所有群重传名片。现代上传不需额外 V2 授权，历史兼容入口仍按协议 §2.5 校验。
 
 ### 7.2 转移的默认编程顺序
 
@@ -417,7 +417,7 @@ sub 收到 release 通知时，只有在持久历史中找到本人明确 accept
 
 共识检查从首次 NS GET 发出前开始计算整体 30 秒窗口，覆盖首读、证书/Storage 验证和末读；材料变化或超时返回可重试 unavailable。fresh HTTP 携带 no-cache 并禁止自动跟随重定向。收到 sub.cleaned 时，按任务固定上下文新鲜核对当前 NS 完整原文、ETag 和全文摘要；字段已清空时可记录当前 unbound/0 的清理观察。通知或观察进度不能证明本任务执行提交，也不能替代首次完成 release 所需的原件及原 CAS 关联核验。
 
-Group/Org 名片失败稿及 pending 保留实体命名空间中的完整多签原文、原 CAS、固定 owner 和实体证书指纹，由应用显式重试，post-connect／重连不隐式 PUT。重试先验证完整原件及当前 owner、状态和证书代际，原条件完整且同代际原文／ETag 已确认提交时只观察完成。转移、rekey 或解散后停止旧代际待办，不更换身份、指纹或条件重签。新 SDK 现代上传不再保存、刷新或检查额外 V2 授权及过期窗口；旧 V2 兼容入口仍按协议 §2.5 校验；普通文件签名与当前证书检查保留。专属 create/transfer 自身 checkpoint 恢复机制不变。
+Group/Org 的普通名片失败稿只按原字节和原 CAS 显式重试；生命周期 create/transfer 的检查点恢复以及首次访问的声明补齐是独立路径，不能笼统写为实体一律不恢复或重连自动重传旧稿。补齐先预筛本地实体材料，再按当前身份／连接代际共享单实体检查；已有可用共识匹配本人时跳过，否则确认 active 生命周期 owner 后查询并补齐。缺私钥、依赖 unavailable、关系 invalid 或其他 owner 冲突均不能按无主覆盖。具体顺序、版本复用和旧代际边界见第 7.1 节及协议 §2.5。
 
 重连恢复先读取 NS/Storage，再考虑待发消息、写入和删除。一次持久保存的 step 不能证明远端副作用已经发生，远端的新版本也不能被旧 step 覆盖。
 

package/_packed_docs//346/266/210/346/201/257/345/274/271/346/200/247/350/241/245/346/213/211/351/200/232/351/201/223/345/256/236/346/226/275/350/256/241/345/210/222.md

@@ -0,0 +1,400 @@
+# 消息弹性补拉通道实施计划
+
+> 日期：2026-11-08。状态：既有实现持续验收；本轮单辅助连接与 namespace 串行规则正在实施，历史通过记录不证明新规则通过；64 个跨 SDK 基础矩阵 case 均已有通过 attempt，原首败仍保留并由独立 retry38 新 trace 验证；控制面四 SDK 在线开关、S13 水位/公平性定向验收通过。资源性能、旧 SDK 在线兼容、完整场景及阶段门仍未全部验收完成。
+> 依据：[消息弹性补拉通道方案](消息弹性补拉通道方案.md)。范围：控制面板、Gateway、Message/Group、Python、Go、TS/Node、JS/Browser。
+
+## 1. 交付目标与边界
+
+长期离线积压通过辅助短连接补拉，主长连接继续承担正常 RPC、实时通知、ACK 和必要管理消息。业务继续使用现有 Facade，由一个 AUNClient 内部协调主辅通道。
+
+| 交付项 | 必须达到的结果 |
+| --- | --- |
+| 面板开关 | 在控制面板配置 Gateway 的“启用弹性补拉通道”，经现有配置中心持久保存，页面重载、Gateway 重启后仍保留 |
+| 动态授权 | 本轮 Gateway 向双能力协商成功的 SDK 动态授权 0/1 条；开关关闭必为0，开启时授权上限为1，压力仍可降为0或回收；同一 Gateway 的 `(aid, device_id)` 跨 slot、主会话合计最多1条。SDK 遵从策略支持0..N，现有协议测试到2 |
+| 策略闭环 | 所有 Pull 触发入口先处理最新策略；暂停后 Gateway 主动通知恢复；收缩时通知并回收连接 |
+| 共享状态与资源 | 身份、游标、去重、解密、提交、ACK 及额度属于主 client；增加连接不增加资源份额 |
+| 正确性 | 同 namespace 网络 Pull 串行、不同 namespace 可在策略与预算允许时并行复用辅助连接；各流协调提交并公平推进；历史缺口、稀疏序号、主会话换代及迟到页面均按既有语义处理 |
+| 验收 | 四 SDK 分别验收，再完成四发送端×四接收端矩阵、真实浏览器及 Ubuntu Docker 测试 |
+
+实施边界沿用方案：辅助连接仍需认证；Message/Group 维护分页、可见性、覆盖证明和确认，不管理辅助连接或 EventService 订阅业务。首版主辅连接绑定同一 Gateway 实例或已有亲和路径。
+
+### 1.1 控制面板与持久化规则
+
+配置键为 `sync_channels_enabled`，布尔值，缺省为 `true`，已有显式 `false` 保持关闭；该开关只控制弹性辅助通道，不关闭消息同步。连接数只在承接主连接的 Gateway 内合计，当前不跨 Gateway 全局统计；同设备最多1条，不同设备可分别使用1条。SDK进程池每AID最多2条、总计最多8条；这些连接数与主辅共享的总16、background 8、event 4、pull 4 RPC预算及历史Pull最多3并发分别计量。
+
+| 操作或状态 | 运行行为 |
+| --- | --- |
+| 开启 | 双能力协商成功的在线会话收到新策略；Gateway 按实时压力给出 0/1，同一 Gateway 内 `(aid, device_id)` 跨 slot、主会话合计最多 1 条，有积压且满足本地预算时 SDK 申请通道 |
+| 关闭 | Gateway 立即禁止新增辅助连接，下发 `max_aux_channels=0`，通知既有辅助通道排空或取消后关闭 |
+| 关闭后的历史补拉 | 回到主通道小页、低优先级补拉，仍受历史在途和速率限制；历史额度为 0 时继续暂停 |
+| 页面刷新或服务重启 | 从配置中心读取已保存的有效配置；Gateway 在接受辅助注册前完成配置加载 |
+| 保存失败 | 不显示保存成功，不把本次草稿作为有效运行配置 |
+| 已保存但部分实例未应用 | 面板区分配置修订与实例生效状态；实例恢复配置链路后按最新有效版本收敛 |
+| 关闭后再次开启 | 恢复申请资格，不主动为没有积压的 client 建连，不复活已失效主会话 |
+
+复用现有配置 schema、修订、绑定、发布和实例应用链路。作用域沿用现有 Gateway 配置规则，不新设按 AID 的持久开关表。配置修订号与每个主会话的 `sync_policy.version` 分别管理。
+
+仅修改此开关时热应用，不重启 Gateway，不中断主连接。Launcher 比较配置摘要时只排除 `sync_channels_enabled`；其它冷配置或混合改动继续执行原重启流程。热应用期间保留旧实际版本，只有诊断中的实例、目标配置版本和 `enabled` 全部匹配后才报告新实际版本。复用既有 watch 与生命周期检查，不新增定时任务。
+
+```mermaid
+sequenceDiagram
+    actor O as 管理员
+    participant C as 控制面板
+    participant P as 配置中心
+    participant G as Gateway
+    participant S as SDK主连接
+    O->>C: 修改弹性补拉开关并发布
+    C->>P: 按既有流程校验、持久保存配置修订
+    P-->>C: 保存结果与修订号
+    P->>G: 分发有效配置
+    G->>G: 更新准入规则和各主会话策略版本
+    G-->>S: 策略通知，关闭时附通道回收通知
+    S->>S: 先安装策略，再伸缩或回收
+    G-->>P: 按既有链路报告应用结果
+    C->>P: 查询保存及实例生效状态
+```
+
+### 1.2 实施期间始终成立的约束
+
+- 主辅合计：总 RPC 16、background 8、event 4、pull 4；历史 Pull 最多占 3，保留实时/前台 Pull 位置。
+- Gateway 的零值暂停对主辅历史请求都生效；SDK 不用主连接绕过历史暂停。
+- 先预留消费容量和内存，再请求页面；编码字节预算与解密后本地内存预算分别执行。
+- EventService 的 64 条/64 MiB 保持原适用范围，不作为普通补拉的现有容量。
+- 不新增周期策略查询、需求心跳、独立 token 刷新或完整 client 后台任务；仅使用按需冷却/空闲/排空期限。
+
+## 2. 阶段与依赖
+
+```mermaid
+flowchart LR
+    P0["P0 契约与失败用例"] --> P1["P1 四端共享预算与分页边界"]
+    P0 --> P2["P2 Gateway策略与面板持久开关"]
+    P1 --> P3["P3 单辅助通道与统一提交"]
+    P2 --> P3
+    P3 --> P4["P4 动态0/1与回收公平性"]
+    P4 --> P5["P5 Ubuntu Docker与四端验收"]
+```
+
+P0 固定后，四 SDK 的 P1 可以并行，P2 的 Gateway 与控制面工作可以并行。P3 必须等待预算和服务端准入通过；P4 必须等待单辅助链路正确。每个阶段均按失败用例→最小实现→受影响回归推进，阶段门未通过不进入下一阶段验收。
+
+### P0：协议、配置与共同测试向量
+
+| 编号 | 任务 | 交付与通过条件 |
+| --- | --- | --- |
+| P0-1 | 固定 `elastic_connections_v1`、`sync_channels_v1`、主辅认证字段、内部同步用途标识和辅助方法白名单 | 认证主体、device、slot、主会话绑定、建连中计数、两层能力未协商行为一致；具体方法逐项列明 |
+| P0-2 | 固定 `_meta.sync_policy` 与控制通知契约 | 完整快照、版本安全整数、零值/缺省、乱序策略、旧页与旧会话区别明确 |
+| P0-3 | 列出所有直接/间接 Pull 触发入口 | 对照实际方法和事件制作清单，覆盖认证、目录、通知、页面、ACK、发送结果及错误响应；每项都有观察顺序断言 |
+| P0-4 | 固定面板开关 schema 和配置应用流程 | 核实配置存储、有效作用域、发布/应用结果、重启加载位置；明确默认开启、显式关闭保留与动态生效契约 |
+| P0-5 | 固定硬字节边界与存储范围选择 | 明确单条超页的可恢复结果及读取路径；明确持久/volatile 分流参数与旧端兼容，避免空页死循环 |
+| P0-6 | 整理语言无关向量并记录旧行为基线 | 四端使用同一输入/输出期望；先补能复现额度倍增、过期策略派发及回收误重连的失败用例 |
+
+**阶段门 G0：** 协议及配置字段没有双重含义，S01—S28 已分配测试层和责任端；新增契约断言在旧实现上按预期失败。普通 RPC、单连接补拉和内存基线记录完整。
+
+### P1：共享调度、消费背压与分页边界
+
+| 编号 | 任务 | 依赖 | 交付与通过条件 |
+| --- | --- | --- | --- |
+| P1-1 | 将四端 Transport 内资源额度收口为 client 共享预算 | P0-6 | 主辅两个 Transport 仍共享 16/8/4/4；历史最多 3；原单连接行为通过 |
+| P1-2 | 统一会话公平调度与资源预留 | P1-1 | SDK 遵从策略支持0..N条辅助、现有协议测试到2；同 namespace 网络 Pull 串行，不同 namespace可按授权并行；共享16/8/4/4、历史最多3及字节/速率预算，跨流轮转，续页排队尾；无消费额度不派页 |
+| P1-3 | 四端实现共享字节和对象内存预算 | P1-1、P0-5 | 在途、密文、解析、明文、预取和待提交均计入；取消/超时/拒绝/半页断线释放预留 |
+| P1-4 | Message/Group 执行页条数与硬编码字节上限 | P0-5 | 第一条超大消息也有确定处理结果；覆盖证明完整，不静默跳过或反复空页 |
+| P1-5 | 落实历史与 volatile 的存储范围选择 | P0-5 | 历史辅助查询与主通道必要处理正确分流；原设备/slot/服务租约过滤和 volatile cursor/TTL 保持 |
+
+**TDD重点：** 先构造多 Transport 额度累加、慢消费持续发页、首条超限及取消后预算泄漏，再实现共享控制。Gateway 限额前，SDK 本地已有的约束也必须成立。
+
+**阶段门 G1：** 不启用辅助连接时回归通过；模拟多通道时额度与内存保持有界；Message/Group 新旧分页请求均通过。不得用每条连接一份预算替代共享控制。
+
+### P2：Gateway 权威策略与控制面开关
+
+| 编号 | 任务 | 依赖 | 交付与通过条件 |
+| --- | --- | --- | --- |
+| P2-1 | 主会话策略状态与主辅原子注册 | P0-1、P0-2 | 校验认证 AID/device/slot 及双能力；同一 Gateway 内 `(aid, device_id)` 跨 slot、主会话建立中和已建立合计最多 1 条；注销、拒绝、主失效正确释放 |
+| P2-2 | 按 AID 聚合请求、字节、速率和公平份额 | P2-1、P0-5 | 多设备/多主会话/多辅助不能增加 AID 总份额；服务端即时拒绝或暂停超额历史准入 |
+| P2-3 | 统一对外帧的策略注入和四 SDK 观察入口 | P0-3、P2-1 | Gateway 发出时附最新策略；SDK 在 Future/Promise 完成、事件分发和后续调度之前观察 |
+| P2-4 | 策略变更通知与暂停恢复 | P2-2、P2-3 | 历史在途/速率为 0 时不派发；无业务流量时主动通知可以恢复，无轮询探测 |
+| P2-5 | 配置中心注册开关并接入面板 | P0-4 | 现有配置页可编辑布尔值、保存和重读；复用权限及持久化流程，不只写进程内变量 |
+| P2-6 | Gateway 启动加载及运行时应用配置 | P2-4、P2-5 | 重启保持配置；仅开关变更热应用且主连接不中断；冷/混合改动沿原重启流程；实例/版本/开关确认后报告实际应用 |
+| P2-7 | 剥离非权威同名外层字段 | P2-3 | 仅 Gateway 注入的认证连接元数据影响授权，不改签名正文；业务字段同名不改变策略 |
+
+**TDD重点：** 先断言“响应回调即发 Pull”也已看到暂停；两个并发辅助申请与关闭开关只能按当前额度准入；保存失败不能显示成功；保存成功后重启仍为原值。
+
+**阶段门 G2：** 面板→持久配置→Gateway 准入→在线策略通知闭环通过；所有 P0-3 入口逐项有证据；不能仅验证 Pull 正常响应这一条路径。
+
+### P3：一条辅助连接的完整正确链路
+
+| 编号 | 任务 | 依赖 | 交付与通过条件 |
+| --- | --- | --- | --- |
+| P3-1 | 四 SDK 增加内部辅助 Transport 生命周期 | G1、G2 | 仅授权且有需求时建立；复用主 client token 来源，不重复登录、注册密钥或启动维护任务 |
+| P3-2 | 将适用历史任务派给辅助连接 | P3-1 | 只将普通持久 Forward Pull 按 P0 白名单调度，目录/状态留主连接；普通 RPC、实时通知及 ACK 保留主路径 |
+| P3-3 | 主辅接入统一校验、解密、提交与 ACK | P3-2 | 既有 A/T/H、coverage、去重、密钥依赖不分叉；worker 不直接 ACK 下载最大 seq |
+| P3-4 | 主会话代际、token 更新、断线和超时恢复 | P3-3 | 同主会话旧策略页可正常处理；主替换后的旧页不提交/ACK；辅助失败不使主 client 下线 |
+| P3-5 | 持久/volatile、聊天回填与指令顺序回归 | P3-3、P1-5 | 聊天可合并最新窗口；顺序指令等待同流缺口；过期 volatile 不补，独立管理处理可推进 |
+
+**阶段门 G3：** Gateway 仅授权 1 条时，四端各完成单 peer、多 peer、群消息、加密依赖及故障恢复；增加连接没有产生新的游标、解密状态所有者或应用分发器。
+
+### P4：动态伸缩、通知回收与公平性
+
+| 编号 | 任务 | 依赖 | 交付与通过条件 |
+| --- | --- | --- | --- |
+| P4-1 | 0/1 伸缩与发送前原子复核 | G3 | 并发触发、建连中降额、配置快速切换均不越权；更严格策略立即执行 |
+| P4-2 | 需求摘要和回收排序 | P4-1 | 通过请求及状态变化通知维护需求；区分无需求空闲、等待消费/密钥、正在传页；未知需求不当作无需求 |
+| P4-3 | Gateway 主通道通知与有界排空 | P4-2 | 先通知再正常回收，优先确认无需求且最久空闲者；到期取消，不等待应用 ACK |
+| P4-4 | 四端目标通道退役与重连抑制 | P4-3 | 重复/乱序通知幂等；关闭辅助自动重连；完整页可提交、半页不 ACK；主 client 持续在线 |
+| P4-5 | 按需扩容、空闲归还及进程内多 AID 预算 | P4-1、P4-4 | 冷却避免抖动；多 Agent 不各自开满；有任务且授权恢复才重新申请；计时器随任务结束释放 |
+| P4-6 | 持续历史负载下的普通 RPC 和跨流公平 | P4-5、P2-2 | 有限负载夹具中所有可运行流持续推进，额外连接不增加主体份额，主路径资源预留可观测 |
+
+**阶段门 G4：** S07—S12、S16、S19、S21—S28 通过；无定时探测、需求心跳、无任务重建或辅助回收引发的登录失败。
+
+### P5：Ubuntu Docker 验收与交付
+
+| 编号 | 任务 | 依赖 | 交付与通过条件 |
+| --- | --- | --- | --- |
+| P5-1 | 对齐四端类型、协议向量与实现差异 | G4 | wire 字段、版本处理、预算、关闭/恢复行为相同；仅保留语言命名和运行环境差异 |
+| P5-2 | 四 SDK 分别验收 | P5-1 | Python、Go、TS/Node、JS/Browser 分别给出功能、恢复、内存和构建结果 |
+| P5-3 | 跨 SDK 发送/接收矩阵 | P5-2 | 16 个组合分别验证 P2P、群、离线积压与恢复，不用同语言测试代替跨语言 |
+| P5-4 | 受控性能与网络变化测试 | P5-2 | 记录普通 RPC P95、吞吐、RSS/堆、队列、在途字节、连接/认证次数及公平性结果 |
+| P5-5 | 新旧兼容、配置重启与多 Gateway 生效 | P5-2 | 无新能力沿用原路径；有作用域覆盖时显示实际有效配置；主迁移重新取得策略 |
+| P5-6 | 更新协议与 SDK 指南，整理证据 | P5-3—P5-5 | 控制面开关、辅助用途、通知、预算、边界及四端差异可查；完成条目均有对应命令与结果 |
+
+**阶段门 G5：** S01—S28 无未解释失败；四端独立验收、跨 SDK、真实浏览器及受控性能结果完整。未执行、跳过、失败不得标记通过。
+
+## 3. 实施落点与测试落点
+
+以下 SDK 路径相对 `aun-sdk-core/`；服务端与面板路径相对仓库根。列表是修改定位，不要求重写整文件；新增内部组件或测试文件仅在实际拆分确有必要时确定。
+
+| 责任端 | 现有代码入口 | 对应验证入口 |
+| --- | --- | --- |
+| 控制面板/配置链路 | `extensions/services/aun_console/web/src/views/ControlCenter.vue`、`web/src/lib/configDraft.ts`；Console Go 的 `internal/httpserver` 配置路由，向后追踪现有配置中心 schema、修订及应用链路 | 既有 `configDraft.test.mjs`、Console handler 测试、面板真实浏览器保存/重读；配置中心与 Gateway 重启集成 |
+| Gateway | `extensions/services/gateway/go/internal/httpserver/server.go`、`internal/clientws/state.go`、`internal/events/dispatcher.go` 及现有配置消费入口 | `internal/httpserver/server_test.go`、`internal/clientws` 和 dispatcher 原测试；Go race 与受影响包检查 |
+| Message/Group | `extensions/services/message/go/internal/p2p/pull.go`；Group 实际 Pull handler、分页与 coverage 实现 | 现有 Pull/分页/保留期/设备过滤测试；超大单条及存储范围契约 |
+| Python | `python/src/aun_core/transport.py`、`_client/rpc_pipeline.py`、`_client/lifecycle.py`、`_client/delivery.py`、`events.py`、`seq_tracker.py` | `python/tests/unit/test_push_service_lifecycle_contract.py`、`test_seq_tracker.py` 及现有调度测试；`python/tests/integration_test_transport_isolation.py` |
+| Go SDK | `go/transport.go`、`client_rpc_pipeline.go`、`client_lifecycle.go`、`events.go`、`seq_tracker.go` | `go/transport_test.go`、`inline_lifecycle_generation_test.go`、`push_service_lifecycle_contract_test.go`、`seq_tracker_test.go`；race |
+| TS/Node | `ts/src/transport.ts`、`src/client/rpc-pipeline.ts`、`src/client/lifecycle.ts`、`src/client/delivery.ts`、`src/events.ts` | `ts/tests/unit/transport.test.ts`、`transport-connect-race.test.ts`、`rpc-pipeline.test.ts`、`lifecycle-controller.test.ts`；`tests/integration/transport-isolation.test.ts` |
+| JS/Browser | `js/src/transport.ts`、`src/client/rpc-pipeline.ts`、`src/client/lifecycle.ts`、`src/client/delivery.ts`、`src/events.ts` | `js/tests/unit/transport-background.test.ts`、`rpc-pipeline-semantic.test.ts`、`lifecycle-controller.test.ts`；真实浏览器 `tests/e2e-browser/transport-isolation.spec.ts` |
+| cross-SDK | `tests/cross-sdk/runner/` 与四端既有测试 agent | 扩展现有消息/恢复场景配置，逐组合保留机器可读结果 |
+
+控制面板已有布尔配置编辑能力，应优先扩展 Gateway 配置 schema 与既有应用链路；只有现有页面无法表达保存/生效结果时，才修改对应界面。配置持久化位置及热更新接收点在 P0-4 精确登记，不能把 Console 的任意状态库当成配置真源。
+
+## 4. 场景与验收追踪
+
+S01—S24 与方案编号保持一致；S25—S28 补充控制面配置。已完成的定向验证见第 9.4 节；逐场景 E2E 验收仍需记录测试 ID、适用 SDK、命令、构建版本及证据。
+
+| 场景 | 主要阶段 | 验证层 | 通过标准 |
+| --- | --- | --- | --- |
+| S01 单 peer 巨大积压 | P3 | 单测、四端 E2E | 同流协调提交，ACK 只前进到可靠覆盖水位 |
+| S02 多 peer/多群 | P1、P4 | 调度单测、E2E | 独立流轮转，续页不长期占用 worker |
+| S03 历史期间持续新消息 | P3 | 四端 E2E | A/T/H、初始目标、聊天回填及顺序指令符合既有语义 |
+| S04 普通 RPC 并发 | P4、P5 | 受控性能 | 同网络/负载下 P95 增幅目标≤无补拉基线 20%；绝对门槛在 P0 基线确定 |
+| S05 慢消费/解密/磁盘 | P1、P3 | 单测、资源 E2E | 停止新页派发，条数和字节预留有界，无持续内存增长 |
+| S06 所有 Pull 触发入口 | P0、P2 | 契约、集成 | 逐入口证明先观察策略，后完成回调/分发/调度 |
+| S07 授权 0→1→0→1 | P4 | 四端 E2E | 不多开；历史暂停时不借主通道绕过 |
+| S08 策略乱序与重复 | P2、P4 | 四端单测、集成 | 旧策略不回退；同主会话合法旧页仍可提交 |
+| S09 主连接替换/迁移 | P3、P5 | 生命周期单测、E2E | 旧主会话页不提交、不 ACK；新会话重新取策略 |
+| S10 建连中降额 | P2、P4 | 竞态单测、集成 | 建立中与已建立合计不超额，释放计数准确 |
+| S11 无业务流量恢复 | P2、P4 | E2E | Gateway 主动通知唤醒积压，无周期探测 |
+| S12 辅助断线/超时 | P3、P4 | 故障注入 E2E | 从安全游标恢复，主 client 在线，资源不泄漏 |
+| S13 稀疏/重复/保留边界 | P1、P3 | 分页单测、E2E | 使用覆盖证明，不猜连续 seq，不跳确认或无限重试 |
+| S14 单条超大消息 | P0、P1 | 契约、四端 E2E | 硬上限成立；有确定恢复路径，无空页循环或静默跳过 |
+| S15 群状态/密钥/volatile | P1、P3 | 四端 E2E | 群依赖和设备可见性正确；volatile 独立游标及 TTL 保持 |
+| S16 多 AID/设备/连接 | P2、P4 | 公平性单测、压力 E2E | 同一 Gateway 内 `(aid, device_id)` 跨 slot、主会话辅助合计最多 1 条，不同设备分别计数；未双能力协商不授权，历史资源仍按 AID 聚合 |
+| S17 新旧组合 | P2、P5 | 兼容集成 | 未协商不创建新通道；既有主路径可用；Gateway 仍实施总体保护 |
+| S18 四端与 cross-SDK | P5 | 独立 E2E、矩阵 | 四端分别签收，再完成 16 个组合及相应场景 |
+| S19 延迟/带宽变化 | P4、P5 | 受控网络性能 | 有真实收益记录；冷却有效，无连接/认证风暴 |
+| S20 非权威同名策略 | P2 | 受控契约单测 | 业务/远端同名元数据不更改授权，不修改签名正文 |
+| S21 空闲回收优先级 | P4 | 排序单测、集成 | 确认无需求最先回收；等待消费或未知需求不冒充空闲无需求 |
+| S22 通知/关闭乱序 | P4 | 四端单测、E2E | 指定通道幂等退役，主在线，不立即自动重建 |
+| S23 完整/半页回收 | P3、P4 | 故障注入 E2E | 完整合法页按约定提交；半页不 ACK，释放预留并保留任务 |
+| S24 需求变化竞态 | P4 | 单测、集成 | 新需求不丢任务；归属及在途核验正确，无周期心跳 |
+| S25 保存/重读/重启 | P2、P5 | 面板与配置 E2E | 页面重开及 Console/Gateway 重启后开关值保持；启动先加载后准入 |
+| S26 在线开关及快速切换 | P2、P4 | 四端 E2E | 关闭立即禁止新辅助并通知排空；旧配置不回退；开启无需求不建连 |
+| S27 保存失败及生效状态 | P2、P5 | handler、面板 E2E | 未授权/保存失败不误报成功；已保存与实例未应用可区分，恢复后收敛 |
+| S28 多 Gateway 配置范围 | P2、P5 | 分布式 Docker | 按既有作用域应用；跨实例生效版本可核对；主迁移后服从目标实例策略 |
+
+## 5. 四 SDK 独立验收与跨 SDK 矩阵
+
+### 5.1 分别签收
+
+| SDK | 必须单独完成 | 结果状态 |
+| --- | --- | --- |
+| Python | 协议向量、共享额度/背压、0/1、通知回收、代际、P2P/Group/E2EE、构建及受影响检查 | 本机定向及 Ubuntu S07/S16 单辅助夹具通过，见9.5；完整服务验收待完成 |
+| Go | 同上；增加资源释放和共享状态并发检查、受影响包 race | 本机定向及 Ubuntu S07/S16 单辅助 race 夹具通过，见9.5；完整服务验收待完成 |
+| TS/Node | 同上；Node 实际 WebSocket、类型检查与构建，不用 TS/JS 共用结论替代 | 本机定向及 Ubuntu S07/S16 单辅助夹具通过，见9.5；完整服务验收待完成 |
+| JS/Browser | 同上；真实浏览器 WebSocket、构建与类型检查；验证浏览器挂起恢复，不能依赖 Node 专属 API | 本机定向及 Ubuntu S07/S16 单辅助 Chromium 夹具通过，见9.5；完整服务验收待完成 |
+
+### 5.2 发送端×接收端
+
+每格分别保留消息生成端与补拉接收端的版本及结果。四个同端组合做基准，其余十二个组合做跨 SDK 验收。64 项 P2P/Group×明文/E2EE 基础矩阵已逐 case 对账通过：原37项、独立 retry38 新 trace、remaining39 中26项合计64个唯一 case ID；原第38项首次超时仍保留为历史失败，不被重试结果覆盖。各次构建来源和 checkpoint 分开记录；这些历史结果不证明本轮单辅助连接与 namespace 串行规则通过。
+
+| 发送端＼补拉接收端 | Python | Go | TS/Node | JS/Browser |
+| --- | --- | --- | --- | --- |
+| Python | 见checkpoint | 见checkpoint | 见checkpoint | 见checkpoint |
+| Go | 见checkpoint | 见checkpoint | 见checkpoint | 见checkpoint |
+| TS/Node | 见checkpoint | 见checkpoint | 见checkpoint | 见checkpoint |
+| JS/Browser | 见checkpoint | 见checkpoint | 见checkpoint | 见checkpoint |
+
+每格覆盖 P2P 与群、明文与既有 E2EE、离线积压与持续新消息、辅助断线及安全恢复。动态策略、主会话换代、配置关闭回收另按接收端四种实现逐一验收；不能只跑 16 次普通收发就宣称 S01—S28 覆盖完成。
+
+## 6. Ubuntu Docker 执行顺序与证据
+
+1. **核实环境。** 按[默认测试指南](aun测试运行指南.md)及[分布式指南](aun分布式测试运行指南.md)选定 Ubuntu Docker 环境，记录 Compose、域名、project、镜像和数据挂载；本机源码是唯一源头。
+2. **记录基线。** 同一批数据、网络及负载分别测原单通道、开关关闭和开启；普通 RPC 基线为相同前台负载且无后台补拉，另保留单通道补拉对照。历史数据规模、流数、平均/最大消息大小和消费速率固定并记录。
+3. **先完成定向单测。** 服务端/Console、四 SDK 分别先通过契约、调度、竞态及类型/lint/构建检查，再部署集成环境。Python 命令带 `-X utf8`，Go 对受影响并发路径跑 race。
+4. **同步并重建。** 本机修改同步至 Ubuntu；Gateway、Message/Group、配置中心或 Console 有变更时重建对应镜像并重启，不把旧镜像结果记为新实现证据。
+5. **功能验收。** 先契约集成，再四 SDK 分别 E2E、真实浏览器，随后 cross-SDK 矩阵；使用 `{svc}.{issuer}` 服务地址。
+6. **配置与故障验收。** 实际执行面板保存、重读、Gateway 重启、在线关闭、暂停后无业务恢复、半页断线及主替换；分布式环境验证配置作用域和主迁移。
+7. **受控性能。** 逐级增加积压流、消息大小、消费延迟和测试网络延迟/带宽约束；同时发送正常 RPC、实时消息及租约请求。测试只作用于隔离环境。
+8. **断点续跑。** 首个失败立即停在该项，修复后从该项继续；已通过且不受改动影响的项目不重跑，受影响的契约或调度路径必须回归。
+
+| 指标 | 采集与判定 |
+| --- | --- |
+| 普通 RPC | 同样本量、稳态窗口与网络条件记录 P50/P95/P99、错误和超时；P95 增幅目标≤20%，不通过降低样本量掩盖尾延迟 |
+| 追赶效果 | 积压完成时间、历史吞吐、实时到达延迟；分别列 0/1 实际授权结果，不能将更多连接直接等同更高吞吐 |
+| 内存与队列 | 峰值及稳态 RSS/堆、预留/实占字节、队列条数、在途页；达到背压后不随积压总量继续线性增长 |
+| 公平性 | 各 AID/设备/流的调度次数、最长等待与进度；固定有限竞争集中的可运行流不得持续零进度 |
+| 连接成本 | 建连、TLS/认证次数、回收原因与重试次数；无需求不建连，关闭后不抢重连 |
+| 定时任务 | 比较开关前后任务/计时器；只存在尚有需求的冷却、空闲或排空期限，结束后释放 |
+| 配置证据 | 配置修订、有效作用域、各实例应用版本、主会话策略版本、重启前后读值及回收记录 |
+
+每条证据至少包含：任务/场景编号、SDK、代码差异标识、镜像构建标识、环境、准确命令、预期/实际、状态及日志路径。性能阈值和样本设计在 P0 登记后保持一致；失败不能只记“偶现”。
+
+## 7. 启用、兼容与回退
+
+部署支持新契约且缺省开启的服务端，保留已有显式关闭配置；先验证未协商 SDK 及显式关闭、旧 Gateway 条件下的既有路径，再验证协商成功时的动态 0/1，以及同一 Gateway 内 `(aid, device_id)` 跨 slot、主会话合计最多 1 条。
+
+| 组合或操作 | 验收要求 |
+| --- | --- |
+| 新 SDK＋旧 Gateway | 无 `sync_channels_v1` 时不申请辅助连接，沿用原主通道 |
+| 旧 SDK＋新 Gateway | 原方法及响应可用，新增外层元数据不破坏解析；服务端总体保护仍生效 |
+| 新 SDK＋新 Gateway，开关关闭 | 不申请辅助连接，普通补拉及 RPC 可用 |
+| 面板关闭回退 | 配置持久保存并下发在线会话；既有辅助通知排空，任务从安全游标回到允许的主通道路径 |
+| Gateway 重启或主会话迁移 | 已保存配置恢复；附属旧代际作废，新主会话重新协商并取得目标实例策略 |
+
+协议字段上线后保持兼容；回退不删除消息、游标或配置历史，不改变原消息确认契约。
+
+## 8. 实施完成清单
+
+- [ ] G0：契约、面板开关、所有触发入口和共同失败向量冻结。
+- [ ] G1：四端共享预算与背压、Message/Group 分页边界及存储范围通过。
+- [ ] G2：Gateway 权威策略、配置持久化、启动加载及动态应用通过。
+- [ ] G3：四端单辅助链路、统一提交、代际与故障恢复通过。
+- [ ] G4：动态 0/1、通知回收、公平性及按需计时器通过。
+- [ ] G5：Ubuntu Docker 四端独立、16 组合、真实浏览器、兼容和性能验收通过。
+- [ ] S01—S28 逐项具有结果及证据，所有失败已修复或明确为未交付。
+- [ ] RPC/连接协议、SDK 集成与移植指南、配置说明及索引同步，实施状态如实更新。
+
+方案、协议、SDK 和服务端实现已有部分定向验证；以上完整阶段门尚未全部验收，通过范围与未完成项见第 9.4 节。
+
+## 9. 实施契约冻结与进度
+
+2026-11-08 已按本计划实施 Gateway、Message/Group、四 SDK 及控制面开关。四端辅助断线、S14 超页停流与恢复、最终 bundle 的真实 Chromium、64项跨 SDK 基础矩阵及控制面四 SDK 在线开关均已有对应通过证据；单独修改 `sync_channels_enabled` 热应用后，主连接 ID 和 Gateway 实例 ID 保持不变。资源性能、旧 SDK 在线兼容、持久化重启和多 Gateway 等完整场景仍待验收，阶段门尚未全部通过。
+
+### 9.1 能力与用途
+
+用户明确弹性连接未来可承载其它用途。本轮将通用能力与补拉用途分开：
+
+| 字段 | 冻结规则 |
+| --- | --- |
+| `elastic_connections_v1` | 通用弹性辅助连接能力，主辅连接均需声明并协商；提供认证、主会话绑定、动态授权与回收基础 |
+| `sync_channels_v1` | 本轮历史补拉用途的协议能力；与通用能力均协商成功且有效配置允许后，才可申请补拉辅助连接 |
+| `options.purpose=history_sync` | 当前受支持的用途；后续其它用途另行定义方法白名单与额度，复用主辅生命周期 |
+| `options.parent_connection_id` | 必须绑定相同已认证 AID、device、slot 的有效主会话 |
+| 请求 `_meta.sync` | `{purpose:"history_sync",parent_connection_id,has_pending:true}`；主通道历史回退也携带，额度不因换 socket 改变 |
+| 响应 `_meta.sync_policy` | 当前补拉用途的权威快照，字段见方案；不是未来所有用途共用的业务策略结构 |
+| 通知 | `event/gateway.sync_policy_changed`、`event/gateway.sync_channel_close`；需求使用 `gateway.sync_demand` Notification |
+
+当前只实现 `history_sync` 的业务用途，未知用途不自动获得补拉方法权限。未协商通用能力、未协商补拉能力、面板关闭分别验收；原普通短连接用途保持兼容。
+
+### 9.1.1 辅助断线退回主连接
+
+用户明确：弹性/补拉连接断线后不自动重连，相关操作退回主连接。辅助 Transport 不启动自动重连；协调器也不能以冷却重试的方式为同一批待补任务自动补开连接。
+
+断线时未完整接收的页不提交、不 ACK，保留安全游标；当前主会话仍有效时，使用主连接重试同一受限历史请求，沿用剩余 deadline、共享额度和最新策略。主连接历史额度为 0 时等待 Gateway 恢复通知，不借回退绕过暂停；主会话已经改变则按原代际取消，不向新会话提交旧结果。
+
+当前主会话/策略授权下记录辅助故障状态，后续任务使用主路径；只有新的 Gateway 策略明确重新授予辅助资格或新的主会话协商后才可再次按需申请。未变更的重复快照不解除故障状态。正常主动回收同样不触发 Transport 自动重连；空闲无需求时不补开。
+
+自然断线、RPC 失败和建连失败锁定实际请求或连接使用的版本；主动 `sync_channel_close` 优先锁定通知附带的合法权威策略版本，没有合法匹配策略时退回目标连接的实际使用版本。旧版本请求晚失败、旧关闭通知晚到，均不得锁住已经获得的新策略资格。
+
+四端增加真实断线测试：辅助确实关闭、主连接 ID 保持、该请求及后续任务走主路径、连接计数不增长、暂停额度仍有效、旧页不越过 ACK。此规则优先于原文“冷却后重新申请”的一般描述。
+
+### 9.2 分页与预算共同口径
+
+共同向量位于 `tests/contracts/sync_channels_v1_vectors.json`（相对 SDK 根），四 SDK 使用同一份数据验证适用场景。
+
+- `storage_scope` 支持 `all|persistent|volatile`，缺省 `all` 保持旧行为；`persistent` 不读取 volatile mailbox。
+- `volatile` 专用页不携带持久 coverage/head/server ACK，也不接受 `ack_up_to_seq`；仅由共享 SDK 路径解码分发及更新 volatile cursor。
+- `max_page_bytes` 显式值为 1024—786432；协商初始页预算 256 KiB、聚合在途编码预算 1 MiB。旧未指定请求保留旧分页行为。
+- 本地历史共享预留预算初值 8 MiB，以页编码上限的 8 倍预留并贯穿消费；同时采集实际对象/堆使用，预留倍数不等同于 RSS 精确上限。
+- 单条超过页预算返回 `OVERSIZED_MESSAGE`，不推进游标；SDK 明确上报该流错误，停止无进展续页。大对象引用走原有读取方式，不悄悄提高 Gateway 授权预算。
+
+`max_page_bytes` 按 RPC `result` 的 JSON 编码字节计量；JSON-RPC 信封及 Gateway 元数据另保留有界开销，不混入四端的结果长度比较。诊断 `history.reserved_bytes` 表示编码结果预留，`history.local_reserved_bytes` 表示本地放大预留，分别与编码额度及 8 MiB 本地额度比较。
+
+后台不可继续的超页错误统一向应用发布 `sync.error`，字段为 `namespace`、`method`、`code="OVERSIZED_MESSAGE"`、`error`；该流停止自动续页，其他流继续。显式前台调用继续返回原 RPC 错误，不能记录日志后无限重试，也不能为绕过错误推进 ACK。
+
+### 9.3 测试桥诊断
+
+四端测试桥提供 `GET /sync/channels/state`，至少包含 `policy`、`main_connected`、`channels`、`history.inflight`、`history.reserved_bytes`、`history.aux_completed_pages`、`counters.aux_connects/aux_closes`、`metrics.rss_bytes`。只计真实辅助连接返回的成功页面，不能用主连接页面冒充专用通道证据。
+
+cross-SDK 以 16 个发送/接收组合，分别覆盖 P2P/Group 和明文/E2EE；同语言组合也使用不同发送身份，避免断开补拉接收端时把发送端一起关闭。
+
+### 9.4 已有验证证据与未完成验收
+
+下表只记录已执行范围，历史重叠集合不累计；SDK 本地测试通过不等同于 Ubuntu E2E 通过。
+
+| 范围 | 已有结果与边界 |
+| --- | --- |
+| Python | 既有同步/背景额度定向103 passed、Client选择9 passed；辅助通道诊断状态回归70 passed，空连接ID统一为`connecting`。本轮`demand=true`先通知修复最终105 passed/2 skipped、相关回归5项通过；`sync_channels.py`冻结SHA为`d7ff55fa4decf760ad8adc1dc69b35d57a78e25e44bbe3f8d3948930d5d99704`，上述修复已随下述统一runtime部署。Ruff受影响范围、compileall与差异检查通过；重叠集合不累计，Transport整文件既有45项lint无新增 |
+| Go | 既有同步/预算定向50个顶层测试、含子测试86项通过，版本竞态与断线三项连续10轮通过。Ubuntu SyncChannels/observer定向race通过（25.632s）、主辅共享预算race通过（1.084s），两种桥构建的`go vet`通过。逐次解密重复写IK修复在Ubuntu离线Docker中34项及2个子用例race、vet和crosssdk build通过，已部署两Go测试桥并核验进程SHA，证据`go-ik-isolated-20261107T191807Z-de46fd/`；新第38项260条回调首末1950ms，仅记功能时限验证。本轮demand与禁辅助Ping修复定向、race及vet通过，已随下述统一runtime部署；主包全量原结果1778 passed/2旧夹具失败/3 skipped，仅将`client_test.go`两处`scan_after_seq`从0改为7后，两项原失败及5项相关回归、vet通过；保留原红证据，未将定向绿测记为全量重跑通过，重叠集合不累计 |
+| TS/Node | 辅助诊断状态35/35、真实辅助observer定向63项、类型检查和build通过。最终源码与产物随1324文件快照同步核验；本轮S13 floor补丁在Ubuntu离线构建及294项定向回归通过（含5项S13），最小3文件已部署两TS测试桥，证据`ts-floor-isolated-20261107T193245Z-fc8608/`。真实断线与S14结果单列，未以JS结果替代TS验收 |
+| JS/Browser源码 | 辅助诊断状态/背景通道90/90；超页重复`sync.error`以3个既有文件最小修复，TDD先红后绿，受影响712项、类型检查及Browser build通过。最终bundle另完成真实Chromium定向验收。本轮修复逐次解密查询重复写IK，session在本机及Ubuntu离线Docker中38/38通过，tsc及Browser build通过；本机证据`js-ik-hotpath-20261107T191928Z/`，已部署本任务两JS测试桥，385个产物文件SHA一致，后续矩阵待续跑。重叠测试不累计 |
+| Launcher | 控制监督单测文件137 passed；生命周期/受控启动两个文件104 passed；py_compile、Ruff关键错误检查及差异检查通过。仅开关热应用、精确诊断确认和冷/混合重启已有回归；Ubuntu四SDK在线开关E2E通过，Gateway切换前后PID均为66；此前135项为历史计数；缺省开启与显式关闭保留的Linux定向18 passed，复用既有热应用与冷/混合重启边界，证据`default-enabled-linux-frozen-20261108T095337Z/result.json` |
+| Console | Gateway开关持久化与参数校验定向1项通过；配置草稿Node测试4/4通过。S27真实Chromium页面503和匿名401通过，3次配置SHA一致、合法配置写入0；真实SQLite保存失败handler本机及Ubuntu离线验证通过；恢复驱动本机/Ubuntu各71项通过，隔离B未应用→同实例恢复已在Ubuntu通过，见`s27-b-only-20261108T032300Z/`；本轮缺省开启、持久化及作用域优先级的Ubuntu离线3个顶层`-race`测试与vet通过，证据`default-enabled-linux-frozen-20261108T095337Z/result.json`，不计作在线配置场景验收 |
+| Gateway | 分页附加字段预留修复已部署，Ubuntu定向race 20个顶层测试及`go vet`通过。writer完成回调与普通RPC互等`writeMu`已用atomic计数最小修复，TDD先红后绿，Ubuntu 62个顶层race及vet通过并部署；含2→1→0→2真实WebSocket压力回归。本轮S10/S20/S21/S24新增4个顶层回归Ubuntu `-race -count=10`、全部`TestSync -race`及vet通过，111文件SHA核对；证据`s10-s20-s21-s24-race/`，重叠集合不累计；本轮缺省开启、显式关闭保留及仅双能力协商成功可用的Ubuntu离线2个顶层`-race`测试与vet通过，证据`default-enabled-linux-frozen-20261108T095337Z/result.json`；该包162个冻结源码及9个工作区文件SHA一致。同Gateway内AID＋设备跨slot共享辅助上限的Linux全部`TestSync -race`，按执行stdout记录为28个顶层、含子测试60 passed及2个外部夹具skipped；无独立artifact，不记为E2E |
+| Message/Group | 可信`_auth.pull_response_row_overhead_bytes`已计入整页、裁剪和首条超限判断，保留游标/coverage与Gateway最终硬上限；Ubuntu Message 28、Group 12个顶层race及vet通过。首次空volatile cursor改为空字符串后，Ubuntu cmd 8、P2P 28个顶层race/vet通过并部署。Group `UseNumber`＋`json.Number`页预算修复已加载，RPC 5、Service 12个顶层定向race及vet通过；全包race检出既有handler `_auth` map竞争，未扩修。本轮基于488文件冻结源修复4条SQL的`TO_BASE64` LF，真实MySQL Red→Green、定向race、vet及build通过，派生镜像已部署并完成Chromium冷SPK恢复 |
+| Runner | 既有75 passed及游标摘要52 passed；S14后续修复持久Pull统计混入volatile与Go采样过快触发本地8/s保护，两次TDD后最新35 passed。S13 新增水位/公平性证据回归定向14 passed，相关 Python `py_compile`、TS/JS `npx tsc --noEmit` 和 `git diff --check` 通过；Group 水位摘要保留 retention 与 join 信息，finite runner 按 raw Pull 顺序记录各流进展及最长观测间隔，并拒绝未覆盖目标水位的结果。沿原 checkpoint 续跑，不重发已接受消息，原失败与清理记录保留；分页字段验收新增Forward三标志、volatile-only双标志与Tail契约验证，184项观察/29项batch回归通过；测试桥在回调入口绑定观察窗口，保留实际重复记录。S15 native真实验收继续；重叠集合不累计；最终`resume2/runner-validation.result.json`记录707个唯一节点按484/21/1/1/200分段断点通过，索引完整且无重复；不是全量重跑，缺`cases.inbox-migration.json`及fsync拖慢0.3秒deadline的两次原首败保留，完整来源为`sdk-s05-final-incremental-20261108T045019Z-resume2/` |
+| 构建与同步 | 分页修复803源码SHA一致；Gateway死锁与Message空cursor修复已部署，原运行镜像为`docker-deploy-kite:sync-volatile-cursor-20261107`（`ea0c856c3dbdbda94fbc03c15d8535b2a392e27b5a460ffb6ae364401ba2c8ff`），本轮已切换到下述LF修复镜像。Group页预算补丁运行二进制已核验进程SHA及attach日志，对应`docker-deploy-kite:sync-group-wire-budget-20261107`已构建（`e6bd5bbbd3ed828e0447da6a1711996fab85229b613d42b195e766ea1293515e`）。本轮LF修复派生镜像`docker-deploy-kite:sync-group-canonical-base64-20261108`已构建并部署（`68547bf16a49a621807baf4c83cf6448655e720641cb0d7f7beeb95ea93c3900`）；部署前后身份挂载、数据库来源及环境键值不变，Group活进程SHA匹配候选产物。历史1324文件快照核对见`sdk-final-freeze-20261107T131552Z.verify.json`，不替代后续新增测试源码核对。前一版统一runtime `sdk-unified-runtime-s05-s09-20261108T021418Z/sdk`已保留八桥AID/device/slot、身份挂载及JS本地存储状态部署，进程/源码/产物SHA核验见该目录`deployment-result.json`和`deployment-sha-verification.json`；该版archive/manifest/provenance SHA256依次为`6cab1fe924022eae5883724af3ec94983bba7ce010a8a309ee5f54d3b115564b`、`404e694c341a2a9301577c1e0955028c96af089aa1fb0b3dbb8a0e2fd891dfa7`、`a80f5ebd6824e6192f986f1ed958835aa3b3e2d3d8e8b14ebf84ee897bb26211`；构建时`result.json`的not_deployed状态由后续部署证据更新；后续最终增量`sdk-s05-final-incremental-20261108T045019Z-resume2/`逐tar成员核对3313文件路径及内容SHA与manifest一致，仅11项overlay＋Go桥二进制共12项差异；`deployment-result.json`为`deployed_identity_preserved`，更新Python/Go四桥，其余TS/JS四桥未变。归档/manifest/provenance SHA256依次为`32cb5f00506c7a3053a7638b88625d8dbe55276f6f6f57be1dc295d91d113f6b`、`4f67fc55ed525af8fc1cd8e1a7ac6125eaf6bc297d7f4c2eb1e47adcb81f65b5`、`e26246fa7d088761290d72b7b2b22f2e5bb9dd426284e17ca59c73608c57cebe`；源码/产物对应见`source-artifact-correspondence.json` |
+
+服务端证据位于 `docker-deploy/test-artifacts/sync-channels-20261107/`：`page-overhead-build/result.json`、`gateway-inline-deadlock-build/result.json`、`inline-writer-deployment.json`、`message-volatile-cursor-build/result.json`、`group-wire-budget-build/result.json`、`s10-s20-s21-s24-race/result.json`及本轮LF修复`group-base64-canonical-20261107T193845Z-c607f9/summary.json`；构建与部署按各自时间记录。Group原失败checkpoint修复后续跑完成260条，28个真实辅助成功页、local/server ACK均260；该RPC重叠采样只证明功能。Go测试JSON另见 `aun-sdk-core/tests/cross-sdk/artifacts/sync-go-build/go-sync-final-tests.json`，以上不替代完整服务回归。
+
+Ubuntu控制面用例 `sync-console-persisted-toggle-four-sdk` 已通过：持久化关闭、开启并恢复原配置，四 SDK 主连接 ID 全程不变，策略辅助额度随开关在 0/2 之间更新，Gateway `service_instance_id` 保持不变；因此单独切换该配置不需要重启 Gateway。原始结果为 `attempt-20261107T105932Z-e9bc85d4/results.json`，本地归档 `docker-deploy/test-artifacts/sync-channels-20261107/control-toggle-results.json`。分页修复后，原 260 条 checkpoint 续跑全部交付，7 个真实辅助成功页，local/server ACK 均为 260；结果为 `attempt-20261107T115854Z-7f7d51a5/results.json`，本地归档同目录 `page-budget-python-resume-results.json`。该次只证明功能及 RPC 并行采样，不作为性能验收通过。
+
+| 验收项 | 已有结果与剩余边界 |
+| --- | --- |
+| 四端辅助断线与跨SDK | 四端512条真实辅助断线已分段通过：Python在`attempt-20261107T122615Z-33af681d`内checkpoint completed，该父控制用例随后TS失败的整体判定保留；TS/JS/Go本地结果分别为`ts-volatile-cursor-resume-results.json`、`js-volatile-cursor-fault-results.json`、`go-volatile-cursor-fault-results.json`，辅助成功页7/5/3、local/server ACK均512，真实关闭后主ID/策略不变、配置恢复。64个基础矩阵唯一case均有通过attempt：原37项、retry38新trace及remaining39的26项；remaining39本地镜像与远端SHA匹配，26/26通过且配置恢复，原第38项首次失败仍保留。四端完整场景尚未签收 |
+| 原Python512条失败与恢复 | 原失败`attempt-20261107T120003Z-8ce06439/results.json`保留：辅助断线后主连接续拉，inbox350/wire378，随后`meta.ping`写响应10秒超时。死锁修复部署后只读原checkpoint恢复全部512条，未重发，local/persisted/server ACK872；证据`old512-recovery-20261107T122444Z.json`及`.persisted.json`。恢复不改判旧故障用例，新的Python辅助断线证据单列 |
+| 真实Chromium | 首轮`20261107T131417Z-a3940bec`通过；最终bundle复验`chromium-run-20261107T135932Z-a0c6c191/`的JSON报告为1 passed、0 skipped/flaky，browser/control exit0且配置恢复。独立附件与`verified-summary.json`证明辅助成功页1、剩209条时真实close、随后主路径5页；260条唯一ID/正文/seq/发送者正确，expected/server/local/persisted ACK均260，主ID/策略/辅助建连数不变 |
+| S06/S08/S22路由、策略代际与关闭竞态 | Ubuntu私有快照中Python 24、TS 24、JS整文件114 passed/2 skipped、Go 24入口子测试及1项组合`-race`通过；本机Python 96/2、TS 61/2、JS 114/2 skipped，Ruff/tsc/vet通过。证据`s06-s08-s22-20261108/run-011211/result.json`。范围为真实Transport observer接coordinator的协议/单测，不连接AUN；JS为jsdom，最终存储ACK由既有E2E覆盖 |
+| S07/S11动态授权、暂停恢复与主RPC | Ubuntu私有网络通过：真实NewServer Gateway、测试Auth/Message服务及四SDK真实认证/Transport/调度；Python/TS/Go/Chromium均通过，854个源码文件SHA匹配。验证额度0→1→2→0→2、暂停恢复期间不做SDK业务探测、主连接ID稳定、暂停时普通主连接ping可用、预算归零；JS实际运行Chromium。证据`s07-pressure-20261108/acceptance.json`。这是Gateway＋SDK夹具验收，不是完整AUN服务E2E |
+| S13水位与公平性证据 | 发现Go/TS/JS允许`floor`大于`scan/after`；局部生产修复后四端定向验证通过。本机Python 17、TS 371、JS 296、Go 8及vet通过；Ubuntu隔离测试Python 13、TS 5、JS 5、Go `-race` 8个顶层测试通过，451个源码与144个测试文件SHA匹配，`network=none`。新增 runner 定向14 passed，补齐 Python Group retention/join 水位摘要、请求窗口、peer 页连续覆盖到目标水位检查，以及基于 raw Pull 顺序的有限负载逐流进度/最长等待证据；不添加计划外数值门槛。首次 Python 快照缺`test_client.py` helper 导致失败，保留失败记录并续跑余下用例；定向测试不等于完整 AUN 服务 E2E。Group 晚加入设备的 visibility E2E 仍未覆盖。汇总`s13-peer-coverage-20261108/ubuntu/result.json`；归档`s13-summary.json` SHA256=`5A4DABB0E0DDA2C971E61769FEFF98DC668359670035D8C23E16483AF8CCF989` |
+| S15密钥与群可见边界 | P2P旧epoch `0,nil`和Group `-32000`/data字段检查已通过；Go cold group SPK Ubuntu `-race`定向测试通过，日志`s13-peer-coverage-20261108/go-group-spk-restore-ubuntu.log`。Python/TS/JS cold定向各1项、TS/JS类型检查及Browser构建通过。原真实Chrome 3DH/device检出Group MySQL `TO_BASE64` LF，首败证据`s15-cold-spk-20261108/acceptance.json`保留。4条SQL修复已部署，运行镜像`68547bf16a49a621807baf4c83cf6448655e720641cb0d7f7beeb95ea93c3900`；真实Chromium冷恢复1 passed、0 skipped，证明IndexedDB原SPK私钥恢复、冷加载解密、History不推进ACK、Forward唯一回调及提交后ACK。证据`s15-cold-spk-final-20261108/{browser.playwright.json,js-browser.stdout.log}`，部署核验在该目录`deployment-20261108T020922Z/`；native验收继续，不签收整个S15 |
+| S16跨主体公平与共享预算 | Ubuntu私有网络中真实NewServer Gateway＋测试Auth/Message服务通过，Python、TS、Go race、JS jsdom及真实Chromium均exit 0，1000个源码SHA匹配。证据`s16-budget-20261108/result.json`；这是Gateway＋SDK夹具验收，不是完整AUN服务E2E |
+| S26在线开关及快速切换 | runner本机TDD 48 passed，Ruff/AST通过；Ubuntu真实E2E待共享runtime空闲后执行，当前仅实现及测试准备，不记为场景通过 |
+| S23页面中断与回收 | Ubuntu隔离真实SDK＋WebSocket协议夹具通过：Python 2项、TS 2项、Go race 1项、真实Chrome 1项；451个源码文件SHA匹配。证据`s23-partial-frame-20261108/`含机器报告与命令，运行`network=none`；范围是隔离集成，实际AUN服务E2E另行验收 |
+| S03持续新消息 | 本机runner定向130 passed；显式来源准备脚本5项夹具、Ruff及Ubuntu来源核验通过，当前ready38/remaining26、matrix_complete=false，保持401×256B、live8/0.5秒、120秒。证据`s03-explicit-sources-20261107T194216Z-499338/`；真实S03 E2E未运行，与基础64项矩阵分别签收 |
+| S17新旧兼容 | 旧 SDK→当前部署 Gateway 原运行 9 项通过，第 10 项旧 Go P2P E2EE 超时记录保留；`results/tmpfs-remaining/s17-old-client-20261107T211216Z-5996d2/result.json` 补跑剩余 7 项通过，16 个唯一 case 均已有通过记录。tmpfs 部分仅证明协议互通，不代替 Go 磁盘持久化验收。当前SDK→旧Gateway的8项P2P（四SDK×明文/E2EE）均已有通过记录，各128条且local/server ACK一致；Group首轮已建群并接受2条，第3条发送返回“操作结果未知”，已首败停止并核查，反向Group与整个S17尚未签收。证据位于`s17-isolated-20261107T192015Z-5cd05c/attempts/`：Python两项见`reverse-python-ts-checkpoint-resume-20261108T024015Z-1f8cc0/checkpoint/result.json`，其余六项见`reverse-final-new-js-device-20261108T031719Z-56e0fa/results/s17-new-client-20261108T031744Z-623752/result.json`；Group首败见`reverse-final-groups-20261108T031945Z-5821f0/results/s17-new-client-20261108T032544Z-485b0a/result.json`及该attempt的`runner.log`，原失败与未知发送记录保留 |
+| S27已保存未应用与恢复 | Ubuntu独立B实例的node作用域配置验收通过：持久保存true后，暂停的B报告unknown；恢复后同PID、同service_instance_id精确应用该配置版本，再恢复false。共享service绑定保持原值，测试B及其新node绑定已清理。证据`s27-b-only-20261108T032300Z/{result.json,checkpoint.json,cleanup-api-proof.json,execution.log}`；此前页面503/401及SQLite保存失败证据保留，S25重启和S28迁移另行验收 |
+| 性能与公平性 | 无补拉 RPC 基线各 40 样本：Python P95 4.782ms、TS 4.310ms、JS 3.298ms；Go 每秒采样，P95 5.343ms。S13 finite runner 已补各流 Pull 顺序、进度和最长观测间隔校验，实际负载未签收。S05先前缺`history.completed_pages`及netem清理字段的问题已修；后续窗口的重复记录已证含reset前阻塞回调，测试工具入口归属与提前连接时序按TDD修复，Go明文peer ACK的`seq`→`up_to_seq`字段修复及四端定向回归已通过，并随最终统一runtime部署。S05最终runtime窗口已运行，load尚未启动即首败停止，验收未签收；证据`s05-slow-consumer-prepared-runtime-v5-20261108T021534Z/executions/codex-s05-v5-fresh-20261108T032000Z-enabled/result.json`，首败记录保留。该次 qdisc 已按容器/接口及队列归属精确清理，四接口恢复 `noqueue` 且无 filter，原失败保留，恢复证据为该次 `netem/manual-recovery-20261108.json`。S19 尚未运行；同负载开关对照、长期 RSS/堆及跨流公平性仍无完整结果 |
+| S14与完整场景 | 四端S14已通过，证据`s14-final-evidence/attempt-20261107T135624Z-759e74bd/{results.json,s14-runtime-evidence.json}`：各3唯一回调、1次`sync.error`、停流不跳ACK、健康流继续，显式恢复后各1次真正persistent后续Pull。Go从原receiving继续，未重发且未重启桥；control恢复true、无恢复错误。64项基础矩阵逐case对账通过：原前37项、独立retry38新trace及remaining39中26项合计64个唯一case ID；原第38项120秒首次超时保留为失败历史。260条晚完成回调及ACK2075已只读归档，首末回调133341ms，原118快照辅助页增12、晚完成另增2，证据`late-completion-sync-ts-go-p2p-e2ee-20261107T191715Z-2d2e25a0/`。修复后新trace保持260×4096B及120秒限制并通过，9个真实辅助页、local/server ACK2335、260回调首末1950ms，本机证据`post-fix-retry38-evidence/post-fix-same-load-evidence/`；remaining39结果镜像已逐ID核对、配置恢复。有限负载/性能、S09、S15 native、S25/S28尚未完成；S15 Chromium冷SPK与S27同实例恢复已有独立通过记录，G0—G5和S01—S28总清单保持未签收 |
+
+### 9.5 本轮积压门槛、短连接与统计验收
+
+本轮补充如下冻结规则；第 9.4 节按原额度产生的历史数值和证据保留，不证明单辅助连接、namespace 串行及下列改动后的四 SDK 和 Ubuntu E2E 验收通过。
+
+| 项目 | 验收标准 |
+| --- | --- |
+| Gateway连接上限 | 本轮 Gateway `max_aux_channels` 只取0/1；关闭开关必0，开启允许上限1，压力仍可降0/回收；同 Gateway 本 AID＋设备跨 slot、主会话建立中及已建立合计最多1，每设备最多1 |
+| SDK连接能力与RPC并发 | SDK 遵从策略支持0..N条辅助，按已确认的当前协议上限 N≤2，拒绝大于2的策略；Gateway 本轮只下发0/1。进程池每AID最多2条、总计最多8条。同 namespace 网络 Pull 串行，不同 namespace 可按授权并行；主辅共享16/8/4/4、历史Pull最多3及字节/速率预算，不把当前 Gateway 每设备连接上限1解释成并发总1 |
+| 四 SDK 多流门槛 | 当前真实待拉的唯一 peer／群消息／群事件流至少 4 条，当前请求属于其中才可使用辅助；同流重复入口只计一次，清空或失败后及时更新，不累计已拉条数 |
+| 四 SDK 单流门槛 | 同流最新 `pending_count_lower_bound>=100` 且仍需续页；下界下降、缺省、0、迟到旧页及主会话换代均不保留过期资格 |
+| 服务端下界 | 仅普通持久 Forward、带 `max_page_bytes`，复用本次已读取、可见且去重候选的未返回量，cap 100；Message 要求 `persistent`，Group 当前 `all` 也只含持久来源；排除 force／Tail／History／control／sdk_control／volatile 及 Message 持久/临时混合来源 |
+| 无额外读取 | 不增加 RPC、SQL COUNT、查询、扫描或读取 limit；小正文 `limit+1` 只能证明 1、Group V2 可为 0，不补读凑阈值；完成仍用原分页证明 |
+| 短连接 unread hint | 普通 short 与 `history_sync` 都不触发或接收 unread hint，不注册在线消息路由；主 long 正常收取提示，短连接显式 Pull 正常 |
+| Token 与空闲 | 新辅助连接取主 client 最新有效 access token、剩余超过 30 秒，不为辅助另行登录/刷新；已认证连接不因原 token 自然到期立即断线。SDK 25 秒、Gateway 120 秒，四端空闲计时条件差异保留 |
+| 当日补拉连接 | `traffic.daily_history_sync_connections` 按 UTC+8 自然日记录成功建连次数，同 issuer 共享，跨 Gateway 按 scope/date 取最新日最大值；失败不计、重建计次 |
+| 在线补拉连接 | `traffic.connections.history_sync` 为本 Gateway 当前在线数，可相加；旧字段缺失显示 `—`，复用原分钟批量持久化，不加定时任务 |
+
+本轮进度：Gateway／Console 统计已完成定向验证；Console httpserver 全包与 vet、前端统计测试 9/9 及构建通过。已修复 Python 历史 Pull 别名未进入统一调度和同流串行、事件背景误入历史调度，以及 Group 短连接仍调度 unread hint 的问题。当前本机定向结果：Python 139 passed／2 skipped、TS 918 passed／2 skipped、JS 777 passed／2 skipped、Go 同步测试通过；Gateway、Message、Group 相关回归、TS／JS 类型检查、Python Ruff 与 Gateway／Group vet 通过；跨 SDK runner 同步定向 250 passed。以下前三项仅签收本机定向验证，更新后的完整 Ubuntu E2E 仍待验收。
+
+- [x] Gateway 与四 SDK 本机定向验证单辅助上限、并发建连不超额、同 namespace 串行、不同 namespace 共享辅助并行、进程池 AID 2/总计8及原总体预算。
+- [x] 四 SDK 本机定向通过 3→4 条流门槛、同流去重、流清空与失败释放、单流 99→100→0／缺省、迟到页和换代测试。
+- [x] 服务端本机回归验证下界与最终字节截页一致，普通短连接和补拉辅助连接无 unread hint，显式 Pull 和 long 提示不受影响。
+- [x] Ubuntu Docker S07/S16 单辅助 Gateway＋SDK 夹具：Python、TS/Node、Go race、JS/Chromium 各两项通过；使用真实 `group.pull`、先暂停登记多群积压再恢复，验证0/1策略、暂停恢复、每设备1条、每AID2条及进程8条共享额度和等待任务推进。相关源码及测试10项SHA匹配，汇总为 `docker-deploy/test-artifacts/sync-channels-20261107/s07fix-20261108t180903z/final-validation.json`；夹具使用测试Auth/Group服务，不替代完整AUN服务E2E。
+- [ ] Ubuntu Docker 使用本机最终源码构建，验证真实积压门槛、主连接回退及控制台当日/在线统计；首败停止、修复后断点续跑。