UnheardCity/docs/history/mission3_audio_text_prompt.md

CONTINUE: Finish full-game audio editing, then add subtitle and menu-text editing

Same autonomous rules as before: I won't answer questions, so decide, log assumptions in NOTES.md, and continue. Start by reading NOTES.md, CLAUDE.md, docs/ and docs/decisions.md to restore context, and apply the new findings from the last session. Keep the Steam, backup and byte-identical-originals rules.

1. Complete audio editing for every sound in the game

• Make editing work for every audio file in the game (all WADs and languages), using the new findings. Handle edge cases explicitly (different codecs/variants, streamed vs. in-memory, sizes, alignment) in ackit, not in app-side workarounds.
• Make sure every single audio file is cataloged and the catalog is correct: add a verification command and test that cross-checks the catalog CSVs against the real WADs (missing, extra, duplicate, wrong character, wrong category, wrong language). Fix the data, and report remaining unknowns in docs/.

2. Subtitles and menu text editing

• Reverse engineer where and how the game stores subtitles and menu/UI text (they are text files in the game folders). Document the formats and encodings in docs/, and implement parsing and writing in ackit (with safe backup/revert, as for audio).
• In the editor:
  • Subtitles section, linked to audio. Each sound shows its subtitle, and each subtitle links back to its sound. Editing both together should be convenient: search by text, character and category, show both side by side in the single-file editor, and bulk edit/find-and-replace.
  • Separate "Menu text" section, kept apart from audio and subtitles, with its own search, filters and per-string editing.
• Support revert (per entry and all), mod export/import for text, and detect when game files changed underneath.

Quality rules

• Do it properly: no hacks. If the editor UI or ackit need major restructuring to fit this cleanly, do it, and keep the repository organised as it is now (clear modules, no duplicated code, no leftover scripts).
• Add the necessary tests: unit, headless app-logic, GUI smoke tests, and a real end-to-end test against the game for audio and for text (apply, check the game starts and shows the change, revert, byte-identical).
• Document everything and update the existing documents (README, docs/, decisions.md, user guide, NOTES.md, CLAUDE.md), including the new catalog schema and the text file formats.
• Update the relevant docs and README in the same commit as each change, not at the end. A stage is not finished until its docs, tests and NOTES.md status are updated.
• Rebuild the packaged distribution (with bundled tools and licenses) and re-verify it.

Saving quota (I'm on a limited Claude Pro quota; this is a hard requirement)

• Plan before acting: write a short ordered plan in NOTES.md, work in small stages, and commit after each. Finish and verify one stage before starting the next, so a usage pause never leaves broken work.
• Keep context small: never print whole files, big logs, WAD listings or catalogs. Use grep, head/tail, counts and summaries, and read only the line ranges you need. Write long outputs to files and inspect them selectively.
• Don't re-read what you already know: rely on NOTES.md and docs/ instead of re-deriving or re-reading large sources. Update them as you go so a context reset is cheap.
• Use cheaper subagents (Sonnet or Haiku) for mechanical and bulk work: catalog cross-checks, CSV fixes, log triage, repetitive edits, test runs, and doc updates. Keep the main Opus context for reverse engineering, design decisions and tricky debugging.
• Run the cheapest check that proves the point: run the specific failing test first, not the whole suite after every edit. Run the full suite only at stage boundaries.
• Run the expensive real-game end-to-end tests (launching the game) sparingly: once per stage after the headless tests pass, plus the full pass at the end. Batch many changes into one game run where possible.
• Avoid GUI screenshots and image reads unless a layout problem needs them. Prefer headless assertions.
• Don't rebuild the distribution until the end, except for a single early build to check the pipeline.
• Avoid repeated failed attempts: after two failures on the same problem, write down the hypotheses tried, then change approach instead of retrying.
• Order of priority if the quota runs short: (1) correct, complete audio editing and catalog, (2) subtitle editing linked to audio, (3) menu text section, (4) tests and docs for each as you go, (5) packaging. Always leave NOTES.md with a clear "Current status / Next steps" so work can resume cleanly after a pause.

Finish with a short summary and a REPORT.md of anything unresolved.