结论与 Q1–Q7

• Q1 Native 是否完整准确采集确认流量？——观察到问题 / 部分成立。 有效 ON run 中 writer 1032/1032、无 drop、无序号缺口；但修复前 boundary 顺序造成 201 条 Native transition 只有 195 条 Shadow-confirmed。修复已完成并通过局部测试，尚未在设备端复验。
• Q2 Follow 与 Replay 是否一致？——已验证成立（完整文件）。 同一有效 ON 事件文件的 Replay 与分块 Follow 两张 Snapshot 核心字段完全一致；真实在线 Follow 只完成了一个提前失败 run，终态证据不足。
• Q3 Shadow 是否影响动作选择/吞吐？——未发现已确认副作用，性能仅 Smoke 观测。 固定 trace 9/9 一致；OFF/ON 吞吐约 0.628/0.621 exec/s，不能做统计归因。
• Q4 Infomap 是否跟得上？——计算本身及时，周期证据不足。 单次计算约 8.8–34.5ms，低于动作间隔；但真实 run 只有 195 条确认执行，未达到 250 周期，不能声称已完成两个基线周期。
• Q5 社区是否出现可追溯变化？——观察到快照结构变化，lineage 证据不足。 100 条 checkpoint 为 4 社区、终态为 10 社区，事件截止边界正确；仅两张快照没有可认证 lineage 事件。
• Q6 Ⅰ类入口哪些在线成立？——当前没有在线成立的语义入口。 入口字段可记录，ODK Download 事实若出现保持 UNKNOWN/UNVERIFIED；Oracle 标签只作事后展示，未注入在线判断。
• Q7 是否满足下一阶段多 App 被动 Shadow？——证据不足，暂不满足。 OFF/ON、Native 对账、Replay/离线 Follow 已有有效证据；但修复后的退休 State NPE 尚未设备端复验，真实在线 Follow run 曾失败且设备锁保留，250 周期和 lineage 也未完成。下一阶段最小建议是先通过调度中心的合法锁回收完成一条修复后 ODK ON run，要求无 executor 异常、Shadow status 无 fail、Native/Shadow/Replay 三方对账后再扩展第二个 App；不开发 SUPPRESS。