Mindbridge ยท track status

RETENTION

Deletion is promised in customer copy, and no tenant-wide deleter exists.

Measured 2026-08-16 from live gh issue list. This page has never been published โ€” verify against gh before starting on anything here.

Next โ†’ #2944 โ€” connector-scoped deletion over-deletes merged nodes, in the only deleter that exists and runs today.
3 open โ€” the over-deletion defect in the one deleter that exists, the resumability gap in the tenant-wide deleter that does not, and the silent dead-sweep on the 30-day promise.
72FK'd tables to teardown
30tenant_id tables, no FK
8stranded tenants, stage 4
30day deletion promise
Open work Why this order Rulings History

Open work

The deleter that exists โ€” over-deletion
p2 #2944 ADR-138 stage 4: connector-scoped deletion over-deletes merged graph nodes and relies on a self-heal that stranded tenants may never get over-deletes nodes shared with survivors Enterprise
A connector-scoped delete can destroy a graph node that also touches a surviving person โ€” correctness depends on enrichment running again for that tenant. Stage 4's targets are the 8 stranded tenants, the population least likely to have active enrichment, because nothing drives ingestion for a dead connector; the self-heal is a promise about a future enrich pass that may never come. Close it by confirming an enrichment path per tenant before each delete, or by making _delete_graph spare cross-connector-merged nodes outright (the equivalent of find_gone_person_ids for identities).
The deleter that does not exist โ€” resumability
p1 #2941 ADR-138 stage 6: the tenant-wide deleter has no resumability design for a partial failure across 72 FK'd tables no resume after partial teardown Latent
Nothing states what happens when the highest-blast-radius code in the product dies halfway: one transaction risks statement timeout and IO-budget exhaustion; many need resumption tracking that is not named. A first attempt that deletes rows and then dies leaves a retry with no storage keys to act on โ€” the files are orphaned a second, independent way, via retry not ordering. Resumability and the storage harvest are the same problem: the harvested key list must outlive the deleting transaction. Close it with a durable harvest artifact keyed by run id, a resume path that reads the harvest not the substrate, and a real-DB test that kills the deleter mid-run and resumes it.
The sweep that enforces the promise โ€” dead-sweep detection
p1 #2942 ADR-138: no dead-sweep detection โ€” D6's CI gate catches 'never scheduled', not 'scheduled and silently stopped working' scheduled sweep can silently stop Latent
D6's CI gate diffs declared policy against the live cron.job table โ€” it catches 'never scheduled', not 'scheduled and silently stopped working'. A swallowed exception, a permission error, or a column rename leaves cron.job reading active and CI green. The 30-day lifecycle sweep is worse: the entire customer-facing '30 days' promise depends on it firing. Close it with a last-successful-run watermark per policy, written by the job itself and only on success โ€” a job that runs and throws must not advance it โ€” plus a staleness alert surfaced where an operator sees it.
Why is it in this order?

Destruction-first: what each defect can destroy if left alone. Of ADR-138's two deleters, the connector-scoped one (stage 4) exists and runs today; the tenant-wide one (stage 6) does not. So the over-deletion defect in the deleter that exists comes first (#2944), the unbuilt deleter's resumability design second (#2941), and the dead-sweep detector third (#2942).

What it ignores: priority labels (#2944 is p2 and sits first), filing order and age (all three filed 2026-08-01 within the same minute), how cheap a fix looks, and the 30-day promise as an urgency lever โ€” the standing ruling that manual deletion suffices today means the promise alone does not pull the sweep detector up.

Standing rulings

History & forensics

ADR-138 merged 2026-08-01 (PR #2871, commit 3d1aae2b2) โ€” the retention-and-deletion policy. Its four-lens adversarial review produced the three open issues above, each blocking a stage of the program, all filed 2026-08-01 within the same minute.