Flow
Reading the zero
1Every row fails the same check
It is a scope problem, so a longer window will not help.
2No match with or without the rule
Nothing to bridge. Park the product and look at other reviewed items.
3Match only without the rule
An alias might fit. Propose it, do not save it.
4Second copy has the same mismatch
It is no way out. Keep the fixed pick rule.
5Rehearsal count is not exactly one
The rerun blocks. Nothing was written, so nothing to undo.
Zero of the stored sales rows from a short window belonged to an approved product, according to a check in the ordering system.
A zero like that has several possible causes: the window is too short, the mapping is wrong, the ID type is wrong, you picked the wrong copy of the data (I had two copies of the same window), or the ID is there but filed under another store connection. Widening the query only helps with the first.
Finding which miss it was
I picked one copy by a fixed rule and reported the other on the side. Then a gap check looked at every row. Each had a product ID and a good date, and each failed the connection check. When every row fails the same way, a bigger window won't help.
The first product wasn't there
Before guessing at an alias, I compared IDs twice, once with the connection rule and once without. For the first product, both were empty. There was nothing to bridge, so I parked it.
Then I searched the rest of the reviewed queue for an item whose ID did show up in the sales rows. One did. It got its own approval and records, and its check also said zero.
Same ID, wrong drawer
This time the ID was there, in both copies, filed under the wrong connection in each. So the second copy was no way out. The proposal step suggested a connection alias, called it safe to review with medium confidence, and created nothing.
Review, rehearse, then write
The review takes accept, reject, or needs more evidence. An accept only counts if the proposal holds up, and it covers a rerun only, not a write.
The rerun applies the alias in memory and counts.
It counts the matching rows under the old connection and under the new one, and it is ready only when the count goes from zero to one.
Zero before, one after. Nothing was saved, so nothing needed undoing.
The real write needed a separate sign-off. It re-checked everything, wrote one sales fact, then proved two things:
- sending the same command again didn't make a second row;
- sending a different payload under the same key was refused.
The fact keeps a note that an alias was used. The alias itself was never saved.
The test that isn't there yet
The rerun has no test that feeds it two matching rows and checks that it blocks. Reading the code, it looks like it blocks on that. I'd still want the test before reusing this anywhere.