Charles Pre-PR Review Checklist

Run this against the actual diff (git diff origin/master...HEAD), hunk by hunk. For every item below: fix it, or have a one-line defense ready. Charles will ask. Approximate comment counts from the corpus are shown per section — §1 (dead code), §10 (UX & layout), and §7 (state placement) draw the most comments by far.

How Charles reviews — calibrate to this

• He tests on device before approving. Approvals cite verified behavior; his bug reports come with repro steps, screenshots, and recordings. He expects the same evidence standard from authors — run the feature on a physical device, without the debugger, before requesting review (he catches laggy TextFields, hangs, rendering issues).
• Reviewability is a product feature. Recordings, testing recipes, feature previews, clean descriptions: "These screen recordings will really help the reviewer going forward and help us ship faster with fewer bugs!"
• Scope discipline over big PRs. Server vs client, infra/analytics vs experimental offer, feature vs launch — all separate PRs. Data collection precedes interventions.
• Reversibility first, decisiveness second. Keep old code until sure ("in case heaven forbid we want to go back"), grace-period rollouts — but once aligned, commit fully: "Time to bite the bullet and make a decision!" One app, never two maintained versions.
• Pragmatic blocking. He distinguishes blockers from follow-ups explicitly and files non-blockers as TODO(<TICKET>-launch) comments or tickets — but he re-comments until every prior comment is actually resolved ("Still need to remove").
• Every added line must have a self-evident reason. His most common question shapes: "Why is this necessary?", "Where did this come from?", "Is this used anywhere?"
• Repo idioms beat ceremony. He defends existing patterns against restructuring ("strengthen the comment, not the control flow") and expects new code to match what siblings already do.
• Craft in the details. Animation pacing, celebration weight, padding parity, icon weight — polish is reviewed as rigorously as correctness.
• Process compounds. Recurring feedback becomes a standing rule or a repo skill ("Let's always have claude…") so the same comment never has to be made twice.