data-engineeringlisted

# Data Engineering — schemas, migrations, pipelines, PII Data is the hardest thing to change safely — a bad migration or a PII leak isn't a rollback away. Design schemas deliberately, make migrations safe and reversible, validate data at boundaries, and treat PII as a first-class constraint (#7). The data layer is part of the foundation. ## Fits in the pipeline - **Stage 6** (`/build`) — the data layer is foundation work (built before the modules that depend on it). Migrations and pipelines are built and tested here. Owned by `data-engineer`. - Any schema change re-enters via `change-propagation` (Stage 9): data model → API → frontend → call sites → tests. ## Schema design - Model from the domain and the module that **owns** the data (single source of truth — ties to `module-architecture`). Right normalization for the access pattern; denormalize deliberately, not accidentally. - Constraints in the schema: keys, foreign keys, NOT NULL, uniqueness, checks — let the database enforce invariants, don't rely on app code alone. - Index for the real query patterns; don't speculatively index everything. - Parameterized access only — never string-concat SQL (#7). ## Migrations — safe and reversible - **Every migration is reversible** (a real down path), or the irreversibility is called out explicitly and coordinated with rollout (`devops-delivery`). - **Expand → migrate → contract** for changes to live data: add the new shape, backfill, switch reads/writes, then remov