refactor(db): migrate application checklist

Move workflow checklist state into an additive provider-aware migration. Preserve system-key idempotency, manual progress, ordering, and application cascade semantics.
This commit is contained in:
cesnimda
2026-08-30 18:52:08 +02:00
parent ae57d1afde
commit e933409698
9 changed files with 165 additions and 63 deletions
+6 -2
View File
@@ -35,6 +35,8 @@ cohesive table groups. It does not attempt to delete the legacy reconciler whole
retaining public slugs, builder settings, and job-link/version retention semantics.
- Added `20260830129000_AdoptAiInteractionSchema` to take ownership from both the startup reconciler
and historical compatibility bootstrap while retaining append-only results and usage counters.
- Added `20260830130000_AdoptApplicationChecklistSchema` for application workflow state, retaining
stable system keys, manual steps, completion state, and user ordering.
- Corrected the ownership runbook: new tables now default to migrations; the reconciler is legacy
compatibility code to retire one dependency group at a time.
@@ -68,14 +70,16 @@ migration.
its job clears only the optional link, while deleting the CV cascades through its revisions.
- A representative AI result, mode, provider, and usage counts survive adoption, downgrade, and
re-upgrade; deleting the parent application still cascades through its interaction history.
- Representative system-generated and manual checklist steps survive adoption, downgrade, and
re-upgrade; deleting the parent application still cascades through its workflow items.
- Generated MariaDB SQL contains the provider-correct `SystemEmailSettings` DDL.
- Full backend: 731/731 passed after the AI interaction history transfer.
- Full backend: 732/732 passed after the application checklist transfer.
- Fresh application startup over a new disposable SQLite database applied
`20260830120000_AdoptSystemEmailSettingsSchema` and reached the healthy listening state.
## Remaining JT-019 work
Eighteen model tables remain startup-created, including the Identity group and several tables
Seventeen 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.