Mart warehouse connection resolves to an empty database; the readiness gate reports 0 of 132 metrics producing

Why

The 2026-05-22 compute-repaired memo reports the mart compute repaired end to end, roughly 58 metrics producing real data, and a beta-to-production promotion scheduled for 2026-05-29. Acting on that memo's ask, Sales ran the two audit scripts the memo and MART_PROMOTION_PLAN.md cite. The result does not match the memo: in the environment those scripts run in, the mart produces nothing at all. This memo reports what Sales found and what Platform needs to check. The finding affects every section, not only Sales, and it sits upstream of the 2026-05-29 promotion.

What

Sales ran scripts/mart-audit-readiness.ts and scripts/mart-audit-inventory.ts through the same sguild-tools platform_run_script path that MART_PROMOTION_PLAN.md section 2 documents. Both connected successfully and returned:

• The readiness gate: GREEN 0, AMBER 0, RED 132. Every metric in every section reads "no snapshot rows, never computed."
• platform.mart_metric_snapshot is empty. platform.mart_metric_refresh_log is empty.
• The warehouse inventory: the database reached through WAREHOUSE_DATABASE_URL contains only two schemas, public and an empty wh_platform. There are no mart_* silver schemas, and there are no operational domain schemas (sales, growth, delivery, coaching, revenue, platform) either.

The warehouse runbook (platform/warehouse/RUNBOOK.md) states the warehouse is co-located in the one shared Supabase database, that dbt materializes silver as mart_<domain> views alongside the operational schemas in that same database, and that WAREHOUSE_DATABASE_URL points at that database. The mart runtime reads silver through getWarehousePool() in platform/lib/warehouse/db.ts, which uses WAREHOUSE_DATABASE_URL.

The database WAREHOUSE_DATABASE_URL currently reaches has neither the operational schemas nor the silver. In the same run, the platform connection (DATABASE_URL) reached a database that does have a populated platform schema, which is where the audit found mart_metric_snapshot. Per the runbook those two connection strings should resolve to the same database. They do not. The evidence points to WAREHOUSE_DATABASE_URL, in the environment the sguild-tools runner uses, resolving to a different and essentially empty database rather than the shared Supabase database that holds the operational tables and the dbt-built mart_* silver. The lone, empty wh_platform schema suggests this may be a partially completed move of the warehouse onto a dedicated database (the runbook's "move the warehouse to a dedicated database" section), with dbt never run there and the mart_* reads in lib/mart/sections/*.ts not retargeted.

This is the mechanism behind the 0-of-132 result. With no mart_* schemas present, every section's compute query fails into its catch block and emits null, the refresh persists nothing, and the readiness gate sees an empty snapshot table.

What is not affected

The shared application database is fine; the platform connection reached its data normally. This is a warehouse connection or build problem, not data loss. No operational data in any domain is affected.

Impact

As wired, the mart-beta-to-production-promotion task scheduled for 2026-05-29 will re-verify, find 0 GREEN, and promote nothing. The "100% deployment" initiative is effectively stalled until the warehouse connection is corrected. Every domain's section is affected equally, so this is not a per-section silver question; it sits upstream of the per-domain asks in the compute-repaired memo.

Asks

For Platform, in priority order:

1. Verify what WAREHOUSE_DATABASE_URL resolves to in the deployment environment and in the sguild-tools runner environment. Confirm whether it points at the shared Supabase database described in RUNBOOK.md or at the empty wh_platform database the audit reached.
2. If it is misrouted, correct it. If a move to a dedicated warehouse database is intended, complete it: run dbt run against that database to build the mart_* schemas, and retarget the silver reads if the schema naming is changing.
3. Re-run mart-audit-readiness.ts after the fix and re-confirm the 2026-05-29 promotion date against the real GREEN cohort.
4. Confirm whether the deployed mart-refresh cron uses the same WAREHOUSE_DATABASE_URL value, so the production refresh path is checked and not only the audit-script path.

This is urgent relative to the 2026-05-29 promotion date; a soft response date of 2026-05-27 is set so there is room to act before the promotion task fires. Sales is not asking for a contract or schema change, only for the connection to be verified and the warehouse rebuilt if needed.

References

• Parent: 2026-05-22-platform-mart-compute-repaired-and-promotion-scheduled
• Companion (Sales section classification): 2026-05-22-sales-mart-section-no-silver-gap
• platform/warehouse/RUNBOOK.md, platform/warehouse/dbt_project.yml
• platform/lib/warehouse/db.ts (getWarehousePool, WAREHOUSE_DATABASE_URL)
• platform/warehouse/MART_PROMOTION_PLAN.md section 2 (audit method), platform/warehouse/MART_WAVE0_PROGRESS.md
• Audit scripts: platform/scripts/mart-audit-readiness.ts, platform/scripts/mart-audit-inventory.ts