The serving tier and the background work must not fight over the same machines, and a deploy must not change what the product does except by what the diff says. Born 2026-08-18 out of the migrations-vs-deploy gate defect, and named a track by usage when the maildir-poll cutover needed a label β this page is its first, written 2026-08-25.
One item, one order. The track's only open issue is the second half of a cutover whose first half is live β finishing it removes the duplicated driver and the 70-minute period ambiguity in one migration. Anything else that lands on this label later (a deploy-gate defect, a machine-placement regression) enters by the same criterion this page's siblings use: what a user experiences first.
Evidence below is generated from the read-only audit of 2026-08-29 and reconciled against the open issues at build time. Every claim cites the issue it came from. Nothing here is a decision β rulings stay in the prose above, which is written by hand.
Detection exists and is armed; automatic recovery does not. `.github/workflows/fly-health-alert.yml` (cron `*/5 * * * *`) runs `docs/reference/operations/alerting/fly-health-check-alert.sh` over the matrix mawja-api / mindbridge-evolution / mindbridge-evolution-db β it alerts only. Search for any restart action: `git grep -rn "machine restart|/restart|machines/.*restart" origin/main -- .github docs/reference/operations backend/scripts` β population = the entire CI-workflow tree, the ops docs tree, and backend scripts on origin/main. Six hits, ALL prose in runbooks (docs/reference/operations/monitoring.md:227, 243, 247, 306, and 322 which explicitly names this as the missing complement) plus one line in the DeepSeek re-enrich runbook. Zero code path calls the Machines API restart endpoint.
Part 1 shipped and is reachable: `maildir_poll` is a registered drain loop at `backend/app/worker.py:220` (named in the loop roster docstring at line 157). Part 2 has NOT shipped: `git grep -rn "poll-maildir-tenants" origin/main -- supabase/migrations` returns only `20260616174657_pgcron_poll_maildir_tenants.sql` (the original SCHEDULE migration; its `cron.unschedule` is the idempotent pre-schedule guard inside that same file) and a comment line in `20260817134432_schedule_cron_delivery_sweep.sql`. No unschedule migration exists. Prod cron census 2026-08-29: jobid 18 `poll-maildir-tenants`, `0 * * * *`, active, POST /api/connectors/internal/poll-maildir, last start 13:00:00 succeeded, 24 runs/24h. The endpoint is still driving the walk on the serving tier.
3 assessed issues closed since the audit and are not shown β a closed issue's evidence is history, and printing it as current is how a page starts lying.
PR #3453 (merged 2026-08-19; the label itself was first used 2026-08-18 on #3442) gated the backend deploy on the DATABASE's schema rather than the migrations job's conclusion β closing the class where a migration job reports success while the schema the app deploys against is not what the migrations produced (#3442). That fix predates this page; it is why the label exists.
One maildir tick walked 302 mailboxes (96,114 messages deduped) over ~10 minutes β inline, on the serving tier. The steal table across machines read 7.54% (shared 4-worker box) versus 0.007% (dedicated) β a 1,032Γ difference β and tool calls measured 36β63s with the DB idle at 1β3s against 1.8β4.0s on the healthy comparison, which is the signature of CPU starvation rather than query cost. After the move, steal read 0.09% β and the follow-on turn-time instrumentation found a Regina turn still costs ~2.25Γ an aeldaly turn at the same LLM round count, with ~30s/turn still unattributed: the steal was real but not the whole story, and the rest belongs to AMA-TRUST.