@agentunion/fastaun-browser 0.5.19 → 0.5.21

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

@@ -0,0 +1,930 @@
+# Ownership SDK 编排指南 2.1
+
+本文说明 [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. 参与方与顺序
+
+本指南的通用 Facade 只处理普通主体的 Ownership 2.1。`human` 不可声明 owner；`group/org` 的 owner 由专属创建、解散和转移维护，不创建本指南的 `owner.md`、关系锁、版本、任务或审批。通用操作对此类目标直接返回 `not_applicable`、`retryable=false`，共识 `status/code=not_applicable`，不自动转调用生命周期方法。Group 的两阶段 rekey 见 [Group RPC Manual](09-group-rpc-manual.md#grouptransfer_owner)；Org 保持 0.8 的专属先 rekey 后 owner CAS。实体名片的当前 owner 必填、实体主签、owner token 上传、可选 owner 附签与代际恢复见 [协议 §2.5](../protocol/Ownership协议定义2.1.md#25-grouporg-名片的实体主签与-owner-上传)。
+
+| 参与方 | 职责 |
+| --- | --- |
+| 应用 | 发起绑定、释放或转移；通过界面或代码策略作出本端同意、拒绝决定，保存业务审计。 |
+| sub_aid | 签署自己的 `agent.md`，使用自己的认证身份上传到 NS。 |
+| owner_aid | 签署自己的 `owner.md`，发布到自己的 Storage；主动释放或授权转移。 |
+| `new_owner`（`new_owner_aid`） | 原 owner 在转移授权中指定的新管理方；签署自己的目标 `owner.md`，发布到自己的 Storage。 |
+| NS（nameservice，名称服务） | 核验当前双文件与上传身份，以数据库事务/CAS 原子保存完整 sub 自签 agent.md，并同步名片副本；不另存关系事实表或证据事实表。 |
+| Storage（存储） | 保存 owner 的当前权威 `owner.md` 及 sub_aid 的已验收 `agent.md` 副本，提供公开读取、下载和权威对象查询；`owner.md` 仅 owner_aid 可写入、删除。 |
+| Auth / CA | 提供已有身份认证、证书及验签能力。 |
+
+`agent.md` 使用 NS 当前权威版本，验收并持久保存后由 NS 同步到 `{sub_aid}:/agent.md`，完整字节及签名保持不变；流程见第 2.3 节。
+
+`owner.md` 使用对应 owner Storage 当前权威版本，路径为 `owner_aid:/sub_aids/{sub_aid}/owner.md`；仅 owner_aid 可以写入、删除，不授予第三方写删权限。
+
+self-owner 表示 `owner_aid == sub_aid`，同一 AID 承担两个角色，可以由同一 SDK 实例分别写自己的两个文件；NS 仍按统一规则验收并投影当前关系，见第 10 节。
+
+协议不要求跨方提交顺序。本文主要流程图展示第 2.4 节的 SDK 默认编排：先完成业务审批，再依次发布所需声明、由 sub 提交，最后新鲜确认 NS 结果；各端步骤独立持久化和恢复。协议层文件操作仍允许乱序执行，NS 只在验收时检查当前材料；章节编号用于定位文件规格。
+
+| 场景 | NS 最后检查的验收条件 |
+| --- | --- |
+| 建立关系 | 当前无锁；sub 本次提交与 owner Storage 当前声明的 AID、签名和目标版本匹配，ETag 条件满足。 |
+| 转移 | 原关系受锁保护；三方材料齐全、签名有效，原 owner 指定的新 owner、目标版本、期限和 ETag 条件均匹配。 |
+| release 解绑 | 原 owner 当前 release 签名有效，指向受保护的关系版本；sub 的文件另按本方身份和 ETag 验收。 |
+| 直接删除解绑 | owner Storage 权威确认规范路径当前不存在；sub 的文件另按本方身份和 ETag 验收。 |
+| 旧文件清理 | 新鲜核验当前 release/删除或已提交转移，核对当前 NS 与本任务完整 owner 原件后删除；已观察到后续文件时停止。 |
+
+材料不齐时不提交绑定或转移。release/权威删除按两份当前材料动态判定，不另写释放终局、不改 sub 签名字节或递增版本。NS 不维护跨方审批任务；各方只签传自己的文件，SDK P2P 载荷不构成关系授权。
+
+## 2. SDK 分层与完成判断
+
+SDK 的协议文件层对应协议定义的文件签署、发布和提交操作；应用编排层在其上增加审批、P2P 协调及恢复。下列五个文件方法作为 SDK 内部实现保留，由编排器及消息处理器复用，不导出为 Facade 接口。面向应用开发者的接口统一列在第 2.4 节。
+
+| 内部方法 | 执行角色 | 本端工作与完成条件 |
+| --- | --- | --- |
+| `declareOwneraid(owner_aid)` | sub_aid | 准备自己的声明并上传；绑定及转移均以 NS 验收为准，转移须匹配原 owner 指定的目标及版本。 |
+| `declareSubaid(sub_aid)` | owner 或新 owner | 准备并发布自己的 `declare` 文件；发布成功只证明本方文件已保存。 |
+| `revokeOwneraid()` | sub_aid | 新鲜检查原 owner 已 release/删除后清理自己的文件；稳定关系存在时返回 `owner_locked`。 |
+| `revokeSubaid(sub_aid)` | 原 owner | 条件发布 release，新鲜确认后延迟条件清理；不要求 NS 独立留证。 |
+| `transferOwneraid(sub_aid, new_owner_aid)` | 原 owner | 核对当前关系，独立签署、条件发布指定目标和版本的转移授权；不依赖另外两方的目标文件。 |
+
+内部文件方法只执行本端协议步骤，不发起审批或创建编排任务；签名、上传、条件提交及验收实现由编排层复用。转移各方分别记录本端文件进度，上传及重试使用本方已签署的原始文件；原 owner 的授权不依赖目标文件先行发布或交付。
+
+共识检查先获取 NS 新鲜结果及权威 `agent.md`，读取 owner Storage 当前文件并验签，再核对 NS 当前版本、完整原文、ETag 和锁；材料变化返回可重试的 `unavailable`，不能返回 `consensus`。总窗口为 30 秒，从首次 NS GET 发出前开始，首读、证书/Storage 验证和末读均计入；超时同样为 `unavailable`。结果定义见协议第 6 节。
+
+应用区分文件已保存、NS 已确认变更、清理已完成；owner 文件发布成功不等于绑定或转移完成。内部文件发布方法只确认 Storage 保存，编排随后在通知发送前核查及完成确认等推进步骤请求 NS 新鲜检查；失败保留恢复待办。App 展示查询不构成建锁的前置条件，锁始终由当前双文件及实际读写验收判定。
+
+名片读写复用 `GET/HEAD/PUT /agent.md`；新 SDK 新鲜检查携带 `X-AUN-Ownership-Check: 1`，提交条件见第 2.1 节。Header 只选择新鲜检查与结果投影，不作为关系事实或旧客户端读取的门槛；NS 按文件格式和已存材料执行上传校验，缺头不得绕过保护。新鲜检查的 NS 响应包含：
+
+```text
+X-AUN-Ownership-Protocol: 2.1
+X-AUN-Ownership-Version: <NS当前关系版本>
+X-AUN-Ownership-Lock: locked | unlocked
+```
+
+关系事实仅有 NS 当前完整 sub agent.md 与 owner Storage 当前 owner.md。NS 保存原文、摘要、ETag 和 CAS 元数据；owner.md 保存完整原文。查询、同步和 SDK 本地任务记录不能脱离两份材料授权，不维护独立关系事实表、证据事实库或历史高水位。
+
+### 2.1 本端条件提交
+
+| 本端操作 | 提交条件及稳定结果 |
+| --- | --- |
+| 本人创建或更新普通主体 agent.md | 首次创建用 `If-None-Match: *`，已有文件用本次新鲜读取的原 `If-Match`；NS 另检查关系版本和 owner 锁。Group/Org 条件发布见协议 §2.5，不进入此关系检查。 |
+| owner / 新 owner 创建或更新 owner.md | 重新核对当前完整原文、摘要和存在性，原子发布完整文件，禁止先删后建，失败保留旧文件。 |
+| 延迟清理或本端直接删除 | 重新核对当前 NS、规范路径及本任务完整原件后删除；目标或关系变化时停止。真实授权删除仍由 NS 确认解绑。 |
+
+NS 原 ETag 条件冲突或当前 owner 文件与保存的起始原件不符时停止旧写入，核对权威现状及业务意图，不能刷新 ETag 或更换起始原件强行续写。release 的新鲜确认条件见第 6.1 节。
+
+普通名片显式上传先新鲜读取可靠 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 或解散后停止旧代际待办，不更换身份、指纹或条件重签。新 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 基线。
+
+### 2.2 NS 双材料校验与提交
+
+NS 从已存 agent.md 确定原 owner 与声明版本，新鲜核验该 owner 当前 owner.md；候选新 owner 不能决定旧保护。绑定和转移核对所需当前签名文件，release/权威删除动态返回 released，不额外持久化释放终局、不改 sub 原字节。
+
+当前单实例按 sub_aid 串行检查与提交；最终复核原 ETag/CAS、当前证书及转移期限。短数据库事务只以原 CAS 原子保存完整 sub 自签文件；Storage、CA、P2P 及副本同步位于事务外。
+
+响应 Header 的版本投影当前 agent.md 声明，无声明为 0；release/删除不递增。sub 自签清理后再绑定为 1；未清理旧声明时，仅不同 owner 的新绑定使用其可见版本加一，同 owner 必须先清理。不维护退休版本或历史最大值，旧任务必须按 operation、完整原件、摘要和原 CAS 区分，不能只比较版本数字。
+
+### 2.3 验收后的名片同步
+
+建立关系、转移、普通更新及解绑后的字段清理，均在 NS 持久保存名片后执行同步。只确认释放而未更新文件时，保留原签名名片。
+
+同步沿用 [Storage/FS 协议](../protocol/11-Storage-子协议.md) 的寻址、权限和条件写入机制，权限范围仅覆盖 `{sub_aid}:/agent.md`。对应对象参数为 `owner_aid=sub_aid`、`bucket=default`、`object_key=agent.md`；这里的 `owner_aid` 指 Storage 命名空间所属 AID。
+
+NS 按 sub_aid 串行同步当前完整签名文件，保持原始字节及签名，沿用 Storage 既有原子文件发布。写入后核对 NS 当前文档 ETag 和完整文件摘要；已变化则继续同步当前文件。普通更新不增加关系版本，不能只用关系版本判断副本是否一致。
+
+```mermaid
+flowchart TB
+    A[NS 验收 agent.md] --> B[数据库 CAS 保存完整自签名片]
+    B --> C[读取 NS 当前完整签名文件和 ETag]
+    C --> D[条件同步到 sub_aid 的 Storage 根路径 agent.md]
+    D --> E{副本与 NS 当前文件一致吗}
+    E -->|是| F[同步完成]
+    E -->|文件已变化或条件冲突| C
+    D -->|失败或中断| R[保持已验收结果，恢复后补齐当前副本]
+    R --> C
+```
+
+同步失败不回滚 NS 已验收关系；NS 恢复后从当前权威名片补齐副本。各端 SDK 仍以 NS 的新鲜结果判断关系是否完成。
+
+### 2.4 应用层 Facade：编排、审批与共识检查
+
+Ownership Facade 仅提供以下接口。应用调用编排接口发起操作，订阅本地事件并通过审批接口表达同意或拒绝，按需检查共识；文件准备、签署、提交和后续推进由 SDK 负责。以下接口及消息格式均为 2.1 的 SDK 设计契约。
+
+| Facade 方法 | 调用方 | 行为与完成依据 |
+| --- | --- | --- |
+| `bindOwneraid(owner_aid)` | sub | 请求 owner → owner 审批 → owner 发布声明 → sub 自签提交 → 确认 NS 验收；常规绑定入口。 |
+| `bindSubaid(sub_aid)` | owner | 请求 sub → sub 同意 → owner 发布声明 → sub 自签提交 → 确认 NS 验收。 |
+| `acceptOwnershipRequest(operation_id)` | 绑定接收方；转移中的新 owner 或 sub | 持久保存本端同意决定，回复发起方；只在审批阶段完成、材料匹配后推进本端文件步骤。 |
+| `rejectOwnershipRequest(operation_id, reason?)` | 绑定接收方；转移中的新 owner 或 sub | 持久保存拒绝决定，通知发起方，结束本次待审批任务。 |
+| `releaseSubaid(sub_aid)` | 原 owner | 发布 release → 新鲜动态确认 → 通知 sub 自签清理 → 延迟条件清理旧 owner 文件；任务目标版本等于当前声明版本。 |
+| `transferSubaid(sub_aid, new_owner_aid)` | 原 owner | 请求新 owner 和 sub → 收齐双方同意 → 原 owner 发布转移授权 → 新 owner 发布声明 → sub 自签提交 → 确认 NS 转移 → 条件清理旧文件。 |
+| `checkOwnershipConsensus(sub_aid?)` | 校验方 | 读取 NS 新鲜关系结果和双方当前文件，验证签名、身份、版本并给出共识结论；不创建 SDK 编排任务。 |
+
+编排器和 P2P 消息处理器调用同一组内部文件方法：绑定复用 `declareSubaid`、`declareOwneraid`；解绑复用 `revokeSubaid`、`revokeOwneraid`；转移由原 owner 复用 `transferOwneraid`，目标声明和提交复用两个 declare 方法。消息处理器继续原任务，不再次调用 Facade 发起接口创建任务。`checkOwnershipConsensus` 对应用公开，其校验实现也供编排层复用。
+
+绑定、释放、转移的发起接口先查询权威现状以固定起始版本，在发送消息、发布文件或删除等副作用前持久保存本端任务，返回 `operation_id` 和本端进度；超时可返回等待结果，由事件继续通知。审批接口关联已有任务，不创建新任务。`operation_id` 为 SDK 生成的 UUIDv4，不写入 agent.md、owner.md 或额外 NS 关系事实。同一 sub_aid 的本端修改串行推进；恢复复用原任务及已签署文件。
+
+绑定可由 sub 或 owner 发起，发起 API 表达发起方意愿，接收方通过 `ownership.request` 同意或拒绝。转移仅由 NS 当前原 owner 发起；新 owner 和 sub 分别审批，原 owner 收齐两方同意后才发布转移授权。两方审批可任意先后；任一方拒绝，原 owner 通知另一方停止本次待审批任务，不发布授权，原关系保持。
+
+三方意向共识只保存在各端 SDK 任务中，不写入协议文件或额外 NS 关系事实。sub 的同意还须落实为其自行签署、提交目标 agent.md；同意消息本身不能完成转移。
+
+审批决定限定 `operation_id`、操作、参与 AID 及起始/目标关系版本，在发送回复或发布文件前持久保存；不能用一个任务的同意批准另一目标。审批 API 仅用于待审批任务，批准后的停止按第 2.6 节处理。
+
+无界面的 sub 同样通过 `ownership.request` 接入应用层策略。应用可按操作类型、发起方、目标 owner 允许名单及本地管理策略自动判断，再明确调用同意或拒绝接口；无需显示审批界面。未配置策略、策略未给出结论或应用未处理事件时保持待审批，SDK 不默认同意。以下 TypeScript 示例中的 `policy` 由应用实现，返回 `accept`、`reject` 或 `pending`：
+
+```ts
+client.on('ownership.request', async (request) => {
+  const decision = await policy(request);
+  if (decision === 'accept') {
+    await client.acceptOwnershipRequest(request.operation_id);
+  } else if (decision === 'reject') {
+    await client.rejectOwnershipRequest(request.operation_id);
+  }
+});
+```
+
+审批通过后，SDK 可自动推进已授权且材料匹配的本端步骤，无需每一步再交互；重新签署前仍核对审批上下文和权威现状。没有匹配的本端授权时发布 `ownership.action_required`，应用决定是否继续；既有同意不允许换目标或绕过 owner 锁。
+
+释放后的自动字段清理只使用本端明确 accept、含 sub 角色、本人已签 agent 与 owner/sub/原声明完整 statement 相匹配的任务。收到 release 通知时，该原绑定／转移任务可因发布响应丢失仍 pending；无控制消息时，仅已完成历史任务的恢复路径触发自动清理。缺授权时不自动签写，发布 action_required，应用可用现有名片 API 明确清理。当前 release/删除需重新核验；清理后无声明，网络结果为 unbound/0，不能要求继续返回历史 released/v。已完成本地任务保留审批和原件，只表示当时完成，不赋予当前 owner 权限。
+
+完成判断见第 2.6 节；字段清理、Storage 名片同步及凭据交接分别跟踪，不阻塞已确认的关系结果。self-owner 中重合的角色在本地处理，一次应用决定可覆盖本端多个角色；向兼任 sub 与新 owner 的同一 AID 合并发送一个审批请求，不给自己发送 P2P 消息。
+
+### 2.5 P2P 编排消息与拦截
+
+复用加密 `message.send`，采用持久消息，不设置 volatile TTL。Message/Gateway 只传递普通 P2P 载荷；SDK 在解密后、应用 `message.received` 投递前识别并消费编排消息，再通过本地 dispatcher 通知应用。实时 push、离线 pull 和重连补拉使用同一拦截入口。需要回复时发送关联同一 `operation_id` 的 P2P 消息，不新增协议层 RPC。
+
+控制 JSON 保留解密后的原始文本用于严格校验，不能因提前解析成对象而丢失重复键或关系版本的整数词法。有效收件持久保存成功后，才能移除待解密、排序或补拉项，推进游标、标记已投递及 ACK；保存失败保留原重试来源，不转为普通应用消息或不可解密消息。
+
+现有通路可参考 [TypeScript client.ts](../../ts/src/client.ts) 的 `_sendOwnershipControl`、`_handleOwnershipMessage`、`_publishAppEvent`，以及 [Python client.py](../../python/src/aun_core/client.py) 的对应实现。2.1 仅参考其发送前持久化、统一拦截和本地事件方式，不沿用旧 proof、代签或代上传步骤，完成依据改为 NS 新鲜验收。
+
+SDK 协调载荷使用独立标识 `aun.ownership.sdk.v1`，避免被现有 `aun.ownership.v1` 处理器误执行；此版本号只标识 SDK 消息格式。所有 action 使用以下字段：
+
+| 字段 | 类型及要求 |
+| --- | --- |
+| `type` | 必填字符串，固定为 `aun.ownership.sdk.v1`。 |
+| `operation_id` | 必填 UUIDv4；同一编排各方及重试沿用同一值。 |
+| `operation` | 必填 `bind`、`release` 或 `transfer`。 |
+| `action` | 必填下表中的 action，必须与 operation 和发送方向匹配。 |
+| `sub_aid` | 必填完整小写 AID。 |
+| `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.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 任务。 |
+| `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。 |
+| `transfer.ready` | transfer：原 owner → 新 owner、sub。 | 核对原 owner 当前签名授权及本端审批；新 owner 发布自己的声明，sub 保存目标并等待材料。 |
+| `relation.confirmed` | bind/transfer：sub → 其它参与方；release：原 owner → sub。 | 新鲜查询 NS；核对任务目标后更新本端结果，已释放的 sub 可清理旧字段。 |
+| `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。
+
+按发送者、`operation_id`、action 幂等接收，同一任务的参与方和版本不能变化。重复或乱序消息先回源核对当前事实，只补本端尚未完成步骤；不能用旧提示覆盖新文件。SDK 控制类型的无效载荷、未知 action 或处理失败也由拦截器消费，不投递为普通聊天消息；有效待办须持久保存后再结束接收处理。
+
+```mermaid
+flowchart TD
+    A[完成 P2P 解密] --> B{是 SDK ownership 控制类型吗}
+    B -->|否| C[沿原路径发布 message.received]
+    B -->|是| D[SDK 拦截，核对发送者、载荷、任务和权威现状]
+    D -->|无效或版本不支持| E[消费控制消息，停止推进]
+    D -->|有效| F[持久保存本端待办并幂等处理]
+    F --> T{是待审批的绑定或转移请求吗}
+    T -->|是| Q[发布 ownership.request，由应用界面或策略判断]
+    Q -->|拒绝| V[持久保存拒绝并回复 P2P，发布 ownership.rejected]
+    Q -->|同意| P[持久保存审批，回复 P2P 并推进本端步骤]
+    T -->|否| G{下一步需要本端签署或写入吗}
+    P --> G
+    G -->|否| H[新鲜核查结果并发布本地事件]
+    G -->|是| R{审批阶段完成且前置材料就绪吗}
+    R -->|否| S[保存待办，发布进度并等待]
+    R -->|是| I{已有本端应用授权吗}
+    I -->|否| J[发布 ownership.action_required 并等待]
+    J -->|明确授权后| K[回源复核并调用本端内部文件方法]
+    I -->|是| K
+    K --> H
+```
+
+### 2.6 本地事件与完成依据
+
+应用通过现有事件订阅接口监听以下 SDK 本地事件。它们不通过 P2P 转发，也不是服务端 `event/...` 消息。公共载荷包含第 2.5 节的任务、参与 AID、起始/目标版本字段、`step` 和按本端 AID 推导的 `local_roles`（owner、sub、new_owner 中的相关角色）；请求事件另含经消息层确认的 `requester_aid`，供界面或自动策略决策。已新鲜核验时附 `relation_version`，错误附 `reason`、`retryable`。
+
+| 事件 | 何时发布 |
+| --- | --- |
+| `ownership.request` | 收到有效绑定请求或原 owner 的转移请求，提示绑定接收方，或转移中的新 owner、sub 作应用层决策。 |
+| `ownership.action_required` | 本端尚未授权下一步签署或写入，提示应用作本地决定。 |
+| `ownership.progress` | 本端文件保存、通知发送、等待对端或条件清理等阶段推进；不表示关系已成立。 |
+| `ownership.completed` | NS 新鲜结果与本任务目标一致，且本端完成相应材料核验。 |
+| `ownership.rejected` | 本端拒绝或收到有效审批拒绝；只表示本次 SDK 业务流程被拒绝。 |
+| `ownership.stopped` | 收到有效对端停止通知，或本端因当前版本/目标已被后续操作替代而停止推进；当前没有公开取消 Facade。 |
+| `ownership.error` | 无法推进或核验；可重试错误保留当前稳定结果及待办。 |
+
+绑定、转移的 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 一致且当前证书验证有效确认，均不得补造旧条件。
+
+事件可能因恢复再次发布，应用按 `operation_id`、事件名及 step 幂等处理；已持久保存的审批结论不因重复事件而重新决定。审批回复按各审批方分别关联尚待决定的请求；收齐同意前，任一尚未决定的审批方拒绝仍结束任务。迟到拒绝不能覆盖该方已保存的同意或 NS 已验收结果。停止任务仅停止本端后续推进；已发布的转移授权须由原 owner 按第 7.7 节撤回，已提交关系保持。旧文件清理使用第 2.1 节的对象条件，不用删除 owner.md 表示取消。
+
+## 3. YAML 与签名约定
+
+下列 YAML 块完整列出每次写入的 frontmatter。实际文件以独占一行的 `---` 包裹 frontmatter，可添加 Markdown 正文，最后追加文件签名。其它业务字段和正文原样保留；完整字段类型和限制 见协议第 2 节。
+
+agent.md 与 owner.md 共用 Store.sign/verify document 模式及各 SDK 唯一签验 core；通用容器不判断 YAML，业务调用者仍检查主签身份、Schema、资源和授权。连续尾块的每块签署此前完整 prefix，附签 signer_aid 必填且全块验签，总尾区 2048 字节，见协议 §2.4。
+
+所有文件按原始 UTF-8 字节签名。签名覆盖尾部开始标记之前的全部内容，不能在签名后重新序列化 YAML 或转换换行。ownership 不另设业务签名；附签仅增加签署证据，不改变主签角色。
+
+sub 的 `agent.md` 签名块如下，也兼容原来的 `AUN-SIGNATURE` 标识：
+
+```text
+<!-- AUN-SIGNATURE-AGENTMD-V2
+cert_fingerprint: sha256:<64位小写hex>
+public_key_fingerprint: sha256:<64位小写hex>
+timestamp: <Unix秒正整数>
+signature: <严格Base64编码的DER签名>
+-->
+```
+
+owner 的 `owner.md` 使用同样的签名字段，采用 `AUN-SIGNATURE-OWNERSHIP-V2`，也兼容 `AUN-SIGNATURE`：
+
+```text
+<!-- AUN-SIGNATURE-OWNERSHIP-V2
+cert_fingerprint: sha256:<64位小写hex>
+public_key_fingerprint: sha256:<64位小写hex>
+timestamp: <Unix秒正整数>
+signature: <严格Base64编码的DER签名>
+-->
+```
+
+`public_key_fingerprint` 可省略，其余字段必填；值由本方身份生成，验证时核对证书、AID 和完整文件签名。新验收以服务端当前时间检查证书有效期、吊销及可签名状态，不能用尾部 timestamp 代替当前状态检查。尾部 timestamp 不在正文签名输入内，历史授权依据被签署的声明时间、证书验证材料和服务端验收记录。
+
+示例初始声明版本为 0，绑定后为 1。第 6 节 release/删除不改版本，旧声明在时仍为 1；sub 自签清理后无声明，投影为 0，再绑定使用 1。第 7 节直接转移使用 1→2；版本是当前材料的投影，不是独立历史计数器。
+
+## 4. 建立关系
+
+常规绑定由 sub 应用调用 `bindOwneraid`。owner 批准后发布自己的声明，再由 sub 自签提交；拒绝时结束本次 SDK 任务。
+
+```mermaid
+flowchart TB
+    A[sub 应用调用 bindOwneraid] --> B[sub SDK 新鲜检查无锁及版本 v，保存绑定意图]
+    B --> C[持久保存并发送 P2P bind.request 给 owner]
+    C --> D[owner SDK 拦截并核对，发布 ownership.request]
+    D --> E{owner 应用同意还是拒绝}
+    E -->|拒绝| R[持久记录拒绝并发送 bind.reject，双方发布 ownership.rejected]
+    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]
+    N -->|材料不足或冲突| W[保存本端待办，按当前事实恢复]
+    K --> L[sub 新鲜核查共识及本次文件后发布 ownership.completed]
+    K --> M[NS 按第 2.3 节同步 Storage 名片副本]
+    L --> O[向 owner 发送 P2P relation.confirmed]
+    O --> P[owner SDK 拦截并新鲜核查后发布 completed]
+```
+
+### 4.1 读取当前无 owner 的文档
+
+NS 当前版本为 `0`、锁为 `unlocked`，已有的 `agent.md` 如下：
+
+```yaml
+aid: subject.agentid.pub
+name: Subject AID
+type: agent
+version: 1.0.0
+```
+
+双方依据当前版本准备关系版本 `1`。仅看到本地无 owner 文件不足以开始绑定，必须先完成 NS 新鲜检查。
+
+### 4.2 owner 发布自己的声明
+
+owner 签署、发布 `owner.agentid.pub:/sub_aids/subject.agentid.pub/owner.md`：
+
+```yaml
+owner_aid: owner.agentid.pub
+sub_aid: subject.agentid.pub
+ownership:
+  statement:
+    version: 2
+    declaration_id: 660e8400-e29b-41d4-a716-446655440000
+    owner_aid: owner.agentid.pub
+    sub_aid: subject.agentid.pub
+    relation_version: 1
+    declared_at: 1791523200
+  action: declare
+```
+
+按第 2.1 节发布并保存完整原件与摘要，成功只确认本方文件已保存；响应丢失按第 8 节恢复。
+
+### 4.3 sub 提交自己的声明
+
+sub 签署、上传自己的完整 `agent.md`：
+
+```yaml
+aid: subject.agentid.pub
+name: Subject AID
+type: agent
+version: 1.0.0
+owner: owner.agentid.pub
+ownership:
+  statement:
+    version: 2
+    declaration_id: 550e8400-e29b-41d4-a716-446655440000
+    owner_aid: owner.agentid.pub
+    sub_aid: subject.agentid.pub
+    relation_version: 1
+    declared_at: 1791523260
+```
+
+NS 验收成功后以 CAS 保存完整 sub 自签 agent.md，当前声明版本为 1；owner.md 保持在 owner Storage。两方声明标识和时间可不同，AID 与关系版本须匹配。
+
+材料未齐时 sub 提交不改变权威名片；本端保留文件，后续独立重试。
+
+绑定中断及响应丢失的恢复见第 8 节。
+
+### 4.4 owner 发起绑定
+
+owner 应用调用 `bindSubaid` 时，先向 sub 发出绑定请求，由 sub 同意或拒绝。owner 只有收到有效同意后才发布自己的 owner.md；sub 已保存的同意决定允许后续在材料匹配时自签提交。
+
+```mermaid
+flowchart TB
+    A[owner 应用调用 bindSubaid，保存意图及 NS 版本]
+    A --> B[向 sub 发送 P2P bind.request]
+    B --> C[sub SDK 拦截，发布 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 验收与确认步骤]
+```
+
+## 5. owner 锁下的普通更新
+
+sub 可以更新名称、正文等，重新签署完整文件；当前 `owner` 和 `ownership.statement` 必须完整保持。以下是允许的更新：
+
+```yaml
+aid: subject.agentid.pub
+name: Updated Subject AID
+type: agent
+version: 1.0.1
+owner: owner.agentid.pub
+ownership:
+  statement:
+    version: 2
+    declaration_id: 550e8400-e29b-41d4-a716-446655440000
+    owner_aid: owner.agentid.pub
+    sub_aid: subject.agentid.pub
+    relation_version: 1
+    declared_at: 1791523260
+```
+
+```mermaid
+flowchart TD
+    A[sub 提交自己的新 agent.md] --> B[NS 读取当前权威文档和保护记录]
+    B --> C[查询原 owner Storage 当前文件]
+    C --> D{原关系仍稳定吗}
+    D -->|是| E{完整保留关系字段吗}
+    E -->|是| F[保存新文档，关系版本不变]
+    E -->|否| G[拒绝，返回 owner_locked]
+    D -->|已 release 或确认删除| H[动态确认 released 后验收候选]
+    D -->|无法确认或文件无效| I[拒绝本次关系变更，保留保护记录]
+```
+
+普通更新无需 owner 客户端在线。所有名片入口仍受旧关系锁保护，不能以新文件中的 owner 判断旧锁。
+
+## 6. 解绑与再次绑定
+
+### 6.1 推荐流程：release 后延迟删除
+
+原 owner 应用调用 `releaseSubaid`。释放确认、通知 sub、两端文件清理分别保存进度；sub 在线状态不影响 NS 确认。
+
+```mermaid
+flowchart TB
+    A[原 owner 应用调用 releaseSubaid] --> B[SDK 新鲜核对旧关系及版本 v]
+    B --> C[SDK 内部 revokeSubaid：自签条件发布 release]
+    C --> D[请求 NS 新鲜检查]
+    D --> N[NS 动态核验 release，声明版本仍 v]
+    D -->|暂不可确认| W[保留 release 和待办，恢复后重试检查]
+    W --> D
+    N --> E[原 owner 发布 ownership.completed]
+    E --> F[持久保存并发送 P2P relation.confirmed]
+    F --> G[sub SDK 拦截，确认 NS 释放事实及本端清理授权]
+    G --> H[sub SDK 内部 revokeOwneraid：自签条件提交清理后的 agent.md]
+    H --> I[NS 保存名片并单独同步 Storage 副本]
+    I --> J[sub 发送 P2P sub.cleaned，本地更新清理进度]
+    J --> K[原 owner 拦截后回源核对，更新清理进度]
+    E --> L[原 owner 依据确认事实条件延迟删除旧 release]
+```
+
+有效 release 发布后，旧关系不能通过新鲜 owner 授权；该判断由当前两份材料得出。NS 不保存不可逆释放终局，sub 离线不影响本次 released 结果；后续读写须重新核验当前材料与 CAS。
+
+步骤 1：原 owner 按第 2.1 节条件覆盖原路径的 release `owner.md`：
+
+```yaml
+owner_aid: owner.agentid.pub
+sub_aid: subject.agentid.pub
+ownership:
+  statement:
+    version: 2
+    declaration_id: 770e8400-e29b-41d4-a716-446655440000
+    owner_aid: owner.agentid.pub
+    sub_aid: subject.agentid.pub
+    relation_version: 1
+    declared_at: 1791523800
+  action: release
+```
+
+步骤 2：新鲜检查核验两份当前材料并返回 released、版本 1、unlocked；sub 原签名文件字节不变，不保存额外释放事实或证据表。
+
+步骤 3：sub 自己清理、签署和上传以下 `agent.md`：
+
+```yaml
+aid: subject.agentid.pub
+name: Subject AID
+type: agent
+version: 1.0.0
+```
+
+字段清理由 sub 自签并使用原 ETag 提交；清理后无声明，版本投影为 0。当前 release/权威删除未经确认时不允许借清理绕过原关系。
+
+步骤 4：延迟删除前重新核对当前 NS 与本任务已保存的 release 完整原件、摘要；当前路径已不是该原件时停止清理，不能仅等待固定时长。sub 已自签清理时当前关系为 unbound/0，不要求 NS 继续返回历史 released。
+
+### 6.2 直接删除也等同于解绑
+
+```mermaid
+flowchart TB
+    subgraph P[各方独立执行：任意先后，可重复]
+        direction LR
+        O[原 owner 独立删除自己的 owner.md]
+        S[任一方独立检查或 sub 提交自签清理文件]
+    end
+    O --> T[原 owner Storage 当前对象状态]
+    S --> N[NS 验收本次检查或提交]
+    T -. NS 权威查询规范路径 .-> N
+    L[NS 当前完整 agent.md 与 CAS] --> N
+    N --> C{Storage 权威确认当前文件不存在吗}
+    C -->|是| A[动态返回 released；声明版本仍 v]
+    C -->|仍存在| K[按当前双文件处理]
+    C -->|超时、权限错误或非权威 404| R[返回 unavailable，保护保留]
+    A --> F[本次 sub 清理文件单独验收；也可后续独立清理]
+```
+
+删除后路径无 YAML，不创建 action: delete 或空文件。NS 动态判定 released，原声明版本仍为 1；不保存独立删除终局。owner.md 仅 owner 可写删，保护覆盖 ACL/token、父目录、移动、重命名及自动清理旁路。
+
+权威确认须核对 Storage 服务身份、owner 命名空间及规范路径，绕过过期正向、负向缓存。网关或缓存 404、错误路径、超时、5xx、权限错误、元数据不一致、目录迁移和恢复未完成均不能当作删除；签名无效也不构成释放。公开下载能力不可用时，可使用该 Storage 已有的权威对象查询能力确认。确认真实删除后必须允许解绑，不要求补发 release，也不能继续等待已确认删除的文件。
+
+sub 清理时自行签署、上传：
+
+```yaml
+aid: subject.agentid.pub
+name: Subject AID
+type: agent
+version: 1.0.0
+```
+
+清理后当前 agent.md 无声明，版本投影为 0。Storage 权威不存在仍须核对服务、命名空间、规范路径及当前查询结果；下载失败不等于删除。
+
+### 6.3 解绑后再次绑定
+
+本例先确认 sub 已自签清理，当前无声明，版本为 0；双方重新签署版本 1 的新声明，并使用本次新鲜 CAS。若旧声明仍在但已 release/权威删除，仅不同 owner 的新绑定以当前可见版本 1 为基数、目标为 2。同 owner 再次绑定必须先由 sub 按现有授权清理旧声明，再发布新 declare；否则覆盖同一路径的 release 会丢失确认旧关系已释放的唯一当前材料。SDK 在创建 bind 任务、发送消息或写入前返回 conflict/action_required，提示应用先清理，不新增自动编排。数字可能重用，必须同时核对完整声明、原文摘要和 ETag，不能复用旧任务原件。
+
+```yaml
+owner_aid: next-owner.agentid.pub
+sub_aid: subject.agentid.pub
+ownership:
+  statement:
+    version: 2
+    declaration_id: bb0e8400-e29b-41d4-a716-446655440000
+    owner_aid: next-owner.agentid.pub
+    sub_aid: subject.agentid.pub
+    relation_version: 1
+    declared_at: 1791524400
+  action: declare
+```
+
+sub 自己签署、提交对应文件：
+
+```yaml
+aid: subject.agentid.pub
+name: Subject AID
+type: agent
+version: 1.0.0
+owner: next-owner.agentid.pub
+ownership:
+  statement:
+    version: 2
+    declaration_id: cc0e8400-e29b-41d4-a716-446655440000
+    owner_aid: next-owner.agentid.pub
+    sub_aid: subject.agentid.pub
+    relation_version: 1
+    declared_at: 1791524460
+```
+
+NS 验收后锁定新关系，版本为 `1`。这是原 owner 主动释放之后的新绑定；指定目标的连续转移使用下一节流程。
+
+## 7. transfer_owner：连续转移
+
+本节独立从第 4 节的稳定版本 `1` 出发。原 owner 的 Storage 授权仍声明旧关系；只有 NS 验收完整材料时，才把权威名片和锁切换到新 owner。
+
+原 owner 应用调用 `transferSubaid`。先取得原 owner 发起意愿、新 owner 与 sub 的同意；意向达成后再推进文件。审批不增加协议字段，最终完成仍取决于三方签名材料及 NS 验收。
+
+```mermaid
+flowchart TB
+    A[原 owner 应用调用 transferSubaid] --> B[新鲜核对原关系及版本 v，持久保存转移意图]
+    B --> C[向新 owner 发送 P2P transfer.request]
+    B --> S[向 sub 发送 P2P transfer.request]
+    C --> D[新 owner SDK 核对请求，发布 ownership.request]
+    S --> T[sub SDK 核对请求，发布 ownership.request]
+    D --> E{新 owner 应用同意还是拒绝}
+    T --> U{sub 应用或自动策略同意还是拒绝}
+    E -->|同意| F[持久保存同意并回复 transfer.accept]
+    U -->|同意| V[持久保存同意并回复 transfer.accept]
+    E -->|拒绝| R[回复 transfer.reject；原 owner 通知另一方停止，原关系保持]
+    U -->|拒绝| R
+    F --> J{原 owner 收齐两方同意且原关系仍匹配吗}
+    V --> J
+    J -->|尚未收齐| W[保留待审批任务，不发布授权]
+    J -->|目标或版本已变化| X[停止旧任务]
+    J -->|是| G[原 owner SDK 内部 transferOwneraid：自签条件发布指定目标授权]
+    G --> H[向新 owner 和 sub 发送 P2P transfer.ready]
+    H --> I[新 owner 核对授权及本端同意，自签发布目标 owner.md]
+    H --> Y[sub 核对授权及本端同意，等待新 owner 声明]
+    I --> K[向 sub 发送 P2P owner.ready]
+    K --> L[sub 回源核对当前授权、目标声明及本端审批]
+    Y -->|目标声明就绪后| L
+    L --> Z[sub SDK 内部 declareOwneraid：自签条件提交目标 agent.md]
+    Z --> N[NS 最终核验三方材料、目标、版本、期限及 owner 文件原文和存在性]
+    N -->|通过| M[CAS 提交完整目标自签名片，声明 v+1]
+    N -->|材料不足或冲突| Q[保存本端待办，按当前权威事实恢复]
+    M --> O[sub 新鲜确认共识及本次文件，发布 completed]
+    M --> P[NS 按第 2.3 节同步 Storage 名片副本]
+    O --> AA[向原 owner 和新 owner 发送 P2P relation.confirmed]
+    AA --> AB[两端各自回源核查后发布 completed，原 owner 条件清理旧文件]
+```
+
+默认 SDK 编排先取得三方意愿，再按图先发布第 7.4 节的原 owner 授权、再发布第 7.2 节的目标声明、最后由 sub 按第 7.3、7.5 节提交。新 owner 与 sub 不向原 owner 提供目标文件或摘要；审批阶段无协议写入，拒绝保持原关系。协议层允许文件乱序发布，NS 不等待 SDK 审批或通知，只验收当前材料。
+
+验收失败不保存目标文件；有效 release 或权威删除仍按解绑规则处理。旧文件仅依据 NS 已确认转移事实清理，见第 7.6 节。
+
+### 7.1 读取旧关系
+
+三方核对 NS 仍为旧 owner、版本 `1`，保存 ETag，目标版本为 `2`；旧关系已释放或被替代时停止旧任务。
+
+### 7.2 新 owner 准备自己的目标文件
+
+新 owner 签署并保存以下文件，发布到 `next-owner.agentid.pub:/sub_aids/subject.agentid.pub/owner.md`：
+
+```yaml
+owner_aid: next-owner.agentid.pub
+sub_aid: subject.agentid.pub
+ownership:
+  statement:
+    version: 2
+    declaration_id: 880e8400-e29b-41d4-a716-446655440000
+    owner_aid: next-owner.agentid.pub
+    sub_aid: subject.agentid.pub
+    relation_version: 2
+    declared_at: 1791524100
+  action: declare
+```
+
+默认 SDK 在本端同意且收到 `transfer.ready`、核对当前授权后发布；协议层不限制与原 owner 授权的先后。验收时此文件必须是 Storage 当前版本，声明指定的关系版本 `2`，并由新 owner 自己签署。
+
+### 7.3 sub 准备自己的目标文件
+
+默认 SDK 在 sub 已同意、原 owner 授权及新 owner 声明均已核对后，签署并持久保存以下完整 `agent.md`，无需交给原 owner 验证：
+
+```yaml
+aid: subject.agentid.pub
+name: Subject AID
+type: agent
+version: 1.0.0
+owner: next-owner.agentid.pub
+ownership:
+  statement:
+    version: 2
+    declaration_id: 990e8400-e29b-41d4-a716-446655440000
+    owner_aid: next-owner.agentid.pub
+    sub_aid: subject.agentid.pub
+    relation_version: 2
+    declared_at: 1791524160
+```
+
+本地保存不改变 NS 旧关系；提交与重试使用本方已签署的原始文件，见第 7.5 节。
+
+### 7.4 原 owner 签署转移授权
+
+默认 SDK 先确认已收齐新 owner 与 sub 的同意，再核对当前旧关系、指定目标及版本，读取原路径完整文件、摘要和存在性，签署并原子发布自己的 `owner.md`。本步骤不要求第 7.2、7.3 节的目标文件先行准备或发布，审批结论不写入文件：
+
+```yaml
+owner_aid: owner.agentid.pub
+sub_aid: subject.agentid.pub
+ownership:
+  statement:
+    version: 2
+    declaration_id: aa0e8400-e29b-41d4-a716-446655440000
+    owner_aid: owner.agentid.pub
+    sub_aid: subject.agentid.pub
+    relation_version: 1
+    declared_at: 1791524220
+  action: transfer_owner
+  transfer:
+    new_owner_aid: next-owner.agentid.pub
+    target_relation_version: 2
+    expires_at: 1791527820
+```
+
+此声明仍确认原版本 `1` 的旧关系，授权将该关系转移到指定新 owner、目标版本 `2`。有效期只限制执行转移；过期不会自动解绑旧关系。
+
+### 7.5 sub 上传，NS 决定是否切换
+
+sub 使用自己的身份上传第 7.3 节自行签署的完整文件。NS 按第 1 节条件验收当前三方材料，并按第 2.2 节完成提交前的最终复核。
+
+成功后以数据库事务/CAS 保存完整 sub 自签名片及文档元数据；关系锁和版本 `2` 由当前双材料投影，不独立保存关系证据事实。再次读取只能缩小竞争窗口；NS 不提供跨 Storage 一致快照或全局事务，在途请求以最终验收和实际提交结果为准，不承诺撤回瞬间使所有在途请求失效。
+
+转移提交前，目标文件更新须由本方重新签署，并保持授权指定的新 owner 和目标关系版本，无需重新取得原 owner 对文件的批准；条件冲突按第 2.1 节核对现状，不能自动覆盖。
+
+### 7.6 确认与旧文件清理
+
+NS 当前名片是本次验收的 sub 签名文件，新 owner 的声明以其 Storage 当前版本为准，关系版本为 `2`；确认完成时不重新签署文件。
+
+sub 新鲜确认后向原 owner、新 owner 发送 `relation.confirmed`，各方各自核查 NS 结果后发布完成事件。原 owner 按第 2.1 节延迟清理旧文件；清理失败不影响新关系。恢复见第 8 节。
+
+停止本地任务不撤回已发布授权；撤回按第 7.7 节，已提交后的反向转移须新 owner 重新授权。
+
+### 7.7 撤回尚未提交的转移授权
+
+原 owner 新鲜确认 NS 仍为旧 owner、版本 `1`，核对当前转移完整原件，按第 2.1 节发布以下 declare 文件，省略 transfer。不能删除文件表示取消（删除即解绑）；有待确认 release 或 NS 后续版本时停止旧写入。
+
+```yaml
+owner_aid: owner.agentid.pub
+sub_aid: subject.agentid.pub
+ownership:
+  statement:
+    version: 2
+    declaration_id: bc0e8400-e29b-41d4-a716-446655440000
+    owner_aid: owner.agentid.pub
+    sub_aid: subject.agentid.pub
+    relation_version: 1
+    declared_at: 1791524300
+  action: declare
+```
+
+```mermaid
+flowchart TB
+    subgraph P[各方独立执行：撤回与目标提交可能竞争]
+        direction LR
+        O[原 owner 自签条件覆盖为 declare]
+        S[sub 可能已有目标提交在途]
+    end
+    O --> T[原 owner Storage 原子替换当前文件]
+    O -->|本端确认发布后| Q[请求 NS 新鲜检查]
+    S --> N[NS 串行验收提交或检查]
+    Q --> N
+    T -. NS 读取当前完整文件 .-> N
+    L[当前完整权威名片与 CAS] --> N
+    N --> K{权威状态可确认吗}
+    K -->|否| R[保留材料，不认定撤回完成]
+    K -->|是| C{NS 已提交目标转移吗}
+    C -->|是| A[新关系保持；反向转移须新 owner 授权]
+    C -->|否| D{仍是原 owner 和版本且当前文件为 declare 吗}
+    D -->|是| B[原锁保持，本次旧目标已无授权]
+    D -->|否| V[停止旧任务，按最新权威结果处理]
+```
+
+覆盖冲突按第 2.1 节停止旧写入。覆盖成功仍须新鲜查询 NS：已转移则保持新关系；仍为原关系且当前 owner 文件为 declare 时，本次目标已无当前授权。本方覆盖不能作为回滚证明。
+
+## 8. 崩溃与响应丢失后的恢复
+
+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 当前文件]
+    B --> C{权威结果可确认吗}
+    C -->|否| D[保留本端文件与待办，等待恢复]
+    C -->|是| E{当前事实与原任务是否匹配}
+    E -->|已完成本次提交| F[确认本端完成，补发有效通知并条件清理]
+    E -->|原版本仍在且任务有效| G[恢复待审批或未完成步骤，仅重发仍有效的消息]
+    E -->|原关系已释放| H[sub 可清理旧字段，转移任务停止]
+    E -->|已有后续版本或目标不符| I[停止旧任务写入和删除]
+```
+
+本端保存 `operation_id`、操作与参与方、起始/目标版本、本端审批及已收到的各方决定、待发送 P2P 消息、完整签名文件原始字节、ETag、首次转移授权全文摘要及实际期限和待清理项。发送前保存待发送项，发送成功后清除；收件先保存有效待办，重复消息幂等处理。各端分别持久化，不组成跨方事务。
+
+恢复先核对权威现状，再恢复待审批事件、重发仍有效的通知或补本端文件步骤；复用原任务 ID、审批结论及已签署原始字节。尚未决策的请求再次发布 `ownership.request`，不得自动批准；拒绝、停止、过期或被替代的任务不能被迟到消息重启。release 待确认、sub 字段待清理和转移旧文件待清理分别恢复，不因超时生成新声明或回滚已提交结果。
+
+重复发起 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`。 |
+| 关系版本被替代、目标改变、授权过期、原提交条件失效 | `stopped` / `false`。 |
+| 确定无效的文件、签名、证书或任务证据 | `error` / `false`，code 为 `invalid`。 |
+| 明确审批拒绝 | `rejected` / `false`。 |
+| 新鲜 NS 与完整本人证据确认目标 | `completed` / `false`。 |
+
+参数、身份、发起资格预检失败直接返回错误，不创建任务；human 的绑定和目标关系版本超过 `9007199254740991` 的递增操作均须在任务、消息和文件副作用前以 `invalid` 拒绝，非当前 owner 发起 release/transfer 以 `forbidden` 拒绝。本地任务存储、CAS 或租约失败返回 `persistence_unavailable`，保持已持久记录并禁止继续副作用，不伪造业务终态。completed 的通知或清理失败只追加错误及待办，不降级状态。判定 stopped 前先核对精确目标是否已经提交；迟到消息不得推翻完成事实或重启拒绝、停止、不可重试 error。
+
+| 情况 | 稳定结果及恢复行为 |
+| --- | --- |
+| 请求或审批回复尚未送达 | 先按第 2.1 节核对原关系的完整 statement、固定目标及本任务已准备原件；无声明时核对起始原件。已准备候选、Storage 起始原件和清理原件仍按全文、摘要、存在性及原 CAS 精确匹配，再复用原任务重发；待审批事件可重发，已决定的请求沿用原决定。 |
+| 转移只收到一方同意 | 不发布转移授权；等待另一方，收到拒绝则通知停止。 |
+| 只保存了本地目标文件 | NS 名片和关系不变；核对本端授权及当前版本，继续缺少的本方写入或停止任务。 |
+| 新绑定只发布了 owner 文件 | 尚无新稳定关系，不授予 owner 权限；等待 sub 提交匹配声明。 |
+| owner 上传响应丢失 | 核对规范路径完整原文及摘要；与本任务已签文件一致则仅确认，否则仅在起始存在性、原文及摘要仍匹配时重传。已观察到后续变化则停止。 |
+| sub 上传响应丢失（绑定或转移） | 核对 NS 当前 owner、关系版本及完整文件摘要，判断是否已提交；仅版本增加不足以认定成功。已提交结果保持，不能因超时盲目重写或回滚。 |
+| 名片已验收，Storage 副本未同步 | NS 已提交结果保持；由 NS 恢复后按第 2.3 节补齐当前权威名片副本，SDK 仍以 NS 为准。 |
+| release 已发布，NS 不可用 | 保留 release 和待确认项；恢复后重新请求新鲜检查。 |
+| 新鲜检查已确认 released，sub 离线 | sub 恢复后重新核验当前 release/权威删除；即使没有 relation.confirmed，也只依据本人已同意且完整声明、原件和原 CAS 匹配的历史任务自动清理。 |
+| 转移材料已准备或发布，NS 未提交 | 按当前材料保留原关系保护；核对指定新 owner、版本、期限后重试本方已签署文件。release 或删除已确认时停止旧转移。 |
+| 转移授权已过期 | 停止转移上传；旧关系仍稳定时保持，继续转移须原 owner 新授权。 |
+| 已提交关系，旧文件清理失败 | 已提交结果保持，仅在当前 NS 与本任务完整原件仍匹配时重试清理。 |
+| 已有后续关系版本 | 停止旧写入和旧删除，向应用报告任务已过期或被替代。 |
+| 清理目标对象已变化 | 不删除新对象；旧待办结束或保留人工处理信息。 |
+
+无控制消息的自动清理要求本端已完成的历史绑定/转移记录含 sub 角色及明确同意，owner/sub、被释放完整声明、摘要和原 CAS 精确匹配，不能只比较可能重复的版本；转移历史以其目标 owner 为准。该 completed 触发限制不适用于收到 release 通知后的授权查找：本人明确 accept、sub 角色、本人已签 agent 完整 statement 精确匹配的原绑定/转移任务，即使因发布响应丢失仍 pending，也可提供清理授权。清理原件和原 CAS 单独持久保存，历史 completed 状态及完成证据保持；响应丢失后只复用清理原件，全文、ETag及已知提交 ETag 已对应清理提交时仅观察完成。字段已清空时零签名、零 PUT，owner/代际或 ETag 变化时保留错误和待办，不覆盖后续文件，不创建新的控制消息或审批接口。
+
+NS 恢复沿用数据库和 Storage 既有流程，读取当前 agent.md、owner.md、ETag及证书后重新判定关系。不借独立证据库、账本或历史版本上界恢复关系；当前材料不可确认只暂停相应关系功能，普通名片仍可用。不承诺仅凭当前材料识别所有历史回滚。
+
+## 9. 功能降级、审计与可选托管
+
+| 缺失或故障能力 | 编排行为 |
+| --- | --- |
+| NS 不支持 2.1 owner 锁 | 只展示旧声明，保持普通身份认证和通信；不执行声称具备 2.1 保护的关系变更。 |
+| NS、Storage 或证书状态无法确认 | 保存本端准备文件，暂停关系变更，不授予未经确认的 owner 权限。 |
+| Storage 不支持原子替换或条件发布 | 暂停相应写操作；既有关系仍按当前双文件核验，release/删除动态判定，不依赖独立 NS 账本。 |
+| 转移能力不可用 | 保持原关系，不自动改走解绑后重绑。 |
+| 当前 owner 原件无法确认 | 保留旧 release/授权文件，关系仍可正常完成。 |
+| P2P 不可达或对端未实现 SDK 编排拦截 | 保留本端编排待办，等待通信恢复或对端具备编排能力；不推断对方同意，不绕过审批调用内部文件方法，也不降低 NS 验收要求。 |
+| 没有托管能力 | 绑定、解绑、转移均可完成。 |
+
+### 9.1 业务授权和审计
+
+权限由业务执行端校验，不能信任客户端传来的共识布尔值。最终授权时认证调用者，核对当前 owner、目标 sub_aid、操作权限范围及新鲜共识，确保 NS 锁和关系版本与双方当前签名文件匹配；NS 保留的旧字段不能独自授予权限。要求指定外部 owner 时核对其 AID 或允许名单，self-owner 或仅 AID 不相等不能证明业务认可的外部授权。
+
+如使用 token 或 ACL，绑定 owner_aid、sub_aid、当前完整关系声明及权限范围，使用时重新核对当前声明和共识；版本数字可重复，短有效期和仅比较版本均不能代替撤销检查。旧 SDK、缺少检查头或服务降级不得绕过执行端校验。已通过本次最终授权验收的在途操作按该时点处理，后续独立敏感步骤需重新授权，不承诺跨服务即时撤回。
+
+```mermaid
+flowchart TD
+    A[业务执行端收到操作] --> B[认证调用者并确定目标与权限范围]
+    B --> C[NS 新鲜检查及双方当前文件验签]
+    C --> D{当前 owner、锁、版本和业务权限均匹配吗}
+    D -->|否或无法确认| R[拒绝本次 owner 权限操作]
+    D -->|是| E{本次授权材料仍在验证时限内吗}
+    E -->|否| R
+    E -->|是| F[持久保存本次完整授权证据]
+    F --> G{证据保存成功吗}
+    G -->|否| R
+    G -->|是| H[执行本次获批操作并追加实际结果]
+```
+
+执行前持久保存调用方、目标、操作及权限范围、最终验收时间、NS 版本和 ETag、双方完整签名文件及摘要、证书验证材料，完成后追加实际结果；证据不能保存时停止操作。只保存 URL、statement 或签名块不足以复验。
+
+上述业务授权与执行审计由业务执行端保存，不作为 NS 独立关系事实。NS 仅通过数据库事务/CAS 保存当前完整 sub 自签 agent.md 及文档元数据，当前关系重新核对 owner Storage 的 owner.md。
+
+### 9.2 可选托管和凭据交接
+
+托管由应用显式启用，各端仍只签署、上传自己的文件，不自动赋予代理身份能力；优先保存 owner 无法独立解密的密文。原外部 owner 若曾持有可解密的 sub 私钥，移除代签、代上传接口也不能消除其冒用 sub 身份操作资源的能力。
+
+发生上述可解密托管时，应用分别验证新钥可用、旧证书及旧 token 已失效，并限制旧凭据继续续签或恢复身份，完成凭据隔离后再宣布业务交接完成。NS 关系转移成功不等于凭据交接完成。关系提交、凭据隔离及托管数据清理分别保存进度，不合并成跨服务事务。
+
+## 10. self-owner
+
+### 10.1 定义与本端角色
+
+self-owner 是 `owner_aid == sub_aid`，区别于无 owner。仍需双文件及所属该 AID 的文件签名，不新增协议字段或 RPC；`human` 不能声明 self-owner。
+
+| 本端角色 | SDK 复用的内部文件方法 |
+| --- | --- |
+| owner | `declareSubaid(本端 AID)` 发布声明，`revokeSubaid(本端 AID)` 发布 release；作为原 owner 时使用 `transferOwneraid` 授权转移。 |
+| sub | `declareOwneraid(本端 AID)` 提交名片，`revokeOwneraid()` 在 NS 确认释放后清理名片。 |
+
+同一身份承担两个角色不属于代签或代上传，无需两个 SDK 实例；两个文件的准备、发布和重试进度分别记录。
+
+### 10.2 SDK 本地推进，NS 最后验收
+
+本例从无 owner 的 NS 版本 `0` 开始，目标版本为 `1`。应用发起 self-owner 绑定表达本端两个角色的意愿，默认 SDK 先发布 owner 文件，再提交 sub 文件；无需向自己发送审批消息：
+
+```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 保存完整自签名片]
+    N -->|失败| R[保留本端稳定结果与待办，按当前事实恢复]
+    E --> F[SDK 新鲜核查后发布 ownership.completed]
+    E --> G[NS 按第 2.3 节同步 Storage 名片副本]
+```
+
+本端 owner 角色发布 `subject.agentid.pub:/sub_aids/subject.agentid.pub/owner.md`：
+
+```yaml
+owner_aid: subject.agentid.pub
+sub_aid: subject.agentid.pub
+ownership:
+  statement:
+    version: 2
+    declaration_id: dd0e8400-e29b-41d4-a716-446655440000
+    owner_aid: subject.agentid.pub
+    sub_aid: subject.agentid.pub
+    relation_version: 1
+    declared_at: 1791523200
+  action: declare
+```
+
+本端 sub 角色提交自己的 `agent.md`：
+
+```yaml
+aid: subject.agentid.pub
+name: Self-owned AID
+type: agent
+version: 1.0.0
+owner: subject.agentid.pub
+ownership:
+  statement:
+    version: 2
+    declaration_id: ee0e8400-e29b-41d4-a716-446655440000
+    owner_aid: subject.agentid.pub
+    sub_aid: subject.agentid.pub
+    relation_version: 1
+    declared_at: 1791523260
+```
+
+缺少任一有效声明时 NS 不提交 self-owner，本端保留文件独立重试；不能退为单文件共识。
+
+稳定后当前 agent.md 声明 owner 为 subject.agentid.pub、relation_version 为 1，owner.md 匹配时关系投影为 locked；普通更新见第 5 节。
+
+### 10.3 解绑
+
+本端以当前 owner 角色重新签署并发布自己的 release：
+
+```yaml
+owner_aid: subject.agentid.pub
+sub_aid: subject.agentid.pub
+ownership:
+  statement:
+    version: 2
+    declaration_id: ff0e8400-e29b-41d4-a716-446655440000
+    owner_aid: subject.agentid.pub
+    sub_aid: subject.agentid.pub
+    relation_version: 1
+    declared_at: 1791523800
+  action: release
+```
+
+本端请求新鲜检查，NS 依据当前 release 动态返回 `released`、版本 `1`、锁为 `unlocked`，不另存释放事实。本端再以 sub 角色签署、上传清理后的名片：
+
+```yaml
+aid: subject.agentid.pub
+name: Self-owned AID
+type: agent
+version: 1.0.0
+```
+
+清理提交 sub 重新自签的完整文件；无声明时版本投影为 `0`。即使原 owner 是本端，仍须新鲜确认 release 或权威删除。清理可提前尝试，由 NS 验收。
+
+直接删除及延迟清理分别沿用第 6.2、6.1 节；本例清理后再次绑定使用版本 `1`。若未清理旧声明，仅不同 owner 的新绑定使用其当前可见版本加一；同 owner 必须先由 sub 清理，按第 6.3 节处理。
+
+### 10.4 与外部 owner 的转移
+
+| 方向 | 同一身份承担的角色 | 必须具备的材料 |
+| --- | --- | --- |
+| self-owner → 外部 owner | 本端为原 owner 和 sub。 | 本端的转移授权和目标 `agent.md`，外部新 owner 的目标 `owner.md`。 |
+| 外部 owner → self-owner | 本端为 sub 和新 owner。 | 原外部 owner 的转移授权，本端的目标 `agent.md` 和自有 Storage 目标 `owner.md`。 |
+
+两种方向均由当前原 owner 发起，按第 7 节先取得三个角色的意愿，再验收对应文件、指定目标、版本和期限，从 `v` 切换到 `v+1`。重合角色按第 2.4 节合并本地审批或同一对端请求，不减少所需签名材料。
+
+已有外部 owner 锁时，两个 self-owner 文件不能代替原 owner 转移授权。原 owner 主动 release 或被权威确认删除后，才可按第 6.3 节重新绑定。原、新 owner 相同不构成有效转移。
+
+### 10.5 恢复与业务授权
+
+恢复、降级与审计沿用第 8、9 节；分别核对 NS 和自身 Storage 的两份文件，不能退为单文件验收。
+
+self-owner 共识仅证明本方自主管理声明；外部 owner 的身份及业务信任检查按第 9.1 节，审计同样保存两个完整文件。