Not a new feature — a checkpoint after three commits in a row (plan
pricing/HWID live-settings, branding + client site, subscription hold)
that all touched adjacent ground, none of which had been exercised
against backup/restore since. backup.py itself needed zero changes —
it already does a full sqlite-level snapshot plus a raw .env copy, so
by design any new column or .env key is automatically covered without
per-feature updates. That's exactly the kind of claim worth actually
proving instead of assuming, especially for a "restore my database"
feature — if it silently missed something, the admin would only find
out when they needed it most.
Verified end to end against a real isolated sqlite db (not mocked):
set a custom brand name, a price override, HWID settings, and held one
of two subscriptions — snapshot — mutated all of that further (new
brand name, new price, HWID back off, resumed the held subscription,
granted a third one) — restored from the snapshot — confirmed every
single value reverted to exactly what it was at snapshot time,
including held_at surviving the round-trip (the held subscription
comes back held, not silently resumed) and the newer third subscription
being gone. 23 checks, all passing on the first run — backup/restore's
"it's a full snapshot, not a selective export" design held up exactly
as intended.
Added this as a permanent CI step (not just a local script) so future
changes to any of these three features get caught if they ever break
this interaction — ran the step's exact extracted content locally
before committing, same as every other CI addition tonight.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
savsis
71c98c5032