Public blueprint · No client repository or production data

Supabase staging and CI that can be reproduced from zero

A paid staging trial should prove more than “the second project runs.” It should show that migrations, safe data, application builds and integrity checks can be replayed by another engineer without production credentials.

The acceptance boundary

Production remains untouched. The trial receives repository code, documented environment-variable names and non-sensitive test fixtures. It creates a new Supabase project, replays migrations in order and reports every assumption that prevents a clean bootstrap.

Phase 1: inventory before mutation

• Map applications, package managers, build commands and supported runtime versions.
• List migration files and identify manual dashboard changes or missing history.
• Classify environment variables as public configuration, server-only secret or production-only dependency.
• Record database extensions, scheduled jobs, storage buckets and external webhooks.
• Write the expected role, customer and site ownership graph before changing RLS.

Phase 2: deterministic staging bootstrap

1. Create an empty staging project
2. Apply repository migrations in timestamp order
3. Verify extensions, functions, triggers and policies
4. Seed synthetic organizations, sites, roles and users
5. Build each application against staging configuration
6. Run integrity and authorization test matrices
7. Destroy and replay once to prove reproducibility

A copied production database is not the default. Synthetic fixtures are safer, smaller and easier to reason about. If realistic distributions are required, the cleaning process must be irreversible, documented and reviewed before any export.

Pull-request quality gates

GitHub Actions outline

pull_request:
  install -> lint -> typecheck -> build
  start isolated Postgres/Supabase test services
  replay migrations from an empty state
  load synthetic fixtures
  run integrity tests
  run RLS role x customer x site matrix
  archive safe test reports (never secrets or database dumps)

Secrets use repository environments with least privilege. Pull requests from untrusted forks do not receive staging credentials. Logs must not print tokens, connection strings, service-role keys or fixture passwords.

RLS changes come after the test matrix

Replacing “authenticated users can access everything” with new policies before defining allowed and forbidden paths risks both leakage and accidental outage. For each protected object, verify anonymous, same-user, same-site, same-customer, cross-site, cross-customer and privileged-service paths.

Trial deliverables

1. Staging bootstrap instructions that work from a clean environment.
2. A migration-drift and undocumented-dependency report.
3. Synthetic seed fixtures with no production or personal data.
4. Pull-request CI for builds and the existing integrity suite.
5. A proposed RLS regression matrix, without silently rewriting policies.
6. A short backlog ranked by production risk and dependency order.

Evidence and limits

This is a reference blueprint, not a claim that it has already been installed in a client repository. The public RLS isolation fixture demonstrates the forbidden/legitimate-path testing pattern used here.

Related: membership SaaS architecture, RLS testing guide and Supabase RLS audit scope.