@agentunion/fastaun-browser 0.5.19 → 0.5.21

package/_packed_docs/INDEX.md

@@ -1,18 +1,20 @@
-# AUN SDK Core 文档索引
-
-> 根级文档索引采用三层结构。Layer 1 用于快速定位，Layer 2 按主题交叉查找，Layer 3 给出重点文档摘要。SDK API 细节继续查看 `docs/sdk/INDEX.md`。
-
----
-
-## Layer 1：文档地图
-
-| 文档 | 定位 |
-| --- | --- |
+# AUN SDK Core 文档索引
+
+> 根级文档索引采用三层结构。Layer 1 用于快速定位，Layer 2 按主题交叉查找，Layer 3 给出重点文档摘要。SDK API 细节继续查看 `docs/sdk/INDEX.md`；P2P 保留共享 seq、按 sender 隔离游标，网络 Pull Gate 同 namespace 单飞、每客户端最多4个并行，末页独立 ACK。
+
+---
+
+## Layer 1：文档地图
+
+| 文档 | 定位 |
+| --- | --- |
+| [0.5.21 SDK 应用集成指南](sdk/0.5.21-SDK应用集成指南.md) | TypeScript 应用接入、batch 持久幂等、peer 同步、resolve/owner 展示、关系审批、凭证续期、诊断与升级验收 |
+| [0.5.21 SDK 开发与移植指南](sdk/0.5.21-SDK开发与移植指南.md) | 四端公开契约、peer 水位、流控与提交边界、frontmatter/共识缓存、原 CAS 和旧任务、checkpoint、语言差异及验收顺序 |
 | [aun测试运行指南](aun测试运行指南.md) | `agentid.pub/agentid.cn` 双域本地单实例、独立固定材料与 Tester、Go 1.24、断网 cross-SDK、三文件线上镜像替换包、开箱默认配置、一次性初始化辅助包及单节点部署 |
-| [aun公网测试运行指南](aun公网测试运行指南.md) | 可配置 issuer domain 的 Python SDK 公网 integration/E2E runner、独立身份/运行目录、TLS 与服务端公网验收衔接 |
+| [aun公网测试运行指南](aun公网测试运行指南.md) | 可配置 issuer domain 的 Python SDK 公网 integration/E2E runner、独立身份/运行目录、TLS 与服务端公网验收衔接 |
 | [aun分布式测试运行指南](aun分布式测试运行指南.md) | 当前 `kite` worktree 内的三节点、本地与公网 `agentid.pub/agentid.cn` 双域、隔离 federation、固定材料/双身份 runner、Storage OSS 验收、镜像/Compose/mount 来源预检及分布式 Tester/cross-SDK |
-| [分布式 AUN 节点与服务启动流程](../../extensions/services/docs/分布式AUN节点与服务启动流程.md) | control master / worker node、控制/注册/配置中心一体化、节点启动、服务启停、注册发现和配置恢复流程 |
-| [AUN 服务 Go 化重构精细化源码审查](audit/AUN服务Go化重构精细化源码审查-20260718.md) | 10 个 AUN 服务的 Go/Python 调用链、字段、并发、安全与性能修复终审；开放 P0/P1/P2 已归零，并附 Claude 60+76 条复审映射、跨实例/资源边界修复和 Docker/Linux 2344 条 Python 回归证据 |
+| [分布式 AUN 节点与服务启动流程](../../extensions/services/docs/分布式AUN节点与服务启动流程.md) | control master / worker node、控制/注册/配置中心一体化、节点启动、服务启停、注册发现和配置恢复流程 |
+| [AUN 服务 Go 化重构精细化源码审查](audit/AUN服务Go化重构精细化源码审查-20260718.md) | 10 个 AUN 服务的 Go/Python 调用链、字段、并发、安全与性能修复终审；开放 P0/P1/P2 已归零，并附 Claude 60+76 条复审映射、跨实例/资源边界修复和 Docker/Linux 2344 条 Python 回归证据 |
 | [AUNClient 拆分重构执行方案](design/AUNClient拆分重构执行方案.md) | Python / Go / TS / JS SDK AUNClient 内部拆分边界、执行步骤和验收矩阵 |
 | [AUNClient 门面化与 Runtime 状态迁移细化方案](design/AUNClient门面化与Runtime状态迁移细化方案.md) | AUNClient 完全门面化、ClientRuntime 单一状态源和四端分批迁移步骤 |
 | [消息同步与历史拉取改造方案](消息同步与历史拉取改造方案.md) | Forward A/T/H 窗口、Group 成员可见性下界、Tail/History RPC、页内唯一有序发布、应用层跨页幂等排序、三 Pull Gate、缺 sender IK 有界同步 bootstrap、永久页内 Gap、坏密文推进和跨 SDK 验收门禁 |
@@ -20,59 +22,61 @@
 | [跨设备已读未读方案](跨设备已读未读方案.md) | 同一 AID 多设备按话题同步已读位置；服务端按 message ID 公共顺序汇总，返回汇总 message ID 及当前设备 seq 映射，支持 P2P/Group、批量和部分会话上报 |
 | [跨设备已读未读详细设计](跨设备已读未读详细设计.md) | RPC、单条/显式空值边界、紧凑状态表、晚到位置持久回填、Group canonical 与权限版本、owner 事件路由及四端补偿 |
 | [跨设备已读未读实施计划](跨设备已读未读实施计划.md) | 按 TDD 分阶段落地服务端、状态缓存与异步批写、Gateway、四端 SDK、单域/E2E/cross-SDK/跨域测试及完成定义 |
-| [跨设备已读未读 SDK 集成指南](跨设备已读未读SDK集成指南.md) | TypeScript 身份加载、P2P/Group 上报查询、单调事件、本地 `read_state_sync`、精确整数和映射状态 |
-| [跨设备已读未读 SDK 实现/移植指南](跨设备已读未读SDK实现移植指南.md) | 其它语言 SDK 的 wire 契约、状态表迁移、顺序与映射、CACHE/异步批写、事件联邦、四端对齐和测试矩阵 |
+| [跨设备已读未读 SDK 集成指南](跨设备已读未读SDK集成指南.md) | TypeScript 身份加载、P2P/Group 上报查询、单调事件、本地 `read_state_sync`、队列身份代际隔离、精确整数和映射状态 |
+| [跨设备已读未读 SDK 实现/移植指南](跨设备已读未读SDK实现移植指南.md) | 其它语言 SDK 的 wire 契约、状态表迁移、顺序与映射、CACHE/异步批写、事件联邦、逐处理器身份代际复核、四端对齐和测试矩阵 |
 | [跨设备已读未读代码审查报告](跨设备已读未读代码审查报告.md) | 服务端及四端 SDK 补充修复、本轮实际验证与历史隔离/Docker 证据；部署层验收未执行 |
 | [消息同步与历史拉取代码审查问题清单](消息同步与历史拉取代码审查问题清单.md) | Python/Go 服务端、Gateway 与四 SDK 当前实现的 P0/P1/P2 问题、retention/Group Forward 可见性边界、跨语言差异、修复顺序和已排除误报 |
 | [跨语言容器E2E测试方案](design/跨语言容器E2E测试方案.md) | 多语言 SDK 同网同服、test-runner 控制面的跨语言 E2E 方案 |
 | [E2EE V2 简化为 1DH + Per-AID Wrap 方案](design/E2EE_V2简化为1DH加Per-AID_Wrap方案.md) | SDK bootstrap 能力声明 + 服务端 policy 控制 1DH/per-AID wrap 的兼容方案 |
 | [E2EE V2 消息通信时序图](sdk/E2EE_V2消息通信时序图.md) | 当前 V2-only P2P / Group 明文与加密主链路、设备密钥注册和 pull/ack 时序 |
 | [ProtectedHeaders 用法专题](sdk/ProtectedHeaders用法专题.md) | 四 SDK `protected_headers` API、E2EE V2 元数据 HMAC、自动字段和接收信任边界 |
-| [Ownership 协议定义 2.1](protocol/Ownership协议定义2.1.md) | 当前普通双文件/锁/版本、非权威 P2P 编排，以及 Group/Org 专属生命周期、owner 本人尾签 signer_aid、V2 授权和实体证书代际 |
-| [Ownership SDK 编排指南 2.1](sdk/Ownership-SDK编排指南2.1.md) | 七 Facade、审批、普通加密 P2P、本地事件、按角色完成证据与恢复契约 |
-| [Ownership 2.1 SDK 应用集成指南](sdk/Ownership2.1-SDK应用集成指南.md) | 当前应用接入、Group/Org 作为 sub 的边界、审批策略、任务事件、新鲜共识与 legacy 展示字段边界 |
-| [Ownership 2.1 SDK 开发与移植指南](sdk/Ownership2.1-SDK开发与移植指南.md) | 当前 SDK 文件验证、Storage 权威 revision、条件发布与发布标记恢复、HTTP 428 映射、持久任务和逐条通知恢复 |
-| [凭证与组织服务 SDK 应用集成指南](sdk/凭证与组织服务SDK应用集成指南.md) | 0.5.19 应用接入、CAP 完整验证、登记回执、成员闭环、代表请求和转让恢复 |
-| [凭证与组织服务 SDK 开发与移植指南](sdk/凭证与组织服务SDK开发与移植指南.md) | 0.5.19 四端协议实现、canonical JSON、强状态 proof、facade/RPC、持久编排和共同向量 |
-| [Ownership 2.1 详细设计](sdk/Ownership2.1详细设计.md) | SDK、NS、Storage 组件职责、原子提交、持久证据及 journal 恢复边界 |
-| [Ownership 2.1 TDD 分阶段实施计划](sdk/Ownership2.1-TDD分阶段实施计划.md) | 冻结实现契约、HTTP 428 与错误分类、共同向量、实施账本与四 SDK 实际验收范围 |
-| [Ownership 管理专题（legacy）](sdk/Ownership管理专题.md) | 历史 `aun.ownership.v1`、proof、托管、代签、代上传与 rekey 记录，不作为 2.1 接入依据 |
-| [Ownership SDK 集成指南（legacy）](sdk/Ownership-SDK集成指南.md) | 2026-10-09 历史 TypeScript 应用接入、旧审批 API 与自动编排记录 |
-| [Ownership SDK 实现指南（legacy）](sdk/Ownership-SDK实现指南.md) | 历史 proof/escrow、metadata、恢复和 rekey 移植记录 |
-| [Ownership 协议定义（legacy）](protocol/Ownership协议定义.md) | 历史 `aun.ownership.v1`、proof、托管和 owner 上传授权格式 |
-| [Ownership 2.1 代码审查报告](audit/Ownership2.1代码审查报告.md) | 历史服务端/四端审查与修复；本轮 13 项复审、逐项参考端、V2 过期停传、无消息释放清理及本地验证边界 |
-| [Group 专属生命周期与名片](sdk/09-group-rpc-manual.md) | 自动 owner 绑定/解绑、强制 rekey 的两阶段转移、owner 本人尾签和 V2 名片上传 |
-| [Org 0.8 专属生命周期](../../extensions/services/docs/org/0.8/02-组织模型.md) | 创建与解散 owner 自动建立/解除、先 rekey 后 owner CAS、材料归属与组织名片 |
+| [Ownership 协议定义 2.1](protocol/Ownership协议定义2.1.md) | agent.md/owner.md 关系、原格式兼容、release/清理/重绑版本、Header 投影、普通 agent.md 独立及旧 SDK 兼容；非权威 P2P 编排与 Group/Org 专属生命周期、实体主签、owner token 上传与可选附签和实体证书代际 |
+| [Ownership SDK 编排指南 2.1](sdk/Ownership-SDK编排指南2.1.md) | 七 Facade、审批、普通加密 P2P、本地事件、按角色完成证据与恢复契约 |
+| [Ownership 2.1 SDK 应用集成指南](sdk/Ownership2.1-SDK应用集成指南.md) | EC CLI／Evolcore 待接入的 sub 发起、human owner 点击审批 TS 示例与流程图；上传后 NS 检查锁定、可选 owner 注册、公共签验、关系操作与恢复 |
+| [Ownership 2.1 SDK 开发与移植指南](sdk/Ownership2.1-SDK开发与移植指南.md) | Rust 等新语言 SDK 的分层接口、共识、收件、绑定／释放／转移与恢复流程图及 TS 接口示例；上传后 NS 检查锁定、统一签验、Storage 完整文件和原 CAS |
+| [凭证与组织服务 SDK 应用集成指南](sdk/凭证与组织服务SDK应用集成指南.md) | 0.5.19 应用接入、CAP 完整验证、登记回执、成员闭环、实体主签与 owner 上传、转让恢复 |
+| [凭证与组织服务 SDK 开发与移植指南](sdk/凭证与组织服务SDK开发与移植指南.md) | 0.5.19 四端协议实现、canonical JSON、强状态 proof、facade/RPC、实体多签与原件恢复、共同向量 |
+| [凭证服务 RPC 手册](sdk/09-凭证服务RPC手册.md) | Credential Service 实际注册 RPC、状态 proof、登记、吊销和吊销列表 |
+| [组织服务 RPC 手册](sdk/09-组织服务RPC手册.md) | Org Service 生命周期、成员、受保护查询、审计/授权及内部/未实现方法 |
+| [Ownership 2.1 详细设计](sdk/Ownership2.1详细设计.md) | agent.md 兼容非回归原则与审查矩阵、旧 SDK owner RPC/JSONL 隔离、SDK／NS／Storage 职责；关系事实依赖`sub_aid/agent.md` 与 owner_aid 规范路径的 `owner.md`，普通名片和其 Storage 副本独立 |
+| [Ownership 2.1 TDD 分阶段实施计划](sdk/Ownership2.1-TDD分阶段实施计划.md) | 历史分阶段计划、冻结契约、HTTP 428 与错误分类、共同向量及四 SDK 实际验收范围 |
+| [Ownership 管理专题（legacy）](sdk/Ownership管理专题.md) | 历史 `aun.ownership.v1`、proof、托管、代签、代上传与 rekey 记录，不作为 2.1 接入依据 |
+| [Ownership SDK 集成指南（legacy）](sdk/Ownership-SDK集成指南.md) | 2026-10-09 历史 TypeScript 应用接入、旧审批 API 与自动编排记录 |
+| [Ownership SDK 实现指南（legacy）](sdk/Ownership-SDK实现指南.md) | 历史 proof/escrow、metadata、恢复和 rekey 移植记录 |
+| [Ownership 协议定义（legacy）](protocol/Ownership协议定义.md) | 历史 `aun.ownership.v1`、proof、托管和 owner 上传授权格式 |
+| [Ownership 2.1 代码审查报告](audit/Ownership2.1代码审查报告.md) | 第二十二节：恢复 agent.md/owner.md 与原控制格式、reset、历史兼容、本地专项、Gateway 部署、单域／cross-SDK／双域验证及未测边界；第十六至二十一节保留阶段记录，不替代当前验收 |
+| [Group 专属生命周期与名片](sdk/09-group-rpc-manual.md) | 自动 owner 绑定/解绑、强制 rekey 的两阶段转移、实体主签、owner token 名片上传与可选附签 |
+| [Org 0.8 专属生命周期](../../extensions/services/docs/org/0.8/02-组织模型.md) | 创建与解散 owner 自动建立/解除、先 rekey 后 owner CAS、材料归属与组织名片 |
 | [AUN RPC Trace 增强设计](design/2026-05-22-aun-rpc-trace-enhancement.md) | RPC trace 诊断字段与 enter/exit span 设计 |
-| [AUN 服务端消息通信诊断面板方案](design/AUN服务端消息通信诊断面板方案.md) | aun-console 消息通信页的服务端可观察诊断面板总体方案 |
-| [服务端消息通信诊断面板 P0 方案](design/服务端消息通信诊断面板P0方案.md) | aun-console 消息通信页的服务端可观察 P0 诊断面板 |
-| [消息收件箱统一迁移方案](design/消息收件箱统一迁移方案.md) | P2P `message_inbox` 与群消息 `group_inbox` 的统一读模型、后台回填和旧表清理方案 |
+| [AUN 服务端消息通信诊断面板方案](design/AUN服务端消息通信诊断面板方案.md) | aun-console 消息通信页的服务端可观察诊断面板总体方案 |
+| [服务端消息通信诊断面板 P0 方案](design/服务端消息通信诊断面板P0方案.md) | aun-console 消息通信页的服务端可观察 P0 诊断面板 |
+| [消息收件箱统一迁移方案](design/消息收件箱统一迁移方案.md) | P2P `message_inbox` 与群消息 `group_inbox` 的统一读模型、后台回填和旧表清理方案 |
 | [AUN 反向代理服务方案与 TDD 实施计划](design/AUN反向代理服务方案与TDD实施计划.md) | AUN Service Proxy、service_proxy 服务模块、SDK service-proxy-client、URL 路由、隧道协议、Web 边界和分阶段 TDD 落地计划 |
-| [agent.md Schema（legacy 2.0）](agent.md/SCHEMA.md) | 历史 Ownership 2.0 双文件声明与撤销格式；当前 2.1 文件、关系版本和 owner 锁见协议定义 2.1 |
+| [agent.md Schema（legacy 2.0）](agent.md/SCHEMA.md) | 历史 Ownership 2.0 双文件声明与撤销格式；当前 2.1 文件、关系版本和 owner 锁见协议定义 2.1 |
 | [远程 agent.md 缓存与 ETag 透传方案](agent.md/远程agent.md缓存与etag透传方案.md) | 远程 agent.md per-AID 本地文件/IndexedDB 缓存、Gateway `_meta.agent_md_etags` 角色、消息信封 ETag 和注入节流方案 |
 | [agent.md Schema 与签发/验签流程澄清记录](agent.md/working/agent.md-schema与签发验签流程澄清.md) | working 讨论记录：当前 Schema、内嵌签名实现、三字段关系声明与 self-owner 单签、公开 proof 独立验签、owner 关系写入经 Auth 验证及冲突仲裁、事实摘要与 nonce/编排上下文分层、Auth 登记见证与回执、证书/关系状态分离，以及 `unbound`/`unusable`、状态 pull/push、TTL、type-change 和 Storage 权限的最新决策 |
 | [AID 类型、owner 关系与换 owner 编排方案](agent.md/working/AID类型-owner关系与换owner编排方案.md) | working 方案：Schema 的 owner/proof 可选但出现即必须完整合法，human 禁止 owner；共同签署声明字段为 proof_id/subject_aid/owner_aid，self-owner 仅 subject 单签，事实摘要排除 nonce、完整声明摘要绑定 proof，使用可见分号域分隔符；Auth 作为登记机构托管证据并签发回执，公开 owner 声明多数场景可独立验证，旧 AID 通过 `aid_bind` 建立 type/owner 绑定且基本登录通信不受限，关系写入经 Auth 仲裁，Storage 内部对象可删除/移动/重命名，失效关系进入 `unbound`/`unusable` |
 | [AID 类型、owner 关系与 agent.md 签发/换 owner 完整设计与实施计划](agent.md/working/AID类型-owner关系完整设计与实施计划.md) | 汇总设计及 Phase 0 已确认的 P0-A01 至 P0-A12：Schema owner/proof 可选性与 human 禁止 owner、三字段共同声明与 self-owner 单签、事实 hash 与完整声明 hash 分层、canonical JSON/可见分号域分隔符/签名封套、proof-only 与 registered 验证等级、Auth 登记见证/回执、证书状态与关系 operation 分离、legacy/绑定中基本登录通信及按应用场景降级、旧 AID `aid_bind` 与新建 `aid_register` 的 Facade/RPC 边界、active/pending 唯一性检查、离线审批、`unbound`/`unusable`、Storage 保留目录和内部对象操作、服务端/四端 SDK 调整及逐阶段验收标准；剩余仅为正式 wire/RPC 文档和跨端向量落稿 |
 | [本地 Docker 测试 Bug 清单](agent.md/working/本地Docker测试Bug清单.md) | 本轮 owner 关系实施及单域、cross-SDK、双域 federation 回归中发现的非任务失败、根因、修复与验证记录 |
 | [群索引版本提示与附件引用方案](design/群索引版本提示与附件引用方案.md) | `group.index` 签名索引、`_meta.group_indexes` 版本提示、CAS 更新、服务端缓存注入和附件稳定引用 |
-| [SDK 文档索引](sdk/INDEX.md) | SDK 使用手册、四 SDK 当前 access token getter、Python Push 自动登记/Facade、RPC 手册、E2EE、Storage VFS、Group FS 和 Collab 的子索引 |
+| [SDK 文档索引](sdk/INDEX.md) | SDK 使用手册、P2P peer 能力/游标、完整 pending peers/快照、need_render、50k 内存去重/应用持久幂等、四端门面、RPC、E2EE、Storage VFS、Group FS 和 Collab 的子索引 |
 | [SDK 查阅指南](sdk/AUN_DOCS_GUIDE.md) | SDK 文档按行区间渐进式查阅方法 |
 | [AUN SDK 0.5.6 更新日志](sdk/CHANGELOG-0.5.6.md) | 以 0.5.5 为基线的四 SDK 发布汇总；覆盖首次签名者回源、下载提交前验签、消息窗口、显式 change-seed 和语言能力边界 |
-| [四 SDK 版本对齐变更清单](../python/CHANGES_FOR_PARITY.md) | 以 Python 实现为主线的 v0.3.3 至 v0.5.19 跨语言对齐清单；0.5.19 以仓库 0.5.18 为基线，覆盖跨设备已读未读、Ownership 2.1、凭证与组织服务、语言边界和测试入口 |
+| [四 SDK 版本对齐变更清单](../python/CHANGES_FOR_PARITY.md) | 以 Python 实现为主线的 v0.3.3 至 v0.5.21 跨语言对齐清单；0.5.21 以已发布 0.5.20 为基线，覆盖消息同步、Ownership 恢复、组织凭证、语言边界和测试入口，以及 resolve frontmatter/按需 ownership 与 owner.md 缓存 |
 | [AUN CLI 手册](cli/CLI手册.md) | Python CLI 源码位置、安装运行入口、全局选项、profile 配置和主要命令集 |
-| [AUN CLI 设计文档](cli/AUN-CLI设计文档.md) | `python/src/aun_cli` 当前实现架构、命令注册面、配置解析、SDK 桥接和实现边界 |
+| [AUN CLI 设计文档](cli/AUN-CLI设计文档.md) | `python/src/aun_cli` 当前实现架构、命令注册面、配置解析、SDK 桥接和实现边界 |
 | [AUN Storage 架构设计](<aun-fs/AUN Storage架构设计.md>) | Storage SDK VFS、控制面/数据面分离、下载 ticket / AID Bearer 边界、当前 access token getter、类 Linux 权限、mount/symlink、服务端分层和 direct backend 上传下载 |
-| [AUN Storage SDK 存储分层设计](<aun-fs/SDK存储分层设计.md>) | Python SDK StorageVFS / StorageLowLevel 接口契约、返回类型、错误映射和跨语言对齐要求 |
-| [AUN Storage CLI-fs 命令设计](<aun-fs/CLI-fs命令设计.md>) | `aun fs` 命令语义、寻址规则、输出格式、CLI 工程改造和端到端场景 |
-| [AUN Storage 分阶段实施计划](<aun-fs/分阶段实施计划.md>) | AUN Storage VFS + CLI 的 6 阶段 TDD 实施计划、P1-P6 实际执行记录和验收口径 |
-| [AUN FS POSIX 覆盖与补全计划](<aun-fs/aun-fs-completion-plan.md>) | Storage VFS 与 Group FS 对照 POSIX 命令的当前复审基线、缺口优先级、接口确认点和 step-by-step TDD 补全计划 |
-| [群文件系统 group.fs POSIX 化详细设计](<aun-fs/group-fs/group.fs-POSIX化详细设计.md>) | 统一为 `group.fs.*`、`client.group.fs.*` 和 `aun group fs` 的 POSIX 风格群文件系统设计；包含群自有区角色 ACL、`parents` 和 JS string 语义 |
-| [群自有区角色 ACL 写权限实施方案](<aun-fs/group-fs/群自有区角色ACL写权限实施方案.md>) | 群自有区 owner 默认写、admin 需 owner 显式 `role:admin` ACL 授权、group/storage 分工、Storage 写审计、显式撤销/查询和 TDD 执行计划 |
-| [群文件系统 group.fs POSIX 化分阶段实施计划](<aun-fs/group-fs/group.fs-POSIX化分阶段实施计划.md>) | group.fs 重构的 8 阶段实施计划，每阶段包含目标、IPO、Step-by-step、用例集、Checklist、验收与回滚，并记录 Phase 8 单域/双域 Docker 与四语言互操作验收 |
-| [系统目录保护方案](protocol/16-系统目录保护方案.md) | `memberdata` 与 `group_data` 的系统目录保护、`group_data` 目录树隐藏与读下载/写保护边界、Group FS 间接访问和真实 owner AID 配额归属 |
-| [collab 协作层服务端编排设计](<aun-fs/collab/2026-06-10-collab层服务端编排详细设计.md>) | collab 服务端编排、台账、diff3、snapshot、export/adopt、群协作注册表和四语言薄 SDK 设计 |
-| [collab 协作层 Plan 1 服务端基础](<aun-fs/collab/2026-06-10-collab服务端编排-plan1.md>) | storage 进程内 collab 编排的 TDD 任务拆分、repository 事务原语、RPC 注册和群协作发现计划 |
-| [collab 协作层 Plan 2 Python SDK/CLI](<aun-fs/collab/2026-06-12-collab协作层-plan2.md>) | Python SDK collab 薄封装、CLI 命令、单域 Docker E2E 和文档同步计划 |
+| [AUN Storage SDK 存储分层设计](<aun-fs/SDK存储分层设计.md>) | Python SDK StorageVFS / StorageLowLevel 接口契约、返回类型、错误映射和跨语言对齐要求 |
+| [AUN Storage CLI-fs 命令设计](<aun-fs/CLI-fs命令设计.md>) | `aun fs` 命令语义、寻址规则、输出格式、CLI 工程改造和端到端场景 |
+| [AUN Storage 分阶段实施计划](<aun-fs/分阶段实施计划.md>) | AUN Storage VFS + CLI 的 6 阶段 TDD 实施计划、P1-P6 实际执行记录和验收口径 |
+| [AUN FS POSIX 覆盖与补全计划](<aun-fs/aun-fs-completion-plan.md>) | Storage VFS 与 Group FS 对照 POSIX 命令的当前复审基线、缺口优先级、接口确认点和 step-by-step TDD 补全计划 |
+| [群文件系统 group.fs POSIX 化详细设计](<aun-fs/group-fs/group.fs-POSIX化详细设计.md>) | 统一为 `group.fs.*`、`client.group.fs.*` 和 `aun group fs` 的 POSIX 风格群文件系统设计；包含群自有区角色 ACL、`parents` 和 JS string 语义 |
+| [群自有区角色 ACL 写权限实施方案](<aun-fs/group-fs/群自有区角色ACL写权限实施方案.md>) | 群自有区 owner 默认写、admin 需 owner 显式 `role:admin` ACL 授权、group/storage 分工、Storage 写审计、显式撤销/查询和 TDD 执行计划 |
+| [群文件系统 group.fs POSIX 化分阶段实施计划](<aun-fs/group-fs/group.fs-POSIX化分阶段实施计划.md>) | group.fs 重构的 8 阶段实施计划，每阶段包含目标、IPO、Step-by-step、用例集、Checklist、验收与回滚，并记录 Phase 8 单域/双域 Docker 与四语言互操作验收 |
+| [系统目录保护方案](protocol/16-系统目录保护方案.md) | `memberdata` 与 `group_data` 的系统目录保护、`group_data` 目录树隐藏与读下载/写保护边界、Group FS 间接访问和真实 owner AID 配额归属 |
+| [collab 协作层服务端编排设计](<aun-fs/collab/2026-06-10-collab层服务端编排详细设计.md>) | collab 服务端编排、台账、diff3、snapshot、export/adopt、群协作注册表和四语言薄 SDK 设计 |
+| [collab 协作层 Plan 1 服务端基础](<aun-fs/collab/2026-06-10-collab服务端编排-plan1.md>) | storage 进程内 collab 编排的 TDD 任务拆分、repository 事务原语、RPC 注册和群协作发现计划 |
+| [collab 协作层 Plan 2 Python SDK/CLI](<aun-fs/collab/2026-06-12-collab协作层-plan2.md>) | Python SDK collab 薄封装、CLI 命令、单域 Docker E2E 和文档同步计划 |
 | [collab 协作层 Plan 3 四语言互操作](<aun-fs/collab/2026-06-12-collab协作层-plan3.md>) | Go / TypeScript / JavaScript SDK collab 薄封装、跨语言 E2E 和双域边界验证计划 |
 | [Notify 通知方案](sdk/Notify通知方案.md) | `client.notify()` 在线轻量通知、跨域 federation 和可靠消息分工 |
 | [AUN 离线推送 Push Service 设计](superpowers/specs/2026-07-24-push-service-design-v3.md) | 独立 Go Push Service 的职责边界、SDK connect 登记语义、主链路、持久状态机、可靠性、安全、生命周期与三中心纳管 |
@@ -82,21 +86,21 @@
 | [AUN 离线推送接入与演示指南](AUN离线推送接入与演示指南.md) | 终端客户端登记、Push Server token/长连接/幂等/ACK 实现，以及 Python Mock 隔离演示和验收排障 |
 | [离线推送通知协议](protocol/15-离线推送通知协议.md) | `push.register/unregister/ack`、Python connect 自动登记、installation delivery、事件与持久恢复边界 |
 | [Service Proxy RPC 手册](sdk/09-proxy-rpc-manual.md) | `proxy.*` 控制面、proxy-server 数据面注册、服务列表一致性和 wakeup 路由语义 |
-| [协议文档目录](protocol/) | AUN 协议相关文档 |
-| [审查与路线图目录](audit/) | 历史审查、修复路线图、测试补充清单 |
-| [superpowers 目录](superpowers/) | AUN SDK 规范类补充文档 |
-
----
-
-## Layer 2：主题交叉索引
-
-### 测试与 E2E
-
+| [协议文档目录](protocol/) | AUN 协议相关文档 |
+| [审查与路线图目录](audit/) | 历史审查、修复路线图、测试补充清单 |
+| [superpowers 目录](superpowers/) | AUN SDK 规范类补充文档 |
+
+---
+
+## Layer 2：主题交叉索引
+
+### 测试与 E2E
+
 - 本机各套环境边界、默认单实例服务端、独立 SDK Tester、容器/网络/数据目录和测试命令 → [aun测试运行指南](aun测试运行指南.md)
-- `evolagent.cn` / `agentid.pub` 等公网域的 Python SDK integration/E2E、隔离目录、TLS 和报告 → [aun公网测试运行指南](aun公网测试运行指南.md)
+- `evolagent.cn` / `agentid.pub` 等公网域的 Python SDK integration/E2E、隔离目录、TLS 和报告 → [aun公网测试运行指南](aun公网测试运行指南.md)
 - 双域 Issuer/AID/MySQL 材料校验、三文件线上镜像替换包、开箱默认值与可选生产覆盖、一次性初始化辅助包及线上单节点部署 → [aun测试运行指南](aun测试运行指南.md)
 - 当前 worktree 三节点、本地与公网 `agentid.pub/agentid.cn` 双域、固定身份双域 runner、Storage OSS、dist 域名、data-dist、镜像/Compose/mount 来源核验、控制中心和跳过 TLS verify → [aun分布式测试运行指南](aun分布式测试运行指南.md)
-- 分布式节点角色、节点启动、服务启动/停止、注册发现、配置恢复和重启后状态恢复 → [分布式 AUN 节点与服务启动流程](../../extensions/services/docs/分布式AUN节点与服务启动流程.md)
+- 分布式节点角色、节点启动、服务启动/停止、注册发现、配置恢复和重启后状态恢复 → [分布式 AUN 节点与服务启动流程](../../extensions/services/docs/分布式AUN节点与服务启动流程.md)
 - AUNClient 巨类拆分、内部组件边界、逐步迁移和验收矩阵 → [AUNClient 拆分重构执行方案](design/AUNClient拆分重构执行方案.md)
 - AUNClient 完全门面化、Runtime 状态归属、状态写入收口和四端分批实施 → [AUNClient 门面化与 Runtime 状态迁移细化方案](design/AUNClient门面化与Runtime状态迁移细化方案.md)
 - P2P/Group Message 的 A/T/H、Tail/History、页内唯一有序发布、应用层跨页幂等排序、三 Pull Gate、缺 sender IK 有界同步 bootstrap、永久页内 Gap、坏密文推进和分布式验收门禁 → [消息同步与历史拉取改造方案](消息同步与历史拉取改造方案.md)
@@ -109,96 +113,101 @@
 - 跨设备已读未读实现完整度、文档一致性、四端 SDK 对齐、问题修复闭环及本轮/历史验证边界 → [跨设备已读未读代码审查报告](跨设备已读未读代码审查报告.md)
 - 当前实现的完整度、P0/P1/P2 缺陷、Python/Go 服务端差异、四 SDK 差异与 Go Group inbox-only 对齐项 → [消息同步与历史拉取代码审查问题清单](消息同步与历史拉取代码审查问题清单.md)
 - Python / TypeScript / Go / JavaScript 跨语言容器 E2E、internal 网络、每轮唯一 AID、test-runner、test-control API、用例矩阵 → [aun测试运行指南](aun测试运行指南.md)、[跨语言容器E2E测试方案](design/跨语言容器E2E测试方案.md)
-- 多语言 SDK 测试缺口与补测清单 → [审查与路线图目录](audit/)
-
-### 服务端 Go 化重构审查
-
-- 10 个 AUN 服务的 Go/Python 逐调用链终审、request/response/event 字段对齐、Claude 60 条已确认项和 76 条候选复审、跨实例 recovery/nonce/队列边界修复、开放缺陷归零、Docker/Linux race 与 2344 条 Python 回归证据及动态 E2E 边界 → [AUN 服务 Go 化重构精细化源码审查](audit/AUN服务Go化重构精细化源码审查-20260718.md)
-
-### SDK 使用与协议
-
-- Python / TS / Go / JS SDK 使用手册，以及 Python `push_notify_aid` connect 自动登记和 PushFacade → [SDK 文档索引](sdk/INDEX.md)
-- Ownership 2.1 双文件、身份、owner 锁、关系版本、释放、转移、非权威 P2P 和审计 → [协议定义 2.1](protocol/Ownership协议定义2.1.md)、[详细设计](sdk/Ownership2.1详细设计.md)
-- Ownership 2.1 七 Facade、Group/Org 作为 sub 的边界、审批、本地事件、任务与新鲜共识 → [SDK 编排指南 2.1](sdk/Ownership-SDK编排指南2.1.md)、[应用集成指南](sdk/Ownership2.1-SDK应用集成指南.md)
-- Ownership 2.1 文件验证、权威 Storage revision、条件发布与发布标记恢复、HTTP 428 映射、持久恢复和实际验收 → [开发与移植指南](sdk/Ownership2.1-SDK开发与移植指南.md)、[TDD 实施账本](sdk/Ownership2.1-TDD分阶段实施计划.md)
-- Credential/Org 应用接入、CAP 完整 Verify、登记回执、成员入组/续期、代表请求和转让恢复 → [凭证与组织服务 SDK 应用集成指南](sdk/凭证与组织服务SDK应用集成指南.md)
-- Credential/Org 四端协议实现、canonical JSON、父链强状态 proof、请求绑定、facade/RPC 和共同向量 → [凭证与组织服务 SDK 开发与移植指南](sdk/凭证与组织服务SDK开发与移植指南.md)
-- legacy 四端 proof、托管、代签和代上传记录 → [Ownership 管理专题](sdk/Ownership管理专题.md)
-- legacy 应用接入与旧 SDK 自动编排 → [Ownership SDK 集成指南](sdk/Ownership-SDK集成指南.md)
-- legacy proof/escrow、metadata 和 rekey 移植记录 → [Ownership SDK 实现指南](sdk/Ownership-SDK实现指南.md)
-- legacy `aun.ownership.v1` wire 格式和 owner 上传授权 → [Ownership 协议定义](protocol/Ownership协议定义.md)
-- Ownership 2.1 当前代码审查、四端逐项裁决、本轮 13 项修复、实体授权过期规则和验证限制 → [Ownership 2.1 代码审查报告](audit/Ownership2.1代码审查报告.md)
+- 多语言 SDK 测试缺口与补测清单 → [审查与路线图目录](audit/)
+
+### 服务端 Go 化重构审查
+
+- 10 个 AUN 服务的 Go/Python 逐调用链终审、request/response/event 字段对齐、Claude 60 条已确认项和 76 条候选复审、跨实例 recovery/nonce/队列边界修复、开放缺陷归零、Docker/Linux race 与 2344 条 Python 回归证据及动态 E2E 边界 → [AUN 服务 Go 化重构精细化源码审查](audit/AUN服务Go化重构精细化源码审查-20260718.md)
+
+### SDK 使用与协议
+
+- 0.5.21 应用开发者的 TypeScript 接入、消息入库与 UI、resolve、Ownership、凭证组织及升级验收 → [应用集成指南](sdk/0.5.21-SDK应用集成指南.md)
+- 0.5.21 SDK 开发者的分层、peer/batch 提交、共识缓存、原件恢复、持久化和跨语言验收 → [开发与移植指南](sdk/0.5.21-SDK开发与移植指南.md)
+- Python / TS / Go / JS SDK 使用手册，P2P peer 能力、共享 seq/隔离游标、轻量 pending peers/可选整体估计快照、目录/Pull逐页next_pending_seq持续提示/每N次FIFO、peer ACK/slot 公共 S、need_render/页内渲染计数、50k 内存去重/应用持久幂等，以及 Python PushFacade → [SDK 文档索引](sdk/INDEX.md)、[Message RPC](sdk/09-message-rpc-manual.md)、[服务协议](protocol/06-服务协议.md#63-点对点消息-message)
+- Ownership 2.1 agent.md/owner.md 关系、原格式兼容、普通 agent.md 独立、release 保持当前版本、清理后版本投影为 0／重绑默认 1、响应 Header 只投影校验结果、普通 agent owner 可选及旧 SDK 隔离兼容 → [协议定义 2.1](protocol/Ownership协议定义2.1.md)、[详细设计](sdk/Ownership2.1详细设计.md)
+- Ownership 2.1 七 Facade、EC CLI 待接入的 sub 发起／human owner 审批 TS 示例与流程图、公开签验与文件多签、Group/Org 实体上传、本地事件、任务与新鲜共识 → [SDK 编排指南 2.1](sdk/Ownership-SDK编排指南2.1.md)、[应用集成指南](sdk/Ownership2.1-SDK应用集成指南.md)
+- Ownership 2.1 Rust 等新语言 SDK 的内部流程图与接口示例、统一签验核心、多签 HTTP 表示、Storage 完整原文/存在性再读、owner.md 同会话上传与 expected_version 发布 CAS、原件恢复与持久任务验收 → [开发与移植指南](sdk/Ownership2.1-SDK开发与移植指南.md)、[TDD 实施账本](sdk/Ownership2.1-TDD分阶段实施计划.md)
+- Credential/Org 应用接入、CAP 完整 Verify、登记回执、成员入组/续期、代表请求和转让恢复 → [凭证与组织服务 SDK 应用集成指南](sdk/凭证与组织服务SDK应用集成指南.md)
+- Credential/Org 四端协议实现、canonical JSON、父链强状态 proof、请求绑定、facade/RPC 和共同向量 → [凭证与组织服务 SDK 开发与移植指南](sdk/凭证与组织服务SDK开发与移植指南.md)
+- Credential Service 服务端 RPC、签名状态 proof 和吊销列表 → [凭证服务 RPC 手册](sdk/09-凭证服务RPC手册.md)
+- Org Service 生命周期、成员、受保护查询、内部接口和未实现占位 → [组织服务 RPC 手册](sdk/09-组织服务RPC手册.md)
+- 旧 SDK owner 注册、绑定、转移、查询和解绑的隔离 RPC/Auth JSONL 兼容 → [当前协议兼容边界](protocol/Ownership协议定义2.1.md)；legacy proof、托管、代签和代上传记录 → [Ownership 管理专题](sdk/Ownership管理专题.md)
+- legacy 应用接入与旧 SDK 自动编排 → [Ownership SDK 集成指南](sdk/Ownership-SDK集成指南.md)
+- legacy proof/escrow、metadata 和 rekey 移植记录 → [Ownership SDK 实现指南](sdk/Ownership-SDK实现指南.md)
+- legacy `aun.ownership.v1` wire 格式和 owner 上传授权 → [Ownership 协议定义](protocol/Ownership协议定义.md)
+- Ownership 2.1 恢复 agent.md/owner.md 及原控制格式、无参数 reset、绑定容错和历史任务兼容 → [第二十二节](audit/Ownership2.1代码审查报告.md#二十二2026-10-18-恢复发布格式与历史兼容更正)、[编排第 8 节](sdk/Ownership-SDK编排指南2.1.md#8-崩溃与响应丢失后的恢复)
 - 四 SDK 当前 access token getter、缓存快照语义和外部 HTTP 数据面下载凭据生命周期 → [连接与认证](sdk/04-连接与认证.md)、[API 手册](sdk/06-API手册.md)、[Storage RPC 手册](sdk/09-storage-rpc-manual.md)、[AUN Storage 架构设计](<aun-fs/AUN Storage架构设计.md>)
+- 四 SDK resolve 的 opts/输入输出、frontmatter 全字段与类型、按需 ownership 共识及 owner.md 缓存 → [resolve 规格](sdk/06-API手册.md#resolve-输入与输出)、[连接与认证](sdk/04-连接与认证.md)
 - 按主题和行区间查 SDK 文档 → [SDK 查阅指南](sdk/AUN_DOCS_GUIDE.md)
 - 四 SDK 0.5.6 发布摘要、首次签名者回源、可信缓存提交、消息窗口、语言能力边界 → [AUN SDK 0.5.6 更新日志](sdk/CHANGELOG-0.5.6.md)
-- 四 SDK 0.5.19 相对仓库 0.5.18 的已读未读、Ownership 2.1、凭证/组织服务、代码/测试落点、语言边界及历史实现差异 → [四 SDK 版本对齐变更清单](../python/CHANGES_FOR_PARITY.md)
-- Python CLI 源码位置、安装运行入口、全局选项、profile 配置、身份/消息/群组/Storage/Group FS/Collab/诊断等命令用法 → [AUN CLI 手册](cli/CLI手册.md)
-- Python CLI 当前实现架构、`main.py` 命令注册、`CLISession` SDK 桥接、配置解析和实现边界 → [AUN CLI 设计文档](cli/AUN-CLI设计文档.md)
+- 四 SDK 0.5.21 相对发布 0.5.20 的 peer Pull、批量背压／ACK、Ownership reset／旧任务、凭证续期撤销、加密 checkpoint、诊断及语言边界 → [四 SDK 版本对齐变更清单](../python/CHANGES_FOR_PARITY.md)
+- Python CLI 源码位置、安装运行入口、全局选项、profile 配置、身份/消息/群组/Storage/Group FS/Collab/诊断等命令用法 → [AUN CLI 手册](cli/CLI手册.md)
+- Python CLI 当前实现架构、`main.py` 命令注册、`CLISession` SDK 桥接、配置解析和实现边界 → [AUN CLI 设计文档](cli/AUN-CLI设计文档.md)
 - Storage SDK VFS、控制面/数据面分离、下载 ticket / AID Bearer 边界、当前 access token getter、类 Linux 权限、mount/symlink、direct backend 上传下载和服务端分层 → [AUN Storage 架构设计](<aun-fs/AUN Storage架构设计.md>)
-- StorageVFS / StorageLowLevel 接口契约、NodeView/ObjectView、错误映射和跨语言对齐 → [AUN Storage SDK 存储分层设计](<aun-fs/SDK存储分层设计.md>)
-- `aun fs` 命令语义、AID 路径解析、输出格式和 CLI 到 SDK 的调用边界 → [AUN Storage CLI-fs 命令设计](<aun-fs/CLI-fs命令设计.md>)
-- AUN Storage 6 阶段 TDD 计划、P1/P2/P3/P4/P5/P6 实际执行记录、阶段实施前详细计划和 Docker 验证纪律 → [AUN Storage 分阶段实施计划](<aun-fs/分阶段实施计划.md>)
-- Storage VFS / Group FS 对 POSIX 命令的覆盖现状、过期状态修正、`lstat/readlink/quota/setfacl/du/head/tail/touch/getfacl` 的分阶段 TDD 补全步骤和新增 RPC 确认点 → [AUN FS POSIX 覆盖表](<aun-fs/aun-fs-posix-coverage.md>)、[AUN FS POSIX 补全计划](<aun-fs/aun-fs-completion-plan.md>)
-- `group.fs.*` POSIX 风格群文件系统、`client.group.fs.*`、`aun group fs`、`cp/mv` 上传下载心智、群自有区角色 ACL 与 `group_aid` 签名、`parents` 语义、JS string 差异、服务端 memberdata 映射和 SDK 数据面编排 → [群文件系统 group.fs POSIX 化详细设计](<aun-fs/group-fs/group.fs-POSIX化详细设计.md>)
-- 群自有区 owner 默认写、admin 需 owner 显式 `role:admin` ACL 授权与撤销/查询、group 与 storage 鉴权分工、Storage 写审计 → [群自有区角色 ACL 写权限实施方案](<aun-fs/group-fs/群自有区角色ACL写权限实施方案.md>)
-- `memberdata` 和 `group_data` 系统目录保护、`group_data` 目录树隐藏但读/下载不刻意隐藏、普通写入口保护、group.fs 授权写入路径、真实 owner AID 配额计入 → [系统目录保护方案](protocol/16-系统目录保护方案.md)
-- group.fs 8 阶段重构步骤、每阶段 IPO、Step-by-step、用例集、Checklist、验收、回滚和 Phase 8 Docker 完成记录 → [群文件系统 group.fs POSIX 化分阶段实施计划](<aun-fs/group-fs/group.fs-POSIX化分阶段实施计划.md>)
+- StorageVFS / StorageLowLevel 接口契约、NodeView/ObjectView、错误映射和跨语言对齐 → [AUN Storage SDK 存储分层设计](<aun-fs/SDK存储分层设计.md>)
+- `aun fs` 命令语义、AID 路径解析、输出格式和 CLI 到 SDK 的调用边界 → [AUN Storage CLI-fs 命令设计](<aun-fs/CLI-fs命令设计.md>)
+- AUN Storage 6 阶段 TDD 计划、P1/P2/P3/P4/P5/P6 实际执行记录、阶段实施前详细计划和 Docker 验证纪律 → [AUN Storage 分阶段实施计划](<aun-fs/分阶段实施计划.md>)
+- Storage VFS / Group FS 对 POSIX 命令的覆盖现状、过期状态修正、`lstat/readlink/quota/setfacl/du/head/tail/touch/getfacl` 的分阶段 TDD 补全步骤和新增 RPC 确认点 → [AUN FS POSIX 覆盖表](<aun-fs/aun-fs-posix-coverage.md>)、[AUN FS POSIX 补全计划](<aun-fs/aun-fs-completion-plan.md>)
+- `group.fs.*` POSIX 风格群文件系统、`client.group.fs.*`、`aun group fs`、`cp/mv` 上传下载心智、群自有区角色 ACL 与 `group_aid` 签名、`parents` 语义、JS string 差异、服务端 memberdata 映射和 SDK 数据面编排 → [群文件系统 group.fs POSIX 化详细设计](<aun-fs/group-fs/group.fs-POSIX化详细设计.md>)
+- 群自有区 owner 默认写、admin 需 owner 显式 `role:admin` ACL 授权与撤销/查询、group 与 storage 鉴权分工、Storage 写审计 → [群自有区角色 ACL 写权限实施方案](<aun-fs/group-fs/群自有区角色ACL写权限实施方案.md>)
+- `memberdata` 和 `group_data` 系统目录保护、`group_data` 目录树隐藏但读/下载不刻意隐藏、普通写入口保护、group.fs 授权写入路径、真实 owner AID 配额计入 → [系统目录保护方案](protocol/16-系统目录保护方案.md)
+- group.fs 8 阶段重构步骤、每阶段 IPO、Step-by-step、用例集、Checklist、验收、回滚和 Phase 8 Docker 完成记录 → [群文件系统 group.fs POSIX 化分阶段实施计划](<aun-fs/group-fs/group.fs-POSIX化分阶段实施计划.md>)
 - collab 协作层服务端编排、`collab.*` RPC、版本台账、snapshot、群协作注册表和后续四语言 SDK/CLI/E2E 计划 → [collab 协作层服务端编排设计](<aun-fs/collab/2026-06-10-collab层服务端编排详细设计.md>)、[Plan 1](<aun-fs/collab/2026-06-10-collab服务端编排-plan1.md>)、[Plan 2](<aun-fs/collab/2026-06-12-collab协作层-plan2.md>)、[Plan 3](<aun-fs/collab/2026-06-12-collab协作层-plan3.md>)
 - `client.notify()` 在线轻量通知、AID/群路由、跨域 federation 和不离线存储边界 → [Notify 通知方案](sdk/Notify通知方案.md)
 - 终端如何登记、Push Server 如何签发 token、接收批次、平台推送、幂等 ACK，以及如何运行 Mock smoke → [AUN 离线推送接入与演示指南](AUN离线推送接入与演示指南.md)
 - P2P/Group 离线唤醒、Python connect/Facade 登记、六项冻结契约、9 Phase/40 Task、发布门和回滚 → [离线推送协议](protocol/15-离线推送通知协议.md)、[Push Service 设计](superpowers/specs/2026-07-24-push-service-design-v3.md)、[契约冻结](superpowers/契约冻结-v3-to-v4.md)、[v4 实施计划](superpowers/plans/2026-07-24-push-service-implementation-v4.md)、[运维与发布指南](AUN离线推送服务运维与发布指南.md)；[旧 Codex 版本](AUN离线推送服务架构与详细实现计划-codex.md)仅作历史背景
 - 协议细节、Agent 自主行为、群 `mention_mode` 提及过滤和消息格式 → [协议文档目录](protocol/)、[Group 子协议](protocol/10-Group-子协议.md)、[Agent 行为规范](protocol/13-Agent行为规范.md)
-- legacy Ownership 2.0 的 agent.md/owner.md 声明与撤销 → [agent.md Schema](agent.md/SCHEMA.md)；当前 2.1 文件与锁规则 → [协议定义 2.1](protocol/Ownership协议定义2.1.md)
+- legacy Ownership 2.0 的 agent.md/owner.md 声明与撤销 → [agent.md Schema](agent.md/SCHEMA.md)；当前 2.1 文件与锁规则 → [协议定义 2.1](protocol/Ownership协议定义2.1.md)
 - agent.md 远程缓存、`remote_etag` / `local_etag`、`requester` / `peer` / `group` 角色、消息信封与 Gateway `_meta` ETag 透传 → [远程 agent.md 缓存与 ETag 透传方案](agent.md/远程agent.md缓存与etag透传方案.md)
 - agent.md Schema、内嵌签名、三字段关系声明与 self-owner 单签、公开 proof 独立验签、关系写入经 Auth 验证与冲突仲裁、既有签名协议开放项及本轮状态/TTL/Storage 决策 → [agent.md Schema 与签发/验签流程澄清记录](agent.md/working/agent.md-schema与签发验签流程澄清.md)
 - AID 类型、owner/ownership_proof 可选但出现即合法、human 禁止 owner、共同签署字段集合、可见分号 canonical bytes、公开关系声明、Auth 关系写入与冲突裁定、owner-side 备份 ACL、`unbound`/`unusable` 与无专门 recovery → [AID 类型、owner 关系与换 owner 编排方案](agent.md/working/AID类型-owner关系与换owner编排方案.md)
 - Auth 权威写入状态、Schema 可选性与 human 禁止 owner、三字段共同声明与 self-owner 单签、canonical bytes、公开 owner proof 独立验证、active/pending 唯一性检查、owner 流程、状态传播、`unbound`/`unusable`、Storage 内部对象权限、服务端/四端 SDK 调整和分阶段验收 Checklist；剩余为正式 wire/RPC 文档和跨端向量落稿 → [AID 类型、owner 关系与 agent.md 签发/换 owner 完整设计与实施计划](agent.md/working/AID类型-owner关系完整设计与实施计划.md)
 - 本轮本地 Docker、单域、cross-SDK 与双域 federation 回归中的非任务失败及修复证据 → [本地 Docker 测试 Bug 清单](agent.md/working/本地Docker测试Bug清单.md)
 - `group.index` owner/admin SDK 生成签名索引、`_meta.group_indexes` 观察、`expected_index_etag` CAS、服务端正/负缓存与注入频率控制 → [群索引版本提示与附件引用方案](design/群索引版本提示与附件引用方案.md)、[SDK 文档索引](sdk/INDEX.md)
-
-### Service Proxy 与服务暴露
-
-- AUN Service Proxy、service_proxy 服务模块、SDK service-proxy-client、embedded registry、URL 路由、隧道协议和 Docker E2E 入口 → [AUN 反向代理服务方案与 TDD 实施计划](design/AUN反向代理服务方案与TDD实施计划.md)
-- Service Proxy `proxy.*` 控制面、proxy-server `register_services` 数据面注册、服务列表一致性和 wakeup 路由语义 → [Service Proxy RPC 手册](sdk/09-proxy-rpc-manual.md)、[服务协议](protocol/06-服务协议.md)
-- ACP Proxy 可借鉴点、GlobalRegistry/RSA 不照搬项、目录式 Web 边界 → [AUN 反向代理服务方案与 TDD 实施计划](design/AUN反向代理服务方案与TDD实施计划.md)
-- 不影响现有 Gateway、NameService、SDK 接口的 TDD 分阶段计划 → [AUN 反向代理服务方案与 TDD 实施计划](design/AUN反向代理服务方案与TDD实施计划.md)
-
-### 诊断与可观测性
-
-- RPC trace span、跨模块诊断字段、安全字段白名单 → [AUN RPC Trace 增强设计](design/2026-05-22-aun-rpc-trace-enhancement.md)
-- aun-console 消息通信服务端可观察总体面板、事实/推断边界 → [AUN 服务端消息通信诊断面板方案](design/AUN服务端消息通信诊断面板方案.md)
-- 服务端可观察的消息通信 P0 面板、过滤语义、数据来源 → [服务端消息通信诊断面板 P0 方案](design/服务端消息通信诊断面板P0方案.md)
-- P2P `message_inbox`、群消息 `group_inbox`、迁移期 fallback、后台 batch 回填和旧表 drop 收口 → [消息收件箱统一迁移方案](design/消息收件箱统一迁移方案.md)
-- 测试日志路径、测试输出、容器日志查看 → [aun测试运行指南](aun测试运行指南.md)
-- 跨语言 E2E trace 字段、日志产物、失败分类 → [跨语言容器E2E测试方案](design/跨语言容器E2E测试方案.md)
-
+
+### Service Proxy 与服务暴露
+
+- AUN Service Proxy、service_proxy 服务模块、SDK service-proxy-client、embedded registry、URL 路由、隧道协议和 Docker E2E 入口 → [AUN 反向代理服务方案与 TDD 实施计划](design/AUN反向代理服务方案与TDD实施计划.md)
+- Service Proxy `proxy.*` 控制面、proxy-server `register_services` 数据面注册、服务列表一致性和 wakeup 路由语义 → [Service Proxy RPC 手册](sdk/09-proxy-rpc-manual.md)、[服务协议](protocol/06-服务协议.md)
+- ACP Proxy 可借鉴点、GlobalRegistry/RSA 不照搬项、目录式 Web 边界 → [AUN 反向代理服务方案与 TDD 实施计划](design/AUN反向代理服务方案与TDD实施计划.md)
+- 不影响现有 Gateway、NameService、SDK 接口的 TDD 分阶段计划 → [AUN 反向代理服务方案与 TDD 实施计划](design/AUN反向代理服务方案与TDD实施计划.md)
+
+### 诊断与可观测性
+
+- RPC trace span、跨模块诊断字段、安全字段白名单 → [AUN RPC Trace 增强设计](design/2026-05-22-aun-rpc-trace-enhancement.md)
+- aun-console 消息通信服务端可观察总体面板、事实/推断边界 → [AUN 服务端消息通信诊断面板方案](design/AUN服务端消息通信诊断面板方案.md)
+- 服务端可观察的消息通信 P0 面板、过滤语义、数据来源 → [服务端消息通信诊断面板 P0 方案](design/服务端消息通信诊断面板P0方案.md)
+- P2P `message_inbox`、群消息 `group_inbox`、迁移期 fallback、后台 batch 回填和旧表 drop 收口 → [消息收件箱统一迁移方案](design/消息收件箱统一迁移方案.md)
+- 测试日志路径、测试输出、容器日志查看 → [aun测试运行指南](aun测试运行指南.md)
+- 跨语言 E2E trace 字段、日志产物、失败分类 → [跨语言容器E2E测试方案](design/跨语言容器E2E测试方案.md)
+
 ### E2EE 与跨语言一致性
 
 - SDK E2EE V2 API、会话管理、ProtectedHeaders、P2P/Group 当前主链路 → [SDK 文档索引](sdk/INDEX.md)、[E2EE V2 消息通信时序图](sdk/E2EE_V2消息通信时序图.md)
 - `protected_headers` 四端 API、合并优先级、元数据 HMAC 和解密信任边界 → [ProtectedHeaders 用法专题](sdk/ProtectedHeaders用法专题.md)
 - E2EE V2 1DH/per-AID wrap、bootstrap 能力声明、服务端 fanout → [E2EE V2 简化为 1DH + Per-AID Wrap 方案](design/E2EE_V2简化为1DH加Per-AID_Wrap方案.md)
-- 共享测试向量、transcript 回放、Python / TS / Go / JS 互通 → [aun测试运行指南](aun测试运行指南.md)、[跨语言容器E2E测试方案](design/跨语言容器E2E测试方案.md)
-
----
-
-## Layer 3：重点文档摘要
-
-### aun测试运行指南
-
+- 共享测试向量、transcript 回放、Python / TS / Go / JS 互通 → [aun测试运行指南](aun测试运行指南.md)、[跨语言容器E2E测试方案](design/跨语言容器E2E测试方案.md)
+
+---
+
+## Layer 3：重点文档摘要
+
+### aun测试运行指南
+
 记录本机 `agentid.pub/agentid.cn` 两套单节点环境以及三节点、federation 的 Compose、数据、project、网络与容器边界。真实双域各自固定 Issuer CA、服务 AID、MySQL UUID、workspace 和 Tester 目录，通过材料清单与运行态 mount 双重预检防止混用。指南统一 Go 1.24 与断网测试纪律，并定义停止写入后的 MySQL 单事务逻辑快照、三文件线上包的开箱默认值与可选生产覆盖、首部署导入和后续镜像升级流程；公网复测另有固定身份注册、TLS 和镜像发布门禁。
-
-### aun公网测试运行指南
-
-定义 `python/run-public-tests.py` 的公网专用运行方式。支持配置 issuer domain、smoke/integration/e2e/full/stress 套件和单用例选择；公网身份、每轮 HOME/临时目录、日志与报告独立于本地 Docker 和 `data-dist`。指南说明默认全链路 TLS 校验、显式身份创建确认、受保护目录拒绝规则、一次性 Docker runner、50 项 Python SDK full 矩阵，以及与 12 项服务端公网验收脚本的分工。
-
-### aun分布式测试运行指南
-
+
+### aun公网测试运行指南
+
+定义 `python/run-public-tests.py` 的公网专用运行方式。支持配置 issuer domain、smoke/integration/e2e/full/stress 套件和单用例选择；公网身份、每轮 HOME/临时目录、日志与报告独立于本地 Docker 和 `data-dist`。指南说明默认全链路 TLS 校验、显式身份创建确认、受保护目录拒绝规则、一次性 Docker runner、50 项 Python SDK full 矩阵，以及与 12 项服务端公网验收脚本的分工。
+
+### aun分布式测试运行指南
+
 规定当前 `D:\modelunion\kite` worktree 独立维护默认单实例、本地与公网真实域名双域 `agentid.pub/agentid.cn`、三节点 `dist-agentid.pub`、隔离 federation、服务端镜像、Tester 和部署产物，不得引用相邻 worktree。包含本地双域的 env 合并规则、固定身份双挂载 runner、Storage OSS 跨域授权/下载验收、公网固定身份注册与 TLS 复测、线上镜像门禁、跨域日志判定、跨 worktree 的停写整套冷克隆边界、分布式 Tester/cross-SDK、镜像哈希、Compose label 与 bind mount 强制预检、精确 Git 忽略边界；日常流程禁止在线或局部复制、擅自重签、`setup_aids.py` 或清库，Go Tester 统一 1.24。
-
-### 分布式 AUN 节点与服务启动流程
-
-整理当前分布式节点架构和启动时序。文档明确 `control master` 本身也是 worker 节点，aun-console 同时承载控制中心、注册中心和配置中心，worker 通过 launcher/control supervisor 注册节点、拉取 desired-state、建立 WebSocket watch、按 `managed` 目标状态启停服务；服务启动后通过本机 kernel 注册 RPC 能力，并优先从注册中心发现 Gateway business endpoint，随后由 launcher 上报 service instance 和 endpoints。文档还定义服务停用时 `running -> stopping -> stopped` 的 AUN 层优雅关停顺序、nameservice 使用注册中心 `public_http` 改写 302、配置中心 revision/binding 合并顺序，以及默认单实例兼容边界。
-
+
+### 分布式 AUN 节点与服务启动流程
+
+整理当前分布式节点架构和启动时序。文档明确 `control master` 本身也是 worker 节点，aun-console 同时承载控制中心、注册中心和配置中心，worker 通过 launcher/control supervisor 注册节点、拉取 desired-state、建立 WebSocket watch、按 `managed` 目标状态启停服务；服务启动后通过本机 kernel 注册 RPC 能力，并优先从注册中心发现 Gateway business endpoint，随后由 launcher 上报 service instance 和 endpoints。文档还定义服务停用时 `running -> stopping -> stopped` 的 AUN 层优雅关停顺序、nameservice 使用注册中心 `public_http` 改写 302、配置中心 revision/binding 合并顺序，以及默认单实例兼容边界。
+
 ### 消息同步与历史拉取改造方案
 
 定义在原 Forward Cursor 上增加 A/T/H 实时扫描窗口：新 Head 一律先 Tail，仍有未扫描 Gap 时再执行一页后台 Forward；History 是独立只读 RPC。方案明确 A/T/H 只是扫描水位，SDK 仅保证响应页内唯一有序发布，跨页由应用按 message_id 幂等并按 seq 排序；同时区分物理 GC retention floor 与 Group Forward 成员可见性下界，规定缺 sender IK 时最多 3 秒 single-flight 同步 bootstrap、Forward 按服务端原始页最大 seq 推进、页内缺号视为永久空号、坏密文不阻塞水位、三个 Pull Gate 的前后台 FIFO 与 3 秒旁路，以及四语言 SDK、服务端、Gateway、兼容矩阵和分布式 E2E 门禁。
@@ -236,52 +245,52 @@
 以当前代码为唯一事实来源，汇总 Python/Go Message 与 Group 服务端、Python/Go Gateway、Python/TypeScript/Go/JavaScript SDK 的实现完整度和横向一致性。问题按 P0/P1/P2 排序，覆盖跨 Gap ACK、retention 与 Group Forward 可见性边界、崩溃窗口、异步任务代际、反向快照、History 分页、GC/WAL/cache、响应上限、敏感日志与诊断缺口；明确迁移完成后 Python Group inbox-only 为基准，Go Group 仍合并旧表必须对齐，并记录已排除的误报。
 
 ### AUN 服务 Go 化重构精细化源码审查
-
-以当前工作树为代码基线，逐项核对 auth、ca、gateway、group、leaderboard、message、nameservice、service_proxy、storage、stream 的 Go/Python 调用链和 RPC 字段，并记录修复后的最终状态。Storage 短 SHA panic、Gateway 签名与 service-plane ACL、Message audit/WAL、Group 关闭与游标、CA CT/nonce、Leaderboard 跨实例 recovery、Storage mount/collab、Proxy/Stream 资源预算等已知问题均已闭合；Claude 报告的 60 条已确认项、76 条候选与原 4 条误报已完成源码复审映射，其中候选 C71/C72 经源码再核确认为已修复的兼容性缺陷。当前开放 P0/P1/P2 为 0/0/0，十服务通过 Docker/Linux Go race/vet/gofmt，Python 两层对应套件合计为 2344 passed、0 skipped；真实单域/双域 E2E 仍作为发布前动态门槛。
-
-### AUNClient 拆分重构执行方案
-
-定义在不改变公开 API、协议字段、事件名和默认行为的前提下，如何把 Python / Go / TypeScript / JavaScript SDK 的 `AUNClient` 拆为内部门面、运行时上下文、生命周期控制、RPC 流水线、消息投递、V2 E2EE、群状态和 peer 目录等组件。文档给出 19 个执行步骤、跨 SDK 迁移顺序、风险点和验收矩阵，并记录当前进度：Python 已形成组件化参考实现，TS/JS/Go 已完成 runtime、identity、peers、lifecycle 和 `RpcPipeline` preflight/签名/pull gate/raw call 接入。
-
-### AUNClient 门面化与 Runtime 状态迁移细化方案
-
-在既有 AUNClient 拆分方案基础上，进一步定义“完全门面化、状态全部迁入 runtime”的完成标准和分步执行方法。文档给出状态归属表，将身份与配置、基础依赖、生命周期、RPC、消息投递、V2 E2EE、群状态和 peer 状态分别归入 runtime 与对应 coordinator，并按 Step 0 到 Step 10 说明基线建立、ClientRuntime 状态分区、identity/lifecycle/RPC/delivery/V2/group state 迁移、runtime 写入接口收口、shim 清理、四端 parity 验证和回滚策略。
-
-### 跨语言容器E2E测试方案
-
-定义多语言 SDK 同时作为真实客户端运行的目标测试体系。核心模型是每个语言一个客户端容器，全连接同一 AUN server / gateway；业务消息走 AUN，test-runner 通过每个客户端暴露的 test-control HTTP API 编排动作和断言结果。当前单域落地覆盖 Python / TypeScript / Go / JavaScript 容器互操作；浏览器 JavaScript 网络 E2E 仍按宿主机 Playwright 运行。
-
-### E2EE V2 简化为 1DH + Per-AID Wrap 方案
-
-定义新 SDK 通过 bootstrap 入参声明 `e2ee_wrap_capabilities`，服务端再返回实际 `e2ee_wrap_policy`；旧 SDK 未声明时保留 legacy `3DH/device`。policy 不进入 envelope 或 AAD。方案规定 per-AID row 使用现有 8 字段结构并以 `device_id=""` 标识，服务端按真实 device fanout 但保存 `recipient_row_json` 原始 row，pull 时用原始 row 重建 recipient，确保 Merkle proof 和历史消息兼容。
-
-### AUN RPC Trace 增强设计
-
-设计 RPC trace 的 enter/exit span 结构，补充方法、AID、route、错误码、业务结果等诊断字段，并定义安全字段白名单。目标是在跨模块 RPC 失败时能定位到具体业务原因，而不是只看到模块路径和耗时。
-
-### AUN 服务端消息通信诊断面板方案
-
-记录 aun-console“消息通信”页面的服务端可观察诊断总体方案。方案明确只展示 Gateway、Message/Group、Federation、Service Plane 和模块业务指标可观察事实，不依赖 SDK 诊断模式，不读取 SDK 本地状态，并定义发送端、接收端、消息 ID、Group ID、关键词和任意方向过滤语义。服务端自主 Trace 默认关闭，只能通过面板临时开启。
-
-### 服务端消息通信诊断面板 P0 方案
-
-定义 aun-console 消息通信页的 P0 服务端诊断面板。范围限定为 Gateway、Message/Group、Federation 和 Service Plane 可观察事实，不采集 SDK 本地状态。文档给出发送端、接收端、消息 ID、Group ID 和任意方向过滤语义，并定义服务端 Trace、投递路径、Pull/ACK/GAP、E2EE、Federation、Service Plane 六个子标签，其中服务端自主 Trace 是默认关闭的运行时开关，`message.ack` 需区分 RPC 与同名事件的设备字段语义。
-
-### 消息收件箱统一迁移方案
-
-定义 P2P `message_inbox` 与群消息 `group_inbox` 的统一 receiver 读模型。方案要求 SDK RPC 契约不变，`group_events` 保持独立；迁移期新写入只写新 inbox，旧表仅作为 source/fallback，后台仅在 writer queue 空闲时 batch 回填并删除旧 batch，确认完成后再执行旧表 drop 和旧 DDL/fallback 收口。
-
-### AUN 反向代理服务方案与 TDD 实施计划
-
-定义 AUN Service Proxy / AUN 服务代理的整体方案：服务侧新增 `service_proxy` 模块，`service-proxy-server` 负责公网 HTTP/HTTPS 入口、WSS 隧道、在线连接索引和协议桥接；SDK 侧 `service-proxy-client` 负责 provider 侧 embedded registry、本地 endpoint 调用和服务摘要上报。方案明确去掉 ACP GlobalRegistry/RSA 同步，URL 以 `https://proxy.{issuer}/{user_name}/{svc_name}/...` 为 canonical，`https://{user_name}.{issuer}/proxy/{svc_name}/...` 由 NameService 跳转；Web 服务推荐 host-root 模式，目录式 path-prefix 只做受限转发。文档还按 Phase 0 到 Phase 11 给出 TDD 实施步骤，记录 Phase 10 已新增宿主机进程内 7 类 HTTP/SSE/WS/NameService/Web/ACL/双域边界 E2E，以及单域和双域 Docker E2E 脚本入口；真实 Docker 执行仍需先满足模块启用、镜像包含新模块和 `/ws/client` AUN 身份 resolver 前置条件。
-
+
+以当前工作树为代码基线，逐项核对 auth、ca、gateway、group、leaderboard、message、nameservice、service_proxy、storage、stream 的 Go/Python 调用链和 RPC 字段，并记录修复后的最终状态。Storage 短 SHA panic、Gateway 签名与 service-plane ACL、Message audit/WAL、Group 关闭与游标、CA CT/nonce、Leaderboard 跨实例 recovery、Storage mount/collab、Proxy/Stream 资源预算等已知问题均已闭合；Claude 报告的 60 条已确认项、76 条候选与原 4 条误报已完成源码复审映射，其中候选 C71/C72 经源码再核确认为已修复的兼容性缺陷。当前开放 P0/P1/P2 为 0/0/0，十服务通过 Docker/Linux Go race/vet/gofmt，Python 两层对应套件合计为 2344 passed、0 skipped；真实单域/双域 E2E 仍作为发布前动态门槛。
+
+### AUNClient 拆分重构执行方案
+
+定义在不改变公开 API、协议字段、事件名和默认行为的前提下，如何把 Python / Go / TypeScript / JavaScript SDK 的 `AUNClient` 拆为内部门面、运行时上下文、生命周期控制、RPC 流水线、消息投递、V2 E2EE、群状态和 peer 目录等组件。文档给出 19 个执行步骤、跨 SDK 迁移顺序、风险点和验收矩阵，并记录当前进度：Python 已形成组件化参考实现，TS/JS/Go 已完成 runtime、identity、peers、lifecycle 和 `RpcPipeline` preflight/签名/pull gate/raw call 接入。
+
+### AUNClient 门面化与 Runtime 状态迁移细化方案
+
+在既有 AUNClient 拆分方案基础上，进一步定义“完全门面化、状态全部迁入 runtime”的完成标准和分步执行方法。文档给出状态归属表，将身份与配置、基础依赖、生命周期、RPC、消息投递、V2 E2EE、群状态和 peer 状态分别归入 runtime 与对应 coordinator，并按 Step 0 到 Step 10 说明基线建立、ClientRuntime 状态分区、identity/lifecycle/RPC/delivery/V2/group state 迁移、runtime 写入接口收口、shim 清理、四端 parity 验证和回滚策略。
+
+### 跨语言容器E2E测试方案
+
+定义多语言 SDK 同时作为真实客户端运行的目标测试体系。核心模型是每个语言一个客户端容器，全连接同一 AUN server / gateway；业务消息走 AUN，test-runner 通过每个客户端暴露的 test-control HTTP API 编排动作和断言结果。当前单域落地覆盖 Python / TypeScript / Go / JavaScript 容器互操作；浏览器 JavaScript 网络 E2E 仍按宿主机 Playwright 运行。
+
+### E2EE V2 简化为 1DH + Per-AID Wrap 方案
+
+定义新 SDK 通过 bootstrap 入参声明 `e2ee_wrap_capabilities`，服务端再返回实际 `e2ee_wrap_policy`；旧 SDK 未声明时保留 legacy `3DH/device`。policy 不进入 envelope 或 AAD。方案规定 per-AID row 使用现有 8 字段结构并以 `device_id=""` 标识，服务端按真实 device fanout 但保存 `recipient_row_json` 原始 row，pull 时用原始 row 重建 recipient，确保 Merkle proof 和历史消息兼容。
+
+### AUN RPC Trace 增强设计
+
+设计 RPC trace 的 enter/exit span 结构，补充方法、AID、route、错误码、业务结果等诊断字段，并定义安全字段白名单。目标是在跨模块 RPC 失败时能定位到具体业务原因，而不是只看到模块路径和耗时。
+
+### AUN 服务端消息通信诊断面板方案
+
+记录 aun-console“消息通信”页面的服务端可观察诊断总体方案。方案明确只展示 Gateway、Message/Group、Federation、Service Plane 和模块业务指标可观察事实，不依赖 SDK 诊断模式，不读取 SDK 本地状态，并定义发送端、接收端、消息 ID、Group ID、关键词和任意方向过滤语义。服务端自主 Trace 默认关闭，只能通过面板临时开启。
+
+### 服务端消息通信诊断面板 P0 方案
+
+定义 aun-console 消息通信页的 P0 服务端诊断面板。范围限定为 Gateway、Message/Group、Federation 和 Service Plane 可观察事实，不采集 SDK 本地状态。文档给出发送端、接收端、消息 ID、Group ID 和任意方向过滤语义，并定义服务端 Trace、投递路径、Pull/ACK/GAP、E2EE、Federation、Service Plane 六个子标签，其中服务端自主 Trace 是默认关闭的运行时开关，`message.ack` 需区分 RPC 与同名事件的设备字段语义。
+
+### 消息收件箱统一迁移方案
+
+定义 P2P `message_inbox` 与群消息 `group_inbox` 的统一 receiver 读模型。方案要求 SDK RPC 契约不变，`group_events` 保持独立；迁移期新写入只写新 inbox，旧表仅作为 source/fallback，后台仅在 writer queue 空闲时 batch 回填并删除旧 batch，确认完成后再执行旧表 drop 和旧 DDL/fallback 收口。
+
+### AUN 反向代理服务方案与 TDD 实施计划
+
+定义 AUN Service Proxy / AUN 服务代理的整体方案：服务侧新增 `service_proxy` 模块，`service-proxy-server` 负责公网 HTTP/HTTPS 入口、WSS 隧道、在线连接索引和协议桥接；SDK 侧 `service-proxy-client` 负责 provider 侧 embedded registry、本地 endpoint 调用和服务摘要上报。方案明确去掉 ACP GlobalRegistry/RSA 同步，URL 以 `https://proxy.{issuer}/{user_name}/{svc_name}/...` 为 canonical，`https://{user_name}.{issuer}/proxy/{svc_name}/...` 由 NameService 跳转；Web 服务推荐 host-root 模式，目录式 path-prefix 只做受限转发。文档还按 Phase 0 到 Phase 11 给出 TDD 实施步骤，记录 Phase 10 已新增宿主机进程内 7 类 HTTP/SSE/WS/NameService/Web/ACL/双域边界 E2E，以及单域和双域 Docker E2E 脚本入口；真实 Docker 执行仍需先满足模块启用、镜像包含新模块和 `/ws/client` AUN 身份 resolver 前置条件。
+
 ### 远程 agent.md 缓存与 ETag 透传方案
 
 定义每个远程 AID 在 SDK 内存和本地持久化记录中维护一条 agent.md 状态：Python / TypeScript / Go 使用 `{aun_path}/AIDs/{aid}/agent.md` 与 `agentmd.json`，浏览器 JavaScript 使用 IndexedDB logical key。方案规定 Gateway 在 RPC response / event push 的 `_meta.agent_md_etags` 中按 `requester`、`peer`、`group` 注入元数据，保留旧别名兼容，并通过 300 秒正缓存、60 秒负缓存和默认 60 秒发送节流控制热路径开销；Message Service V2 P2P 信封携带 `agent_md.sender`。四端 SDK 自动观察 `_meta` 和信封 `agent_md.sender/group`，写入 `remote_etag` / `last_modified`，并遵守按需下载、无条件 GET、304 兼容、竞态和跨 SDK 一致性规则。
 
 ### agent.md Schema
 
-保留 legacy Ownership 2.0 的 agent.md/owner.md 独立声明、共识与撤销格式，不定义当前 2.1 的关系版本、owner 锁和释放终局。当前完整文件与身份校验见 [Ownership 协议定义 2.1](protocol/Ownership协议定义2.1.md)；`docs/protocol/agent.md/SCHEMA.md` 则是更早的 legacy 1.0 副本。
+保留 legacy Ownership 2.0 的 agent.md/owner.md 独立声明、共识与撤销格式，不定义当前 2.1 的关系版本、owner 锁和释放终局。当前完整文件与身份校验见 [Ownership 协议定义 2.1](protocol/Ownership协议定义2.1.md)；`docs/protocol/agent.md/SCHEMA.md` 则是更早的 legacy 1.0 副本。
 
 ### agent.md Schema 与签发/验签流程澄清记录
 
@@ -300,12 +309,20 @@
 记录本轮 owner 关系实施及单域、cross-SDK、双域 federation 回归中发现的非任务失败，包括 Go SQL mock 期望缺失、损坏 Python 字节码、Tester 原生 ABI、身份游标污染、双域端口冲突和 Group 成员状态异步持久化断言竞态；每项均列出根因、修复动作和验证结果。
 
 ### 群索引版本提示与附件引用方案
-
-定义 `group.index` 的 owner/admin SDK 生成、canonical JSONL、签名、`etag` / `body_hash`、`expected_index_etag` CAS、`_meta.group_indexes` 版本提示、Gateway/Message 转发边界、服务端正/负缓存、singleflight、写后失效/刷新、注入频率控制，以及 DB 保存核心设置、group.fs 保存大附件、附件稳定引用和 SDK `check/get/updateGroupIndex` 语义。
-
+
+定义 `group.index` 的 owner/admin SDK 生成、canonical JSONL、签名、`etag` / `body_hash`、`expected_index_etag` CAS、`_meta.group_indexes` 版本提示、Gateway/Message 转发边界、服务端正/负缓存、singleflight、写后失效/刷新、注入频率控制，以及 DB 保存核心设置、group.fs 保存大附件、附件稳定引用和 SDK `check/get/updateGroupIndex` 语义。
+
+### 0.5.21 SDK 应用集成指南
+
+面向应用开发者整理当前 0.5.21 工作区的身份与连接、批量消费和持久幂等、peer Pull/History、业务已读、resolve 全类型元数据与按需 owner 展示、Ownership 审批/reset、当前托管凭证、组织恢复、诊断及升级验收。示例统一使用 TypeScript，区分 Node 和浏览器。
+
+### 0.5.21 SDK 开发与移植指南
+
+面向四端维护者和新语言 SDK 实现者说明严格能力协商、稀疏 seq 与 A/T/H、共享 Gate 和背压、batch/single 选择、handler/水位/ACK 提交、运行时去重、resolve 缓存、双文件原 CAS、历史任务/reset、续期撤销、加密 checkpoint、证书并发、语言差异和分阶段验收。
+
 ### SDK 文档索引
 
-`docs/sdk/INDEX.md` 是 SDK 手册的三层子索引，覆盖快速开始、连接认证、E2EE V2、P2P device/TTL volatile 消息、Group 成员控制与两阶段群主转让、Storage MIME/Content-Type/OSS 403、Python `ErrorInfo.cause`、Group FS、Collab 和各类 RPC 手册。
+`docs/sdk/INDEX.md` 是 SDK 手册的三层子索引，覆盖快速开始、连接认证、E2EE V2、P2P 共享 seq/peer 游标、pending peers/统计快照、need_render、50k 内存去重/应用持久幂等、device/TTL volatile、Group 成员控制与两阶段群主转让、Storage、Group FS、Collab 和各类 RPC 手册。peer 模式本期限定单 Message 实例，设备级密钥安全证明可缺省。
 
 ### ProtectedHeaders 用法专题
 
@@ -313,61 +330,63 @@
 
 ### Ownership 管理专题
 
-保留 legacy `aun.ownership.v1` 四端 proof、托管、代签、代上传和 rekey 历史记录；文中“当前”指该历史基线，不作为 Ownership 2.1 契约或接入依据。
-
-### Ownership 协议定义 2.1
-
-定义当前普通双文件原始字节签名、自身份上传、owner.md 权限、持久 owner 锁、关系版本、release/权威删除、连续转移和审计；Group/Org 创建自动绑定、解散自动解绑、专属转移强制 rekey，实体名片 owner 本人尾签与 V2 上传授权单独分流；三个时间字段统一安全整数范围，invalid 与 unavailable 分别表示无效与不可用。实体 pending 固定完整 V2 授权与原 CAS，过期停止自动重传并保留待办，明确上传才生成新授权；同全文/ETag 已提交仅观察确认。SDK 普通 P2P 编排仅作非权威协作，不构成协议层授权。
-
-### Ownership SDK 编排指南 2.1
-
-定义七 Facade、明确审批、普通加密 P2P 载荷、公共 local_roles 与请求身份、本地事件、按角色核对完成证据和新鲜权威恢复；冻结重复发起复用、错误与任务状态分别记录、时间整数边界，文件保存、关系完成与清理分别跟踪；整体 30 秒从首次 GET 前计时，接收方固定授权摘要/期限，无控制消息也按精确本人历史同意恢复清理。
-
-Group/Org 作为 sub 时不进入这些通用任务、审批或 NS Ownership 账本；以其为 sub 误调用直接 not_applicable，符合普通 owner 规则时仍可作为 owner_aid。实体 owner 创建自动建立、解散自动解除，专属转移强制 rekey，名片由 owner 本人尾签，signer_aid 与 V2 上传授权绑定当前实体证书代际。
-
-### Ownership 2.1 SDK 应用集成指南
-
-说明应用身份准备、Group/Org 作为 sub 的专属边界、审批 UI/策略、任务事件、新鲜 checkOwnershipConsensus 和恢复接入；普通下载 ownership_status 保留 legacy proof 展示语义，不能作为 2.1 授权结果；说明实体授权过期保留待办/明确上传和无消息释放清理的应用处理。
-
-### Ownership 2.1 SDK 开发与移植指南
-
-以当前 Node TS 接线为参考，说明文件、证书、Storage authoritative/revision/expected_revision、持久 CAS/outbox 和实际收件边界；发布成功后保存权威 revision/ETag 标记，恢复区分未保存和已保存标记的核验条件，禁止刷新原提交条件；HTTP 428 统一映射 unsupported_protocol；通知恢复发送前逐条核对新鲜 NS，不以参考实现代替各语言验收；严格 OCSP issuer 绑定、本人原件/任务上下文及实体 pending 原授权复用以协议与逐项裁决为准，不默认全部行为以 TS 为准。
-
-### Ownership 2.1 详细设计
-
-定义四 SDK、NS、Storage 的组件职责、证据与原子边界、条件发布、名片同步和旧版隔离；说明 reserve 无法证明 SQL 提交及 DB+journal 一起回退时的人工恢复与可信上界门槛；补当前时间 OCSP 复核、原授权固定、无消息释放清理和实体授权过期恢复边界。
-
-### Ownership 2.1 TDD 分阶段实施计划
-
-保存实施顺序、共同向量、冻结实现契约与历史测试账本，统一 Group/Org 的 sub 边界、HTTP 428/错误分类及非权威 P2P；第 13 节区分各端当前源码、运行版本、恢复进程边界及未验证环境；旧群自签/token 上传结果保留为旧契约事实，不能作为新 owner 本人名片契约验收；第 13.7 节单列本轮 13 项复审后的本地验证，不改写历史网络账本。
-
-### Ownership 2.1 代码审查报告
-
-保留首次审查的实现完整性、协议一致性、四端差异及服务端问题；第九节记录用户授权后的 6 个 P1、12 个 P2、追加恢复窗口修复、受影响测试证据和验证边界；第十节记录三项契约冻结与本地验证，第十一节记录 Group/Org 既有转移/解散上的约束与恢复修复、owner 本人名片和 V2 授权、四端与服务按断点取得的本地测试证据、已知基线首败及未执行环境验收。第十二节新增本轮 6 个 P1、7 个 P2 的影响、修代码/修文档裁决和参考端，记录 V2 过期停止自动重传的用户决定、无消息释放清理、Red → Green 和断点回归结果。修复判断以 2.1 协议和冻结契约为准，不外推真实部署验收。
-
-### Ownership SDK 集成指南
-
-保留 2026-10-09 legacy TypeScript 应用接入及 proof、escrow、代上传流程。当前七 Facade、审批与新鲜共识见 [2.1 应用集成指南](sdk/Ownership2.1-SDK应用集成指南.md)。
-
-### Ownership SDK 实现指南
-
-保留 legacy proof/escrow、metadata 和 rekey 移植记录。当前双文件、持久任务、权威条件发布和恢复见 [2.1 开发与移植指南](sdk/Ownership2.1-SDK开发与移植指南.md)。
-
-### Ownership 协议定义
-
-保留 legacy `aun.ownership.v1`、proof、托管和 owner 代上传授权格式；当前文件、锁、版本及审计以 [协议定义 2.1](protocol/Ownership协议定义2.1.md) 为准。
+保留 legacy `aun.ownership.v1` 四端 proof、托管、代签、代上传和 rekey 历史记录；文中“当前”指该历史基线，不作为 Ownership 2.1 契约或接入依据。
+
+### Ownership 协议定义 2.1
+
+定义 NS 当前 `agent.md` 与 owner Storage 当前 `owner.md` 的原始字节多签、逐块 prefix 验证、multi-v1 表示协商、自身份上传、owner.md 权限和当前关系校验；owner 锁与响应 Header 只投影本次材料的校验结果。release 保持被释放的版本 v，sub 清理关系字段后的版本投影为 0、再次绑定默认 1；转移仍核对 v 与 v+1。Group/Org 创建自动绑定、解散自动解绑、专属转移强制 rekey，实体名片以实体主签、owner token 上传与可选 owner 附签单独分流；三个时间字段统一安全整数范围，invalid 与 unavailable 分别表示无效与不可用。实体 pending 固定完整多签原文、owner/实体代际及原 CAS，取消额外 V2 上传授权与过期窗口，应用显式重试仍须新鲜核对当前代际；同全文/ETag 已提交仅观察确认。SDK 普通 P2P 编排仅作非权威协作，不构成协议层授权。新服务端保留旧 SDK 注册、绑定、转移、查询和解绑 RPC 及隔离的 Auth JSONL，仅激活旧 NS ownership_proof；不写 2.1 双文件，不授 2.1 lock/version/consensus，也不覆盖已存现代声明。
+
+### Ownership SDK 编排指南 2.1
+
+定义七 Facade、明确审批、普通加密 P2P 载荷、公共 local_roles 与请求身份、本地事件、按角色核对完成证据和新鲜权威恢复；冻结重复发起复用、错误与任务状态分别记录、时间整数边界，文件保存、关系完成与清理分别跟踪；整体 30 秒从首次 GET 前计时，接收方固定授权摘要/期限，无控制消息也按精确本人历史同意恢复清理。
+
+Group/Org 作为 sub 时不进入这些通用任务或审批；以其为 sub 误调用直接 not_applicable，符合普通 owner 规则时仍可作为 owner_aid。实体 owner 创建自动建立、解散自动解除，专属转移强制 rekey，名片由实体主签、owner token 上传，可选 owner 附签不改变当前授权。
+
+### Ownership 2.1 SDK 应用集成指南
+
+面向 EC CLI／Evolcore 集成开发者，提供创建和加载 sub、由 sub 发起、human owner App 点击审批的分步 TS 示例，明确 EC CLI 当前尚未集成 Ownership；含绑定、释放、转移与恢复流程图。说明普通 agent 注册 owner 可选、sign/verify 公共门面、显式文件输入与多签结果、Group/Org 实体主签和 owner 上传、审批 UI/策略、任务事件、新鲜 checkOwnershipConsensus 和恢复接入；普通下载 ownership_status 保留 legacy proof 展示语义，不能作为 2.1 授权结果；实体 pending 保留完整原件和原 CAS，由应用显式重试。
+
+### Ownership 2.1 SDK 开发与移植指南
+
+面向 Rust 等新语言 SDK 开发者，以当前 Node TS 接线为参考，提供分层、共识、实际收件、持久恢复、sub 发起／human owner 审批绑定、释放与转移流程图及短接口示例。说明公开签验门面与唯一内部核心、多签 prefix、离线证书与显式 resolver、HTTP 表示协商和现代实体指纹绑定；Storage authoritative 保留当前完整原文/摘要/存在性，object_id/version 不作为读取一致性或共识条件；owner.md 使用 create_upload_session→HTTP PUT→complete_upload 的同一会话，沿用 expected_version 作发布 CAS，agent 保留原 ETag，持久 CAS/outbox 恢复不刷新原提交条件；HTTP 428 统一映射 unsupported_protocol；通知恢复发送前逐条核对新鲜 NS，不以参考实现代替各语言验收；严格 OCSP issuer 绑定、本人原件/任务上下文和实体 pending 完整原件恢复以协议与逐项裁决为准，不默认全部行为以 TS 为准。
+
+### Ownership 2.1 详细设计
+
+定义四 SDK、NS、Storage 的组件职责、NS原ETag、owner.md 同会话完整发布与 expected_version CAS、名片同步、legacy RPC/Auth JSONL 隔离与 agent.md 非回归；NS 可信内部 Storage 副本仅限本域 default/agent.md，不经客户端会话，不写删 owner.md，也不替代 NS 权威；Ownership 关系事实只由`sub_aid/agent.md` 与 owner_aid 规范路径的 `owner.md` 提供；普通 agent.md 的读写、缓存、原 CAS 和 Storage 副本不依赖关系验证，Header 只投影本次校验结果；补 release 保持 v、清理后版本投影为 0／重绑默认 1，以及当前时间 OCSP 复核、原文件及 CAS 固定、无消息释放清理和实体多签恢复边界。
+
+### Ownership 2.1 TDD 分阶段实施计划
+
+保存早期实施顺序、共同向量、原实施阶段冻结契约与历史测试账本，统一 Group/Org 的 sub 边界、HTTP 428/错误分类及非权威 P2P；第 13 节记录当时各端源码、运行版本、恢复进程边界及未验证环境，第 13.3 节的历史冻结契约不覆盖当前协议；旧群自签/token 上传结果保留为旧契约事实，不能作为新 owner 本人名片契约验收；第 13.7 节单列 2026-10-11 的 13 项复审后本地验证，第 13.8 节关联 2026-10-13 更正与修复边界，不改写历史网络账本。
+
+### Ownership 2.1 代码审查报告
+
+当前格式与兼容更正见[第二十二节](audit/Ownership2.1代码审查报告.md#二十二2026-10-18-恢复发布格式与历史兼容更正)：继续使用 agent.md/owner.md 和原控制字段；普通正文保留关系材料且不以前置 Ownership 共识为条件；保留 reset、绑定容错与 0.5.19 及更早任务兼容。第十六至二十一节保留阶段记录，其中独立资源、显式迁移及资源标记契约已经撤销，原通过计数不能作为恢复后专项、现场部署或全平台验收结论。
+
+### Ownership SDK 集成指南
+
+保留 2026-10-09 legacy TypeScript 应用接入及 proof、escrow、代上传流程。当前七 Facade、审批与新鲜共识见 [2.1 应用集成指南](sdk/Ownership2.1-SDK应用集成指南.md)。
+
+### Ownership SDK 实现指南
+
+保留 legacy proof/escrow、metadata 和 rekey 移植记录。当前双文件、持久任务、权威条件发布和恢复见 [2.1 开发与移植指南](sdk/Ownership2.1-SDK开发与移植指南.md)。
+
+### Ownership 协议定义
+
+保留 legacy `aun.ownership.v1`、proof、托管和 owner 代上传授权格式；当前文件、锁、版本及审计以 [协议定义 2.1](protocol/Ownership协议定义2.1.md) 为准。
 
 ### Service Proxy RPC 手册
-
-定义 `proxy.register_services` / `proxy.unregister_services` / `proxy.list_services` 的 Gateway 控制面语义，以及 proxy-server `register_services` 数据面隧道消息、服务列表与连接绑定、一致性约束和 wakeup 路由策略。
-
+
+定义 `proxy.register_services` / `proxy.unregister_services` / `proxy.list_services` 的 Gateway 控制面语义，以及 proxy-server `register_services` 数据面隧道消息、服务列表与连接绑定、一致性约束和 wakeup 路由策略。
+
 ### SDK 查阅指南
 
 `docs/sdk/AUN_DOCS_GUIDE.md` 说明如何按行区间渐进式读取 SDK 文档，避免一次性加载过多文档内容。
-
-### 凭证与组织服务 SDK 指南
-
-[应用集成指南](sdk/凭证与组织服务SDK应用集成指南.md)覆盖 service-plane 边界、完整验证、Credential 请求绑定、受保护读取、首次 admission、创建/转让恢复及解散清理；[开发与移植指南](sdk/凭证与组织服务SDK开发与移植指南.md)定义四端共同密码学、CAP、binding、facade/RPC、checkpoint 和测试向量契约。
+
+### 凭证与组织服务 SDK 指南
+
+[应用集成指南](sdk/凭证与组织服务SDK应用集成指南.md)覆盖 service-plane 边界、完整验证、Credential 请求绑定、受保护读取、首次 admission、创建/转让恢复及解散清理；[开发与移植指南](sdk/凭证与组织服务SDK开发与移植指南.md)定义四端共同密码学、CAP、binding、facade/RPC、checkpoint 和测试向量契约。
+
+[凭证服务 RPC 手册](sdk/09-凭证服务RPC手册.md)与[组织服务 RPC 手册](sdk/09-组织服务RPC手册.md)按两个服务当前 dispatcher 描述实际方法、请求用途和受限/未实现边界。
 
 ### AUN SDK 0.5.6 更新日志
 
@@ -375,56 +394,56 @@ Group/Org 作为 sub 时不进入这些通用任务、审批或 NS Ownership 账
 
 ### 四 SDK 版本对齐变更清单
 
-`python/CHANGES_FOR_PARITY.md` 以 Python SDK 历史实现为主线记录 Go / TypeScript / JavaScript 的对齐要求。当前 v0.5.19 章节以 `1f03bf2d` 的仓库 v0.5.18 为基线，记录跨设备已读未读、Ownership 2.1 持久编排、显式 type/owner 注册、实体名片代签与 rekey、凭证完整验证、组织门面与服务事件验签；列出四端 API、Python 函数定位、语言差异和测试入口，并保留 v0.5.18 历史章节。
+`python/CHANGES_FOR_PARITY.md` 以 Python SDK 历史实现为主线记录 Go / TypeScript / JavaScript 的对齐要求。当前 v0.5.21 章节以已发布 v0.5.20 对应的 `08221fbb` 快照为基线，记录按对端 Pull、批量交付与背压／ACK、Ownership 原格式与 reset／旧任务兼容、凭证续期及撤销分页、组织恢复和敏感 checkpoint、诊断与证书并发，以及 resolve frontmatter、按需共识和 owner.md 快照/TTL；列出四端实现和测试入口、语言差异及未验环境，保留 v0.5.20 和更早历史章节。
 
 ### AUN CLI 手册
-
-面向 CLI 使用者，说明 Python CLI 位于 `D:\modelunion\kite\aun-sdk-core\python\src\aun_cli`，安装后入口为 `aun`，也可通过 `python -m aun_cli` 运行。文档列出全局选项、`~/.aun/cli.toml` profile 配置、身份、P2P 消息、群组、`aun group fs`、`aun fs`、对象存储、Collab、agent.md、keys、诊断和 bench 命令集；其中 Storage VFS 覆盖 `touch/du/quota/getfacl`，Group FS 覆盖 `setfacl/getfacl` 角色 ACL，并给出常用示例和退出码。
-
-### AUN CLI 设计文档
-
-描述当前 `python/src/aun_cli` 实现，而不是早期设想。文档覆盖 Typer 根应用、命令模块目录、`adapter.CLISession` 对 AIDStore/AUNClient 的生命周期桥接、Gateway discovery 边界、profile 解析顺序、命令注册表、各命令组职责、错误码映射和当前未实现命令边界。
-
-### AUN Storage 架构设计
-
+
+面向 CLI 使用者，说明 Python CLI 位于 `D:\modelunion\kite\aun-sdk-core\python\src\aun_cli`，安装后入口为 `aun`，也可通过 `python -m aun_cli` 运行。文档列出全局选项、`~/.aun/cli.toml` profile 配置、身份、P2P 消息、群组、`aun group fs`、`aun fs`、对象存储、Collab、agent.md、keys、诊断和 bench 命令集；其中 Storage VFS 覆盖 `touch/du/quota/getfacl`，Group FS 覆盖 `setfacl/getfacl` 角色 ACL，并给出常用示例和退出码。
+
+### AUN CLI 设计文档
+
+描述当前 `python/src/aun_cli` 实现，而不是早期设想。文档覆盖 Typer 根应用、命令模块目录、`adapter.CLISession` 对 AIDStore/AUNClient 的生命周期桥接、Gateway discovery 边界、profile 解析顺序、命令注册表、各命令组职责、错误码映射和当前未实现命令边界。
+
+### AUN Storage 架构设计
+
 定义 AUN Storage 的 SDK VFS、low-level storage client、Storage Service、Storage Core、Metadata Engine 和 Blob Backend 分层。大文件主数据流量直连 localfs/OSS/S3/COS backend，控制面通过 `storage.*` RPC 管理权限、配额、session/ticket、元数据提交和事件；普通应用通过 SDK VFS 使用类 POSIX 文件操作。SDK 手册补充四语言实际字节 MIME 识别、session/PUT/complete Content-Type 一致性和 OSS 403 边界；底层 RPC 保留给能自行完成该编排的高级客户端。
-
-### AUN Storage SDK 存储分层设计
-
-定义 Python SDK 中 `StorageVFS` 与 `StorageLowLevel` 的分层职责。文档给出应用默认入口、low-level RPC 一对一封装、`NodeView/ObjectView/QuotaView` 返回类型、上传下载编排、路径规范化、P1 list 兼容实现、服务端 code 到 SDK 异常的映射，以及后续 TS/Go/JS 对齐要求。
-
-### AUN Storage CLI-fs 命令设计
-
-定义 `aun fs` 命令组的用户语义和工程落地方式。文档覆盖 `ls/stat/cat/cp/mv/rm/mkdir/ln/df` 等命令、`<AID>:<path>` 寻址规则、操作者身份来源、Typer 命令组注册、路径解析工具、现有 `storage_core.py` 迁移、端到端场景和输出格式规范。
-
-### AUN Storage 分阶段实施计划
-
-把 AUN Storage 架构、SDK 分层和 CLI 设计落地为 6 个 TDD 阶段。文档记录 P1 VFS 基础读写层、P2 symlink 原语、P3 `storage.fs.*` 统一 RPC、P4 ACL/token、P5 四语言 SDK/CLI 对齐和 P6 mount/umount 的实际修改范围、执行顺序、单元/集成/E2E 覆盖内容、Docker 内 Python/TS/Go 实测结果、JS 浏览器 Playwright Storage VFS P6 E2E 补跑结果、公网验证口径修正，以及 P6 退群自动失效和完整虚拟卷生命周期等遗留边界；并在每阶段开始前展开服务端表/RPC 变更、任务依赖图、可并行工作包、TDD 执行步骤和 Docker 验证纪律。
-
-### AUN FS POSIX 覆盖与补全计划
-
-`aun-fs-posix-coverage.md` 按 POSIX 命令对照 Storage VFS 与 Group FS 的 CLI、SDK、LowLevel、RPC 覆盖情况，列出 `touch/du/readlink/lstat/group.fs.getfacl/head/tail/quota/group fs setfacl` 等缺口和架构不适用项。`aun-fs-completion-plan.md` 在 2026-06-26 代码复审后修正过期判断，记录当前真实基线，并按 TDD 拆解 Phase 0 基线护栏、P0-A CLI 快速补齐、P0-B 客户端聚合、P0-C `storage.fs.touch` 与 `group.fs.get_acl/list_acl` 新 RPC、SDK 别名和低优先级能力；每项包含 Red/Green/Refactor、涉及文件、验收命令、接口确认点和回滚策略。
-
-### 群文件系统 group.fs POSIX 化详细设计
-
-定义群文件系统对外模型：统一为 `group.fs.*`、`client.group.fs.*` 和 `aun group fs`。文档规定群自有区与成员 `memberdata` 由 `group_aid:/...` 路径表达；群自有区允许当前 `group_aid` 证书签名、默认 `role:owner`、以及 owner 通过 `group.fs.set_acl` 显式授权后的 `role:admin` 写入，撤销使用 `group.fs.remove_acl`，查询使用 `group.fs.get_acl/list_acl`；`group_aid:/memberdata/{member_ref}/...` 在服务端映射到 `member_aid:/group_data/{group_aid}/...`，跨域成员必须使用完整 AID；上传、下载和远程复制统一用 `cp`，不提供 `read/write/put/get` 主入口，数据面由 SDK 编排，group 服务只负责控制面。
-
-### 群自有区角色 ACL 写权限实施方案
-
-定义群自有区写权限调整方案。群自有区是 `owner_aid = group_aid` 下除系统保留根外的整个 namespace，不与群主或管理员个人 storage 混用；owner 默认可写，admin 只有在 owner 通过 `group.fs.set_acl` 显式授予 `role:admin` ACL 后可写，并通过 `group.fs.remove_acl` 撤销、`group.fs.get_acl/list_acl` 查询。方案还规定 `group.set_role` 只改变 membership、不联动 ACL，`memberdata` / `group_data` 规则不变，Storage 写权限与控制面写入口均记录 `storage.write_auth` 审计，并给出 storage、group.fs、collab 和 CLI 的 TDD 执行计划。
-
-### 系统目录保护方案
-
-定义 `memberdata` 与 `group_data` 的分层保护。`memberdata` 不是隐藏目录，但根和成员槽位根不可被普通文件操作破坏，group AID 命名空间下的普通 Storage 写入必须拒绝；`group_data` 是成员个人 Storage 内部真实根，Storage 服务端必须在目录树浏览中隐藏它，读/下载按普通 read 权限处理，写入、删除、重命名、挂载、授权和状态变更必须拒绝。文档同时规定 `group_data` 空间计入真实 owner AID 配额，group.fs 是可信授权写入路径，并给出访问矩阵、生命周期、审计和测试验收要求。
-
-### 群文件系统 group.fs POSIX 化分阶段实施计划
-
-把 group.fs 重构拆为 8 个阶段：契约冻结、服务端路径解析与 memberdata 映射、读侧 POSIX RPC、写侧控制面、Python SDK GroupFSVFS、CLI `aun group fs`、TS/JS/Go SDK 对齐、旧兼容入口移除和 Docker 单域/双域 E2E。每阶段都按阶段目标、IPO、Step-by-step 流程、用例集、Checklist、验收和回滚展开；Phase 8 已记录本地目标回归、Docker 镜像重建、单域 Python/CLI E2E、四语言 cross-sdk group.fs 矩阵和双域 group.fs/memberdata 验收结果。
-
-### collab 协作层服务端编排与实施计划
-
-定义 collab 是锚定在 storage 上的自包含版本化目录，服务端负责 `collab.*` 编排、`collab_ledger` 台账、乐观锁、行级 diff3、snapshot、export/adopt、prune 和群协作注册表。Plan 1 拆解 storage 进程内服务端基础实现和测试；Plan 2 扩展 Python SDK/CLI 与单域 Docker E2E；Plan 3 扩展 Go / TypeScript / JavaScript SDK、跨语言互操作和双域边界验证。
-
+
+### AUN Storage SDK 存储分层设计
+
+定义 Python SDK 中 `StorageVFS` 与 `StorageLowLevel` 的分层职责。文档给出应用默认入口、low-level RPC 一对一封装、`NodeView/ObjectView/QuotaView` 返回类型、上传下载编排、路径规范化、P1 list 兼容实现、服务端 code 到 SDK 异常的映射，以及后续 TS/Go/JS 对齐要求。
+
+### AUN Storage CLI-fs 命令设计
+
+定义 `aun fs` 命令组的用户语义和工程落地方式。文档覆盖 `ls/stat/cat/cp/mv/rm/mkdir/ln/df` 等命令、`<AID>:<path>` 寻址规则、操作者身份来源、Typer 命令组注册、路径解析工具、现有 `storage_core.py` 迁移、端到端场景和输出格式规范。
+
+### AUN Storage 分阶段实施计划
+
+把 AUN Storage 架构、SDK 分层和 CLI 设计落地为 6 个 TDD 阶段。文档记录 P1 VFS 基础读写层、P2 symlink 原语、P3 `storage.fs.*` 统一 RPC、P4 ACL/token、P5 四语言 SDK/CLI 对齐和 P6 mount/umount 的实际修改范围、执行顺序、单元/集成/E2E 覆盖内容、Docker 内 Python/TS/Go 实测结果、JS 浏览器 Playwright Storage VFS P6 E2E 补跑结果、公网验证口径修正，以及 P6 退群自动失效和完整虚拟卷生命周期等遗留边界；并在每阶段开始前展开服务端表/RPC 变更、任务依赖图、可并行工作包、TDD 执行步骤和 Docker 验证纪律。
+
+### AUN FS POSIX 覆盖与补全计划
+
+`aun-fs-posix-coverage.md` 按 POSIX 命令对照 Storage VFS 与 Group FS 的 CLI、SDK、LowLevel、RPC 覆盖情况，列出 `touch/du/readlink/lstat/group.fs.getfacl/head/tail/quota/group fs setfacl` 等缺口和架构不适用项。`aun-fs-completion-plan.md` 在 2026-06-26 代码复审后修正过期判断，记录当前真实基线，并按 TDD 拆解 Phase 0 基线护栏、P0-A CLI 快速补齐、P0-B 客户端聚合、P0-C `storage.fs.touch` 与 `group.fs.get_acl/list_acl` 新 RPC、SDK 别名和低优先级能力；每项包含 Red/Green/Refactor、涉及文件、验收命令、接口确认点和回滚策略。
+
+### 群文件系统 group.fs POSIX 化详细设计
+
+定义群文件系统对外模型：统一为 `group.fs.*`、`client.group.fs.*` 和 `aun group fs`。文档规定群自有区与成员 `memberdata` 由 `group_aid:/...` 路径表达；群自有区允许当前 `group_aid` 证书签名、默认 `role:owner`、以及 owner 通过 `group.fs.set_acl` 显式授权后的 `role:admin` 写入，撤销使用 `group.fs.remove_acl`，查询使用 `group.fs.get_acl/list_acl`；`group_aid:/memberdata/{member_ref}/...` 在服务端映射到 `member_aid:/group_data/{group_aid}/...`，跨域成员必须使用完整 AID；上传、下载和远程复制统一用 `cp`，不提供 `read/write/put/get` 主入口，数据面由 SDK 编排，group 服务只负责控制面。
+
+### 群自有区角色 ACL 写权限实施方案
+
+定义群自有区写权限调整方案。群自有区是 `owner_aid = group_aid` 下除系统保留根外的整个 namespace，不与群主或管理员个人 storage 混用；owner 默认可写，admin 只有在 owner 通过 `group.fs.set_acl` 显式授予 `role:admin` ACL 后可写，并通过 `group.fs.remove_acl` 撤销、`group.fs.get_acl/list_acl` 查询。方案还规定 `group.set_role` 只改变 membership、不联动 ACL，`memberdata` / `group_data` 规则不变，Storage 写权限与控制面写入口均记录 `storage.write_auth` 审计，并给出 storage、group.fs、collab 和 CLI 的 TDD 执行计划。
+
+### 系统目录保护方案
+
+定义 `memberdata` 与 `group_data` 的分层保护。`memberdata` 不是隐藏目录，但根和成员槽位根不可被普通文件操作破坏，group AID 命名空间下的普通 Storage 写入必须拒绝；`group_data` 是成员个人 Storage 内部真实根，Storage 服务端必须在目录树浏览中隐藏它，读/下载按普通 read 权限处理，写入、删除、重命名、挂载、授权和状态变更必须拒绝。文档同时规定 `group_data` 空间计入真实 owner AID 配额，group.fs 是可信授权写入路径，并给出访问矩阵、生命周期、审计和测试验收要求。
+
+### 群文件系统 group.fs POSIX 化分阶段实施计划
+
+把 group.fs 重构拆为 8 个阶段：契约冻结、服务端路径解析与 memberdata 映射、读侧 POSIX RPC、写侧控制面、Python SDK GroupFSVFS、CLI `aun group fs`、TS/JS/Go SDK 对齐、旧兼容入口移除和 Docker 单域/双域 E2E。每阶段都按阶段目标、IPO、Step-by-step 流程、用例集、Checklist、验收和回滚展开；Phase 8 已记录本地目标回归、Docker 镜像重建、单域 Python/CLI E2E、四语言 cross-sdk group.fs 矩阵和双域 group.fs/memberdata 验收结果。
+
+### collab 协作层服务端编排与实施计划
+
+定义 collab 是锚定在 storage 上的自包含版本化目录，服务端负责 `collab.*` 编排、`collab_ledger` 台账、乐观锁、行级 diff3、snapshot、export/adopt、prune 和群协作注册表。Plan 1 拆解 storage 进程内服务端基础实现和测试；Plan 2 扩展 Python SDK/CLI 与单域 Docker E2E；Plan 3 扩展 Go / TypeScript / JavaScript SDK、跨语言互操作和双域边界验证。
+
 ### Notify 通知方案
 
 定义 `client.notify()` 的 JSON-RPC Notification 发送语义。方案规定 notify 只投递在线长连接设备，不做离线存储、不分配 seq、不进入 pull/ack；同时说明服务端通知、AID 在线转发、群在线转发、跨域 federation 转发的路由模型，以及和 `message.send` / `group.send` 可靠应用事件的分工。