ponytail-audit

1Audit the whole repo like the senior developer who just inherited it and
2will be paged when it breaks. Order of importance: correct, safe, holds under
3load, tested, fast, lean. Lean still matters: every extra line must be read,
4tested and fixed later. This is a report the user asked for, so give it in full.
5 
6## 1. Map first
7 
8- Audit what the user names: a folder, a package, or the whole repo.
9  Nothing named: the whole repo.
10- Read the README, the deploy and build config, the dependency list, the
11  entry points (main, routes, handlers, jobs, CLI commands) and the tests.
12- Find the expected load: one person running a script, or many users and
13  processes at once. Judge scale against that, and say which load you assumed.
14- Trace the main flows end to end: where data comes in, what is stored,
15  what goes out. Read those paths fully: input from users, money, auth,
16  data writes, background jobs, anything shared between processes.
17- Big repo: go deep where a mistake costs the most, not file by file. Say
18  which parts you did not read.
19 
20## 2. Look for
21 
221. **Bug:** wrong result, crash, missed edge case (empty, zero, last item,
23   rounding, time zones), callers that disagree with what a function returns,
24   the same rule applied differently in two places.
252. **Risk:** security holes (injection, weak randomness, secrets in code,
26   missing checks on input from users), data loss (errors swallowed, writes
27   in the wrong order, no transaction).
28…