stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 2 Releases Wiki Activity

wip: doctor/cli/docs/api to vector db consolidation; api hardening for descriptions, tenant, and scopes; migrations and conversions of all DALs to EF v10

Browse Source
This commit is contained in:
master
2026-02-23 15:30:50 +02:00
parent bd8fee6ed8
commit e746577380
1424 changed files with 81225 additions and 25251 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
docs/db/MIGRATION_CONSOLIDATION_PLAN.md
View File

@@ -19,8 +19,14 @@ Module discovery for this runner is plug-in based:
- One migration module plug-in per web service implementing `src/Platform/__Libraries/StellaOps.Platform.Database/IMigrationModulePlugin.cs`.
- Consolidated module registry auto-discovers plug-ins through `src/Platform/__Libraries/StellaOps.Platform.Database/MigrationModulePluginDiscovery.cs`.
- Each service plug-in may flatten multiple migration sources (assembly + resource prefix) into one service-level runner module.
- Current built-in plug-ins are in `src/Platform/__Libraries/StellaOps.Platform.Database/MigrationModulePlugins.cs`.
- Optional external plug-in directories can be injected with `STELLAOPS_MIGRATION_PLUGIN_DIR` (path-list separated by OS path separator).
- Consolidated execution behavior:
- When `<schema>.schema_migrations` is empty, CLI/API runner paths execute one synthesized per-service migration (`100_consolidated_<service>.sql`) built from the plug-in source set.
- After a successful non-dry-run consolidated execution, legacy per-file history rows are backfilled so future incremental upgrades remain compatible.
- If consolidated history exists but legacy backfill is partially missing, CLI/API runner paths auto-backfill missing legacy rows before source-set execution.
- Therefore, bootstrap execution is one migration per service module, but the resulting history table intentionally retains per-file entries for compatibility.
Canonical history table format is:
@@ -67,6 +73,7 @@ UI/API execution path (implemented):
- Module registry ownership is platform-level: `src/Platform/__Libraries/StellaOps.Platform.Database/MigrationModuleRegistry.cs`.
- UI-triggered migration execution must call Platform WebService administrative APIs (no browser-direct database execution).
- Platform service applies the same consolidated-empty-db behavior as CLI using `MigrationModuleConsolidation`.
- Platform endpoint contract:
- `GET /api/v1/admin/migrations/modules`
- `GET /api/v1/admin/migrations/status?module=<name|all>`
@@ -124,3 +131,17 @@ Exit criteria before EF phase opens:
- One canonical operational entrypoint in runbooks and CI/CD automation.
- Legacy history tables mapped and validated.
- Migration replay determinism proven for clean install and upgrade scenarios.
Gate decision (2026-02-22 UTC): `GO`
- Gate evidence accepted:
- `docs/db/rehearsals/20260222_mgc06_retry_seq_after_fix6/` (clean install + idempotent rerun evidence)
- `docs/db/rehearsals/20260222_mgc06_rollback_retry_seq3/` (sequential rollback/retry rehearsal from partial state)
- EF transition implementation sprint opened:
- `docs/implplan/SPRINT_20260222_062_DOCS_efcore_v10_dapper_transition_phase_gate.md`
Governance boundary for EF phase:
- Migration registry ownership remains platform/infrastructure-owned in `src/Platform/__Libraries/StellaOps.Platform.Database/`.
- Migration execution from UI must continue through Platform migration admin APIs; UI must not execute database operations directly.
- Consolidated migration policy (categories, numbering, checksum/history compatibility) remains authoritative and cannot be relaxed by ORM refactors.