Estimate: 13m · Depends on: 1.2.3, 1.2.6
The load-bearing test that validates the Story-level AC's "structurally impossible" claim. Two layers, mirroring the two defense layers from 1.2.3: (1) E2E test via Playwright that signs in as user A in workspace A, tries to access workspace B (via URL manipulation, cookie tampering, forged headers), and asserts every path returns 404; (2) Direct-DB integration test via Vitest that opens a Prisma transaction WITHOUT setting the app.workspace_id GUC and tries to SELECT / UPDATE rows from workspace-scoped tables, asserting RLS denies everything.
Why both layers, not just one: E2E proves the middleware handles every legitimate-looking attack vector; direct-DB proves RLS catches a middleware bug. If only the E2E existed, a future Subtask could disable the middleware (or forget to wrap a new endpoint in withWorkspaceContext) and the test wouldn't catch it — the test would just stop firing in the right code path. The direct-DB test guarantees that even if 100% of the application code were wrong, the database would still refuse to leak.
Why 404 (not 403) for cross-workspace access: 403 leaks the workspace's existence to the attacker ("this workspace exists, you're just not in it"). 404 makes a non-member workspace indistinguishable from a non-existent one. Standard B2B SaaS practice (GitHub, Linear, Notion all return 404 for cross-tenant access).
What you'll do: Create tests/e2e/multi-tenant-isolation.spec.ts (tagged @smoke) that: (a) creates two workspaces (A via sign-up, B via invite to a second user); (b) as user A, attempts to GET /api/workspaces/{B.id}/invites, PATCH workspace B, leave workspace B, delete workspace B — assert 404 on all; (c) attempts to read workspace B's data by forging the workspace_id cookie value — assert the middleware re-validates membership and returns 404. Create tests/multi-tenant-rls.test.ts (Vitest) that opens db.$transaction without withWorkspaceContext and asserts SELECT returns zero rows from workspace and workspace_membership tables; that an INSERT into workspace_membership for a workspace the GUC doesn't grant access to fails with a Postgres RLS error; that an UPDATE to a workspace not matching the GUC affects zero rows. Run the cascade-delete portion of the test by creating a workspace with a membership, deleting the workspace, asserting the membership row is also gone.
tests/e2e/multi-tenant-isolation.spec.ts exists and is tagged @smoke; passes locally and in CI.tests/multi-tenant-rls.test.ts exists; passes locally and in CI.tests/e2e/auth-credentials.spec.ts + auth-google.spec.ts from 1.1.7 — the E2E patterns for sign-up + sign-in + DB assertiontests/password-reset.test.ts from 1.1.6 — the Vitest pattern for testing Better-Auth handler routes directly (this Subtask uses the same approach for the workspace API routes)lib/workspaces/{context,middleware}.ts from 1.2.3 — the gates being tested42501 insufficient_privilege for denied mutations, 0 rows affected for denied reads — both are valid RLS-denial signals depending on the query)