微信工作搭子

说话人、时间、引用关系、附件与特殊消息类型是否与微信中一致，覆盖缺口能否被发现。

真实账号回归：38 条私聊与 150 条群聊全部渲染，12 种 appmsg 编号与 6 种本地消息类型逐一按真实载荷核对；发现并标出 message_4.db 无密钥导致的约 25 小时缺口；附件按字节数确认到重名文件中的正确一份。2026-11-09 同一缺口：搜索索引的行与正常读到的原文逐条一致（14 条）；群聊消息库读到 18 条、索引补回其后 21 条，按编号断档标出 4 条非文字消息，边界重复的一条已去重；inbox 中 49 个读不到最新一条的私聊有 25 个由索引判断。2026-11-10 核对 appmsg 74：索引里标 74 的 5,353 行标题全是文件名，落在可解密分库的 5,325 行有 5,302 行在消息库已是 6（同一行被原地改写），据此把索引来的 74 认作文件。同日核对同名多份：一个分库 3,026 条带字节数的文件消息里，865 条在本机有 2 个以上同名文件，其中 737 条候选大小全相同、是同一个文件的多份副本；把它们当作没有字节数来检验，旧逻辑会把这 865 条全报成未下载，现在 737 条直接选中、128 条列出候选。新分库里 40 条文件消息（27 条标 74）现在 37 条定位到本机文件，其余 3 条本机没有。

交付的回复与成果是否可以直接使用，是否把需要用户拍板的点讲清楚。

真实案例：从客户私聊与 3 页提问清单整理出已谈定条件、3 项待办、6 个问题的分诊表和两版可复制回复，未依据的判断全部标为待确认。

从说出对象到拿到可读上下文所需的时间与调用次数。

约 7 GB、2,400 张消息表的账号：resolve 约 1 秒，context 约 15–20 秒，inbox 约 10 秒，doctor 约 5 秒；新分库缺密钥时 context 与 inbox 各多一次搜索索引查询（复制约 1 GB 隔离副本）。

是否只读、不发送、不泄露账号与路径、不替用户承诺。

脚本只经 lov-wdb-cli 隔离副本读取；测试断言 transcript 不含 wxid；上下文目录权限 0700、文件 0600；clean 拒绝删除不带标记的目录。