stela ops usage fixes roles propagation and timoeut, one account to support multi tenants, migrations consolidation, search to support documentation, doctor and open api vector db search

docs/db/MIGRATION_CONVENTIONS.md

@@ -2,6 +2,42 @@
 
 This document defines the standard conventions for database migrations in StellaOps.
 
+## Consolidation Baseline (2026-02-22)
+
+The repository currently contains multiple migration naming styles and execution paths. Use:
+
+- `docs/db/MIGRATION_INVENTORY.md`
+- `docs/db/MIGRATION_CONSOLIDATION_PLAN.md`
+
+as the authoritative current-state baseline while this conventions document defines the target standard.
+
+During the consolidation sprint:
+
+- New migrations must follow this document's naming rules.
+- Legacy folders that do not yet conform are tracked as remediation items, not exceptions to the target standard.
+- Any procedure docs (setup, CLI, compose, upgrade runbooks) must be updated in lockstep with migration mechanism changes.
+
+## Canonical Runner Entrypoint Convention
+
+For release and upgrade operations, the only supported runner entrypoint is the `stella system migrations-*` command group:
+
+```bash
+stella system migrations-status --module all
+stella system migrations-verify --module all
+stella system migrations-run --module all --category release --dry-run
+stella system migrations-run --module all --category release --force
+```
+
+Startup-hosted migration execution is limited to automatic categories (`startup`, `seed`) and must route through the shared startup migration host contract.
+
+## Legacy Compatibility Convention
+
+During consolidation, non-canonical history tables must be adapter-mapped to the canonical `<schema>.schema_migrations` structure without rewriting already-applied migration files.
+
+Current mandatory mappings are tracked in:
+
+- `docs/db/MIGRATION_CONSOLIDATION_PLAN.md` (Legacy Compatibility Mapping table)
+
 ## File Naming
 
 All migration files must follow the naming pattern: