#NSIO Next · 功能闭环总账

本文回答一个实施问题：两个团队只读权威规格、分别实现每个组件，能否在不口头补充语义的情况下完成互操作。产品范围以能力目录为准；本总账只记录每项能力的完整调用链、权威落点、协议落点和证据门。

#1. 闭合等级

当前没有能力达到 ga_proven。除下文明确绑定到协议条款和证据包的窄切片外，各完整能力仍为 contract_closed + evidence_blocked。

slice_evidence_available 是独立的证据标记：它只证明列出的协议条款、提交、拓扑和场景，不自动解除完整能力的 evidence_blocked，也不自动使任何 Gate 通过。实现者和产品文案不得把局部执行序证据扩大解释为完整互操作、网络适应性、规模或 GA 证据。

reuse_evidence_available 是独立的工程标记：旧 NSIO 中已有实现和测试，说明算法/产品路径可复用，但不证明 Next 的对象、projection、credential、撤销和数据链已接通。只有 Next serializer、跨进程 fixture、集成和真机门通过后，才能解除 evidence_blocked。Edge 六种认证属于这一类；Relay、ServiceFlow 与 L3 candidate/roaming 没有同等完整的现网线协议证据。

#2. 四条标准调用链

#2.1 租户控制对象

Client/Console command
→ NSD authentication + TenantContext
→ AdminAuthorizer / corresponding Policy evaluator
→ Entitlement admission + expected revision + impact digest
→ one transaction: resource + audit + outbox
→ async compiler/controller
→ operation status + notification

适用于 Organization、Group、Role、AccessRequest、Capability、Service、Route、Gateway、PublicApplication、Share、Billing 和数据权利。事务成功不代表 runtime ready。

#2.2 Runtime 投影

NSD authority revision
→ production compiler/controller
→ target-minimal signed snapshot/delta
→ ns/NSGW validate version/signature/scope/watermark/expiry
→ build candidate + platform/config plan
→ journal + atomic apply + real-state verify
→ projection ACK
→ Client renders authority/projection/runtime separately

读/编译失败不生成空 snapshot。新投影失败保留未过期 last-known-good；过期按能力 fail-closed。

#2.3 节点/服务/路由流量

application or OS packet
→ local ns source projection
→ direct or Relay encrypted peer path
→ self-contained short credential where required
→ target ns/Connector publisher projection
→ local final authorization + destination/manifest check
→ target socket/network

NSD 不在建流路径上。Route 与 Service 的角色投影、凭据、generation/digest 和传输遵守 Data Plane Protocol。

#2.4 NSGW 能力

Gateway registration
→ CapabilityPolicy eligibility
→ per-instance CapabilityActivation + quota + audit
→ short Capability Lease + role config
→ NSGW staging/verify/atomic activate
→ terminal flow credential/tunnel lease
→ NSGW final scope/resource check
→ health/metering/ACK

Relay、Egress、Exit、Ingress 分 capability 隔离。NSGW 不读取 SKU、不获得完整目录、不扩大 AccessGrant。

#3. 身份、空间和设备总账

#4. Policy、请求和分享总账

#5. L3、路径、地址和 DNS 总账

#5.1 首份 Next 数据面执行证据

2026-08-09 的 l3-peerpath/20260809-bfd3f588 只证明 Data Plane Protocol §4.3 和 §4.4 的以下执行事实：

• source 在 WireGuard 封装前执行目标、purpose、lease、egress Grant 和 packet identity 判定；
• target 以已认证 peer key 映射 Membership，并在明文进入 channel/TUN/OS 前执行 ingress Grant、inner source 反欺骗和 ip_forward=false；
• lease 未过期时控制面离线不影响已授权 packet，过期后 fail-closed；
• dual_accept 的 current/next key epoch 归因到同一正确 Membership；更高权限 decoy Membership 的独占目标使错误归因可观测；
• 八个严格场景、七个编译期单判定翻转反测和 32 个非空 pcap 全部通过。

证据绑定 ns-next evidence commit 8e417f57、nsd-next@82c5c03e、ns-shared-next@38b34d7f、Linux 6.8.0-117-generic、BoringTun 0.7.1、runner image、fixture digest、拓扑和复现脚本。原始包位于该提交的 evidence/l3-peerpath/20260809-bfd3f588/。

这份证据只覆盖 userspace BoringTun carrier。内核 WireGuard 解密后直接进入内核网络栈，必须另行设计并证明 §4.3 第 3–4 步的等价 key-epoch→Membership 归因和 OS 注入前 inner-IP enforcement；在 nftables/eBPF 或其他执行点证据通过前，不能继承本切片结论。

这份证据也没有 NAT、CGNAT、双端 symmetric NAT、UDP blocked、Relay/WSS、漫游、真实路径 MTU、生产 AccessCompiler/Projection fanout 或完整撤销 SLA，因此 G2、G3、G9 均保持阻塞。

#5.2 首份 Next Relay 回退证据

2026-08-09 的 l3-relay/20260809-ed4f0563 证明了 Data Plane Protocol §5.1-§5.5 的一个有界 QUIC/userspace-WireGuard 切片：

• source、target 和 Relay 分处三个 Linux network namespace，两个 direct peer endpoint 被故意设为不可路由；
• 两端在可观测的 direct deadline 后先把 WireGuard peer 切到精确连接的本地 shim，再分别用定向 RelayRouteLease attach，不存在 attach 失败后静默恢复 direct 或明文路径；
• 独立 NSGW Relay 只本地校验短期 opaque route/session、projection digest、方向、租约和限制，并只转发加密 BoringTun UDP payload；
• 两个普通 ICMP packet 和一个精确 1280-byte inner packet 经 QUIC Relay 到达目标 OS；32-byte Relay header 的 1024-byte payload 上限触发 carrier 分片与有界重组，不改变内层 packet；
• 单判定 direct_connected=true 注入后两端不选择 Relay，目标保持 100% 不可达，证明严格场景不是由隐藏 direct fallback 偶然跑绿；
• Relay QUIC 与目标 TUN pcap 均非空，manifest 绑定四仓提交、runner image、Linux kernel、BoringTun 版本、fixture digest、构建锁文件和复现脚本 digest。

证据绑定 ns-next@ed4f05637724076aaef79b199bcf77b6e4c8f6f7、ns-shared-next@21e4bd931e24d184ae40f6bf3a1de4689ce6d48c、nsd-next@7be2cfde5303c46d159dfa91fccb712cd9fc7759 和 nsgw-next@ba3113b8afac11bee2c13b96a8cbbddda25087ea；原始证据位于 ns-next 的 evidence/l3-relay/20260809-ed4f0563/。

这份证据没有覆盖 WSS/UDP-blocked、NAT/CGNAT/symmetric NAT、candidate discovery、路径漫游、Relay 区域与容量切换、生产 projection fanout、内核 WireGuard 等价执行或完整撤销 SLA。它也没有证明超限 inner packet 的 ICMP PTB 注入。因此只增加 slice_evidence_available，G2、G3、G7、G9 均保持阻塞。

#5.3 Relay 授权与 MTU 边界补强证据

2026-08-09 的 l3-relay/20260809-0ad84086 沿用 §5.2 的真实 QUIC/netns 数据链，但把初版证据强度不足的两处单独补齐：

• NSGW 生产 Relay 仍只走严格本地验证；测试构建分别只放宽 lease validity、relay_route_digest、attach session binding、retired route 四个谓词。四组均证明严格路径拒绝，而单谓词放宽后 attach 或实际转发成功；生产 Relay binary 不包含这些 mutation 符号或 CLI 入口；
• direct_connected=true 路径注入继续证明选路严格场景；它只证明回落逻辑，不证明 NAT、CGNAT、symmetric NAT、UDP firewall 或 candidate probe 触发条件；
• 精确 1280-byte inner packet 经 Relay 到达目标 OS；1281-byte 且 DF 的 inner packet 在 source 的 1280-MTU TUN 明确返回 message too long, mtu=1280，target 专用 pcap 为 0 packet；
• Relay client 对超过 255 个 fragment 的 packet 返回 RelayClientError::PacketTooLarge。这和上一条 TUN MTU 错误是两个执行边界，不能合并为同一机制；
• 原始日志、五份 mutation JSON、QUIC/TUN pcap、fixture/lockfile 摘要、runner image、脚本 digest 和复现命令全部归档。

证据绑定 ns-next@0ad84086ecb31f21f2be25db5e594d08c73ae280、ns-shared-next@21e4bd931e24d184ae40f6bf3a1de4689ce6d48c、nsd-next@7be2cfde5303c46d159dfa91fccb712cd9fc7759 和 nsgw-next@b07a0656d31c4e9390667b6c3fc31efd4c9c3eb1；原始证据位于 ns-next 的 evidence/l3-relay/20260809-0ad84086/。

这份补强仍未证明 ICMP Packet Too Big 注入、真实 NAT/防火墙导致的 fallback trigger、WSS、candidate discovery/漫游、内核 WireGuard 等价执行、Relay 区域/容量切换、生产 projection fanout 或完整撤销 SLA。它增强 slice_evidence_available，不解除 G2、G3、G7、G9。

#5.4 首份直接 ServiceFlow 隔离证据

2026-08-09 的 service-flow/20260809-97e54ddb 证明了一个有界的 direct userspace-WireGuard TCP ServiceFlow：

• Source 和 Publisher 使用 NSD fixture 通过共享 production canonical CBOR、 digest 和 Ed25519 例程签发的 PeerPath、Consumer projection/credential、 Publisher projection 与本地 Manifest；fixture 不自行求值策略；
• 两份 Node projection 均没有 egress/ingress Node Grant。原始 ping 与指向 Publisher 真实诱饵 listener 的 TCP 在 source egress authorizer 被 service_transport_only 拒绝，未越过 carrier；
• 同一对节点的授权 Service 返回精确 backend 响应 service:exact-service-flow。Publisher decrypted boundary pcap 有 9 个 Service transport packet，OS pcap 有 17 个，Publisher 仅在本地完成签名、 source、Service/Endpoint、protocol/port、generation、digest、freshness、 nonce 与 Manifest 校验后连接 127.0.0.1 backend；
• Consumer projection、Publisher projection、credential scope、Manifest、 projection digest 和 security-first generation 六个判定各有单谓词翻转： 严格路径拒绝，翻转该谓词后放行；生产 binary 经扫描不含 mutation CLI 或符号；
• manifest 绑定 ns-next@97e54ddb13194b1ec46612333a585f8d4c8529d7、 ns-shared-next@d26d1b3d、nsd-next@3a487d26、nsgw-next@7efd4863、 Linux 6.8.0-117-generic、container image、lockfile 与复现脚本 digest， 且 NS worktree patch digest 为空补丁摘要。

该证据使用专用 TCP carrier，只验证 Service 授权结构和 L3 隔离，不证明 Data Plane Protocol §3.1 的 runtime-only QUIC、完整 v1 OPEN/ACCEPT framing、UDP、half-close、VIP/DNS、 Relay carrier、HA、生产 AccessCompiler/Projection fanout、revoke reset、 bounded_drain 或内核 WireGuard。因此只增加 slice_evidence_available， G2、G3、G4、G7、G9 均保持阻塞。

#5.5 Publisher 独立拒绝补强证据

2026-08-09 的 service-flow/20260809-d4d8681c 从干净的 ns-next@d4d8681c94746d92b9aae0ff88102ddfebddbd22 重跑 §5.4 正向场景， 并新增一条只在 Publisher 侧失配的端到端场景：

• nsd-next@da7a0cc46b0a37c3fdb16085a60c3d61a46592ed 使用 production canonical CBOR、签名和校验例程签发 service-consumer-target-reject.cbor；其 projection 与 credential 在 Consumer 侧一致，但与 Publisher projection 的 service_projection_digest 不一致；
• Source 合法接受该 Consumer artifact 并发送 OPEN。Publisher decrypted boundary pcap 记录 6 个 carrier packet，Publisher OS 的 daemon carrier pcap 记录 12 个 packet，证明请求真实到达 Publisher；
• Publisher 返回并记录稳定 ProjectionMismatch，客户端没有收到 Service 数据，配置的 loopback backend pcap 为 0 packet，证明拒绝发生在 backend dial 之前；
• Publisher credential 校验发生在专用 carrier 已进入 daemon 的 OS socket 之后，因此本场景的正确 fail-closed 判据是“carrier 已到、backend 为零”， 不是 publisher_os=0。后者只适用于 §4.3 原始 L3 的 OS 注入前 packet authorizer。

证据包由 ns-next@6f918cec 归档，manifest 绑定空 worktree patch digest、 Shared/NSD/NSGW revision、Linux 内核、runner image 和复现脚本。它补齐了 ServiceFlow 双端授权中 Publisher 独立拒绝的端到端证据；仍不证明 runtime QUIC、完整 OPEN/ACCEPT framing、directional half-close、reset、UDP、已传输 字节后的不可透明重放、HA、Relay carrier 或撤销收敛。

#5.6 Direct QUIC TCP ServiceFlow 传输证据

2026-08-09 的 service-flow/2026-08-09-8af9779b 在 §5.4/§5.5 的双端授权 基础上，把临时 TCP carrier 替换为 direct userspace-WireGuard path 内的 runtime-only QUIC：

• ns-shared-next@302afada1e9bff3a0ab2a3377bf570865a18e5c1 将 UDP 44330、精确 ALPN nsio-flow/1、证书 SHA-256、transport revision 和双方 共同 peer_epoch_id 绑定进签名的 PeerPath；
• nsd-next@7194e4ea8266983bf79c69686d618010f8751800 使用 production canonical CBOR/Ed25519 路径生成双方投影和确定性 runtime identity，私钥只作为 0600 node-local fixture 写出，不进入投影；Linux 互操作曾反向发现并修复双方 使用方向性 pair epoch 的真实跨仓库错误；
• Consumer 与 Publisher 使用双向证书固定的 mTLS，显式关闭 0-RTT。首个 QUIC stream 的 Runtime Hello 同时核对 source/target Membership、source WG key epoch、 共同 pair epoch、双方 transport revision 和 inner source IP；
• 每个 TCP flow 使用一个独立 bidirectional stream。OPEN 和 ACCEPT/REJECT 使用 64 KiB 上限的 canonical frame；Consumer 只接受 version、flow ID 和 generation 全部精确匹配的 ACCEPT。未知 OPEN major、零长度/超长控制帧关闭整条 connection， 且不拨 backend；
• 两个方向的 TCP EOF 分别映射 QUIC FIN，Consumer half-close 后仍收到 response， Publisher half-close 后仍收到后续 request。稳定 reset code 同时停止两方向； ACCEPT 后 backend 已观察到 1 byte 再 reset，不产生第二次 backend connection， 不重放该 byte；
• Publisher 在 backend dial 前原子执行 nonce replay 检查，过期项回收且有 65,536 条硬上限。重复 nonce 返回 ReplayDetected，容量耗尽返回 CapacityLimited；
• 正向 Linux 场景保持 Node L3 Grant 为空：原始 ping/TCP 在 source 边界拒绝， Service 返回 service:exact-service-flow。反向场景的 OPEN 到达 Publisher 后以 ProjectionMismatch 拒绝，backend pcap 仅 24-byte 文件头、零 packet；
• 13 个 focused runtime test、6 个单谓词授权 mutation、production binary 无 mutation 入口、两组 pcap/result/log 全部归档。manifest 绑定干净的 ns-next@8af9779be95488fc208bf0fbbc8746f80b79e2d2、共享/fixture/NSGW revision、 Linux 6.8.0-117-generic、container image 和复现脚本 digest；证据提交为 ns-next@e0a06e57。

这份证据把 direct TCP ServiceFlow 的 §3.3 OPEN/ACCEPT、双向 half-close、reset 收敛和已传输字节不可透明重放提升为 slice_evidence_available。它不证明 UDP ServiceFlow、ServiceFlow 经 Relay/WSS、exclusive listener/firewall 隔离、 VIP/DNS、multi-endpoint HA、bounded drain、生产 NSD AccessCompiler/fanout、 控制面撤销在途流、内核 WireGuard、NAT/漫游或移动端；G2、G3、G4、G7、G9 继续阻塞。

#5.7 Relay-carried QUIC TCP ServiceFlow 组合证据

2026-08-09 的 service-relay/2026-08-09-b99c93d5 将 §5.6 已证明的 runtime-only QUIC TCP ServiceFlow 放入 §5.2/§5.3 已证明的 opaque QUIC Relay 承载中，未新增协议或放宽任何授权面：

• Source、Publisher 与独立 NSGW Relay 分处三个 Linux network namespace；两端 direct WireGuard endpoint 使用不可路由 TEST-NET 地址，direct deadline 后才把 精确 peer endpoint 切到本地 Relay shim；
• 两端分别用独立 RelayRouteLease attach 到同一短期 opaque route，Relay 日志只 出现两个不同 session ID 和同一个 route ID。日志扫描未出现 Membership、WG key、 Node IP、Service ID 或应用明文；
• Node L3 Grant 仍为空，原始 ICMP/TCP 在 Source egress 被拒绝；同一 peer path 上的 授权 Service 经原有 Consumer/Publisher projection、credential、Manifest、digest、 generation、Runtime Hello 和 OPEN/ACCEPT 校验返回精确 service:exact-service-flow，backend 只建立一次连接；
• 单判定 direct_connected=true 翻转会跳过 Relay，Service 不可用且 backend 零报文， 证明成功路径没有隐藏 direct 或明文 fallback；
• Service 已 ACCEPT 且 backend 已接收一次 first 后终止 Relay。两端在 QUIC 2 秒 keepalive、10 秒 idle timeout 的有界窗口内将 Relay 失败上送 runtime supervisor，客户端收到 EOF，backend 没有第二次连接、没有收到 second，也没有 重放 first；
• manifest 绑定干净的 ns-next@b99c93d5、Shared/NSD/NSGW revision、Linux kernel、BoringTun、container image、拓扑、复现命令，以及外层脚本、Linux 脚本和 Dockerfile 三份独立 SHA-256；外层 runner 会在归档前反向核验三份摘要。

证据由 ns-next@d2e08c12 归档，原始结果位于 evidence/service-relay/2026-08-09-b99c93d5/。

这份证据证明的是 Relay-carried userspace-WireGuard 上的 TCP ServiceFlow 组合与 已接受流的 fail-closed 中断，不证明真实 NAT/防火墙触发、direct↔Relay 迁移或重连、 WSS、UDP ServiceFlow、VIP/DNS、multi-endpoint HA、generation drain、生产 NSD 编译/撤销 fanout、内核 WireGuard、移动端或完整撤销 SLA。G2、G3、G4、G7、G9 继续阻塞。

#5.8 Direct 与 Relay-carried QUIC UDP ServiceFlow 证据

2026-08-09 的 service-udp/2026-08-09-675bff43 在不改变 §5.4-§5.7 授权边界的前提下，实现并验证了 flow-scoped UDP ServiceFlow。OPEN 与 ACCEPT/REJECT 仍走有界 QUIC control stream，ACCEPT 后的应用报文只走 QUIC DATAGRAM，不把 UDP 透明转换成可靠字节流：

• ns-shared-next@13330d08056d63fc2000af930802511b68730640 固定 v1 datagram header、精确 payload length、flow close、mandatory idle timeout 与 maximum datagram；未知版本/flags、长度不一致和超限输入 fail-closed；
• nsd-next@686d3a36aafa6a2bd3d9cda0ab07ac3f97a5a445 经 production canonical CBOR/Ed25519 路径生成 protocol=UDP 的 consumer/publisher projection、 credential 与 local Manifest；nsgw-next@c69f4b08 只对齐共享契约，Relay 仍只转发 opaque WireGuard frame；
• 一个 authenticated QUIC connection 只有一个 DATAGRAM reader。Consumer 以 local source tuple 建立随机 flow ID；Publisher 为每个 accepted flow 建立独立 connected UDP backend socket。4096 flow 上限、每 flow 64 条有界队列和 30 秒 双向 idle timeout 都是运行时约束，不是文档默认值；
• direct 与 Relay 两条路径分别以两个 local source port 发送 alpha、beta、 empty、协商环境上限 1134-byte 和 intentional-drop 报文。两条路径的四个成功 payload digest 完全一致，backend 只看到 5 个原始 datagram，两个 source tuple 对应不同 backend source port，边界未合并；
• intentional-drop 没有重传；2000-byte 本地报文在 Consumer 以 max_payload=1134 拒绝且 backend 零投递。pre-ACCEPT、post-close、unknown-flow、 malformed 与 publisher oversize 的 focused negative control 同样证明零 backend delivery；production binary 不包含 mutation 入口；
• 同一个 client source port 空闲 32 秒后得到新的 flow ID 和新的 publisher backend source port，旧 flow 没有复活。Relay 在 ACCEPT 和首个 backend datagram 后被主动终止，post-loss datagram 无回复、backend 总数仍为 1，没有自动重连或 replay；
• direct_connected=true 单谓词翻转会跳过 Relay，client 超时且 backend 零 datagram，证明 Relay 成功路径没有隐藏 direct/plaintext fallback；Relay 日志和 pcap 扫描未出现 Membership、Node IP、WG key、Service identity 或应用明文。

manifest 绑定干净的 ns-next@675bff439b3006c1409a1f35d46b0426027782ed、 上述 Shared/NSD/NSGW revision、Linux 6.8.0-117-generic、BoringTun 0.7.1、 container image、拓扑、复现命令和五份 runner digest；证据归档提交为 ns-next@bf3312e4。

这份证据把 userspace-WireGuard 上 direct 与 opaque-Relay-carried UDP ServiceFlow 的协议匹配、准入、DATAGRAM 边界、源隔离、loss/no-retransmit、超限拒绝、idle replacement 和 Relay-loss no-replay 提升为 slice_evidence_available。它不 证明 VIP/split DNS、真实 NAT/防火墙触发、candidate/roaming、WSS、packet reordering 注入、multi-endpoint HA/drain、生产 AccessCompiler/撤销 fanout、内核 WireGuard、平台 reserved listener、移动端或容量目标。G2、G3、G4、G7、G9 继续阻塞。

#5.9 Authenticated Candidate 与构造漫游证据

2026-08-09 的 l3-roaming/20260809T151500Z 在 userspace BoringTun 上证明了 一个有界的 authenticated candidate/discovery/endpoint-promotion 切片：

• ns-shared-next@3baf7fbc 定义 Node-signed candidate report、短期 discovery certificate、target-specific NSD projection 和 canonical signed ping/pong； projection signature、freshness、audience、peer WG key epoch 四个检查分别有 compile-time 单判定反向控制；
• nsd-next@d9f35dc6 在签发 projection 前验证 Node identity、Membership、WG key epoch 和 report high-water mark。stale report 严格路径拒绝，const-generic test-only 翻转后接受；普通构建不实例化关闭检查的版本；
• ns-next@a099c14b 在 WireGuard 的同一 UDP socket 上处理 discovery。错误或未知 owned frame 静默消费，不落入普通 WG parser，也不产生放大响应；Ping validation、 bounded replay cache、Pong validation 三个运行时判定分别有严格/翻转成对断言；
• 构造 underlay move 场景在 Node IP、PeerPathLease 和 WG identity 不变时观察到 10 个 discovery datagram、新 endpoint 上 20 个 carrier datagram；晋升后的专用 pcap 中新 endpoint 14 个、旧 endpoint 0 个，underlay Node plaintext 为 0；
• discovery 成功但目标端阻断 WG handshake 时，candidate 只进入 probe-ready，运行时 没有 endpoint promotion，L3 保持不可达；错误 audience 与 expired projection 都在 runtime readiness 前以稳定错误拒绝；
• 八份 mutation JSON、三层原始测试日志、两个非空 carrier pcap、生产 binary mutation 字符串排除、四仓 revision、Linux kernel、BoringTun 版本、container image、 lockfile 与复现脚本 digest 均进入 manifest，并通过外层 SHA-256 复核。

原始运行绑定 ns-next@a099c14b05bbe2ce09add986aacdc8c7ab4acbb6、 nsd-next@d9f35dc6561628b87e80ee75ffd6e77e569e6852、 nsgw-next@2a539f4417811a9d23b2d8b223c2e0598aa5f8e0 和 ns-shared-next@3baf7fbc2e6ab3ce2effd8a133262e0f4929c7e0；证据由 ns-next@8b0559d36c06e0e60aad2cc3a5c00bed03735e09 归档。

这份证据只证明启动时已加载 projection 内候选的构造 IPv4 underlay move。它 没有证明运行中接受更高 report_epoch 的 projection 并原子替换候选，也没有证明 旧/同 epoch 冲突热更新拒绝；没有真实 NAT、CGNAT、双端 symmetric NAT、UDP blocked/WSS、direct↔Relay 迁移、移动端接口回调、内核 WireGuard 等价执行、生产 NSD report persistence/fanout、规模或完整撤销 SLA。因此只增加 slice_evidence_available，G2、G6、G9 继续阻塞。

#5.10 Candidate Projection 运行时热替换证据

2026-08-09 的 l3-roaming-hot-update/20260809T190000Z 补齐 §5.9 刻意保留的 运行时 projection 生命周期缺口，但没有把 deterministic fixture 提升为生产控制面：

• nsd-next@c64b0d16 使用与生产相同的 canonical CBOR、签名和 validation 路径，为 fixture 增加独立 projection_issued_at，从而能构造同一已认证 report 在不同 projection revision/签发时刻下的精确 redelivery、rollback 与 conflict；
• ns-next@0664b0c6 在活跃 runtime 中原子替换已验证 projection：更高 report epoch 必须携带更高 projection revision；旧 report/revision 被拒，equal revision 只有 claims 完全相同时才幂等接受，equal-conflicting material fail-closed；
• 更新会清除旧 candidate 的 pending ping/order，但保留有界 replay cache，不自行 晋升 endpoint 或发送 WG 流量。新 candidate 必须重新完成 signed ping/pong 与 WireGuard authenticated handshake 后才能切换 live peer；
• 只有 candidate 过期或新 projection 暂无可用 candidate 时，旧候选从探测集合移除， 但 Membership、PeerPathLease 和当前授权 runtime 不被伪装成 revoked；后续更新可 恢复候选探测；
• 四个 compile-time 单谓词反向控制分别证明 report rollback、report conflict、 projection rollback 和 projection conflict 保护有效；release binary 扫描确认不含 mutation 入口；证据包的日志、manifest 与 SHA-256 全部可复核。

证据归档于 ns-next@4fdbcdca，manifest 绑定 ns-next@701650a6、ns-shared-next@3baf7fbc、 nsd-next@c64b0d16、nsgw-next@2a539f44、Darwin 24.1.0、Rust 1.96.0、userspace BoringTun 适用范围和精确复现命令。

该证据当时没有实现或证明 Node report 的生产接收与 high-water 持久化、NSD target-minimal compiler/fanout、authenticated control stream 的 delivery/ACK/replay、 真实接口变化、NAT/CGNAT/symmetric NAT、UDP blocked/WSS、direct↔Relay 自动迁移、 移动端回调、内核 WireGuard 等价执行、规模或撤销 SLA。总账因此只更新有界 slice_evidence_available；后续 controller 与单实例持久化证据分别见 §5.11、 §5.12，但不扩大本次 packet-path 证据；G2、G6、G9 继续阻塞。

#5.11 Signed Candidate Delivery 核心证据

2026-08-09 的四仓提交补齐了 §5.10 刻意保留的 transport-independent controller/consumer 缺口，但没有把它描述成生产网络传输：

• ns-shared-next@d5b6c3c0 定义 target-bound signed projection event、snapshot/ delta mode、epoch/revision/base、payload digest、applied watermark、typed ACK 和 stable reject code，并区分 not-yet-valid、expired 与 malformed；Candidate helper 同时绑定 outer target/revision/digest 与 inner signed projection；
• nsd-next@449585cc 的生产 Candidate controller 验证注册 Membership、Node identity、WG key epoch、report high-water 与 equal-epoch conflict，随后在一个 repository CAS 边界中更新 report、全部 target head 和 outbox。fixture 调用该 controller，不再维护第二套签发逻辑；in-memory repository 明确只作 reference， 不冒充 durable/HA storage；
• ns-next@53f72186 的 consumer 先验证 outer signature/freshness/target/stream/ event type/epoch/revision/base/digest，再独立验证 inner Candidate binding，最后才 原子替换 DiscoveryRuntime。watermark 只在 apply/unchanged 后前移；拒绝保留 runtime 与水位；完整密码学验证发生在 delivery watermark 锁之前，ACK 只为签名 有效且精确指向本 Membership 的事件产生；
• higher delivery epoch 只允许同一 inner projection revision 的受控元数据刷新；它 不是内容回滚授权，lower inner revision 或 higher report 携带 non-advancing inner revision 都 fail-closed。未来若需要显式回滚，必须使用独立签名恢复授权。持久化水位 还必须与运行时已加载 projection payload digest 一致，避免重启把未应用状态误判为 exact redelivery；
• 跨仓库测试使用 production NSD controller 和 Shared canonical signer，覆盖 initial/ newer/exact redelivery、stale/conflicting、wrong target、invalid signature、corrupt/ expired/future payload、Candidate v1 delta rejection、inner apply failure、新 epoch rollback rejection、equal-inner-revision refresh、exact redelivery freshness 与 persisted-watermark mismatch。ns-next 最终状态通过 full workspace test 与 full workspace Clippy；nsgw-next@a74030b9 仅对齐同一份 Shared/NSD revision；后续 nsgw-next@30bd17ee 对齐修订契约，并通过 Relay crate 的 15 项测试与 Clippy。

这份证据把“fixture file 直接调用 runtime”推进为可由未来认证 transport 调用的 生产 controller/consumer core。单实例 SQLite 持久化的后续证据见 §5.12；本节 自身没有实现或证明 Device-session /control authentication、网络 reconnect/ ACK exchange、transactional outbox worker、多实例 claim/lease、真实 NAT/接口变化、 移动端或 kernel WireGuard。G2、G6、G9 继续阻塞，production transport/HA fanout 不得因本节变绿。后续认证网络投递与断线重投证据见 §5.16，但不反向扩大本节范围。

#5.12 Candidate 单实例持久权威证据

nsd-next@d1acf6cef8479cfb7fb1dc5b1c9085b46051184c 把 §5.11 的 repository boundary 落成独立 nsd-next-store 生产 crate，但证据范围严格限定为 单 NSD 进程使用的 SQLite 持久化：

• 独立 Diesel migration 与 schema 不复用 legacy Realm/Machine/NSC/NSN 表；source aggregate 持久化注册 source、精确 authorized targets、report high-water、target projection heads、每目标 revision high-water、CAS generation 与显式 payload schema version；
• signed projection outbox 独立存储 event/target/epoch/revision/digest、完整 signed head、 ACK 与 observation time；关系列与 CBOR 内容在读取时交叉校验，损坏或未知 schema version 返回 read_unavailable，不折叠成没有授权或空目录；
• report authority 更新与全部新 target events 在同一个 SQLite IMMEDIATE transaction 内提交。outbox 插入故障会回滚 report/generation；并发双写者只有一个 Applied，另一方得到显式 CAS conflict，不产生重复事件；
• 普通进程重启保持 delivery epoch、report/projection/outbox/ACK。精确 report replay 不提升 revision、不重复入队；精确 ACK replay 为 unchanged，冲突 ACK 被拒绝；
• target deauthorization 删除 active head/outbox，但保留 revision high-water；重新授权 后从下一 revision 签发。显式 authority reseed 才提升 delivery epoch，并清除旧 head/ outbox 后按保留的 revision high-water 重新投影；普通重启不得隐式换 epoch；
• focused 14 tests、NSD full workspace tests、full workspace Clippy、Diesel migration apply/redo、generated schema comparison、format 与 diff checks 全部通过。

该证据当时不包含 authenticated Device-session /control、网络 reconnect/ACK exchange、 异步 outbox worker、PostgreSQL、multi-instance claim/lease、active-active 或故障转移。 因此这里只增加 single_instance_durability_evidence_available，不宣称 HA 或 G2/G6/G9 通过。后续 §5.16 只证明该 SQLite outbox 与真实 QUIC 单事件投递的组合。

#5.13 Device 控制会话契约与单实例权威证据

ns-shared-next@6d465c81c9a7f7a66ff8a5bffd1416e27f710a34 与 nsd-next@2694767 与 ns-next@aed89645 把 Runtime Protocol §1 从概述推进为可执行的四消息控制会话切片：

• Shared 使用 production canonical CBOR、domain-separated digest 和 Ed25519 artifact， 定义 Device-signed Hello、NSD-signed Challenge、Device-signed Authenticate 与 NSD-signed SessionCredential；完整 transcript、双方 manifest、确定性 capability 交集、 Deployment/Organization/Device/Key/Membership scope 和 session generation 均被签名；
• control@1.0 是不可移除的 mandatory capability。未知可选 feature 只能不协商，不能 触发更宽松认证路径；Challenge 最长 60 秒，Credential 最长 15 分钟；
• NSD 在验证注册 Device Key 的完整 Hello 前不信任定位字段。Challenge 绑定连接唯一的 authenticated transport binding、Device authority generation 和 expected session generation；Membership 或 Key 权威变化会使在途 Challenge 失效；
• Challenge consumption 与 session generation advancement 在一个 repository commit 内完成。两写者并发时只签发一个新 generation；同一 transport 的精确 Authenticate 重传返回原 signed bytes，跨 transport/不同 proof/过期或被后续 session 取代均拒绝；
• Credential 只含当前 Device 的精确排序 Membership 集，scope 只能读取 runtime projection。Repository 反向测试证明即使传入结构上有效但扩大 Membership 的 credential 也无法提交；
• ns-next 使用 transport-independent typestate client 保留四个 exact signed artifact； 未验证 Challenge 时不暴露 Authenticate，重试复用同一 Authenticate bytes，最终 Credential 只有在 pinned NSD Authority 和完整 transcript 验证后才可见。每次投影 target admission 还会重新检查 Credential 有效期与精确 Membership scope；
• 跨仓库测试覆盖正常握手、exact retransmission、未 pin Authority、sibling transcript、 Challenge/Credential expiry、scope 越界、mandatory capability downgrade 与非 canonical watermark。Shared focused tests、NSD 9 条 session 测试、ns-next 7 条 client 测试、 三仓 full workspace tests/Clippy、供应链、FFI contract、format 与 diff checks 全部通过。

该证据只覆盖 Shared wire/crypto contract、nsd-next-control 的传输无关单进程内存事务 权威和 ns-next 的传输无关 client。它没有实现或证明 HTTP/QUIC /control framing、真实信道 exporter、Challenge/session 进程重启持久化、多实例 claim、 Credential 在线撤销传播、Candidate outbox 网络发送/ACK、reconnect scheduler 或 HA。 因此这里只增加 control_session_core_evidence_available，不解除 G2、G6、G9。

#5.14 Device 控制会话单实例持久权威证据

nsd-next@c09dff4 把 §5.13 的内存 NSD 权威推进为隔离的、可跨重启恢复的 SQLite repository，同时保持相同的 Shared 契约和 controller 事务边界：

• generated Device/Challenge 表不复用 legacy Realm/Machine/NSC/NSN 存储；精确 Device authority、Membership scope、transport binding、Challenge artifacts、签名 Credential bytes、consumption result、authority generation 与 session generation 均被持久化；
• canonical CBOR 与索引列并存且每次读取交叉校验。未知 schema、损坏 CBOR 或索引 内容不一致返回 read_unavailable，不伪装成 Device 不存在或 Challenge 未消费；
• Challenge consumption 与 Device session-generation advancement 在一个 SQLite IMMEDIATE transaction 内提交。注入第二次写失败会整体回滚；并发 exact Authenticate 收敛为一个 Issued 与一个字节完全相同的 ExactRetransmission；
• pending Challenge 与 exact retransmission 可跨 repository/process reopen 恢复。 cross-transport replay、Challenge expiry、Device authority 变化、session generation 变化与 conflicting consumption 仍是独立 fail-closed 结果；
• production controller 不再根据两个非事务读取对并发 exact Authenticate 提前作出 stale 判断；最终 stale generation 与 exact retransmission 分类由 repository 原子决定；
• 九条 focused integration tests、并发签发 20 次压力重复、migration apply/revert/ reapply、generated-schema comparison、default/all-feature workspace tests、full Clippy、supply-chain、unused-dependency、spelling、documentation、format 与 diff gates 全部通过。

该证据严格限定为单 NSD 进程使用 SQLite。它没有实现或证明 HTTP/QUIC /control framing、真实 channel exporter、network reconnect、Candidate outbox send/ACK、Credential 在线撤销、PostgreSQL、multi-instance claim/lease、active-active 或 failover。因此这里只增加 control_session_single_instance_durability_evidence_available；G2、G6、G9 继续阻塞。

#5.15 Device 控制会话真实 QUIC 互操作证据

ns-shared-next@af6c9cdc0336e4f76263d48fb81099ba6cd58816、 nsd-next@f3f579cc84f0e863d9084bbebac9b9b41ded6295 与 ns-next@cc78304f 把 §5.13 的传输无关握手推进到真实 loopback UDP/QUIC：

• Shared 定义唯一 nsio-control/1 ALPN、四字节大端长度前缀、256 KiB body 上限和 stage-bound canonical CBOR frame。接收端先校验长度前缀再分配 body，且 artifact kind 必须与 Hello/Challenge/Authenticate/Credential stage 一致；
• NSD 禁用 0-RTT，只允许首条双向控制 stream，并从 live QUIC TLS exporter 派生 transport binding。完整 Credential 事务提交前不返回 authenticated stream；拒绝时 对端只看到通用 transport reason，服务端保留结构化内部错误；
• ns 使用 enrollment 固定的 TLS roots 与 NSD Authority，要求精确 ALPN，按唯一 四消息顺序驱动原 typestate client。只有 TLS、Challenge、完整 transcript 和最终 Credential 全部通过后，调用方才得到 live stream 与 EstablishedControlSession；
• NSD 五条网络测试覆盖成功、跨 QUIC 连接 Authenticate replay、oversize prefix、 wrong-stage artifact 与错误 ALPN；ns 五条跨仓库网络测试覆盖成功、不受信任证书、 未 pin Authority、过期 Challenge 与合法编码但错误 stage；所有失败路径都不推进 Device session_generation；
• nsgw-next@224342f 仅把 Relay 测试依赖对齐到同一 Shared revision，15 条 Relay 测试与 Clippy 通过；ns-next 的 dependency graph 不再同时包含两份 nsio-next-contracts，并保持 ring-only Rustls/QUIC 图。

该证据证明 production adapters 的认证网络边界，但不把两个独立持久化证据 拼成未经测试的结论：跨进程重启后的网络 Challenge/session 恢复仍未实证。Candidate outbox 网络发送与 ACK 在后续 §5.16 得到有界证据；长运行 reconnect/backoff、Credential 在线撤销、PostgreSQL、 multi-instance claim/fanout、active-active 与 failover 仍阻塞。因此这里只增加 authenticated_control_transport_evidence_available，G2、G6、G9 不变。

#5.16 Candidate 认证网络投递与断线重投证据

2026-08-10 的 Shared、NSD 与 ns 提交把 §5.11、§5.12 和 §5.15 的独立边界 组合成一条真实 QUIC、单事件、单实例 SQLite 投递链：

• ns-shared-next@ed113467643c5ac5ddfad97aec7117c43de283cf 在认证握手后增加 bounded canonical projection_event / projection_ack frame；event 与 ACK 都保留 event ID、target Membership、stream、epoch、revision 和 payload digest 的精确关联；
• nsd-next@611750c38e767dd0bda67d2311a2eacc5e5376ee 从已提交 Credential 解出 Membership scope，只读取该 scope 内稳定排序的 pending Candidate，发送一条后必须 收到精确 ACK 才推进 SQLite outbox；transport、scope、malformed frame 或 correlation 失败均不清 pending；
• ns-next@95903cf8 只在四消息握手完成后读取 event，并先经过已有签名、freshness、 monotonic watermark、inner Candidate binding 与 last-known-good consumer。应用后再次 校验 Credential freshness 和 Membership scope，才发送 ACK；无法安全确定 target 时 关闭连接且不 ACK；
• 跨仓测试先写入 revision 2，真实 NSD adapter 发送后由 ns 应用，但客户端在 ACK 前 断线。SQLite outbox 仍保留完全相同的 signed event；重连后收到相同字节，consumer 返回 Unchanged，只有精确关联的 ACK 才清除 pending；
• 反向注入在断线前越过 ACK 边界直接清除 outbox，使测试在“pending 必须仍存在”断言 处变红；恢复生产路径后重新跑绿。因此证据验证的是 ACK 时机，而不只是一次成功收发；
• ns-next 通过 workspace default/all-feature tests、all-feature Clippy、deny、shear、 typos、FFI contracts、format 与 diff gates；NSD 通过 workspace all-feature tests、 doctests、Clippy、deny、shear、typos、documentation、format 与 diff gates。

该证据只覆盖一条已认证连接上的单事件投递，以及断线后由测试显式建立的新连接。 它不证明生产 daemon 的长运行 reconnect/backoff、空闲等待/唤醒、公平多 Membership fanout、Credential 在线撤销传播、PostgreSQL claim/lease、多实例 active-active 或 failover，也不证明跨进程 Challenge/session 恢复。因此只增加 candidate_network_delivery_evidence_available；G2、G6、G9 继续阻塞。

#5.17 Candidate 长运行监督、空闲唤醒与多 Membership 恢复证据

2026-08-10 的 Shared、NSD 与 ns 提交把 §5.16 的有界单事件组合扩展为 可取消的长运行控制会话，但仍限定在单 NSD 进程与 SQLite outbox：

• ns-shared-next@ed113467643c5ac5ddfad97aec7117c43de283cf 提供本轮使用的 canonical frame、水位和 ACK 契约；nsd-next@1f10999d4db0e12df58b971f5087d8f05406c2bd 在同一认证会话内稳定轮转 Credential 的 Membership scope，并以 durable commit 唤醒空闲 Candidate worker；ns-next@e32ca2f9a789e81db749a2f884c9907d127cf38e 增加可取消 receive/reconnect supervisor 与按 Membership 隔离的 consumer registry；
• supervisor 每次重新认证后发送全部本地 Membership 水位，transport close 只进入 有界 equal-jitter exponential backoff；协议、scope、签名和内容拒绝仍是 terminal， 不被重试分类伪装成暂时网络问题；一次健康认证会话会重置 backoff；
• consumer registry 只用未验证 target 作为有界路由提示。被选中的 consumer 仍独立验证 Authority 签名、target、freshness、payload digest、inner Candidate binding 与单调水位， 因而路由提示不能扩大授权；
• 真实 QUIC/SQLite 跨仓测试证明：apply-before-ACK 断线后 pending 保留、重连收到精确原字节、 idempotent ACK 才清 pending；连接空闲后再提交 revision 3 会唤醒同一 NSD worker； cancellation 可终止空闲认证会话；多 Membership 顺序为 A→B→A，不会由一个持续有事件的 Membership 饿死另一个；
• 反向注入把 transport delivery loss 从 transient 改成 terminal，跨仓测试在 supervisor reconnect 断言超时变红；恢复单个 predicate 后重新跑绿。该注入证明的是重连触发分类， 不是仅证明测试能建立第二条连接；
• ns-next 的 default/all-feature tests、all-target/all-feature Clippy、deny、shear、typos、 FFI contracts、package Rustdoc、format 与 diff gates 通过；NSD 的 all-feature tests 在 串行模式通过，Clippy、doctests、deny、shear、typos、workspace Rustdoc、format 与 diff gates 通过。NSD 并行全量测试仍有既有 telemetry 全局状态竞态，不作为本切片能力声明。

该证据只证明 controller-local wake、单进程 SQLite authority 和 userspace runtime adapter。 它不证明 Credential 在线撤销传播、跨进程/跨实例 wake、PostgreSQL claim/lease、HA active-active/failover，也未把 supervisor 接入所有平台的 production daemon owner lifecycle。因此只增加 candidate_delivery_supervision_evidence_available；G0、G2、G6、 G9 保持原状态。

#5.18 Candidate 在线控制权威复核与重认证恢复证据

2026-08-10 的 Shared、NSD、Relay 依赖对齐与 ns 提交把 §5.17 刻意保留的 单实例在线权威复核闭合，但不扩大为完整 G9 撤销声明：

• ns-shared-next@deb7bc3e61be0aa7cb98eb5e7812a370ca772d37 在签名 ControlSessionCredential 中加入必需且非零的 authority_generation；真实结构经 published schema 校验，旧 fixture 或缺字段负载不能继续通过；
• nsd-next@5c7b157c0c66c5912da5aa71ca2fcbc4ba6b17a3 在发送前、空闲等待、 ACK 等待和 ACK 持久化前复核 fixed expiry、Device status、Device Key、Organization、 deployment、Membership scope、authority generation 与 latest session generation； expired、revoked、superseded 和 authority read failure 保持为四种不同事实；
• ACK 等待期间使用持续保留的 frame read future，周期复核不会取消半读 frame；权威在 event 发出后、ACK 到达前变化时，晚到 ACK 被拒绝且不能删除 durable outbox row；
• nsgw-next@b6cc5dd8245f978ed828db9e8850586de4545f91 只对齐同一 Shared/NSD revision，防止 Relay 测试图中出现两个来源不同但同名的 Credential 类型，不增加 Relay 产品能力声明；
• ns-next@1ff467d0d12d87ff14baa2267c5ebdb94b25041b 的真实 loopback QUIC 与 SQLite 测试证明四条行为：失效权威在新事件发送前终止；event 已发后失效会拒绝晚到 ACK 并保留原 outbox；新认证 session 使旧 idle stream superseded 且只有最新 stream 收到事件；Device 恢复 active 并以新 authority generation 认证后，会收到并 ACK 同一 pending event；
• NSD 的内存/SQLite 单测覆盖 Device disable、key replacement、Membership scope change、 fixed expiry、session supersession 与 repository read failure；ns-next 的 focused 4 条 interop 测试、workspace all-feature tests、all-target/all-feature Clippy 与格式门通过。 macOS 深层临时目录曾使一条无关 CLI Unix socket 超出 SUN_LEN；完整测试在短 TMPDIR=/tmp 下通过，未通过忽略或降低断言处理。

该证据只证明一个 NSD 进程内的 Device/latest-session 在线权威复核和 SQLite outbox 恢复。它不证明按单份 Credential revoke_key 的定向撤销、跨进程/跨实例 wake、 PostgreSQL claim/lease、HA active-active/failover、全部平台 production daemon owner lifecycle 接线或 G9 撤销 SLA。因此只增加 live_control_authority_evidence_available；G0、G2、G6、G9 保持原状态。

#5.19 定向 Control Credential 撤销与 outbox 恢复证据

2026-08-10 的 NSD 与 ns 提交闭合了 §5.18 明确保留的单份 Credential revoke_key 核心语义，但尚未形成管理员可操作的完整撤销产品面：

• nsd-next@4a359f3c09ab02f1cad12da13df62f159f911f16 把当前 Credential 的 session/credential ID、revoke key、generation、签发/过期时间与撤销时间放入同一 durable Device session snapshot；Credential 签发与 session generation 原子提交；
• 定向撤销同时绑定 Device、Credential、revoke key 和 generation，区分 revoked、 already_revoked 与 superseded。它不 disable Device、不改变 Membership，也不 bump generation；旧 key 不能撤销随后重新认证的新 Credential；
• SQLite restart 测试证明撤销 disposition 跨进程恢复；并发 revoke/reauthentication 通过 BEGIN IMMEDIATE 串行化，最终只有新 Credential active；stale Device replacement 的 CAS 不能擦除并发撤销；
• ns-next@ef25e983ece7bf3cc3146d83db970d0bd856850a 固定上述 NSD revision， 从真实 authenticated QUIC connection 取原始 NSD-signed Credential 执行撤销，不使用 测试专用身份；
• event 已发但 ACK 未提交时撤销，服务端返回 CredentialRevoked，晚到 ACK 不能清除 SQLite outbox；idle Credential 被撤销后不能收到新事件，fresh generation 会收到并 ACK 同一 pending event；既有 Device disable、latest-session supersession 与 reconnect 证据仍通过；
• NSD 与 ns 的 workspace format、all-target/all-feature Clippy、all-feature tests 与 doctests 通过；ns 完整测试继续使用短 TMPDIR=/tmp 避免 macOS 无关 Unix socket 路径超限，未降低断言或忽略失败。

该证据只增加 targeted_control_credential_revocation_evidence_available。它不证明 管理 API 的调用者授权、actor/reason 审计、平台 daemon owner lifecycle 接线、PostgreSQL 事务、跨实例 wake/关闭、HA active-active/failover 或 60 秒/5 分钟 G9 撤销 SLA。因此 G0、G2、G6、G9 保持原状态。

#5.20 管理员撤销与生产 Control Listener 证据

2026-08-10 的两次 nsd-next 提交把 §5.19 的核心撤销原语接入了真实管理面和 生产进程，但证据仍严格限定为单 NSD + SQLite：

• nsd-next@1556668 提供 POST /api/v1/next/devices/{device_id}/control-credentials/{credential_id}/revoke 与 Organization-scoped revocation ledger；调用要求管理员会话、step-up、精确 Deployment/Organization/Device/Credential，actor、reason 和 outcome 与撤销在同一 BEGIN IMMEDIATE 事务提交；跨 Organization 查询与撤销均不泄漏目标存在性；
• nsd-next@2f1a1f9 从 production nsd 进程绑定独立 Next QUIC listener，强制完整 bind/certificate/private-key 配置、固定 ALPN、early_data=false，并把所有同步 SQLite 权威调用移到 Tokio blocking pool；
• 管理 API 与 QUIC listener 使用同一 Deployment 和数据库。真实 QUIC Device 完成 Hello/Challenge/Authenticate/Credential 后，管理员精确撤销该 Credential；listener 在有界 idle recheck 内关闭该连接，Device authority generation 与 Membership 不变；
• artifact signing key 与 TLS key 分离。签名公钥按 Deployment 单例绑定进 Next 数据库；首次绑定后，密钥文件丢失、被替换或数据库串到另一 Deployment 都在监听 端口开放前拒绝启动，不自动生成新权威，也不把读失败解释成撤销；
• process-wide shutdown 同时驱动 HTTP/ACME 与 QUIC，停止接收后有界 drain session； workspace all-feature tests、all-target/all-feature Clippy、format 与 migration up/down/reapply 均通过。

该证据增加 production_control_listener_evidence_available，证明单实例生产进程内的 管理撤销到实时会话收敛。它不证明 Device enrollment/registration、节点生产 Candidate report 上报、平台 ns daemon owner lifecycle、PostgreSQL、跨实例 wake、 active-active/failover、真实网络压力或 99% 60 秒/最长 5 分钟 G9 SLA。因此 G0、G2、 G6、G9 保持原状态。

#5.21 生产 Candidate Report Ingestion 证据

2026-08-10 的共享契约与 NSD 提交把 Node 的 Candidate report 从测试入口接入了生产 QUIC control stream，但证据仍严格限定为已注册 authority、单 NSD 与 SQLite：

• ns-shared-next@ca97c02e1b0fc441838936df1e7614884a615dab 固定 candidate_report_v1 feature、显式 runtime_projection_read_candidate_report_write Credential scope、相关请求/结果与稳定 credential_scope_denied 错误；未协商的新能力不能靠发送新 frame 越权；
• nsd-next@ca5d7de874cc2b2e57fb41c6e52717a3434d6402 只在双方认证协商该 feature 时签发 读写 scope，旧客户端继续获得 projection-read-only Credential；报告处理再次独立检查 feature、scope、session Membership、已注册 Node authority、Node 签名、时间窗与 epoch；
• authenticated stream 由一个 bounded reader 独占读取，并在 projection ACK outstanding 时继续分流 Candidate report；所有同步 session/Candidate/SQLite 调用运行于 blocking pool， success result 只在 report/high-water/projection/outbox 原子事务完成后发送；
• 真实 loopback QUIC 覆盖 source-outside-session、source-not-registered、错误 Node 签名、 applied/unchanged/stale/conflicting epoch、ACK outstanding 时的新报告与有序 projection ACK； 生产 nsd listener 测试使用 SQLite 验证 report head、projection outbox 和 ACK 持久化；
• NSD workspace 的 all-target/all-feature Clippy、all-feature tests、doctests 与 format 通过。

该证据只增加 production_candidate_report_ingestion_evidence_available。它不证明 Device enrollment/source registration API、平台 ns daemon 的候选采集与发送生命周期、 真实接口/NAT、PostgreSQL、跨实例 wake/ownership、active-active/failover 或 G2/G6/G9 SLA。 因此相应 Gate 继续阻塞。

#5.22 生产 Candidate Report 客户端发送证据

2026-08-10 的 Shared、NSD、NSGW 依赖对齐与 ns 提交把 §5.21 的生产接收端 接到了运行时客户端发送边界，但输入仍是已构造并签名的报告，不是平台实时采集结果：

• ns-next@ce5ba1d1 固定 ns-shared-next@ca97c02e、 nsd-next@ca5d7de8 与 nsgw-next@f8436930，避免跨仓测试同时解析两份同名但 revision 不同的控制契约；
• CandidateReportPublisher 在报告进入网络循环前验证 Node 签名、有效期、精确 source Membership 和单调 report epoch。同 epoch 同签名字节幂等，回退或同 epoch 冲突在通知与网络发送前拒绝；
• report-aware supervisor 在每条认证连接上只保留一个 frame reader，按 frame kind 分流 projection 与 report result；所有写入由同一 send stream 串行化，projection ACK 与 report request 不会争用读端或各自创建第二条控制连接；
• 每次发送生成非零随机 request ID，结果必须同时匹配 request ID、source Membership 和精确 report epoch。结构化 NSD reject code 决定 terminal/retryable，不能靠错误文本 嗅探；
• 同一连接最多一个 report outstanding。期间产生的新报告保留为 latest，当前结果完成后 再发送；断线不会推进 accepted 状态，重连以新 request ID 重发 latest，由 NSD 的 Unchanged 结果完成幂等收敛；
• 真实 loopback QUIC 测试在首条连接上并发完成 report、projection、projection ACK 和 Applied result，随后强制断线并证明同一 signed report 以新 request ID 重发且得到 Unchanged。另一条真实 QUIC 测试证明 SourceNotRegistered 为 terminal，不进入 reconnect loop；
• ns-next workspace all-target/all-feature Clippy、all-feature tests 与 doctests 通过。 macOS 深层临时目录会使旧 nsc 一条 Unix socket 测试超过 SUN_LEN，完整测试使用 TMPDIR=/tmp/nsio-test 通过，未忽略测试或降低断言。

该证据只增加 production_candidate_report_client_evidence_available。它没有实现或 证明平台接口枚举、同一 WireGuard socket 的 server-reflexive/STUN 观测、NAT 分类、 接口变化去抖、持久 report epoch 分配、Node key 安全存储/daemon owner lifecycle、真实 Device enrollment、PostgreSQL/HA 或 G2/G6/G9 SLA。因此这些 Gate 继续阻塞。

#5.23 Candidate Report 持久构造核心证据

2026-08-10 的 ns-next@00450c6b 把显式平台观察结果接到了 §5.22 的生产 CandidateReportPublisher，并闭合了此前单独阻塞的持久 report epoch 与报告构造核心：

• CandidateReportEpochStore 使用现有跨平台私有原子文件原语保存独立的版本化、带 domain-separated SHA-256 校验的高水位。进程内 clone 共享互斥分配器，调用方必须持有 daemon state directory 的单实例租约；
• 每个 epoch 必须先完成持久写入，之后才允许构造或签名报告。崩溃或无效观察可以留下 跳号，但不能复用已经保留的 epoch；写入失败不推进内存水位，也不进入 publisher；
• collector 用已注册 Node identity 签发短期 discovery key certificate，再用同一 Node identity 签完整 EndpointCandidateReport。交给网络发送边界前，精确 signed artifact 必须通过 ns-shared-next 的身份、时间、TTL、重复、数量和签名校验；
• 七个聚焦测试覆盖重启单调性、并发 clone 分配、损坏/篡改拒绝、持久写失败恢复、无效 snapshot 消耗 epoch 但不发布、共享 duplicate/count 拒绝，以及 Node/discovery 身份绑定；
• ns-next 的 locked workspace format、check、all-target/all-feature Clippy、all-feature tests 与 doctests 全部通过。旧 nsc 的 macOS socket 长度测试使用短 TMPDIR 运行， 没有忽略测试或降低断言。

本地校验和只识别损坏或篡改，不声称能识别一份格式正确、校验合法的旧备份。该类回滚 仍由 NSD 持久 report epoch 高水位拒绝。本证据只增加 candidate_report_collection_core_evidence_available；它没有证明平台接口枚举、同一 WireGuard socket 的 reflexive/STUN 观测、NAT 分类、接口变化去抖、移动端网络回调、 Node key 安全存储与 daemon owner lifecycle、真实 Device enrollment、PostgreSQL/HA 或 G2/G6/G9 SLA。因此这些 Gate 继续阻塞。

#5.24 Unix Host Candidate 观察证据

2026-08-10 的 ns-next@407ce226 在 §5.23 的显式观察输入前增加了 Next-only Unix Host/LAN Candidate source：

• 生产 source 使用安全的 nix::getifaddrs，只形成 UP、非 loopback 的 IPv4 接口事实； collector 进一步拒绝 unspecified、multicast、broadcast 和 link-local 地址；
• 真实 WireGuard UDP listener port 必须由 socket owner 显式传入且非零；collector 不猜 端口、不创建第二个 socket。调用方必须传入 runtime-owned TUN/WG interface exclusion；
• interface name 只参与本地 keyed digest，不进入 Candidate 或 canonical CBOR。每次 collector 启动生成新随机 seed，因此 path/Candidate ID 不跨重启稳定；同一进程内未变化的接口事实 保持 ID，地址变化只轮换 Candidate ID；
• 同一 socket address 去重，并在分配线上 ID 前按本地接口/IP 顺序确定性截断到 Shared v1 的 16 条上限。没有合格地址返回 NoEligibleCandidate，不伪造空报告；
• 七个测试覆盖过滤与排除、ID 稳定/隐私、地址变化、去重/上限、空/非法端口分型、原生 Unix getifaddrs 烟测，以及 Host snapshot → durable epoch → Node/discovery 签名 → Shared 验证 → production publisher 的完整本地链；
• locked workspace format/check、all-target/all-feature Clippy、all-feature tests 与 doctests 全绿；ns 77 个单测、冻结的旧 nsc 1183 个单测均通过。

该证据只增加 unix_host_candidate_observation_evidence_available。它没有实现或证明 Windows/IP Helper、IPv6-global Candidate、同一 WireGuard socket 的 reflexive/STUN、NAT 分类、接口变化 debounce、移动端回调、daemon 自动触发与 identity lifecycle、真实 Device enrollment、PostgreSQL/HA 或 G2/G6/G9 SLA。因此这些 Gate 继续阻塞。

#5.25 Host/Reflexive Candidate 持续刷新证据

2026-08-10 的 ns-next@4df7b86f 把 §5.23/§5.24 的持久报告构造、Unix Host 观察和同 socket Reflexive 观察收敛为一个长运行生命周期：

• 单一 coordinator 持有最近仍有效的 Host snapshot，合并当前有效的 Reflexive Candidate，并通过既有持久 epoch allocator 发布完整 Node-signed report；完全相同的 callback 不消耗 epoch，周期续期仍会在 60 秒生命周期内产生新报告；
• Host 读取失败时保留仍有效的 last-known-good；失效后不把读取失败推断成空报告。 Reflexive 失败或过期只移除 Reflexive Candidate，不清除 Host，也不终止控制会话；
• 生产 control supervisor 默认每 30 秒刷新同 socket 观察，并在 bootstrap 到期前 45 秒 请求替换。定时器与显式 network-change signal 共用一个串行入口；bootstrap 或观察请求 任一时刻最多一份在途；
• 认证 QUIC 互操作使用生产 NSD issuer/SQLite report store、生产 NSGW canonical responder 和生产 ns collector。Host 报告为 epoch 1，第一次 Reflexive 地址为 epoch 2，网络变化 后的新 Reflexive 地址为 epoch 3；NSD 持久 report head 最终精确推进到 epoch 3；
• 反向路径证明临时 reflector 不可用会继续有界重试，但不会杀掉 Host 报告、认证控制 会话或伪造第二个 UDP socket；独立的真实 UDP 测试继续证明 Reflexive 地址来自实际 carrier socket；
• ns-next 的 locked format、完整 workspace all-feature tests/doctests 和 all-target/ all-feature clippy -D warnings 全绿。macOS 旧 nsc socket 测试使用短 TMPDIR=/tmp/t 避免测试路径超过 SUN_LEN，没有忽略测试或降低断言。

该证据增加 continuous_candidate_lifecycle_evidence_available。它没有证明平台原生 network-change adapter、Windows IP Helper、移动端后台/切网、多反射器 mapping behavior、 真实 NAT/CGNAT/filtering/UDP 封锁、kernel WireGuard 等价执行、生产 daemon 启动接线、真实 Device enrollment、PostgreSQL/HA 或 G2/G6/G9 SLA。因此这些 Gate 继续 阻塞。

#5.26 多反射器 UDP 映射观察证据

2026-08-10 的 ns-shared-next@1aa0b30、nsd-next@a154d19、 nsgw-next@e4c9cb5 与 ns-next@b7e90816 把单反射器观察扩展为有界多反射器闭环：

• Shared 请求显式携带一至四的期望数量，响应携带非空、有界、reflector ID/endpoint 唯一的 bootstrap set；旧客户端式的隐式单值不进入 Next 契约；
• NSD 从管理员配置的 reflector pool 选择集合，为每个目标分别生成 session、credential、 revoke key 和响应公钥绑定。生产配置以一个 JSON pool 表达，不把多个环境变量拼成第二套 权威；
• ns 同时维护 per-reflector active/pending/admitted 状态并从同一 WireGuard socket 发包。 某个 reflector 的失败、坏签名或错误来源不消费其他合法在途请求，也不清 Host/Candidate；
• path ID 改由本地 network generation 生成。credential/bootstrap 续租保持 path ID，显式 network-change 才推进 generation、清除旧分类证据并拒绝晚到响应；
• 分类只产生 endpoint_independent、endpoint_dependent、unknown。两个 reflector ID 还必须落在两个目标 IP；同一 IP 的两个端口、部分响应、过期或混代证据均为 unknown；
• 认证 QUIC 互操作使用生产 NSD issuer、两个 NSGW canonical responder、生产 ns supervisor/collector 和 NSD persistent report head，证明两份独立 credential、两条不同 Reflexive Candidate 和网络变化后的新完整报告；
• 为保证 macOS 可复现，互操作中的两个 listener 使用同一 loopback IP 的不同端口，因此它 只证明多凭据/多 Candidate/report 链路，不冒充“公网 IP 独立”。不同目标 IP 的分类由 deterministic contract/runtime tests 证明；生产部署地域与公网 IP 独立性仍未验证；
• 四个相关仓库的锁定测试与严格 Clippy 通过；ns-next 完整 workspace all-feature tests、 doctests 和 all-target/all-feature clippy -D warnings 全绿。

该证据增加 multi_reflector_mapping_evidence_available，并关闭“客户端只能观察一个 server-reflexive endpoint”的实现缺口。它不证明 full-cone/restricted-cone/ port-restricted/symmetric NAT 等 filtering 类型，也不证明真实家用 NAT、CGNAT、双端 endpoint-dependent mapping、UDP firewall、生产 reflector 部署、direct probe 成功率或 Relay 触发 SLA。G2、G6、G9 继续阻塞。

#6. L4 Service 与 Route 总账

#7. Gateway 与 Edge 总账

#8. Client、运营和商业总账

#9. 每个团队的交付证明

#Shared

为 ledger 中每个 typed ID、command、event、credential 和 error 提供真实类型、schema、golden fixture、未知字段/major、跨 scope replay 和签名反测。

#NSD

为每个权威命令提供事务、Admin/Policy/Entitlement 判定、revision/impact、audit/outbox、projection job、撤销 reverse index 和 read/evaluation failure 测试。

#ns

为每个 projection 提供 last-known-good、journal、原子 apply、平台复验、双端 enforcement、流协议、owner binding、结构化状态和故障恢复。

#Client

每个命令只消费结构化对象/operation/error；表驱动穷尽 pending/denied/unavailable/read_failed/incompatible/revoked，并为用户提供取消、重试、明确安全降级或联系管理员动作。

#NSGW

按 capability/tenant 隔离 lease/config/session/secret/metering；本地验签和最终 scope/resource 判定；按应用/策略/Binding/身份/凭据撤销在途流。

#QA

每个 ledger row 至少有正常、deny、read failure、revoke、control outage、component restart、version mismatch 七类证据。涉及系统网络、NAT、移动后台、外部 VPN、长连接和卸载的能力必须有真机。

#10. 变更规则

新增功能必须先在能力目录定义产品边界，再在本总账增加一行并链接权威 API/协议。缺少任一链接时状态保持 incomplete，不能靠实现 PR 补充未评审语义。删除或改变既有安全语义必须形成版本化架构决议，并同步 Shared schema、producer/consumer fixtures、Client 状态和 Gate 证据。