Brief Claude Code to port a codebase between languages without smuggling over the source language's idioms

You are porting Python 3.11 code to Go 1.22. Work in four phases, in order, and do not begin Phase 2 until Phase 1 is written down and confirmed.

PHASE 1 — INVENTORY AND IDIOM MAP
List every file or module in scope: the report_generator/ package (9 files) that builds nightly PDF usage reports. For each source-language idiom that has no direct equivalent in Go 1.22 — error handling style, iteration patterns, null/optional handling, concurrency primitives — write down the target-language idiom it maps to, using these notes as the starting point: Python's try/except with broad catches maps to Go's explicit error-return checking, not to panic/recover; Python generators map to Go channels only where laziness is actually needed elsewhere it's a plain slice. This map is the single most important output of this phase; a port that skips it tends to produce Go 1.22 code that still thinks in Python 3.11, which compiles but reads as foreign to anyone who maintains it afterward.

PHASE 2 — PORT ONE REPRESENTATIVE FILE FIRST
Before touching the rest of the scope, port the single file most representative of the module's overall pattern. Stop and show it. This is the checkpoint where a wrong idiom-mapping decision gets caught once, cheaply, rather than propagated across every remaining file.

PHASE 3 — PORT THE REMAINDER
Apply the confirmed pattern from Phase 2 across the rest of the scope, file by file. For anything genuinely out of scope for this pass — the email-delivery wrapper that calls report_generator, which stays Python and just shells out to the new binary — leave it in Python 3.11 with a clear marker rather than porting it partially or guessing at its intent.

PHASE 4 — PARITY VERIFICATION
Run python scripts/compare_outputs.py --python-cmd 'python -m report_generator' --go-cmd './bin/report_generator' --fixtures tests/fixtures/ against both the original and the ported code on identical input and confirm matching output, not just that the port compiles or passes its own new tests written after the fact. A test suite written by the same pass that wrote the port will tend to test what the port actually does rather than what the original guaranteed — parity means checking against the original's behavior, including its edge cases and error paths, not just against the new code's own assumptions.

WHAT NOT TO DO
- Do not port line-by-line or function-by-function as a literal transliteration; a for-loop that exists because Python 3.11 lacks a construct Go 1.22 has natively should become that native construct, not a hand-rolled loop.
- Do not silently drop or reinterpret error-handling semantics — if Python 3.11 distinguishes recoverable from fatal errors in a way Go 1.22 handles differently, say so explicitly rather than picking one arbitrarily.
- Do not introduce a target-language dependency not already in Go 1.22's ecosystem or the project's existing dependency list without naming it and asking first.
- Do not mark the port complete based on Phase 3 alone; Phase 4 is not optional cleanup, it is the actual acceptance criterion.

End each phase by stating explicitly what was decided and what is still open, so a reviewer or a later session can pick up from that exact point.