Admin console · animated

Click to expand

Schema changes

Route: /health?view=schema (Mushi Mushi health → Schema changes). The old /drift link redirects there. Until October 2026 this was its own page, called Drift scanner.

First on the page: one sentence on what changed since the baseline, with Review changes when any wait. Once scanned, Changes found per day draws the changes over time with a dashed line per release and a dot on each day with a serious change (red while one is open). Never scanned: one Run first scan step and nothing else.

Scenario: You shipped a refactor last Friday. It’s Monday and a screen that calls your API shows nothing. You suspect a route was renamed or a handler was removed. You run a scan and see which routes no longer line up.

Each scan in Mushi Mushi builds a fresh contract snapshot from three sources, then compares them with each other:

• your OpenAPI spec, if you set its URL for the project
• the API calls in your app map (inventory api_dep nodes)
• your database schema, from the latest backend schema snapshot

A source that is not set up is reported as not configured, not as “no changes”. There is no scheduled scan: scans run when you start one.

When to run it

• After every deploy, especially refactors, route changes or renamed handlers.
• Before an improvement run, to confirm there is no regression before the loop starts.
• When reports spike: a broken screen often matches a finding you haven’t seen yet.

Tab: Run a scan

Enter Max paths to walk (a whole number from 10 to 1000; the field starts at 200) and click Run scan.

When it completes, a Scan complete box shows:

• discovered: how many findings the scan produced
• new stored: how many were stored. A finding already stored with the same type, surface and path in the last 24 hours is not stored again.
• snapshot: the ID of the contract snapshot the scan used

If the scan fails

The error names the step that failed (for example the snapshot builder could not read your OpenAPI spec). Fix that source and run the scan again.

Tab: Changes

Your list of findings. The summary counts at the top are Changes to review, Serious, Warnings and Scans.

Each row shows Severity, Surface (api or inventory), Path, Message and when it was Found. Today’s scan writes four kinds of finding:

Click a row to open the detail drawer with:

• The Expected and Actual values
• → Lesson (shown on findings marked critical only): turns the finding into a candidate lesson, reviewed under Lessons
• Dismiss: marks a known or intentional change. Mushi Mushi then checks that route less often.

What to do with a finding

1. Open it and read Expected against Actual.
2. Intentional (you renamed the route on purpose)? Dismiss it.
3. A regression? Fix the route or the spec, or start a fix from Fixes, then scan again.

Tab: Scans

The last 20 contract snapshots, each with its ID, edge count and time. Use it to see when the baseline last changed.

Common tasks

Post-deploy check (the fast path)

1. Open the Run a scan tab and click Run scan.
2. Open Changes. No new warnings? Carry on.
3. A warning? Open it, compare Expected and Actual, then dismiss or fix.

Investigating a screen that stopped loading

1. Run a scan with a higher max paths, such as 500.
2. In Changes, look for dead_handler or missing_inventory findings on the route the screen calls.
3. If the route was removed by mistake, start a fix.

API

POST /v1/admin/drift/scan             { "project_id": "<pid>", "max_paths": 50 }
GET  /v1/admin/drift?project_id=<pid>&limit=100
GET  /v1/admin/drift/snapshots?project_id=<pid>
PATCH /v1/admin/drift/<id>            { "status": "dismissed" }
POST  /v1/admin/drift/<id>/create-lesson

Related pages

• Improvement runs — run a quality scoring loop after clearing findings
• User stories — the app map the scan reads
• Fixes — act on a regression
• Lessons — where a promoted finding goes