Adds a [client location start end] arity to upsert-cash-shifts, matching
upsert-payouts, so a backfill can cover a chosen window rather than the fixed
75-day default.
Re-keyed and re-imported the two newly scoped types on the restore, then checked
what it cost:
144,652 expected deposits and 69,291 cash drawer shifts re-keyed
entity counts unchanged on all four Square types, 0 collisions, 0 legacy keys
live re-import over 66 of 102 clients wrote NOTHING — no entities created and
no values rewritten, because every record resolved to the importing client's
own entity through the legacy-key fallback
0 ownership changes since the re-key, across deposits, shifts and refunds
12,044 summaries recomputed afterwards and compared: 0 differences
So re-keying 213,943 entities moved no money at all, which is the result you
want from a migration whose only job is to make contention impossible.
The re-key does not retrospectively re-attribute records claimed by the wrong
client while a location was shared; those stay where they were last written.
Correcting them is a separate exercise, gated on the business deciding which
client owns each location.
Report updated with the isolation audit and a plain-language explanation of the
remove-voided-orders component cascade.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bryce
41a1eb04a8