create-kr-patch

Create a Korean patch for a retro game

Purpose

Base decisions on evidence from the target game. Keep the evidence and adopted results from the initial survey, fonts and encoding, PoC, extraction, translation, reinsertion, product builds, distributable patches, and runtime verification traceable through completion.

Choose tools, languages, libraries, and fonts based on the target project's existing structure and the current environment. Regardless of those choices, preserve the required capabilities and verification criteria. Look up basic specifications from current primary sources when one straightforward search can recover them.

Treat source-language frequencies and structures from other titles as hypotheses until the target revision confirms them.

Foundational principle

Treat each playthrough as the whole product. Successful paths do not offset a known in-scope defect that can block progress, corrupt text or intended meaning, mislead the player about a choice, break approved terminology or voice, or impair interaction. Fix it, present evidence and feasible options for an explicit human decision to narrow the scope or claim, or withhold the release. See references/strategy/build-and-verify.md §6 and references/strategy/translation-workflow.md §6.

Operating principles

1. Let product closure define the work. Define the target by what must hold together across its declared scope and claims, not by the current artifact plus the next plausible edit. Credit a result only to the claim it strengthens. Keep the hardest unresolved completion condition—or the one most likely to force redesign—visible, and choose work from it. Among approaches with the same prerequisites and proof scope, prefer the lower total cost of obtaining evidence. See references/conventions/project-records.md §1 and references/strategy/build-and-verify.md §1·§6.
2. Keep each evidence loop informative. Let unresolved uncertainty determine whether static inspection, runtime observation, or both can produce the next discriminating evidence. Keep the exact applicable artifact fixed while affected routes can still yield interpretable evidence; one defect does not require an immediate rebuild. Change the baseline when its question is answered or observation is blocked, contaminated, or unsafe. Conflicting evidence, repeated equivalent evidence, local passes that do not strengthen the cumulative claim, and accumulating exceptions signal reassessment. Restore the baseline, completion condition, and live and rejected explanations; search references/tips/README.md by observation before adding another local exception. Cases suggest hypotheses, not repairs. See references/conventions/project-records.md §2 and references/strategy/debugging.md §2·§3·§5·§6.
3. Keep product priorities and decision authority separate from implementation. Current implementation establishes behavior and change cost, not product value. The agent establishes technical facts and feasible options; humans choose product direction, quality, scope, acceptable loss, support, and investment. At a meaningful point of convergence, present the current result and possible gains with their effort, risk, uncertainty, and claim impact. Bind the human choice to that evidence baseline; it is not technical completion or proof that improvement is exhausted. Routine implementation that preserves adopted intent remains the agent's responsibility. See references/conventions/project-records.md §1.1 and references/strategy/translation-workflow.md §4.1·§5.