pr-preplisted

# PR Prep A PR is a unit of communication as much as a unit of code change. Before you open one, review it the way a careful reviewer would — catching the issues you'd want flagged before anyone else has to deal with them. ## Step 1: Read your own diff Pull up the full diff and read it cold, as if you didn't write it: ```bash git diff main...HEAD # or whatever the base branch is ``` What to look for: - **Unintended changes**: whitespace noise, reformatted files, debug logging left in, commented-out code that shouldn't be there - **Incomplete work**: TODOs added but not addressed, stubs that aren't wired up, feature flags that haven't been connected - **Sensitive data**: credentials, tokens, API keys, internal hostnames — anything that shouldn't be in source control - **Scope creep**: changes unrelated to the PR's stated purpose. Pull these into a separate PR or a follow-up commit. ## Step 2: Test coverage check For every meaningful behavior change in the diff: - Is there a test that would fail if this code were reverted? - Are error paths and edge cases covered, not just the happy path? - If this fixes a bug, is there a regression test? Missing test coverage isn't always a blocker, but it should be a deliberate choice, not an oversight. If you're leaving coverage thin, say why in the PR description. ## Step 3: Migration and deployment safety If the change touches a database, schema, or persisted data format: - Is the migration reversible? Can you roll back the