我们已经学会怀疑读取对象，也学会留意消息的年龄。还有一种可能：对象和版本都正确，响应里的数字也是 1，页面却画出了 0。
此时继续刷新，可能只是反复把正确数据交给同一段错误规则。
本实验的统计约定很简单：统计所选范围内已经完成的任务项数。每组只有一个任务；它完成时计 1，未完成时计 0，没有另行声明的扣减规则。
在真实系统里，两个统计也可能采用不同定义。先取得明确约定，才有资格判断实现是否符合它。不能仅凭自己希望看到 1，就宣布 0 是错误。
登记预测，再点击“记录响应与当前显示”。观察 request_id、scope、version、响应 completed，以及从当前页面读取的 displayed。
记录的是这一刻你选择查看的响应与画面。如果此前已经刷新、改范围或放行旧请求，先在卡片里说明这些操作，不能把它们当作最初的那一幕。
当 received 和 displayed 不同，你有理由调查显示转换。但仍需检查版本与对象，避免把两次不同读取的数字放到一起比较。
勾选“按响应原值显示”，点击“只重新显示当前响应”。先预测：如果问题在显示转换，什么会改变？如果问题在旧响应，是否仍然会保留旧数值？
这是一次有辨别力的操作，因为它沿用当前响应，不把新的网络读取同时混进来。时间线中的浏览器记录会标记这次是 render-again-without-read。
若重新显示修好了数字，并且当前响应值与约定一致，这支持了显示规则的问题。若没有修好，并不代表实验失败；你可能需要回对象线或时间线寻找尚未解决的条件。
实验台可以打开 displayedCount 与 renderSummary 的相关代码。关注两个位置：响应字段如何参与计算，计算值如何写到页面。看见函数后，再回到对照实验核对它是否解释了观察。
本实验有一个现场故意漏算一项。源码说明的是这个实验版本，不应把“减一”当成所有界面分歧的答案。真正需要带走的是找到转换边界的方法。
还要留意，按原值显示只是本约定下的对照。若产品本来需要单位换算、聚合或脱敏，直接显示原值未必符合需求。正确性总要与明确的含义一起讨论。
引用一份响应证据和一份浏览器显示证据，说明它们怎样对应；写出对照前后变化，解释是否真的触及了原因。
问其他两条线：这份响应属于哪个对象？它为何会成为当前采用的版本？三路解释一致时，才有理由提出更完整的判断。