The check gate recreates the developer database

compass check reads as a read-only gate, and two of its checks recreate the environment database. The db check is ./compass.sh db recreate -y -k. ticks-smoke runs ./compass.sh smoke ticks --fresh, which stops the services, recreates the database, and then provisions acme_corporation from acme_demo.

Gating a change is ordinary work, and it should not cost a developer their state. Anything provisioned by hand is destroyed, including the rows a manual proof recorded, and the replacement looks like a provision, so nothing signals that the old rows are gone. The reader who goes looking for an instance id finds a fresh ACME tenant with no history.

Three ways out, in order of preference:

• Run the heavy checks against a database of their own, created and dropped with the run. That also answers the isolation capture below.
• Keep the current database, and make the destructive step explicit: a flag on compass check, or a prompt that names the database it is about to rebuild.
• At minimum, print the database name and what will be destroyed before the recreate, so the log says what happened.

The same run also exposes the shared test database name, which is a separate capture: Give the test run its own database.

• compass check --list, the check catalogue: the db check runs ./compass.sh db recreate -y -k, and ticks-smoke runs ./compass.sh smoke ticks --fresh.
• projects/ores.compass/src/compass_smoke.py: the smoke stops the fleet, recreates, and provisions acme_corporation with the acme_demo profile.
• Observed on 2026-10-25: after a gate run, the database held 2 live tenants, 78 report definitions and 34 parties, all stamped 01:40 to 01:42, where a hand-provisioned environment had stood before.