fix(db): repair fresh migration chain
This commit is contained in:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user