两个面板都提到了“读一段讲义”。它们紧挨着，又长得很像，我们很容易默认右边正在统计左边。
这个默认值得先检查。否则，我们可能仔细分析一段时间顺序，最后才发现两边根本没有在回答同一个问题。
文件可以同名，任务可以同名，两个项目也可以各有一条“读一段讲义”。显示给人的标题，经常承担方便阅读的职责；系统识别对象时可能使用另一个编号，并把它放在某个范围里。
因此，先提出两个解释：H1，两边确实读同一组任务，只是其中一边较旧；H2，两边读不同范围，表面的相同标题让我们误认了对象。
先预测：如果 H2 成立，仅刷新右边而不改变查询范围，会使它和左边对上吗？
在实验台对象线登记预测，再点击“核对起始现场的对象”。记录两边的 scope、task_ids 和对应 S 证据编号。
不要只记“main”和“archive”两个单词。它们在本实验中代表两组独立任务；重要的是查询是否指向同一组、同一编号，以及这是否符合当前用途。
如果 scope 或 task_ids 不同，先别直接比较 v1、v2 的大小。两个独立对象各有自己的版本计数，“一边 2、一边 1”本身还不能证明同一份数据变旧。
保持任务状态和显示规则不变，选择右侧下一次查询的范围，再发起一次读取。先写预测，再观察。
若调整范围后数字对上，证据支持“查询对象影响了分歧”。再结合起始快照里的编号，才能判断原先是否接错了对象。
若范围本来就一致，或者调整后仍不一致，这条线也有价值：它可以排除一类解释，把问题交给时间线或显示线。调查的结果不一定是找到罪魁，也可以是缩小范围。
每次读取都会产生新证据。卡片中分清你解释的是起始现场，还是修正操作之后的状态，别用后来的结果冒充原始画面。
给时间线：“你比较的两个版本，确认属于同一个 scope 和任务了吗？”
给显示线：“响应里的 completed 正在统计哪组任务？它和你眼前以为的统计对象一致吗？”
这正是分支汇合的意义。各条线能独立取证，但结论需要互相约束。
你的证据卡应写出：初始对象是否一致、哪条记录支持它、改变范围后发生了什么，以及这还不能解释什么。
例如，“两边范围一致”不能进一步推出“版本相同”或“渲染正确”。如果使用真实业务系统，身份还可能包含租户、账号、筛选条件或日期范围，本实验并未覆盖全部情况。