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). - **Commit a Mermaid `erDiagram` with every schema design/change** — inside the schema/migration doc so it renders in review, per the shared convention's ER section (`${CLAUDE_PLUGIN_ROOT}/skills/_shared/c4-mermaid-convention.md`): singular UpperCamel entities, `PK`/`FK`/`UK` marks, verb-labeled relationship