一次同步账本静默失败，报告了 763 项资产，而实际有效的资产仅约 400 项。通过检查平台 UI 和 API 进行人工验证，发现了这一差异。账本的不准确源于三种不同的故障模式。“幽灵”指已从平台删除但仍存在于数据库中的资产，涉及至少 173 行记录。“遗漏”指存在于平台但从未被记录到数据库中的资产，总计至少 63 行。“误报”指平台默认项被错误计为用户资产，贡献了至少 109 行记录。这三种模式部分相互抵消，使得总计数成为一个具有误导性的指标。具体错误示例包括：平台技能列表因页面大小限制错误报告了 100 项，而用户实际仅有 4 项技能；另一例是将设置页的占位符文本存储为用户记忆，同时遗漏了真实的记忆；此外，还有 42 条指令行指向机器上不存在的本地目录。关键教训是：成功的同步报告并不能保证数据的准确性。分页问题导致资产缺失，因为列表调用过早终止；看似合理的数字助长了麻痹心态。提出的解决方案并非改进收集器，而是在每次同步后强制执行回读审计。该过程涉及重新读取平台并执行双向 ID 差异比对。必须显式识别并处理平台提供的默认项。这种按调度运行的主动验证对于防止账本数据衰减至关重要。作者正在开发一个名为 untactit 的控制平面，其中回读验证是一项核心产品经验。