触发与范围
桌面聊天保持连接时，inbox 游标属于当前服务进程的内存 broker。服务重新创建 broker 后，seq 从 0 开始；客户端重连仍传旧 appliedSeq，snapshot 只取两者最大值且不处理 0。服务事件循环又按这个旧 after 过滤新 seq，后续侧栏更新可能持续被压住，直到新序列超过旧水位。
按 P2 重连恢复追踪。2026-09-30 的原 hook 和纯 InboxBroker 隔离验证已确认该合同不一致；没有真实重启、SSE/HTTP 请求、桌面 profile、审批或用户数据丢失。本项是 desktop-owned inbox adapter 的游标/连接范围恢复；内存 broker 与服务过滤代码作为最小合同依赖，不要求本轮修改 Web、后端或业务功能。
分层合成证据与保护对照
客户端 fixture 原样运行 useConversationThreads、inbox admission 与 attention helpers，使用内存 apiFetch/EventSource/定时器。较高水位后触发合成断线，原重连 URL 保留旧 after；新的低水位 snapshot 不重置它。向客户端 admission 单独送一个低 seq 合成 probe，该 probe 被判旧，待办不更新。
低 seq probe 是独立客户端逻辑探针，不是实际服务已发送的 frame。 原 handler 源码也会在投递前过滤这些 seq，因此不能从这份 fake EventSource 记录声称真实网络交付或端到端重启事故已复现。
生产端条件由另一 fixture 单独核验：按文件直接加载原纯 InboxBroker，源码只依赖 Python 标准库，未初始化应用/router/manager。旧 broker 形成较高游标，新建 broker 从 0 开始；相同旧 after 的原 events_after 不返回低于或等于旧水位的新事件，超过后才返回。原 handler 的完整 cursor/过滤源码另存为静态合同证据，没有调用该处理器。
保护对照：同一 broker 重连的新 seq 正常接受；fresh hook/after=0 正常接收新 broker 第一条事件；已关闭旧 EventSource 的迟到回调被原 guard 拒绝。完整合成行、broker 输出、hook 列表/回调、原函数与哈希仅存本地 ignored artifact。
根因与影响边界
broker seq/ring 在内存且没有 epoch 标识；客户端将 seq 当作跨服务实例连续的水位。低 snapshot 与旧 resume cursor 没有明确的重置/重取合同，服务和客户端两侧的旧值过滤共同压制新事件。
重连 snapshot 仍可显示当时的完整侧栏，因此问题不是必然白屏。影响是 snapshot 之后的待办、未读和运行状态更新可能缺失；真实持续时间、事件数量与桌面 UI 未测，不能声称消息永久丢失、数据被删除或工具错误执行。主聊天的持久事件序列属于另一合同，不能把 inbox 内存 seq 的结果推广到它。
桌面优化与验收
- 将 inbox 游标绑定到已确认的服务/broker epoch 或等价的重置合同；新实例被确认后，重新建立适用的新游标与去重范围。
- 当前合同若检测到新 snapshot 游标回退，应明确恢复/重取，并确保下一连接不继续传失效 after。保持同实例重复事件和旧连接回调的既有拒绝。
- 同类双层 fixture 中，新 broker 的首条更新可在恢复后生效，无需积累到旧水位；同 broker 重连、重复事件、旧流回调对照继续正确。
- 在可弃置桌面环境另做真实服务重启验收，仅用合成聊天；分别记录 producer、transport 和 consumer，避免把人工 frame 注入当实际网络证据。确认身份的要求继续由原服务认证合同独立执行。
去重与源码
#37、#38、#67 分别处理提示、停止竞争和决定投递；#78 为服务认证入口。本条为进程重建后的序列归属，既不是身份绕过，也不是旧 REST 覆盖新列表的快照 admission 根因。关联 Epic #31。
固定公开源码用于导航；本次原模块与静态合同均保存当前哈希：useConversation、conversationInbox、InboxBroker、conversation API 合同。
触发与范围
桌面聊天保持连接时，inbox 游标属于当前服务进程的内存 broker。服务重新创建 broker 后，seq 从 0 开始；客户端重连仍传旧 appliedSeq，snapshot 只取两者最大值且不处理 0。服务事件循环又按这个旧 after 过滤新 seq，后续侧栏更新可能持续被压住，直到新序列超过旧水位。
按 P2 重连恢复追踪。2026-09-30 的原 hook 和纯 InboxBroker 隔离验证已确认该合同不一致；没有真实重启、SSE/HTTP 请求、桌面 profile、审批或用户数据丢失。本项是 desktop-owned inbox adapter 的游标/连接范围恢复；内存 broker 与服务过滤代码作为最小合同依赖，不要求本轮修改 Web、后端或业务功能。
分层合成证据与保护对照
客户端 fixture 原样运行
useConversationThreads、inbox admission 与 attention helpers，使用内存 apiFetch/EventSource/定时器。较高水位后触发合成断线，原重连 URL 保留旧 after；新的低水位 snapshot 不重置它。向客户端 admission 单独送一个低 seq 合成 probe，该 probe 被判旧，待办不更新。低 seq probe 是独立客户端逻辑探针，不是实际服务已发送的 frame。 原 handler 源码也会在投递前过滤这些 seq，因此不能从这份 fake EventSource 记录声称真实网络交付或端到端重启事故已复现。
生产端条件由另一 fixture 单独核验：按文件直接加载原纯
InboxBroker，源码只依赖 Python 标准库，未初始化应用/router/manager。旧 broker 形成较高游标，新建 broker 从 0 开始；相同旧 after 的原 events_after 不返回低于或等于旧水位的新事件，超过后才返回。原 handler 的完整 cursor/过滤源码另存为静态合同证据，没有调用该处理器。保护对照：同一 broker 重连的新 seq 正常接受；fresh hook/after=0 正常接收新 broker 第一条事件；已关闭旧 EventSource 的迟到回调被原 guard 拒绝。完整合成行、broker 输出、hook 列表/回调、原函数与哈希仅存本地 ignored artifact。
根因与影响边界
broker seq/ring 在内存且没有 epoch 标识；客户端将 seq 当作跨服务实例连续的水位。低 snapshot 与旧 resume cursor 没有明确的重置/重取合同，服务和客户端两侧的旧值过滤共同压制新事件。
重连 snapshot 仍可显示当时的完整侧栏，因此问题不是必然白屏。影响是 snapshot 之后的待办、未读和运行状态更新可能缺失；真实持续时间、事件数量与桌面 UI 未测，不能声称消息永久丢失、数据被删除或工具错误执行。主聊天的持久事件序列属于另一合同，不能把 inbox 内存 seq 的结果推广到它。
桌面优化与验收
去重与源码
#37、#38、#67 分别处理提示、停止竞争和决定投递；#78 为服务认证入口。本条为进程重建后的序列归属，既不是身份绕过，也不是旧 REST 覆盖新列表的快照 admission 根因。关联 Epic #31。
固定公开源码用于导航；本次原模块与静态合同均保存当前哈希：useConversation、conversationInbox、InboxBroker、conversation API 合同。