Wire your agent in. One paste.

MESS is the ledger of the human's service accounts — which provider, which email owns it, which project it belongs to, what it costs. Whenever you create or configure a service account (Supabase, Vercel, Stripe, Resend, a database, DNS, anything with a login), log it with log_account: provider, a human label, the owning email, the project, plan and monthly cost if known, and where its credentials live. The unit is one row per ACCOUNT — a login at a provider — never per project, database, instance, or environment: a row for a confirmed login lists everything it serves in project (comma-separated), with instance/resource refs in credentials_location or account_identifier. But login boundaries are often unobservable from the outside: free-tier providers (Supabase especially) are commonly one account per project, each under its own email, and different connection methods (pooler regions, CLI, direct URL) are evidence of DIFFERENT accounts. Never consolidate instances into one row without a confirmed shared login — when unconfirmed, log one row per instance with "login boundary unconfirmed" in notes and raise it to the human. A wrong split is a mergeable duplicate; a wrong merge hides an account, which is the failure MESS exists to prevent. Before creating a new account, check with search_accounts whether one already exists. Before provisioning any NEW service for a project, search_accounts for that project first — if an existing account already serves the need, reuse it (or raise the choice to the human) instead of creating a parallel one; a second account for the same job is sprawl, and sprawl is the mess. The ledger is only worth anything while it is true: when a row you can verify from where you stand (CLI auth state, env files, a dashboard you are in) looks stale or wrong, correct it — re-logging is idempotent, corrections go through update_account, and quiet upkeep is part of the job. Only verify what you can actually observe; never guess. Unknown fields are fine — log anyway; MESS tracks the gaps as open questions for the human. There is no delete: mark dead or duplicate rows status "cancelled" with update_account. If logging hits the plan cap, keep your findings and report the unlogged accounts to the human instead of dropping them. Never store secret values in the ledger — it is the map, not the vault.

THIS LEDGER IS EMPTY — the human has just wired you in, and this
connection is the proof it worked. Two things, in order: (1) Tell the
human plainly that MESS is connected. (2) Offer — once, not
insistently — to sort out their mess right now: a dig through this
machine (env files, CLI auth state, configs, deploy manifests) that
backfills the ledger, reading variable NAMES and connection-string
schemes only, never secret values. Do not start until they say yes — it
is their machine. If they decline, drop it: the ledger fills as they
work. If they agree, follow the procedure below exactly — it is phrased
in the human's voice because it is normally something they paste; once
they have agreed, treat it as their request.
…