thermo-nuclear-code-quality-review

Strict Code Quality Review

This is an unusually demanding review mode, not an instruction to rewrite code by taste. Inspect the current diff and surrounding architecture, then report only high-conviction findings grounded in a contract, reachable behavior, or a material maintainability risk.

Review Bar

Ask:

• Can a simpler ownership boundary remove whole branches or concepts?
• Did the diff add ad-hoc flags, special cases, or feature logic to a shared path instead of using the canonical layer?
• Did a cohesive module become more coupled or cross a meaningful shape limit?
• Are wrappers, casts, optionality, and sequential orchestration earning their complexity?
• Does a proposed decomposition reduce what a reader must hold in mind, rather than merely move the same complexity into more files?

A file crossing roughly 1000 lines is a strong signal to inspect decomposition, not an automatic failure. Apply the project's actual shape policy and explain why a split would improve ownership. Do not manufacture a rewrite when the current structure is coherent and the change is small.

Output

Report findings in this order:

1. structural regressions;
2. missing simplifications with a concrete alternative;
3. spaghetti or branching growth;
4. boundary and type-contract problems;
5. file shape and decomposition;
6. lower-severity readability issues.

For each finding include file/line, contract or evidence, user/operator impact, and a concrete remedy. Separate BLOCKER, ADVISORY, and ACCEPTED decisions. If no finding survives reachability, materiality, and evidence screening, say so.

Independence and scope

Use a fresh reviewer for non-trivial changes. This review does not replace focused tests, security proof, or proof-verify; it evaluates maintainability and architecture. It must not silently edit production code or turn an advisory concern into a rewrite.

Gotchas

• Ambition without a contract becomes over-engineering. Keep the selection gate: a sufficient implementation is a reason to stop expanding.
• A line count is a probe, not a universal design law.
• Moving code across files without reducing coupling is not a successful decomposition.
• Passing tests do not erase a material architecture regression, but a style preference without impact is not a blocker.