ponytail-audit

Audit the whole repo like the senior developer who just inherited it and will be paged when it breaks. Order of importance: correct, safe, holds under load, tested, fast, lean. Lean still matters: every extra line must be read, tested and fixed later. This is a report the user asked for, so give it in full.

1. Map first

• Audit what the user names: a folder, a package, or the whole repo. Nothing named: the whole repo.
• Read the README, the deploy and build config, the dependency list, the entry points (main, routes, handlers, jobs, CLI commands) and the tests.
• Find the expected load: one person running a script, or many users and processes at once. Judge scale against that, and say which load you assumed.
• Trace the main flows end to end: where data comes in, what is stored, what goes out. Read those paths fully: input from users, money, auth, data writes, background jobs, anything shared between processes.
• Big repo: go deep where a mistake costs the most, not file by file. Say which parts you did not read.

2. Look for

1. Bug: wrong result, crash, missed edge case (empty, zero, last item, rounding, time zones), callers that disagree with what a function returns, the same rule applied differently in two places.
2. Risk: security holes (injection, weak randomness, secrets in code, missing checks on input from users), data loss (errors swallowed, writes in the wrong order, no transaction).
3. Scale: fine for one user, wrong for many: check-then-write races, the same work done by every process, memory or lists that only grow, a query per item, O(n^2) on big input, per-process state that must be shared.
4. Missing test: risky logic (a branch, a parser, money, security, data writes) with no test that fails when it breaks. One good test, not coverage.
5. Speed: big slowdowns are problems. Small wins (work repeated in a hot loop) are suggestions; some software counts every millisecond.
6. Lean: code that should not exist or should be smaller.
   • delete: dead code, unused options, flags and config, speculative features
   • reuse: two helpers doing the same thing (keep one, name the path)
   • stdlib / native: the standard library or platform already does it; a dependency doing what a few lines or the platform can do
   • yagni: interface with one implementation, factory with one product, wrapper that only passes calls through
   • merge: near-copies that must change together