6. Destroying a tenant environment

divvent destroy <modelDir> --env <env> --tenant <tenant> \
  --confirm <tenant>-<env> --snapshot-out ./<tenant>-<env>.sql

--confirm must match <tenant>-<env> exactly. That is the whole guard on destroying the wrong environment: deleting the wrong one means typing the wrong one.

Production needs --allow-prod as well as --confirm, deliberately, as a second deliberate act. --env has no default, for the same reason.

A trial is removed by its own name: --instance heatco--try-b and --confirm heatco--try-b-prod, never production's. It sits in prod, so it takes --allow-prod too.

A trial deployed before trials were marked (#53) is still called heatco-try-b-prod, and nothing composes that name any more: its next deploy goes to heatco--try-b-prod, fresh, and the old Worker, database and bucket are left with nothing that names them. Tear them down by the old name, said out loud, then close the trial and open it again:

divvent destroy <modelDir> --env prod --tenant heatco --instance heatco-try-b \
  --legacy-trial --confirm heatco-try-b-prod --allow-prod --snapshot-out ./heatco-try-b-prod.sql

--legacy-trial is the only way the deployer names <application>-<trial>, because that spelling is also what an application called heatco-try-b would call its production. So it also reads the database's own ledger first (_divvent_meta's app.slug), and refuses unless it says heatco: another application's production, or a database that records nobody — or no database at all, since then nothing says whose the Worker and bucket are — is never deleted this way. Every deploy reads the same ledger and refuses to bind a database that names another application or another deployment. A pull request's copy (pr<n>-heatco, in the preview account) does not: the deployer exempts a pr<digits>- tenant on the same predicate that routes it there, and still refuses heatco itself.

--via <control plane> tears down with the company's own sealed credential, the one deploy --via opens, rather than the platform's.

Take the snapshot. --snapshot-out writes a dump before anything is deleted. The database is about to stop existing and with it the _divvent_meta ledger, so this file is the only thing that will still say what was there. --no-snapshot exists for an environment you are certain about; D1 cannot export a database with FTS5 tables, which is why the dump is ours and not D1's.

Order: snapshot → empty the bucket → delete the bucket → delete the database → delete the Worker and its staged twin. A destroy records itself in the state file's history, which outlives the deploy it destroyed.

---