Marc-André Bombeck 361e577864 fix(ops): refuse an account whose rows are not the thousandfold class ...

The provenance criterion proves where a row came from, not which build
imported it. An account re-imported on the fixed build carries the same
`EXPORT_XML_SOURCE_MAX` stamp and the same `stats:` external id with the
right numbers and no audit row, so it is selected exactly like a broken
one — and its rest days, under 200 m because the phone stayed at home,
survive the plausibility check after another thousandfold multiply.

So one candidate row that would leave the range now refuses the whole
account: nothing written, no audit row, the offending rows and a printed
reason instead. The idempotency guard only ever held against the
script's own prior run; this holds against the case it could not see.

The runbook says the same in words — a re-imported account must not be
repaired, the re-import already did it — and says what the dry run is
for: it is where the decision is made, not a formality in front of one
already taken.

Integration coverage for the re-imported account: correct rows, an
`--apply` run, nothing changes and no audit row is left behind.

Review finding H1.

2026-09-10 00:27:43 +02:00

..

fixtures/v137

Let a checkup be skipped or pushed back, and remember every outcome

2026-08-14 09:23:58 +02:00

integration

fix(ops): refuse an account whose rows are not the thousandfold class

2026-09-10 00:27:43 +02:00