fix(db): repair fresh migration chain
CI and Deploy / test (pull_request) Successful in 5m19s
CI and Deploy / deploy (pull_request) Has been skipped

This commit is contained in:
cesnimda
2026-08-15 20:47:36 +02:00
parent 191de69c48
commit 74a1e0d845
15 changed files with 297 additions and 35 deletions
@@ -45,6 +45,6 @@ The exact isolated API process was stopped and port 5303 was confirmed closed. L
## Limitations
- Browser localhost access remains denied by the in-app browser administrator policy; no browser claim is made.
- No MariaDB server was available. Pomelo SQL generation passed, but execution awaits a disposable or production-safe MariaDB smoke.
- Direct `dotnet ef database update` against a completely blank SQLite file still fails in the pre-existing reconciler-owned schema gap at `AddJobEntityAndProspectStages`. The documented application startup path succeeds because the reconciler establishes those columns before migrations. This is JT-019 schema-ownership debt, not the JT-003 query defect, and historical migrations were not changed.
- Disposable MariaDB 11.8 execution now passes for a fresh application start and restart with all 29 migrations and 49 tables. Production MariaDB execution remains unverified.
- Direct `dotnet ef database update` against a blank SQLite file now reaches the latest migration and is idempotent. A populated older checkpoint preserves its job data through the same chain, and real application startup over the EF-only database serves `/health` (V-186). The broader migration/reconciler dual-ownership architecture remains JT-019 debt.
- Execution policy denied deletion of the exact disposable nested data directory; it is stopped and recorded in the session handoff.