All packsMulti-Tenant Auth & RBAC CoreSolve
postgres rls policy infinite recursion membership subquery
A membership check inside its own table's policy recurses
A naive RLS policy on org_members that subqueries org_members to check membership triggers infinite recursion the moment Postgres tries to evaluate it.
This is one of the things Multi-Tenant Auth & RBAC Core already handles. Sign-in, organisations, invites and roles — with one customer's data provably unable to reach another's.
Is this you?
Checking "is this user a member of this org" by writing a policy on org_members that itself queries org_members to answer the question creates a circular evaluation: Postgres has to apply the policy to check the policy. Depending on the exact shape, this either errors outright or silently degrades into a much more expensive query plan than anyone intended.
Why this one is easy to get wrong
The subquery is the obvious, direct translation of the English rule ("check the membership table") into SQL, and it's the kind of policy that looks correct on paper and in a quick manual test with one org and one user, before the recursive evaluation cost or the outright recursion error shows up under a slightly more realistic policy shape.
What you get instead
Core decision 6 routes the membership check through a SECURITY DEFINER helper function (is_org_member, running as the table owner, exempt from the policy it's being called from) instead of a subquery inside the policy itself. The same decision keeps org_members at RLS ENABLE (not FORCE) specifically so this definer function -- which the owner-exemption trick depends on -- keeps working on managed Postgres where the owner isn't a superuser.
Source: ARCHITECTURE.md core decision 6 — checkable in the pack you receive
How you actually use this
You don’t install a library or wire up an SDK. Your own coding agent builds the code in your project, and you keep it — no runtime dependency on us.
Step 1
Download and unzip
You get a folder: the docs that tell an agent what to build, a starting skeleton, and the test suite that decides when it's done.
Step 2
Open it in Claude Code or Cursor
Point your coding agent at the folder. Nothing to install, no account with us, no API key.
Step 3
Paste one prompt
The pack contains the exact prompt. Paste it as your first message and leave it alone — it works through the build itself, choosing a cheaper or stronger model per task.
Step 4
Run ./verify.sh
One command. It prints a pass or fail for every check. Green means the build is done — the same script we ran to produce the receipt on this page.
Typical build: about 12 minutes of your agent working, mostly unattended. Then you integrate the working module into your app the way you would any code you’d written yourself.
Why you can believe this
2 of 3 runs passedWe ran this pack from an empty folder 3 times and published exactly what happened — every check, the model, the token cost, the wall time. Not a testimonial, and not our opinion: the same verify.sh you run yourself. Read the full receipt →