ponytail-audit

Topics in the source

• 1. Map first
• 2. Look for
• 3. Check before you report
• 4. Output

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. 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. 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.

This is an excerpt. Refer to the complete source and its current requirements.