Full-stack audit
Route: /fullstack-audit (sidebar: Checks › Full-stack audit)
The Full-stack audit reads your app’s Supabase backend and every Mushi Mushi check in one pass.
First on the page: one sentence with the exact number of open errors and warnings (counted on the server, not from the capped list) and Copy fix prompt for the top finding: the check, the file and line, the rule and what to do, ready to paste into your editor. Every finding in the list has its own Copy fix prompt. The list says “at least” only when it could not get an exact count, and then says why (only the newest 500 findings were read).
Known holes in your dependencies (vuln-watch, known holes)
are listed and managed at the end of this page (#dependency-holes). Mushi Mushi health →
Code size links here instead of repeating them.
Scenario: It’s Monday standup. You need a PM-readable health scorecard — RLS gaps, recent backend errors, API contract drift — without opening five different tabs.
One Run audit button calls POST /v1/admin/projects/:id/audit and
returns a severity-ranked scorecard.
Scorecard sections
| Check | What it surfaces |
|---|---|
| Backend link | Supabase PAT + project ref configured |
| DB advisors | Security + performance findings from Supabase MCP |
| RLS gaps | Tables without row-level security |
| Error log | Recent backend ERROR-level log count |
| Gate runs | The newest run of every check in the last 7 days, by name: the eight inventory gates, schema drift, code health, the recipe drift checks (design, CI, deploy, env vars), Mushi Mushi setup checks, the app hole checks and the store review checklist |
If a part of the audit could not be read (the settings, the advisors, the logs,
the table list or the gate runs), the page lists it and the verdict reads
Incomplete, never All clear. A count Mushi Mushi could not read is shown as
—, not 0.
Open findings by check
Below the scorecard, every open finding of each check’s newest run is listed
with its rule, file and line. This list is available on every plan; it
reads GET /v1/admin/inventory/:projectId/findings, the same data as the MCP
tool list_gate_findings. Running gates, crawls and test generation still need
a plan with the inventory features.
Mushi Mushi setup checks and “Apply suggested caps”
Once a day Mushi Mushi checks its own setup for each app (gate radar): a provider
key the provider now rejects, a webhook that never delivered, a stale code
index, and missing spend caps. The spend-cap check flags a project with no
monthly AI budget, and auto-fix limits that are not set (a warning while
auto-fix is on, a note while it is off).
That finding has an Apply suggested caps button. It shows each cap before anything changes:
- a monthly AI budget of about twice your last 30 days of AI spend, at least $10, so it does not stop triage on the day you apply it;
- $2 of auto-fix spend per 30 days and 3 automatic fixes a day.
The suggestion comes from the last daily check, so the button reads your
current settings first, and again when you confirm. A cap someone set since the
check ran is left as it is, and the dialog names it. If every suggested cap is
already set, nothing is sent. If the current settings cannot be read, nothing is
sent either. The button saves the remaining caps through
PATCH /v1/admin/settings and needs a signed-in project admin, so an API key or
MCP client cannot apply them. Change or clear them any time in
Settings → General → Spend limits. The finding clears on the next daily
check.
Prerequisites
Set the Supabase project ref under Settings → General → Your database → Supabase project,
then add a scoped Supabase access token under Settings → AI keys → Supabase:
this one project only, with Database, Edge Functions, Advisors and Logs set to
Read, and an expiry. CLI equivalent: mushi audit.
CLI
mushi audit
mushi audit --json
mushi audit --project-id <uuid>Related pages
- Code size — bundle + god-file trends from CI ingest (Mushi Mushi health → Code size)
- Schema changes — scheduled schema drift findings (Mushi Mushi health → Schema changes)
- Mushi Mushi health — Slack / Sentry / GitHub probe status
- User stories — the same findings next to the inventory graph (inventory plans)