Kanishq Sharma

I'm building Rewind for recovery of captured Supabase updates. One documentation addition I'd suggest: `no-rows` can also mean that an expected-version filter correctly rejected a stale edit, even when the row exists and the caller has access. A disposable test case: 1. Read the same owned row into two clients at version 5. 2. Client A updates it with both ID and version 5 in the filter, advancing the version to 6 in that same UPDATE. 3. Client B tries its old version-5 update and requests the affected rows. Expect an empty result; independently read the row and verify A's values remain. Every writer must advance the revision for this contract to hold. The empty result alone cannot distinguish stale revision, missing row and RLS filtering. I'd keep the generic `no-rows` result, add predicate mismatch to its explanation, and let the application's context choose the message. Don't automatically retry after removing the version filter. This is a proposed test case, not a claim that I've run your package. [PostgreSQL's Read Committed documentation](https://www.postgresql.org/docs/current/transaction-iso.html#XACT-READ-COMMITTED) explains the WHERE recheck behind it.