Bryce
e05f20c135
Running the split across all 19,040,296 orders left 104 payments with two parent orders in a 250,000-order sample. Every one of them is two orders of the SAME client; cross-client sharing is gone entirely. Attempting to split those too was wrong twice over. Both orders compute the same name, so there is no second name to give a copy and the transaction conflicts. And a copy would double that client's takings for the day — where Square splits one tender across two of a client's own orders, one payment covering both is the truthful record. So the rule is now explicit: split per client, not per order. The component cascade still reaches these, which is why remove-voided-orders needs its own guard regardless of how complete this migration is — that was already the recommendation and this makes it load-bearing rather than belt-and-braces. Batch bookkeeping now records which name each charge was claimed under, so a second order in the same batch computing that same name is left alone instead of attempting a colliding copy. Migration state on the restore, measured rather than asserted: charges 17,046,418 scoped · 0 legacy · 0 unscopable refunds 51,986 scoped · 0 legacy payouts 144,652 scoped · 0 legacy · 36 with no owner shifts 69,291 scoped · 0 legacy A second full pass walked all 19M orders in 7.8 minutes and changed nothing, which is the idempotency the tests assert, confirmed at full scale. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>