jobtrackingapp/docs/verification/jt-019-schema-ownership.md

JT-019 schema ownership — first migration-backed transfer

Scope

This increment establishes a behaviour-preserving ownership boundary and moves one independent table. It does not attempt to delete the legacy reconciler wholesale.

Implemented

• Added StartupSchemaOwnership, classifying all 49 EF model tables into disjoint migration-owned and reconciler-owned creation sets.
• Added a regression that fails when a model table is unclassified, multiply classified, or when a compatibility bootstrap is incorrectly treated as migration ownership.
• Added 20260830120000_AdoptSystemEmailSettingsSchema, with provider-aware additive DDL for SQLite and MariaDB/MySQL.
• Removed the MariaDB startup CREATE TABLE block for SystemEmailSettings and moved the table to the migration-owned set.
• Corrected the ownership runbook: new tables now default to migrations; the reconciler is legacy compatibility code to retire one dependency group at a time.

Data compatibility

The migration uses CREATE TABLE IF NOT EXISTS. Existing MariaDB installations keep their table and rows; SQLite installations that never received the reconciler-only table now receive it. Down is intentionally non-destructive because it cannot determine whether the existing table predates this migration.

Proof

• Ownership and migration-chain focused suite: 6/6 passed.
• Blank SQLite chain applies all migrations twice and creates all ten expected SystemEmailSettings columns.
• A database stopped immediately before the adoption migration, seeded with a representative SMTP settings row, upgrades without changing that row.
• Generated MariaDB SQL contains the provider-correct SystemEmailSettings DDL.
• Full backend: 722/722 passed.
• Fresh application startup over a new disposable SQLite database applied 20260830120000_AdoptSystemEmailSettingsSchema and reached the healthy listening state.

Remaining JT-019 work

Thirty-four model tables remain startup-created, including the Identity group and several tables with parent dependencies. Transfer them in small dependency-aware migrations with blank, populated, retry and MariaDB runtime proof. Column/index repairs must remain until historical upgrade fixtures prove each one redundant.