@agentunion/fastaun 0.5.32 → 0.5.33

package/CHANGELOG.md

@@ -6,6 +6,36 @@
 
 ---
 
+## 0.5.33 — 未发布
+
+按当前工作区未提交变更整理；四端接口、实现差异和服务依赖见 [parity 0.5.33](../python/CHANGES_FOR_PARITY.md#v0533)。
+
+### 控制消息兼容与降级
+
+- P2P／群 `control` 发送在未协商分类能力时，发送前移除外层及可变保护头中的类别，按普通消息投递；已协商时保留控制类别。明文控制消息继续使用明文发送路径，需配套 Gateway／Message／Group 正确路由及确认发送者身份。
+- P2P `sdk_control` 缺少分类或协议协商时移除外层路由类别，保留 E2EE 信封中的类别、协议及版本，由接收 SDK 消费。明文 `sdk_control` 和群 `sdk_control` 仍在本地拒绝，参数与受保护元数据冲突仍报错。
+- 解密后的消息未携带受保护 `message_class` 时按 `normal` 校验，修复普通消息及群 volatile 普通流的类别误判；群普通 TTL 发送不再受到控制类协商门禁影响。
+
+### Ownership 批量申请与审批
+
+- `bindOwneraid`、`bindSubaid`、`transferSubaid` 增加可选 `{ batchId }`，使用 UUIDv4；请求消息、任务持久化及结果携带 `batch_id`。批次纳入固定任务上下文校验，重放请求不能增删或更换批次；原有单次调用保持兼容。
+- 新增 `acceptOwnershipRequests(operationIds)`／`rejectOwnershipRequests(operationIds, reason?)`，去重后逐项审批并返回每项任务或错误及汇总；批次用于应用聚合展示，每项沿用已认证请求和现有 Ownership 流程。导出 `OwnershipRequestOptions` 与 `OwnershipApprovalBatchResult` 类型。
+
+### agent.md 与共识查询
+
+- 连接后先读取本地 `agent.md`；本地正文与已观察 ETag／校验记录一致时复用，不再因新 Client 或连接成功强制首查。共识查询可复用本地持久快照，并核对锁状态、ETag、正文摘要及关系声明；未达共识、缺失、内容变化或 `force=true` 时重新查询。
+- 群／组织首访同样优先复用有效本地共识；绑定、审批、转移等管理流程保留强制刷新。Ownership 事件清除相关快照，异步查询完成后检查 Client 与观察代际，避免旧结果覆盖新状态。
+
+### Storage 批量 ACL 与缓存
+
+- VFS 和 LowLevel 的 `setAcl`／`removeAcl` 增加 `granteeAids` 数组，映射 RPC `grantee_aids`；保留 `granteeAid`／`grantee_aid` 兼容。数组可含一个或多个 AID，`maxUses` 对每个被授权 AID 分别生效，批量处理依赖配套 Storage 服务。
+- ACL 授予／撤销 RPC 失败时同样失效受影响路径的读缓存，覆盖服务端已完成部分操作后报错的情况；保留原始错误和无关路径缓存，Raw／LowLevel／VFS 共用该处理。
+
+### 版本与验证
+
+- 包配置、锁文件、运行时及相关测试版本引用统一为 `0.5.33`；版本升级阶段四端版本一致性检查、Node 加密回环 17 项和类型检查通过。
+- 补充控制消息降级、Ownership 批次／本地共识、批量 ACL 与失败缓存失效的回归覆盖；跨 SDK 工具增加分类协商开关及线上发送观测。本轮仅整理文档，未重跑这些功能的全量或跨 SDK 验收。
+
 ## 0.5.32 — 未发布
 
 相对已发布 `0.5.31` 整理，源码增量以 `2df732673` 为对照；四端实现与验证边界见 [parity 0.5.32](../python/CHANGES_FOR_PARITY.md#v0532)。

package/_packed_docs/CHANGELOG.md

@@ -6,6 +6,36 @@
 
 ---
 
+## 0.5.33 — 未发布
+
+按当前工作区未提交变更整理；四端接口、实现差异和服务依赖见 [parity 0.5.33](../python/CHANGES_FOR_PARITY.md#v0533)。
+
+### 控制消息兼容与降级
+
+- P2P／群 `control` 发送在未协商分类能力时，发送前移除外层及可变保护头中的类别，按普通消息投递；已协商时保留控制类别。明文控制消息继续使用明文发送路径，需配套 Gateway／Message／Group 正确路由及确认发送者身份。
+- P2P `sdk_control` 缺少分类或协议协商时移除外层路由类别，保留 E2EE 信封中的类别、协议及版本，由接收 SDK 消费。明文 `sdk_control` 和群 `sdk_control` 仍在本地拒绝，参数与受保护元数据冲突仍报错。
+- 解密后的消息未携带受保护 `message_class` 时按 `normal` 校验，修复普通消息及群 volatile 普通流的类别误判；群普通 TTL 发送不再受到控制类协商门禁影响。
+
+### Ownership 批量申请与审批
+
+- `bindOwneraid`、`bindSubaid`、`transferSubaid` 增加可选 `{ batchId }`，使用 UUIDv4；请求消息、任务持久化及结果携带 `batch_id`。批次纳入固定任务上下文校验，重放请求不能增删或更换批次；原有单次调用保持兼容。
+- 新增 `acceptOwnershipRequests(operationIds)`／`rejectOwnershipRequests(operationIds, reason?)`，去重后逐项审批并返回每项任务或错误及汇总；批次用于应用聚合展示，每项沿用已认证请求和现有 Ownership 流程。导出 `OwnershipRequestOptions` 与 `OwnershipApprovalBatchResult` 类型。
+
+### agent.md 与共识查询
+
+- 连接后先读取本地 `agent.md`；本地正文与已观察 ETag／校验记录一致时复用，不再因新 Client 或连接成功强制首查。共识查询可复用本地持久快照，并核对锁状态、ETag、正文摘要及关系声明；未达共识、缺失、内容变化或 `force=true` 时重新查询。
+- 群／组织首访同样优先复用有效本地共识；绑定、审批、转移等管理流程保留强制刷新。Ownership 事件清除相关快照，异步查询完成后检查 Client 与观察代际，避免旧结果覆盖新状态。
+
+### Storage 批量 ACL 与缓存
+
+- VFS 和 LowLevel 的 `setAcl`／`removeAcl` 增加 `granteeAids` 数组，映射 RPC `grantee_aids`；保留 `granteeAid`／`grantee_aid` 兼容。数组可含一个或多个 AID，`maxUses` 对每个被授权 AID 分别生效，批量处理依赖配套 Storage 服务。
+- ACL 授予／撤销 RPC 失败时同样失效受影响路径的读缓存，覆盖服务端已完成部分操作后报错的情况；保留原始错误和无关路径缓存，Raw／LowLevel／VFS 共用该处理。
+
+### 版本与验证
+
+- 包配置、锁文件、运行时及相关测试版本引用统一为 `0.5.33`；版本升级阶段四端版本一致性检查、Node 加密回环 17 项和类型检查通过。
+- 补充控制消息降级、Ownership 批次／本地共识、批量 ACL 与失败缓存失效的回归覆盖；跨 SDK 工具增加分类协商开关及线上发送观测。本轮仅整理文档，未重跑这些功能的全量或跨 SDK 验收。
+
 ## 0.5.32 — 未发布
 
 相对已发布 `0.5.31` 整理，源码增量以 `2df732673` 为对照；四端实现与验证边界见 [parity 0.5.32](../python/CHANGES_FOR_PARITY.md#v0532)。

package/_packed_docs/sdk/0.5.33-SDK/345/272/224/347/224/250/351/233/206/346/210/220/346/214/207/345/215/227.md

@@ -0,0 +1,316 @@
+# AUN SDK 0.5.33 应用集成指南
+
+面向应用开发者，说明从仓库 0.5.32 基线升级到当前目标 0.5.33 的接入变化。本文对照 `072b7c69f` 与截至 2026-11-07 的未提交源码；0.5.33 为未发布目标，安装产物和配套服务部署需分别核对。四端实现差异见 [parity 0.5.33](../../python/CHANGES_FOR_PARITY.md#v0533)，内部流程见[开发与移植指南](0.5.33-SDK开发与移植指南.md)。
+
+## 1. 本版变化与整体架构
+
+| 本版变化 | 应用如何使用 |
+| --- | --- |
+| 应用控制消息兼容 | 保留原 `control` 调用，SDK 按协商结果选择分类或普通投递；明文仍可发送 |
+| Ownership 批量申请／审批 | 同批申请传同一 UUIDv4，Owner 归组展示后一次提交操作 ID 列表 |
+| agent.md 与共识本地优先 | 保留本地身份仓库；新 Client 和连接成功不再触发无条件首查 |
+| Storage 多 AID ACL | VFS／LowLevel 直接传列表，单个 AID 的旧参数继续可用 |
+| Python 专项 | 拥塞等待采用新策略，容量压测使用新增 `bench run/report` |
+
+EventService、设备租约、有界 fanout 和原有 VFS Cache 已由 0.5.32 提供，接入方法继续参考[上一版应用指南](0.5.32-SDK应用集成指南.md)。
+
+```mermaid
+%%{init: {"theme":"base","themeVariables":{"fontFamily":"Microsoft YaHei, sans-serif","fontSize":"14px"},"flowchart":{"curve":"linear","nodeSpacing":24,"rankSpacing":32}}}%%
+flowchart TB
+    subgraph APP["各 AID 的应用进程"]
+        direction LR
+        U["Owner 应用<br/>批次展示与审批"]:::app
+        A["Agent 应用<br/>绑定 / 消息 / 文件"]:::app
+    end
+    subgraph SDK["每个 AID 各自持有 SDK"]
+        F["AUNClient 门面"]:::entry
+        O["Ownership<br/>批次 / agent.md / 本地共识"]:::owner
+        R["消息发送与接收<br/>分类协商 / E2EE / 应用回调"]:::entry
+        V["Storage VFS<br/>多 AID ACL / 读缓存"]:::storage
+        E["EventService · 继承 0.5.32<br/>Pub / Bus / Sub"]:::event
+        F --> O & R & V & E
+    end
+    G["Gateway<br/>认证会话 / 可信发送者 / RPC 转发"]:::gateway
+    subgraph SERVICES["AUN 服务"]
+        direction LR
+        M["Message / Group<br/>P2P / 群消息 / TTL 投递"]:::infra
+        N["Name Service<br/>归属关系 / 权威名片状态"]:::infra
+        S["Storage<br/>对象 / ACL / 条件写入"]:::infra
+        C["Credential<br/>事件授权凭证登记 / 状态证明"]:::infra
+    end
+    U & A --> F
+    O & R & V & E --> G
+    G --> M & N & S & C
+    classDef app fill:#eff6ff,stroke:#93c5fd,color:#1e3a8a,rx:10,ry:10
+    classDef entry fill:#f0f9ff,stroke:#7dd3fc,color:#0c4a6e,rx:10,ry:10
+    classDef owner fill:#eef2ff,stroke:#a5b4fc,color:#312e81,rx:10,ry:10
+    classDef storage fill:#fff7ed,stroke:#fdba74,color:#9a3412,rx:10,ry:10
+    classDef event fill:#f0fdf4,stroke:#86efac,color:#166534,rx:10,ry:10
+    classDef gateway fill:#f5f3ff,stroke:#a78bfa,color:#4c1d95,rx:10,ry:10
+    classDef infra fill:#f8fafc,stroke:#cbd5e1,color:#334155,rx:10,ry:10
+    style APP fill:#ffffff,stroke:#e2e8f0
+    style SDK fill:#ffffff,stroke:#e2e8f0
+    style SERVICES fill:#f8fafc,stroke:#e2e8f0
+```
+
+图中合并表示相同的 SDK 能力；每个 AID 的身份、连接和缓存分别保存。批次归组和审批界面由应用完成，归属共识仍由原有 Ownership 流程确认。EventService 的目录、订阅表和分发仍在 Bus SDK，Message 只负责承接实例租约及通用消息投递。
+
+## 2. 示例前提与四端入口
+
+以下 TypeScript 片段使用应用已加载身份且连接就绪的 Client，加载与连接沿用[快速开始](01-快速开始.md)。Owner 与新 Owner 为 human／agent 身份，两个 Agent 已符合 Ownership 适用条件。
+
+```ts
+import type { AUNClient } from '@agentunion/fastaun';
+declare const ownerClient: AUNClient;
+declare const nextOwnerClient: AUNClient;
+declare const firstAgent: AUNClient;
+declare const secondAgent: AUNClient;
+const ownerAid = String(ownerClient.aid);
+const nextOwnerAid = String(nextOwnerClient.aid);
+```
+
+片段分别运行在相应身份的应用中；跨进程通过 SDK 收到的事件或应用界面传递选择结果。
+
+| 用途 | Python | TypeScript／Browser JS | Go |
+| --- | --- | --- | --- |
+| 申请绑定 | `bind_owner_aid(..., batch_id=...)` | `bindOwneraid(..., { batchId })` | `BindOwneraid(..., OwnershipRequestOptions{BatchID: ...})` |
+| Owner 发起绑定 | `bind_sub_aid` | `bindSubaid` | `BindSubaid` |
+| 转移 | `transfer_sub_aid` | `transferSubaid` | `TransferSubaid` |
+| 批量同意／拒绝 | `accept_ownership_requests/reject_ownership_requests` | `acceptOwnershipRequests/rejectOwnershipRequests` | `AcceptOwnershipRequests/RejectOwnershipRequests` |
+| ACL 列表 | `grantee_aids` | `granteeAids` | `GranteeAIDs` |
+| 共识查询 | `check_ownership_consensus(..., force=True)` | `checkOwnershipConsensus(aid, true)` | `CheckOwnershipConsensusWithOptions(..., OwnershipConsensusOptions{Force: true})` |
+
+Go 网络及等待方法还需传入 `context`。原有单次 Ownership 调用和 ACL 单 AID 参数保留。
+
+## 3. 应用控制消息：保留调用，按能力投递
+
+### 3.1 明文或加密的页面响应
+
+发送应用控制消息时继续声明 `message_class: 'control'`，由 SDK 处理协商和加密位置。例如向 Owner 发送一条有期限的明文页面响应：
+
+```ts
+await firstAgent.call('message.send', {
+  to: ownerAid, message_class: 'control', encrypt: false, ttl: 60,
+  payload: { type: 'menu.response', request_id: 'request-1', data: { ready: true } },
+});
+```
+
+需要加密时改为 `encrypt: true`。群应用控制使用既有 `group.send` 入口，并按群能力协商；应用无需自己移动保护头或构造 E2EE 信封。
+
+```mermaid
+sequenceDiagram
+    autonumber
+    participant A as 发送应用
+    participant S as 发送 SDK
+    participant G as Gateway
+    participant M as Message / Group
+    participant R as 接收 SDK
+    participant U as 接收应用
+    A->>S: send(control, encrypt, ttl)
+    alt 已协商应用控制类别
+        S->>G: 保留类别；按 encrypt 选择明文或 E2EE
+    else 未协商应用控制类别
+        S->>S: 构造请求时去掉外层及可改写保护头的类别
+        S->>G: 普通消息投递，保留正文、TTL 和设备目标
+    end
+    G->>M: 可信发送者身份与请求
+    M->>R: 在线 Push 或后续 Pull
+    R->>U: 通过原有消息事件交付
+```
+
+接收应用继续注册 `message.received`、`group.message_created` 等已有事件；按业务 `payload.type` 识别页面响应。降级后不依赖 `message_class` 仍为 `control` 来识别业务。
+
+### 3.2 SDK 控制消息由 SDK 管理
+
+| 消息 | 分类／协议能力已协商 | 未协商 |
+| --- | --- | --- |
+| 普通 P2P／群消息 | 普通投递 | 普通投递；普通群 TTL 不再被分类门禁阻断 |
+| 明文／加密的应用 `control` | 保留控制类别 | 构造请求时降级为普通投递 |
+| P2P 加密 `sdk_control` | SDK 校验并消费 | 外层路由降级，E2EE 保护头保留 SDK 类别及协议，仍由 SDK 消费 |
+| 明文 `sdk_control`、群 `sdk_control` | 拒绝 | 拒绝 |
+
+应用通过 `EventService`、Ownership 等门面调用 SDK 功能。SDK 控制消息不会因为普通通道投递就交给应用消息处理器。已签名的信封保持受保护内容，由配套服务完成通道路由；部署升级时应同时核对 Gateway、Message 和 Group 的兼容逻辑。
+
+## 4. Ownership：一批申请，一次选择审批
+
+### 4.1 Owner 先接收并按批次展示
+
+注册处理器后，SDK 交付的 `ownership.request` 已经过原请求校验。以下集合是应用的待审批列表；没有批次的旧请求以自身操作 ID 单独展示。
+
+```ts
+type RequestItem = { batch_id?: string; operation_id: string; sub_aid: string };
+const requests = new Map<string, RequestItem[]>();
+ownerClient.on('ownership.request', (payload) => {
+  const item = payload as RequestItem;
+  const key = item.batch_id ?? item.operation_id;
+  requests.set(key, [...(requests.get(key) ?? []), item]);
+});
+```
+
+同一操作可能再次通知，应用列表可按 `operation_id` 合并展示。SDK 的审批接口也会对提交列表去重。
+
+### 4.2 多个 Agent 向同一 Owner 申请绑定
+
+由发起这批操作的应用生成一个 UUIDv4，并传给每个 Agent。实际使用可由同一进程里的多个 Client，也可由应用将批次号传到各进程。
+
+```ts
+const batchId = crypto.randomUUID();
+const firstBinding = await firstAgent.bindOwneraid(ownerAid, { batchId });
+const secondBinding = await secondAgent.bindOwneraid(ownerAid, { batchId });
+```
+
+Owner 收到并展示两项请求后，用户点一次同意，将选中请求的操作 ID 提交给批量接口：
+
+```ts
+const selectedIds: string[] = [];
+for (const item of requests.get(batchId) ?? []) selectedIds.push(item.operation_id);
+const approval = await ownerClient.acceptOwnershipRequests(selectedIds);
+```
+
+拒绝时调用 `ownerClient.rejectOwnershipRequests(selectedIds, '本批不予绑定')`。`batchId` 只用于申请及展示归组，审批使用已收到的 `operation_id`，不会按一个批次号自动批准后来加入的请求。
+
+```mermaid
+sequenceDiagram
+    autonumber
+    participant A as Agent A
+    participant B as Agent B
+    participant M as AUN 消息投递
+    participant O as Owner SDK
+    participant U as Owner 审批界面
+    participant N as 原有文件与归属服务
+    A->>M: bind.request(operation A, batch X)
+    B->>M: bind.request(operation B, batch X)
+    M->>O: 认证原请求，保留各自上下文
+    O->>U: ownership.request，按 batch X 展示
+    U->>O: 一次同意 [operation A, operation B]
+    loop 对列表中每个独立操作
+        O->>N: 强制核对当前关系并执行单项绑定
+        N-->>O: 当前项结果
+        O->>M: 单项回复／后续通知
+    end
+    O-->>U: total / succeeded / failed / results
+```
+
+批量结果保留每项的 `result` 或 `error`。`succeeded` 表示该次审批调用未落入失败分类，结果仍可能为 `pending`；应用应查看每项状态，通过后续 `ownership.completed` 或共识查询确认归属完成。单项失败不回滚其它项。
+
+### 4.3 批量转移给新 Owner
+
+当前 Owner 使用新的批次号发起转移，审批发生在新 Owner：
+
+```ts
+const transferBatchId = crypto.randomUUID();
+const firstTransfer = await ownerClient.transferSubaid(String(firstAgent.aid), nextOwnerAid, { batchId: transferBatchId });
+const secondTransfer = await ownerClient.transferSubaid(String(secondAgent.aid), nextOwnerAid, { batchId: transferBatchId });
+```
+
+新 Owner 按 §4.1 注册自己的请求处理器；用户确认后提交已收到的转移操作列表：
+
+```ts
+declare const selectedTransferIds: string[];
+const transferApproval = await nextOwnerClient.acceptOwnershipRequests(selectedTransferIds);
+```
+
+SDK 逐项保留原发送者、目标 Owner、关系版本和批次上下文；同一操作换批次或换内容会触发冲突。批量执行期间切换身份也不会继续用新身份批准旧请求。
+
+## 5. 新 Client 与重连：本地名片和共识优先
+
+应用保留原身份仓库及本地 `agent.md`，按原流程加载身份、连接即可。SDK 不再因“这个 Client 还没有查过”而强制访问服务器，群／组织首次访问同样复用有效本地状态。
+
+```mermaid
+flowchart LR
+    Q["连接后 / 首次查询"] --> L["读取本地 agent.md 与共识快照"]
+    L --> C{"本地记录仍一致？"}
+    C -->|"ETag / 摘要 / 关系声明一致"| H["复用本地名片及已达共识结果"]
+    C -->|"缺失 / 未共识 / 内容或 ETag 变化"| R["查询远端并更新观察"]
+    F["管理流程或 force=true"] --> R
+```
+
+本地有正文不等于已经达成归属共识；SDK 还核对已保存快照、锁状态、ETag、正文摘要、Owner 和关系版本。绑定、审批、转移、释放等管理流程继续强制核对当前状态。
+
+```ts
+const localFirst = await firstAgent.checkOwnershipConsensus();
+const current = await firstAgent.checkOwnershipConsensus(undefined, true);
+```
+
+普通展示使用默认查询；应用确需当前远端事实时显式强刷。Ownership 状态变化后 SDK 清除相关快照，本轮没有新增周期共识查询任务。
+
+## 6. Storage：一次授予或撤销多个 AID
+
+以下文件已存在且属于 `ownerClient`；传入列表即可从 VFS 贯通到 LowLevel 和 RPC。数组也可以只有一个 AID。
+
+```ts
+await ownerClient.storage.setAcl('/reports/result.json', {
+  granteeAids: [String(firstAgent.aid), String(secondAgent.aid)],
+  perms: 'r', maxUses: 10,
+});
+await ownerClient.storage.removeAcl('/reports/result.json', {
+  granteeAids: [String(firstAgent.aid), String(secondAgent.aid)],
+});
+```
+
+`maxUses: 10` 表示每个被授权 AID 各有自己的使用次数；权限、过期时间等设置应用到每项。配套 Storage 服务归一化并去重 AID，SDK 请求使用 `grantee_aids`。
+
+原调用保持可用：
+
+```ts
+await ownerClient.storage.setAcl('/reports/result.json', {
+  granteeAid: String(firstAgent.aid), perms: 'r',
+});
+```
+
+```mermaid
+sequenceDiagram
+    autonumber
+    participant A as 应用
+    participant V as VFS / LowLevel
+    participant C as SDK 读缓存
+    participant S as Storage 服务
+    A->>V: setAcl 或 removeAcl，多 AID
+    V->>S: storage.set_acl / remove_acl，grantee_aids
+    S->>S: 逐项授予或撤销
+    S-->>V: 成功结果或中途错误
+    V->>C: 两种结果都失效相关路径缓存
+    V-->>A: 返回结果或保留原始错误
+    A->>V: 按需重新查询 ACL
+    V->>S: 回源确认当前实际权限
+```
+
+批量请求发生中途错误时，可能已有部分 AID 更新成功。应用保留错误并重新查询当前 ACL，再决定如何处理剩余项；SDK 会清理相关路径缓存，保留无关路径缓存。接口字段及精简后的对象／下载票据／共享链接返回值见 [Storage RPC 手册](09-storage-rpc-manual.md)。
+
+## 7. Python 独有变化
+
+### 7.1 限流与拥塞等待
+
+| 响应条件 | Python 等待策略 |
+| --- | --- |
+| 有效正数 `retry_after_seconds/retry_after_ms` | 按服务端提示等待，取适用的较长值 |
+| 无有效提示，`-32029/-32429` 且错误文本表明队列／背压／容量拥塞 | 默认 1 秒 |
+| 其它可识别限流 | 默认 60 秒 |
+
+这项调整仅为本轮 Python 变更，TS／JS／Go 没有同等退避修改；应用写请求不会因此自动重试。应用仍需根据单次请求结果决定后续操作。
+
+### 7.2 容量压测 CLI
+
+新增 `aun bench run` 和 `aun bench report`，支持 16 种场景、套件选择、多进程、多身份通道、预算和断点续跑。将 `<issuer>` 替换为目标域，先查看计划，再启动选定场景：
+
+```sh
+aun bench run "<issuer>" --suite messaging --dry-run
+aun bench run "<issuer>" --case p2p-plain --budget 10 --run-id sdk033
+aun bench run "<issuer>" --case p2p-plain --budget 10 --run-id sdk033 --resume
+aun bench report ".aun-bench/<issuer>/runs/sdk033"
+```
+
+报告提供 JSON／HTML，区分延迟达标容量、稳态吞吐、边界区间和发压端瓶颈。`pubsub` 场景包含发压端的 Bus SDK；未验证的结果或发压端瓶颈不能当作已确认的纯服务端容量。
+
+## 8. 升级与验收
+
+| 检查项 | 验收行为 |
+| --- | --- |
+| 四 SDK 产物 | 核对目标版本 0.5.33；Browser JS 与 Node TS 使用各自包 |
+| 消息兼容 | 已协商／未协商的明文和加密应用控制可投递；普通消息继续工作；SDK 控制由 SDK 消费 |
+| 批次审批 | 同批多个 Agent 可一次选择；逐项显示结果，失败项可单独处理；最终归属以完成事件／共识为准 |
+| 本地优先 | 保存的有效共识可跨 Client／重连复用；无共识或记录变化会查询远端；管理调用强刷 |
+| 批量 ACL | 列表及旧单项调用都可用；计数按 AID 独立；部分失败后可读到实际权限 |
+| 配套服务 | Gateway／Message／Group 支持兼容路由；Storage 支持批量 ACL；原 EventService 服务依赖继续保留 |
+
+已有版本升级验证包括四端版本一致性、TS 加密回环 17 项、JS 加密回环 13 项、Go E2EE 包及对应类型／vet 检查。控制消息 runner 的 96 格脚本已纳入工作区，但本轮没有取得其完整通过产物；它只关闭发送端能力，不能代表接收端缺少能力的全部组合。详细覆盖与前序定向回归记录见 [parity 验证边界](../../python/CHANGES_FOR_PARITY.md#v0533)。本文整理不代替全量或跨 SDK E2E 验收。