postgres-schema-designlisted

# Invariant-First PostgreSQL Schema Design A schema is an executable model of business invariants: `language -> invariants -> dependencies -> relations -> constraints -> scenarios` Model correctness before physical optimization. Start normalized; make every denormalization name its source of truth, synchronization mechanism, repair path, and measured reason. ## Request and authority contract Before modeling, establish the requested outcome, schema boundary, work mode (design, review, or implementation), target PostgreSQL version when relevant, available evidence, and success criteria. Distinguish confirmed rules from inferences and assumptions; surface the distinctions that affect the design. - For design, review, or planning requests, inspect available product contracts, code, schemas, migrations, queries, and tests; preserve database and repository state. - For build or change requests, edit canonical migrations, schema definitions, models, and tests within the supplied repository, then run non-destructive validation. - Treat production DDL, backfills, data repair, constraint validation, and migration execution as separate production actions requiring explicit authority. Ask a question when two plausible business meanings produce materially different identities, ownership, cardinalities, retention, money, or time semantics. Otherwise proceed with explicit assumptions. Finish when the applicable completion criteria below are satisfied and the requested artifact is de