@agentunion/fastaun-browser 0.5.20 → 0.5.21

package/_packed_docs/agent.md/working/agent.md-schema/344/270/216/347/255/276/345/217/221/351/252/214/347/255/276/346/265/201/347/250/213/346/276/204/346/270/205.md

@@ -0,0 +1,349 @@
+# agent.md Schema 与签发/验签流程澄清记录
+
+本文为历史 working 草案；现行字段与验证规则以 [Ownership 协议定义 2.1](../../protocol/Ownership协议定义2.1.md) 为准。当前 Group/Org 可有 owner 而无 ownership；仅当前生命周期 owner 本人尾签，必含 signer_aid，并携带绑定实体当前证书代际的 V2 上传授权。本草案中的旧 proof、双方独立关系签名和目标身份代签说明保留为历史，不覆盖新契约。
+
+> 状态：working，已纳入已确认的 Phase 0 关系签名/证书策略；正式 wire Schema、RPC 和 golden vectors 仍待冻结
+>
+> 记录日期：2026-10-02
+>
+> 目的：在修改 SDK、Name Service 或正式协议前，先统一 `agent.md` 的字段、签名载体和签发/验签边界。
+
+## 1. 本轮范围
+
+本记录只讨论以下内容：
+
+- `agent.md` 的 YAML frontmatter 与 Markdown 文件结构；
+- 签名载体、签名覆盖范围和签名字段；
+- 签发方、Name Service、SDK 本地验签的责任边界；
+- 证书有效期、吊销和历史签名的处理口径。
+
+暂不修改 SDK、服务端代码或正式协议；本文件中的“当前事实”不等于最终协议结论。
+
+## 2. 当前实现事实
+
+### 2.1 文件和 frontmatter
+
+当前 SDK 对照文档是 [`docs/agent.md/SCHEMA.md`](../SCHEMA.md)，代码实现分布在 Python、TypeScript、JavaScript 和 Go SDK 的 `agent_md` / `agent-md` 相关模块。
+
+当前共同约束为：
+
+- 文件为 UTF-8；正文由 YAML frontmatter 和 Markdown 内容组成；
+- 被签名 payload 最大 4 KiB；尾部签名块最大 2 KiB；
+- frontmatter 必填字段为 `aid`、`name`、`type`、`version`；
+- `aid` 使用多标签 DNS 型格式；新写入先复用现有创建 AID 规则校验，再强制保存和返回 ASCII 小写值。legacy 读取可兼容大小写输入，但不得把非小写值写入 registry、proof、事件或 Storage 路径；
+- `version` 当前要求三段式 SemVer；
+- `description`、`avatar`、`tags` 为可选字段，分别有字符串、长度和数组元素校验；
+- 当前文档还描述了可选 `exttype`，但各 SDK 对未知 frontmatter 字段和 `exttype` 的一致性约束仍需确认；
+- `type` 有 `human`、`agent`、`group`、`service`、`device`、`host`、`org`、`custom` 等预设值，同时保留扩展值的可能性；`group`/`org` 的主体签名用途分别由 CA 的 `group_identity`/`org_identity` 映射确定。
+
+### 2.2 当前签名格式
+
+当前实现采用文件尾部内嵌签名块，而不是外挂 `.sig` 文件：
+
+```text
+<!-- AUN-SIGNATURE
+cert_fingerprint: sha256:<64 位 hex>
+public_key_fingerprint: sha256:<64 位 hex>  # 可选
+timestamp: <Unix 秒>
+signature: <DER 编码 ECDSA 签名的 Base64>
+-->
+```
+
+当前实现事实：
+
+- 签名块必须位于文件尾部，尾部只能有一个签名块；
+- `cert_fingerprint`、`timestamp`、`signature` 必填，`public_key_fingerprint` 可选；
+- 签名覆盖签名块起始标记之前的原始 UTF-8 字节；不做换行、空白或 Markdown 规范化；
+- payload 追加签名块前必须已经以换行结束，SDK 不替调用方改写 payload；
+- 当前算法固定为 ECDSA P-256 / SHA-256，签名使用 DER 编码并以 Base64 表示；
+- `cert_fingerprint` 指向签名证书的 SHA-256 指纹，不能用公钥指纹替代；
+- 若存在 `public_key_fingerprint`，验签时还会校验 SubjectPublicKeyInfo 指纹；
+- 签名时间戳不能比验证方当前时间快 300 秒以上，并且必须落在签名证书有效期内。
+- 写入链路（agent.md 发布、owner proof 登记、owner-change、E2EE 发送等）只允许 `active_signing` 证书生成新签名；
+- 只读链路按签名中的 `cert_fingerprint` 定位历史证书。只要签名时间位于证书有效期内且签名当时证书有效，即使证书后来变为 `verify_only`、自然过期或被吊销，历史签名仍可验签，并单独返回当前证书状态；不得用当前 active 状态替代签名时状态判断。
+
+### 2.3 当前签发和验签链路
+
+当前 SDK 上传大致按以下顺序执行：
+
+1. 本地检查 UTF-8、payload 大小和 frontmatter；
+2. 使用当前 AID 的签名私钥追加尾部签名块；
+3. SDK 在发起上传前再次做完整 Schema 校验和本地验签；
+4. `PUT /agent.md` 携带身份认证，Name Service 校验 Bearer、Host、AID 与签名证书主体的一致性；
+5. 服务端按签名中的证书指纹获取证书，检查证书主体、指纹、曲线/算法、签名时间戳以及写链路所需的 `active_signing` 状态；只读历史验签按签名时证书有效性处理；
+6. 服务端验签成功后才写入数据库和缓存。
+
+下载或读取时，SDK 会解析尾部签名块，按证书指纹解析对应证书，校验证书和原始 payload 签名，再将结果保存到本地 agent.md 缓存；结果还应区分签名时有效性和当前证书状态。当前本地读取接口仍能返回 `unsigned`，但上传接口要求签名存在且有效。
+
+## 3. 已发现的规范冲突
+
+| 来源 | 现有表述 | 与当前实现的冲突 |
+| --- | --- | --- |
+| `docs/protocol/草案-agent.md签名协议.md` | 外挂 `agent.md.sig`，签名可选，JSON 签名文件携带证书链 | 当前实现是尾部内嵌块，上传签名必需，证书按指纹回源 |
+| `docs/protocol/agent.md/SCHEMA.md` | 旧 AID 格式、旧 `type` 枚举、`description` 必填、无签名块 | 当前 SDK 使用更宽的 AID 格式、扩展 type、`description` 可选和尾部签名块 |
+| `docs/agent.md/SCHEMA.md` | 描述了当前内嵌签名和扩展字段 | 仍需明确哪些字段是协议硬约束、哪些只是 SDK 当前校验行为 |
+
+在最终决策前，历史草案不应被实现者当作当前上传验收契约；实现改动也不应在没有协议确认的情况下直接展开。
+
+## 4. 需要讨论的候选方案
+
+### 4.1 签名载体
+
+**方案 A：继续使用尾部内嵌签名块。** 与当前四端 SDK 和上传验收一致，单文件分发和 CDN 缓存简单；代价是签名解析必须严格处理尾部和原始字节。
+
+**方案 B：改为外挂 `agent.md.sig`。** 与历史草案一致，正文解析器完全不接触签名；代价是本体和签名文件存在发布竞态，客户端需要处理两次获取和版本配对。
+
+**方案 C：过渡兼容。** 读取阶段可识别历史外挂签名，发布阶段只接受内嵌签名，并明确优先级、冲突处理和下线时间；代价是协议和测试矩阵会暂时变复杂。
+
+### 4.2 发布是否强制签名
+
+可分为两层：
+
+- 读取/展示：无签名返回 `unsigned`，有签名但验签失败返回 `invalid`；
+- Name Service 发布：必须签名并通过验签，还是允许未签名草稿上传。
+
+当前代码选择“读取可 unsigned、发布必须 signed”。这是否作为正式协议规则，需要明确确认。
+
+### 4.3 证书材料和信任链（已确认基线）
+
+签名块继续保存证书指纹；验证器按指纹获取对应证书并校验证书主体、指纹、信任链、算法和签名时间。新写入只接受 `active_signing`；只读历史验签允许使用签名时有效的历史证书，当前状态可以是 `verify_only`、自然过期或吊销。证书状态必须作为独立结果返回，不能把历史签名强行改判为当前 active。
+
+CA 扩展 `aid_type/key_purpose`：`group -> group/group_identity`、`org -> org/org_identity`，`human/agent/service/device/host/custom -> normal/signing`。group AID 的 agent.md 主体由 group identity 私钥签名，群主只提供上传授权；org 同理。Auth 负责 owner 关系台账，Name Service 依赖 Auth，Auth 不回调 Name Service；未知 AID 可懒注册并报告 `registered=false`/`unbound`。
+
+### 4.4 时间和历史签名（已确认基线）
+
+签名时间戳必须落在签名证书有效期内。写入链路在签名时检查 `active_signing`，防止发送端故意使用过期或 verify-only 证书生成新凭证。只读链路只根据签名中的证书指纹定位证书并验证签名时有效性；证书后来轮换、自然过期或吊销不抹掉已经有效生成的历史签名。E2EE 作为实时写链路使用 active signing 证书，但接收端不得因缓存证书当前状态不是 active 就否定签名时有效的历史材料。
+
+### 4.5 Schema 与版本语义
+
+需要明确：
+
+- `type` 的开放扩展值与 `custom` 的正式注册表治理细节；已确认八种预设值和 owner 矩阵；
+- `exttype` 是否进入正式 Schema；
+- frontmatter 是否拒绝未知字段，还是采用向前兼容的忽略策略；
+- `version` 表示文档内容版本、Schema 版本，还是两者分离；
+- `description` 的可选性、字符长度和 Unicode 计数方式是否由协议统一规定；
+- 未来 group-like type 的 CA 映射扩展方式；`group`/`org` 的当前主体签名和上传授权边界已确认。
+
+## 5. 既有 agent.md 规范的非本轮待决项
+
+以下是整个 agent.md 签名协议的既有开放问题，不属于本轮 owner/ownership proof Phase 0 的新增 pending；它们仍需在正式 agent.md 协议整理时单独确认，不能反向改变本轮已确认的关系字段、状态和签名输入：
+
+1. 历史外挂签名文件是否仅在读取阶段兼容，以及与内嵌签名冲突时的优先级和下线时间。
+2. `PUT /agent.md` 的未签名草稿是否允许仅在本地或 pending staging 保存；公开发布仍必须签名。
+3. 证书链是否随签名块传输，还是始终按 `cert_fingerprint` 从 PKI/Name Service 获取；两种获取失败时的错误映射。
+4. `exttype`、未知 frontmatter 字段和 `version` 的正式跨 SDK 语义。
+5. `valid`、`unsigned`、`invalid`、`expired` 以及“签名时有效但当前证书已吊销”的结构化验签状态名称。
+
+## 5.1 决策记录：关系字段可选性与 human 约束
+
+**日期：2026-10-02；确认方：owner**
+
+- 新增的 `owner` 与 `ownership_proof` 在 agent.md Schema 中均为可选字段，用于兼容旧文档；字段缺省不代表新建非 human AID 可以省略 owner。
+- 这两个字段一旦出现，必须完整、合法并通过相互一致性和签名校验；只出现其中一个、字段格式错误或 proof 与 `aid/type` 不匹配，验签器返回无效。
+- `human` AID 不得指定 `owner`，也不得携带 `ownership_proof`。新建 human 默认无 owner；显式传入任一关系字段时拒绝。
+- 除 `human` 外，新建 AID 的业务流程仍要求有效 owner；`agent` 可使用 self-owner，其它类型只能使用符合规则的外部 owner。
+
+影响范围：四端 agent.md Schema/验证器、Auth 创建与绑定校验、Name Service 发布校验、ownership proof 测试向量、SDK 创建参数校验和错误码。
+
+## 5.2 决策记录：共同签署的关系声明范围
+
+**日期：2026-10-02；确认方：owner**
+
+- subject 与 owner 独立签署同一份最小关系声明；声明字段恰为 `proof_id`、`subject_aid`、`owner_aid`。
+- `schema` 不作为关系声明字段。若 proof 外层需要格式版本，必须作为未参与关系事实签名的封套元数据另行定义，不能与三字段声明混淆。
+- `subject_type`、`relation_version`、operation ID、签名封套和 agent.md 展示内容不进入双方共同签署的声明；它们由 Auth/验证器按注册表、operation 和 Schema 规则另行校验。
+- 本决定冻结的是共同签署的语义字段集合；canonical JSON 的 AID 规范化、键序、可见分号域分隔符、哈希与签名编码按 7.6 实现基线执行，跨 SDK golden vectors 仍需生成。
+
+影响范围：四端 proof 生成/验签、Auth operation 绑定和验签、跨语言测试向量及 owner 转移流程。
+
+## 5.3 决策记录：关系事实与 nonce/编排上下文分层
+
+**日期：2026-10-02；确认方向：owner 提问后形成的澄清，待正式协议冻结**
+
+- “事实”只表示关系本身：`subject_aid` 的 owner 是 `owner_aid`。签名内部 nonce、operation ID、challenge nonce、`relation_version`、`created_at`、`expires_at` 等都是证明或编排上下文，不进入事实摘要。
+- 关系声明自包含 `proof_id`、`subject_aid`、`owner_aid` 及各自角色、签署时间和按需扩展；双方分别独立签名，self-owner 只有 subject 签名。关系证明不携带额外摘要字段。
+- 当前编排由 SDK 通过加密 P2P 完成，服务端仅验证 agent.md 内的 proof，不维护关系台账或做关系防重放。
+- wire schema 保存双方原始声明与实际签名，字段以当前 SCHEMA.md 为准。
+- 如果“nonce”指 ECDSA 内部生成的临时随机数 `k`，它永远不属于事实、关系证明上下文或 agent.md，不能序列化、比较或写入 proof。双方签名值因 `k` 不同而不同是正常的；owner-change challenge nonce 则是另一种由 Auth 生成的可见一次性授权字段。
+
+影响范围：ownership proof 的字段命名、跨端 canonical vectors、Auth 的一次性 challenge/重放检查、离线签名请求和公开独立验签。本次只新增“事实摘要”和“完整声明摘要”的区分；`proof_id` 仍是三字段共同声明的一部分，operation/nonce 等编排上下文不进入声明。
+
+## 5.4 决策记录：Auth 作为登记机构、见证者和凭证托管方
+
+**日期：2026-10-02；确认方向：owner 提出的登记机构类比，待正式协议冻结**
+
+- 可以把 Auth 类比为 AUN 信任域内的登记机构/见证者，但它不是 owner 关系的第三个事实签署方。subject 与 owner 的独立签名证明双方对同一关系事实作出确认；Auth 负责验签、检查证书和策略、登记结果并维护当前状态。
+- Auth 的“见证”发生在关系提交登记时，不要求双方签名交换时 Auth 在线。双方可以通过 pending inbox 或离线文件完成签名，之后由 Auth 验证同一 fact/statement、operation、有效期和版本，再原子登记。
+- 当前 ownership 关系不依赖 Auth 登记回执，直接验证公开 proof 中的声明与签名。
+- Auth 可以持久化原始 canonical fact/statement、双方 detached 签名、证书指纹或证书链引用、operation、登记回执和不可变审计记录，作为关系证明的证据托管。Auth 不得接收、保存或代管 subject/owner 私钥，也不应因登记关系而接管可由 Name Service/Storage 保存的完整 agent.md 或备份密文。
+- `ownership_proof` 可继续随 subject 的 agent.md 公开携带，便于离线独立验签；Auth 回执/状态用于证明“已登记、当前 active 或已 superseded/revoked”。不访问 Auth 时可以验证双方签名和事实一致性，但不能仅凭旧 proof 推断当前关系仍 active。
+- Auth 回执和台账属于 Auth 信任边界：Auth 密钥或台账被攻破会影响登记状态的可信度，因此回执必须有版本、状态迁移和审计；这不改变双方签名材料可独立保存和复验的要求。
+
+影响范围：Auth proof ledger、登记回执/状态查询、Name Service 与 Storage 的关系状态消费、公开验签的“事实有效”与“当前登记状态”区分，以及离线签名提交后的最终化流程。
+
+## 5.5 决策记录：self-owner 签名数、最小关系声明与未解除关系检查
+
+**日期：2026-10-02；确认方：owner**
+
+- `agent` 的 self-owner 只保留一份 `subject_signature`。因为 `subject_aid == owner_aid`，不再重复生成或保存 `owner_signature`；外部 owner 关系仍要求 subject 与 owner 两份独立签名。
+- 按本条最新决定，关系声明的最小业务字段收敛为 `owner_aid`、`subject_aid`、`proof_id`。关系声明中不再单独加入 `schema` 字段；proof 外层按已确认的签名封套表达，不加入 nonce、时间或 relation version；正式 wire Schema 仍需将该结构写入协议文档，不能与共同签署字段混淆。
+- 关系声明提交和 `agent.md` 发布都必须经过 Auth 权威关系检查。Auth 对同一 subject 原子检查是否存在未解除的 `active` 关系或未完成的 pending operation：同一 owner/proof 的幂等重试可以继续；不同 owner、不同 proof 或不同 operation 必须返回关系冲突。`superseded`、`revoked`、`expired`、`cancelled` 等终态记录不再阻止新编排，但新关系仍须使用新的 proof/version。
+- 普通 `agent.md` 内容更新不创建新关系，但 Auth/Name Service 仍须确认其 `owner`/`ownership_proof` 与当前 active proof 完全一致；非 human AID 不能通过省略关系字段、伪造新 proof 或普通 PUT 绕过未解除关系。pending 注册只能使用绑定 operation 的一次性发布凭据；关系字段变化必须转入 Auth 的绑定/换 owner 流程。
+- 上述检查必须在 Auth 的同一事务/CAS 中完成，Name Service、SDK 或客户端提交的“已验证”标记不能替代台账检查。Auth 不需要参与双方离线签名交换，但必须在最终绑定或 agent.md 激活登记时执行检查。
+
+影响范围：`ownership_proof` self/delegated 分支、四端 Schema/验签器、Auth 唯一性约束与状态机、Name Service agent.md 发布门禁、幂等和关系冲突错误码。
+
+## 5.6 决策记录：关系状态、能力边界与存储/传播策略
+
+**日期：2026-10-02；确认方：owner**
+
+- 具体业务是否要求 owner 关系由应用层决定；AUN/Auth 只报告准确的证书、AID 生命周期和 owner 关系状态，不因 `pending`、`unbound` 或 `unusable` 破坏基本登录、Gateway 连接和消息通信。
+- owner 证书或 profile 失效时关系报告为 `unusable`。old owner 失联、丢失或疑似泄露时本版不启动专门 recovery、争议恢复或自动换绑；不凭新 agent.md 或单方声明强行改绑。
+- 解绑必须经 Auth，结果为 `unbound`；基本登录和通信不受限，是否限制 owner 依赖场景由应用层按状态决定。`unbound` 不等同于首次绑定尚未完成的 `pending`。
+- 状态观察复用现有 agent.md 机制：主体上线时拉取一次当前状态；主体在线且状态发生变化时推送一次。状态对象的业务新鲜度和使用门槛由具体应用定义。
+- AID 仍是其它 AID 的未解绑 owner 时不得改变自身 `type`；其下属关系全部进入 `unbound` 后，才允许走 type-change operation。普通 agent.md PUT 不能改变 type。
+- 登记/换绑 operation、离线 request/reply 和 pending inbox 的有效期统一为 7 天；Name Service 一次性发布 token 的 TTL 为 15 分钟，过期后重新申请，不续用旧 token。
+- owner 备份目录允许 subject 管理目录内部对象，包括删除、移动和重命名；subject 根目录本身不得移动或删除，关系撤销只撤 ACL 和票据，不清理目录或数据。
+- 新增公开 RPC、错误码、事件和结果封套遵循既有 RPC 惯例；本记录不凭空引入另一套调用风格。
+
+影响范围：Auth/Name Service 状态字段和事件、四端 SDK 能力判定与恢复、type-change 检查、Storage 关系目录 ACL、TTL 及跨端 RPC 文档。
+
+## 5.7 决策记录：状态机、证书用途和服务依赖（2026-10-03）
+
+- 注册 operation 统一为 `reserved -> proof_pending -> agent_md_pending -> active`；`proof_pending` 内部用等待签名子状态表示进度，不再使用 `certificate_issued`、`owner_signature_pending` 或 `proof_ready` 作为生命周期状态。证书状态、AID 生命周期和 owner 关系状态分开维护。
+- 新签名/写入链路只使用 `active_signing`；只读历史验签按证书指纹定位证书，签名时有效即可在证书后续 `verify_only`、自然过期或吊销时通过，并报告当前状态。旧 `auth.create_aid` 和新注册在 owner pending 时均签发正常可用证书，不阻断基本登录和通信。
+- Auth 对 owner 台账、关系唯一性、成环检查、CAS 和冲突仲裁负责；Name Service 依赖 Auth，Auth 不依赖 Name Service。未注册 AID 允许懒注册并返回 `registered=false`、`unbound`/`legacy_unbound`，不把未知身份当作服务故障。
+- `group`/`org` 的 agent.md 主体签名分别使用 CA 映射的 group/org identity 证书；群主/组织管理者只提供上传授权，管理者转让与 Auth owner 关系保持一致。
+
+## 6. 讨论期间的临时基线
+
+在上述决策完成前：
+
+- 不修改现有四端 SDK、Name Service 或正式协议实现；
+- 新实现如需读取 agent.md，应以当前尾部内嵌签名格式为实现基线，并保留明确的兼容边界；
+- `docs/agent.md/SCHEMA.md` 作为当前实现对照，不视为已经完成协议冻结；
+- `docs/protocol/草案-agent.md签名协议.md` 标记为历史候选方案，不应覆盖当前上传验收行为；
+- 每次 owner 确认后，在本文件追加“决策记录”并注明影响的规范、SDK、服务端和测试范围。
+
+## 7. Owner 关系证明签名澄清
+
+> 状态：working 讨论方向，待最终协议冻结
+>
+> 记录时间：2026-10-02
+
+### 7.1 双方签名的共同内容
+
+subject 先签、owner 后签是签名交换顺序；owner 不是在 subject 的签名封套或 agent.md 上再签一层。按照最新决定，双方应分别独立签署同一份三字段 canonical statement。事实摘要可以从 statement 投影计算；不因此新增一个尚未冻结的额外关系对象。
+
+共同事实的规范对象为：
+
+```json
+{
+   "proof_id": "550e8400-e29b-41d4-a716-446655440000",
+  "subject_aid": "sensor.agentid.pub",
+  "owner_aid": "alice.agentid.pub"
+}
+```
+
+关系事实是 subject AID 的 owner 为 owner AID；proof 保存双方各自独立声明及实际签名，接收方验证共同关系字段、角色与签署时间。
+
+下面的 `fact/context` 分层仅用于说明摘要语义，不是当前已冻结的 wire schema：
+
+```json
+{
+  "fact": {
+    "subject_aid": "sensor.agentid.pub",
+    "owner_aid": "alice.agentid.pub"
+  },
+  "context": {
+     "proof_id": "550e8400-e29b-41d4-a716-446655440000",
+    "operation_id": "op-01J...",
+    "relation_version": 1,
+    "expires_at": "2026-10-02T10:00:00Z"
+  }
+}
+```
+
+签名输入是域前缀加各自 statement 的 canonical 字节；声明时间和扩展可不同，共同关系字段必须匹配。接收方直接验证实际签名。
+
+subject 与 owner 交换各自声明及独立签名。封套标识签署者的证书指纹、角色、声明和签名值；P2P request/reply 通过 request_id/proof_id 关联。
+
+### 7.2 时间戳与异步审批
+
+- 不在每个签名封套中让签名者分别填写本地时间戳。两个本地 timestamp 既不相同，也不能在没有可信时间戳服务时证明签名的真实产生时间。
+- operation 的创建时间和截止时间由服务端在 prepare 时生成并持久化；双方签名都必须在 operation 有效期内交回。服务端分别记录接收时间用于审计与有效期判定，不把接收时间标记成签名产生时间。
+- 离线 owner 如果超过服务端截止时间才提交，operation 失败；需要重新 prepare，得到新 proof ID 并由双方重新签名。若业务必须接受“截止前已签、截止后才上传”的离线回执，必须另行引入协议认可的可信时间戳机制，不能靠客户端自报时间。
+
+若后续决定关系 statement 本身必须携带时间信息，`issued_at` / `expires_at` 应在双方签名前由服务端一次生成、原样冻结并共同纳入 statement，不能由双方各自生成；当前关系 statement 保持三字段最小形式，owner-change 的时间和 challenge 只绑定 old owner 转移授权。
+
+### 7.3 Owner 变更中的旧 owner
+
+owner 关系建立后，换 owner 必须由 Auth 台账中的当前 owner 发起；self-owner 时 subject 与 current owner 是同一 AID，可以按 current owner 身份发起；其它 subject 不能只凭自己的私钥创建另一条有效 owner 关系。Auth 为转移生成 operation 后，old owner 签署独立的转移授权，授权绑定 subject AID、当前 owner AID、指定的 new owner AID、当前 relation version、operation ID、服务端生成的一次性 `challenge_nonce` 和 `expires_at`。subject 与 new owner 仍分别对“subject 的 owner 是 new owner”这一最小新关系 statement 独立签名。转移授权和新关系声明是不同事实、不同用途的载荷。
+
+Auth 只有在当前 owner 转移授权、subject 对新关系的确认、new owner 的接受均验签通过，且 relation version 仍匹配时才提交。Auth 是 AUN 内关系写入的唯一入口和权威台账；Name Service、Gateway、Storage 与 SDK 不得另行写 owner 状态。Auth 对每个 subject 最多允许一个 active owner 和一个未完成的 owner-change operation，并通过事务/CAS 拒绝并发、重放、旧版本及目标被替换的请求。
+
+在 Auth 状态存储强一致且所有 owner 关系变更都经 Auth 提交的前提下，Auth 台账可保证权威状态中每个 subject 至多有一个 active owner。关系 proof 本身及其签名可公开独立验证，大多数场景可据此信任 agent.md 中的 owner；需要判断最新/active 状态时，验证方才需要取得相应 Auth 状态。持钥者仍可在 Auth 之外生成互相冲突的签名或文件，但这些文件不会改写 Auth 权威状态。Auth 及其管理员属于信任边界。
+
+此保证还依赖 subject 与 old owner 的私钥由不同主体控制，owner 私钥不交给 subject SDK 或 subject agent 使用。签名只能证明对应私钥参与签署，不能证明操作者的现实身份或排除私钥被共享/窃取；如果 subject 能调用或取得 old owner 的有效签名能力，密码学本身无法阻止其伪装成 owner 发起转移。
+
+Auth 可按当前台账、有效签名和 CAS 规则自动裁定协议冲突；私钥失窃/遗失、主体身份争议等不能仅靠普通签名自动判定。本版不提供覆盖常规授权的 recovery、争议恢复或自动换绑流程。解绑必须经 Auth 并进入 `unbound`；基本登录和通信不受限，具体 owner 依赖场景由应用层决定。owner 证书/profile 失效、失联、丢失或疑似泄露时关系报告为 `unusable`。
+
+### 7.4 独立验证与 Auth 写入仲裁
+
+- `agent.md` 中的 `owner` 与 `ownership_proof` 对公众可验证；SDK 和相关服务持有签名及证书材料时，可以独立校验证明。大多数读取、展示和普通验签场景直接信任验签通过的 owner 声明，不要求访问 Auth。
+- 只有创建、替换或撤销权威 owner 关系的写入必须提交 Auth。Auth 复验签名、证书、operation、当前 relation version 与冲突状态，并以事务/CAS 决定是否提交；协议状态冲突由 Auth 按台账和协议规则仲裁。只改名片正文等不改变 owner 关系的内容，不因此触发 owner 关系审批；仍按 agent.md 自身签名和发布规则处理。
+- 公开验签可证明相应密钥签署了该关系声明，但不能单独证明它仍是最新或 active 关系。只有具体场景要求确认最新关系状态时，才需额外取得可验证且满足该场景新鲜度要求的 Auth 状态/版本；不把这一要求扩大到普通验签。
+- Auth 仲裁覆盖关系台账、并发写入、版本冲突、重放及 operation 冲突等协议事实；密钥失窃、现实主体争议等不在本版专门 recovery 范围内，owner 验证材料失效时按 `unusable` 报告。
+
+### 7.4.1 证书状态与 owner 关系状态分离（2026-10-02 22:08）
+
+- 旧 SDK 通过 `auth.create_aid` 创建 AID 时，证书保持正常可用状态，不能因为没有 owner proof 被标记为 `pending`；该 AID 的关系状态仅记为 `legacy_unbound`。
+- 新 SDK 的注册流程即使分为 prepare、签名交换、agent.md 发布等多步，证书签发后也保持正常可用于认证的状态；绑定完成前只把 owner 关系/注册 operation 记为 `pending`。
+- 证书有效且 AID 未停用时，legacy 或关系 pending 身份保留基本登录、Gateway 连接和消息通信。是否要求 Auth `registered/active` 由具体应用场景决定；不能因关系未完成把服务整体置为不可用。
+- operation 超时、取消或失败不自动吊销已签发证书、停用 AID 或断开基本会话；允许用新 operation/proof 重试。证书状态、AID lifecycle、owner relation status 和按场景计算的 capability profile 分开维护。
+
+### 7.4.2 旧 AID 使用绑定流程（2026-10-03 10:23）
+
+- 旧 `auth.create_aid` 创建的 AID 沿用绑定语义。已有 AID 若需要登记缺失的 `type`、owner 或 ownership proof，统一使用 `aid_bind` operation；它只建立绑定，不更换 AID、密钥、证书或通信身份。
+- `auth.aid_bind_prepare` 必须由 subject 以现有 AID 身份调用。缺少 `type` 时请求必须显式提供；缺少 owner 时，非 `human` 必须显式提供 owner，`agent` 可以 self-owner，`human` 不得提供 owner。若 Auth 已有 type/owner，绑定请求只能写入缺失值或提交完全相同的值，不能借此改变既有登记。
+- Auth 不根据 AID 名称、证书 CN、历史聊天、旧 agent.md 文本或客户端配置推断缺失的 type/owner。旧 agent.md 可以继续读取、缓存、上传展示内容，但普通 `PUT /agent.md` 不能写入或改变权威关系字段。
+- `aid_bind_submit` 接收 self-owner 单签或外部 owner 双签，允许双方离线、分批提交；`aid_bind_activate` 只在绑定 operation 对应的 agent.md 快照发布成功后登记 type/owner/proof。绑定不重新签发证书。
+- AID 没有 type/owner、绑定 pending、绑定失败或未发起绑定时，证书和 AID 仍可正常登录、连接 Gateway、收发消息；Auth 只报告 `legacy_unbound`/`pending`，具体 owner-sensitive 能力由应用层按场景限制。绑定成功后 human 进入 `not_applicable`，非 human 进入 `active`。
+- 四端 SDK Facade 提供 `bindAid`、`getAidBindingStatus`、`resumeAidBinding`、离线绑定签名包导入/导出和公开 proof 验证入口；旧 `createAid` Facade 保持原语义，不隐式触发绑定。
+
+### 7.5 Phase 0 后的正式化工作
+
+关系字段、共同事实分层、Auth 登记边界、证书与关系状态分离、状态传播、type-change 约束、TTL、Storage 操作集和 recovery 排除范围已经确认。正式协议仍需把这些结论整理为精确 wire schema、RPC/错误码/事件封套，并生成四端 canonical bytes、签名互验、转移授权、TTL、CAS、状态 pull/push 和 Storage ACL 正反例向量。
+
+### 7.6 现有实现对照下的 canonical bytes 实现基线
+
+本轮已检查 Python、TypeScript、JavaScript、Go 的 `v2` canonical JSON，以及当前 AID/agent.md 签名载体。为避免为 owner proof 再引入一套 JSON 或签名格式，Phase 0 实现基线如下：
+
+1. **AID 规范化**：先复用现有创建 AID 代码的 AID 规则校验，要求 ASCII AID 格式；写入共同声明前将 `subject_aid`、`owner_aid` 转为 ASCII 小写。声明中的两个字段必须已经是该小写结果，不接受同一 AID 的多种大小写字节；返回值、Auth registry、proof、事件和 Storage 路径同样只保存小写。
+2. **JSON**：复用 `python/src/aun_core/v2/crypto/canonical.py`、`ts/src/v2/crypto/canonical.ts`、`js/src/v2/crypto/canonical.ts`、`go/v2/crypto/canonical.go` 的规则：对象键递归按 Unicode 码点升序，紧凑无空白，非 ASCII UTF-8 直出，字符串最小转义，数组保持顺序，禁止 NaN/Infinity 和超出安全范围的整数；不附加换行。
+3. **关系字段**：`subject_aid` 与 `owner_aid` 使用规范的小写 AID；双方声明须确认同一对 AID 与同一 proof。
+4. **三字段 statement 和签名输入**：当前推荐直接对已确认的三字段 statement 签名；Auth 通过 `proof_id` 与 operation、当前 relation version 和服务端有效期的台账绑定提供防重放约束。建议的签名输入为：
+
+   ```text
+    UTF-8("AUN-AID-OWNER-RELATION-V1;") || canonical_json(statement)
+   ```
+
+域分隔符中的分号是可见字符，不使用不可见分隔符。双方各自签署原始声明，签署时间和扩展可不同；当前方案不增加关系防重放机制。
+5. **签名校验**：直接验证双方声明及实际签名，检查关系字段、角色与各自签署时证书有效性，不传输或比较额外摘要字段。
+6. **签名载体**：复用当前 AID/agent.md 的 `ECDSA-P256-SHA256`，签名结果为 ASN.1 DER，外层使用带 `=` 填充的标准 Base64；封套另带签名证书的 `cert_fingerprint`。不采用 E2EE V2 的 64 字节 RAW 签名，也不采用 `client_signature` 的 `method|aid|timestamp|params_hash` 串。ECDSA 内部随机 nonce `k` 永不序列化；签名字符串不同是正常的。若必须要求签名字节可复现，则应另行选择 RFC6979 RAW/DER 方案，不能沿用本候选的现有签名载体。
+7. **时间**：共同事实不放双方本地时间；普通 relation operation 的 `created_at`/`expires_at` 由 Auth 生成并按服务端时间判定有效期。owner-change 的 `challenge_nonce`/`expires_at` 进入 old owner transfer authorization，不进入三字段 relation statement。
+
+上述规则是已确认的 Phase 0 实现基线，正式协议落稿时应原样写入。下一步生成至少一组包含大小写输入（规范化后相同）、非法 AID、控制字符和边界 proof ID 的四端 golden vectors；正例分别比较 fact/statement canonical bytes 和两层摘要，负例比较一致拒绝，签名只做跨端互验，并把 Phase 1 checklist 标记为完成。
+
+## 8. 参考资料
+
+- [`docs/agent.md/SCHEMA.md`](../SCHEMA.md)
+- [`docs/protocol/草案-agent.md签名协议.md`](../../protocol/草案-agent.md签名协议.md)
+- [`docs/protocol/agent.md/SCHEMA.md`](../../protocol/agent.md/SCHEMA.md)
+- `python/src/aun_core/agent_md_schema.py`
+- `python/src/aun_core/agent_md.py`
+- `go/agent_md_schema.go`
+- `go/aid.go`
+- `ts/src/agent-md-schema.ts`
+- `js/src/agent-md-schema.ts`

package/_packed_docs/agent.md/working//346/234/254/345/234/260Docker/346/265/213/350/257/225Bug/346/270/205/345/215/225.md

@@ -0,0 +1,40 @@
+# 本地 Docker 测试 Bug 清单
+
+本清单记录本轮 owner 关系功能实施及单域、跨 SDK、跨域 Docker 回归中发现的非任务失败。每项均在继续回归前处理，并保留对应验证结果。
+
+| 状态 | 失败现象 | 根因 | 修复与验证 |
+| --- | --- | --- | --- |
+| 已修复 | Group Go SQL mock 测试因缺少期望失败 | 新增成员状态写入路径后，既有 mock 未声明对应 SQL 操作 | 补齐 repository/service mock 期望；`go test ./internal/repository` 及受影响 Group 测试通过 |
+| 已修复 | 双域服务启动时报 `EOFError: marshal data too short` | Compose 启动时 Python 写入损坏或不完整的 `.pyc` 字节码 | 双域 Compose 增加禁写 Python 字节码环境变量，重建并重启隔离双域镜像；服务稳定运行 |
+| 已修复 | Python Tester 原生 `aiohttp` 扩展导入在运行态失败 | Tester 镜像中的原生扩展 ABI 与运行时不一致 | 重建 Tester 运行依赖并执行 100 次原生扩展导入探针，全部通过 |
+| 已修复 | 新设备首次 `group.pull` 复用身份时无法复现入群后消息 | 回归脚本复用旧身份目录，游标状态污染了首次 Pull 场景 | 增加独立身份树复制并补充首次 Pull 回归；定向邀请跨域用例通过 |
+| 已修复 | 隔离双域 B 域启动失败或端口占用 | 稳定的 `kite-agentid-cn-local-app` 占用默认 `424xx` 宿主端口 | 为 B 域显式覆盖 Gateway、Console、AUN Console、NameService、Leaderboard、Stream、Service Proxy 端口；双域容器正常运行 |
+| 已修复 | 跨域群成员状态断言偶发看到 `last_message_at=0`、`last_payload_type=""` | `group.send` 成功后成员最后消息状态由 pending worker 异步持久化，立即查询存在最终一致性窗口 | Group 单项测试和 Python Group 管理集成断言改为轮询最终状态；修复后成员状态专项通过，数据库最终记录正确 |
+| 已修复 | Go Federation Ack 测试偶发读取到 `ack=0` 或游标未推进 | SQLite inline 游标写入仍在异步提交，Ack 请求早于提交完成时 SDK 会按当前游标裁剪 Ack | Ack 前增加游标收敛等待；`TestFederationAckMainChain` 与 `TestFederationMultiDeviceAck` 定向测试通过 |
+| 已修复 | TypeScript Federation Notify 首次运行出现 Tester worker 瞬时异常 | 测试 worker 首次启动时发生短暂运行时抖动，业务断言未执行 | 重试同一用例后通过，`federation-notify.test.ts` 结果为 1/1；未发现业务回归 |
+| 已修复 | Python Tester 稳定性探针约第 100 次导入出现 `TypeError ... dynamically allocated` 并 abort | 运行态 Python/原生扩展发生瞬时堆类型损坏，业务 SDK 尚未执行；Bookworm、环境变量和 `pip check` 均正常 | 保留 image/runtime 证据后按指南重建 `sdk-tester` 并只重建 Python Tester；重建后重新执行 100 次完整导入探针通过 |
+| 已修复 | Python `e2e_test_delivery_changed.py` 的 Group inline_push 等待 `delivery.changed` 超时 | 连接期间到达的 V2 Head 在 `connect()` 返回前后可能抢先触发前台 Pull；调用方尚未注册监听器时，离线消息已被消费 | Python SDK 增加连接期及连接后监听器注册前的 V2 Push 延迟队列；排除内部 transport 订阅，改由用户 `on()` 注册后排空；单测、旧 GAP 定向 E2E、`e2e_test_delivery_changed.py` 均通过（5/5） |
+| 已修复 | Group V2 首条消息（成员事件占用 seq=1、消息从 seq=2 开始）未生成 inline Push | 服务端 Group inline 状态只按真实 `cursor.current_seq` 判断，空 Forward 的 ACK=0 回退了 Tail 建立的可见 seq=1 基线；join/retention/earliest 下界未参与候选判定 | Go Group 状态分离真实 `ackSeq` 与 `visibilitySeq`，Tail 建立只读可见基线，Forward 合并可见下界且不改写真实 ACK；新增 TDD 回归，`go test ./internal/online`、Group push 单测及单域 `e2e_test_delivery_changed.py` 均通过（5/5） |
+| 已修复 | `integration_test_group_sync.py` 新设备首次访问的消息下界低于旧消息 head（`join=4 old_head=6`） | 新设备显式复用已有 device_id 时，Group cursor 初始化使用了过早的成员 join/message 边界，未以首次访问时的当前消息 head 建立不可回退的可见下界 | 初始化同时比较成员 join 序号与当前群 head，专用 inbox 仍可降低消息下界；消息/事件 repository TDD、Group Go 全量测试、Docker 单域 `integration_test_group_sync.py` 均通过（25/25） |
+| 已记录并规避 | 在宿主机直接执行固定 AID 的 `integration_test_group_sync.py` 时出现 `AID 'alice.agentid.pub' is already registered` | 宿主机默认 `.aun` 没有 Docker 单域配套的固定身份目录，脚本尝试用新密钥注册已存在的固定 AID | 按测试指南改用 `kite-python-sdk-tester`，复用 `/data/aun-fixed-agentid-pub` 后同一用例通过（25/25）；后续固定 AID 单域脚本统一在 Tester 容器中执行 |
+| 已恢复 | 下一 Group 文件执行前 Python/TS/Go/JS Tester 同时退出 255 | Docker 运行态同时重启；服务容器自动恢复，Tester 未配置自动重启；inspect 未显示 OOM，Tester 日志无业务异常 | 按指南对独立 Tester project 执行 start，保留原容器、volume、固定身份与数据库，从未执行的 Group management 文件续跑 |
+| 已修复 | `integration_test_delivery_changed.py` 旧能力完整 Push 用例收到 raw `delivery.changed` 但 `message.received` 回调超时（6/7） | 旧完整 Push 带目标 `device_id` 但没有 `slot_id`；SDK 未推进序号，seq=1 被有序发布器误判为缺口而挂起 | Python delivery 序号推进改为按目标 `device_id` 生效并继续排除 inline payload；单域 Docker `integration_test_delivery_changed.py` 复跑 7/7 |
+| 已修复 | `integration_test_delivery_changed.py` Pull/Push 交错用例的 raw handler 打印 `name 'raw' is not defined` | 回归测试注册回调时遗漏 `raw` 列表初始化，隐藏 handler 异常未被主断言捕获 | 补充 raw 列表并复跑该脚本，7/7 通过且无该异常 |
+| 已修复 | `integration_test_delivery_changed.py` Group inline 用例偶发在 Tail 阶段返回 `membership_unconfirmed/pending` | Group 成员提交与 Tail 可见性之间存在最终一致性窗口，测试只在 `head_seq>0` 时重试一次 | `_prime_group` 对 pending/unconfirmed Tail 做 25 秒有界条件轮询；后续脚本复跑通过 |
+| 已修复 | `integration_test_delivery_changed.py` Pull/Push 交错用例消息到达但 `delivery.changed` 为空 | 通知由异步 dispatcher 在消息回调之后提交，测试固定等待 450ms 后立即断言 | 改为等待带 `p2p` 变更行的 `delivery.changed`（20 秒超时）；后续脚本复跑通过 |
+| 已修复 | Python Tester 全量单元收集阶段 5 个契约测试失败 | Tester 仅挂载 `/tests`、`/contracts` 和 `/kite-source/extensions`；旧测试通过 `Path.parents` 查找仓库根，NameService Python 实现已迁移为 Go 且不存在 | Push 契约测试改用 `AUN_CONTRACTS_ROOT`，Push 模块测试改用 `KITE_TEST_ROOT` 并在无 Go 工具链的 Python Tester 中跳过 Go 专项；过时的 NameService Python 契约测试显式跳过，Go Tester/服务端已有等价覆盖；定向结果 39 passed、2 skipped |
+| 已修复 | Python 单元回归的 6 个环境/契约测试失败 | Trace E2E 为等待 observer 使用了私有 `_dispatcher`；session helper 对测试替身的空 `state` 解引用；cross-SDK 契约在 Tester 内没有 `.git`；新增 owner relation 脚本未加入公网测试分类 | Trace 改为公共异步等待，helper 安全处理缺失 state，Compose 契约在无 Git 元数据时按已知运行期目录判断，runner 增加 owner relation case；定向结果 6/6 通过 |
+| 已修复 | 串行回归在 `integration_test_service_proxy_docker.py` 处因文件不存在退出（2） | 测试编排命令把公网 Service Proxy E2E 的文件名误写成了 `integration_test_service_proxy_docker.py`；仓库实际入口为 `e2e_test_service_proxy_docker.py`，指南和 `run-public-tests.py` 均使用后者 | 修正断点续跑命令为实际 E2E 入口；`docker exec kite-python-sdk-tester python -X utf8 /tests/e2e_test_service_proxy_docker.py` 通过（persistent，exit 0） |
+| 已修复 | Python/TS/Go/JS Tester 在回归中途同时退出 255 | 四个 Tester 容器均在约一小时运行后同时退出，`OOMKilled=false`、无容器错误和业务日志，属于测试运行态生命周期中断 | 按测试指南仅对 `kite-sdk-testers` project 执行 `docker compose ... -f docker-compose.testers.yml start`，保留原身份、数据库和卷；Bookworm、`pip check` 及 100 次完整 SDK 导入探针均通过，未重建或清理固定材料 |
+| 已记录并改用正确入口 | 直接执行 `e2e_test_group_fs_sdk.py` 退出 0 且无测试输出 | 该文件是纯 pytest 异步用例，没有 `__main__` 入口；直接按脚本方式运行不会收集任何用例 | 依据测试指南改用 `python -m pytest -v -s /tests/e2e_test_group_fs_sdk.py` 执行真实用例；后续同类纯 pytest 文件统一使用 pytest 入口 |
+| 已修复 | TypeScript Group management 成员最后消息断言偶发读取空状态 | `group.send` 返回后成员最后消息状态由服务端异步持久化，立即查询存在最终一致性窗口 | 测试增加 15 秒有界轮询；失败用例定向复跑 1/1 通过 |
+| 已修复 | TypeScript transport isolation 用例入口缺少 `TMPDIR` | 默认 SDK Tester 未注入 `TEMP/TMP/TMPDIR`，用例在真实 WebSocket 断言前直接退出 | TS/JS Tester Compose 注入 `/tmp` 临时目录；重建 Tester 后 TS transport isolation 3/3 通过 |
+| 已修复 | Go `TestIntegrationDeliveryChangedCompatibilityPush` 等待 P2P 兼容 Push 应用消息超时（`integration_delivery_changed_test.go:349`） | 禁用 V2 状态后 Go SDK 只记录 `max_seen` 并返回，未像其它 SDK 一样发布明文兼容 Push；Group 路径也存在同一分支问题 | Go P2P/Group 无 V2 session 的明文 seq Push 改为按 `push` 发布并生成 `delivery.changed`，加密 Push 继续走 Pull；Go 定向单测通过，Docker `TestIntegrationDeliveryChangedCompatibilityPush` 通过 |
+| 已修复 | Go `TestIntegrationDeliveryChangedMultiPagePullGlobalDrain` 等待两个 Pull reservation 超时（`integration_delivery_changed_test.go:462`，实际 `active=0`） | 重连后服务端排队的 P2P Push 先触发前台自动 Pull，显式 Pull 启动前消息已被消费；异步应用事件 handler 不能阻塞 Pull reservation | 集成测试在重连前为 P2P/Group namespace 建立临时实时同步占位，让重连 Push 仅记录待同步水位；显式两路 Pull 通过 Docker 定向验证，测试通过 |
+| 已修复 | 双域 Group 加人或定向邀请接受后首次 `group.pull` 持续为空 | 成员同步完成前 `group.pull_events` 为设备创建了临时群 head 游标（`join_msg_seq=1`）；成员表随后确认真实零入群下界，但已有游标读取未校正，seq=1 首条消息被过滤 | 消息/事件游标读取 SQL 在成员存在且 `join_*_seq=0` 时校正已有设备游标；新增 repository TDD 消息/事件场景，Group Go repository 测试及双域 `e2e_group.py` 四场景通过 |
+| 已修复 | 单域群主转让的异步 Push 瞬时丢失 | `group.transfer_owner` 已持久化 `owner_transfer_rekey_pending`，但 Group Go 已提交事件 Push 在 Gateway service-plane 短暂不可用时只尝试一次；Bob 未收到事件序号，客户端不会立即触发 gap-fill | 仅当事件目标存在在线 session 且 Gateway attach 正处于断线/重连传输窗口时，异步及已提交 Group Push 按 100/200/400/800ms 有界重试，保持原事件 ID 幂等；离线目标、普通超时和业务错误不重试。Group Go TDD 与 Python 群管理定向场景通过 |
+| 已处理并记录 | JS 浏览器 E2E 的 `new-device-message-history.spec.ts`、`service-proxy.spec.ts` 首次串行执行退出失败 | 首次浏览器运行出现瞬态测试运行态失败，单文件立即重跑均通过，未复现业务断言或服务端错误 | 按断点续跑规则保留首次失败记录并从原文件重跑；两文件分别 1/1 通过，未修改业务实现 |
+| 已处理并记录 | 本轮 TS 双域 federation 文件首次启动出现 `Worker exited unexpectedly`，随后 `ReferenceError: promises is not defined` | Vitest/Node 22 测试收集阶段的瞬态运行态异常，均发生在业务测试开始前；同一独立进程重启后未复现 | TS federation 指南改用 `node --max-opt=0 node_modules/vitest/vitest.mjs --pool forks` 固定入口；按断点规则重跑，`federation.test.ts` 2/2、`federation-v2-thought.test.ts` 2/2 通过，未修改业务实现 |
+| 已处理并记录 | 本轮 JS 双域 `federation.spec.ts` 在 Docker Tester 中以 `139`/`SIGSEGV` 退出 | Playwright worker 的 Node/V8 原生运行态崩溃，未产生业务断言结果；同一两域服务端保持运行 | 按指南切换宿主机 Node 复跑同一文件，3/3 通过；未修改业务实现，后续文件从 `notify.spec.ts` 继续 |
+| 已修复 | Go `TestIntegration_GroupBlockBanAndMemberStatus` 发送状态消息后立即读取到 `last_message_at=0`、`last_payload_type=""` | 成员最后消息状态由服务端异步持久化，测试读取早于最终一致性完成 | 测试改为 15 秒有界轮询成员状态；定向 Docker 集成测试通过 |
+| 已修复 | Go `TestIntegrationSPKRotation` 在 SPK 轮换后只收到 1/2 条消息 | 一条消息可能已经通过 Push 被确认，另一条仍在服务端可拉取窗口；测试 helper 只要收到部分 Push 就提前结束，未合并 Pull 结果 | 用 message_id 去重合并部分 Push 与后续 Pull；定向 Docker 集成测试通过 |