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/operations/devops/runbooks/deployment-upgrade.md

@@ -103,15 +103,38 @@ Infrastructure components (PostgreSQL, Valkey, RustFS) are pinned in the release
      -f devops/compose/docker-compose.prod.yaml \
      up -d
    ```
-4. Tail logs for critical services (`docker compose logs -f authority concelier`).
-5. Update monitoring dashboards/alerts to confirm normal operation.
+4. Run migration status and verification checks:
+   ```bash
+   stella system migrations-status --module all
+   stella system migrations-verify --module all
+   stella system migrations-run --module all --category release --dry-run
+   ```
+5. Execute release migrations when approved:
+   ```bash
+   stella system migrations-run --module all --category release --force
+   stella system migrations-status --module all
+   ```
+6. Tail logs for critical services (`docker compose logs -f authority concelier`).
+7. Update monitoring dashboards/alerts to confirm normal operation.
+
+Migration notes:
+
+- Compose PostgreSQL init scripts in `devops/compose/postgres-init` are first-initialization only.
+- CLI module coverage is currently limited; consult `docs/db/MIGRATION_INVENTORY.md` before production upgrades.
+- Consolidation target policy and cutover waves are documented in `docs/db/MIGRATION_CONSOLIDATION_PLAN.md`.
+- For upgradeable on-prem installations, the `stella system migrations-*` sequence is the required release migration gate.
+- UI-driven migration execution must call Platform admin APIs (`/api/v1/admin/migrations/*`) and not connect directly from browser to PostgreSQL.
 
 ### Rollback (Compose)
 
 1. Check out the previous release tag (e.g. `git checkout 2025.09.1`).
-2. Re-run `docker compose pull` and `docker compose up -d` with that profile. Docker will restore the prior digests.
-3. If reverting to a known-good snapshot is required, restore volume backups (see `docs/modules/authority/operations/backup-restore.md` and associated service guides).
-4. Log the rollback in the operations journal.
+2. Capture migration state before rollback:
+   ```bash
+   stella system migrations-status --module all
+   ```
+3. Re-run `docker compose pull` and `docker compose up -d` with that profile. Docker will restore the prior digests.
+4. If schema incompatibility is detected, restore known-good database snapshots before service restart (see `docs/modules/authority/operations/backup-restore.md` and associated service guides).
+5. Re-check migration status and log rollback actions in the operations journal.
 
 ---
 

docs/operations/upgrade-runbook.md

@@ -122,26 +122,37 @@ kubectl get pods -n stellaops-green -w
 ### Run Migrations
 
 ```bash
-# Step 16: Apply Category A migrations (startup)
+# Step 16: Check current migration state (CLI-registered modules)
+stella system migrations-status --module all
+
+# Step 17: Verify checksums before execution
+stella system migrations-verify --module all
+
+# Step 18: Preview release migrations (manual gate)
 stella system migrations-run \
-  --category A \
-  --namespace stellaops-green
+  --module all \
+  --category release \
+  --dry-run
 
-# Step 17: Verify migration success
-stella system migrations-status --namespace stellaops-green
-# All migrations should show "Applied"
-
-# Step 18: Apply Category B migrations if needed (manual)
-# Review migration list first
-stella system migrations-pending --category B
-
-# Apply after review
+# Step 19: Execute approved release migrations
 stella system migrations-run \
-  --category B \
-  --namespace stellaops-green \
-  --confirm
+  --module all \
+  --category release \
+  --force
+
+# Step 20: Verify migration success
+stella system migrations-status --module all
 ```
 
+Migration notes:
+
+- Category names are `startup`, `release`, `seed`, and `data`.
+- Compose and service startup paths may apply additional migrations outside CLI coverage.
+- Use `docs/db/MIGRATION_INVENTORY.md` for current module-by-module runner coverage before production upgrade.
+- Canonical consolidation policy and wave plan are in `docs/db/MIGRATION_CONSOLIDATION_PLAN.md`.
+- For upgradeable on-prem environments, treat this CLI sequence as the required release migration gate.
+- UI-triggered migration operations must execute through Platform admin APIs (`/api/v1/admin/migrations/*`) with `platform.setup.admin` (no browser-direct PostgreSQL access).
+
 ### Evidence Migration (If Required)
 
 ```bash