Romaji to Kana Converter: Astro — Chapter 2, Exercise 2 ===================================================================== TASK Build convertNaiveV1 (the fixed 2-then-1-character tokenizer) exactly as this chapter describes. Run it against "kyaku" and confirm the real "kやく" output, then run it against "kaki" (a word with no 3-character tokens anywhere in it) and confirm it produces the correct result there -- showing the bug specifically depends on a 3-character token being present at that position, not a universal failure. SOLUTION Running the naive tokenizer for real: console.log(convertNaiveV1('kyaku')); // 'kやく' console.log(convertNaiveV1('kaki')); // 'かき' "kyaku" breaks exactly as the chapter describes: position 0 tries "ky" (not a valid token) and "k" (also not valid), falls through to emitting the raw letter "k", then correctly picks up "ya" and "ku". "kaki" (垣, a fence, or one reading of a few other words) never runs into the same problem, because every token it actually needs -- "ka" and "ki" -- is exactly two characters long. Since convertNaiveV1 DOES try two-character tokens (it just never tries three), a word built entirely from two-character tokens is invisible to the bug completely. The function isn't "broken" in some general sense; it's specifically blind to any token that's three characters long, wherever one happens to occur. This is exactly why "sushi" also isn't a safe word to test this fix against on its own -- "shi" is itself one of the base gojūon grid's real three-character tokens (not a yōon combination at all), so it triggers the identical class of failure convertNaiveV1('sushi') produces the real, verified output "すsひ". WHY THIS WORKS AS AN ANSWER ---------------------------- It confirms both real outputs against actual node execution, then correctly narrows the bug's real scope: convertNaiveV1 doesn't fail on "kaki" because that word happens not to contain any of the exact tokens the bug depends on, not because the underlying flaw only shows up on yōon combinations specifically.