Mindbridge · track status

REGINA-STAGING-GATE

Regina's full-fidelity SAP staging and its gated drain — the staging DB is pivoting Postgres → SQL Server (SAP has no PG DBSL), and the one labelled defect is a latent repeat with zero prod rows.

Re-measured 2026-08-16 from gh issue list + gh pr view. This page has never been published — publish fresh per docs/status/artifacts.json. Verify before starting: issue and PR state decay on every open/close — re-run the gh queries first.

Next → Decision — the owed handoff document + connector ADR: now drafted as PR #2814, the Postgres → SQL Server pivot (SAP has no PG DBSL). Code — #2875: the Exchange/Slack drain fix, a latent repeat behind the gate.

1 open issue (latent Exchange/Slack drain) · 1 open PR (staging pivot Postgres → SQL Server) · staging box needs re-provisioning before real data

1open issues

0Exchange runs · 14d

0Slack runs · 14d

Open work

The gate — handoff + connector ADR (the decision)

#2814 docs(ops): pivot Regina SAP staging from Postgres to SQL Server (SAP has no PG DBSL) the gate decision, drafted Enterprise

SAP ships a native DBSL only for SQL Server, Oracle, DB2 — none for PostgreSQL (SAP Note 1082356), so the merged guide's DBCON-into-Postgres path was a dead end. Owner's call: switch the SAP-facing staging DB to SQL Server (the graph side stays Supabase Postgres). This PR renames ADR-133 (…-postgres-connector → …-staging-connector), converts the schema to T-SQL, and updates the handoff doc. Follow-on: the box, still on the superseded Postgres, needs re-provisioning with SQL Server before real data.

The code — the one labelled issue

p2 #2875 fix(source): Exchange and Slack live drains write one ingestion_runs row per message latent repeat, zero prod rows Latent

Each staged event opens its own ingestion_runs row — both handlers call ingest() inside a per-event loop with no run_id. A repeat of the Gmail drain bug (#2821, closed/fixed), but latent: the body's own prod census shows zero Exchange and zero Slack rows in the last 14 days — no tenant runs either connector. Port the Gmail fix, with per-source grouping Gmail did not need (Exchange keys on the mailbox's source.name, Slack on channel_source_name(channel)).

Why is it in this order?

Dependency order on the staging gate

Unblock the branch first (handoff + connector ADR), ship the branch next, fix the labelled issue last. The handoff document and connector ADR come first because the track index says the branch does not proceed without them; the single open issue is last because its own body records zero prod rows for both connectors.

What this order ignores: issue age (#2875 is from 2026-07-31, but age does not move it ahead of the gate); priority label alone (p2 is "this quarter", a horizon, not a claim it precedes the gate); and how cheap the fix looks (porting the Gmail fix is a small diff that still does not unblock staging).

Standing rulings

None recorded — track-order.json's decided list for track:regina-staging-gate is empty.

History / forensics

Gmail precedent — #2821 (closed)

The same one-row-per-message defect was fixed in the Gmail incremental drain (#2821, closed). #2875 is the follow-up for Exchange and Slack, split out because both have zero prod rows and fixing them alongside Gmail would have tripled the review surface for no measured benefit.

Prod census — ingestion_runs, last 14 days (from #2875)

source_type	runs	parsed	runs with exactly 1
maildir	14,918	59,698	6,061 (already batched)
gmail	5,320	6,510	5,294 — the bug, fixed by #2821
whatsapp_live	3,046	5,905	2,265 (already batched)
exchange	0	0	0
slack	0	0	0

No tenant currently runs Exchange or Slack — this is a latent repeat, not a live cost.

Staging DB pivot — PR #2814 (open since 2026-07-28)

The staging box is still on the superseded Postgres and needs re-provisioning with SQL Server before real data; SAP ships no DBSL for PostgreSQL, so the staging DB pivots to SQL Server, and the graph side stays Supabase Postgres.