cassette layout changes after first boot never reach spirekeeper (one-shot hello gate)

padreug commented

2026-09-20 15:15:27 +00:00

Owner

The bitspire-cassettes-state hello is gated by the boolean meta.bootstrapPublishedAt. It fires once on first boot and then only after a dispense or an applied operator config (#65). Any change to the layout itself — reseeding the cassettes table, adding a bay with atm-tui, direct SQL — is never published, so spirekeeper's cassette_configs keeps the old bay set and every publish from the dashboard fails position-set validation (or worse, pushes stale values back down, see below).

Hit this on 2026-09-20 on the sintra after a DB wipe + reseed: the first boot published the hello, a Publish from the dashboard form (still loaded with the old rows) landed 7 min later and overwrote the fresh seed. Working around it needs

DELETE FROM cassettes; UPDATE meta SET value='' WHERE key='bootstrapPublishedAt'

and a restart.

Proposed:

drop the boolean gate. Publish the state on every boot (replaceable event, latest wins, encrypted — cheap), or store a fingerprint of the position set in meta and republish when it differs.
provision-atm.sh: accept a CASSETTES input so the layout is part of provisioning.
factory-reset-atm.sh: carry VITE_LAMASSU_CASSETTES through the .env rewrite like model + fiat, otherwise a non-preset machine reverts to the preset bay count.

Related: #56 (design), #65 (live republish), aiolabs/spirekeeper#43 (reconciliation side).

The bitspire-cassettes-state hello is gated by the boolean meta.bootstrapPublishedAt. It fires once on first boot and then only after a dispense or an applied operator config (#65). Any change to the layout itself — reseeding the cassettes table, adding a bay with atm-tui, direct SQL — is never published, so spirekeeper's cassette_configs keeps the old bay set and every publish from the dashboard fails position-set validation (or worse, pushes stale values back down, see below). Hit this on 2026-09-20 on the sintra after a DB wipe + reseed: the first boot published the hello, a Publish from the dashboard form (still loaded with the old rows) landed 7 min later and overwrote the fresh seed. Working around it needs ``` DELETE FROM cassettes; UPDATE meta SET value='' WHERE key='bootstrapPublishedAt' ``` and a restart. Proposed: - drop the boolean gate. Publish the state on every boot (replaceable event, latest wins, encrypted — cheap), or store a fingerprint of the position set in meta and republish when it differs. - provision-atm.sh: accept a CASSETTES input so the layout is part of provisioning. - factory-reset-atm.sh: carry VITE_LAMASSU_CASSETTES through the .env rewrite like model + fiat, otherwise a non-preset machine reverts to the preset bay count. Related: #56 (design), #65 (live republish), aiolabs/spirekeeper#43 (reconciliation side).

padreug referenced this issue from aiolabs/spirekeeper

2026-09-20 15:15:33 +00:00

cassette_configs never reconciles bay removals, and Publish can overwrite a newer ATM report #43

padreug referenced this issue from a commit

2026-09-22 20:14:17 +00:00

fix(cassettes): publish state on every change, and make the stamps monotonic

padreug referenced this issue from a pull request that will close it,

2026-09-22 20:14:49 +00:00

fix(cassettes): close the machine-side divergence paths #104

padreug closed this issue

2026-09-22 20:30:24 +00:00