debug-tenantlisted

# debug-tenant ## Premise Find the real leak, not a plausible one. Every step cites the actual value observed (header, resolved id, session GUC, connection, SQL, cache key) at `<file:line>`. "Probably the cache" is not a root cause. Tenant leaks are security incidents and the report must name the file:line — or the session state — that produced the leaked SQL or cache key. **There is no single chain. There are four, and Step 0 picks which one you walk.** Application-level filtering, Postgres RLS, schema-per-tenant and database-per-tenant fail in entirely different places, and the verdict that is correct for one is a false positive on the others — most sharply, "the SQL has no tenant filter" is *the bug* under app-level filtering and *the expected shape* under RLS. Walk the selected chain top-to-bottom; skipping a hop on a guess is forbidden. A "fixed" leak without a regression test that would have caught it is unfinished work. ## When to invoke - Customer reports: "I see products I don't own" / "my orders are missing" - Audit finds cross-tenant data in a response - Cache returns data from tenant B to tenant A ## Steps ### 0. Identify the isolation mechanism — before anything else The rest of this playbook branches here. Establish which mechanism this project uses (one grep each; a project may use more than one, in which case walk each): | Mechanism | How to confirm it | Chain to walk | |---|---|---| | **Application-level filtering** | a repository base class / query