chore(工作区): 纳入版本控制基线（回收 411 MB 过程产物）

回收 411 MB（470 M → 58.8 M），全部经回收站，可恢复：
- 待清理/（146.2 M，含 relay 分片 128 M 与 42 项过程目录）
- tmp/（32.4 M，按接续棒命名的过程临时区）
- .workbuddy/tmp/（39.5 M）
- 4 份 workbuddy.db 冗余副本（101 M，09-23 事故的坏副本 / 抢救产物）
- tmp/im16/gw/centrifugo 二进制（63.9 M，可重下）+ 缓存残留

入库范围：常驻规则（CODEBUDDY.md / README.md / state.py）、在途接续入口与
接续包、docs/、交付物/、交接单/、归档/、scripts/、.codebuddy/、
.workbuddy/memory/；共 398 件，其中 >60 KB 的 26 件全为文档。

排除（.gitignore）：tmp/、待清理/、运行态日志与缓存、*.db 与 DB 备份整目录、
打包二进制（*.tar.gz / *.tgz）、记忆修复前备份。

docs/覆盖网络/覆盖网络_补遗与参考方案_20260916.md

@@ -0,0 +1,165 @@
+# 覆盖网络 · 补遗与参考方案（含「互联游戏」可行性）
+
+> 日期：2026-09-16 ｜ 性质：**补遗复盘**（承接 `覆盖网络_全球架构复盘_20260916.md` 与 `覆盖网络_答疑_群聊备份迁移保密_20260916.md`）
+> 🟢 范围：只考虑技术实现；跨境数据合规由使用者自行考虑。
+
+---
+
+## 一、互联游戏：✅ 支持，但**由游戏形态决定**
+
+覆盖网络对游戏是"够用"的底座，**但它是所有应用场景里最"重"的一个** —— 实时性、状态一致性、反作弊三条同时压上来。所以先分类：
+
+| 游戏类型 | 覆盖网络可行性 | 关键约束 |
+|---|---|---|
+| 回合制 / 卡牌 / 桌游 / 异步 | ✅ **非常合适** | 带宽极小（只传输入），延迟不敏感 |
+| 小规模实时合作（≤8–16 人） | ✅ 合适 | 需要主机或专用服务端之一 |
+| 大厅在服务器 + 对局 P2P | ✅ 经典架构 | 匹配/排行在中心，对局在 P2P |
+| 大规模强实时竞技（FPS/MOBA 64+） | ❌ **不合适** | 需专用服务端 + 权威模拟；中继多一跳；P2P 无法反作弊 |
+| 需要严格反作弊的竞技类 | ❌ **P2P 的致命伤** | **客户端持有权威状态 = 可作弊**，必须服务端权威 |
+
+### 1.1 三种同步模型（带宽与延迟特性完全不同）
+
+| 模型 | 传什么 | 带宽 | 适合 |
+|---|---|---|---|
+| **状态同步** | 定期广播状态快照 + 客户端插值 | 高（随人数上升） | 动作类、小规模 |
+| **锁步 / 帧同步** | **只传输入（命令）** | **极低** | RTS、回合、卡牌 —— **对覆盖网络最友好** |
+| **回滚码（GGPO 式）** | 输入 + 确定性模拟 + 预测回滚 | 低但要求严格 | 格斗类；**对延迟最敏感，跨洲不可行** |
+
+⇒ **给覆盖网络的第一建议：优先做"只传输入"的锁步/回合制**，带宽可忽略、延迟容忍度高；实时动作类必须限定在同区域。
+
+### 1.2 延迟预算（决定哪些能玩）
+
+| 路径 | 典型 RTT | 可承载 |
+|---|---|---|
+| 同区域直连 | 5–30 ms | 几乎任何类型 |
+| **经中继（多一跳）** | +RTT×2 | 回合/锁步仍可；动作类吃力 |
+| 跨洲 | ~200 ms | **只适合回合制/异步** |
+
+### 1.3 游戏特有的风暴点（比聊天更危险）
+
+1. **状态广播放大**：每帧每人发给全体 = O(N²) ⇒ 必须**主机聚合后再分发**，或按**兴趣区域（AOI）裁剪**。
+   > 📄 **重点修正（2026-09-16 10:0x）**：用户明确游戏重点是 **MMORPG（2D/2.5D）· MUD · 传奇类** —— 这三类是**覆盖网络最匹配的应用**（天生服务端权威 + tick 驱动 + **AOI 九宫格广播** + 分区/分线扩展，每玩家仅数 KB/s~数十 KB/s，几百 ms 延迟无感）。本节上面那张"❌ 不合适"的表**只适用于 3D 大世界强实时竞技**。游戏专项见 **`覆盖网络_游戏专项_MMORPG与MUD_20260916.md`**。
+   ⭐ 该专稿的核心简化：**这类游戏玩家之间不需要互联**（服务端权威，玩家只与游戏服通信）⇒ 覆盖网络只需解决"**让玩家到达游戏服**"，**中继容量按"服数"算、不按"玩家数"算**。
+2. **输入风暴**：锁步必须限帧率 + 合并输入，不能"每动一下发一条"。
+3. **主机切换惊群**：房主掉线时全员抢当主机 ⇒ **必须确定性继任顺序 + 退避**（不能"谁先喊谁当"）。
+4. **匹配/大厅风暴**：开房高峰的列表刷新 ⇒ 列表走**带 TTL 的拉取**，不做推送。
+
+### 1.4 反作弊（决定架构，不是可选）
+
+**P2P 无法防作弊** ⇒ 只要游戏有竞技性，就必须 **服务端权威**。好消息：覆盖网络里"**有公网 IP 的节点**"天然可当对局主机/专用服务端 —— 与骨干层设计天然衔接。
+
+### 1.5 技术选型与复用点
+
+- 传输：**WebRTC DataChannel 的"不可靠 + 无序"模式**（类 UDP，适合状态流）；或直接用覆盖网络的 UDP 隧道。WebRTC 自带 ICE（打洞）+ TURN（中继）兜底，与我们的中继设计同构。
+- ⭐ **可复用"房间"抽象**：**群聊房间与游戏对局是同一个模型** —— 成员 / 可见性 / 事件分发 / 离线补拉。一旦建了房间层，**群聊、游戏、协作编辑、看板共用一次投资**。这是本方案最划算的一处架构复用。
+
+---
+
+## 二、补遗清单（按主题；凡前面没写到的都在这）
+
+### 2.1 身份与账户（**最容易被漏，且漏了会出运维灾难**）
+
+1. **多设备同账号**：一个用户多台设备如何归属同一身份；设备加入/移除流程。
+2. **密钥丢失的重建路径** ⚠️：私钥丢 = 设备永久失去身份。必须有**恢复机制**（恢复码 / 管理员重签 / 设备转让），且要能撤销被盗设备。
+3. **密钥存放**：用系统密钥库（Windows DPAPI / macOS Keychain / Linux TPM），不要明文落盘。
+4. **账户与设备的绑定粒度**：设备级身份 + 用户级授权（两层），避免"一台设备泄露 = 整个账号沦陷"。
+
+### 2.2 寻址与名字（没有它，用户只能记 IP）
+
+5. **稳定名字解析**（MagicDNS 式）：`<设备>.<用户>.<域名>`；平台已有 `alotbuy.com`，可直接做子域解析。
+6. **IPv6 优先** ⚠️ **重要且常被忽略**：不少网络有 IPv6 直达能力 ⇒ **可跳过打洞直接连**。别只按 IPv4 NAT 设计，否则白丢一大块性能红利。
+
+### 2.3 接入与可见性
+
+7. **出口节点 / 子网路由**：把某台机器背后的**整个局域网**借进覆盖网络（访问家里的 NAS、打印机）—— 对"一个人的多设备"场景是关键能力。
+8. **服务暴露**：把实例或某端口按**网内可见 / 公网可见**两档暴露（对应 Serve / Funnel 的区分）。
+9. **ACL 的具体形态**：粒度（用户 / 设备 / 服务 / 端口 / 时间）、表达方式（策略语言）、下发与缓存、**默认拒绝**。
+
+### 2.4 自检与选路
+
+10. **上线自检**（netcheck 式）：探测 UDP 是否被封、NAT 类型、到各区域中继的时延 ⇒ 再决定选路。
+11. **路径决策可解释**：每次连接"为什么走了中继"要能查出原因（打洞失败？UDP 被封？策略强制？）—— 排障只能靠这个。
+12. **节点健康自评**：打洞率 / 丢包 / 时延 → 主动换路径或换骨干。
+
+### 2.5 流量与公平
+
+13. **按用户/设备配额**（带宽与连接数），防单点占满。
+14. **交互流量优先于后台流量**：备份/同步这类用**低优先级队列**（fq_codel / LEDBAT 类），保证聊天与游戏不被备份堵死。
+15. **多路径**：直连 + 中继同时传，聚合吞吐（大文件迁移用）。
+16. **前向纠错（FEC）**：丢包高的移动网，FEC 比"重传"便宜得多。
+
+### 2.6 移动端与弱网（独立一章，坑最多）
+
+17. **电量**：心跳频率要能与电量/前台状态联动（后台降频）。
+18. **系统休眠/冻结**：唤醒后必须**秒级重连**，不能等下一个心跳周期。
+19. **网络切换**：Wi-Fi ↔ 蜂窝切换会换 IP ⇒ 需**连接迁移**（QUIC 的 connection migration 就是为这个设计的）。
+
+### 2.7 升级、版本与自愈
+
+20. **协议版本协商**：客户端与平台必须能协商协议版本，**严格递增防降级**。
+21. **灰度与回滚**：按节点分批升级，出问题能退回上一版。
+22. **更新包签名校验**（防投毒）。
+
+### 2.8 可观测
+
+23. **集中指标 + 每节点画像**（路径类型 / 打洞率 / 时延 / 重连次数）。
+24. **可 grep 的决策日志**（"为什么走中继"）—— 与 12 配套。
+
+---
+
+## 三、参考方案对照（可直接借鉴的现成物）
+
+| 能力域 | 参考方案 | 借什么 |
+|---|---|---|
+| 组网 / 打洞 / 中继 | **Tailscale / headscale + derper**、NetBird、Nebula、ZeroTier、EasyTier、innernet | 控制面/数据面分离；先中继后直连；限额中继；区域 DERP |
+| 打洞 / 中继库 | **libp2p**（DCUtR + relay v2）、**Pion**（Go WebRTC）、**coturn** | 直接可用的协议实现与默认限流参数 |
+| 游戏网络 | **GGPO / 回滚码**、**Nakama**（开源游戏后端）、Colyseus、Photon、**WebRTC DataChannel** | 房间/匹配/状态同步的现成模型；不可靠传输 |
+| 联机传输库 | enet / KCP / QUIC | 类 UDP 的低延迟可靠传输 |
+| 协作编辑 / CRDT | **Yjs**、Automerge | 无中心也一致的协作模型（适合 P2P 房间） |
+| 群聊 / 联邦房间 | **Matrix**（联邦式房间，理念与覆盖网络最接近）、Nostr、Scuttlebutt | 房间、事件图、离线补拉、联邦 |
+| 备份 | **restic / Borg**（增量 + 去重 + 加密）、**rclone**（多后端 + 加密）、MinIO | **与我们结论一致**：去重 + 客户端加密 + 不可变 |
+| 迁移 | rsync（块级增量）、rclone、对象存储中转 | 断点续传与增量 |
+| 观测 | Prometheus + Grafana（libp2p 有现成面板）、集中日志 | 直接抄面板 |
+| 全球就近 | GeoDNS（PowerDNS / Route53）、anycast、DERP 的区域模型 | 就近接入 |
+
+---
+
+## 四、反模式清单（踩了就出事，逐条对照）
+
+| # | 反模式 | 后果 |
+|---|---|---|
+| 1 | **建全互联**（N² 保活） | 保活与连接数爆炸 |
+| 2 | **无扇出限制的 gossip / 广播** | 泛洪风暴 |
+| 3 | **客户端持有权威状态** | 可作弊、可伪造归属 |
+| 4 | **控制面下发全网名单** | 元数据全暴露 + 每条连接都要维护 |
+| 5 | **单中心中继当唯一通道** | 单点 + 带宽瓶颈 |
+| 6 | **把网内副本当主备份** | 无 SLA、可误删、对端离线即失效 |
+| 7 | **用慢链路做备份/迁移通道** | 22 KB/s 量级 ⇒ 不可用 |
+| 8 | **失败即重试（无退避/抖动）** | 重试风暴 |
+| 9 | **agent 直接触发 agent** | 无限循环消息风暴 |
+| 10 | **推送式分发（版本/目录/大资源）** | 冷启动拉取风暴 |
+| 11 | **共享密钥当节点身份** | 无法吊销、一泄全通 |
+| 12 | **只按 IPv4 NAT 设计** | 白丢 IPv6 直达红利 |
+
+---
+
+## 五、落地优先级（补遗之后，按"依赖"排）
+
+1. **房间层**（一次投资，群聊 + 游戏 + 协作 + 看板共用）。
+2. **身份与密钥**（一机一钥 + 恢复机制 + 吊销）—— 大量能力的共同前置。
+3. **会合 / 中继拆成独立组件**（老结论，仍是第一件实事）。
+4. **IPv6 优先 + 上线自检 + 路径决策日志**（低成本高收益）。
+5. **配额与优先级队列**（交互优先，备份让路）。
+6. 备份改造（去重 + 客户端加密 + 对象存储主层）。
+7. 游戏（锁步/回合制先行，服务端权威留给竞技类）。
+
+---
+
+## 六、未验证项
+
+| # | 项 | 状态 |
+|---|---|---|
+| 1 | 本环境 IPv6 可用度（决定能否吃到"直达"红利） | ⚠️ 未实测 |
+| 2 | 移动端休眠唤醒后的实际重连耗时 | ⚠️ 未实测 |
+| 3 | WebRTC DataChannel 经我们中继的延迟与丢包表现 | ⚠️ 未实测 |
+| 4 | FEC / 多路径的实际收益 | 📋 待评估 |