@agentunion/fastaun 0.5.20 → 0.5.22

package/_packed_docs/protocol/08-AUN-E2EE.md

@@ -1,12 +1,12 @@
-# AUN-E2EE 历史扩展规范（Legacy）
-
-> 版本：2.0-draft
-> 状态：历史兼容文档
-> 适用范围：AUN 客户端 SDK、客户端应用、跨语言实现
-> 不适用范围：Gateway、Message 模块的加解密实现
-> 定位：旧 P2P E2EE 信封说明；当前默认主路径已迁移到 E2EE V2 多设备 wrap
-
-> **当前实现说明**：最近版本的 SDK 默认使用 V2 多设备 wrap。P2P 加密消息通过 `message.send` 承载 `e2ee.p2p_encrypted` envelope，Group 加密消息通过 `group.v2.send` 承载 `e2ee.group_encrypted` envelope；每条消息一把 `master_key`，按 recipient 设备生成 `3DH` / `1DH` wrap，接收端验证 `sender_signature`、AAD、recipient digest/proof 后解密。当前 V2 链路见 [E2EE_V2消息通信时序图](../sdk/E2EE_V2消息通信时序图.md)；群组 V2 规范见 [08-AUN-E2EE-Group](08-AUN-E2EE-Group.md)。本文保留 `prekey_ecdh_v2` / `long_term_key` 旧格式，用于历史兼容和迁移排查，不应作为新实现的默认发送格式。
+# AUN-E2EE 历史扩展规范（Legacy）
+
+> 版本：2.0-draft
+> 状态：历史兼容文档
+> 适用范围：AUN 客户端 SDK、客户端应用、跨语言实现
+> 不适用范围：Gateway、Message 模块的加解密实现
+> 定位：旧 P2P E2EE 信封说明；当前默认主路径已迁移到 E2EE V2 多设备 wrap
+
+> **当前实现说明**：最近版本的 SDK 默认使用 V2 多设备 wrap。P2P 加密消息通过 `message.send` 承载 `e2ee.p2p_encrypted` envelope，Group 加密消息通过 `group.v2.send` 承载 `e2ee.group_encrypted` envelope；每条消息一把 `master_key`，按 recipient 设备生成 `3DH` / `1DH` wrap，接收端验证 `sender_signature`、AAD、recipient digest/proof 后解密。当前 V2 链路见 [E2EE_V2消息通信时序图](../sdk/E2EE_V2消息通信时序图.md)；群组 V2 规范见 [08-AUN-E2EE-Group](08-AUN-E2EE-Group.md)。本文保留 `prekey_ecdh_v2` / `long_term_key` 旧格式，用于历史兼容和迁移排查，不应作为新实现的默认发送格式。
 
 ---
 
@@ -95,6 +95,11 @@ AUN-E2EE 是 Layer 3 扩展协议，建立在以下核心能力之上：
 - `message_id`
 - `timestamp`
 - `type`
+- `need_render`（可选布尔值，默认 `true`，P2P 与 Group 一致）
+
+`need_render` 是服务端可见的展示/统计提示，由 SDK 从 `message.send` / `group.send` 参数提取到外层信封；历史缺字段或 NULL 按 `true`。它不参与 E2EE AAD、`protected_headers`、消息保护签名或元数据 HMAC，不能当作接收端已验证的业务授权条件。RPC `client_signature` 仍按现有完整业务参数规则覆盖该字段，不为它增加 canonical 排除项。
+
+按 sender 隔离的 Pull/ACK 只改变消费游标，不重写历史密文或 AAD，不引入 `peer_seq`。`prev_peer_seq` 和 peer 扫描覆盖字段均是服务端投递元数据，规则见 [服务协议 §6.3](06-服务协议.md#63-点对点消息-message)。单 peer ACK、slot 级 `legacy_safe_ack_seq` 都不是设备级密钥销毁证明；当前单实例实现可省略 `device_safe_ack_seq`，客户端须保守保留仍可能用于历史解密的旧 SPK。
 
 ### 4.2 密文载荷
 
@@ -110,7 +115,7 @@ AUN-E2EE 是 Layer 3 扩展协议，建立在以下核心能力之上：
 
 ### 5.2 密文消息
 
-旧 `e2ee.encrypted` 信封通过 `message.send` 传输时，`encrypted` 必须为 `true`，`payload.type` 必须为 `e2ee.encrypted`。当前新实现应使用 V2 `e2ee.p2p_encrypted` 信封。
+旧 `e2ee.encrypted` 信封通过 `message.send` 传输时，`encrypted` 必须为 `true`，`payload.type` 必须为 `e2ee.encrypted`。当前新实现应使用 V2 `e2ee.p2p_encrypted` 信封。
 
 ---
 
@@ -188,7 +193,7 @@ AUN-E2EE 支持两种加密模式，SDK 自动按优先级选择。
 
 ### 7.3 模式选择策略
 
-旧版 SDK 在 legacy 信封中按以下优先级自动选择：
+旧版 SDK 在 legacy 信封中按以下优先级自动选择：
 
 1. **优先**：prekey_ecdh_v2（服务端有接收方 prekey）
 2. **降级**：long_term_key（无 prekey 时，需客户端安全策略允许）
@@ -197,7 +202,7 @@ AUN-E2EE 支持两种加密模式，SDK 自动按优先级选择。
 
 ### 7.4 兼容性
 
-- 旧版发送端应优先使用 `prekey_ecdh_v2` 模式发送；当前新实现应使用 V2 多设备 wrap。
+- 旧版发送端应优先使用 `prekey_ecdh_v2` 模式发送；当前新实现应使用 V2 多设备 wrap。
 
 ---
 

package/_packed_docs/protocol/11-Storage-/345/255/220/345/215/217/350/256/256.md

@@ -31,14 +31,22 @@ Storage 服务是 AUN 协议的应用层扩展，提供对象存储能力。负
 
 ## 11.3 控制面方法
 
-**权威对象读取**：`storage.head_object`、`storage.get_object` 和 `storage.fs.stat` 可传 `consistency: authoritative`，绕过正负缓存并确认恢复可用性。结果包含 `consistency`、`exists`、`owner_aid`、`bucket`、规范 `path` 和 Unix 秒 `observed_at`；存在时附摘要及现有对象元数据，get 返回完整严格 Base64 `content`。故障、权限错误和恢复未完成不得返回 `exists=false`；下载或网关 404 不能证明权威不存在。
+**权威对象读取**：`storage.head_object`、`storage.get_object` 和 `storage.fs.stat` 可传 `consistency: authoritative`，绕过正负缓存并确认恢复可用性。结果包含 `consistency`、`exists`、`owner_aid`、`bucket`、规范 `path` 和 Unix 秒 `observed_at`；存在时附摘要及现有对象元数据，get 返回完整严格 Base64 `content`。故障、权限错误和恢复未完成不得返回 `exists=false`；下载或网关 404 不能证明权威不存在。
 
 
 
-规范 `default/agent.md` 与 `default/sub_aids/{sub_aid}/owner.md` 的上传会话使用独立临时对象，`create_upload_session` 返回 `session_id`；新客户端完成这些规范文件时必须携带同一 `session_id`。服务端核对会话的认证申请者、目标及有效期，验证完整内容后原子发布，失败保留旧完整文件。普通对象保持既有上传流程，不保证返回 `session_id`；该临时会话不记录 Ownership 关系事实或路径历史。
-
+规范 `default/agent.md` 与 `default/sub_aids/{sub_aid}/owner.md` 的上传会话使用独立临时对象，`create_upload_session` 返回 `session_id`；新客户端完成这些规范文件时必须携带同一 `session_id`。服务端核对会话的认证申请者、目标及有效期，验证完整内容后原子发布，失败保留旧完整文件。普通对象保持既有上传流程，不保证返回 `session_id`；该临时会话不记录 Ownership 关系事实或路径历史。
+
 Ownership 2.1 的 `default/sub_aids/{sub_aid}/owner.md` 必须公开可读，只有命名空间所属 owner 可修改、删除；该限制覆盖 ACL、token、父目录、移动、重命名、软链、挂载及自动清理，不能由通用权限顺序放宽。关系释放仍以 NS 验收为准；完整规则见 [Ownership 协议定义 2.1](Ownership协议定义2.1.md)。
 
+### 读取条件与缓存策略
+
+普通 `storage.get_object`、`storage.get_by_share` 和 `storage.create_download_ticket` 可接受 `if_sha256`（完整对象的 64 位十六进制 SHA-256）。服务端仍执行本次访问授权；摘要匹配时可返回对象元数据、`not_modified: true` 并省略正文或下载票据。该响应仅表示正文未变化，不等于 HTTP 304。SDK 只有在同一缓存键下持有摘要匹配且已验证的完整正文时，才能复用正文；无可用正文时必须重新请求完整内容。
+
+读取响应可返回 `read_cache`：`reusable` 表示响应可否复用，`inline` 表示是否允许缓存完整正文，`max_age_ms` 是有效期上限，`max_inline_bytes` 是服务端 inline 正文大小上限。显式允许策略须 `reusable: true`，正文还须 `inline: true`；省略 `max_age_ms` 时默认 60 秒，有限正数最多使用 60 秒；显式禁止、null／非正数／非法 TTL 均不得复用。`read_cache` 缺省或为 `null` 时，SDK 默认缓存元数据及不超过 65,536 字节、摘要已验证的完整正文 60 秒。服务端返回的 TTL 不得超过对象有效期或本次访问授权有效期，并须扣除本次授权／对象解析所用元数据的已缓存年龄及解析耗时，使元数据可能陈旧时间与 SDK 可复用时间之和不超过 60 秒；服务端正缓存内部同样封顶 60 秒。
+
+有限次 token、ACL 或分享授权的 inline 读取只有返回正文才计次；inline 和大对象匹配 `if_sha256`、仅返回无正文 `not_modified` 均不计次，额度耗尽后仍允许该条件验证。SDK 本地正文缓存命中不请求 Storage，因此不计次；HEAD 等纯元数据查询不计次。联网条件验证仍检查撤销、过期、身份和权限，不能借 SHA 绕过这些检查。限次授权可按 `read_cache` 缓存，TTL 受授权和对象有效期限制。大对象按下载授权计次：非 `not_modified` 请求签发下载 URL 或授权 302 时计一次，直接复用已签发的正文下载 URL 属于同次授权；再次向 Storage 申请 URL／授权跳转按新授权计次；Storage 不代理外部 OSS 正文，因此该计数不是 OSS 实际 GET 次数。范围参数错误、正文读取失败、下载 URL／票据准备失败不扣次；`storage.get_object_url` 仅返回稳定地址，不计次，权限和额度预检保持。响应准备成功后发生网络中断，不承诺退回次数。
+
 ### `storage.put_object`
 
 内联写入小对象（≤ 内联上限）。
@@ -75,12 +83,15 @@ Ownership 2.1 的 `default/sub_aids/{sub_aid}/owner.md` 必须公开可读，只
 | `owner_aid` | string | ❌ | 默认调用者 AID |
 | `bucket` | string | ❌ | 默认 `"default"` |
 | `object_key` | string | ✅ | 对象路径 |
+| `if_sha256` | string | ❌ | 完整对象摘要条件；匹配时可返回 `not_modified: true` 并省略正文 |
 | `consistency` | string | ❌ | 传 `authoritative` 时绕过缓存并返回完整权威对象 |
 
-**响应**：`{ owner_aid, bucket, object_key, content (base64), content_type, size_bytes, sha256, version, updated_at }`
+**响应**：`{ owner_aid, bucket, object_key, content (base64, 可省略), content_type, size_bytes, sha256, version, updated_at, read_cache, not_modified }`
 
 可选 `consistency: authoritative` 返回本节定义的权威对象结果；权威 get 要求完整对象，不接受范围读取。
 
+`not_modified: true` 仅在带有匹配 `if_sha256` 时返回；响应仍须包含当前对象摘要及可用缓存策略。
+
 **权限**：私有对象仅所有者可读；公开对象（`is_private=false`）任何 AID 可读。
 
 ### `storage.head_object`
@@ -89,20 +100,28 @@ Ownership 2.1 的 `default/sub_aids/{sub_aid}/owner.md` 必须公开可读，只
 
 **参数**：同 `get_object`。
 
-**响应**：`{ owner_aid, bucket, object_key, content_type, size_bytes, sha256, version, etag, is_private, expire_at, created_at, updated_at }`
+**响应**：`{ owner_aid, bucket, object_key, content_type, size_bytes, sha256, version, etag, is_private, expire_at, created_at, updated_at, read_cache }`
 
 可选 `consistency: authoritative` 返回本节定义的权威对象结果，包括明确当前不存在。
 
+HEAD 不返回正文，也不消耗 token、ACL 或分享的读取次数。
+
 **权限**：同 `get_object`。
 
 ### `storage.delete_object`
 
 删除单个对象。
 
-**参数**：对象寻址同 `get_object`。
+**参数**：对象寻址同 `get_object`，另有：
+
+| 参数 | 类型 | 必需 | 说明 |
+|------|------|:----:|------|
+| `expected_version` | integer | ❌ | 非负 JSON 整数版本 CAS；缺省保持无条件删除 |
 
 **响应**：`{ deleted (bool), owner_aid, object_key }`。
 
+提供 `expected_version` 时，`0` 仅匹配对象不存在并返回 `deleted: false`；正整数仅匹配当前对象版本并删除。对象存在性或版本与条件不符、检查后对象被替换导致 CAS 失败时返回 `-32009`（Version conflict）；不提供时保持既有无条件删除语义。字符串、浮点数、布尔值及负数不是合法版本条件。收到 `-32009` 后，先权威读取当前对象及原件摘要；目标已不是本任务原件时停止删除，不得改用新版本号自动重试。请求结果未知时，先核对目标是否已删除，再决定是否重放原条件请求。
+
 **权限**：仅所有者可删。
 
 **副作用**：成功后发布 `event/storage.object_changed`（`action: "delete"`）。
@@ -204,7 +223,7 @@ Ownership 2.1 的 `default/sub_aids/{sub_aid}/owner.md` 必须公开可读，只
 | `size_bytes` | integer | ❌ | 期望大小，服务端校验 |
 | `expire_in_seconds` | integer | ❌ | 过期时间，默认永不过期 |
 | `metadata` | object | ❌ | 用户自定义元数据 |
-| `expected_version` | integer | ❌ | CAS 并发控制 |
+| `expected_version` | integer | ❌ | CAS 并发控制 |
 | `session_id` | string | ❌ | 规范 agent.md/owner.md 新上传必须沿用 create_upload_session 返回的同一会话 |
 
 **响应**：`{ owner_aid, bucket, object_key, size_bytes, content_type, sha256, version, etag, updated_at }`
@@ -222,9 +241,12 @@ Ownership 2.1 的 `default/sub_aids/{sub_aid}/owner.md` 必须公开可读，只
 | `owner_aid` | string | ❌ | 默认调用者 AID |
 | `bucket` | string | ❌ | 默认 `"default"` |
 | `object_key` | string | ✅ | 对象路径 |
+| `if_sha256` | string | ❌ | 完整对象摘要条件；匹配时可返回 `not_modified: true` 并省略下载票据 |
 | `expire_in_seconds` | integer | ❌ | URL 有效期，默认 3600 秒 |
 
-**响应**：`{ download_url, expire_at, file_name, size_bytes, content_type, sha256, version, etag }`
+**响应**：`{ download_url, expire_at, file_name, size_bytes, content_type, sha256, version, etag, read_cache, not_modified }`
+
+下载票据路径由 `create_download_ticket` 和 HTTP GET 组成。SDK 可在该路径与 `get_object` 入口间复用尚有效且摘要已验证的 inline 大小完整正文；没有可用正文时，必须获取新的下载票据并完成 HTTP 下载。票据 URL、token 和响应头不作为可长期复用的对象正文缓存。
 
 **权限**：私有对象仅所有者；公开对象任何 AID 可申请。
 

package/_packed_docs/protocol/Ownership/345/215/217/350/256/256/345/256/232/344/271/211.md

@@ -1,5 +1,7 @@
 # Ownership 协议定义
 
+> **历史 legacy 协议**：本文保留旧 `aun.ownership.v1`、proof、托管和代上传契约，下文“当前实现”指该历史实现时期，不代表 Ownership 2.1。当前 2.1 规范见 [Ownership协议定义2.1](Ownership协议定义2.1.md)；旧状态仅按其隔离兼容边界保留。
+
 本文定义当前四端 SDK 使用的 ownership wire 协议、`agent.md` ownership 字段、identity escrow 封套、owner 代上传授权和现有 RPC 边界。协议版本以当前实现中的 `aun.ownership.v1` 为准；`v1` 是消息类型版本，关系声明本身使用 `version: 2`。
 
 这里的声明 `version: 2` 不等于 [Ownership协议定义2.0](Ownership协议定义2.0.md)。工作区的 [agent.md SCHEMA](../agent.md/SCHEMA.md) 已采用该另一套文档声明契约；本文件中的 `ownership_proof`、托管、代上传与 release 以当前四 SDK 和 Name Service 代码为准。

package/_packed_docs/protocol/Ownership/345/215/217/350/256/256/345/256/232/344/271/2112.1.md

@@ -2,6 +2,8 @@
 
 本文完整定义 Ownership 2.1 的 AID 关系、双方声明、文件格式、owner 锁、解绑、转移及审计。读者无需同时查阅旧版协议。Ownership 是 `agent.md` 上可选的关系属性；关系状态只决定依赖 Ownership 验证的功能是否可用，不改变 `agent.md` 本身的有效性。关系为 `unbound`、`single_sided`、`released`、`invalid` 或 `unavailable` 时，只有依赖该关系的功能需要停止或降级；符合自身身份、格式和签名规则的 `agent.md` 仍可按普通名片读取、验证和使用。SDK 编排场景见 [Ownership SDK编排指南2.1](../sdk/Ownership-SDK编排指南2.1.md)。本文规定协议契约；当前工作区的实现、验收结果及剩余项见 [实施账本第 13 节](../sdk/Ownership2.1-TDD分阶段实施计划.md#13-2026-10-10-实施账本)，不以协议定义代替实现验收。
 
+普通 `agent.md` 的基础读取、验签、上传与显式 pending 恢复不以前置 Ownership 共识、owner Storage 或关系状态为条件。普通正文更新须原样保留当前原件中全部关系材料的字段存在性、类型和值，并遵守本人签名和原 ETag/CAS；材料无效或依赖不可用不能阻断这种更新。增删改关系字段继续执行当前双文件授权核验，不能借普通名片入口清除或替换 owner 锁。
+
 本协议的通用关系流程适用于 `human`、`group`、`org` 以外的主体；`human` 禁止声明 owner，`group/org` 作为被管理的 subject 时使用第 1.3 节的专属生命周期，也可按普通规则作为 `owner_aid`。通用关系双方独立签名、上传自己的声明文件；本协议不定义 ownership 专用授权 RPC 或权威关系控制方法，也不提供代签名、代上传及协议层申请、接受、拒绝方法。SDK 可以用普通加密 P2P 载荷进行非权威的本地编排；这些载荷不构成关系授权或 NS 提交事实，不能替代双方文件及服务端验收。可选托管由应用层实现，不改变这两个文件的签署及上传身份。
 
 兼容方向为新服务端保留旧 SDK 的既有身份认证、普通名片、通信和 legacy owner 操作入口；新 SDK 的 2.1 关系操作不兼容旧服务端。兼容旧 SDK 所需的注册、绑定、转移、查询和解绑 RPC 使用隔离的 Auth JSONL 状态及 NS `ownership_proof`，只处理 legacy 关系；它们不生成 2.1 双文件声明，不构成 2.1 授权、owner 锁、关系版本或 `consensus`，也不得覆盖已存现代声明。Ownership 2.1 当前关系始终重新核对两份当前文件；不把新 SDK 源码调用形态兼容作为本契约要求。
@@ -14,7 +16,7 @@
 | `owner_aid` | 声明管理关系的完整小写 AID。 |
 | `new_owner`（`new_owner_aid`） | 原 owner 在转移授权中指定的新管理方，其 AID 为完整小写 AID；独立签署、上传自己的目标 `owner.md`。 |
 | NS（nameservice，名称服务） | 在数据库中保存 sub_aid 的当前权威 `agent.md` 及 ETag，依据该文件与 owner 当前 `owner.md` 验证关系，负责名片发布验收及同步。owner_aid 只标识声明签署者的 AID/证书身份。 |
-| Storage（存储） | 保存 owner 的当前权威 `owner.md` 及 sub_aid 的已验收 `agent.md` 副本，提供公开读取、下载和权威对象查询；`owner.md` 仅 owner_aid 可写入、删除。 |
+| Storage（存储） | 保存 owner 的当前权威 `owner.md` 及 sub_aid 的 `agent.md` 读取副本（包括 NS 验收后的同步副本），提供公开读取、下载和权威对象查询；`owner.md` 仅 owner_aid 可写入、删除。 |
 | self-owner | `owner_aid == sub_aid`，同一 AID 同时承担管理方与被管理方角色。 |
 | `agent.md` | sub_aid 在 NS 上的当前权威版本；由 sub_aid 自己签名、上传。 |
 | `owner.md` | owner_aid 的 Storage 上的当前权威版本，路径为 `owner_aid:/sub_aids/{sub_aid}/owner.md`。 |
@@ -25,7 +27,7 @@ owner 锁是对两份当前签名材料的验证结果，不是另行持久化
 
 `owner.md` 公开可读、可下载；只有 owner_aid 可以写入、删除，不授予任何第三方写删权限。
 
-`agent.md` 经 NS 验收并持久保存后，由 NS 将完整原始签名文件同步到 sub_aid 的 Storage：`{sub_aid}:/agent.md`，保持原始字节及签名。该副本使用受限的可信 nameservice 内部 `storage.put_object` 完整原子写入入口，无需采用新客户端的 HTTP 上传会话；它只能写入本域 sub 的 `default/agent.md`，不获得 `owner.md` 写删权限，也不代签。寻址和文件操作遵循 [Storage/FS 协议](11-Storage-子协议.md)；关系验收和 owner 权限校验以 NS 当前 `agent.md` 与 owner 当前 `owner.md` 共同决定。同步队列只记录副本投递状态，Storage 名片副本不是 2.1 关系事实来源。
+`agent.md` 经 NS 验收并持久保存后，由 NS 将完整原始签名文件同步到 sub_aid 的 Storage：`{sub_aid}:/agent.md`，保持原始字节及签名。该副本使用受限的可信 nameservice 内部 `storage.put_object` 完整原子写入入口，无需采用新客户端的 HTTP 上传会话；它只能写入本域 sub 的 `default/agent.md`，不获得 `owner.md` 写删权限，也不代签。寻址和文件操作遵循 [Storage/FS 协议](11-Storage-子协议.md)；关系验收和 owner 权限校验以 NS 当前 `agent.md` 与 owner 当前 `owner.md` 共同决定。同步队列只记录副本投递状态，Storage 名片副本不是 2.1 关系事实来源。sub-first 的 Stage PUT 保存的文件即为 NS 当前权威名片，但关系未形成共识；NS 主动同步仍须待 fresh 验收清除 pending。Storage 对 `default/agent.md` 的普通 GET/HEAD 优先读取已有副本，不保证与 NS 强一致；仅该路径确实缺失时回源 NS，通过 multi-v1 GET 获取完整原始签名文件，并以 `expected_version=0` 的 CAS 保存公开、无过期时间的字节副本。该缺失回源缓存可包含 NS 普通 GET 返回的 pending 候选，但不清除 NS pending、不确认关系共识，也不授予 owner 权限。
 
 ### 1.1 self-owner
 
@@ -41,7 +43,7 @@ Storage 必须原子发布完整 `owner.md`：读取者只能看到完整旧版
 
 `agent.md` 发布保留原 ETag 条件：已有文件使用 `If-Match`，首次创建使用 `If-None-Match: *`。owner 发布前重新核对当前完整 `owner.md` 原文、摘要和存在性，使用规范上传会话原子写入完整文件，不先删除再创建；HTTP PUT 使用 create 返回的会话 URL，complete 携带同一 `session_id`，create/complete 沿用同一既有 `expected_version` 发布条件，不增加 Storage 路径修订或哈希条件接口。
 
-协议客户端发起删除前重新核对当前 NS `agent.md` 及本任务保存的 owner 完整原件；目标原文、摘要或当前关系已变化时停止旧清理。owner_aid 经其它存储入口执行的真实删除仍按第 4.2 节确认解绑。
+协议客户端删除 `owner.md` 前须精确核对本任务完整原件，并将最后读取到的当前对象 `version` 作为 `expected_version` 提交，使版本比较与删除原子完成；版本变化返回 Storage `-32009`，不得改用新版本盲重试或降级为无条件删除。owner_aid 经其它存储入口执行的真实删除仍按第 4.2 节确认解绑。
 
 Storage 须在文件、父目录、移动、重命名及自动清理等所有能改变规范路径对象的入口执行 owner 限制；ACL、token 或目录授权不得赋予第三方修改、删除 `owner.md` 的能力。
 
@@ -53,7 +55,9 @@ Storage 须在文件、父目录、移动、重命名及自动清理等所有能
 
 Group 使用 `group.transfer_owner` → `group.complete_transfer` 的两阶段转移；Org 使用既有 `org.lifecycle.transfer` → `org.lifecycle.transferAccept`。两者都必须真正 rekey，使证书及公钥指纹变化，旧身份材料不再授权当前操作，新材料归新 owner 持有；Org 的 rekey 与 owner CAS 顺序保持其专属 0.8 契约。创建时实体身份公私钥及证书由初始 owner 持有，业务服务不保存实体私钥。解散后不再存在可用 owner 授权，旧身份材料和待上传文件不能继续鉴权或发布名片。
 
-新 SDK 发布的 Group/Org 名片必须含当前 `owner`，必须省略 `ownership`、`ownership_proof`、`ownership_release`。实体私钥生成主签，当前 owner 使用本人 token 上传，可选追加 owner 附签；Group 旧实体单签及实体身份上传持续兼容，Org 不开放该旧入口，见第 2.5 节。实体类型和当前 owner 必须以权威身份及生命周期记录校验，不能只相信上传文件中的 `type/owner`，也不能通过改类型绕过已有普通 Ownership 锁。
+新 SDK 发布的 Group/Org 名片必须含当前 `owner`，必须省略 `ownership`、`ownership_proof`、`ownership_release`。实体私钥生成主签，当前 owner 使用本人 token 上传，可选追加 owner 附签；Group 旧实体单签及实体身份上传持续兼容，Org 不开放该旧入口，见第 2.5 节。实体类型和当前 owner 必须以权威身份及生命周期记录校验，不能只相信上传文件中的 `type/owner`。
+
+Org 生命周期向 CA 可信登记权威 Org 类型；分类只标识 AID 类型，不保存 owner 关系。Org 创建提交前完成登记，恢复时含 dissolved 的存量记录每批最多 256 条登记，全部成功后才持久标记分类回填完成。初签、轮换和导入不得覆盖已登记 Org 类型，Org 证书沿用 `signing` purpose。NS 仅在 CA 明确返回分类完成时将未登记的 normal 身份按普通主体处理；回填未确认时保留保守生命周期核验，Org 或 CA 故障不能降为普通身份。完成后普通主体 PUT 不再逐次查询 Org；Org 自身仍执行其生命周期校验。
 
 ## 2. 声明与文件签名
 
@@ -182,11 +186,15 @@ signature: <严格Base64编码的DER签名>
 
 现代上传使用当前 owner 的有效 token，无需实体登录；不再生成或强制实体专用 `AUN-AGENTMD-OWNER-AUTHORIZATION` V2 头。token 证明使用了该有效凭据，不证明本人操作，也不替代离线 owner 附签。普通 Ownership 既有 V1 兼容授权不因此变更。Group 始终兼容当前实体证书单签、实体身份上传的旧流程，仍执行生命周期、证书和文件 CAS 检查；Org 不开放该旧入口。
 
+旧0.5.19保留独立的 owner 主签 V2 兼容入口：请求无 multi-v1，文件仅一块主签，显式 signer_aid 等于正文 owner 且不同于实体 aid，正文 owner/entity_cert_fingerprint 完整合法。原 marker 可为裸或已有 tag，不能据 marker、UA 或尾签时间证明客户端版本。须有当前 owner token、原 `AUN-AGENTMD-OWNER-AUTHORIZATION` V2 授权和原 HTTP 条件；严格核对 target、uploader、完整原文摘要、实体当前指纹、owner 证书指纹、nonce、±300秒授权窗口及签名，并核对当前权威类型、owner、状态和实体代际，按完整快照 CAS 提交。该例外证明 owner 对原件的授权，不证明持有实体私钥；现代 multi-v1 上传仍必须实体主签。更早 Group 实体身份旧入口不因此增加 V2 要求。
+
+当前 fresh 及 Storage 副本验证识别这种单块 owner 主签原件，核对当前权威 owner/实体代际和完整签名，不要求读取时提供未持久化的 V2 请求头。公开历史 verified 下载仅按正文 owner、显式 signer 及其历史证书验证原字节，实体指纹字段仍严格校验格式，但不与 owner 主签证书指纹混为一谈；不要求历史 owner 或证书代际仍为当前，不据此授予当前权限。历史读取例外不扩展到多块 owner 主签文件或现代写入；实体主签的单签、双签及多签均继续接受，所有存在的签块逐一验证。
+
 NS 新鲜核对权威类型、生命周期状态、当前 owner、实体当前证书及所有签名，再允许提交。沿用既有 PKI current HTTP 查询并绕过缓存，不新增 RPC、证书链字段或关系账本。`entity_cert_fingerprint` 绑定 owner/rekey 代际，不另建数字 epoch，也不是 `relation_version`。非当前 owner 的现代上传为 `forbidden`，确定非法签名或字段为 `invalid`，旧实体证书代际为 HTTP 409 / `conflict`；生命周期、数据库或证书依赖不可用为 HTTP 503 / `unavailable`。Group 旧入口按专属兼容授权检查，不能据此开放 Org。
 
 实体 fresh GET 必须同时携带 `X-AUN-Ownership-Check: 1`、`Cache-Control: no-cache`、`X-AUN-Signature-Format: multi-v1`；NS 仅凭 Check 头绕过 LRU 并新鲜验证全部签块，仍返回 not_applicable，不进入通用 Ownership 账本。GET/HEAD 按第 3.3 节协商表示，再返回 200 或按该表示 ETag 返回 304。响应保留 `X-AUN-Ownership-Status: not_applicable`、`X-AUN-Entity-Verification-Status: current|stale`、`X-AUN-Entity-Owner-AID` 和 `X-AUN-Entity-Cert-Fingerprint`；最终解散 owner 为空，无有效证书指纹为空。owner、状态或证书代际变化时为 `stale`，新 owner 可获取旧文件的表示 ETag 后按 CAS 替换；历史文件中的 owner 不作为当前权限。确实缺失时为 404，仍携带权威 owner/指纹及 stale，无 ETag；权威依赖失败为 503，不能伪装 404。
 
-新 SDK 首次发布用 `If-None-Match: *`，更新用原表示 `If-Match`；缺条件为 428，ETag 冲突为 412。实体 pending 保留完整签名原文、原 CAS、固定 owner 与实体证书指纹；显式重试先验证原件和当前生命周期代际，仅重传原字节。转移、rekey 或解散后停止旧代际待办，不换 owner、指纹或条件重签；连接恢复不隐式 PUT。取消 V2 后不再保存或检查额外上传授权及其 ±300 秒窗口；文件签名时间与当前证书校验仍按第 2.4 节执行。原条件完整且原文及对应 ETag 已证明提交时可仅观察完成。
+新 SDK 首次发布用 `If-None-Match: *`，更新用原表示 `If-Match`；缺条件为 428，ETag 冲突为 412。实体 pending 保留完整签名原文、原 CAS、固定 owner 与实体证书指纹；显式重试先验证原件和当前生命周期代际，仅重传原字节。转移、rekey 或解散后停止旧代际待办，不换 owner、指纹或条件重签；连接恢复不隐式 PUT。新 SDK 现代上传不再保存或检查额外 V2 授权及其 ±300 秒窗口；旧 V2 兼容入口仍执行原授权检查；文件签名时间与当前证书校验仍按第 2.4 节执行。原条件完整且原文及对应 ETag 已证明提交时可仅观察完成。
 
 新 SDK 依据 NS fresh 权威 owner/指纹及独立 fresh PKI 查询交叉检查，不信 raw owner。Org 公共生命周期投影隐藏 owner，需 CAP 的 owner fields 不作为默认查询入口。公开 verified 下载逐块按签署者、尾签指纹和时间查询历史证书并验原始字节，不要求历史证书当前仍可签；不因 owner 或实体代际变化拒绝历史有效文件，历史验签不授予当前权限。确定坏签名或无效链为 `invalid`，依赖不可用为 `unavailable`。内部 fresh raw 可接收 stale 供条件替换，上传和当前授权仍执行当前生命周期及证书检查。
 
@@ -211,7 +219,7 @@ NS 不为 2.1 另建关系事实表、不可变证据表、版本上界或释放
 
 ### 3.2 判定顺序
 
-NS 处理关系检查或 `PUT /agent.md` 时，先读取数据库当前完整 `agent.md` 及 ETag，由其中的声明确定待验证的原 owner，再查询规范路径上的 owner 当前 `owner.md`，校验签署身份、AID、关系版本和动作。不能用待上传文件中的新 owner 判断旧关系，也不能只凭数据库派生字段授予权限。
+NS 处理显式关系检查或改变关系材料的 `PUT /agent.md` 时，先读取数据库当前完整 `agent.md` 及 ETag，由其中的声明确定待验证的原 owner，再查询规范路径上的 owner 当前 `owner.md`，校验签署身份、AID、关系版本和动作。不能用待上传文件中的新 owner 判断旧关系，也不能只凭数据库派生字段授予权限。
 
 新声明为 self-owner 时也不得跳过原 owner 的保护；释放或转移仍须满足下表及第 4 节的条件。
 
@@ -228,7 +236,7 @@ NS 处理关系检查或 `PUT /agent.md` 时，先读取数据库当前完整 `a
 
 确认删除时核对 Storage 服务身份、规范路径及当前权威查询结果。该结果只描述本次当前文件不存在，不建立永久释放记录。删除即解绑使 Storage 成为受信任的授权参与方；恶意 Storage 伪造权威不存在不能由文件签名识别，不能宣称协议消除了这一信任边界。
 
-所有能改变权威名片的入口均须依据两份当前签名材料执行等效关系保护，包括删除 `agent.md`、改类型、删部分字段、覆盖旧版本、同 AID 重新注册、恢复导入和旧 SDK 上传。关系材料读取或解析失败时不能按无 owner 接受关系破坏；仅普通读取和验签不受该关系结果阻断。锁校验不能仅依赖 SDK 或请求头开启。
+所有能改变权威名片的入口均须依据两份当前签名材料执行等效关系保护，包括删除 `agent.md`、改类型、删部分字段、覆盖旧版本、同 AID 重新注册、恢复导入和旧 SDK 上传。关系材料读取或解析失败时不能按无 owner 接受关系破坏；普通读取、验签及完整保留关系材料的正文更新不受该关系结果阻断。锁校验不能仅依赖 SDK 或请求头开启。
 
 请求缺少 2.1 字段、头部或来自旧 SDK 时，NS 仍依据当前材料保护已有现代声明；普通旧关系正文更新完整保留原有关系材料，不自动迁移、清空或改写关系。隔离的 legacy owner RPC 兼容流程可按旧 operation ID 激活旧 `ownership_proof`，不得通过该入口新增、替换或清除已存现代声明，也不得把旧 proof/台账结果作为 2.1 授权或共识。
 
@@ -244,21 +252,21 @@ X-AUN-Ownership-Version: <当前agent.md声明的relation_version；无声明时
 X-AUN-Ownership-Lock: locked | unlocked
 ```
 
+支持待确认绑定的 NS 对带 `X-AUN-Ownership-Check: 1` 的普通 agent GET/HEAD fresh 响应（包括 404/304）返回 `X-AUN-Ownership-Stage: 1` 能力头。客户端必须在任何 Stage PUT 前探测该头；缺失时 fail closed，不得发送 Stage。NS 还接受 `X-AUN-Ownership-Stage: 1` PUT：仅在当前关系未锁定、sub 身份及完整签名有效且原 CAS 满足时，保存 sub 自己签署的绑定候选，并在响应中返回同一能力头及 `X-AUN-Ownership-Status: pending`、`Lock: unlocked` 和候选声明版本。PUT 响应确认实际处理能力，不能替代预探测。普通共识检查将 pending 映射为 `single_sided`，不授予 owner 权限。Stage 不用于绕过稳定关系锁或替代转移验收。
+
+NS 将候选全文摘要、文档更新时间、关系版本及暂存时 owner 文件摘要保存在与名片 CAS 绑定的 `ownership_pending` 记录中。该记录是待确认流程标记，不是稳定关系或释放历史账本。fresh 检查发现 owner 文件缺失，或摘要仍等于暂存快照时，保持 pending；本轮匹配 declare 已更新、当前签名及证书有效，且复读双方原件一致后，原子清除 pending 并验收已保存的 sub 原字节，不要求 sub 在线或再次 PUT。依赖失败、材料变化或候选被替换时不能沿用旧验收结果。
+
 释放后，NS 可以保留仍含旧 owner 字段的原始 `agent.md`，等待 sub_aid 自己更新；当前 `owner.md` 的 release 或权威不存在使旧关系不可用于授权。NS 不替 sub_aid 修改、重签文件，也不单独递增或保存释放版本。
 
 同一 sub_aid 的最终关系检查与 NS 本地文件提交必须串行，并在提交时核对当前文档 ETag；冲突的写入必须拒绝。缓存不能作为关系授权的最终依据。SDK 共识检查的总窗口为 30 秒，从首次 NS GET 发出前开始计时，覆盖首读、Storage 和证书验证及末次 NS GET；前后重新读取 owner 完整原文、摘要和存在性，两份材料或 ETag 变化以及超时均返回可重试的 `unavailable`，不能返回成功共识。
 
-NS 的数据库原子边界只包含当前 `agent.md` 文件、ETag 及可选同步投递待办；Storage 写入、CA 调用和 SDK 网络调用在边界之外。名片副本在本地持久提交后同步，失败不回滚已发布文件，恢复后按同步待办补齐副本；同步进度不证明 Ownership 关系。
-
 最终验收必须满足当前 `agent.md` ETag、上传条件、两份当前签名声明、转移期限及证书状态要求；期限及证书状态按服务端当前时间判定。材料须处于服务端本次验证时限内，文件变化或材料超时后，先前验收结果不得用于提交。
 
-NS 与业务执行端均以本次最终授权验收时点裁决在途请求，并记录该时点及使用的材料。owner 发布 release 或撤回转移授权后，新鲜检查须使用当前材料；已在验收中的请求以 NS 实际提交结果为准。本协议不提供跨 Storage 的一致快照、全局事务或撤回瞬间使所有在途请求失效的保证。
-
-新 SDK 发布及 2.1 关系、现代实体格式写入均须携带条件：已有文件使用原 `If-Match`，首次创建使用 `If-None-Match: *`；缺少条件返回 428，声明关系版本不匹配或文档 ETag 冲突的写入必须拒绝。NS 兼容旧客户端普通及实体旧格式请求缺少新 Header/CAS，但必须在数据库事务内以服务端原子 CAS 核对当前文件快照，并验证适用的当前双文件关系，不得绕过 2.1 关系保护；Group 旧实体上传入口持续兼容，但不得绕过当前生命周期或存储 CAS。SDK 恢复须先确认本地持久保存的原上传条件完整，再核对远端完整文件；缺少原条件时保留原待办及错误，即使远端完整字节和 ETag 相同也不能自动清除待办。
+新 SDK 发布及 2.1 关系、现代实体格式写入均须携带条件：已有文件使用原 `If-Match`，首次创建使用 `If-None-Match: *`；缺少条件返回 428，ETag／存在性条件或提交快照冲突返回 412，声明关系版本等语义冲突可返回 409。旧 0.5.19 实体 V2 兼容入口保留其原有 HTTP 条件要求；NS 兼容更早客户端普通及实体旧格式请求缺少新 Header/CAS，但必须在数据库事务内以服务端原子 CAS 核对当前文件快照，并验证适用的当前双文件关系，不得绕过 2.1 关系保护；Group 旧实体上传入口持续兼容，但不得绕过当前生命周期或存储 CAS。SDK 恢复须先确认本地持久保存的原上传条件完整，再核对远端完整文件；缺少原条件时保留原待办及错误，即使远端完整字节和 ETag 相同也不能自动清除待办。
 
 ## 4. 关系操作与完整文件示例
 
-各方独立签署、提交自己的文件，顺序不限。NS 在本次提交或新鲜检查时验收当前材料，不维护跨方等待任务。图中各方分支之间不连线，虚线表示 NS 读取 Storage；编号用于定位示例，不规定跨方调用顺序。
+各方独立签署、提交自己的文件；NS 始终以当前双文件及条件提交验收关系。sub 发起的绑定可以按第 3.3 节暂存 sub 候选，再由 owner 发布本轮声明并触发 fresh 验收；owner 发起的绑定须先 fresh 确认当前无 owner 锁，再由 owner 条件发布本轮 `owner.md` 并通知 sub，sub 确认后直接条件提交 `agent.md`，不使用 Stage。NS 对 owner-first 直接提交重新检查当前关系、双方签名文件和 CAS，并在成功时建立锁；SDK 的消息同意或通知不能替代这些检查。
 
 以下 YAML 完整列出每次写入的 frontmatter；文件容器及尾部签名按第 2 节。读取、确认和删除不生成新声明文件。
 
@@ -266,9 +274,9 @@ NS 与业务执行端均以本次最终授权验收时点裁决在途请求，
 
 ### 4.1 建立关系
 
-建立关系要求当前双文件未构成需要保护的稳定关系，双方新声明的关系字段及版本一致，owner 的 `action` 为 `declare`。NS 验收 sub 上传时核对当前 owner 文件、上传文件及原 `agent.md`；成功后按 ETag CAS 原子保存 sub 的完整签名名片，不另建关系记录。
+建立关系要求 fresh 确认当前没有 owner 锁，双方新声明的关系字段及版本一致，owner 的 `action` 为 `declare`。owner 发起前必须先检查当前状态；`invalid`、`unavailable`、读取失败或无法确认基线均不能当作无锁。已有 owner 锁时不得进入绑定，只有当前 owner 可以发起解绑或转移。NS 在 sub 直接上传、owner-first 直接提交或 sub-first 待确认候选的 fresh 检查时核对当前双方文件及原 CAS；直接验收时原子保存完整签名名片，待确认验收时保留已经保存的 sub 原字节并原子清除 pending，不另建稳定关系记录。
 
-材料未齐时不提交，当前权威状态保持。
+材料未齐时不能确认稳定关系。sub-first 的带 Stage 头提交须先通过第 3.3 节能力预检；NS 可保存候选并返回 `pending/unlocked`。owner-first 不使用 Stage：owner 的条件 `owner.md` 发布后，sub 按原 NS ETag/If-None-Match 条件直接提交匹配的 `agent.md`；普通无 Stage 提交遇到 owner 材料缺失或不匹配时拒绝，不保存为 pending。拒绝本身不改变关系；owner 可按 Storage `expected_version` 原子条件删除本任务发布的 `owner.md`，版本冲突时停止清理。sub-first 拒绝后仅由 sub 对仍 pending、原文／摘要／ETag 精确匹配的本轮候选条件清理，不能覆盖已验收或已替换的文件。
 
 当前无 owner 的 `agent.md`：
 
@@ -315,17 +323,20 @@ ownership:
 
 ```mermaid
 flowchart TB
-  subgraph P[各方独立执行：任意先后，可重复]
+  subgraph P[owner-first：各方各发布一次文件]
     direction LR
-    S[sub 自签提交 agent.md]
-    O[owner 自签发布 declare owner.md]
+    Q[owner fresh 确认当前无 owner 锁]
+    O[owner 自签条件发布 declare owner.md]
+    S[sub 验证通知并同意，自签条件提交 agent.md]
+    Q --> O
+    O -->|bind.request| S
   end
   S --> N[NS 验收本次提交]
   O -. NS 读取 Storage 当前声明 .-> N
   L[NS 当前签名 agent.md 与 ETag] --> N
   N --> C{无锁、双方签名、AID、目标版本及 ETag 均匹配吗}
-  C -->|是| A[按 ETag CAS 保存签名 agent.md]
-  C -->|否| R[本次不提交，本端后续独立重试]
+  C -->|是| A[按 ETag CAS 保存签名 agent.md，建立锁并排队同步副本]
+  C -->|否| R[本次不提交，按权威现状恢复或停止旧任务]
 ```
 
 ### 4.2 解绑
@@ -361,7 +372,7 @@ version: 1.0.0
 
 ```mermaid
 flowchart TB
-  subgraph P[各方独立执行：任意先后，可重复]
+  subgraph P[各方独立执行]
     direction LR
     O[owner 自签发布 release]
     S[sub 独立检查或提交自签清理文件]
@@ -532,7 +543,7 @@ ownership:
     declared_at: 1791523260
 ```
 
-NS 保存新签名文件但不增加关系版本，原 owner 的 `owner.md` 不变；清除或替换稳定关系字段的普通上传按第 3.2 节拒绝。
+NS 保存新签名文件但不增加关系版本，原 owner 的 `owner.md` 不变；清除或替换稳定关系字段的普通上传按第 3.2 节拒绝。 本次正文更新不查询 owner Storage 或重新判断关系是否有效；关系依赖不可用时仍按当前名片原件及 ETag 验收。
 
 ### 4.5 self-owner 的建立、解绑与转移