fc81df14e4
Every pull was a full snapshot, so a shop with a thousand products re-sent all of them to correct one price. The response now carries a revision the terminal stores and hands back, and a pull that supplies one gets only what moved: the product row, its row at that outlet, or its stock ledger. Stock is included because a shop's count drifts from a till's on every sale rung at another counter, and a delta that ignored it would let that drift persist until someone forced a full pull. The dangerous part is the flag, not the filter. A response marked is_delta:false tells the terminal to withdraw every product it does not mention — so a filtered result carrying that label empties the shelf. Both are now derived from one value, and there is no path through the function that filters without also setting the flag. Everything ambiguous resolves toward the snapshot. A revision that is malformed, empty, or issued to another outlet yields a zero cutoff and a complete response; the opposite would leave a terminal permanently missing changes with nothing to show for it. The revision advances only on the final page, so a terminal that abandons a paginated pull cannot end up holding one that claims it saw pages it never received. And the stamp is taken a second in the past, because a product written during the same second the query ran would otherwise fall on the wrong side of the next cutoff and be skipped for good. A delta still cannot withdraw a deleted product — removing a row from productlocations leaves no tombstone — so a periodic pull without a revision is what collects those. Verified against the live outlet: a full pull of 12, a delta returning only the one product whose price had changed, and pagination that stays exact now that productid <= 0 is excluded in SQL rather than after the LIMIT. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>