@agentunion/fastaun 0.5.20 → 0.5.22

package/_packed_docs/sdk/INDEX.md

@@ -8,36 +8,40 @@
 
 | 文档 | 说明 |
 |------|------|
+| [0.5.21 SDK 应用集成指南](0.5.21-SDK应用集成指南.md) | TypeScript 接入 · batch 持久幂等 · peer 同步 · resolve/owner 展示 · 凭证组织恢复 · 诊断与升级 |
+| [0.5.21 SDK 开发与移植指南](0.5.21-SDK开发与移植指南.md) | 四端公开契约 · peer 水位/流控/提交 · frontmatter 与共识缓存 · 原 CAS/旧任务/reset · checkpoint · 语言差异和验收 |
+| [0.5.22 SDK 应用集成指南](0.5.22-SDK应用集成指南.md) | TypeScript 接入 · 消息订阅 · 两种绑定与审批恢复 · resolve 展示 · 60 秒读缓存与刷新 · 撤销同步和完整成员包 |
+| [0.5.22 SDK 开发与移植指南](0.5.22-SDK开发与移植指南.md) | 后台退避 · 群状态 · 两种绑定与 Stage/CAS · 消息内部消费 · 撤销同步 · 组织恢复及配套服务修复 · 默认读缓存 · Rust 清单 |
 | [CHANGELOG-0.5.6](CHANGELOG-0.5.6.md) | **0.5.6 版本更新日志**：首次签名者回源 · 下载提交前验签 · 消息窗口 · 显式 change-seed · 语言能力边界 |
 | [01-快速开始](01-快速开始.md) | 安装 · 三主体模型 · 最小示例 · 多语言构造 |
-| [02-WebSocket协议](02-WebSocket协议.md) | 握手流程 · Capabilities 能力声明 · JSON-RPC 消息格式 · 裸 WebSocket 示例 |
-| [03-核心概念](03-核心概念.md) | AID · AIDStore · AUNClient · A/T/H 消息窗口 · 每个 AUNClient 一个 Pull Gate · 九态状态机 · E2EE |
-| [04-连接与认证](04-连接与认证.md) | 注册加载 · 认证连接 · 当前 access token getter · Python Push 自动登记 · 网关发现 · 事件 · 已读状态本地补偿完成事件 · agent.md 自动观察 |
+| [02-WebSocket协议](02-WebSocket协议.md) | 握手流程 · 严格布尔 peer 能力声明 · JSON-RPC 消息格式 · 裸 WebSocket 示例 |
+| [03-核心概念](03-核心概念.md) | AID · AIDStore · AUNClient · peer A/T/H 与稀疏覆盖 · N=4 Pull Gate 与动态共享队列 · 50k 内存去重 及 store/client 边界 · 九态状态机 · E2EE |
+| [04-连接与认证](04-连接与认证.md) | 注册加载 · 认证连接 · 当前 access token getter · Python Push 自动登记 · 网关发现 · 事件 · 已读状态本地补偿完成事件 · agent.md 自动观察 · resolve frontmatter 与按需 ownership |
 | [Ownership管理专题（legacy）](Ownership管理专题.md) | 四端 `aun.ownership.v1` P2P owner API · 应用层 accept/reject · identity escrow · owner 代签 agent.md · release 解绑/rekey · 崩溃恢复 · 完整消息 payload · metadata 状态 |
 | [Ownership SDK集成指南（legacy）](Ownership-SDK集成指南.md) | TypeScript 应用层快速接入 · 审批 API · 状态查询 · SDK 自动编排流程图 |
 | [Ownership SDK实现指南（legacy）](Ownership-SDK实现指南.md) | 四端移植入口 · proof/escrow · 消息拦截 · metadata · rekey/上传恢复 · 验收 |
 | [Ownership协议定义（legacy）](../protocol/Ownership协议定义.md) | P2P 消息 schema · proof/签名 · agent.md · escrow · owner 授权头 · 现有 RPC |
-| [Ownership 协议定义 2.1](../protocol/Ownership协议定义2.1.md) | 关系仅由 agent.md/owner.md 确认 · release 保持 v、清理后 0／重绑默认 1 · Header 结果投影 · Group/Org 专属生命周期、实体主签与 owner token 上传 · owner完整原文/存在性再读 · 隔离的旧 SDK owner RPC/Auth JSONL · 无Storage路径历史 |
-| [Ownership SDK 编排指南 2.1](Ownership-SDK编排指南2.1.md) | 当前七 Facade、审批、持久任务/恢复 · 无消息历史同意释放清理 · Group/Org not_applicable 门禁 |
-| [Ownership 2.1 应用集成指南](Ownership2.1-SDK应用集成指南.md) | 普通 agent 可选 owner 注册、应用接入、审批与新鲜共识 · sign/verify 公共门面、显式文件输入、多签读取与实体原件恢复 |
-| [Ownership 2.1 开发与移植指南](Ownership2.1-SDK开发与移植指南.md) | 四端统一签验核心、多签 HTTP 表示与实体指纹绑定 · 文件/证书/Storage当前原件 · owner.md 同会话上传与 expected_version 发布 CAS · 任务CAS · 按协议逐项裁决 |
-| [凭证与组织服务 SDK 应用集成指南](凭证与组织服务SDK应用集成指南.md) | 0.5.19 应用接入：CAP 验证、登记回执、成员入组/续期、组织请求、实体主签与 owner 上传、转让恢复 |
-| [凭证与组织服务 SDK 开发与移植指南](凭证与组织服务SDK开发与移植指南.md) | 0.5.19 四端协议实现：canonical JSON、签名/状态 proof、binding、facade/RPC、实体多签与原件恢复、测试向量 |
+| [Ownership 协议定义 2.1](../protocol/Ownership协议定义2.1.md) | 关系仅由agent.md/owner.md 确认 · release 保持 v、清理后 0／重绑默认 1 · Header 结果投影 · Group/Org 专属生命周期、实体主签与 owner token 上传 · owner完整原文/存在性再读 · 隔离的旧 SDK owner RPC/Auth JSONL · 无Storage路径历史 |
+| [Ownership SDK 编排指南 2.1](Ownership-SDK编排指南2.1.md) | 七 Facade、sub-first Stage／owner-first 直接提交、原件 CAS 冲突分类与恢复 · 无参数 reset、绑定容错和 0.5.19 及更早任务兼容 · Group/Org not_applicable 门禁 |
+| [Ownership 2.1 应用集成指南](Ownership2.1-SDK应用集成指南.md) | 应用侧 TS 接线与审批；sub-first／owner-first 绑定、释放、三方转移和重连恢复流程图，任务与当前共识分开判断 |
+| [Ownership 2.1 开发与移植指南](Ownership2.1-SDK开发与移植指南.md) | SDK 内部 TS 接口；严格文件签验、NS fresh 共识、Storage 同会话发布、收件持久化和原 CAS 恢复流程图 |
+| [凭证与组织服务 SDK 应用集成指南](凭证与组织服务SDK应用集成指南.md) | TS 示例与凭证登记／验证、成员申请／邀请、续期、撤销同步和组织 rekey／finalize 转让流程图 |
+| [凭证与组织服务 SDK 开发与移植指南](凭证与组织服务SDK开发与移植指南.md) | TS 内部示例与 Verify、双层请求摘要、登记最终化、撤销快照和实体 checkpoint 流程图；跨语言契约与验收 |
 | [凭证服务 RPC 手册](09-凭证服务RPC手册.md) | Credential Service 实际注册的 health/status/register/revoke/revocationList RPC |
 | [组织服务 RPC 手册](09-组织服务RPC手册.md) | Org Service 生命周期、成员、凭证查询、审计/授权及内部/未实现方法 |
-| [Ownership 2.1 详细设计](Ownership2.1详细设计.md) | 当前双文件关系、agent.md 兼容非回归矩阵、旧 SDK owner RPC/JSONL 隔离、本地失败稿／显式重试、本地任务与原 CAS |
-| [Ownership 2.1 TDD 实施计划](Ownership2.1-TDD分阶段实施计划.md) | 当前实施计划、历史冻结契约与网络账本、2026-10-13 复查修复边界 |
-| [Ownership 2.1 审查报告](../audit/Ownership2.1代码审查报告.md) | 历史复审；2026-10-15 旧 SDK wire 隔离兼容、owner 可选、四端会话/CAS、Storage 持久化和当前验证限制 |
-| [05-E2EE加密通信](05-E2EE加密通信.md) | E2EE V2 消息 · ProtectedHeaders · agent.md 版本提示 · recipient wrap |
+| [Ownership 2.1 详细设计](Ownership2.1详细设计.md) | agent.md/owner.md 关系、agent.md 兼容非回归矩阵、旧 SDK owner RPC/JSONL 隔离、本地失败稿／显式重试、本地任务与原 CAS |
+| [Ownership 2.1 TDD 实施计划](Ownership2.1-TDD分阶段实施计划.md) | 历史分阶段计划、冻结契约与网络账本、2026-10-13 复查修复边界 |
+| [Ownership 2.1 审查报告](../audit/Ownership2.1代码审查报告.md) | 第二十二节：恢复 agent.md/owner.md 与原控制格式、reset 及历史兼容；第十六至二十一节保留已撤销方案的历史验证边界 |
+| [05-E2EE加密通信](05-E2EE加密通信.md) | E2EE V2 消息 · ProtectedHeaders · need_render 外层提示 · agent.md 版本提示 · 旧 SPK 保留边界 |
 | [ProtectedHeaders用法专题](ProtectedHeaders用法专题.md) | `protected_headers` 四端 API · 实例级/单次调用 · E2EE V2 HMAC 完整性 · 接收信任边界 |
 | [E2EE_V2消息通信时序图](E2EE_V2消息通信时序图.md) | V2 P2P/GROUP 明文与加密主链路 |
-| [06-API手册](06-API手册.md) | AIDStore · AID · AUNClient · 四 SDK access token getter · Python PushFacade · P2P TTL volatile 消息 · Message/Group History 与已读门面 · 已读变更和本地补偿完成 · 消息来源与 Pull 同步生命周期 · 事件 · E2EE 高级 API · RPC 索引 |
+| [06-API手册](06-API手册.md) | AIDStore · resolve 完整输入输出/frontmatter/ownership 与 owner.md 缓存 · AID · AUNClient · 四 SDK access token getter · Python PushFacade · P2P TTL volatile 消息 · Message/Group History 与已读门面 · 已读变更和本地补偿完成 · 消息来源与 Pull 同步生命周期 · 三类批量事件/完整 single fallback · SDK 50k 内存去重/应用持久幂等 · E2EE 高级 API · RPC 索引 |
 | [07-错误处理](07-错误处理.md) | Result · Python `ErrorInfo.cause` · 错误类层级 · 错误码 · 重试 |
 | [08-最佳实践](08-最佳实践.md) | 幂等连接 · 消息同步/History · AUNClient 级 Pull Gate（同 namespace 单飞、客户端最多 4 个并行）· group.index · 测试数据保护 |
 | [09-payload-reference](09-payload-reference.md) | message / group / thought payload 格式 |
-| [09-message-rpc-manual](09-message-rpc-manual.md) | P2P 消息 RPC（含跨设备 `read/read_state/read_changed`、设备映射、精确整数、device 定向发送、TTL volatile 消息、双游标/ACK、Forward Pull、`message.history`、Piggy ACK、实时推送内联载荷） |
-| [09-group-rpc-manual](09-group-rpc-manual.md) | 群组 RPC（自动 owner 绑定/解绑、owner 本人名片、强制 rekey 的两阶段转移、跨设备已读、成员 block/status、Group Forward/History/index、Group FS） |
-| [09-storage-rpc-manual](09-storage-rpc-manual.md) | 存储 RPC（含实际字节 MIME 识别、session/PUT/complete Content-Type 一致性、OSS 403、POSIX VFS / ACL / token） |
+| [09-message-rpc-manual](09-message-rpc-manual.md) | P2P 共享 seq/peer 游标 · 轻量 pending peers/可选整体估计快照 · 目录A近似/Pull精确next_pending_seq/缺hint安全A/每N次FIFO · Pull 页内渲染计数 · 200 条 Pull/History · 稀疏覆盖/前驱 · peer ACK/公共 S/历史基线 · SDK 50k 内存去重/应用持久幂等/三类batch · 跨设备已读 · TTL volatile |
+| [09-group-rpc-manual](09-group-rpc-manual.md) | 群组 RPC（need_render · 原 Pull/ACK 模型 · 自动 owner 绑定/解绑、owner 本人名片、强制 rekey 的两阶段转移、跨设备已读、成员 block/status、Group Forward/History/index、Group FS 默认读缓存与条件票据） |
+| [09-storage-rpc-manual](09-storage-rpc-manual.md) | 存储 RPC（含 MIME／上传会话、POSIX VFS、60 秒 inline 缓存、SHA 条件读取、无正文免计次与删除 CAS） |
 | [09-collab-rpc-manual](09-collab-rpc-manual.md) | 协作 RPC（版本化文档 / 乐观锁 / 三方合并 / 标签 / GC / reflog / revert） |
 | [group.fs POSIX 化详细设计](../aun-fs/group-fs/group.fs-POSIX化详细设计.md) | `client.group.fs.*` / `aun group fs` / `group.fs.*` 群文件系统设计，含群自有区角色 ACL、`parents` 和 JS string 语义 |
 | [group.fs POSIX 化分阶段实施计划](../aun-fs/group-fs/group.fs-POSIX化分阶段实施计划.md) | group.fs 重构的 IPO、Step-by-step、用例集、Checklist、验收和回滚 |
@@ -52,17 +56,28 @@
 
 ## Layer 2：概念交叉索引
 
+### 0.5.21 接入与移植
+
+- 应用身份与连接、消息持久化及 UI、resolve、Ownership、凭证组织、诊断和升级 → [应用集成指南](0.5.21-SDK应用集成指南.md)
+- 新语言 SDK 分层、peer/batch 提交、缓存与原件恢复、持久化、语言差异和验收 → [开发与移植指南](0.5.21-SDK开发与移植指南.md)
+
+### 0.5.22 接入与移植
+
+- 应用身份与连接、消息订阅、两种绑定与审批恢复、resolve、60 秒读缓存与刷新、撤销同步及完整成员包 → [0.5.22 SDK 应用集成指南](0.5.22-SDK应用集成指南.md)
+- 后台退避、群状态、NS fresh 共识、sub-first Stage／owner-first 直接提交与原 CAS、消息内部消费、撤销同步、组织恢复及配套服务修复、默认读缓存与 Rust 移植 → [0.5.22 SDK 开发与移植指南](0.5.22-SDK开发与移植指南.md)
+
 ### 身份与认证
 
-- 当前普通 Ownership 2.1 双文件关系、release 保持 v／清理后 0／重绑默认 1、Header 结果投影、旧 SDK owner 隔离兼容、七 Facade 与任务恢复、Group/Org not_applicable → [编排指南 2.1](Ownership-SDK编排指南2.1.md)、[协议 2.1](../protocol/Ownership协议定义2.1.md)
+- 当前普通 Ownership 2.1 双文件关系、sub-first Stage／owner-first 直接提交、fresh 无锁预检、三类 CAS 冲突恢复、release／清理／重绑与 legacy 边界 → [编排指南 2.1](Ownership-SDK编排指南2.1.md)、[协议 2.1](../protocol/Ownership协议定义2.1.md)
 - 通用 Store raw/document 多签、Group/Org 实体主签、owner token 上传及可选附签、代际与原 CAS pending → [协议 §2.5](../protocol/Ownership协议定义2.1.md#25-grouporg-名片的实体主签与-owner-上传)、[Group RPC](09-group-rpc-manual.md#群组生命周期)
-- Credential/Org 应用接入、CAP 完整验证、登记回执、成员入组/续期、代表请求和转让恢复 → [凭证与组织服务 SDK 应用集成指南](凭证与组织服务SDK应用集成指南.md)
-- Credential/Org 四端协议实现、canonical JSON、强状态 proof、请求绑定、facade/RPC 和共同向量 → [凭证与组织服务 SDK 开发与移植指南](凭证与组织服务SDK开发与移植指南.md)
+- TS 示例与凭证登记／验证、成员申请／邀请、续期、撤销同步和组织 rekey／finalize 转让流程图 → [应用集成指南](凭证与组织服务SDK应用集成指南.md)
+- TS 内部示例与 Verify、双层请求摘要、登记最终化、撤销快照和实体 checkpoint 流程图；跨语言契约与验收 → [开发与移植指南](凭证与组织服务SDK开发与移植指南.md)
 - Credential Service 实际 RPC 与签名状态 proof/吊销列表 → [凭证服务 RPC 手册](09-凭证服务RPC手册.md)
 - Org Service 生命周期、成员关系、受保护查询、内部接口和未实现占位 → [组织服务 RPC 手册](09-组织服务RPC手册.md)
 
 - AID 格式、证书、不可变值对象 → [03-核心概念](03-核心概念.md)
 - `AIDStore.register()` / `load()` / `exists()` / `resolve()` → [04-连接与认证](04-连接与认证.md)、[06-API手册](06-API手册.md)
+- resolve opts、完整 frontmatter 字段/类型、按需 ownership 共识及 owner.md 缓存 → [resolve 输入与输出](06-API手册.md#resolve-输入与输出)
 - 旧 SDK owner 注册、绑定、转移、查询和解绑 RPC/Auth JSONL 隔离兼容 → [当前协议兼容边界](../protocol/Ownership协议定义2.1.md)；legacy 四端 `bindAid`/`bindOwner`、proof/escrow、代签代上传及 rekey 记录 → [Ownership管理专题（legacy）](Ownership管理专题.md)
 - legacy TypeScript 应用层 ownership 快速集成、审批、查询和 SDK 自动编排流程图 → [Ownership SDK集成指南（legacy）](Ownership-SDK集成指南.md)
 - legacy ownership SDK 实现/移植、声明字节与验签、escrow、metadata 持久化和恢复 → [Ownership SDK实现指南（legacy）](Ownership-SDK实现指南.md)
@@ -77,15 +92,15 @@
 - 九态状态机、device_id / slot_id 隔离键 → [03-核心概念](03-核心概念.md)
 - `connect()` 选项、长短连接、网关发现 → [04-连接与认证](04-连接与认证.md)
 - capability getter、事件、生命周期 API → [06-API手册](06-API手册.md)
-- 消息事件 `source`、`sync.started/progress/stopped`、`delivery.changed` → [06-API手册](06-API手册.md)
+- 消息事件 `source`、`sync.started/progress/stopped`、`delivery.changed` 及 `message.peers_snapshot` 的对端水位/可选整体积压估计 → [06-API手册](06-API手册.md)、[Message RPC](09-message-rpc-manual.md#messagepeers_snapshot)
 - 已读状态重连补偿、本地 `read_state_sync` 的 states/errors 和 `background_sync` 边界 → [04-连接与认证](04-连接与认证.md)、[06-API手册](06-API手册.md)
-- Capabilities 能力声明、`inline_realtime_payload_v1` 实时推送优化 → [02-WebSocket协议](02-WebSocket协议.md)、[CHANGELOG-0.5.6](CHANGELOG-0.5.6.md)
+- 严格布尔 `p2p_peer_pull_v1` 能力、连接上下文与上线提示、`inline_realtime_payload_v1` 实时推送优化 → [02-WebSocket协议](02-WebSocket协议.md)
 - 裸 WebSocket 握手 → [02-WebSocket协议](02-WebSocket协议.md)
 
 ### E2EE
 
 - E2EE 原理和默认行为 → [03-核心概念](03-核心概念.md)
-- ProtectedHeaders、agent.md 版本提示边界、V2 recipient wrap、sender_signature / AAD / recipient proof → [05-E2EE加密通信](05-E2EE加密通信.md)
+- ProtectedHeaders、need_render 不进 AAD/元数据保护但保留 RPC 签名、V2 recipient wrap、旧 SPK 安全证明边界 → [05-E2EE加密通信](05-E2EE加密通信.md)
 - `protected_headers` 用法、四端 API、合并优先级、key/value 规范化、HMAC 和信任边界 → [ProtectedHeaders用法专题](ProtectedHeaders用法专题.md)
 - V2 P2P/GROUP 时序 → [E2EE_V2消息通信时序图](E2EE_V2消息通信时序图.md)
 - 高级 E2EE API → [06-API手册](06-API手册.md)
@@ -96,13 +111,14 @@
 - `client.call()` / `client.on()` → [04-连接与认证](04-连接与认证.md)、[06-API手册](06-API手册.md)
 - Python `connect()` 携带 `push_notify_aid/push_token` 自动登记，以及 `client.push.register/unregister` 运行期变更 → [04-连接与认证](04-连接与认证.md)、[06-API手册](06-API手册.md)、`docs/protocol/15-离线推送通知协议.md`
 - `client.notify()` 在线轻量通知、跨域 federation、在线/离线边界 → [Notify通知方案](Notify通知方案.md)
-- A/T/H 实时窗口、页内唯一有序发布、应用层跨页幂等排序、每个 AUNClient 一个 Pull Gate（同 namespace 单飞、不同 namespace 最多 4 个并行、相同 key 折叠、可运行项前台 FIFO 优先）、缺 sender IK 有界同步 bootstrap、永久页内 Gap、坏密文推进 → [03-核心概念](03-核心概念.md)、[05-E2EE加密通信](05-E2EE加密通信.md)、[08-最佳实践](08-最佳实践.md)
-- P2P device 定向发送、TTL volatile 消息、双游标/ACK、Forward/History/Piggy ACK → [09-message-rpc-manual](09-message-rpc-manual.md)
+- peer A/T/H、稀疏覆盖与 prev_peer_seq、human Tail→Forward、50k 内存去重 与应用幂等、N=4 Gate、后台工作片续拉、缺 sender IK 有界 bootstrap；Group 保持原终态规则 → [03-核心概念](03-核心概念.md)、[05-E2EE加密通信](05-E2EE加密通信.md)、[08-最佳实践](08-最佳实践.md)
+- P2P 完整轻量 pending peers、Pull逐页next_pending_seq/可靠commit后更新/连续提示段与每N次FIFO、原应用列表顺序、按 sender/全部对端 Pull、页内渲染计数、可选整体积压估计、冻结旧 ACK 基线、peer ACK/公共 S、TTL volatile、单 Message 实例范围 → [09-message-rpc-manual](09-message-rpc-manual.md)
 - 跨设备 `read/read_state/read_changed`、单条/显式空值、回执与汇总、scope/owner 绑定、晚到位置回填、Group canonical/权限版本及混合域部分提交 → [09-message-rpc-manual](09-message-rpc-manual.md)、[09-group-rpc-manual](09-group-rpc-manual.md)
 - Group 成员 block/status、暂停群权限、两阶段群主转让、Forward/History、`group.index`、Group FS MIME/Content-Type 和角色 ACL → [09-group-rpc-manual](09-group-rpc-manual.md)
 - 下一版群文件系统 `group.fs.*`、`client.group.fs.*`、`aun group fs`、`cp/mv` POSIX 化语义和 JS string 差异 → [group.fs POSIX 化详细设计](../aun-fs/group-fs/group.fs-POSIX化详细设计.md)、[分阶段实施计划](../aun-fs/group-fs/group.fs-POSIX化分阶段实施计划.md)
 - Storage 架构、SDK VFS、控制面/数据面分离、下载 ticket / AID Bearer 边界、类 Linux 权限和 mount/symlink → [AUN Storage架构设计](<../aun-fs/AUN Storage架构设计.md>)
 - Storage RPC、实际字节 MIME 识别、三阶段 Content-Type 一致性与 OSS 403、`storage.fs.*` / ACL / token、`relation_backup_*` → [09-storage-rpc-manual](09-storage-rpc-manual.md)、[../protocol/11-Storage-子协议.md](../protocol/11-Storage-子协议.md)
+- Storage / Group FS 默认读缓存、60 秒总新鲜度、if_sha256/not_modified、SHA 条件验证与本地命中不计次、持久后端/失效、`noCache` 与 `owner.md` 权威读取 → [缓存策略](09-storage-rpc-manual.md#sdk-默认读缓存)、[API 选项](06-API手册.md#默认读缓存与单次刷新)
 - Collab RPC（`collab.*` 版本化文档、乐观锁、标签、GC、reflog、revert）→ [09-collab-rpc-manual](09-collab-rpc-manual.md)
 - Meta RPC → [09-meta-rpc-manual](09-meta-rpc-manual.md)
 - Stream RPC → [09-stream-rpc-manual](09-stream-rpc-manual.md)
@@ -120,6 +136,22 @@
 
 ## Layer 3：文档摘要
 
+### 0.5.21 SDK 应用集成指南
+
+按应用接入顺序说明当前 0.5.21 的身份、批量入库、peer 同步、已读与 UI、frontmatter/owner 展示、关系审批/reset、凭证组织恢复、诊断和升级。TypeScript 示例区分 Node 与浏览器，明确展示缓存、业务授权和持久幂等的边界。
+
+### 0.5.21 SDK 开发与移植指南
+
+按 SDK 实现职责整理 peer 能力/水位、共享 Gate 与背压、batch/handler/水位/ACK 时序、运行时去重、resolve 元数据与共识缓存、普通名片非回归、Ownership 原 CAS 和历史任务、续期撤销、加密 checkpoint、诊断证书、四端差异及测试矩阵。
+
+### 0.5.22 SDK 应用集成指南
+
+TypeScript 身份与消息接线、Ownership 审批恢复、resolve、默认缓存与刷新、撤销同步、完整成员包及升级验收。
+
+### 0.5.22 SDK 开发与移植指南
+
+定义后台退避、群状态、Ownership Stage／CAS、内部消费、撤销与续期、缓存后端及失效契约；列出服务依赖、语言修复、Rust 定位和验收入口。
+
 ### CHANGELOG-0.5.6
 
 以 0.5.5 发布提交为基线，汇总四个 SDK 的首次签名者证书回源、`group.index` / indexed settings / `agent.md` 下载提交前校验、可信缓存读取、消息窗口、inline realtime、mention mode、显式 change-seed，以及 Python、Go、TS 和浏览器 JS 的能力边界。
@@ -134,23 +166,25 @@
 
 ### 03-核心概念
 
-解释 AID 身份、三主体职责、device_id / slot_id 隔离键、A/T/H 实时消息窗口、每个 AUNClient 一个 Pull Gate、九态状态机、默认 E2EE 行为和 RPC/事件模型。
+解释 AID 身份、三主体职责、device_id / slot_id 隔离键、共享 seq 下的 peer A/T/H 与覆盖证明、human Tail 策略、N=4 Pull Gate 与 page_size×N 共享队列、后台工作片续拉、50k 内存去重、自定义 store/多 client 边界和应用幂等、九态状态机及默认 E2EE 行为。
 
 ### 04-连接与认证
 
-描述 `AIDStore` 注册加载、自有身份 resolve 本地草稿/缓存优先、`AUNClient` 身份加载、显式认证、当前 access token getter、连接选项、Python `connect()` 的 Push 自动登记、长短连接共存、网关发现、已读状态本地补偿完成事件、agent.md 上传/下载/检查，以及连接后从 Gateway `_meta.agent_md_etags` 和信封 `agent_md` 自动观察远端版本。
+描述 `AIDStore` 注册加载、自有身份 resolve 本地草稿/缓存优先、frontmatter 类型保留及按需 ownership 共识/owner.md 缓存、`AUNClient` 身份加载、显式认证、当前 access token getter、连接选项、Python `connect()` 的 Push 自动登记、长短连接共存、网关发现、已读状态本地补偿完成事件、agent.md 上传/下载/检查，以及连接后从 Gateway `_meta.agent_md_etags` 和信封 `agent_md` 自动观察远端版本。
 
 ### Ownership 2.1 当前契约与复审
 
-当前普通 Ownership 关系仅由 NS 当前 `agent.md` 与 owner Storage 当前 `owner.md` 确认，owner 锁与响应 Header 只投影本次校验结果；release 保持被释放的版本 v，sub 清理后版本投影为 0、再次绑定默认 1。普通 agent 注册 owner 可选。新服务端保留旧 SDK owner 注册、绑定、转移、查询和解绑 RPC 及隔离 Auth JSONL，仅激活旧 NS ownership_proof，不写 2.1 双文件，不授 2.1 lock/version/consensus，不覆盖已存现代声明。owner.md 通过 create_upload_session→HTTP PUT→complete_upload 的同一会话发布，既有 expected_version 作发布 CAS；object_id/version 不作为读取一致性或共识条件。六份协议/SDK 文档还定义七 Facade 与实体专属 owner 名片；实体 pending 保留完整多签原文、固定 owner/实体代际与原 CAS，由应用显式重试，不再要求额外 V2 上传授权。无控制消息的释放清理按精确本人历史同意恢复，保持 completed 历史；当前证书严格绑定 OCSP issuer，整体 30 秒包含首次 GET。各端差异按协议逐项裁决，TS 是接线参考；历轮修复与更正保留在审查报告第十二、十三节，2026-10-15 的旧 wire、可选注册、会话/版本、Storage 持久化、Auth 撤权和当前验证见 [审查报告第十五节](../audit/Ownership2.1代码审查报告.md#十五2026-10-15-追加审查兼容裁决与修复验收)。
+当前普通 Ownership 关系仅由 NS 当前 `agent.md` 与 owner Storage 当前 `owner.md` 确认，声明和控制消息沿用 0.5.20；owner 锁与 Header 投影本次校验结果。普通 agent 注册 owner 可选；sub-first 先 Stage、owner-first 先发布 owner.md 后由 sub 直接提交，发起前 fresh 确认无锁；普通正文更新保留全部关系材料、本人签名和原 ETag/CAS，不以前置共识或 owner Storage 为条件。release 保持 v，清理后投影 0／再次绑定默认 1；owner.md 仍通过同一上传会话及 expected_version 条件发布，当前完整原文和存在性用于读取核验。本地 revision／NS 412／Storage -32009 冲突分类、原 operation 恢复、历史任务与 reset 见编排第 8 节和开发移植 §10.3；更早 proof 与旧 owner RPC 保持原隔离边界。当前更正见 [第二十二节](../audit/Ownership2.1代码审查报告.md#二十二2026-10-18-恢复发布格式与历史兼容更正)，阶段计数不能代替恢复后专项及真实旧发布包联网验收。
+
+绑定恢复、reset 和历史任务的当前要求以[第二十二节](../audit/Ownership2.1代码审查报告.md#二十二2026-10-18-恢复发布格式与历史兼容更正)及[编排第 8 节](Ownership-SDK编排指南2.1.md#8-崩溃与响应丢失后的恢复)为准；历史第十九至二十一节仅保留阶段实施记录。
 
 ### 凭证与组织服务 SDK 应用集成指南
 
-面向应用开发者说明 0.5.19 的 Credential/Org service-plane 边界、CAP 完整 Verify、Credential 请求绑定、受保护读取、首次入组 admission、组织创建与两阶段转让恢复、解散证书失效清理；列出四端实际入口及状态未知和 `NOT_IMPLEMENTED` 的 fail-closed 边界。
+以短 TS 示例和流程图说明凭证登记／验证、成员申请／邀请、续期、代表调用、撤销同步和组织转让；保留 service-plane、当前状态与显式恢复边界。
 
 ### 凭证与组织服务 SDK 开发与移植指南
 
-面向其它语言 SDK 开发者冻结两类 canonical JSON、P-256/DER 签名、CAP 深度和安全声明、父链强状态 proof、Org admission 与 Credential 请求绑定、四端 facade/RPC、创建/转让 checkpoint、解散清理、事件去重和共享测试向量。
+以 TS 内部片段和流程图说明共同签验、完整 Verify、两层请求摘要、登记最终化、撤销持久快照及实体 checkpoint；列出四端差异、服务契约和有序验收。
 
 ### 凭证服务 RPC 手册
 
@@ -180,7 +214,7 @@
 
 ### 05-E2EE加密通信
 
-覆盖默认加密发送、接收自动解密、E2EE V2 多设备 wrap、ProtectedHeaders、agent.md 版本提示与 E2EE 安全边界、`sender_signature` / AAD / recipient proof、群 E2EE 和高级存储扩展边界。
+覆盖默认加密发送、接收自动解密、E2EE V2 多设备 wrap、ProtectedHeaders、need_render 外层提示与 RPC 签名边界、agent.md 版本提示、`sender_signature` / AAD / recipient proof、peer/slot ACK 不作为设备旧 SPK 销毁证明、群 E2EE 和高级存储扩展边界。
 
 ### ProtectedHeaders用法专题
 
@@ -188,7 +222,7 @@
 
 ### 06-API手册
 
-列出 AIDStore（含四端可选附签入口）、AID、AUNClient（含四 SDK 当前 access token getter）、Ownership 2.1 七 Facade、Credential/Org 专题入口、Python PushFacade、P2P TTL volatile 消息、Message/Group History 与已读门面、已读变更及本地补偿完成事件、agent.md、ServiceProxyClient、E2EE 高级 API、Group Index facade 和 RPC 手册索引。
+列出 AIDStore、resolve 的四语言 opts/输入输出、frontmatter 标准与扩展字段、ownership 七种共识状态及 owner.md 快照/TTL/失败语义、AID、AUNClient、Ownership 2.1 与 Credential/Org 入口、Python PushFacade、P2P peer/全部对端 Pull、轻量 pending 快照与可选整体估计/Pull 页内渲染计数、50k 内存去重 和应用幂等、Message/Group History 与已读门面、生命周期事件、agent.md、ServiceProxyClient、E2EE 和 Group Index facade。
 
 ### 07-错误处理
 
@@ -196,7 +230,7 @@
 
 ### 08-最佳实践
 
-给出幂等加载身份、连接、关闭、多 AID 管理、Flow Control、A/T/H 实时同步、History 翻页、Piggy ACK、Group Index 更新和测试数据保护建议；每个 AUNClient 的 Pull Gate 同 namespace 单飞、客户端最多 4 个不同 namespace 并行；末页独立 ACK，不为提交 ACK 额外 Pull。
+给出幂等加载身份、连接、关闭、多 AID 管理、Flow Control、peer A/T/H 与 human Tail 策略、History 翻页、50k 内存去重与应用持久幂等、后台超过100页续调度、Piggy ACK 和 Group Index 更新；每个 AUNClient 的网络 Pull Gate 同 namespace 单飞、最多4个不同 namespace 并行。
 
 ### 09-*-rpc-manual
 

package/_packed_docs/sdk/Ownership-SDK/347/274/226/346/216/222/346/214/207/345/215/2272.1.md

@@ -2,6 +2,8 @@
 
 本文说明 [Ownership 协议定义 2.1](../protocol/Ownership协议定义2.1.md) 的应用层调用、SDK 审批与 P2P 编排、文件提交、NS 验收条件和中断恢复。方法、消息和事件构成 SDK 2.1 契约；当前工作区的实现与验收状态见 [实施账本第 13 节](Ownership2.1-TDD分阶段实施计划.md#13-2026-10-10-实施账本)。本轮实现不表示已经发布。
 
+普通 `agent.md` 的基础读取、验签、上传与显式 pending 恢复不以前置 Ownership 共识、owner Storage 或关系状态为条件。普通正文更新须原样保留当前原件中全部关系材料的字段存在性、类型和值，并遵守本人签名和原 ETag/CAS；材料无效或依赖不可用不能阻断这种更新。增删改关系字段继续执行当前双文件授权核验，不能借普通名片入口清除或替换 owner 锁。
+
 协议允许各方独立、乱序提交自己的文件，NS 最终验收 sub 自签的完整 agent.md。Ownership 是可选关系属性；关系失效或不可确认只降级 owner 授权、共识与关系操作，普通名片读取、历史验签、展示和通信继续可用。关系事实仅为数据库当前 agent.md 与 owner Storage 当前 owner.md；事务/CAS 只保护 agent.md 原子更新。SDK 保存本地审批、原件及重试进度，它们不是第三份关系事实。
 
 ## 1. 参与方与顺序
@@ -24,17 +26,17 @@
 
 self-owner 表示 `owner_aid == sub_aid`，同一 AID 承担两个角色，可以由同一 SDK 实例分别写自己的两个文件；NS 仍按统一规则验收并投影当前关系，见第 10 节。
 
-协议不要求跨方提交顺序。本文主要流程图展示第 2.4 节的 SDK 默认编排：先完成业务审批，再依次发布所需声明、由 sub 提交，最后新鲜确认 NS 结果；各端步骤独立持久化和恢复。协议层文件操作仍允许乱序执行，NS 只在验收时检查当前材料；章节编号用于定位文件规格。
+本文按发起方区分绑定：sub-first 先 Stage 保存 sub 已同意的原件，owner 同意后发布声明并触发验收；owner-first 先条件发布 owner 已同意的原件，sub 固定本轮提案完整原文及 SHA 后审批，同意后直接条件提交，不使用 Stage。转移仍先收齐审批，再发布所需声明。各端步骤独立持久化和恢复，NS 只在验收时检查当前材料；已持久历史在途任务保留原流程、原件与 CAS，不因缺少后来新增的提案字段强制切换。章节编号用于定位文件规格。
 
 | 场景 | NS 最后检查的验收条件 |
 | --- | --- |
-| 建立关系 | 当前无锁；sub 本次提交与 owner Storage 当前声明的 AID、签名和目标版本匹配，ETag 条件满足。 |
+| 建立关系 | 当前无锁；sub 当前完整候选与 owner Storage 本轮声明的 AID、签名和目标版本匹配，ETag 条件满足；已暂存候选可由 fresh 验收。 |
 | 转移 | 原关系受锁保护；三方材料齐全、签名有效，原 owner 指定的新 owner、目标版本、期限和 ETag 条件均匹配。 |
 | release 解绑 | 原 owner 当前 release 签名有效，指向受保护的关系版本；sub 的文件另按本方身份和 ETag 验收。 |
 | 直接删除解绑 | owner Storage 权威确认规范路径当前不存在；sub 的文件另按本方身份和 ETag 验收。 |
-| 旧文件清理 | 新鲜核验当前 release/删除或已提交转移，核对当前 NS 与本任务完整 owner 原件后删除；已观察到后续文件时停止。 |
+| 旧文件清理 | 新鲜核验当前 release/删除或已提交转移，核对当前 NS 与本任务完整 owner 原件后，以最后读取到的当前对象 `version` 作为 `expected_version` 原子删除；版本冲突停止清理，不追随新版本重试。 |
 
-材料不齐时不提交绑定或转移。release/权威删除按两份当前材料动态判定，不另写释放终局、不改 sub 签名字节或递增版本。NS 不维护跨方审批任务；各方只签传自己的文件，SDK P2P 载荷不构成关系授权。
+材料不齐时不确认绑定或转移；未锁绑定允许 sub 用 Stage 条件暂存已签原件，NS 返回 pending/unlocked，公共共识为 single_sided，不授 owner 权限。NS 以与当前名片 CAS 绑定的 ownership_pending 保存精确候选标记，不保存跨方审批决定或 SDK 任务。release/权威删除按两份当前材料动态判定，不另写释放终局、不改 sub 签名字节或递增版本。各方只签传自己的文件，SDK P2P 载荷不构成关系授权。Stage／Status 与 fresh 验收要求见 [协议 §3.3](../protocol/Ownership协议定义2.1.md#33-读取并发与接口)。
 
 ## 2. SDK 分层与完成判断
 
@@ -52,7 +54,7 @@ SDK 的协议文件层对应协议定义的文件签署、发布和提交操作
 
 共识检查先获取 NS 新鲜结果及权威 `agent.md`，读取 owner Storage 当前文件并验签，再核对 NS 当前版本、完整原文、ETag 和锁；材料变化返回可重试的 `unavailable`，不能返回 `consensus`。总窗口为 30 秒，从首次 NS GET 发出前开始，首读、证书/Storage 验证和末读均计入；超时同样为 `unavailable`。结果定义见协议第 6 节。
 
-应用区分文件已保存、NS 已确认变更、清理已完成；owner 文件发布成功不等于绑定或转移完成。
+应用区分文件已保存、NS 已确认变更、清理已完成；owner 文件发布成功不等于绑定或转移完成。内部文件发布方法只确认 Storage 保存，编排随后在通知发送前核查及完成确认等推进步骤请求 NS 新鲜检查；失败保留恢复待办。App 展示查询不构成建锁的前置条件，锁始终由当前双文件及实际读写验收判定。
 
 名片读写复用 `GET/HEAD/PUT /agent.md`；新 SDK 新鲜检查携带 `X-AUN-Ownership-Check: 1`，提交条件见第 2.1 节。Header 只选择新鲜检查与结果投影，不作为关系事实或旧客户端读取的门槛；NS 按文件格式和已存材料执行上传校验，缺头不得绕过保护。新鲜检查的 NS 响应包含：
 
@@ -76,11 +78,11 @@ NS 原 ETag 条件冲突或当前 owner 文件与保存的起始原件不符时
 
 普通名片显式上传先新鲜读取可靠 NS 结果，再将完整签名字节、原条件及原关系上下文（owner、完整 statement、relation_version、lock）持久保存后提交；不存在只接受版本 0、unlocked 的可靠结果。普通失败稿仅本地保留，post-connect／重连不隐式 PUT；应用显式重试既有 pending 时先核验持久原条件，再读取远端：缺条件时保留原元数据和原错误，即使远端已有相同完整字节和 ETag，也不能自动清除待办或升级为首次创建。保留原 owner 和完整 statement 的普通正文更新可使用原关系上下文安全恢复；含 statement 却缺原上下文时返回 persistence_unavailable。核对原版本、锁、owner 和 statement 后，当前完整字节和 ETag 均匹配则仅确认，否则只在原条件仍成立时重传原签名字节；缺原上下文的旧待办仅允许版本 0、unlocked 的初始关系。后续文件或关系变化时停止旧写入，不刷新条件；实际绑定、转移、释放等关系变更仍由对应 Ownership 任务恢复。
 
-Group/Org 名片失败稿及 pending 保留实体命名空间中的完整多签原文、原 CAS、固定 owner 和实体证书指纹，由应用显式重试，post-connect／重连不隐式 PUT。重试先验证完整原件及当前 owner、状态和证书代际，原条件完整且同代际原文／ETag 已确认提交时只观察完成。转移、rekey 或解散后停止旧代际待办，不更换身份、指纹或条件重签。取消实体 V2 授权后，不再保存、刷新或检查其额外授权及过期窗口；普通文件签名与当前证书检查保留。专属 create/transfer 自身 checkpoint 恢复机制不变。
+Group/Org 名片失败稿及 pending 保留实体命名空间中的完整多签原文、原 CAS、固定 owner 和实体证书指纹，由应用显式重试，post-connect／重连不隐式 PUT。重试先验证完整原件及当前 owner、状态和证书代际，原条件完整且同代际原文／ETag 已确认提交时只观察完成。转移、rekey 或解散后停止旧代际待办，不更换身份、指纹或条件重签。新 SDK 现代上传不再保存、刷新或检查额外 V2 授权及过期窗口；普通文件签名与当前证书检查保留。服务端为旧0.5.19保留受限 owner 主签单块 V2 入口及原条件，历史读取例外与现代实体主签单/双签规则见协议 §2.5。专属 create/transfer 自身 checkpoint 恢复机制不变。
 
 创建响应丢失时重新读取当前完整 owner 文件：与本任务原件一致则仅确认，否则核对保存的起始存在性、原文及摘要；已观察到后续变化时停止旧任务。当前文件模型不提供删除重建或同内容回滚的 ABA 检测保证。
 
-起始证据统一保存 `base_agent_md={exists,raw,sha256,etag,statement|null}` 与 `base_owner_md={exists,raw,sha256}`。非空 statement 完整相同的普通正文更新不替代关系，尚未签署的本方候选使用新鲜读取的原 ETag；已持久保存的签名字节重试仍沿用其原 CAS，不刷新条件。起始无声明时完整 agent 原文变化则停止旧审批。owner 写前和清理前重读当前完整原文、摘要及存在性，不增加远端条件字段。 base_owner_md 对应 base_agent_md.statement 所指当前/最后 owner 的文件；无 statement 时没有当前 owner 事实，本地可省略或使用空标记；bind/transfer 目标 owner 写前原件在待发布文件中另存并复读，不替代原 owner 基线。
+起始证据统一保存 `base_agent_md={exists,raw,sha256,etag,statement|null}` 与 `base_owner_md={exists,raw,sha256}`。非空 statement 完整相同的普通正文更新不替代关系，尚未签署的本方候选使用新鲜读取的原 ETag；已持久保存的签名字节重试仍沿用其原 CAS，不刷新条件。起始无声明时完整 agent 原文变化则停止旧审批。owner 写前和清理前重读当前完整原文、摘要及存在性；发布沿用保存的原 Storage `expected_version`；删除先精确核对本任务原件，再以最后读取到的当前对象 `version` 作为 `expected_version`，该删除发生冲突即停止，不换新版本盲重试。 base_owner_md 对应 base_agent_md.statement 所指当前/最后 owner 的文件；无 statement 时没有当前 owner 事实，本地可省略或使用空标记；bind/transfer 目标 owner 写前原件在待发布文件中另存并复读，不替代原 owner 基线。
 
 ### 2.2 NS 双材料校验与提交
 
@@ -118,8 +120,8 @@ Ownership Facade 仅提供以下接口。应用调用编排接口发起操作，
 
 | Facade 方法 | 调用方 | 行为与完成依据 |
 | --- | --- | --- |
-| `bindOwneraid(owner_aid)` | sub | 请求 owner → owner 审批 → owner 发布声明 → sub 自签提交 → 确认 NS 验收；常规绑定入口。 |
-| `bindSubaid(sub_aid)` | owner | 请求 sub → sub 同意 → owner 发布声明 → sub 自签提交 → 确认 NS 验收。 |
+| `bindOwneraid(owner_aid)` | sub | fresh 确认无锁及 Stage 能力 → sub 保存并 Stage 条件发布原件 → 请求 owner → owner 同意并发布声明 → NS fresh 验收；sub 可离线。 |
+| `bindSubaid(sub_aid)` | owner | fresh 确认无锁 → owner 保存并条件发布 `owner.md` → 请求 sub → sub 同意后直接条件提交 `agent.md`（无 Stage）→ 确认 NS 锁定。 |
 | `acceptOwnershipRequest(operation_id)` | 绑定接收方；转移中的新 owner 或 sub | 持久保存本端同意决定，回复发起方；只在审批阶段完成、材料匹配后推进本端文件步骤。 |
 | `rejectOwnershipRequest(operation_id, reason?)` | 绑定接收方；转移中的新 owner 或 sub | 持久保存拒绝决定，通知发起方，结束本次待审批任务。 |
 | `releaseSubaid(sub_aid)` | 原 owner | 发布 release → 新鲜动态确认 → 通知 sub 自签清理 → 延迟条件清理旧 owner 文件；任务目标版本等于当前声明版本。 |
@@ -130,7 +132,7 @@ Ownership Facade 仅提供以下接口。应用调用编排接口发起操作，
 
 绑定、释放、转移的发起接口先查询权威现状以固定起始版本，在发送消息、发布文件或删除等副作用前持久保存本端任务，返回 `operation_id` 和本端进度；超时可返回等待结果，由事件继续通知。审批接口关联已有任务，不创建新任务。`operation_id` 为 SDK 生成的 UUIDv4，不写入 agent.md、owner.md 或额外 NS 关系事实。同一 sub_aid 的本端修改串行推进；恢复复用原任务及已签署文件。
 
-绑定可由 sub 或 owner 发起，发起 API 表达发起方意愿，接收方通过 `ownership.request` 同意或拒绝。转移仅由 NS 当前原 owner 发起；新 owner 和 sub 分别审批，原 owner 收齐两方同意后才发布转移授权。两方审批可任意先后；任一方拒绝，原 owner 通知另一方停止本次待审批任务，不发布授权，原关系保持。
+绑定可由 sub 或 owner 发起，只有 fresh 可靠确认当前无 owner 锁才可进入绑定；`invalid`、`unavailable` 或无法确认当前基线均不能当作无锁。已有锁时只能由当前 owner 发起解绑或转移。发起 API 表达发起方意愿，接收方通过 `ownership.request` 同意或拒绝。转移仅由 NS 当前原 owner 发起；新 owner 和 sub 分别审批，原 owner 收齐两方同意后才发布转移授权。两方审批可任意先后；任一方拒绝，原 owner 通知另一方停止本次待审批任务，不发布授权，原关系保持。
 
 三方意向共识只保存在各端 SDK 任务中，不写入协议文件或额外 NS 关系事实。sub 的同意还须落实为其自行签署、提交目标 agent.md；同意消息本身不能完成转移。
 
@@ -175,24 +177,24 @@ SDK 协调载荷使用独立标识 `aun.ownership.sdk.v1`，避免被现有 `aun
 | `owner_aid` | 必填完整小写 AID；绑定时为目标 owner，释放、转移时为原 owner。 |
 | `new_owner_aid` | transfer 必填完整小写 AID，其它操作省略。 |
 | `base_relation_version` | 当前 agent.md 声明版本；无声明为 0。必须同时固定原文、摘要及 CAS，不能只靠数字区分关系。 |
-| `target_relation_version` | bind/transfer 为 base+1，release 为 base；清理不另造版本，清理后无声明投影为 0。 |
+| `target_relation_version` | bind/transfer 为 base+1，新任务 release 为 base；兼容 0.5.19 release 的原 base+1 wire 值并保留原值，实际释放事实仍按 base。清理不另造版本，清理后无声明投影为 0。 |
 | `reason` | 拒绝或 operation.stopped 可选字符串，其它 action 省略。 |
 
 | action | operation 与发送方向 | 接收 SDK 推进什么 |
 | --- | --- | --- |
-| `bind.request` | bind：sub 或 owner → 绑定另一方。 | 保存待审批任务，发布 ownership.request；尚不写声明文件。 |
-| `bind.accept` | bind：绑定接收方 → 发起方。 | 关联原请求，记录同意决定；owner SDK 准备自己的声明，sub 等待 owner.ready。 |
-| `bind.reject` | bind：绑定接收方 → 发起方。 | 关联待审批请求，记录拒绝并结束本次 SDK 任务。 |
+| `bind.request` | bind：sub 或 owner → 绑定另一方。 | 保存待审批任务并回源核对后发布 ownership.request；sub 发起时已确认 Stage 原件，owner 发起时已确认发布本轮 owner 原件。 |
+| `bind.accept` | bind：绑定接收方 → 发起方。 | sub-first 可由 owner 通知 sub 已同意；owner-first 省略该往返，sub 同意后直接提交文件。历史任务仍按原上下文处理。 |
+| `bind.reject` | bind：绑定接收方 → 发起方。 | 记录拒绝，保留拒绝决定；sub 仅恢复本轮仍 pending 且原文／摘要／ETag 匹配的候选清理。 |
 | `transfer.request` | transfer：原 owner → 新 owner、sub。 | 回源确认发起方是当前原 owner，保存待审批任务，发布 ownership.request；尚不发布转移授权或目标文件。 |
 | `transfer.accept` | transfer：新 owner 或 sub → 原 owner。 | 分别记录审批；收齐两方同意并复核原关系后，才条件发布转移授权。 |
 | `transfer.reject` | transfer：新 owner 或 sub → 原 owner。 | 记录拒绝，结束本次待审批任务；以 operation.stopped 通知另一方，原关系保持。 |
-| `owner.ready` | bind：owner → sub；transfer：新 owner → sub。 | 回源核对已批准的目标、当前 owner 声明及相关授权；具备本端授权后提交自己的 agent.md。 |
+| `owner.ready` | sub-first bind：owner → sub；transfer：新 owner → sub。 | sub-first 核验已暂存原件和共识，不再次 PUT；owner-first 不需要此往返。transfer 与历史恢复仍按原材料及授权推进 sub 提交。 |
 | `transfer.ready` | transfer：原 owner → 新 owner、sub。 | 核对原 owner 当前签名授权及本端审批；新 owner 发布自己的声明，sub 保存目标并等待材料。 |
 | `relation.confirmed` | bind/transfer：sub → 其它参与方；release：原 owner → sub。 | 新鲜查询 NS；核对任务目标后更新本端结果，已释放的 sub 可清理旧字段。 |
-| `sub.cleaned` | release：sub → 原 owner。 | 核对本任务原 owner/sub/声明、已保存清理原件及原 CAS，再新鲜确认当前字段已清空和完整文件摘要；清理后版本为 0，通知不是释放证明。 |
+| `sub.cleaned` | release：sub → 原 owner。 | 按任务上下文新鲜核对当前完整关系文件、ETag 和摘要，可记录字段已清空、版本为 0 的观察；通知不证明本任务执行了清理或释放，首次完成仍须第 2.4 节的原件关联证据。 |
 | `operation.stopped` | 三种操作：参与方 → 其它参与方。 | 记录对端停止配合；本端仍按权威现状处理，不撤销声明或已提交关系。 |
 
-消息不承载关系授权，也不要求交换文件摘要；完整文件从 NS 和各方 Storage 的规范路径获取并验签。来源使用消息层确认的 `from_aid`，不能相信载荷自报身份。绑定回复必须来自本地原请求的接收方，转移审批回复必须来自指定的新 owner 或 sub，转移请求及授权通知必须来自 NS 当前原 owner。请求、审批回复及 ready 消息读取当前 NS 关系及声明，核对参与方、起始/目标版本、转移目标和期限，再决定下一步；转移授权尚未发布时不要求存在该授权。relation.confirmed 按目标结果核查，sub.cleaned 按当前完整文档及本任务保存的原声明、原件和原 CAS 核查；清理后的 unbound/0 不补造历史 released。
+消息不承载关系授权，也不要求交换文件摘要；完整文件从 NS 和各方 Storage 的规范路径获取并验签。来源使用消息层确认的 `from_aid`，不能相信载荷自报身份。绑定回复必须来自本地原请求的接收方，转移审批回复必须来自指定的新 owner 或 sub，转移请求及授权通知必须来自 NS 当前原 owner。请求、审批回复及 ready 消息读取当前 NS 关系及声明，核对参与方、起始/目标版本、转移目标和期限，再决定下一步；转移授权尚未发布时不要求存在该授权。relation.confirmed 按目标结果核查，sub.cleaned 触发当前完整关系文件的清理态核验；记录当前已清理与证明本任务提交清理须分开，后者还须原件、摘要和原 CAS 精确关联，清理后的 unbound/0 不补造历史 released。
 
 按发送者、`operation_id`、action 幂等接收，同一任务的参与方和版本不能变化。重复或乱序消息先回源核对当前事实，只补本端尚未完成步骤；不能用旧提示覆盖新文件。SDK 控制类型的无效载荷、未知 action 或处理失败也由拦截器消费，不投递为普通聊天消息；有效待办须持久保存后再结束接收处理。
 
@@ -206,7 +208,7 @@ flowchart TD
     F --> T{是待审批的绑定或转移请求吗}
     T -->|是| Q[发布 ownership.request，由应用界面或策略判断]
     Q -->|拒绝| V[持久保存拒绝并回复 P2P，发布 ownership.rejected]
-    Q -->|同意| P[持久保存审批，回复 P2P 并推进本端步骤]
+    Q -->|同意| P[持久保存审批，按发起方推进本端文件步骤及必要通知]
     T -->|否| G{下一步需要本端签署或写入吗}
     P --> G
     G -->|否| H[新鲜核查结果并发布本地事件]
@@ -233,7 +235,7 @@ flowchart TD
 | `ownership.stopped` | 收到有效对端停止通知，或本端因当前版本/目标已被后续操作替代而停止推进；当前没有公开取消 Facade。 |
 | `ownership.error` | 无法推进或核验；可重试错误保留当前稳定结果及待办。 |
 
-绑定、转移的 completed 需新鲜双文件共识、固定 owner/目标及本端已签完整原件、摘要、原条件匹配；转移原 owner 还需本任务 transfer_owner 原授权。release 的 completed 接受本任务声明 v 的新鲜 released/v，或由本任务原件严格关联的真实 unbound/0；任务 base/target 及历史 verified 仍为 v，实际完成证据不得伪造 released，sub 可离线。消息、ACK 和阶段标记均不替代当前材料核验。
+绑定、转移的 completed 需新鲜双文件共识、固定 owner/目标及本端已签完整原件、摘要、原条件匹配；转移原 owner 还需本任务 transfer_owner 原授权。release 的 completed 接受本任务声明 v 的新鲜 released/v，或由本任务原件严格关联的真实 unbound/0；任务 base/target 保持 v，本次共识验收证据的 status／relation_version 保存真实 released/v 或 unbound/0，公共事件 relation_version 反映该任务本次实际验收的版本（released/v 为 v、unbound/0 为 0），已有历史验收记录不改写，不得伪造 released；sub 可离线。消息、ACK 和阶段标记均不替代当前材料核验。
 
 恢复本地 completed 任务核对本任务审批、本人已签原件、原条件和当时保存的验收结果，缺失损坏仅阻止该任务恢复；不把本地历史记录或独立证据库当作当前关系。实际授权始终重新核验当前 agent.md 与 owner.md；当前网络不能补造历史原件。release 后当前关系为 unbound/0 时，sub 须以本任务清理原件、摘要、原 CAS，或本人明确 accept 的匹配原 bind/transfer.release_cleanup，精确核对当前 NS 原文、摘要、ETag及已知提交 ETag；owner 须以本任务 release 完整原件、hash 与当前 owner.md 一致且当前证书验证有效确认，均不得补造旧条件。
 
@@ -275,27 +277,28 @@ signature: <严格Base64编码的DER签名>
 
 ## 4. 建立关系
 
-常规绑定由 sub 应用调用 `bindOwneraid`。owner 批准后发布自己的声明，再由 sub 自签提交；拒绝时结束本次 SDK 任务。
+sub 发起绑定时调用 `bindOwneraid`，先 fresh 确认无锁并探测 `X-AUN-Ownership-Stage: 1` 能力，再保存本端同意与签名字节，Stage 条件上传待确认原件并核对 pending 响应，之后发送请求。owner 批准后发布自己的声明，由 fresh 检查验收已存候选；sub 可离线。owner 发起的对称路径见第 4.4 节。拒绝决定与待确认候选清理分别保存和恢复。
 
 ```mermaid
 flowchart TB
-    A[sub 应用调用 bindOwneraid] --> B[sub SDK 新鲜检查无锁及版本 v，保存绑定意图]
-    B --> C[持久保存并发送 P2P bind.request 给 owner]
+    A[sub 应用调用 bindOwneraid] --> B[sub SDK 新鲜检查无锁、版本 v 及 Stage 能力，保存绑定意图]
+    B --> S[sub 自签并保存原件与原 CAS，Stage 条件上传 agent.md]
+    S --> T[NS 保存待确认候选：pending / v+1 / unlocked]
+    T --> C[持久保存并发送 P2P bind.request 给 owner]
     C --> D[owner SDK 拦截并核对，发布 ownership.request]
     D --> E{owner 应用同意还是拒绝}
     E -->|拒绝| R[持久记录拒绝并发送 bind.reject，双方发布 ownership.rejected]
+    R --> Q[sub 在线或恢复后，仅条件清理本轮精确匹配的未锁候选]
     E -->|同意| F[持久记录审批并发送 bind.accept]
-    F --> G[owner SDK 内部 declareSubaid：自签条件发布版本 v+1 的 owner.md]
-    G --> H[向 sub 发送 P2P owner.ready]
-    H --> I[sub SDK 拦截，回源核对审批上下文及当前 owner.md]
-    I --> J[sub SDK 内部 declareOwneraid：自签并用 sub 身份条件提交 agent.md]
-    J --> N[NS 最终核对无锁、双方文件、签名、版本及 ETag]
-    N -->|通过| K[CAS 原子保存完整 sub 自签名片，声明 v+1]
+    F --> G[owner 核对候选原件与 CAS，自签发布版本 v+1 的 owner.md]
+    G --> N[NS fresh 核对本轮声明、双方当前原件、签名、版本及 ETag]
+    N -->|通过| K[CAS 清除 pending 并建立锁，保留 sub 原字节]
     N -->|材料不足或冲突| W[保存本端待办，按当前事实恢复]
-    K --> L[sub 新鲜核查共识及本次文件后发布 ownership.completed]
+    K --> P[owner 新鲜核查后 completed；sub 离线不阻碍]
     K --> M[NS 按第 2.3 节同步 Storage 名片副本]
+    K --> H[向 sub 发送 owner.ready；在线或恢复后核对已存原件及共识]
+    H --> L[sub 新鲜确认后发布 ownership.completed，不再次 PUT]
     L --> O[向 owner 发送 P2P relation.confirmed]
-    O --> P[owner SDK 拦截并新鲜核查后发布 completed]
 ```
 
 ### 4.1 读取当前无 owner 的文档
@@ -333,7 +336,7 @@ ownership:
 
 ### 4.3 sub 提交自己的声明
 
-sub 签署、上传自己的完整 `agent.md`：
+sub-first 在 owner 审批及第 4.2 节发布前，先签署自己的完整 `agent.md`，持久保存原字节、摘要与原 CAS，通过能力预检后携带 `X-AUN-Ownership-Stage: 1` 条件上传；必须核对响应能力头、`pending/unlocked` 和候选版本。owner-first 则在确认当前 owner 原件及 sub 同意后直接条件上传同样的目标文件，不带 Stage。以下按文件角色列示原件：
 
 ```yaml
 aid: subject.agentid.pub
@@ -351,29 +354,31 @@ ownership:
     declared_at: 1791523260
 ```
 
-NS 验收成功后以 CAS 保存完整 sub 自签 agent.md，当前声明版本为 1；owner.md 保持在 owner Storage。两方声明标识和时间可不同，AID 与关系版本须匹配。
+Stage 成功后 NS 保存完整 sub 自签 agent.md，当前候选版本为 1，仍 pending/unlocked；该文件是 NS 当前权威名片，关系尚未形成共识。Storage 名片副本待 fresh 验收清除 pending 后才同步。owner 发布本轮匹配 declare 后，fresh 检查复读、验签并以 CAS 清除 pending，建立双文件共识。两方声明标识和时间可不同，AID 与关系版本须匹配。
 
-材料未齐时 sub 提交不改变权威名片；本端保留文件，后续独立重试。
+材料未齐或 owner 摘要仍等于暂存时快照时保持 pending，不能以旧声明完成新审批。验收使用已存 sub 字节，不要求 sub 在线或重签；原件变化则停止旧任务的完成确认与清理。
 
 绑定中断及响应丢失的恢复见第 8 节。
 
 ### 4.4 owner 发起绑定
 
-owner 应用调用 `bindSubaid` 时，先向 sub 发出绑定请求，由 sub 同意或拒绝。owner 只有收到有效同意后才发布自己的 owner.md；sub 已保存的同意决定允许后续在材料匹配时自签提交。
+owner 应用调用 `bindSubaid` 时先 fresh 核对当前状态和原 NS 基线，只有可靠确认无 owner 锁才能绑定；`invalid`、`unavailable` 或基线不明不视为无锁，已有锁只能走当前 owner 发起的解绑或转移。owner 持久保存任务、完整签名 `owner.md` 原件和原 Storage 条件，条件发布并读回确认后才发送一次 `bind.request`。sub 收到通知后回源检查关系及当前 owner 原件，核对签名、证书、AID 和目标版本；明确同意后保存签名 `agent.md` 与原 NS 条件，直接条件 PUT，不带 Stage。NS 最终复核后锁定并同步副本，双方 fresh 确认完成，不需要 `bind.accept` 或 `owner.ready` 往返。
 
 ```mermaid
 flowchart TB
-    A[owner 应用调用 bindSubaid，保存意图及 NS 版本]
-    A --> B[向 sub 发送 P2P bind.request]
-    B --> C[sub SDK 拦截，发布 ownership.request]
+    A[owner 调用 bindSubaid，fresh 确认无锁及基线，保存任务]
+    A --> P[保存完整 owner 原件与原条件，条件发布并确认 owner.md]
+    P --> B[向 sub 发送一次 P2P bind.request]
+    B --> C[sub SDK fresh 复查关系，验签当前 owner 原件，发布 ownership.request]
     C --> D{sub 应用界面或自动策略同意还是拒绝}
     D -->|拒绝| R[回复 bind.reject，双方结束本次 SDK 任务]
-    D -->|同意| E[持久记录同意并回复 bind.accept]
-    E --> F[owner SDK 拦截同意并回源复核，自签发布 owner.md]
-    F --> G[向 sub 发送 P2P owner.ready]
-    G --> H[sub SDK 验证后自签提交，合入第 4 节 NS 验收与确认步骤]
+    D -->|同意| S[保存同意、agent 原件及原 CAS；直接 PUT，不带 Stage]
+    S --> G[NS 复核双文件及原条件，原子提交并锁定，排队同步副本]
+    G --> H[各端 fresh 确认完成，可发送 relation.confirmed 结果通知]
 ```
 
+sub 拒绝时不上传 `agent.md`，拒绝不改变 NS 关系。owner 清理邀请前须 fresh 确认关系未锁定且当前 `owner.md` 仍精确匹配本任务原件，再带最后读取且已核对本任务原件的当前对象 `version` 作为 `expected_version` 原子删除；已锁定、原件替换或版本冲突均停止旧清理。发布或提交响应丢失时复用原任务、原签名字节和原条件；目标已精确提交时只观察确认，不重签、刷新条件或盲目回滚。
+
 ## 5. owner 锁下的普通更新
 
 sub 可以更新名称、正文等，重新签署完整文件；当前 `owner` 和 `ownership.statement` 必须完整保持。以下是允许的更新：
@@ -396,14 +401,14 @@ ownership:
 
 ```mermaid
 flowchart TD
-    A[sub 提交自己的新 agent.md] --> B[NS 读取当前权威文档和保护记录]
-    B --> C[查询原 owner Storage 当前文件]
+    A[sub 提交自己的新 agent.md] --> B[NS 读取当前权威文档，检查本人签名与原 CAS]
+    B --> E{完整保留关系材料的存在性、类型和值吗}
+    E -->|是| F[保存普通正文更新，声明版本不变，不依赖 owner Storage]
+    E -->|否| C[查询原 owner Storage 当前文件]
     C --> D{原关系仍稳定吗}
-    D -->|是| E{完整保留关系字段吗}
-    E -->|是| F[保存新文档，关系版本不变]
-    E -->|否| G[拒绝，返回 owner_locked]
+    D -->|是| G[拒绝，返回 owner_locked]
     D -->|已 release 或确认删除| H[动态确认 released 后验收候选]
-    D -->|无法确认或文件无效| I[拒绝本次关系变更，保留保护记录]
+    D -->|无法确认或文件无效| I[拒绝本次关系变更，保留当前原件与保护]
 ```
 
 普通更新无需 owner 客户端在线。所有名片入口仍受旧关系锁保护，不能以新文件中的 owner 判断旧锁。
@@ -712,6 +717,14 @@ flowchart TB
 
 ## 8. 崩溃与响应丢失后的恢复
 
+冲突须区分三层：本地任务 revision CAS 失败返回 `persistence_unavailable`，停止旧内存任务，后续恢复重读原 operation；NS 原 ETag／存在性条件或提交快照冲突返回 HTTP `412`，关系语义冲突还可能为 `409`；Storage 原 `expected_version`／存在性或条件删除竞态返回 RPC `-32009`，均归为远端 `conflict`。远端冲突后 fresh 读取 NS 和 Storage 当前原文、SHA、ETag／version，与本地持久审批、原签名字节和原条件分类核对。只有整个目标共识及本任务证据精确匹配才幂等确认；单份文件同 SHA 不保证自动恢复。网络或结果未知可恢复原 operation，真实内容／关系变化停止旧任务，再按新状态确认并发起新操作；不自动合并、刷新条件或重签。清理仅条件删除本任务原件。细节见 [开发与移植指南 §10.3](Ownership2.1-SDK开发与移植指南.md#103-cas-冲突分类与恢复边界)。
+
+0.5.20 与 0.5.19 的 `aun.ownership.sdk.v1` 控制消息保持原字段，不能以缺少后来新增的本地字段拒绝任务。恢复先校验原 operation、参与方、角色、审批、inbox/outbox 及已签原件；缺少双文件起始快照的历史任务，核对当前权威材料后，在原 operation 下以 CAS 保存完整源记录、revision、摘要及适配检查点。保留有效决定、原候选签名字节和原条件，适配检查点不能冒充不存在的历史基线；无法确认时保留现场并返回冲突或不可用，不补造授权。0.5.19 release 的控制目标可能是 base+1，原 wire 值及历史记录保持不变，实际释放声明和当前事实仍按 base 核对。更早的 proof、旧普通 pending 和旧 owner 操作沿用其原有兼容规则，不自动转换或伪造 2.1 双文件关系。 旧 Owner 候选尚未发布时，原 `expected_revision` 必须有权威证据精确匹配，不能用当前 version 替代；服务未提供旧 revision 证据时保留原件及任务并返回 unavailable。目标已提交但任务仍待恢复时，只有本地原始签名候选与当前双方共识精确匹配才确认完成；缺少这些证据不能从当前网络补造历史原件或提交条件。
+
+普通主动绑定优先恢复可兼容任务；仅确认同 subject 本地任务损坏或结构不可继续时，归档原任务后新鲜检查、以新 operation 重新发起并重新审批。网络／IO、CAS 竞争、另一有效意图和远端原件／关系冲突不能触发自动重置。
+
+任务管理另提供无参数 TS/JS `resetOwnershipTask()`、Python `reset_ownership_task()`、Go `ResetOwnershipTask(ctx)`，重置当前 AID 作为 sub 或 owner 发起的未完成 bind/release/transfer（pending/error），保留参与他人发起的任务及 completed/rejected/stopped 历史。统一返回 `{reset_operation_ids:[],skipped_operation_ids:[]}`；两列表排序去重，无法可靠判断发起人、状态或操作 ID 的记录列入 skipped。每行以 CAS 原子归档完整源记录、摘要及 revision，竞争后重载判断；批次不是跨行全有或全无事务。已重置任务、旧队列、候选与条件不能再被恢复、审批、指定旧 ID 或迟到消息驱动。接口不发新请求，不删除远端文件，不修改 agent.md，不绕过当前关系锁；随后绑定仍须新鲜检查并取得所需审批。
+
 ```mermaid
 flowchart TD
     A[本端重启、重连或收到超时] --> B[读取 NS 新鲜版本、文档和 owner 当前文件]
@@ -724,17 +737,19 @@ flowchart TD
     E -->|已有后续版本或目标不符| I[停止旧任务写入和删除]
 ```
 
-本端保存 `operation_id`、操作与参与方、起始/目标版本、本端审批及已收到的各方决定、待发送 P2P 消息、完整签名文件原始字节、ETag、首次转移授权全文摘要及实际期限和待清理项。发送前保存待发送项，发送成功后清除；收件先保存有效待办，重复消息幂等处理。各端分别持久化，不组成跨方事务。
+本端保存 `operation_id`、操作与参与方、起始/目标版本、本端审批及已收到的各方决定、待发送 P2P 消息及稳定传输 message_id、完整签名文件原始字节、ETag、首次转移授权全文摘要及实际期限和待清理项。发送前保存待发送项，发送成功后清除；收件先保存有效待办，重复消息幂等处理。各端分别持久化，不组成跨方事务。
 
 恢复先核对权威现状，再恢复待审批事件、重发仍有效的通知或补本端文件步骤；复用原任务 ID、审批结论及已签署原始字节。尚未决策的请求再次发布 `ownership.request`，不得自动批准；拒绝、停止、过期或被替代的任务不能被迟到消息重启。release 待确认、sub 字段待清理和转移旧文件待清理分别恢复，不因超时生成新声明或回滚已提交结果。
 
-重复发起 Facade 先查找本端身份、发起方、operation、sub、原 owner、新 owner及 base/target 关系版本匹配的进行中任务，并核对原声明完整原文、摘要和原 CAS，再执行新操作的资格检查；清理后版本数字可重复，不能仅凭数字认定同一关系。原代际仍有效时复用原 `operation_id`、审批、已签原始字节、提交条件和授权期限；目标已提交但响应丢失时，以新鲜 NS 和完整本人证据完成原任务。同代际不同进行中意图返回 `conflict`，不创建额外 stopped 任务；并发相同意图只保留一个任务。后续代际越过旧任务时先停止旧任务，再创建合法的新任务。rejected、stopped、不可重试 error 不复活；历史 completed 不按参数相同复用为新操作。
+现代 bind 区分起始原件与待确认候选，保存 pending 原文／摘要／ETag；不能只凭 owner 和数字版本认领旧审批。`rejected` 保持原决定，但本轮精确候选的拒绝清理仍可恢复；先保存清理签字节和原 CAS，响应丢失复用原件。reset 不删除远端 pending、不解锁稳定关系；未锁候选可由新显式申请以新上下文、原件 CAS 和重新审批替换，旧任务不能继续清理新原件。
+
+重复发起 Facade 先查找本端身份、发起方、operation、sub、原 owner、新 owner及 base/target 关系版本匹配的进行中任务，并按第 2.1 节核对完整 statement 或无声明时的起始原件，再执行新操作的资格检查；清理后版本数字可重复，不能仅凭数字认定同一关系。原代际仍有效时复用原 `operation_id`、审批、已签原始字节、提交条件和授权期限；已准备候选、Storage 起始原件及清理原件仍须全文、摘要和原 CAS 精确匹配，不因 statement 相同而刷新。目标已提交但响应丢失时，以新鲜 NS 和完整本人证据完成原任务。同代际不同进行中意图返回 `conflict`，不创建额外 stopped 任务；并发相同意图只保留一个任务。后续代际越过旧任务时先停止旧任务，再创建合法的新任务。rejected、stopped、不可重试 error 不复活；历史 completed 不按参数相同复用为新操作。
 
 错误分类与任务状态分别保存：服务、网络或依赖暂不可用为 `unavailable`；确定无效的文件、签名、证书或任务证据为 `invalid`，两者不得混用。权威元数据、正文摘要不一致，以及 Storage Base64 传输封装损坏均为 unavailable；摘要匹配后确定非法的 UTF-8、文件字段或签名为 invalid。
 
 | 情况 | task.status / retryable |
 | --- | --- |
-| 等审批、等材料、网络或服务暂不可用、缺少 2.1 能力 | `pending` / `true`；缺能力 code 为 `unsupported_protocol`。 |
+| 等审批、等材料、可重试的网络或服务暂不可用、缺少 2.1 能力 | `pending` / `true`；缺能力 code 为 `unsupported_protocol`。 |
 | 关系版本被替代、目标改变、授权过期、原提交条件失效 | `stopped` / `false`。 |
 | 确定无效的文件、签名、证书或任务证据 | `error` / `false`，code 为 `invalid`。 |
 | 明确审批拒绝 | `rejected` / `false`。 |
@@ -744,10 +759,12 @@ flowchart TD
 
 | 情况 | 稳定结果及恢复行为 |
 | --- | --- |
-| 请求或审批回复尚未送达 | 先核对原声明完整原文、摘要、目标及原 CAS 仍匹配，再复用原任务重发；待审批事件可重发，已决定的请求沿用原决定。 |
+| 请求或审批回复尚未送达 | 先按第 2.1 节核对原关系的完整 statement、固定目标及本任务已准备原件；无声明时核对起始原件。已准备候选、Storage 起始原件和清理原件仍按全文、摘要、存在性及原 CAS 精确匹配，再复用原任务重发；待审批事件可重发，已决定的请求沿用原决定。 |
 | 转移只收到一方同意 | 不发布转移授权；等待另一方，收到拒绝则通知停止。 |
 | 只保存了本地目标文件 | NS 名片和关系不变；核对本端授权及当前版本，继续缺少的本方写入或停止任务。 |
 | 新绑定只发布了 owner 文件 | 尚无新稳定关系，不授予 owner 权限；等待 sub 提交匹配声明。 |
+| sub 已 Stage 暂存，等待 owner | NS 为 pending/unlocked，公共共识 single_sided；保留原件与审批上下文。owner 发布本轮声明后可在 sub 离线时触发 fresh 验收。 |
+| bind 被拒绝，sub 离线或清理响应丢失 | 拒绝决定保持，恢复时仅对本轮仍待确认且全文／摘要／ETag 匹配的候选复用原清理字节及 CAS；候选变化或已验收时停止旧清理。 |
 | owner 上传响应丢失 | 核对规范路径完整原文及摘要；与本任务已签文件一致则仅确认，否则仅在起始存在性、原文及摘要仍匹配时重传。已观察到后续变化则停止。 |
 | sub 上传响应丢失（绑定或转移） | 核对 NS 当前 owner、关系版本及完整文件摘要，判断是否已提交；仅版本增加不足以认定成功。已提交结果保持，不能因超时盲目重写或回滚。 |
 | 名片已验收，Storage 副本未同步 | NS 已提交结果保持；由 NS 恢复后按第 2.3 节补齐当前权威名片副本，SDK 仍以 NS 为准。 |
@@ -820,16 +837,16 @@ self-owner 是 `owner_aid == sub_aid`，区别于无 owner。仍需双文件及
 
 ### 10.2 SDK 本地推进，NS 最后验收
 
-本例从无 owner 的 NS 版本 `0` 开始，目标版本为 `1`。应用发起 self-owner 绑定表达本端两个角色的意愿，默认 SDK 先发布 owner 文件，再提交 sub 文件；无需向自己发送审批消息：
+本例从无 owner 的 NS 版本 `0` 开始，目标版本为 `1`。应用发起 self-owner 绑定表达本端两个角色的意愿；`bindOwneraid(self)` 与 `bindSubaid(self)` 均沿用本端 sub-first 的 Stage 路径，先确认 Stage 能力，无需向自己发送审批消息：
 
 ```mermaid
 flowchart TB
     A[本端应用调用 bindOwneraid 或 bindSubaid，目标为自身]
     A --> B[SDK 新鲜检查无锁，确认目标版本 v+1]
-    B --> C[本地 owner 角色自签条件发布 owner.md]
-    C --> D[本地 sub 角色自签条件提交 agent.md]
-    D --> N[NS 按统一规则最终验收双方文件]
-    N -->|通过| E[数据库 CAS 保存完整自签名片]
+    B --> D[确认 Stage 能力，保存原件与 CAS，Stage 暂存 agent.md]
+    D --> C[本地 owner 角色自签条件发布 owner.md]
+    C --> N[NS fresh 按统一规则最终验收双方文件]
+    N -->|通过| E[数据库 CAS 清除 pending，保留完整自签原件并锁定关系]
     N -->|失败| R[保留本端稳定结果与待办，按当前事实恢复]
     E --> F[SDK 新鲜核查后发布 ownership.completed]
     E --> G[NS 按第 2.3 节同步 Storage 名片副本]
@@ -869,7 +886,7 @@ ownership:
     declared_at: 1791523260
 ```
 
-缺少任一有效声明时 NS 不提交 self-owner，本端保留文件独立重试；不能退为单文件共识。
+缺少任一有效声明时不能确认 self-owner；已 Stage 暂存的原件保持 pending/unlocked，本端保留各文件进度独立重试，不能退为单文件共识。
 
 稳定后当前 agent.md 声明 owner 为 subject.agentid.pub、relation_version 为 1，owner.md 匹配时关系投影为 locked；普通更新见第 5 节。