the happy path hides the hardest input

The tone translator exists to type Japanese. It shipped with a composer that submitted on Enter — and broke for exactly the people it was built for. When you type Japanese with an IME, you press Enter to confirm a kanji candidate (かんじ → 漢字). That Enter reached the submit handler like any other keystroke, so it sent the half-typed message instead of committing the conversion. A repo-wide search turned up zero composition handling anywhere.

It reached production because every path I naturally tested is the one path that never trips it. I type the UI in English. When I did test Japanese, I confirmed candidates with the mouse. The happy path and the hardest real input were disjoint — and the users I built the tool for, the ones typing CJK, were precisely the ones the naive handler failed.

The fix is one line of standard knowledge I simply didn’t have: bail out of the handler while isComposing is true (plus a keyCode === 229 check for Safari, which fires the confirming Enter just after composition ends). It generalises past Japanese to any composed input — Chinese, Korean, accent entry, dictation. And the wider rule is to distrust the happy path in proportion to how central the hard case is. When the thing that’s hard for your users is the whole reason the product exists, “it works when I try it” is the least reassuring sentence there is — because you aren’t trying it the way they will.