讨论：autoSync 的同步语义（每连接一次 vs 持续收敛）与 pushOnWrite 单向性

[Windsander]

讨论：autoSync 的同步语义（每连接一次 vs 持续收敛）与 pushOnWrite 单向性

背景

G0–G6 与 namespace 工作合并后，多节点路径（WAN 两阶段、MCP 跨机、示例）都能收敛，
但「自动同步到底在什么时候发生」在实现与直觉之间有偏差。本地做独立验证时发现这一语义
盲点，想先对齐设计意图，再决定要不要改。

现状（代码事实）

1. autoSync 仅在握手 authenticated 事件触发一次：发起方（deviceId 字典序较小）
   执行一次双向 syncWithDevice，响应方执行一次 acceptSync；之后无周期任务。
   —— src/sync/syncmgr/SyncManager.ts:807-836（attachToNode）
2. 本地写入进入 pending（按 per-(对端, 分区, 作者) 水位计算缺失集），
   默认不会主动发送：要等下一次会话（重连 / 手动 syncWithDevice / 对端发起 MCP memory_sync）。
   —— hasPendingEvents/getPendingEvents，SyncManager.ts:555-566
3. pushOnWrite 默认关闭；开启后也只有发起方角色会推送本地写入
   —— SyncManager.ts:303（默认）、:311-321（仅 entry.initiate 调度推送）
4. 授权裁剪（默认拒绝 ∩ 订阅声明）与 ack/水位推进不受影响；数据不会丢：
   pending + 水位保证下次会话补发，离线队列/重连有测试覆盖。

观察到的影响

• 两端长期保持连接时（例如两台常驻 mebular serve、或一个长在线的桌面端），
  一方写入后另一方看不到，memory_status.pendingEventCount 会一直增长，直到下一次同步触发。
• 即使开启 pushOnWrite，实时性仍是单向的：deviceId 较大的一方写入不会主动推送。
• 当前正式流程均有触发点（MCP 显式 memory_sync、WAN 两阶段重启、示例先写后连），
  因此不是正确性缺陷；但使用者可能误以为「连接=持续同步」。

待讨论的问题

1. 语义定义：autoSync 想要的是「连接时收敛一次」还是「连接期间持续收敛」？
   文档与产品预期应以哪个为准？
2. pushOnWrite 是否应双向？若双向，如何控制写风暴与并发会话（已有 50ms 节流合并、
   单会话语义、授权裁剪兜底）？
3. 是否需要周期性 anti-entropy（可配间隔 + jitter + 背压）？在移动端电量/流量、
   WAN relay 成本、长连接规模之间如何取舍？
4. 常驻形态（mebular serve）是否应默认开启 pushOnWrite 或周期同步？还是坚持显式触发？
5. README「快速上手」是否应补充一节「同步触发时机」，避免「连接=实时」的误解？

备选方案（供讨论，非结论）

方案	改动面	优点	代价/风险
A. 仅文档澄清	README	零风险	不解决常驻场景的实时性预期
B. pushOnWrite 双向	SyncManager 推送调度	连接期间双向近实时	需处理响应方订阅状态与风暴控制
C. 周期 anti-entropy	SyncManager 定时器	最终收敛有上界	电量/流量/relay 成本，需要间隔与 jitter 策略
D. MCP 层默认周期同步/开 pushOnWrite	packages/mcp 配置	常驻接入层体验好	与 core 语义解耦，需评估跨机默认行为
E. 保持现状 + 显式触发	—	与离线优先、低开销一致	需要文档与 SDK 引导

相关证据

• 本地独立验证报告：docs.design/local-verify-namespace-2026-09-16.md（本地，含 F4 重连缺陷与 F5 本议题）
• 示例需「先写后连」：examples/two-devices/、examples/namespace/
• 相关实现与测试：tests/sync/push-on-write.test.ts、tests/sync/sync-state-persistence.test.ts
• 相关决策：PR Namespaces, default-deny selective sync, and per-namespace sync watermarks #27（feat/namespace-selective-sync）引入的 push-on-write 节流与授权裁剪

期望的讨论产出

• 对 Q1 的明确语义定义（用于 README/规格）；
• 对方案 A–E 的取舍意见与优先级；
• 若选 B/C/D，愿承担的改动范围与验证方式（E1 证据形式）。

[Windsander]

记忆层 v1.1：实时同步 + 一致性口径按域

本轮把同步从「连接时收敛一次」推进到「持续收敛」：① 双向 push——响应方通过无载荷 sync-nudge 请发起方立即起一轮，双向都亚秒级；以每连接单一消费者（PeerFrames）路由帧，会话中忽略 nudge、50ms 节流、per-peer 在途上限 1，仅对已授权且已订阅且有 pending 的对端发送。② 周期 anti-entropy——每 5–15 分钟（±20% jitter）对确有 pending 的对端兜底，无 pending 短路、失败退避；core 默认关，常驻（serve/MCP）默认开。③ 一致性口径按域——新增 stateHashByNamespace，跨端自检只比共同授权域，跨域不再误报。

口径：连接 ≠ 持续同步；实时性依赖常驻进程；授权域内必然全局收敛；policy 对所有已认证设备可读是为 bootstrap 与恢复的取舍；吊销是域收缩（不回撤已入图数据）。未做：订阅=成员资格、继任者交接、多应用协议、快照完整冲突合并、准入层吊销、会话多路复用（亚秒够用，留待升级触发条件）