code-maturity-auditlisted

# Code-maturity audit The app began as a local, no-auth hobby MVP and is now a live, public, multi-tenant SaaS. `CLAUDE.md` reframed the priorities accordingly (*staying minimal* → *production-ready*), and `docs/production-readiness.md` §7 ran this exact lens once, on 2026-07-19 — it produced the Knex (#211), pino (#212), zod (#213) and JWT (#214) adoptions and left two items open. Nothing re-runs that lens as the codebase grows. This skill makes it recurring. The realistic finding is therefore **code that has outgrown its original context, or newly hand-rolled code that skipped the build-vs-buy question** — not a wholesale redesign. The architecture calls were re-examined for the public end-state and held; they live in `criteria.md` as rejected entries so no run re-litigates them. **Read `.claude/skills/audit/audit-loop.md` first** — it owns the loop (research gating, the critique test, the report format, the rule that findings only become issues with the user's approval). This file owns the domain. Pass `--research` to force a research pass; otherwise the cadence in `criteria.md` decides (90 days — the library ecosystem moves slowly relative to this codebase, and most of the value is in the repo-facing audit, which runs every time). ## Calibration — the two ways a "maturity" audit goes wrong Both failure modes produce confident, useless findings; kill them in phase C. - **Enterprise cargo-cult.** The scale anchor is real and small: one operator, a single-digit Rail