@agentunion/fastaun-browser 0.5.20 → 0.5.21

package/_packed_docs/sdk/Ownership2.1/350/257/246/347/273/206/350/256/276/350/256/241.md

@@ -1,476 +1,480 @@
-# Ownership 2.1 详细设计
-
-本文把 [Ownership 协议定义 2.1](../protocol/Ownership协议定义2.1.md) 和 [SDK 编排指南 2.1](Ownership-SDK编排指南2.1.md) 落到现有实现。协议字段、SDK 消息及事件以这两份文档为准；本文定义组件职责、持久数据、提交边界和改造方式。实施顺序与失败用例见 [TDD 分阶段实施计划](Ownership2.1-TDD分阶段实施计划.md)。
-
-实施前代码基线为 2026-10-10 工作区，Git HEAD 为 `1f03bf2d`；该工作区存在尚未提交的实现，不能将基线等同于纯净的 0.5.18 tag。范围是 Python、Node TypeScript、Browser JavaScript、Go 四套 SDK，现有 Go NS、Storage，以及已由测试证明必需的 CA / Gateway 通用适配。下文“现有”“拟新增”描述实施前定位及设计意图；实际实现、验证结果和剩余项以 [实施账本第 13 节](Ownership2.1-TDD分阶段实施计划.md#13-2026-10-10-实施账本) 为准。
-
-## 1. 设计边界
-
-通用 Ownership 2.1 排除 `group/org`：其 owner 来自专属服务的创建、解散、转移事实，不创建 owner.md、通用关系版本、锁、NS Ownership 账本或审批任务。通用 Facade 在副作用前直接返回 `not_applicable`、`retryable=false`，共识 `status/code=not_applicable`，不自动转调用其它方法。新 SDK 的实体名片分支以权威类型和生命周期为准；owner 必填、禁止通用 ownership/proof/release，实体私钥主签、owner token 上传并可选 owner 附签，上传校验实体当前证书代际及完整文件原字节；NS 旧客户端实体 token 与当前实体自签的受限旧格式入口见 [协议 §2.5](../protocol/Ownership协议定义2.1.md#25-grouporg-名片的实体主签与-owner-上传)。
-
-实体 fresh GET 同时携带 X-AUN-Ownership-Check: 1、Cache-Control: no-cache 和 X-AUN-Signature-Format: multi-v1，触发 NS 绕 LRU 全块新鲜验证，仍为 not_applicable、不进入通用账本；GET/HEAD 按 multi-v1 协商完整／首签表示，返回对应 ETag；current/stale、权威 owner/指纹与 missing/unavailable 边界遵循协议 §2.5。verified 下载全块验证历史证书及原始字节，不因当前 owner 或代际变化拒绝历史有效文件，历史成功不代表当前权限。上传仍新鲜校验当前生命周期及证书，不扩展 gateway.resolve。
-
-旧实体文件按历史读取规则保留；历史 relation/evidence/checkpoint 元数据不参与当前关系判定，也不是普通名片可用性的前置条件。当前实体上传按权威类型、生命周期、当前证书及新 Schema 验收。
-
-Ownership 是 agent.md 之上的关系功能，不能因新增 Ownership 2.1 导致原有 agent.md 上传、下载、历史验签、展示或通信不可用。2.1 关系事实只由数据库中持久化的 sub_aid `agent.md` 与 owner_aid 自有 Storage 规范路径中的 `owner.md` 共同确认；数据库事务和 CAS 只负责完整 `agent.md` 的原子更新，不引入独立的第二份 2.1 关系事实。旧 SDK owner RPC 的 Auth JSONL 与 NS `ownership_proof` 是隔离的 legacy 兼容状态，不写 2.1 双文件，不构成 2.1 授权、lock/version/consensus，也不得覆盖已存现代声明。若数据库保留 owner_aid、关系版本或锁等索引列，它们只能服务于 `agent.md` 的 CAS 和查询，不能脱离两份文件单独判定 2.1 关系。只有需要当前 owner 关系的共识、授权和关系操作才执行 2.1 新鲜检查；关系缺失、legacy、stale 或关系依赖 unavailable 时，仅这些功能降级或拒绝授权，不能把普通读取兼容当作 current／consensus，也不能清空既有保护。
-
-后续审查和验收必须同时覆盖下面的兼容矩阵；四 SDK 与 NS 按同一边界检查，不能只验收新增关系流程：
-
-| 场景 | 普通 agent.md 功能及兼容要求 | 当前关系／授权边界 |
-| --- | --- | --- |
-| 旧 SDK 不携带新 Header 读取 | 普通 GET/HEAD 返回旧原字节、ETag 或 304，不因缺头或旧 schema 拒绝 | 缺头不补 current，不作为 2.1 能力或授权证明 |
-| 历史已签文件 | aid-only、已签纯正文、实体自签及旧关系材料按历史读取规则验原字节、实际 signer、指纹、链及签署时间；基础自身格式、目标 AID、真实外签与链仍须通过 | ownership 专属字段的词法／schema 无效只令关系 invalid 或不可授权，不作为完整文件历史外签失败；历史验签不产生当前 owner 权限，现代实体格式仍需完整字段 |
-| 普通展示与通信 | 不因关系缺失、legacy、stale、关系字段 invalid 或 owner 关系依赖 unavailable 阻断 | 只有实际需要 owner 关系的功能降级；严格上传、Ownership 文件解析和 fresh 授权仍拒绝无效关系材料，普通身份与历史文件验签执行各自规则 |
-| 新 SDK 上传／现代实体文件 | 当前 schema、当前可签证书、全部签名、实体代际、owner token 及 CAS 按适用格式严格验证 | NS 不得因请求缺新 Header 而跳过现代校验、agent.md CAS 或关系保护 |
-| 已存普通 legacy 关系正文更新 | 完整保留 owner／ownership／proof／release 的存在性、类型和值，使用当前外签与原 CAS | 普通更新不新建旧绑定、不自动迁入 2.1；原全文、摘要、ETag、关系快照必须可复验 |
-| 旧 SDK owner 操作 | 注册、绑定、转移、查询和解绑走隔离的 legacy RPC/operation ID 流程，兼容旧 proof 与 Auth JSONL 状态 | 只处理旧 `ownership_proof`，不写 2.1 双文件、不授 2.1 lock/version/consensus，不覆盖已存现代声明 |
-| 旧 Group 上传入口 | 始终兼容当前实体证书单签、实体 token 上传，检查生命周期及当前代际；Org 不开放 | 持续执行当前权威检查及存储 CAS；token 本身不证明证书代际 |
-| 本地上传失败稿 | 独立保留 local_draft_content；持有本地私钥材料的自有身份 resolve 本地优先，证书今天过期或不可签不阻断展示，仍为 unverified／非同步且不授 current 权限；显式远端读保留稿，应用显式重试确认后才清稿 | 普通及实体名片和普通 initial 失败稿重连不隐式 PUT；Ownership 任务／消息／outbox 及 Group/Org create/transfer 自身 checkpoint 恢复保留 |
-| 共识、owner 授权及关系操作 | 使用新鲜权威关系、生命周期和当前证书材料 | 必要材料缺失、stale、invalid、unavailable 均不授予 owner 权限，不能将故障降格为 unbound 或自动解锁 |
-
-### 1.1 分工与复用
-
-| 层次 | 本次设计中的职责 | 复用与限制 |
-| --- | --- | --- |
-| 应用 | 发起编排、处理审批、决定业务权限和可选托管策略。 | 无界面应用通过代码明确同意或拒绝；不必自行排列文件提交步骤。 |
-| SDK Facade / 编排器 | 保存本端任务、审批及消息，调用内部文件操作，恢复并通知进度。 | 沿用 AUNClient 的调用形式，不另建第二套 `client.ownership.*` 入口。 |
-| SDK 协议文件层 | 构造、签署、条件提交本方文件，检查新鲜共识。 | 五个文件方法仅供内部复用；不能通过文件方法隐式发起审批。 |
-| NS | 验收 `agent.md` 与 owner.md，按 CAS 原子持久化 sub 名片并同步名片副本。 | 复用 `GET/HEAD/PUT /agent.md`；不把独立关系表、证据表或日志作为事实来源。 |
-| Storage | 提供权威 owner.md、完整文件原子发布、公开读取和名片副本存储。 | 复用通用 Storage/FS 操作；owner.md 只有其命名空间所属 owner 可写删。 |
-| Auth / CA | 本身份认证、证书查询及当前状态验证。 | 不把 2.1 关系事实或审批状态机放回 Auth。 |
-| Message / Gateway | 传递普通加密 P2P 载荷和已有可信服务调用上下文。 | 不增加 ownership RPC 或服务端审批事件。 |
-| 业务执行端 | 实际授权时重新检查关系，先保存证据再执行。 | 不信任应用传来的共识布尔值。 |
-
-```mermaid
-flowchart TB
-    A[应用发起与审批] --> B[SDK Facade 与本端任务]
-    B <--> P[对端 SDK：普通加密 P2P]
-    B --> F[内部文件方法与共识检查]
-    F --> N[NS：权威 agent.md 与 CAS]
-    F --> S[本方 Storage：owner.md]
-    N --> Q[查询各 owner Storage 当前对象]
-    N --> J[提交后同步 agent.md 副本]
-    J --> C[sub Storage：agent.md 副本]
-```
-
-各服务独立实现，不 import SDK 或其它服务的代码。跨语言复用的是格式、测试向量和网络契约；同一 SDK 内可以复用文件方法、签名器及持久化设施。
-
-### 1.2 实施必须保持的不变量
-
-以下编号用于实施计划的验收追踪，不新增协议字段。
-
-| 编号 | 不变量 |
-| --- | --- |
-| D1 | agent.md 的目标、认证上传者和签名者均为 sub_aid；owner.md 的路径 owner、声明 owner 和签名者一致。 |
-| D2 | 原关系有效时，sub 不能清除 owner、只删 statement、改为 human 或 self-owner 来绕过锁。 |
-| D3 | 只有有效 release、权威删除，或原 owner 指定目标的有效 transfer_owner 能改变受保护关系。 |
-| D4 | 当前声明版本无声明为 0；绑定由双方明确选择一致正版本，SDK 默认当前可见基数加一、无声明时为 1；转移强制 v+1。release/删除不递增，清理后不保留独立历史版本上界。 |
-| D5 | NS 只在本地数据库事务中以 CAS 原子提交完整 `agent.md`；owner 的 `owner.md` 由其 Storage 独立条件提交。验收失败不保存候选文件，恢复只依据两份文件、事务提交结果和 CAS 条件。 |
-| D6 | owner 文件操作前重新核对当前完整原文、摘要和存在性；不增加 Storage 路径修订或 ABA 检测机制。 |
-| D7 | 故障、无效签名、缓存 404、旧备份不能解释为解绑或无锁。 |
-| D8 | SDK 审批只表达业务意图；任务、消息 ACK、ready 和 confirmed 提示不能替代 NS 验收。 |
-| D9 | 每次本端外部副作用前有持久待办；恢复先读权威事实，不盲目重新签名、回滚或补写。 |
-| D10 | 名片副本、消息补发、旧文件清理及可选凭据交接独立恢复，不回滚已提交关系。 |
-| D11 | 需要 owner 权限的执行端进行新鲜授权并先留证；历史复验不依赖历史证书今天仍可签名。 |
-| D12 | 降级和旧版兼容不能放宽锁；self-owner 使用同一套双文件和验收规则。 |
-
-## 2. 现有实现与改造定位
-
-本节保留实施前的代码基线与改造原因，不表示这些缺口在当前工作区仍未修复。
-
-### 2.1 SDK
-
-| 现有位置 | 已有能力 | 2.1 改造 |
-| --- | --- | --- |
-| [TS client.ts](../../ts/src/client.ts)、[JS client.ts](../../js/src/client.ts) | `_persistOwnershipRecords`、`_sendOwnershipControl`、`_resumeOwnership`、`_handleOwnershipMessage`、应用消息前拦截、审批及本地事件。 | 保留通路，任务改以 operation_id 关联，切换为双文件步骤和 NS 完成判断，替换旧 proof / escrow / 代传推进。 |
-| [Python client.py](../../python/src/aun_core/client.py) | `_persist_ownership_records`、`_send_ownership_control`、`_resume_ownership`、`_handle_ownership_message` 及重连恢复。 | 与 TS 同义实现；本地存储失败不能被当作“没有任务”。 |
-| [Go ownership_client.go](../../go/ownership_client.go) | `ownershipPersistRecords`、`ownershipSend`、`HandleOwnershipMessage`、`BindAID`、`BindOwner`、审批与释放。 | 调整任务键、模型和方法分工；保留现有 Client 接入，不将 GroupFacade.TransferOwner 当作 AID 转移。 |
-| [TS ownership-proof.ts](../../ts/src/ownership-proof.ts)、[JS 对应文件](../../js/src/ownership-proof.ts)、[Python ownership.py](../../python/src/aun_core/ownership.py)、[Go ownership_proof.go](../../go/ownership_proof.go) | 旧 ownership_proof、独立 statement 签名、ownership_release、托管工具。 | 旧结构仅作兼容识别；2.1 新建文件模型，不能改几个字段后继续使用旧独立签名。 |
-| [Python ownership_protocol.py](../../python/src/aun_core/ownership_protocol.py)、[Go ownership_protocol.go](../../go/ownership_protocol.go)，TS/JS 的 ownership-proof.ts | 旧 `aun.ownership.v1` 载荷与 request_id / proof_id。 | 新消息使用 `aun.ownership.sdk.v1`，独立校验、独立派发，避免旧处理器误执行。 |
-| [TS agent-md.ts](../../ts/src/agent-md.ts)、[JS agent-md.ts](../../js/src/agent-md.ts)、[Python agent_md.py](../../python/src/aun_core/agent_md.py)、[Go agent_md_manager.go](../../go/agent_md_manager.go) | 名片构造、签署、上传、ETag 缓存、待上传恢复；存在 uploadAs / upload_as / UploadAs。 | 增加内部“提交已签署原始字节”能力、条件头和 NS 元数据；2.1 不走代理身份路径。 |
-| [Go agent_md_http.go](../../go/agent_md_http.go) 及其它 SDK 的名片 HTTP 实现 | GET/HEAD、ETag 和旧 owner 授权头。 | 解析新鲜检查结果，保留签名原始字节，普通 2.1 主体停用 legacy V1 的 `X-AUN-AgentMD-Owner-Authorization`；实体不再生成或强制额外 V2 上传授权；全部 NS 请求带 multi-v1。 |
-| 四端 aid-store / aid_store 的注册流程及 Client 的 registration_intent 恢复 | 注册意图可生成旧 proof 名片，再通过旧绑定路径继续推进。 | owner 意图只存本地，首次确认无历史关系时发布无 owner 的本方名片；连接后进入一次 2.1 绑定编排。已存在关系不得走初始化覆盖。 |
-
-现有 AgentMD schema 已有 UTF-8、大小、重复键和类型等校验基础。应在现有校验器增加 2.1 的角色与字段规则，而不是丢弃这些约束重写一套宽松解析器。
-
-Browser SDK 的 metadata 存储为异步；当前缺失存储能力时可直接返回、解析失败可清空记录的行为不能用于 2.1 编排。无法可靠保存审批和待办时，停止会产生文件或消息副作用的操作，仍允许只读共识查询。
-
-### 2.2 NS
-
-NS 下列路径以 [Go 服务根目录](../../../extensions/services/nameservice/go) 为基准。
-
-| 现有文件 / 方法 | 当前行为与缺口 | 修改方式 |
-| --- | --- | --- |
-| `internal/httpserver/agentmd.go`：`get`、`put` | 有 LRU、writeGen 和名片 CAS；没有完整的 2.1 关系验收。get 会把部分 DB 故障映射为 404。 | 引入统一关系检查入口；新鲜 GET/HEAD 绕过缓存并先确认释放；PUT 无论有无检查头都执行基于 agent.md CAS 的保护。 |
-| 同文件：`validateAgentMDUpload`、`enforceStoredOwner` | 完整文件验签已有；锁主要依据旧名片 owner/proof。 | 拆开本身份验签和关系验收；原 owner 从持久化 agent.md 的 ownership 字段及旧名片确定，不能取待上传目标。 |
-| 同文件：`authorizeAgentMDUploader`、`verifyOwnerAgentMDAuthorization`、`verifyOwnershipProof` | 支持旧 proof、owner 授权头和群 owner 代理分支。 | 普通 2.1 本身份上传，旧分支不得覆盖已有关系。Group/Org 按权威类型分流到当前生命周期、实体主签、全块验签及 owner token 上传校验，不落通用账本，不允许自声明改类型绕锁。 |
-| `internal/httpserver/agent_md_schema.go` | `aidParseTailStrictAt`、`validateStrictAgentMDMeta`、旧 ownership 校验。 | 复用严格解析，补 TAG、statement/action、文件角色和当前证书验证。 |
-| `internal/repository/mysql.go`：`CompareAndSwapAgentMD` | CAS 范围只有名片内容、摘要和更新时间。 | 让 ownership 字段随完整 `agent.md` 一起原子提交；不增加独立关系事实表或证据表。 |
-| `internal/httpserver/agentmd_cache.go` | 当前名片缓存。 | 继续供普通展示；不能作为最终授权依据。 |
-| `internal/httpserver/sync.go` | 现有 sync_agent_md 是 SDK 拉取名片快照。 | 保留原用途；另实现 NS 提交后的 Storage 副本同步，不借该接口代上传。 |
-| `internal/httpserver/router.go`：`applyBrowserCORS` | 当前 expose headers 没有 ownership 三个响应头。 | 允许浏览器读取协议、关系版本和锁头，保留现有预检处理。 |
-| `cmd/nameservice-go/main.go` | 已装配 CA、Gateway 等 resolver。 | 装配 Storage 当前对象查询、agent.md CAS 恢复检查和副本同步 worker。 |
-
-### 2.3 Storage 及周边服务
-
-Storage 下列路径以 [Go 服务根目录](../../../extensions/services/storage/go) 为基准。
-
-| 现有文件 / 方法 | 当前能力与缺口 | 修改方式 |
-| --- | --- | --- |
-| `internal/service/service.go`：`PutObject`、`CreateUploadSession`、`CompleteUpload` | 已有 overwrite、expected_version 及提交时版本判断。 | 沿用既有完整文件原子发布，owner 更新不得先删后建。 |
-| 同文件：`DeleteObject`、`deleteResolvedObject`、`FSRemove` | 沿用既有删除能力。 | SDK 清理前核对当前 NS 与本任务完整 owner 原件，不增加删除条件接口。 |
-| 同文件：`HeadObject`、`FSStat` | 现有对象查询。 | 补不经正负缓存的权威查询及明确的路径不存在结果；故障和恢复未完成单独失败。 |
-| 同文件：FSRename、FSCopy、MoveObject、DeleteFolder、BatchDelete、SetVisibility、CheckAccess 等 | 多种目录、路径和授权入口。 | 在最终解析路径后统一执行 owner.md 保护，覆盖父目录、移动、软链、挂载及批量操作。 |
-| `internal/service/handlers.go`、`internal/contracts/methods.go`、`internal/rpc/request_context.go` | 通用 Storage/FS 契约、路由与请求认证上下文。 | 贯穿新增条件和权威结果；NS 镜像授权只认经过认证的服务身份。 |
-| `internal/cleanup/`、`internal/collab/service.go` | 自动清理和其它文件修改通路。 | 不允许自动清理或第三方修改间接删除规范 owner.md；保护下沉至公共写入路径。 |
-
-Auth、CA、Message、Gateway 默认复用。只有测试证明现有身份、证书状态或可信服务上下文不能满足上述契约时，才修改相应适配点；不新增 ownership 关系 RPC、审批 RPC 或服务端消息类型。
-
-## 3. 持久模型
-
-### 3.1 NS：完整 agent.md 与 CAS
-
-关系事实仅有 NS 的 sub agent.md 与 owner Storage 的 owner.md。NS 保存 sub 完整签名原字节、摘要、ETag 和 CAS 元数据；owner.md 保留完整 owner 签名原字节。两者分别使用既有完整文件原子发布。
-
-release/权威删除只令当前关系返回 released；NS 不改 sub 签名字节、不递增声明版本，也不保留独立终局。sub 后续按原 ETag 自签清理；无声明时投影 0，再绑定用 1。旧声明仍在时，仅不同 owner 的新绑定以当前可见版本加一；同 owner 再绑定必须先由 sub 按现有授权清理，再发布新 declare，避免覆盖唯一的当前 release 材料。清理后不保证仅凭当前材料识别全部历史重放。
-
-事务不含远端调用；查询/副本索引不能代替两份材料，也不定义关系表、证据表或同步表为关系事实。
-
-### 3.2 Storage：沿用完整文件存储
-
-不增加逻辑路径修订、删除历史或关系事实记录。owner 操作前再读当前完整原文、摘要和存在性，发现变化则停止旧操作；完整文件原子替换失败时保留旧文件。再读不能识别同内容 ABA 或完整文件回滚，也不提供跨服务一致快照。
-
-Storage 不记录 ownership 的 locked/unlocked、关系版本或 release 终局。它仅证明特定命名空间的路径在本次权威查询时存在什么，或已确认不存在。路径删除记录与“NS 确认释放”是不同事实。
-
-### 3.3 SDK：一个本端任务，不建跨方事务
-
-每个 SDK 以 `operation_id` 为键保存任务；同一 sub_aid 的本端推进串行。下表是内部记录分组，不增加 P2P 字段。
-
-| 分组 | 必须保存的内容 |
-| --- | --- |
-| 固定上下文 | operation、参与 AID、base_relation_version、target_relation_version、发起方、本端角色。创建后不可变。 |
-| 审批 | 本端决定、各审批 AID 已确认的决定和所覆盖的角色。未决、同意、拒绝必须区分；同一决定不能被迟到消息改写。 |
-| 文件进度 | 各本方文件完整签名原始字节、摘要、起始双文件证据及 NS 原 ETag；接收方首次验证转移授权的全文摘要 authorization_sha256 和实际 expires_at，恢复不换字节、不延期。 |
-| 通知待办 | 待发送的相同 operation_id 载荷及接收 AID；接收幂等键为已认证发送者、operation_id、action。 |
-| 结果和清理 | 当前本端 step、已新鲜核验的结果、待清理完整原件及摘要、最近可重试错误。 |
-
-step 表达“本端接下来做什么”，不组合成三方状态笛卡尔积。NS 的 locked/unlocked、SDK 审批决定、文件是否已发布、任务是否已完成分别保存；清理待办可在关系 completed 后继续存在。
-
-本地存储采用各 SDK 已有设施。写入必须可靠完成后才能发消息、发布文件或发出不可恢复的完成通知；存储损坏时不可清空后自动接着批准。Browser 通过异步存储事务完成，多标签页不共享可互相覆盖的陈旧整份任务快照。
-
-实现采用每任务记录及记录修订，读取、比较和写入在本端数据库事务内完成；审批决定与待发送项一次保存。现有普通 metadata getter 不能区分读取失败和空值时，增加专用于任务的错误返回及条件更新能力，不改变其它 metadata 使用者的语义。自定义存储不满足该能力时，2.1 有副作用的编排不可用。
-
-起始证据统一保存 `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 基线。
-
-## 4. 文件层实现
-
-### 4.1 解析、签名与证书
-
-实现分为原始签名容器、YAML 字段、文件角色三个校验步骤，保留当前严格解析基础：
-
-1. 限制 payload 4096 字节、全部尾签区 2048 字节，拒绝非连续块、末尾非空白、非 UTF-8、重复键、YAML tag/锚点/别名及未知 ownership 字段。
-2. 尾标识接受兼容前缀及合法 TAG；常规输出 agent.md 使用 `AUN-SIGNATURE-AGENTMD-V2`，owner.md 使用 `AUN-SIGNATURE-OWNERSHIP-V2`。角色由路径及 AID 决定，不由 TAG 决定。
-3. statement.version 固定为 2，包含 declaration_id、owner_aid、sub_aid、relation_version、declared_at；agent.md 只允许 statement，owner.md 另校验 action 及 transfer 字段。
-4. Store raw/document 统一底层 ECDSA P-256/SHA256；document 按每块之前完整 prefix 逐块签验，首块维持旧正文裸签，不重新序列化 YAML、换行或 Unicode。服务端独立实现同构 core，不依赖 SDK 代码。
-5. 新验收检查证书链、所属 AID、指纹及当前有效/吊销/可签名状态；签名块 timestamp 不能独自证明历史授权时间。
-
-双方声明按容器版本、owner_aid、sub_aid、relation_version 匹配，declaration_id 与 declared_at 可以不同；不能沿用旧 proof 的整段 statement 相等判断。sub 在锁下做普通名片更新时，则须保留自己原来的完整 statement。
-
-TS/JS 的 [cert-utils.ts](../../ts/src/cert-utils.ts)、[JS 对应文件](../../js/src/cert-utils.ts)，Python 的 [_cert_utils.py](../../python/src/aun_core/_cert_utils.py)，Go 的 [aid.go](../../go/aid.go) 均有尾签名基础。实施前 TS/JS/Python 正则只接受未加 TAG 的标识；2.1 在这些位置兼容协议规定的合法 TAG，并与 NS 的 `aidParseTailStrictAt` 使用相同向量验收。
-
-通用 Store.sign/verify 的 document 模式只做原始尾签容器和逐块签验，不判断 YAML；agent.md 与 owner.md 都复用它，再由业务调用者检查资源身份和 Schema。append 已有链才在末字节非 LF/CR 时补 LF，无旧块首签缺换行则拒绝；TAG 不授权、附签 signer_aid 必填、总尾区 2048 字节，精确规则见协议 §2.4。
-
-owner.md 不具备名片必填的 name/type/version，不能直接复用“必须是 agent.md”校验。复用底层签名容器，在各模块内分别实现两种角色 schema；NS 不依赖 SDK 的包。
-
-当前证书材料通过既有权威查询获取，精确核对 AID、证书 DER 指纹、实际 `active_signing`、完整证书链及签名 OCSP。OCSP 绑定本次链选定的直接 issuer，核对 CertID serial、issuer name/key hash 与 ResponderID，只接受该 issuer 亲签及同一 issuer 内嵌证书，不接受委派 responder；链获取和 OCSP 接收后用当时当前时间检查新鲜度，末尾再次核对链有效期。未知签名身份类型时省略 `key_purpose`，不得将 owner.md 的签名者一律视为普通 signing 身份。Group/Org 主签证书属于实体并匹配 frontmatter 指纹，owner 可另附签，附签同样必须验证；已知群实体证书查询使用 `group_identity`。CA `observed_at` 与 OCSP `ThisUpdate` 距当前时间不得超过 30 秒，`ProducedAt` 不得超过 90 秒，三者未来偏差均不得超过 5 秒；`NextUpdate` 严格晚于当前时间和 `ThisUpdate`。CA 的 Go OCSP 签发器按分钟截断 `ProducedAt`，因此其窗口包含取整误差，其它当前状态窗口不变。NS 在最终提交前按当时的服务端时间重新核对；材料不可确认返回 unavailable，已知坏签名、无效链或吊销返回 invalid。
-
-### 4.2 五个内部文件方法
-
-方法名沿用编排指南，实际内部调用还传入任务中固定的版本、文件和提交条件。这些上下文不是新增的 Facade 参数。
-
-| 方法 | 实现步骤 | 稳定返回点 |
-| --- | --- | --- |
-| declareOwneraid | 校验本端为 sub；从 NS 当前原文准备目标声明；先保存完整已签文件，再按原 ETag 自身份 PUT。 | 文件是否已被 NS 验收可确认；失败不生成新 declaration_id 重试。 |
-| declareSubaid | 校验本端为 owner/new_owner；准备目标版本 declare；重新核对当前完整原文、摘要和存在性后原子发布规范路径。 | 本方文件保存成功，只表示 owner 文件已发布。 |
-| revokeOwneraid | 新鲜确认原 owner 已 release/删除，按原 ETag 自签清理 owner/ownership。 | 清理后无声明，版本投影为 0。 |
-| revokeSubaid | 核对当前原关系及 owner 原件，原子发布当前声明版本的 release；请求 NS 新鲜检查，记录本地任务结果和后续清理。 | 发布与 NS 确认是两个独立进度；确认前保留 release。 |
-| transferOwneraid | 核对本端为原 owner、原版本仍有效；签署指定目标、v+1 和有效期的 transfer_owner，条件替换原 owner.md。 | 原授权已保存；不依赖另外两方的文件摘要或提前发布。 |
-
-同一方法可由 Facade 和消息处理器复用。文件层不请求对端同意、不发送业务申请、不创建新的 operation_id。撤回未提交转移是原 owner 的条件替换：同版本 declare、去掉 transfer；按原流程恢复，不能删除文件模拟撤回。
-
-### 4.3 共识检查
-
-`checkOwnershipConsensus(sub_aid?)` 不创建任务。省略 sub_aid 时使用当前身份；任务内部调用可以提供待验收 owner 和版本上下文，以识别 single_sided，但不能把待办当作 NS 已保存关系。
-
-先新鲜读取 NS 原文和 ETag，再核验规范 owner.md，最后复核同一 agent.md、ETag 及 owner 文件原文和存在性。匹配 release 或权威删除返回 released；不写独立终局、不改 sub 文件、不递增版本。材料变化或超时返回 unavailable，普通下载不以此为前置。
-
-当前 agent.md 无声明且无目标上下文时返回 unbound，版本投影 0；仅一方发布可报告 single_sided。released 仅用于当前声明仍在且 owner.md 已 release/权威删除。其余结果使用 consensus、invalid、unavailable。
-
-## 5. Storage 具体改造
-
-### 5.1 通用操作的最小补齐
-
-以下定义 2.1 所需的通用 Storage/FS 契约；本轮实现与契约测试结果见实施账本第 13 节，不增加 ownership RPC。
-
-| 能力 | 拟议实现 |
-| --- | --- |
-| 权威读取 | 沿用现有 Storage/FS 权威查询与完整正文读取，绕过正负缓存；核对请求 owner、bucket、规范 path、exists、sha256 和完整原文。服务身份由认证通道核对，不相信自报字段。 |
-| 路径不存在 | 明确当前路径不存在；DB 故障、路由 404、无权读取、恢复未完成必须失败，不能返回 exists=false。 |
-| 创建 / 替换 | 沿用现有 overwrite 和 expected_version；SDK 先核对保存的起始存在性、完整原文和摘要，不增加 Storage 条件字段。 |
-| 删除 | 沿用既有删除接口；删除前重新核对当前 NS 与本任务完整 owner 原件，后续文件出现时停止。 |
-| 上传 session | 创建 session 时固化路径和条件，CompleteUpload 真正发布前再检查；force/overwrite 不能覆盖 ownership 文件的必需条件。 |
-| 原子发布 | 规范文件使用独立上传临时对象，complete 沿用 create 返回的同一 session_id，核对会话申请者/目标/期限并验证完整内容后原子替换；失败时规范路径仍指向旧完整文件。 |
-
-客户端适配将结果规范化为存在、不存在或不可确认三类；前后重读完整原文、存在性及摘要必须对应，不接受元数据指向新版而下载得到旧缓存正文。
-
-### 5.2 权限和路径保护
-
-owner.md 保护在最终目标解析后执行，并同时检查原始路径和最终路径，防止通过别名、路径编码、大小写处理、挂载或软链绕过。命中 `owner_aid:/sub_aids/{sub_aid}/owner.md` 的修改只接受经认证的同一 owner_aid；父目录删除、路径移出或覆盖同样属于修改。
-
-ACL、token、目录授权和协作写入不能授予第三方该能力。禁止设置使文件不再公开可读的可见性或自动到期删除策略；系统 GC 只能回收已不被当前对象引用的 blob，不能自行移除声明路径。原 owner 通过合法其它入口执行的真实删除仍是解绑，不要求这些入口伪造 release。
-
-NS 复制名片使用可信服务身份，仅允许写 `owner_aid=sub_aid, bucket=default, object_key=agent.md`。校验必须来自现有受认证的服务上下文及目标 NS 的权限范围，不能接受客户端自报 service_name；该内部镜像以 `storage.put_object` 完整原子写入，无需客户端 HTTP 上传会话。该权限不覆盖 owner.md，也不赋予 NS 代签能力；Storage 副本不替代 NS 当前权威名片。
-
-### 5.3 删除后重建
-
-创建响应丢失时先核对当前完整原文与本任务已签文件；相同则仅确认，否则仅在保存的起始存在性、原文和摘要仍匹配时恢复。已观察到后续变化时停止；不能凭当前材料排除同内容 ABA 或历史回滚。
-
-清理 release 或旧转移文件前重新核对当前 NS 与本任务完整原件和摘要。对象已变或无法确认时保留待办或结束旧清理，不替换原件继续删除。
-
-## 6. NS 验收与提交
-
-### 6.1 同一 sub_aid 的处理路径
-
-新鲜关系检查和名片写入口复用同一验收逻辑；普通读取不强制检查当前关系。
-
-1. 按 sub_aid 串行读取当前 agent.md 和 CAS，区分不存在与数据库错误。
-2. 从已存原文确定原 owner/版本，不用候选新 owner 判断旧关系。
-3. 核验当前 owner.md 的签名、路径、身份、版本和完整原文；匹配 release/权威删除返回 released，无效或不可用不授 owner 权限。
-4. GET/HEAD 返回原字节和关系投影，不存额外关系事实。PUT 校验上传身份、原 CAS、完整候选及适用绑定/转移材料。
-5. 最终重新读取 owner 原文和存在性，复核 agent 原 ETag、证书及转移期限；材料变化或超时不能沿用旧结果。
-6. 短数据库事务比较原 CAS，原子提交完整 sub 自签文件；失败回滚本次名片提交。
-7. 提交后刷新缓存并同步副本；响应丢失不撤销已提交文件。
-
-候选失败不撤销 owner.md 的当前 release。NS 不修改或重签 sub 文件，也不持久化独立释放代际。
-
-### 6.2 关系转换表
-
-| 当前材料 | 处理 | 结果 |
-| --- | --- | --- |
-| 无有效关系，当前可见版本 v（无声明为 0） | 双方明确签署一致正版本并按原 CAS 提交；SDK 默认 v+1、无声明时为 1。 | 匹配时 consensus/locked；NS 不独立强制绑定上界，不齐不保存候选。 |
-| 原 owner 有效 declare | 正文更新保留 owner 和完整 statement。 | 版本不变，ETag 可变。 |
-| 有效 transfer_owner | 转移须匹配目标、v+1、期限及目标双文件。 | 直接提交目标 sub 自签文件。 |
-| transfer_owner 过期 | 不转移，继续核验旧关系。 | 不自动释放。 |
-| 匹配 release 或权威删除 | 动态返回 released，允许 sub 清理；未清理时仅不同 owner 可重新绑定。 | 原版本 v 不变；清理后投影 0，同 owner 再绑定由 SDK 默认使用 1。 |
-| 无效或不可确认材料 | 不授 owner 权限，不以故障解锁。 | invalid/unavailable；普通名片继续可用。 |
-
-不维护退休版本或历史最大值。清理后版本可重复；重试必须核对原文、摘要和 CAS，不能只比较数字。旧声明未清理时，同 owner 的 bind 在创建任务、消息或文件副作用前返回 conflict/action_required，要求应用先由 sub 按现有授权清理；不自动编排清理后再绑定。
-
-### 6.3 HTTP、缓存与错误
-
-新鲜 GET/HEAD 即使命中 ETag 或 If-Modified-Since，也必须先完成关系检查，再决定是否返回 304；响应携带当前协议、版本、锁头。原始名片 ETag 未变不代表 owner 没有释放。
-
-普通响应同样返回三个关系元数据头，但不替代新鲜检查。普通读取可继续使用名片展示缓存；缓存条目与持久化 `agent.md` 的 CAS 条件不符时重新回源，不能拼接旧名片和新字段来发放权限。缺少 `X-AUN-Ownership-Check`、来自旧 SDK、伪造 owner 授权头、删除名片或重新注册同一 AID，都不得跳过写入保护。
-
-拟采用的 HTTP 错误映射如下；这是对现有 handler 的实现补齐，不新增 RPC：
-
-| 情况 | HTTP / SDK 处理 |
-| --- | --- |
-| 认证上传者不符，或受锁保护的关系被改写 | 403；区分身份错误与 owner_locked。 |
-| 文件、角色、签名或目标声明无效 | 400；关系检查归类 invalid。 |
-| 文档或 Storage 条件不满足 | HTTP 名片条件失败为 412；Storage 沿用通用版本冲突类别。停止旧提交。 |
-| 名片条件满足，但关系版本已变化 | 409；重新读取，不能自动换最新版本再覆盖。 |
-| 2.1 关系或现代实体格式写入缺少所需条件 | 428；旧客户端旧格式入口可缺新 Header/CAS，仍执行服务端原子 CAS、当前快照及关系保护。 |
-| NS、Storage、CA、名片持久化或当前核验不可用 | 503 / unavailable；不伪装成不存在。 |
-
-2.1 响应头只能由真正执行上述检查的 NS 返回。浏览器 CORS 同步暴露这三个头，否则 JS 无法判断能力和验收结果。
-
-### 6.4 单实例与将来的多实例
-
-当前使用以 sub_aid 为粒度的进程内串行保护，覆盖最终权威读取、关系判定与本地提交；SQL 事务只包围本地数据修改，不包围远端调用。现有 writeGen 不能替代持久版本和所有入口共用的关系串行保护。
-
-未来多实例复用同一处理接口，换为共享数据库及分布式串行保护。提交处必须校验递增持锁代号或等效 fencing 条件；租约失效的旧持锁者即使晚到，也不能写入。首次创建、字段清理和副本同步同样需要防旧实例覆盖。该扩展是启用多实例前的门槛，当前阶段不强行引入分布式锁服务。
-
-Storage 当前完整原文复核与 NS 提交之间没有跨服务一致快照，不提供 ABA 或完整文件回滚检测保证。按协议最终验收时点、服务端验证时限和实际提交裁决竞争，不声称 owner 发布撤回的一瞬间能取消所有在途请求。
-
-### 6.5 名片同步
-
-同步 worker 从持久化的 NS 当前完整原文，以受限服务权限条件写入 `{sub_aid}:/agent.md`。写前和写后比较 NS 当前 ETag 与全文摘要；文档已更新则继续补齐最新版本。关系版本相同的普通更新也必须同步。
-
-同一 sub 的同步串行；提交副本时比较本次读取的文档条件，不能把已被新名片更新的内容覆盖。Storage 失败、响应丢失或 NS 重启后重新读取当前权威文档及目标完整文件，再幂等执行。副本失败不改变关系 completed 的判定。
-
-## 7. SDK 编排与应用接入
-
-### 7.1 七个 Facade 与内部复用
-
-| Facade | 调用的内部工作 | 本端应用责任 |
-| --- | --- | --- |
-| bindOwneraid | 保存 sub 发起任务，发送 bind.request；owner 同意后由 owner declareSubaid，再由 sub declareOwneraid。 | sub 发起即表达本端意愿；owner 处理审批。 |
-| bindSubaid | 保存 owner 发起任务，等待 sub 同意，然后同上推进。 | owner 发起；sub 明确同意或拒绝。 |
-| acceptOwnershipRequest | 对已有请求持久保存决定、回复，并仅推进已经满足审批和权威前置条件的步骤。 | 按界面或代码策略决定，未决定保持等待。 |
-| rejectOwnershipRequest | 持久保存拒绝并回复，结束该待审批任务。 | 只用于尚未作决定的审批；不通过拒绝回滚已发布文件。 |
-| releaseSubaid | 发布 release → 新鲜确认 → 通知 sub 自签清理 → 条件清理旧文件。 | 不等待 sub 在线，任务目标版本为被释放声明的当前版本。 |
-| transferSubaid | 收齐新 owner 与 sub 同意 → transferOwneraid → 新 owner declareSubaid → sub declareOwneraid。 | 只有原 owner 可发起，两个接收角色均参与意向审批。 |
-| checkOwnershipConsensus | 调用第 4.3 节的统一检查器。 | 展示结果或触发业务执行端自己的新鲜授权。 |
-
-发起方法先查询权威现状固定起始版本，在发送消息、发布文件或删除等副作用前保存任务，返回 operation_id 与本端进度，结果由本地事件继续通知。面向应用只导出这些方法和必要类型，五个文件方法不导出。Python/Go 采用本语言命名习惯，但语义和消息 action 保持一致。
-
-内部编排器与消息处理器推进同一任务；禁止收到 owner.ready 后再调用 bindOwneraid 创建第二个任务。普通名片更新仍使用现有名片 API，但必须完整保留锁定的关系字段。
-
-普通 `agent` 注册的 owner 可选；指定 owner 时，owner 意图先与 SDK 生成的固定 operation_id 一起持久保存；初始名片不写 owner 或旧 proof，并以条件创建提交。连接后用该 ID 进入绑定编排，响应丢失或重连都读取原任务，不另建操作、不默认批准；未指定 owner 时只初始化普通名片，不创建关系任务。NS 不可用时保留已有意图；已有关系或未知旧待上传文件不能由初始化路径覆盖。Group/Org 身份准备不生成通用注册意图；创建自动 owner 绑定，owner 持有实体材料，用实体私钥主签并以本人 token 上传，可选追加本人附签。专属 pending 保存实体命名空间、固定 owner、实体证书指纹、原完整多签文件及原 CAS，恢复不补造条件或跨 owner/rekey 代际重签。
-
-普通显式上传与注册初始化分别保存待办。普通名片候选在本地 schema 和外层签名验证通过后、首次远端 preflight 前，先独立保存到既有元数据的私有 `local_draft_content`，不覆盖已确认的远端 content/ETag；自有且持有本地私钥的身份默认 resolve 优先返回该稿，标记 unverified、in_sync=false、source.agent_md_fetched=false。显式 download／forceRefresh 仍读取远端权威内容并保留草稿，只有服务端确认对应候选提交成功才清稿。重连不自动重传普通失败稿，普通注册 initial 失败稿同样需要应用显式重试；即使存在普通 pending 也不隐式 PUT。Ownership 2.1 任务及注册意图的既有恢复不能替代失败稿的显式重试。取得可靠 NS 原条件后，仍在 PUT 前持久保存完整签名字节、原 If-Match／If-None-Match 及关系快照；显式重试既有 pending 时先核原条件，缺失则保留原元数据及原错误，不因远端同字节而清除。2.1 正文更新核对原 owner、完整 statement、relation_version 和 lock。已有普通 legacy owner/proof 或 2.0 关系仅允许更新正文，完整保留 owner、ownership、ownership_proof、ownership_release 的存在性、类型和值；新 metadata 和外签执行当前规则，不自动迁入 2.1。该分支持久保存原全文、摘要、原 ETag 及完整关系快照，重试核对 base/candidate/remote 和原条件；全文及提交 ETag 均对应原提交时只观察确认，否则仅按仍成立的原条件重传原 blob，不刷新 CAS、不重签、不补造上下文。其它缺原上下文的旧待办仅允许版本 0 / unlocked 的初始关系；实际关系变更由对应 Ownership 任务恢复。
-
-Group/Org 名片失败稿及 pending 保留实体命名空间中的完整多签原文、原 CAS、固定 owner 和实体证书指纹，由应用显式重试，post-connect／重连不隐式 PUT。重试先验证完整原件及当前 owner、状态和证书代际，原条件完整且同代际原文／ETag 已确认提交时只观察完成。转移、rekey 或解散后停止旧代际待办，不更换身份、指纹或条件重签。取消实体 V2 授权后，不再保存、刷新或检查其额外授权及过期窗口；普通文件签名与当前证书检查保留。专属 create/transfer 自身 checkpoint 恢复机制不变。
-
-### 7.2 转移的默认编程顺序
-
-```mermaid
-sequenceDiagram
-    participant O as 原 owner SDK
-    participant N as 新 owner SDK
-    participant S as sub SDK
-    participant NS as NS
-    O->>N: transfer.request
-    O->>S: transfer.request
-    par 两方独立审批，顺序不限
-        N-->>O: accept 或 reject
-    and
-        S-->>O: accept 或 reject
-    end
-    alt 收齐两方同意且原关系复核通过
-        O->>O: 条件发布授权
-        O-->>N: transfer.ready
-        O-->>S: transfer.ready
-        N->>N: 核对授权并发布自己的 declare
-        N-->>S: owner.ready
-        S->>NS: 自签目标 agent.md，条件 PUT
-        NS-->>S: 持久验收结果
-        S-->>O: relation.confirmed 提示
-        S-->>N: relation.confirmed 提示
-        O->>NS: 新鲜核验后完成并条件清理
-        N->>NS: 新鲜核验后完成
-    else 任一方拒绝
-        O->>O: 持久停止待审批任务，不发布授权
-        O-->>N: operation.stopped
-        O-->>S: operation.stopped
-    end
-```
-
-任一尚未决定的审批方拒绝时，原 owner 停止任务并通知另一方，不发布授权。授权已发布后的“停止”只停止本端推进；必要的撤回按协议条件写回 declare，并重新确认实际结果。已提交转移不能取消，反向转移须由新 owner 发起。
-
-协议仍允许乱序文件提交；这条顺序是 SDK 默认便利流程，不成为 NS 的请求先后校验，也不要求原 owner 获取目标文件摘要。
-
-原 owner 收齐同意后，按本端有限授权时长策略生成 expires_at 并连同已签文件持久保存；审批等待不提前消耗已发布授权期限。重试复用同一授权，不自动延长；过期后再次转移须新的明确发起和审批。
-
-三个协议时间字段 declared_at、expires_at、签名 timestamp 均为 `1..9007199254740991` 的十进制正整数原词法。先检查词法与范围，再转数字或日期；非法值归 invalid。范围内仍执行证书、当前时钟和过期语义，不另设年份上界。
-
-重复发起先查本端身份、发起方、operation、sub、原 owner、新 owner、base/target 版本匹配的进行中任务，并核对原声明完整原文、摘要和原 CAS，早于新操作资格检查；清理后版本数字可重复，不能仅凭数字认定同一关系。复用原 ID、审批、原签名字节、提交条件和期限。目标已提交时新鲜核验完整本人证据完成原任务；同代际不同意图 conflict 且不建第二任务，并发相同意图只保留一个。后代际先停止旧任务再发起新合法任务；历史 completed 不凭参数相同复用，拒绝、停止、不可重试 error 不复活。
-
-错误分类与业务状态分别保存：服务、网络或验证依赖不可用是 unavailable，确定无效的签名、证书、文件或证据是 invalid。权威元数据、正文摘要不一致，以及 Storage Base64 传输封装损坏均为 unavailable；摘要匹配后确定非法的 UTF-8、文件字段或签名为 invalid。等审批/材料、暂不可用、unsupported_protocol 为 pending/true；代际替代、目标变更、授权过期、原条件失效为 stopped/false；确定证据无效为 error/false；拒绝 rejected/false，完整目标确认 completed/false。预检失败不建任务；存储/CAS/租约失败 persistence_unavailable 且保持已存记录、停止副作用。停止前先核精确目标完成事实，completed 的通知/清理失败只追加错误和待办，迟到消息不重启终态。
-
-### 7.3 消息、安全校验与本地事件
-
-完整 action、载荷和事件表沿用编排指南第 2.5、2.6 节，不再定义第二套消息。实现上对 `aun.ownership.sdk.v1` 使用单一入口，实时 push、离线 pull 和重连重放都进入该入口：
-
-1. 解密后、投递应用 message.received 前识别控制类型；保留原始控制 JSON 以检查重复键及关系版本的整数词法，不能只校验解析后对象。未知 action、无效载荷也作为控制消息消费。
-2. 发送者取消息层确认的 from_aid；校验 action 方向及已有任务的固定上下文，禁止依据载荷自报身份批准。
-3. 请求、审批和 ready 各按所在阶段读取权威关系。未发布转移授权的审批阶段不能要求该授权已存在；实际发布目标前则必须检查它。
-4. 将有效待办和幂等键持久保存后才结束处理；存储失败保留待解密、排序及补拉来源，不推进游标、不标记已投递、不 ACK，也不转为普通应用事件或不可解密消息。
-5. 审批先持久再回复；消息先存待发送项再调用已有 message.send。持久 P2P 不设置 volatile TTL。
-6. ready、confirmed 和 ACK 都只触发重新读取与推进；不能携带或代替关系授权。
-
-事件仍由已有本地 dispatcher 发布。应用可按 operation_id、事件名和 step 去重；恢复可再次发布待审批事件，但不得覆盖已保存决定。收到另一操作的新版本后，旧任务转为停止推进，不能更新 ETag 后强制继续。
-
-绑定／转移 completed 的判断使用当前 NS 目标 owner、目标版本和完整材料，并按本端角色比较自己持久保存的文件摘要：sub 核对 agent.md，owner/new_owner 核对 owner.md，转移原 owner 核对其保存的授权和固定目标；不要求新增消息字段交换目标文件摘要。sub 上传响应丢失时必须比较自己保存的文件摘要；其它参与方不能仅看到任意 v+1 就报成功；原 owner 缺少本任务已保存的转移授权也不能冒认外部转移完成。恢复时校验持久验收证据，包括验收时的 NS ETag、agent.md 全文 SHA256、实际 lock／owner／relation_version，以及按本端角色保存的本人已签原始完整字节、摘要和原提交条件；绑定、转移另须有 owner.md 全文 SHA256及本端批准。本人原件还须按文件角色、签名者、owner/sub、base/target、action、转移目标/期限及原条件匹配任务固定上下文；合法历史只复验结构和上下文，不要求现在仍可签或授权未过期。缺失、损坏证据的旧 completed 返回 persistence_unavailable，不只信任阶段标记，也不从当前网络补造历史证据；合法历史完成不要求当前 NS 仍停在历史版本。release completed 接受本任务声明 v 的新鲜 released/v，或严格关联本任务的真实 unbound/0；任务 base/target 及历史 verified 仍为 v，实际完成证据不得伪造 released。通过 unbound/0 完成时，sub 须以本任务清理原件、摘要及原 CAS，或本人明确 accept 的匹配原 bind/transfer.release_cleanup，精确核对当前 NS 原文、摘要、ETag及已知提交 ETag；owner 须以本任务 release 完整原件、hash 与当前 owner.md 一致且当前证书验证有效确认，不补造旧条件。本地保留原件，后续关系必须重新检查。
-
-sub 收到 release 通知时，只有在持久历史中找到本人明确 accept、含 sub 角色，且本人已签 agent 的 owner/sub、被释放完整 statement 原文与摘要匹配的绑定或转移任务，才自动签署清理；该原任务可因发布响应丢失仍 pending，转移历史匹配其目标 owner。无控制消息时，仅已完成历史任务的恢复路径触发自动清理，即使未收到 relation.confirmed，也须新鲜核验当前 release/权威删除，将清理原件、全文摘要和原 CAS 持久保存于本地任务，保持原 completed 历史。响应丢失复用原件和原条件，当前完整文件、摘要、ETag及已知提交 ETag 匹配时仅确认；冲突保留原待办，不创建新的控制消息。缺授权且仍有旧字段时为 pending/action_required。当前字段已清空时关系为 unbound/0，不再签写；仅在本任务持久清理原件、摘要及原 CAS，或本人明确 accept 的匹配原 bind/transfer.release_cleanup，能精确确认本任务提交时记录清理完成，不据空字段补造释放或同意历史。历史 completed 仅表示当时任务结果，不要求当前关系仍为 released，也不授予当前 owner 权限。历史原件只复验结构及任务上下文；新鲜关系核验与真正新签文件仍按协议检查当前证书。不得新增释放审批 Facade 或从超时推断同意；应用可用现有名片 API 明确自签清理。陈旧 ETag 或后续关系不允许被旧清理任务覆盖。
-
-### 7.4 self-owner 与重合角色
-
-同一 AID 同时承担多个角色时，按 AID 合并消息接收方，审批记录保存其覆盖角色。self-owner 的本端一次明确发起/同意可以覆盖本方角色，不发给自己 P2P；两份文件仍分别签署、写入并经 NS 验收。
-
-外部 owner 转移到 sub 自己时，一个接收 AID 同时承担 sub 与 new_owner，单次审批覆盖这两个角色，但仍先发布 owner.md 再提交 agent.md。self-owner 转移到外部 owner 时，原 owner 与 sub 为同一身份，发起意愿覆盖这两个本端角色，外部新 owner 仍须审批。new_owner 等于当前 owner 不是转移；human 的 self-owner 仍拒绝。
-
-## 8. 恢复与稳定状态
-
-### 8.1 崩溃点与恢复依据
-
-| 中断点 | 已经稳定的事实 | 恢复动作 |
-| --- | --- | --- |
-| 已保存请求，尚未发送 | 关系未变，任务已存在。 | 核对原声明完整原文、摘要、目标与原 CAS，重发相同消息。 |
-| 同意已保存，回复未送达 | 决定已固定。 | 重发原决定，不能重新询问后改成另一决定。 |
-| 转移只收到一方同意 | 原关系保持。 | 等另一方；不发布授权或目标文件。 |
-| 签名文件仅保存在本地 | 网络权威关系未变。 | 核对条件仍有效，重用原字节推进。 |
-| owner 发布响应丢失 | 文件可能已保存。 | 读当前完整原文和摘要；相同仅确认，否则起始原件仍匹配时重试。 |
-| sub PUT 响应丢失 | NS 可能已经验收。 | 比较当前 owner、版本及原始文件摘要；匹配后确认，后续版本出现则停止旧写入。 |
-| release 已发布，NS 不可用 | 新鲜授权不能再使用该 release 对应旧关系；当前关系尚未完成新鲜核验。 | 保留 release，恢复后请求新鲜检查。 |
-| owner.md 已 release，sub 离线 | 动态返回 released，agent.md 字节和版本不变。 | sub 上线按原 CAS 自签清理，不新增释放记录。 |
-| NS 已保存名片，副本同步或旧文件清理失败 | 已提交的完整 agent.md 保持；当前关系仍按双材料核验。 | 分别补齐当前副本、按本任务原件核对后清理。 |
-| 转移授权过期或被有效撤回 | 旧关系仍受保护，除非 NS 已提交转移。 | 新鲜确认；未提交则停止旧任务，不自动延长授权。 |
-
-共识检查从首次 NS GET 发出前开始计算整体 30 秒窗口，覆盖首读、证书/Storage 验证和末读；材料变化或超时返回可重试 unavailable。fresh HTTP 携带 no-cache 并禁止自动跟随重定向。收到 sub.cleaned 时，在持久接收前核对任务固定的原声明、清理原件、ETag/全文摘要和原 CAS；字段已清空时当前关系为 unbound/0，通知不能替代文件与任务核验。
-
-Group/Org 名片失败稿及 pending 保留实体命名空间中的完整多签原文、原 CAS、固定 owner 和实体证书指纹，由应用显式重试，post-connect／重连不隐式 PUT。重试先验证完整原件及当前 owner、状态和证书代际，原条件完整且同代际原文／ETag 已确认提交时只观察完成。转移、rekey 或解散后停止旧代际待办，不更换身份、指纹或条件重签。取消实体 V2 授权后，不再保存、刷新或检查其额外授权及过期窗口；普通文件签名与当前证书检查保留。专属 create/transfer 自身 checkpoint 恢复机制不变。
-
-重连恢复先读取 NS/Storage，再考虑待发消息、写入和删除。一次持久保存的 step 不能证明远端副作用已经发生，远端的新版本也不能被旧 step 覆盖。
-
-### 8.2 NS 与 Storage 恢复
-
-进程崩溃沿用数据库事务恢复：提交前无变更，提交后读取当前完整 agent.md 及 CAS，再核验 owner.md。副本同步从当前名片继续，不借独立日志、关系账本或证据表恢复关系。
-
-备份恢复沿用数据库及 Storage 现有流程。重新读取当前两份材料、ETag及证书；不可确认时只暂停关系变更和 owner 授权。不维护独立历史版本上界，不承诺仅凭当前文件识别所有历史回滚。
-
-不新增跨服务恢复事务或恢复锁状态。Storage 恢复未完成时不提供权威不存在结论；普通名片读取、下载、历史验签、展示和通信按各自规则继续。
-
-Ownership 2.1 只以 sub 的 agent.md 和 owner 的 owner.md 为关系事实。NS 事务/CAS 原子更新完整 agent.md；owner.md 使用 Storage 既有完整文件事务。关系表、证据表、同步待办、独立日志和历史版本上界均不是事实来源。
-
-提交前失败时目标名片未变；响应丢失按原条件核对完整文件与 ETag，匹配则确认，条件失效停止旧提交。SDK 保存审批、已签原件及原条件供重试，不替代两份当前材料。
-
-首次激活沿用现有数据库迁移、事务、CAS 和恢复流程，不需要独立日志初始化、reserve/confirm、独立关系事实表或相关环境变量。数据库事务不包含远端调用。
-
-## 9. 降级、旧版及审计
-
-### 9.1 能力门槛
-
-| 缺失能力 | 本期行为 |
-| --- | --- |
-| NS 无 2.1 检查或 agent.md CAS 保护 | 可读取展示，不启动 2.1 关系变更，不把旧 proof.complete 解释为 2.1 共识。 |
-| Storage 无原子条件发布或权威查询 | 暂停相应写入和 owner 权限判断；不能用删后重建或下载 404 替代。 |
-| 当前 owner 原件无法确认 | 保留旧文件；已确认的关系结果仍可完成。 |
-| SDK 无持久任务存储 | 不启动有副作用的编排；只读查询仍可用。 |
-| P2P 不可达或对端未实现编排 | 保持待办；不推定同意，也不自动改走内部文件方法。 |
-| 不支持转移 | 保持原关系；不自动降级成 release 后重新绑定。 |
-| 无托管 | 正常完成绑定、解绑、转移。 |
-
-### 9.2 旧实现的安全隔离
-
-SDK 的旧 `aun.ownership.v1` 消息、proof 工具和 metadata 不能改名后自动转成新任务。保留必要的旧材料读取与错误提示；2.1 处理器不执行旧 proof、证书托管、代签、代上传或自动 rekey 链路。
-
-NS 保留 legacy owner/proof 原保护；普通名片入口允许原样保留旧关系材料、自签及 CAS 更新正文，不自动迁入 2.1。旧 SDK 的注册、绑定、转移、查询和解绑另由隔离的 legacy RPC、Auth JSONL 与 operation ID 兼容流程承载，只激活旧 `ownership_proof`；不写 2.1 双文件，不产生 2.1 lock/version/consensus。缺新 Header 或旧 operation ID 均不得成为覆盖已存现代声明的通路。
-
-旧 proof 不等于新双方完整签名，不自动改造或伪造声明。旧关系无法确认时只降级 owner 功能；普通读取及兼容正文更新仍可用。2.1 从当前两份文件重新核验。
-
-这是一项明确的兼容边界：新版本可以支持新关系，并安全拒绝未迁入旧关系的危险写入；不能据此宣称所有 0.5.18 关系可无缝自动升级。
-
-### 9.3 业务授权与可选托管
-
-执行端验证调用者、目标 sub、当前 owner、操作范围、新鲜版本及双方签名，先持久保存完整授权材料，执行后追加实际结果。若未来 owner 派生 token/ACL，必须绑定当前完整关系声明并在使用时复验，不能仅比较可能重复的关系版本；当前没有该消费路径的模块不新增无关接口。
-
-NS 不以独立审计记录判定当前关系。业务端可保存授权及执行记录供自身审计；这些记录不是当前关系的第三份事实。
-
-托管由应用显式启用，优先使用 owner 无法独立解密的密文，不作为绑定前提。原 owner 曾持有可解密私钥时，应用另行确认新钥可用、旧证书和 token 失效、续签/恢复能力已隔离。该业务交接进度不改变 NS 已完成的关系结果。
-
-## 10. 实现文件组织
-
-各 SDK 内的下列模块承担 2.1 相关职责，现有消息与身份基础保持原有位置：
-
-| SDK | 实现文件 | 职责 |
-| --- | --- | --- |
-| TS / JS | `src/ownership-v21.ts`、`src/ownership-workflow.ts` | 前者实现两种文件模型、内部步骤和统一共识；后者实现任务、审批、P2P 和恢复。 |
-| Python | `src/aun_core/ownership_v21.py`、`src/aun_core/ownership_workflow.py` | 与上述相同职责，复用当前身份、异步网络及本地存储。 |
-| Go | `ownership_v21.go`、`ownership_workflow.go` | 与上述相同职责，由已有 Client/ownership_client 接入。 |
-| NS | `internal/httpserver/ownership.go`、`internal/repository/ownership.go`、`internal/httpserver/agentmd_storage_sync.go` | 关系检查、持久原子提交、名片副本待办执行；均为服务内部实现。 |
-| Storage | 优先修改现有 service、repository、models 和 migration 文件。 | 复用已有事务、版本及对象操作，不新增 ownership 专用服务。 |
-
-具体已有文件、方法、测试位置和每阶段退出条件以 [实施计划](Ownership2.1-TDD分阶段实施计划.md) 为准。新增模块仍须遵守零跨服务代码依赖；跨语言一致性由协议向量和交叉测试验证。
+# Ownership 2.1 详细设计
+
+本文把 [Ownership 协议定义 2.1](../protocol/Ownership协议定义2.1.md) 和 [SDK 编排指南 2.1](Ownership-SDK编排指南2.1.md) 落到现有实现。协议字段、SDK 消息及事件以这两份文档为准；本文定义组件职责、持久数据、提交边界和改造方式。实施顺序与失败用例见 [TDD 分阶段实施计划](Ownership2.1-TDD分阶段实施计划.md)。
+
+普通 `agent.md` 的基础读取、验签、上传与显式 pending 恢复不以前置 Ownership 共识、owner Storage 或关系状态为条件。普通正文更新须原样保留当前原件中全部关系材料的字段存在性、类型和值，并遵守本人签名和原 ETag/CAS；材料无效或依赖不可用不能阻断这种更新。增删改关系字段继续执行当前双文件授权核验，不能借普通名片入口清除或替换 owner 锁。
+
+实施前代码基线为 2026-10-10 工作区，Git HEAD 为 `1f03bf2d`；该工作区存在尚未提交的实现，不能将基线等同于纯净的 0.5.18 tag。范围是 Python、Node TypeScript、Browser JavaScript、Go 四套 SDK，现有 Go NS、Storage，以及已由测试证明必需的 CA / Gateway 通用适配。下文“现有”“拟新增”描述实施前定位及设计意图；实际实现、验证结果和剩余项以 [实施账本第 13 节](Ownership2.1-TDD分阶段实施计划.md#13-2026-10-10-实施账本) 为准。
+
+## 1. 设计边界
+
+通用 Ownership 2.1 排除 `group/org`：其 owner 来自专属服务的创建、解散、转移事实，不创建 owner.md、通用关系版本、锁、NS Ownership 账本或审批任务。通用 Facade 在副作用前直接返回 `not_applicable`、`retryable=false`，共识 `status/code=not_applicable`，不自动转调用其它方法。新 SDK 的实体名片分支以权威类型和生命周期为准；owner 必填、禁止通用 ownership/proof/release，实体私钥主签、owner token 上传并可选 owner 附签，上传校验实体当前证书代际及完整文件原字节；NS 旧客户端实体 token 与当前实体自签的受限旧格式入口见 [协议 §2.5](../protocol/Ownership协议定义2.1.md#25-grouporg-名片的实体主签与-owner-上传)。
+
+实体 fresh GET 同时携带 X-AUN-Ownership-Check: 1、Cache-Control: no-cache 和 X-AUN-Signature-Format: multi-v1，触发 NS 绕 LRU 全块新鲜验证，仍为 not_applicable、不进入通用账本；GET/HEAD 按 multi-v1 协商完整／首签表示，返回对应 ETag；current/stale、权威 owner/指纹与 missing/unavailable 边界遵循协议 §2.5。verified 下载全块验证历史证书及原始字节，不因当前 owner 或代际变化拒绝历史有效文件，历史成功不代表当前权限。上传仍新鲜校验当前生命周期及证书，不扩展 gateway.resolve。独立 AIDStore 的实体上传接线存在语言差异：Python／Go 须显式注入权威 entity owner resolver；TS／JS 默认通过 fresh NS 与 PKI 核对当前 owner 和实体证书指纹，不能假定四端均自动调用实体服务。
+
+旧实体文件按历史读取规则保留；历史 relation/evidence/checkpoint 元数据不参与当前关系判定，也不是普通名片可用性的前置条件。当前实体上传按权威类型、生命周期、当前证书及新 Schema 验收。
+
+Ownership 是 agent.md 之上的关系功能，不能因新增 Ownership 2.1 导致原有 agent.md 上传、下载、历史验签、展示或通信不可用。2.1 关系事实只由数据库中持久化的 sub_aid `agent.md` 与 owner_aid 自有 Storage 规范路径中的 `owner.md` 共同确认；数据库事务和 CAS 只负责完整 `agent.md` 的原子更新，不引入独立的第二份 2.1 关系事实。旧 SDK owner RPC 的 Auth JSONL 与 NS `ownership_proof` 是隔离的 legacy 兼容状态，不写 2.1 双文件，不构成 2.1 授权、lock/version/consensus，也不得覆盖已存现代声明。若数据库保留 owner_aid、关系版本或锁等索引列，它们只能服务于 `agent.md` 的 CAS 和查询，不能脱离两份文件单独判定 2.1 关系。只有需要当前 owner 关系的共识、授权和关系操作才执行 2.1 新鲜检查；关系缺失、legacy、stale 或关系依赖 unavailable 时，仅这些功能降级或拒绝授权，不能把普通读取兼容当作 current／consensus，也不能清空既有保护。
+
+后续审查和验收必须同时覆盖下面的兼容矩阵；四 SDK 与 NS 按同一边界检查，不能只验收新增关系流程：
+
+| 场景 | 普通 agent.md 功能及兼容要求 | 当前关系／授权边界 |
+| --- | --- | --- |
+| 旧 SDK 不携带新 Header 读取 | 普通 GET/HEAD 返回旧原字节、ETag 或 304，不因缺头或旧 schema 拒绝 | 缺头不补 current，不作为 2.1 能力或授权证明 |
+| 历史已签文件 | aid-only、已签纯正文、实体自签及旧关系材料按历史读取规则验原字节、实际 signer、指纹、链及签署时间；基础自身格式、目标 AID、真实外签与链仍须通过 | ownership 专属字段的词法／schema 无效只令关系 invalid 或不可授权，不作为完整文件历史外签失败；历史验签不产生当前 owner 权限，现代实体格式仍需完整字段 |
+| 普通展示与通信 | 不因关系缺失、legacy、stale、关系字段 invalid 或 owner 关系依赖 unavailable 阻断 | 只有实际需要 owner 关系的功能降级；严格上传、Ownership 文件解析和 fresh 授权仍拒绝无效关系材料，普通身份与历史文件验签执行各自规则 |
+| 新 SDK 上传／现代实体文件 | 当前 schema、当前可签证书、全部签名、实体代际、owner token 及 CAS 按适用格式严格验证 | NS 不得因请求缺新 Header 而跳过现代校验、agent.md CAS 或关系保护 |
+| 已存普通 legacy 关系正文更新 | 完整保留 owner／ownership／proof／release 的存在性、类型和值，使用当前外签与原 CAS | 普通更新不新建旧绑定、不自动迁入 2.1；原全文、摘要、ETag、关系快照必须可复验 |
+| 旧 SDK owner 操作 | 注册、绑定、转移、查询和解绑走隔离的 legacy RPC/operation ID 流程，兼容旧 proof 与 Auth JSONL 状态 | 只处理旧 `ownership_proof`，不写 2.1 双文件、不授 2.1 lock/version/consensus，不覆盖已存现代声明 |
+| 旧 Group 上传入口 | 始终兼容当前实体证书单签、实体 token 上传，检查生命周期及当前代际；Org 不开放 | 持续执行当前权威检查及存储 CAS；token 本身不证明证书代际 |
+| 本地上传失败稿 | 独立保留 local_draft_content；持有本地私钥材料的自有身份 resolve 本地优先，证书今天过期或不可签不阻断展示，仍为 unverified／非同步且不授 current 权限；显式远端读保留稿，应用显式重试确认后才清稿 | 普通及实体名片和普通 initial 失败稿重连不隐式 PUT；Ownership 任务／消息／outbox 及 Group/Org create/transfer 自身 checkpoint 恢复保留 |
+| 共识、owner 授权及关系操作 | 使用新鲜权威关系、生命周期和当前证书材料 | 必要材料缺失、stale、invalid、unavailable 均不授予 owner 权限，不能将故障降格为 unbound 或自动解锁 |
+
+### 1.1 分工与复用
+
+| 层次 | 本次设计中的职责 | 复用与限制 |
+| --- | --- | --- |
+| 应用 | 发起编排、处理审批、决定业务权限和可选托管策略。 | 无界面应用通过代码明确同意或拒绝；不必自行排列文件提交步骤。 |
+| SDK Facade / 编排器 | 保存本端任务、审批及消息，调用内部文件操作，恢复并通知进度。 | 沿用 AUNClient 的调用形式，不另建第二套 `client.ownership.*` 入口。 |
+| SDK 协议文件层 | 构造、签署、条件提交本方文件，检查新鲜共识。 | 五个文件方法仅供内部复用；不能通过文件方法隐式发起审批。 |
+| NS | 验收 `agent.md` 与 owner.md，按 CAS 原子持久化 sub 名片并同步名片副本。 | 复用 `GET/HEAD/PUT /agent.md`；不把独立关系表、证据表或日志作为事实来源。 |
+| Storage | 提供权威 owner.md、完整文件原子发布、公开读取和名片副本存储。 | 复用通用 Storage/FS 操作；owner.md 只有其命名空间所属 owner 可写删。 |
+| Auth / CA | 本身份认证、证书查询及当前状态验证。 | 不把 2.1 关系事实或审批状态机放回 Auth。 |
+| Message / Gateway | 传递普通加密 P2P 载荷和已有可信服务调用上下文。 | 不增加 ownership RPC 或服务端审批事件。 |
+| 业务执行端 | 实际授权时重新检查关系，先保存证据再执行。 | 不信任应用传来的共识布尔值。 |
+
+```mermaid
+flowchart TB
+    A[应用发起与审批] --> B[SDK Facade 与本端任务]
+    B <--> P[对端 SDK：普通加密 P2P]
+    B --> F[内部文件方法与共识检查]
+    F --> N[NS：权威 agent.md 与 CAS]
+    F --> S[本方 Storage：owner.md]
+    N --> Q[查询各 owner Storage 当前对象]
+    N --> J[提交后同步 agent.md 副本]
+    J --> C[sub Storage：agent.md 副本]
+```
+
+各服务独立实现，不 import SDK 或其它服务的代码。跨语言复用的是格式、测试向量和网络契约；同一 SDK 内可以复用文件方法、签名器及持久化设施。
+
+### 1.2 实施必须保持的不变量
+
+以下编号用于实施计划的验收追踪，不新增协议字段。
+
+| 编号 | 不变量 |
+| --- | --- |
+| D1 | agent.md 的目标、认证上传者和签名者均为 sub_aid；owner.md 的路径 owner、声明 owner 和签名者一致。 |
+| D2 | 原关系有效时，sub 不能清除 owner、只删 statement、改为 human 或 self-owner 来绕过锁。 |
+| D3 | 只有有效 release、权威删除，或原 owner 指定目标的有效 transfer_owner 能改变受保护关系。 |
+| D4 | 当前声明版本无声明为 0；绑定由双方明确选择一致正版本，SDK 默认当前可见基数加一、无声明时为 1；转移强制 v+1。release/删除不递增，清理后不保留独立历史版本上界。 |
+| D5 | NS 只在本地数据库事务中以 CAS 原子提交完整 `agent.md`；owner 的 `owner.md` 由其 Storage 独立条件提交。验收失败不保存候选文件，恢复只依据两份文件、事务提交结果和 CAS 条件。 |
+| D6 | owner 文件操作前重新核对当前完整原文、摘要和存在性；不增加 Storage 路径修订或 ABA 检测机制。 |
+| D7 | 故障、无效签名、缓存 404、旧备份不能解释为解绑或无锁。 |
+| D8 | SDK 审批只表达业务意图；任务、消息 ACK、ready 和 confirmed 提示不能替代 NS 验收。 |
+| D9 | 每次本端外部副作用前有持久待办；恢复先读权威事实，不盲目重新签名、回滚或补写。 |
+| D10 | 名片副本、消息补发、旧文件清理及可选凭据交接独立恢复，不回滚已提交关系。 |
+| D11 | 需要 owner 权限的执行端进行新鲜授权并先留证；历史复验不依赖历史证书今天仍可签名。 |
+| D12 | 降级和旧版兼容不能放宽锁；self-owner 使用同一套双文件和验收规则。 |
+
+## 2. 现有实现与改造定位
+
+本节保留实施前的代码基线与改造原因，不表示这些缺口在当前工作区仍未修复。
+
+### 2.1 SDK
+
+| 现有位置 | 已有能力 | 2.1 改造 |
+| --- | --- | --- |
+| [TS client.ts](../../ts/src/client.ts)、[JS client.ts](../../js/src/client.ts) | `_persistOwnershipRecords`、`_sendOwnershipControl`、`_resumeOwnership`、`_handleOwnershipMessage`、应用消息前拦截、审批及本地事件。 | 保留通路，任务改以 operation_id 关联，切换为双文件步骤和 NS 完成判断，替换旧 proof / escrow / 代传推进。 |
+| [Python client.py](../../python/src/aun_core/client.py) | `_persist_ownership_records`、`_send_ownership_control`、`_resume_ownership`、`_handle_ownership_message` 及重连恢复。 | 与 TS 同义实现；本地存储失败不能被当作“没有任务”。 |
+| [Go ownership_client.go](../../go/ownership_client.go) | `ownershipPersistRecords`、`ownershipSend`、`HandleOwnershipMessage`、`BindAID`、`BindOwner`、审批与释放。 | 调整任务键、模型和方法分工；保留现有 Client 接入，不将 GroupFacade.TransferOwner 当作 AID 转移。 |
+| [TS ownership-proof.ts](../../ts/src/ownership-proof.ts)、[JS 对应文件](../../js/src/ownership-proof.ts)、[Python ownership.py](../../python/src/aun_core/ownership.py)、[Go ownership_proof.go](../../go/ownership_proof.go) | 旧 ownership_proof、独立 statement 签名、ownership_release、托管工具。 | 旧结构仅作兼容识别；2.1 新建文件模型，不能改几个字段后继续使用旧独立签名。 |
+| [Python ownership_protocol.py](../../python/src/aun_core/ownership_protocol.py)、[Go ownership_protocol.go](../../go/ownership_protocol.go)，TS/JS 的 ownership-proof.ts | 旧 `aun.ownership.v1` 载荷与 request_id / proof_id。 | 新消息使用 `aun.ownership.sdk.v1`，独立校验、独立派发，避免旧处理器误执行。 |
+| [TS agent-md.ts](../../ts/src/agent-md.ts)、[JS agent-md.ts](../../js/src/agent-md.ts)、[Python agent_md.py](../../python/src/aun_core/agent_md.py)、[Go agent_md_manager.go](../../go/agent_md_manager.go) | 名片构造、签署、上传、ETag 缓存、待上传恢复；存在 uploadAs / upload_as / UploadAs。 | 增加内部“提交已签署原始字节”能力、条件头和 NS 元数据；2.1 不走代理身份路径。 |
+| [Go agent_md_http.go](../../go/agent_md_http.go) 及其它 SDK 的名片 HTTP 实现 | GET/HEAD、ETag 和旧 owner 授权头。 | 解析新鲜检查结果，保留签名原始字节，普通 2.1 主体停用 legacy V1 的 `X-AUN-AgentMD-Owner-Authorization`；实体不再生成或强制额外 V2 上传授权；全部 NS 请求带 multi-v1。 |
+| 四端 aid-store / aid_store 的注册流程及 Client 的 registration_intent 恢复 | 注册意图可生成旧 proof 名片，再通过旧绑定路径继续推进。 | owner 意图只存本地，首次确认无历史关系时发布无 owner 的本方名片；连接后进入一次 2.1 绑定编排。已存在关系不得走初始化覆盖。 |
+
+现有 AgentMD schema 已有 UTF-8、大小、重复键和类型等校验基础。应在现有校验器增加 2.1 的角色与字段规则，而不是丢弃这些约束重写一套宽松解析器。
+
+Browser SDK 的 metadata 存储为异步；当前缺失存储能力时可直接返回、解析失败可清空记录的行为不能用于 2.1 编排。无法可靠保存审批和待办时，停止会产生文件或消息副作用的操作，仍允许只读共识查询。
+
+### 2.2 NS
+
+NS 下列路径以 [Go 服务根目录](../../../extensions/services/nameservice/go) 为基准。
+
+| 现有文件 / 方法 | 当前行为与缺口 | 修改方式 |
+| --- | --- | --- |
+| `internal/httpserver/agentmd.go`：`get`、`put` | 有 LRU、writeGen 和名片 CAS；没有完整的 2.1 关系验收。get 会把部分 DB 故障映射为 404。 | 引入统一关系检查入口；新鲜 GET/HEAD 绕过缓存并先确认释放；PUT 无论有无检查头都执行基于 agent.md CAS 的保护。 |
+| 同文件：`validateAgentMDUpload`、`enforceStoredOwner` | 完整文件验签已有；锁主要依据旧名片 owner/proof。 | 拆开本身份验签和关系验收；原 owner 从持久化 agent.md 的 ownership 字段及旧名片确定，不能取待上传目标。 |
+| 同文件：`authorizeAgentMDUploader`、`verifyOwnerAgentMDAuthorization`、`verifyOwnershipProof` | 支持旧 proof、owner 授权头和群 owner 代理分支。 | 普通 2.1 本身份上传，旧分支不得覆盖已有关系。Group/Org 按权威类型分流到当前生命周期、实体主签、全块验签及 owner token 上传校验，不落通用账本，不允许自声明改类型绕锁。 |
+| `internal/httpserver/agent_md_schema.go` | `aidParseTailStrictAt`、`validateStrictAgentMDMeta`、旧 ownership 校验。 | 复用严格解析，补 TAG、statement/action、文件角色和当前证书验证。 |
+| `internal/repository/mysql.go`：`CompareAndSwapAgentMD` | CAS 范围只有名片内容、摘要和更新时间。 | 让 ownership 字段随完整 `agent.md` 一起原子提交；不增加独立关系事实表或证据表。 |
+| `internal/httpserver/agentmd_cache.go` | 当前名片缓存。 | 继续供普通展示；不能作为最终授权依据。 |
+| `internal/httpserver/sync.go` | 现有 sync_agent_md 是 SDK 拉取名片快照。 | 保留原用途；另实现 NS 提交后的 Storage 副本同步，不借该接口代上传。 |
+| `internal/httpserver/router.go`：`applyBrowserCORS` | 当前 expose headers 没有 ownership 三个响应头。 | 允许浏览器读取协议、关系版本和锁头，保留现有预检处理。 |
+| `cmd/nameservice-go/main.go` | 已装配 CA、Gateway 等 resolver。 | 分别装配关系变更的 Storage/当前证书核验和名片同步 worker；可信 Org 分类回填完成后，CA normal 不再额外查询 Org 判负。 |
+
+### 2.3 Storage 及周边服务
+
+Storage 下列路径以 [Go 服务根目录](../../../extensions/services/storage/go) 为基准。
+
+| 现有文件 / 方法 | 当前能力与缺口 | 修改方式 |
+| --- | --- | --- |
+| `internal/service/service.go`：`PutObject`、`CreateUploadSession`、`CompleteUpload` | 已有 overwrite、expected_version 及提交时版本判断。 | 沿用既有完整文件原子发布，owner 更新不得先删后建。 |
+| 同文件：`DeleteObject`、`deleteResolvedObject`、`FSRemove` | 沿用既有删除能力。 | SDK 清理前核对当前 NS 与本任务完整 owner 原件，不增加删除条件接口。 |
+| 同文件：`HeadObject`、`FSStat` | 现有对象查询。 | 补不经正负缓存的权威查询及明确的路径不存在结果；故障和恢复未完成单独失败。 |
+| 同文件：FSRename、FSCopy、MoveObject、DeleteFolder、BatchDelete、SetVisibility、CheckAccess 等 | 多种目录、路径和授权入口。 | 在最终解析路径后统一执行 owner.md 保护，覆盖父目录、移动、软链、挂载及批量操作。 |
+| `internal/service/handlers.go`、`internal/contracts/methods.go`、`internal/rpc/request_context.go` | 通用 Storage/FS 契约、路由与请求认证上下文。 | 贯穿新增条件和权威结果；NS 镜像授权只认经过认证的服务身份。 |
+| `internal/cleanup/`、`internal/collab/service.go` | 自动清理和其它文件修改通路。 | 不允许自动清理或第三方修改间接删除规范 owner.md；保护下沉至公共写入路径。 |
+
+Auth、Message、Gateway 保留既有通信和认证通路。R02 的权威类型由 CA 持久保存可信 Org 分类及回填完成标记：仅认证的 Org 服务可登记，Org 恢复分页回填全部生命周期记录（含 dissolved），全部成功后提交完成标记；创建先登记，失败时保守保留分类，初签/rekey 不覆盖它。回填完成后 NS 对 CA normal 不再查询 Org；未完成时继续保守核对，不能将 Org 故障降为 normal。Org 仍使用 signing 证书，分类不包含 owner 关系事实。
+
+## 3. 持久模型
+
+### 3.1 NS：完整 agent.md 与 CAS
+
+关系事实仅有 NS 的 sub agent.md 与 owner Storage 的 owner.md。NS 保存 sub 完整签名原字节、摘要、ETag 和 CAS 元数据；owner.md 保留完整 owner 签名原字节。两者分别使用既有完整文件原子发布。
+
+release/权威删除只令当前关系返回 released；NS 不改 sub 签名字节、不递增声明版本，也不保留独立终局。sub 后续按原 ETag 自签清理；无声明时投影 0，再绑定用 1。旧声明仍在时，仅不同 owner 的新绑定以当前可见版本加一；同 owner 再绑定必须先由 sub 按现有授权清理，再发布新 declare，避免覆盖唯一的当前 release 材料。清理后不保证仅凭当前材料识别全部历史重放。
+
+事务不含远端调用；查询/副本索引不能代替两份材料，也不定义关系表、证据表或同步表为关系事实。
+
+### 3.2 Storage：沿用完整文件存储
+
+不增加逻辑路径修订、删除历史或关系事实记录。owner 操作前再读当前完整原文、摘要和存在性，发现变化则停止旧操作；完整文件原子替换失败时保留旧文件。再读不能识别同内容 ABA 或完整文件回滚，也不提供跨服务一致快照。
+
+Storage 不记录 ownership 的 locked/unlocked、关系版本或 release 终局。它仅证明特定命名空间的路径在本次权威查询时存在什么，或已确认不存在。路径删除记录与“NS 确认释放”是不同事实。
+
+### 3.3 SDK：一个本端任务，不建跨方事务
+
+每个 SDK 以 `operation_id` 为键保存任务；同一 sub_aid 的本端推进串行。下表是内部记录分组，不增加 P2P 字段。
+
+| 分组 | 必须保存的内容 |
+| --- | --- |
+| 固定上下文 | operation、参与 AID、base_relation_version、target_relation_version、发起方、本端角色。创建后不可变。 |
+| 审批 | 本端决定、各审批 AID 已确认的决定和所覆盖的角色。未决、同意、拒绝必须区分；同一决定不能被迟到消息改写。 |
+| 文件进度 | 各本方文件完整签名原始字节、摘要、起始双文件证据及 NS 原 ETag；接收方首次验证转移授权的全文摘要 authorization_sha256 和实际 expires_at，恢复不换字节、不延期。 |
+| 通知待办 | 待发送的相同 operation_id 载荷及接收 AID；接收幂等键为已认证发送者、operation_id、action。 |
+| 结果和清理 | 当前本端 step、已新鲜核验的结果、待清理完整原件及摘要、最近可重试错误。 |
+
+step 表达“本端接下来做什么”，不组合成三方状态笛卡尔积。NS 的 locked/unlocked、SDK 审批决定、文件是否已发布、任务是否已完成分别保存；清理待办可在关系 completed 后继续存在。
+
+本地存储采用各 SDK 已有设施。写入必须可靠完成后才能发消息、发布文件或发出不可恢复的完成通知；存储损坏时不可清空后自动接着批准。Browser 通过异步存储事务完成，多标签页不共享可互相覆盖的陈旧整份任务快照。
+
+实现采用每任务记录及记录修订，读取、比较和写入在本端数据库事务内完成；审批决定与待发送项一次保存。现有普通 metadata getter 不能区分读取失败和空值时，增加专用于任务的错误返回及条件更新能力，不改变其它 metadata 使用者的语义。自定义存储不满足该能力时，2.1 有副作用的编排不可用。
+
+起始证据统一保存 `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 基线。
+
+## 4. 文件层实现
+
+### 4.1 解析、签名与证书
+
+实现分为原始签名容器、YAML 字段、文件角色三个校验步骤，保留当前严格解析基础：
+
+1. 限制 payload 4096 字节、全部尾签区 2048 字节，拒绝非连续块、末尾非空白、非 UTF-8、重复键、YAML tag/锚点/别名及未知 ownership 字段。
+2. 尾标识接受兼容前缀及合法 TAG；常规输出 agent.md 使用 `AUN-SIGNATURE-AGENTMD-V2`，owner.md 使用 `AUN-SIGNATURE-OWNERSHIP-V2`。角色由路径及 AID 决定，不由 TAG 决定。
+3. statement.version 固定为 2，包含 declaration_id、owner_aid、sub_aid、relation_version、declared_at；agent.md 只允许 statement，owner.md 另校验 action 及 transfer 字段。
+4. Store raw/document 统一底层 ECDSA P-256/SHA256；document 按每块之前完整 prefix 逐块签验，首块维持旧正文裸签，不重新序列化 YAML、换行或 Unicode。服务端独立实现同构 core，不依赖 SDK 代码。
+5. 新验收检查证书链、所属 AID、指纹及当前有效/吊销/可签名状态；签名块 timestamp 不能独自证明历史授权时间。
+
+双方声明按容器版本、owner_aid、sub_aid、relation_version 匹配，declaration_id 与 declared_at 可以不同；不能沿用旧 proof 的整段 statement 相等判断。sub 在锁下做普通名片更新时，则须保留自己原来的完整 statement。
+
+TS/JS 的 [cert-utils.ts](../../ts/src/cert-utils.ts)、[JS 对应文件](../../js/src/cert-utils.ts)，Python 的 [_cert_utils.py](../../python/src/aun_core/_cert_utils.py)，Go 的 [aid.go](../../go/aid.go) 均有尾签名基础。实施前 TS/JS/Python 正则只接受未加 TAG 的标识；2.1 在这些位置兼容协议规定的合法 TAG，并与 NS 的 `aidParseTailStrictAt` 使用相同向量验收。
+
+通用 Store.sign/verify 的 document 模式只做原始尾签容器和逐块签验，不判断 YAML；agent.md 与 owner.md 都复用它，再由业务调用者检查资源身份和 Schema。append 已有链才在末字节非 LF/CR 时补 LF，无旧块首签缺换行则拒绝；TAG 不授权、附签 signer_aid 必填、总尾区 2048 字节，精确规则见协议 §2.4。
+
+owner.md 不具备名片必填的 name/type/version，不能直接复用“必须是 agent.md”校验。复用底层签名容器，在各模块内分别实现两种角色 schema；NS 不依赖 SDK 的包。
+
+当前证书材料通过既有权威查询获取，精确核对 AID、证书 DER 指纹、实际 `active_signing`、完整证书链及签名 OCSP。OCSP 绑定本次链选定的直接 issuer，核对 CertID serial、issuer name/key hash 与 ResponderID，只接受该 issuer 亲签及同一 issuer 内嵌证书，不接受委派 responder；链获取和 OCSP 接收后用当时当前时间检查新鲜度，末尾再次核对链有效期。未知签名身份类型时省略 `key_purpose`，不得将 owner.md 的签名者一律视为普通 signing 身份。Group/Org 主签证书属于实体并匹配 frontmatter 指纹，owner 可另附签，附签同样必须验证；已知群实体证书查询使用 `group_identity`。CA `observed_at` 与 OCSP `ThisUpdate` 距当前时间不得超过 30 秒，`ProducedAt` 不得超过 90 秒，三者未来偏差均不得超过 5 秒；`NextUpdate` 严格晚于当前时间和 `ThisUpdate`。CA 的 Go OCSP 签发器按分钟截断 `ProducedAt`，因此其窗口包含取整误差，其它当前状态窗口不变。NS 在最终提交前按当时的服务端时间重新核对；材料不可确认返回 unavailable，已知坏签名、无效链或吊销返回 invalid。
+
+### 4.2 五个内部文件方法
+
+方法名沿用编排指南，实际内部调用还传入任务中固定的版本、文件和提交条件。这些上下文不是新增的 Facade 参数。
+
+| 方法 | 实现步骤 | 稳定返回点 |
+| --- | --- | --- |
+| declareOwneraid | 校验本端为 sub；从 NS 当前原文准备目标声明；先保存完整已签文件，再按原 ETag 自身份 PUT。 | 文件是否已被 NS 验收可确认；失败不生成新 declaration_id 重试。 |
+| declareSubaid | 校验本端为 owner/new_owner；准备目标版本 declare；重新核对当前完整原文、摘要和存在性后原子发布规范路径。 | 本方文件保存成功，只表示 owner 文件已发布。 |
+| revokeOwneraid | 新鲜确认原 owner 已 release/删除，按原 ETag 自签清理 owner/ownership。 | 清理后无声明，版本投影为 0。 |
+| revokeSubaid | 核对当前原关系及 owner 原件，原子发布当前声明版本的 release；请求 NS 新鲜检查，记录本地任务结果和后续清理。 | 发布与 NS 确认是两个独立进度；确认前保留 release。 |
+| transferOwneraid | 核对本端为原 owner、原版本仍有效；签署指定目标、v+1 和有效期的 transfer_owner，条件替换原 owner.md。 | 原授权已保存；不依赖另外两方的文件摘要或提前发布。 |
+
+同一方法可由 Facade 和消息处理器复用。文件层不请求对端同意、不发送业务申请、不创建新的 operation_id。撤回未提交转移是原 owner 的条件替换：同版本 declare、去掉 transfer；按原流程恢复，不能删除文件模拟撤回。
+
+### 4.3 共识检查
+
+`checkOwnershipConsensus(sub_aid?)` 不创建任务。省略 sub_aid 时使用当前身份；任务内部调用可以提供待验收 owner 和版本上下文，以识别 single_sided，但不能把待办当作 NS 已保存关系。
+
+先新鲜读取 NS 原文和 ETag，再核验规范 owner.md，最后复核同一 agent.md、ETag 及 owner 文件原文和存在性。匹配 release 或权威删除返回 released；不写独立终局、不改 sub 文件、不递增版本。材料变化或超时返回 unavailable，普通下载不以此为前置。
+
+当前 agent.md 无声明且无目标上下文时返回 unbound，版本投影 0；仅一方发布可报告 single_sided。released 仅用于当前声明仍在且 owner.md 已 release/权威删除。其余结果使用 consensus、invalid、unavailable。
+
+## 5. Storage 具体改造
+
+### 5.1 通用操作的最小补齐
+
+以下定义 2.1 所需的通用 Storage/FS 契约；本轮实现与契约测试结果见实施账本第 13 节，不增加 ownership RPC。
+
+| 能力 | 拟议实现 |
+| --- | --- |
+| 权威读取 | 沿用现有 Storage/FS 权威查询与完整正文读取，绕过正负缓存；核对请求 owner、bucket、规范 path、exists、sha256 和完整原文。服务身份由认证通道核对，不相信自报字段。 |
+| 路径不存在 | 明确当前路径不存在；DB 故障、路由 404、无权读取、恢复未完成必须失败，不能返回 exists=false。 |
+| 创建 / 替换 | 沿用现有 overwrite 和 expected_version；SDK 先核对保存的起始存在性、完整原文和摘要，不增加 Storage 条件字段。 |
+| 删除 | 沿用既有删除接口；删除前重新核对当前 NS 与本任务完整 owner 原件，后续文件出现时停止。 |
+| 上传 session | 创建 session 时固化路径和条件，CompleteUpload 真正发布前再检查；force/overwrite 不能覆盖 ownership 文件的必需条件。 |
+| 原子发布 | 规范文件使用独立上传临时对象，complete 沿用 create 返回的同一 session_id，核对会话申请者/目标/期限并验证完整内容后原子替换；失败时规范路径仍指向旧完整文件。 |
+
+客户端适配将结果规范化为存在、不存在或不可确认三类；前后重读完整原文、存在性及摘要必须对应，不接受元数据指向新版而下载得到旧缓存正文。
+
+### 5.2 权限和路径保护
+
+owner.md 保护在最终目标解析后执行，并同时检查原始路径和最终路径，防止通过别名、路径编码、大小写处理、挂载或软链绕过。命中 `owner_aid:/sub_aids/{sub_aid}/owner.md` 的修改只接受经认证的同一 owner_aid；父目录删除、路径移出或覆盖同样属于修改。
+
+ACL、token、目录授权和协作写入不能授予第三方该能力。禁止设置使文件不再公开可读的可见性或自动到期删除策略；系统 GC 只能回收已不被当前对象引用的 blob，不能自行移除声明路径。原 owner 通过合法其它入口执行的真实删除仍是解绑，不要求这些入口伪造 release。
+
+NS 复制名片使用可信服务身份，仅允许写 `owner_aid=sub_aid, bucket=default, object_key=agent.md`。校验必须来自现有受认证的服务上下文及目标 NS 的权限范围，不能接受客户端自报 service_name；该内部镜像以 `storage.put_object` 完整原子写入，无需客户端 HTTP 上传会话。该权限不覆盖 owner.md，也不赋予 NS 代签能力；Storage 副本不替代 NS 当前权威名片。
+
+### 5.3 删除后重建
+
+创建响应丢失时先核对当前完整原文与本任务已签文件；相同则仅确认，否则仅在保存的起始存在性、原文和摘要仍匹配时恢复。已观察到后续变化时停止；不能凭当前材料排除同内容 ABA 或历史回滚。
+
+清理 release 或旧转移文件前重新核对当前 NS 与本任务完整原件和摘要。对象已变或无法确认时保留待办或结束旧清理，不替换原件继续删除。
+
+## 6. NS 验收与提交
+
+### 6.1 同一 sub_aid 的处理路径
+
+新鲜关系检查和改变关系材料的名片写入口复用同一验收逻辑；普通读取和完整保留关系材料的正文更新不强制检查当前关系。普通更新先比较已存和候选中的完整关系材料，再按自身签名及原 ETag/CAS 提交；owner 网络读取不持有最终提交锁，提交时重新核对同一 agent.md 快照，关系依赖迟缓不能占用普通正文更新的锁。
+
+1. 按 sub_aid 串行读取当前 agent.md 和 CAS，区分不存在与数据库错误。
+2. 从已存原文确定原 owner/版本，不用候选新 owner 判断旧关系。
+3. 核验当前 owner.md 的签名、路径、身份、版本和完整原文；匹配 release/权威删除返回 released，无效或不可用不授 owner 权限。
+4. GET/HEAD 返回原字节和关系投影，不存额外关系事实。PUT 校验上传身份、原 CAS、完整候选及适用绑定/转移材料。
+5. 最终重新读取 owner 原文和存在性，复核 agent 原 ETag、证书及转移期限；材料变化或超时不能沿用旧结果。
+6. 短数据库事务比较原 CAS，原子提交完整 sub 自签文件；失败回滚本次名片提交。
+7. 提交后刷新缓存并同步副本；响应丢失不撤销已提交文件。
+
+候选失败不撤销 owner.md 的当前 release。NS 不修改或重签 sub 文件，也不持久化独立释放代际。
+
+### 6.2 关系转换表
+
+| 当前材料 | 处理 | 结果 |
+| --- | --- | --- |
+| 无有效关系，当前可见版本 v（无声明为 0） | 双方明确签署一致正版本并按原 CAS 提交；SDK 默认 v+1、无声明时为 1。 | 匹配时 consensus/locked；NS 不独立强制绑定上界，不齐不保存候选。 |
+| 原 owner 有效 declare | 正文更新保留 owner 和完整 statement。 | 版本不变，ETag 可变。 |
+| 有效 transfer_owner | 转移须匹配目标、v+1、期限及目标双文件。 | 直接提交目标 sub 自签文件。 |
+| transfer_owner 过期 | 不转移，继续核验旧关系。 | 不自动释放。 |
+| 匹配 release 或权威删除 | 动态返回 released，允许 sub 清理；未清理时仅不同 owner 可重新绑定。 | 原版本 v 不变；清理后投影 0，同 owner 再绑定由 SDK 默认使用 1。 |
+| 无效或不可确认材料 | 不授 owner 权限，不以故障解锁。 | invalid/unavailable；普通名片继续可用。 |
+
+不维护退休版本或历史最大值。清理后版本可重复；重试必须核对原文、摘要和 CAS，不能只比较数字。旧声明未清理时，同 owner 的 bind 在创建任务、消息或文件副作用前返回 conflict/action_required，要求应用先由 sub 按现有授权清理；不自动编排清理后再绑定。
+
+### 6.3 HTTP、缓存与错误
+
+新鲜 GET/HEAD 即使命中 ETag 或 If-Modified-Since，也必须先完成关系检查，再决定是否返回 304；响应携带当前协议、版本、锁头。原始名片 ETag 未变不代表 owner 没有释放。
+
+普通响应同样返回三个关系元数据头，但不替代新鲜检查。普通读取可继续使用名片展示缓存；缓存条目与持久化 `agent.md` 的 CAS 条件不符时重新回源，不能拼接旧名片和新字段来发放权限。缺少 `X-AUN-Ownership-Check`、来自旧 SDK、伪造 owner 授权头、删除名片或重新注册同一 AID，都不得跳过写入保护。
+
+拟采用的 HTTP 错误映射如下；这是对现有 handler 的实现补齐，不新增 RPC：
+
+| 情况 | HTTP / SDK 处理 |
+| --- | --- |
+| 认证上传者不符，或受锁保护的关系被改写 | 403；区分身份错误与 owner_locked。 |
+| 文件、角色、签名或目标声明无效 | 400；关系检查归类 invalid。 |
+| 文档或 Storage 条件不满足 | HTTP 名片条件失败为 412；Storage 沿用通用版本冲突类别。停止旧提交。 |
+| 名片条件满足，但关系版本已变化 | 409；重新读取，不能自动换最新版本再覆盖。 |
+| 2.1 关系或现代实体格式写入缺少所需条件 | 428；旧客户端旧格式入口可缺新 Header/CAS，仍执行服务端原子 CAS、当前快照及关系保护。 |
+| NS、Storage、CA、名片持久化或当前核验不可用 | 503 / unavailable；不伪装成不存在。 |
+
+2.1 响应头只能由真正执行上述检查的 NS 返回。浏览器 CORS 同步暴露这三个头，否则 JS 无法判断能力和验收结果。
+
+### 6.4 单实例与将来的多实例
+
+当前使用以 sub_aid 为粒度的进程内串行保护，覆盖最终权威读取、关系判定与本地提交；SQL 事务只包围本地数据修改，不包围远端调用。现有 writeGen 不能替代持久版本和所有入口共用的关系串行保护。
+
+未来多实例复用同一处理接口，换为共享数据库及分布式串行保护。提交处必须校验递增持锁代号或等效 fencing 条件；租约失效的旧持锁者即使晚到，也不能写入。首次创建、字段清理和副本同步同样需要防旧实例覆盖。该扩展是启用多实例前的门槛，当前阶段不强行引入分布式锁服务。
+
+Storage 当前完整原文复核与 NS 提交之间没有跨服务一致快照，不提供 ABA 或完整文件回滚检测保证。按协议最终验收时点、服务端验证时限和实际提交裁决竞争，不声称 owner 发布撤回的一瞬间能取消所有在途请求。
+
+### 6.5 名片同步
+
+同步 worker 从持久化的 NS 当前完整原文，以受限服务权限条件写入 `{sub_aid}:/agent.md`。写前和写后比较 NS 当前 ETag 与全文摘要；文档已更新则继续补齐最新版本。关系版本相同的普通更新也必须同步。
+
+同一 sub 的同步串行；提交副本时比较本次读取的文档条件，不能把已被新名片更新的内容覆盖。Storage 失败、响应丢失或 NS 重启后重新读取当前权威文档及目标完整文件，再幂等执行。副本失败不改变关系 completed 的判定。
+
+## 7. SDK 编排与应用接入
+
+### 7.1 七个 Facade 与内部复用
+
+| Facade | 调用的内部工作 | 本端应用责任 |
+| --- | --- | --- |
+| bindOwneraid | 保存 sub 发起任务，发送 bind.request；owner 同意后由 owner declareSubaid，再由 sub declareOwneraid。 | sub 发起即表达本端意愿；owner 处理审批。 |
+| bindSubaid | 保存 owner 发起任务，等待 sub 同意，然后同上推进。 | owner 发起；sub 明确同意或拒绝。 |
+| acceptOwnershipRequest | 对已有请求持久保存决定、回复，并仅推进已经满足审批和权威前置条件的步骤。 | 按界面或代码策略决定，未决定保持等待。 |
+| rejectOwnershipRequest | 持久保存拒绝并回复，结束该待审批任务。 | 只用于尚未作决定的审批；不通过拒绝回滚已发布文件。 |
+| releaseSubaid | 发布 release → 新鲜确认 → 通知 sub 自签清理 → 条件清理旧文件。 | 不等待 sub 在线，任务目标版本为被释放声明的当前版本。 |
+| transferSubaid | 收齐新 owner 与 sub 同意 → transferOwneraid → 新 owner declareSubaid → sub declareOwneraid。 | 只有原 owner 可发起，两个接收角色均参与意向审批。 |
+| checkOwnershipConsensus | 调用第 4.3 节的统一检查器。 | 展示结果或触发业务执行端自己的新鲜授权。 |
+
+发起方法先查询权威现状固定起始版本，在发送消息、发布文件或删除等副作用前保存任务，返回 operation_id 与本端进度，结果由本地事件继续通知。面向应用只导出这些方法和必要类型，五个文件方法不导出。Python/Go 采用本语言命名习惯，但语义和消息 action 保持一致。
+
+内部编排器与消息处理器推进同一任务；禁止收到 owner.ready 后再调用 bindOwneraid 创建第二个任务。普通名片更新仍使用现有名片 API，但必须完整保留锁定的关系字段。
+
+普通 `agent` 注册的 owner 可选；指定 owner 时，owner 意图先与 SDK 生成的固定 operation_id 一起持久保存；初始名片不写 owner 或旧 proof，并以条件创建提交。连接后用该 ID 进入绑定编排，响应丢失或重连都读取原任务，不另建操作、不默认批准；未指定 owner 时只初始化普通名片，不创建关系任务。NS 不可用时保留已有意图；已有关系或未知旧待上传文件不能由初始化路径覆盖。Group/Org 身份准备不生成通用注册意图；创建自动 owner 绑定，owner 持有实体材料，用实体私钥主签并以本人 token 上传，可选追加本人附签。专属 pending 保存实体命名空间、固定 owner、实体证书指纹、原完整多签文件及原 CAS，恢复不补造条件或跨 owner/rekey 代际重签。
+
+普通显式上传与注册初始化分别保存待办。普通名片候选在本地 schema 和外层签名验证通过后、首次远端 preflight 前，先独立保存到既有元数据的私有 `local_draft_content`，不覆盖已确认的远端 content/ETag；自有且持有本地私钥的身份默认 resolve 优先返回该稿，标记 unverified、in_sync=false、source.agent_md_fetched=false。显式 download／forceRefresh 仍读取远端权威内容并保留草稿，只有服务端确认对应候选提交成功才清稿。重连不自动重传普通失败稿，普通注册 initial 失败稿同样需要应用显式重试；即使存在普通 pending 也不隐式 PUT。Ownership 2.1 任务及注册意图的既有恢复不能替代失败稿的显式重试。取得可靠 NS 原条件后，仍在 PUT 前持久保存完整签名字节、原 If-Match／If-None-Match 及关系快照；显式重试既有 pending 时先核原条件，缺失则保留原元数据及原错误，不因远端同字节而清除。2.1 正文更新核对原 owner、完整 statement、relation_version 和 lock。已有普通 legacy owner/proof 或 2.0 关系仅允许更新正文，完整保留 owner、ownership、ownership_proof、ownership_release 的存在性、类型和值；新 metadata 和外签执行当前规则，不自动迁入 2.1。该分支持久保存原全文、摘要、原 ETag 及完整关系快照，重试核对 base/candidate/remote 和原条件；全文及提交 ETag 均对应原提交时只观察确认，否则仅按仍成立的原条件重传原 blob，不刷新 CAS、不重签、不补造上下文。其它缺原上下文的旧待办仅允许版本 0 / unlocked 的初始关系；实际关系变更由对应 Ownership 任务恢复。
+
+Group/Org 名片失败稿及 pending 保留实体命名空间中的完整多签原文、原 CAS、固定 owner 和实体证书指纹，由应用显式重试，post-connect／重连不隐式 PUT。重试先验证完整原件及当前 owner、状态和证书代际，原条件完整且同代际原文／ETag 已确认提交时只观察完成。转移、rekey 或解散后停止旧代际待办，不更换身份、指纹或条件重签。新 SDK 现代上传不再保存、刷新或检查额外 V2 授权及过期窗口；旧 V2 兼容入口仍按协议 §2.5 校验；普通文件签名与当前证书检查保留。专属 create/transfer 自身 checkpoint 恢复机制不变。
+
+### 7.2 转移的默认编程顺序
+
+```mermaid
+sequenceDiagram
+    participant O as 原 owner SDK
+    participant N as 新 owner SDK
+    participant S as sub SDK
+    participant NS as NS
+    O->>N: transfer.request
+    O->>S: transfer.request
+    par 两方独立审批，顺序不限
+        N-->>O: accept 或 reject
+    and
+        S-->>O: accept 或 reject
+    end
+    alt 收齐两方同意且原关系复核通过
+        O->>O: 条件发布授权
+        O-->>N: transfer.ready
+        O-->>S: transfer.ready
+        N->>N: 核对授权并发布自己的 declare
+        N-->>S: owner.ready
+        S->>NS: 自签目标 agent.md，条件 PUT
+        NS-->>S: 持久验收结果
+        S-->>O: relation.confirmed 提示
+        S-->>N: relation.confirmed 提示
+        O->>NS: 新鲜核验后完成并条件清理
+        N->>NS: 新鲜核验后完成
+    else 任一方拒绝
+        O->>O: 持久停止待审批任务，不发布授权
+        O-->>N: operation.stopped
+        O-->>S: operation.stopped
+    end
+```
+
+任一尚未决定的审批方拒绝时，原 owner 停止任务并通知另一方，不发布授权。授权已发布后的“停止”只停止本端推进；必要的撤回按协议条件写回 declare，并重新确认实际结果。已提交转移不能取消，反向转移须由新 owner 发起。
+
+协议仍允许乱序文件提交；这条顺序是 SDK 默认便利流程，不成为 NS 的请求先后校验，也不要求原 owner 获取目标文件摘要。
+
+原 owner 收齐同意后，按本端有限授权时长策略生成 expires_at 并连同已签文件持久保存；审批等待不提前消耗已发布授权期限。重试复用同一授权，不自动延长；过期后再次转移须新的明确发起和审批。
+
+三个协议时间字段 declared_at、expires_at、签名 timestamp 均为 `1..9007199254740991` 的十进制正整数原词法。先检查词法与范围，再转数字或日期；非法值归 invalid。范围内仍执行证书、当前时钟和过期语义，不另设年份上界。
+
+重复发起先查本端身份、发起方、operation、sub、原 owner、新 owner、base/target 版本匹配的进行中任务，并核对原声明完整原文、摘要和原 CAS，早于新操作资格检查；清理后版本数字可重复，不能仅凭数字认定同一关系。复用原 ID、审批、原签名字节、提交条件和期限。目标已提交时新鲜核验完整本人证据完成原任务；同代际不同意图 conflict 且不建第二任务，并发相同意图只保留一个。后代际先停止旧任务再发起新合法任务；历史 completed 不凭参数相同复用，拒绝、停止、不可重试 error 不复活。
+
+错误分类与业务状态分别保存：服务、网络或验证依赖不可用是 unavailable，确定无效的签名、证书、文件或证据是 invalid。权威元数据、正文摘要不一致，以及 Storage Base64 传输封装损坏均为 unavailable；摘要匹配后确定非法的 UTF-8、文件字段或签名为 invalid。等审批/材料、暂不可用、unsupported_protocol 为 pending/true；代际替代、目标变更、授权过期、原条件失效为 stopped/false；确定证据无效为 error/false；拒绝 rejected/false，完整目标确认 completed/false。预检失败不建任务；存储/CAS/租约失败 persistence_unavailable 且保持已存记录、停止副作用。停止前先核精确目标完成事实，completed 的通知/清理失败只追加错误和待办，迟到消息不重启终态。
+
+### 7.3 消息、安全校验与本地事件
+
+完整 action、载荷和事件表沿用编排指南第 2.5、2.6 节，不再定义第二套消息。实现上对 `aun.ownership.sdk.v1` 使用单一入口，实时 push、离线 pull 和重连重放都进入该入口：
+
+1. 解密后、投递应用 message.received 前识别控制类型；保留原始控制 JSON 以检查重复键及关系版本的整数词法，不能只校验解析后对象。未知 action、无效载荷也作为控制消息消费。
+2. 发送者取消息层确认的 from_aid；校验 action 方向及已有任务的固定上下文，禁止依据载荷自报身份批准。
+3. 请求、审批和 ready 各按所在阶段读取权威关系。未发布转移授权的审批阶段不能要求该授权已存在；实际发布目标前则必须检查它。
+4. 将有效待办和幂等键持久保存后才结束处理；存储失败保留待解密、排序及补拉来源，不推进游标、不标记已投递、不 ACK，也不转为普通应用事件或不可解密消息。
+5. 审批先持久再回复；消息先存待发送项再调用已有 message.send。持久 P2P 不设置 volatile TTL。
+6. ready、confirmed 和 ACK 都只触发重新读取与推进；不能携带或代替关系授权。
+
+事件仍由已有本地 dispatcher 发布。应用可按 operation_id、事件名和 step 去重；恢复可再次发布待审批事件，但不得覆盖已保存决定。收到另一操作的新版本后，旧任务转为停止推进，不能更新 ETag 后强制继续。
+
+绑定／转移 completed 的判断使用当前 NS 目标 owner、目标版本和完整材料，并按本端角色比较自己持久保存的文件摘要：sub 核对 agent.md，owner/new_owner 核对 owner.md，转移原 owner 核对其保存的授权和固定目标；不要求新增消息字段交换目标文件摘要。sub 上传响应丢失时必须比较自己保存的文件摘要；其它参与方不能仅看到任意 v+1 就报成功；原 owner 缺少本任务已保存的转移授权也不能冒认外部转移完成。恢复时校验持久验收证据，包括验收时的 NS ETag、agent.md 全文 SHA256、实际 lock／owner／relation_version，以及按本端角色保存的本人已签原始完整字节、摘要和原提交条件；绑定、转移另须有 owner.md 全文 SHA256及本端批准。本人原件还须按文件角色、签名者、owner/sub、base/target、action、转移目标/期限及原条件匹配任务固定上下文；合法历史只复验结构和上下文，不要求现在仍可签或授权未过期。缺失、损坏证据的旧 completed 返回 persistence_unavailable，不只信任阶段标记，也不从当前网络补造历史证据；合法历史完成不要求当前 NS 仍停在历史版本。release completed 接受本任务声明 v 的新鲜 released/v，或严格关联本任务的真实 unbound/0；任务 base/target 及历史 verified 仍为 v，实际完成证据不得伪造 released。通过 unbound/0 完成时，sub 须以本任务清理原件、摘要及原 CAS，或本人明确 accept 的匹配原 bind/transfer.release_cleanup，精确核对当前 NS 原文、摘要、ETag及已知提交 ETag；owner 须以本任务 release 完整原件、hash 与当前 owner.md 一致且当前证书验证有效确认，不补造旧条件。本地保留原件，后续关系必须重新检查。
+
+sub 收到 release 通知时，只有在持久历史中找到本人明确 accept、含 sub 角色，且本人已签 agent 的 owner/sub、被释放完整 statement 原文与摘要匹配的绑定或转移任务，才自动签署清理；该原任务可因发布响应丢失仍 pending，转移历史匹配其目标 owner。无控制消息时，仅已完成历史任务的恢复路径触发自动清理，即使未收到 relation.confirmed，也须新鲜核验当前 release/权威删除，将清理原件、全文摘要和原 CAS 持久保存于本地任务，保持原 completed 历史。响应丢失复用原件和原条件，当前完整文件、摘要、ETag及已知提交 ETag 匹配时仅确认；冲突保留原待办，不创建新的控制消息。缺授权且仍有旧字段时为 pending/action_required。当前字段已清空时关系为 unbound/0，不再签写；仅在本任务持久清理原件、摘要及原 CAS，或本人明确 accept 的匹配原 bind/transfer.release_cleanup，能精确确认本任务提交时记录清理完成，不据空字段补造释放或同意历史。历史 completed 仅表示当时任务结果，不要求当前关系仍为 released，也不授予当前 owner 权限。历史原件只复验结构及任务上下文；新鲜关系核验与真正新签文件仍按协议检查当前证书。不得新增释放审批 Facade 或从超时推断同意；应用可用现有名片 API 明确自签清理。陈旧 ETag 或后续关系不允许被旧清理任务覆盖。
+
+### 7.4 self-owner 与重合角色
+
+同一 AID 同时承担多个角色时，按 AID 合并消息接收方，审批记录保存其覆盖角色。self-owner 的本端一次明确发起/同意可以覆盖本方角色，不发给自己 P2P；两份文件仍分别签署、写入并经 NS 验收。
+
+外部 owner 转移到 sub 自己时，一个接收 AID 同时承担 sub 与 new_owner，单次审批覆盖这两个角色，但仍先发布 owner.md 再提交 agent.md。self-owner 转移到外部 owner 时，原 owner 与 sub 为同一身份，发起意愿覆盖这两个本端角色，外部新 owner 仍须审批。new_owner 等于当前 owner 不是转移；human 的 self-owner 仍拒绝。
+
+## 8. 恢复与稳定状态
+
+### 8.1 崩溃点与恢复依据
+
+| 中断点 | 已经稳定的事实 | 恢复动作 |
+| --- | --- | --- |
+| 已保存请求，尚未发送 | 关系未变，任务已存在。 | 核对原声明完整原文、摘要、目标与原 CAS，重发相同消息。 |
+| 同意已保存，回复未送达 | 决定已固定。 | 重发原决定，不能重新询问后改成另一决定。 |
+| 转移只收到一方同意 | 原关系保持。 | 等另一方；不发布授权或目标文件。 |
+| 签名文件仅保存在本地 | 网络权威关系未变。 | 核对条件仍有效，重用原字节推进。 |
+| owner 发布响应丢失 | 文件可能已保存。 | 读当前完整原文和摘要；相同仅确认，否则起始原件仍匹配时重试。 |
+| sub PUT 响应丢失 | NS 可能已经验收。 | 比较当前 owner、版本及原始文件摘要；匹配后确认，后续版本出现则停止旧写入。 |
+| release 已发布，NS 不可用 | 新鲜授权不能再使用该 release 对应旧关系；当前关系尚未完成新鲜核验。 | 保留 release，恢复后请求新鲜检查。 |
+| owner.md 已 release，sub 离线 | 动态返回 released，agent.md 字节和版本不变。 | sub 上线按原 CAS 自签清理，不新增释放记录。 |
+| NS 已保存名片，副本同步或旧文件清理失败 | 已提交的完整 agent.md 保持；当前关系仍按双材料核验。 | 分别补齐当前副本、按本任务原件核对后清理。 |
+| 转移授权过期或被有效撤回 | 旧关系仍受保护，除非 NS 已提交转移。 | 新鲜确认；未提交则停止旧任务，不自动延长授权。 |
+
+共识检查从首次 NS GET 发出前开始计算整体 30 秒窗口，覆盖首读、证书/Storage 验证和末读；材料变化或超时返回可重试 unavailable。fresh HTTP 携带 no-cache 并禁止自动跟随重定向。收到 sub.cleaned 时，按任务固定上下文新鲜核对当前 NS 完整原文、ETag 和全文摘要；字段已清空时可记录当前 unbound/0 的清理观察。通知或观察进度不能证明本任务执行提交，也不能替代首次完成 release 所需的原件及原 CAS 关联核验。
+
+Group/Org 名片失败稿及 pending 保留实体命名空间中的完整多签原文、原 CAS、固定 owner 和实体证书指纹，由应用显式重试，post-connect／重连不隐式 PUT。重试先验证完整原件及当前 owner、状态和证书代际，原条件完整且同代际原文／ETag 已确认提交时只观察完成。转移、rekey 或解散后停止旧代际待办，不更换身份、指纹或条件重签。新 SDK 现代上传不再保存、刷新或检查额外 V2 授权及过期窗口；旧 V2 兼容入口仍按协议 §2.5 校验；普通文件签名与当前证书检查保留。专属 create/transfer 自身 checkpoint 恢复机制不变。
+
+重连恢复先读取 NS/Storage，再考虑待发消息、写入和删除。一次持久保存的 step 不能证明远端副作用已经发生，远端的新版本也不能被旧 step 覆盖。
+
+### 8.2 NS 与 Storage 恢复
+
+进程崩溃沿用数据库事务恢复：提交前无变更，提交后读取当前完整 agent.md 及 CAS，再核验 owner.md。副本同步从当前名片继续，不借独立日志、关系账本或证据表恢复关系。
+
+备份恢复沿用数据库及 Storage 现有流程。重新读取当前两份材料、ETag及证书；不可确认时只暂停关系变更和 owner 授权。不维护独立历史版本上界，不承诺仅凭当前文件识别所有历史回滚。
+
+不新增跨服务恢复事务或恢复锁状态。Storage 恢复未完成时不提供权威不存在结论；普通名片读取、下载、历史验签、展示和通信按各自规则继续。
+
+Ownership 2.1 只以 sub 的 agent.md 和 owner 的 owner.md 为关系事实。NS 事务/CAS 原子更新完整 agent.md；owner.md 使用 Storage 既有完整文件事务。关系表、证据表、同步待办、独立日志和历史版本上界均不是事实来源。
+
+提交前失败时目标名片未变；响应丢失按原条件核对完整文件与 ETag，匹配则确认，条件失效停止旧提交。SDK 保存审批、已签原件及原条件供重试，不替代两份当前材料。
+
+首次激活沿用现有数据库迁移、事务、CAS 和恢复流程，不需要独立日志初始化、reserve/confirm、独立关系事实表或相关环境变量。数据库事务不包含远端调用。
+
+## 9. 降级、旧版及审计
+
+### 9.1 能力门槛
+
+| 缺失能力 | 本期行为 |
+| --- | --- |
+| NS 无 2.1 检查或 agent.md CAS 保护 | 可读取展示，不启动 2.1 关系变更，不把旧 proof.complete 解释为 2.1 共识。 |
+| Storage 无原子条件发布或权威查询 | 暂停相应写入和 owner 权限判断；不能用删后重建或下载 404 替代。 |
+| 当前 owner 原件无法确认 | 保留旧文件；已确认的关系结果仍可完成。 |
+| SDK 无持久任务存储 | 不启动有副作用的编排；只读查询仍可用。 |
+| P2P 不可达或对端未实现编排 | 保持待办；不推定同意，也不自动改走内部文件方法。 |
+| 不支持转移 | 保持原关系；不自动降级成 release 后重新绑定。 |
+| 无托管 | 正常完成绑定、解绑、转移。 |
+
+### 9.2 旧实现的安全隔离
+
+0.5.20、0.5.19 及更早任务按原格式及原有协议边界兼容；保留原 operation、有效审批、原签名字节和原提交条件，不能因缺少后增本地字段而一律停止或新建任务。历史适配、绑定容错和无参数 reset 的完整范围见 [编排指南第 8 节](Ownership-SDK编排指南2.1.md#8-崩溃与响应丢失后的恢复)。reset 只归档当前身份发起的未完成任务，保留原记录和远端文件，迟到消息不能复活。 旧 Owner 候选尚未发布时，原 `expected_revision` 必须有权威证据精确匹配，不能用当前 version 替代；服务未提供旧 revision 证据时保留原件及任务并返回 unavailable。目标已提交但任务仍待恢复时，只有本地原始签名候选与当前双方共识精确匹配才确认完成；缺少这些证据不能从当前网络补造历史原件或提交条件。
+
+SDK 的旧 `aun.ownership.v1` 消息、proof 工具和 metadata 不能改名后自动转成新任务。保留必要的旧材料读取与错误提示；2.1 处理器不执行旧 proof、证书托管、代签、代上传或自动 rekey 链路。
+
+NS 保留 legacy owner/proof 原保护；普通名片入口允许原样保留旧关系材料、自签及 CAS 更新正文，不自动迁入 2.1。旧 SDK 的注册、绑定、转移、查询和解绑另由隔离的 legacy RPC、Auth JSONL 与 operation ID 兼容流程承载，只激活旧 `ownership_proof`；不写 2.1 双文件，不产生 2.1 lock/version/consensus。缺新 Header 或旧 operation ID 均不得成为覆盖已存现代声明的通路。
+
+旧 proof 不等于新双方完整签名，不自动改造或伪造声明。旧关系无法确认时只降级 owner 功能；普通读取及兼容正文更新仍可用。2.1 从当前两份文件重新核验。
+
+这是一项明确的兼容边界：新版本可以支持新关系，并安全拒绝未迁入旧关系的危险写入；不能据此宣称所有 0.5.18 关系可无缝自动升级。
+
+### 9.3 业务授权与可选托管
+
+执行端验证调用者、目标 sub、当前 owner、操作范围、新鲜版本及双方签名，先持久保存完整授权材料，执行后追加实际结果。若未来 owner 派生 token/ACL，必须绑定当前完整关系声明并在使用时复验，不能仅比较可能重复的关系版本；当前没有该消费路径的模块不新增无关接口。
+
+NS 不以独立审计记录判定当前关系。业务端可保存授权及执行记录供自身审计；这些记录不是当前关系的第三份事实。
+
+托管由应用显式启用，优先使用 owner 无法独立解密的密文，不作为绑定前提。原 owner 曾持有可解密私钥时，应用另行确认新钥可用、旧证书和 token 失效、续签/恢复能力已隔离。该业务交接进度不改变 NS 已完成的关系结果。
+
+## 10. 实现文件组织
+
+各 SDK 内的下列模块承担 2.1 相关职责，现有消息与身份基础保持原有位置：
+
+| SDK | 实现文件 | 职责 |
+| --- | --- | --- |
+| TS / JS | `src/ownership-v21.ts`、`src/ownership-workflow.ts` | 前者实现两种文件模型、内部步骤和统一共识；后者实现任务、审批、P2P 和恢复。 |
+| Python | `src/aun_core/ownership_v21.py`、`src/aun_core/ownership_workflow.py` | 与上述相同职责，复用当前身份、异步网络及本地存储。 |
+| Go | `ownership_v21.go`、`ownership_workflow.go` | 与上述相同职责，由已有 Client/ownership_client 接入。 |
+| NS | `internal/httpserver/ownership.go`、`internal/repository/ownership.go`、`internal/httpserver/agentmd_storage_sync.go` | 关系检查、持久原子提交、名片副本待办执行；均为服务内部实现。 |
+| Storage | 优先修改现有 service、repository、models 和 migration 文件。 | 复用已有事务、版本及对象操作，不新增 ownership 专用服务。 |
+
+具体已有文件、方法、测试位置和每阶段退出条件以 [实施计划](Ownership2.1-TDD分阶段实施计划.md) 为准。新增模块仍须遵守零跨服务代码依赖；跨语言一致性由协议向量和交叉测试验证。