project-auditlisted

# Project Audit A real audit is evidence-driven. Every finding points at a line, a route, a table or a config key, and every finding carries a way to prove the fix. Opinions without locations are not findings. ## Phase 0 — Scope and consent (2 minutes, never skipped) Establish before reading code: 1. **What is in scope?** Repository only, or also the live site, infrastructure and third-party accounts? 2. **What is the audit for?** Pre-launch gate, investor due diligence, an inherited codebase, a security concern, or a general health check. This changes what gets weighted. 3. **What may be run?** Read-only analysis is always safe. Ask before installing dependencies, running tests, starting services, or touching anything that reaches production. 4. **Is there a live URL?** If yes, the `web-presence-audit`, `accessibility-audit` and `privacy-compliance` passes become live checks rather than code inference. Never scan, probe or send traffic to infrastructure the user has not confirmed they own or are authorised to test. State the scope in one line and begin. ## Phase 1 — Ground truth Run the discovery protocol from `senior-engineer/references/discovery-protocol.md`. `scripts/recon.sh` (or `recon.ps1` on Windows) automates the first pass and prints a structured summary — run it if the environment allows, and fall back to the manual commands if not. It is read-only. Do not proceed to findings until the Ground Truth block is filled in. An audit built on a