Audit and fix how my app handles secrets: API keys, database passwords, JWT signing keys, Stripe keys, SMTP credentials, webhook signing secrets, and anything else that grants access to something. Do this in order: 1. Scan the repo (current tree and git history) for anything that looks like a secret: long random-looking strings, values in .env files that got committed, hardcoded API keys, credentials in comments or old config files. Report every hit with the file, line, and roughly what it is. Assume anything found in history is compromised, even if it was 'removed' in a later commit. 2. Rotate everything that leaked: generate new keys with the provider, deploy the new values, and revoke the old ones. Don't skip rotation just because the old commit is buried; scrapers find these. 3. Move all secrets to the environment's secret store: the platform's secret manager (Fly secrets, Vercel envs, Render secrets, Doppler, Vault, whatever I use). Don't check .env files into the repo. Do check in a .env.example with placeholder values and comments describing what each is. 4. Enforce per-environment separation: dev, staging, and production use different keys. A leaked staging key must never grant access to production. 5. Add a pre-commit hook or repo-level secret scanner (gitleaks, trufflehog, or the platform's built-in scanner) so this doesn't regress. 6. Document a rotation runbook: how to rotate each type of secret with zero downtime (usually: add the new key, deploy code that accepts either, cut over, remove old). Don't just tell me 'move secrets to env vars' without actually finding what leaked. The deliverable is the leak report, rotation confirmed for anything found, secrets loaded from the secret store in every environment, a .env.example checked in, and a scanner running so it doesn't happen again.