DR-085 — Supabase branches never inherit parent API config; every branch-provisioning path mirrors it explicitly

Status: accepted · S484 (empirically proven, run 29580754072) · amended S499 (held behind id-368 since S494; applied when the {365.5} cutover landed)

Programmatically-created Supabase branches must be treated as if they inherit NOTHING from the parent’s API config: inheritance is nondeterministic across runs — S484 probes were born with DEFAULT PostgREST exposed-schemas (public,graphql_public); the S497 CLI probe (guqejgcmmueolrnwrnem) did inherit the parent’s db_schema: "api" and TOTP-on — the lucky direction, same rule: never rely on it. Every branch-provisioning path MUST explicitly mirror the supabase/config.toml [api] values. The same born-with-defaults class applies to Auth feature flags and DDL replay ({128.10}).

Scope narrowed at the {365.5} cutover (DR-096): the amendment’s main consumer — scripts/e2e-ephemeral-branch.ts, mirror-postgrest leg included — is retired wholesale; E2E runs on the local stack where config.toml is deterministically authoritative. This ruling now governs ad-hoc API/CLI-created branches only (the GitHub-integration git-PR lane gets [api] natively via its Configure step). id-347 further reduced the blast radius from a data-exposure risk to a provisioning-parity rule. Cross-reference DR-096 for the substrate ruling — not restated here.