data-schema-design

# Data Schema Design This skill assumes PostgreSQL (including Supabase's PostgreSQL). For other databases, adapt the specifics but the principles transfer. ## Fail-Fast Rule If a migration could cause data loss, **stop and require explicit confirmation**. Never drop columns or tables without a backup plan. Never alter enum types in a way that invalidates existing rows. Never run destructive DDL in production without testing on a branch first. ## Cardinal Rule **Every table in production must have a DDL file in the `sql/` directory.** If a table exists in the database but has no DDL, it is undocumented technical debt. Schema-as-code is the only way to recover from disaster. Audit periodically to catch drift between production and the `sql/` directory. ## Audit Baseline: Current State ### Existing DDL Files (sql/ directory) | File | Tables Covered | |------|---------------| | `core_tables.sql` | Foundational domain tables for the project | | `billing_tables.sql` | Billing / subscription / webhook audit tables | | `external_data_tables.sql` | Tables for ingested third-party data | | `retention_policies.sql` | `run_retention_cleanup()` function | | `retention_summary_tables.sql` | Daily summary / rollup tables | | `security_fixes.sql` | RLS/function fixes (no new tables) | | `rls_fixes.sql` | RLS policy fixes (no new tables) | ### Tables WITHOUT DDL (missing — identified in audit) Run the audit query (see *Disaster Recovery*) to list tables in production that have no co...