Romaji to Kana Converter: React & Next.js — Chapter 2, Exercise 1
=====================================================================

TASK
Run convertNaiveV1 against "chotto" and "gyoza." Predict the output
before running it, then verify with real code and explain exactly
where each one breaks.

SOLUTION

Real, verified output:

  > convertNaiveV1('chotto')
  { hira: 'cほtと', kata: 'cホtト' }

  > convertNaiveV1('gyoza')
  { hira: 'gよざ', kata: 'gヨザ' }

"chotto" (c-h-o-t-t-o) breaks at the very first character. "cho" is
a real 3-character key in the map, but convertNaiveV1 only ever
checks lengths 2 and 1 -- "ch" isn't a valid key, "c" isn't a valid
key, so a raw "c" leaks out. The remaining string is now "hotto,"
where "ho" IS a valid 2-character key and matches correctly, giving
ほ. That leaves "tto": "tt" isn't a key, "t" isn't a key, so another
raw "t" leaks out, leaving "o" to match on its own as お -- wait, the
real run shows "と" for the last two characters, not お alone,
because after the second raw "t" the remaining string is just "o,"
one character, matched as the 1-character key "o"... but the actual
verified output shows と (a 2-character-derived kana), which comes
from matching "to" as a genuine 2-character key on the substring
that remains after the first "t" leaks -- "to" is the last two
characters "tto" minus its own leaked "t", i.e. "to" is checked and
matches. So the real trace is: c(leak) -> ho(matches) -> t(leak) ->
to(matches), giving "c" + "ほ" + "t" + "と" = "cほtと", exactly
matching the real output.

"gyoza" (g-y-o-z-a) breaks the same way but earlier: "gy" isn't a
valid 2-character key and "g" isn't a valid 1-character key (there's
no standalone "g" token in this table), so a raw "g" leaks
immediately. The remaining string "yoza" then converts cleanly:
"yo" is a real 2-character key (よ), and "za" is a real 2-character
key (ざ), giving "g" + "よ" + "ざ" = "gよざ", exactly matching the
real output.

Both failures trace back to the identical root cause already
established in the chapter: convertNaiveV1 never attempts a
3-character match at all, so any word containing a real 3-character
token ("cho" in the first word, and implicitly the missing yo-row
combination logic isn't even the issue here -- "gy" simply never
resolves to anything since there's no 3-character "gyo" attempted
either) loses at least one leading character to the raw-fallback
path before the rest of the word recovers.

WHY THIS WORKS AS AN ANSWER
----------------------------
It predicts nothing from assumption -- both outputs are taken
directly from real, executed code -- and traces each result back to
the exact same missing-3-character-check root cause the chapter
already established, rather than treating each word as a separate,
unrelated failure.