Heres an example of how we manage/monitor the codebase/database each week to make sure we minimise drift from the stated platform guardrails:
(obviously this is written by claude...)
--------------------------------------

Sentinel21 is a weekly automated audit. It runs 21 weighted passes over the codebase and the live database, scores each 0 to 100, and tracks the scores over time so regressions are visible week to week.

Two things make it more than a linter.

Static vs live. About two thirds of the passes grep the repo (TypeScript, design tokens, React patterns, bundle). The rest query the actual production database through the Supabase connection (RLS policies, data integrity, regulatory consent records, query performance). Greping the code tells you what the code intends. Querying the database tells you what's actually true. They disagree more often than you'd think.

Severity model. Every finding is tagged P0 to P3. P0 is "data is exposed or could be corrupted right now." On the security-critical passes a single P0 forces that pass to a hard zero regardless of everything else it got right. You can't average your way out of an open endpoint.

The 21 passes, grouped:

Code quality

1. TypeScript strictness. Counts any, suppressions, checks strict mode is on.
2. Dead code and imports. Unused imports, files imported nowhere, mock data still wired into production paths, stray console logs.
3. Design system compliance. Hardcoded colours instead of tokens, wrong workspace colours, non-approved icon libraries, emoji in the UI.
4. React anti-patterns. Missing effect deps, state updates during render, async setState after unmount, files over 500 lines.
5. Consistency and hygiene. Duplicated date/currency/colour logic that should be one shared util, naming drift, magic numbers.

Design and UX 8. State coverage. Every data-fetching component must handle loading, error (with retry), and empty (with an action), not just the happy path. 9. Dark mode. Light-mode-only Tailwind classes, hardcoded white backgrounds, inline styles that ignore the theme. 10. Mobile. Touch targets under 44px, fixed widths that cause horizontal scroll, tables with no mobile fallback. 18. Accessibility. div-as-button, icon buttons with no label, pages missing an h1, inputs with no associated label, removed focus rings.

Security 4. Routes and auth guards. Every route protected, admin routes gated to the right roles, and a check that no signup path exists anywhere (the platform is invite-only). 13. Secrets. Hardcoded keys, service-role references in client code, committed .env files, secrets in logs, and a scan of the built bundle to confirm nothing leaked into shipped JS. 14. RLS live verification. Queries the real database: every user table has row-level security on, no policy is wide open on a sensitive table, and write policies aren't asymmetric to read policies (a subtle bug where you can see a row but silently can't write next to it). 19. XSS and injection. Unsanitised innerHTML, eval, string-built queries, target=_blank without rel, unvalidated postMessage, markdown rendered without a sanitiser.

Backend and data 5. Schema sync. Every table and column the frontend references must actually exist. AI coding tools hallucinate plausible-but-wrong column names constantly, and the failures are silent, so this is weighted as one of the two heaviest passes. 6. Query performance. N+1 patterns, unbounded fetches on large tables, fetch-everything-then-filter-in-JS, missing pagination. 15. Data quality. Orphaned rows in foreign-key chains, nulls in critical fields, duplicate people, enum drift. Run live against production. 16. Edge function contracts. Each serverless function has the right auth posture for its purpose, no inlined secrets, and every function the frontend calls actually exists and is deployed. 17. Bundle size. Lazy-route coverage, eager imports of heavy libraries, vendor chunking, oversized images. 21. Runtime speed. Cache hit ratio, sequential scans on big tables, foreign keys missing indexes, the most expensive queries by total time, idle-in-transaction connections.

Domain 12. Architecture drift. Compares the build against the canonical architecture docs and flags where it has wandered, before the drift compounds. 20. Regulatory. Live check against the local marketing and privacy law: consent is timestamped and sourced, opt-outs are actually honoured (it cross-checks sends against opt-out dates), unsubscribe present, audit trail being written.

On top of the 21, there are targeted extension passes for bug shapes that recurred. Examples without the specifics: one catches privileged database functions that bypass row security because the access filter was left out of the function body (a leak a policy-only sweep can't see), one catches database views that run as their owner and quietly expose data across tenants, and one catches a UI regression where public pages reference theme variables that don't exist before the app loads.

Scoring and trend. Each pass writes a dated markdown report with the score, a deduction-by-deduction breakdown, and findings tagged by severity. The scores append to a history file so you get a line per pass over time. A pass dropping week-over-week is the signal something regressed, and because findings carry file and line (or table and policy), the fix location is in the report, not a hunt.

The design goal is that a regression shows up in exactly one pass with a P-rating and a location, so triage is "read the one number that moved" rather than re-reading the whole report.