docs(adr): record the cassette-state synchronization model #105

Merged
padreug merged 2 commits from docs/adr-cassette-sync into dev 2026-09-22 22:26:11 +00:00
Owner

This protocol spans two repos and decides how much cash a machine will pay out, and its only specification was a closed issue and a chat log. That is how four separate divergence bugs went unnoticed.

It records what the transport actually permits — an addressable event is an unconditional overwrite ordered by a second-granularity clock, and a relay acknowledges an event it then discards, so a losing writer is never told — and why that rules out compare-and-swap and leads to the ATM owning the count while the operator publishes operations.

Decisions 5 through 8 shipped in #104 and spirekeeper#44 and are verified live on sintra. Decisions 1 through 4 are the v2 operations wire and are not yet built.

This protocol spans two repos and decides how much cash a machine will pay out, and its only specification was a closed issue and a chat log. That is how four separate divergence bugs went unnoticed. It records what the transport actually permits — an addressable event is an unconditional overwrite ordered by a second-granularity clock, and a relay acknowledges an event it then discards, so a losing writer is never told — and why that rules out compare-and-swap and leads to the ATM owning the count while the operator publishes operations. Decisions 5 through 8 shipped in #104 and spirekeeper#44 and are verified live on sintra. Decisions 1 through 4 are the v2 operations wire and are not yet built.
This protocol spans two repos and decides how much cash a machine will
pay out, and its only specification was a closed issue and a chat log.
That is how four separate divergence bugs went unnoticed.

Records what the transport actually permits — an addressable event is an
unconditional overwrite ordered by a second-granularity clock, and a
relay acknowledges an event it then discards, so a losing writer is
never told — and why that rules out compare-and-swap and leads to the
ATM owning the count while the operator publishes operations.

Decisions 5 through 8 shipped in #104 and spirekeeper#44; 1 through 4
are the v2 operations wire and are not yet built.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Two things learned after the ADR was first written.

The dashboard's publish dialog already warns that the publish overwrites
the ATM's tracked counts and that decrements since the last baseline will
be lost, and says v2 reconciliation will replace it. That changes how the
gap should be read: a known risk with a human-factors mitigation, not an
oversight, and the product had already reached the same conclusion these
decisions formalise. Worth stating that a warning is the weakest control
available — it depends on an operator reading a dialog, and cannot help
when the stale value is the one already in the form.

Also records that decisions 5 to 8 were verified live on sintra rather
than only by unit test, and which of the listed failures those decisions
do not close.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
padreug deleted branch docs/adr-cassette-sync 2026-09-22 22:26:11 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
aiolabs/bitspire!105
No description provided.