Turn access claims into falsifiable tests

First, build a mental model

An access claim is a matrix of allowed and denied cases. A useful test tries to break one invariant and checks both the response and the resulting data.

1. Keep fixture setup separate from the tested actor. A privileged client may create synthetic test data but must not perform the supposedly ordinary-user request.
2. Test SELECT, INSERT, UPDATE and DELETE separately; include foreign IDs, mixed-company references, proposed owner/company changes and missing or stale identity.
3. Assert outcomes precisely: permission error, policy error, filtered empty result, expected row count and unchanged forbidden rows are not interchangeable.
4. The local simulator verifies its own model. Real acceptance needs disposable PostgreSQL/Supabase execution through the intended API/RPC, effective grants/policies and a reviewed candidate.

[
  {"actor":"alice","operation":"SELECT A note","expect":"visible"},
  {"actor":"alice","operation":"SELECT B note","expect":"filtered"},
  {"actor":"guest","operation":"INSERT private note","expect":"denied"},
  {"actor":"alice","operation":"UPDATE A note into B","expect":"denied"},
  {"actor":"alice","operation":"UPDATE B note by ID","expect":"zero affected"},
  {"actor":"alice","operation":"repeat accepted request","expect":"same effect once"}
]

1. Contract

   State expected access independently from the implementation being tested.

2. Adversarial action

   Submit the foreign ID or changed company through the same boundary a real caller uses.

3. Evidence

   Preserve actor, revision, response, affected-row count and the forbidden row's unchanged state.