Deployment index safety
2026-09-15 — staging application deployed; gates remain off
The approved cb73cee application revision deployed through run34938027728. The ordinary staging fast-forward preserved concurrent work. Additive reconciliation verified 232 contracts and created zero indexes. ECS settled on revision 163, image digest a84bcad9c82bc736fe236a064f3b4574aae45eedd3b051493316682c46de8bb4; the public health endpoint returned200/statusok. The 06:56:13 UTC full-schema check found no missing indexes, blockers, duplicates, parallel arrays or changes from the reviewed migration state.
Direct task-descriptor parsing confirms private runs and KMS epoch migration are both explicitly false on163, with private origins absent. Revision162 explicitly had KMS migrationfalse and private flags absent/defaultoff; an earlier empty nested-query projection was ambiguous and is not retained as evidence. No production deployment or private-run enablement occurred. Sanitized deployment/flags/health/index receipt.
Reviewed staging index migration
PR490 merged at cb73cee after independent review and full CI on cb9761f. The explicitly scoped staging migration completed: two canonical Bindr indexes created and verified; only Bindr_projectNodeId_name_key dropped. Full-schema verification at 06:35:22 UTC found all 232 contracts satisfied, zero additions/blockers/duplicate groups/parallel arrays, and no index differences outside the three reviewed changes. Staging remained on task revision162/source cd490e0; no application deployment or production database mutation occurred.
Sanitized before/plan/apply/after receipts include empty active-deployment checks before and after. Those checks and repeated source/index verification are not an atomic lock against external manual DDL. The old manual db:ensure-indexes / Source reset helper still drops historical Source indexes and was not invoked. Source/Connection container startup verifies only; it does not call that helper.
Earlier inventory and implementation boundary
Tracks Vault #241, staging reconciliation #387 and master #247. Reconciliation PR481 merged; this follow-up replaces unconditional deployment schema push and destructive index repair with explicit index planning and additive application. It preserves concurrent Env/Tasks changes.
A read-only inventory of settled staging revision 162, source cd490e0, checked all 87 schema collections / 232 index contracts. No duplicate groups or parallel-array blockers were found. Two canonical Bindr indexes need adding, and the older Bindr_projectNodeId_name_key conflicts with retired-name reuse. The generic synchronizer refuses this extra unique constraint; it never silently drops or repairs it. This is staging evidence, not a production inventory or a deployment claim.
The separate Bindr migration pins the reviewed database fingerprint, task definition, source digest and plan hash. It checks exact old-index metadata, creates and verifies the canonical unique (projectNodeId, name, deletedAt) and nonunique parentId indexes, then drops only the exact old constraint. Unfamiliar metadata or data refuses mutation. Stop concurrent deployment/index writers for this explicit operation: MongoDB's name-based drop cannot atomically compare the previously inspected index metadata.
Operator commands
Run from dreamlake-server. The inventory reads the current settled ECS task's connection privately; it emits index metadata and aggregate counts only. Credentials never appear in arguments or receipts.
Do not reuse a stale receipt after another rollout or index change. A failed or interrupted operation may already have created an index or completed the drop; obtain a fresh inventory and migration plan to resolve the outcome. Repeating a freshly planned completed migration is a no-op. There is no automatic rollback, broad drop, data cleanup or whole-schema push.
Failed workflow preflight retains the sanitized index plan as a seven-day CI artifact: schema index metadata and aggregate counts, with no document values, tenant names or connection credentials. Private-run configuration is forwarded without enabling it: DREAMLAKE_VAULT_PRIVATE_RUNS_ENABLED defaults to false; unset API/repository origins are omitted, and supplied values retain JSON escaping and fail-closed bootstrap validation.
The normal workflow independently checks its configured database against the settled ECS database, validates all expected constraints before creating any, and binds apply to the structural plan hash. Equivalent index names are retained. Unique constraints and TTL indexes affect writes and retention, so additive does not mean behavior-free or atomic; races or build failures can leave acknowledged additions.
Validation and remaining work
Forty focused tests passed across four suites, including owned real Mongo, complete-schema CLI application, idempotence, target/hash refusal, malformed/duplicate data, partial-index semantics, replacement failure, fresh-plan restart and retired-name reuse. Typecheck passed. The reviewed staging index migration and full-schema post-check are now complete. Staging application rollout, health, actual disabled flags and full-schema verification are complete. Private-run enablement and authenticated hosted feature acceptance remain separate gates; no production database changes are claimed.
Full sanitized inventory · Read-only Bindr plan · Remote delivery evidence.