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

JT-019 schema ownership — incremental migration transfers

Scope

This work establishes a behaviour-preserving ownership boundary and moves small independent or cohesive table groups. 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.
• Added 20260830121000_AdoptUserRuleSettingsSchema and removed both provider startup-create paths for the independent per-user rule-settings table.
• Added 20260830122000_AdoptGmailReviewDecisionsSchema, removed the SQLite startup-create path, and supplied the previously absent MariaDB table definition.
• Added 20260830123000_AdoptAuthenticationSupportSchema for recovery codes, trusted devices, and revocable user sessions; both provider startup-create paths are removed while guarded MariaDB repair checks remain for historical schemas.
• 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.
• A representative per-user rules row survives adoption, downgrade, and re-upgrade.
• A representative Gmail review decision survives adoption, downgrade, and re-upgrade.
• Representative recovery-code, trusted-device, and user-session rows survive adoption, downgrade, and re-upgrade, and their indexes are present afterwards.
• Generated MariaDB SQL contains the provider-correct SystemEmailSettings DDL.
• Full backend: 725/725 passed after the authentication-support transfer.
• Fresh application startup over a new disposable SQLite database applied 20260830120000_AdoptSystemEmailSettingsSchema and reached the healthy listening state.

Remaining JT-019 work

Twenty-nine 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.