Mindbridge · track status

TEST-TRUTH

Coverage that reads as present and cannot fail — the suite is green about things it never checks: SQL with no real-DB test, fixtures that cannot discriminate, harness leakage.

Counts and priorities measured 2026-08-16 from gh issue list; regenerate prose as the track moves. This page has never been published — verify live state before starting, and publish fresh per docs/status/artifacts.json.

Next →The only p1 and the top p2 have both closed — see History. Top of what remains: #2996 find_or_create's duplicate-key race branch has no real-DB coverage.

13 open — no p1 left; silent-failure coverage holes, then harness leakage and rot; all one defect class: the suite is green about things it never checks.

Open work Why this order Standing rulings

Open work

Silent failure — the suite is green about what it never checks

p2 #2996 find_or_create's duplicate-key race branch (_refetch_after_race) has no real-DB coverage race branch unproven; fails under concurrency Enterprise

The duplicate-key race branch (_refetch_after_race) has zero real-DB coverage — replacing it with an unconditional raise leaves all 8 tests passing, so a regression surfaces only under production concurrency. It is the recovery path for two connector workers materializing the same (tenant_id, node_type, lower(canonical_name)) at once. The fix forces a real DuplicateKeyError against the live unique index rather than mocking it, then asserts find_or_create returns the pre-existing id.

p2 #3004 No real-DB test covers the FTS half of the hybrid RRF for semantic_search / search_messages FTS half of hybrid never exercised All

Nothing exercises the FTS half of the hybrid RRF for semantic_search / search_messages — the two tests that looked like coverage were on the xfail list and never executed, and both were vacuous about the embedding they claimed. A non-vacuous test seeds two rows whose embeddings are equally distant from the query while only one shares lexemes, then asserts the lexeme-matching row is returned and outranks the other.

p2 #3010 test EMOJI_RE diverges from the production pattern in BOTH directions — emoji assertions are narrower than they read emoji test diverges both directions Dev only

The test's own EMOJI_RE diverges from the production stripper in both directions — narrower, so a regression is invisible (flags, ZWJ and zero-width ranges are stripped in production but unasserted), and broader, so a correct run could falsely fail (the test's single span swallows gaps production deliberately leaves). Importing the production pattern would make the assertion self-referential; the fix needs an independently spelled pattern.

p2 #3011 find_or_create_person_by_alias's canonical-name dedup step has zero real-DB coverage — unreachable within a single ingestion run canonical dedup rung structurally dead Enterprise

The canonical-name dedup rung can be fully disabled and all 14 tests still pass — NodeMaterializer calls find_or_create_person_by_alias once per already-deduped canonical name, so within one ingestion run the rung never has a pre-existing row to find. A regression shows up only as silently duplicated people across re-ingestion or multi-source folds. The test shape: ingest twice into the same tenant and assert the person count is unchanged and the ids are the same rows, not new ones.

p2 #3071 debt-ratchet is blind to growth below file_size_fail_loc — a baselined file can grow silently up to the cap gate reports green over growth Dev only

The debt-ratchet iterates current sizes only, so a baselined file below the cap can grow silently — it reported "held or shrank" after 16 lines of real growth. Measured: file_size_fail_loc = 800, and the one baseline entry at or below the cap (a file at 782) has an 18-line silent growth allowance. The fix iterates the union of baseline keys and current sizes, so a baselined file is always compared regardless of where it sits relative to the cap.

Harness leakage, stale artifacts, and the smaller holes

p3 #2927 test harness: an autouse fixture stamps the shared demo tenant's ms_tenant_id with no teardown autouse fixture pollutes shared tenant Dev only

An autouse fixture stamps the shared demo tenant's ms_tenant_id with no teardown — the column is UNIQUE and the demo tenant has it NULL, so the pollution is ordering-dependent and already caused 14 duplicate-key errors under xdist. The fix converts it to a yield fixture that restores the prior value, or seeds a dedicated tenant instead of mutating demo.

p3 #3008 backend/tests/integration/{SUMMARY,README}.md describe test classes that no longer exist and contradict each other stale docs contradict each other Dev only

Two hand-maintained PASS/FAIL tables describe test classes that no longer exist and record the same test with opposite outcomes — actively misleading for anyone triaging a failure. SUMMARY.md attributes the test to a class TestDataQuality that appears nowhere in backend/tests/. Fix by deleting the tables or generating them, not by hand-refreshing.

p3 #3014 No real-DB coverage for the single-word topic filter in suggested questions topic filter unreachable from fixture All

The single-word topic filter is unreachable from the fixture — mutating both drop sites so the filter never fires leaves the suite 6/6, because every seeded topic is hyphenated and rendered multi-word by construction. Fix: seed a single-word topic and assert it is excluded, with a multi-word topic in the same test as the positive control.

p3 #3015 compute_idf_batch's SQL has no real-DB coverage — short-circuiting it to {} passes every test short-circuited IDF SQL passes all All

Short-circuiting compute_idf_batch to {} passes every test and runs faster — the service defaults every missing key to 1.0 (idf_map.get(target_id, 1.0)), so the join, the ln() arithmetic, and the tenant/tier scoping are unproven. The fix needs a ranking-sensitive fixture and asserts ordering — a low-frequency/high-IDF node outranks a high-frequency one — not membership.

Why is it in this order?

Priority label first, then issue number within a tier. The single p1 (cross-tenant disclosure) and the top p2 have both closed since this ordering was drawn — see History. What remains is silent wrong-answer, silent-loss, and rot shapes. The p2s and the p3s are one defect class, so there is no evidence-backed finer ranking to invent; number is the honest tiebreak.

Deliberately ignored: issue age and creation date (the list spans 2026-08-01 through 08-05); how cheap or small a fix looks; how well understood the fix is; which drain batch or PR surfaced it — every issue was filed by a drain pass, and that provenance does not rank it.

What the audit found — generated

⚠︎ The prose above cites 2 issues that are no longer open

#3010, #3011. A closed issue named as current work is the drift this section exists to surface — re-derive the prose, or move the reference into History.

Evidence below is generated from the read-only audit of 2026-08-29 and reconciled against the open issues at build time. Every claim cites the issue it came from. Nothing here is a decision — rulings stay in the prose above, which is written by hand.

#1741 chore(ci): unpin Supabase CLI — ship the explicit GRANT-audit migration (v2.106.0…codehigh confidence

All three acceptance items are unmet on origin/main. Pins: deploy.yml:883-890 `supabase/setup-cli@v1` version `2.105.0`; substrate-refactor.yml:76-83 version `2.105.0`; integration-tests.yml:509-511 version `2.95.4` — still three workflows, still pinned, still misaligned exactly as the issue describes. No GRANT-audit migration: `git ls-tree -r --name-only origin/main supabase/migrations/` (population = all 646 migration files, which the migration census confirms are all applied in prod) yields only two grant-named files, `20260624120159_disclosure_audit_capture_sensitive_grants.sql` and `20260627165725_lockdown_internal_securitydefiner_rpc_grants.sql` — both narrow, neither a public-schema-wide grant reproduction. `git grep -rn auto_expose_new_tables origin/main` returns zero hits, so the escape hatch is not configured either; the pins are the only thing holding this up.

#2927 test harness: an autouse fixture stamps the shared demo tenant's ms_tenant_id with no…codehigh confidence

origin/main:backend/tests/integration/test_exchange_webhook_realtime.py:101-116 — `@pytest.fixture(autouse=True)` `def _seed_tenant_and_connector(monkeypatch, supabase)` with NO `yield` and NO teardown, doing `supabase.table("tenants").update({"ms_tenant_id": _AZURE_TENANT_ID}).eq("id", str(demo_tid)).execute()`. The prior value is never read and never restored. The #2926 mitigation IS present and is the only thing that landed: origin/main:backend/tests/integration/conftest.py:1150-1153 explicitly sets `row["ms_tenant_id"] = None` on the per-worker demo clone with the comment naming `tenants_ms_tenant_id_key`. So the collision is defused at the clone; the leak itself is untouched. `git log --oneline origin/main -- backend/tests/integration/test_exchange_webhook_realtime.py` → newest commit c4ef7e102 (the xdist parallelization PR #2058), i.e. no fix commit since the issue was filed.

#2996 [L2-g4-w6] find_or_create's duplicate-key race branch (_refetch_after_race) has no…codehigh confidence

origin/main backend/app/slices/graph_building/repositories/node_write_repository.py:361-366 still has the `except DuplicateKeyError: return await self._refetch_after_race(...)` branch. The only tests naming that branch are (a) backend/app/slices/graph_building/repositories/node_write_repository_test.py:528 `TestFindOrCreateRaceCondition` — a UNIT test with mocked PostgREST, no live unique index — and (b) backend/tests/integration/test_node_repository_e2e.py:281-287, whose docstring states verbatim: "This pins the SELECT-then-UPDATE branch only. The race branch itself (DuplicateKeyError -> _refetch_after_race) needs a forced concurrent insert and has no real-DB coverage - #2996." Search: `git grep -rn "_refetch_after_race|TestFindOrCreateE2E|TestFindOrCreateIsolation" origin/main -- backend` over the whole backend tree returned only the repository, its unit test, and that e2e docstring.

#3004 No real-DB test covers the FTS half of the hybrid RRF for semantic_search /…codehigh confidence

HALF FIXED. Node side (semantic_search / node_search_repository.hybrid_search): backend/tests/integration/test_hybrid_search_bv_boost_integration.py on origin/main now carries `class TestHybridFusesBothBranches` (line 351) whose docstring says 'Pin both halves of the RRF fusion, not just the vector half (#3004)', with `test_each_branch_retrieves_and_fusion_outranks_either` (369) and `test_lexical_branch_alone_decides_ordering` (457) — the exact equal-distance-embeddings/ordering shape the issue asked for. Landed in commit 6686de06b ('V1-XFAIL DRAIN batch 11 — hybrid_search + semantic_connections', #3033). No `skip`/`xfail`/`pytestmark` appears anywhere in that file, and no `_v1_substrate_xfail.txt` exists on origin/main (`git ls-tree -r --name-only origin/main | grep -i xfail` -> empty). MESSAGE side (search_messages / backend/app/slices/message/repo/search.py:241 hybrid_search) is still uncovered: the only real-DB test, backend/tests/integration/test_ask_tools_e2e.py:433 `test_search_messages_returns_matching_message`, is DELIBERATELY lexeme-disjoint ('The query text shares no lexeme with the message body, so the FTS half of the hybrid RRF cannot return it', query='zzqx quuxling vorbex'). Population searched for a message-FTS test: `git ls-tree -r --name-only origin/main backend/app/slices/message/` (no search/FTS test file among the 18 integration tests) plus `git grep -rn "hybrid_search" origin/main -- backend | grep -i test` — every hit is either the node-side repo test, the node BV-boost tests, or app/services/ask/tools/search_messages_test.py which mocks hybrid_search entirely (line 24 `repo.hybrid_search = AsyncMock(return_value=[])`).

#3008 backend/tests/integration/{SUMMARY,README}.md describe test classes that no longer exist…codehigh confidence

On origin/main: `git show origin/main:backend/tests/integration/README.md` line ~93 still reads `| test_group_tags_stripped_from_names | ❌ FAILS | 177 unstripped tags |` while `SUMMARY.md` line ~34 reads `| TestDataQuality | test_group_tags_stripped_from_names | ✅ PASS |` — the contradiction is intact. `git grep -n 'class TestDataQuality' origin/main -- backend/tests` returns nothing (population: all of backend/tests on origin/main); the test actually lives on TestNameSanitizationThroughPipeline in backend/tests/integration/test_name_resolution_integration.py. `git log origin/main --since=2026-07-01 -- backend/tests/integration/SUMMARY.md README.md` shows no commit touching either file.

#3014 No real-DB coverage for the single-word topic filter in suggested questionscodehigh confidence

Both filter sites survive verbatim on origin/main: backend/app/services/feed/suggested_questions_service.py:322 `if node_type.lower() == "topic" and len(target_name.split()) < 2:` (viewer path) and :405 `if node_type.lower() == "topic" and len(name.split()) < 2:` (org-wide path). Every topic seeded in origin/main:backend/tests/integration/test_suggested_questions_e2e.py is hyphenated multi-word — sq-test-project-oasis (:126), sq-test-peer-roadmap (:161), sq-test-org-wide-roadmap (:183), sq-test-public-topic (:208), sq-test-confidential-topic (:218), sq-test-topic-{i} (:289); grep for a single-word topic seed over that file returns none. The drop branch remains structurally unreachable from the fixture.

#3015 compute_idf_batch's SQL has no real-DB coverage — short-circuiting it to {} passes every…codehigh confidence

origin/main:backend/tests/integration/test_suggested_questions_e2e.py — 6 test functions (test_personalized_questions_from_viewer_edges, test_empty_for_isolated_person, test_no_viewer_returns_org_wide, test_tier_filtering_excludes_restricted_nodes, test_asked_chatter_floor_drops_explicitly_low_value_questions, test_diversity_across_edge_types). Every assertion is membership/absence/count ('sq-test-...' in texts, len(edge_types) >= 2, is_personalized True/False); none asserts relative ORDER between two candidates. compute_idf_batch remains the only IDF producer (origin/main:backend/app/repositories/suggested_questions_repository.py:243-304, ln() at :291). Population for the absence half: git grep -ln 'compute_idf_batch|fetch_viewer_edges|SuggestedQuestionsRepository' origin/main -- backend/ → 11 files, of which the only integration test is the e2e file above; the rest are unit tests under backend/tests/unit/ (mocked) plus the service. No ranking-sensitive fixture exists anywhere.

#3071 debt-ratchet is blind to growth below file_size_fail_loc — a baselined file can grow…codehigh confidence

origin/main:backend/scripts/hooks/debt_ratchet.py — check() still iterates `for rel, loc in sorted(_current_file_sizes(fail_loc).items())` (comparison loop over CURRENT sizes only), and `_current_file_sizes` still filters `if loc > fail_loc`. No union over baseline keys. Gate IS reachable: .pre-commit-config.yaml:230 and .github/workflows/ci.yml:301 both invoke `scripts/hooks/debt_ratchet.py`. NOTE the issue's measured instance is gone: parsed origin/main:backend/scripts/hooks/debt_baseline.json — 24 file_size entries, fail_loc=800, entries with value <= 800: ZERO (the 782-line person_data_repository entry no longer exists). Also `_build_baseline` applies the same `> fail_loc` filter, so --update-baseline can never mint a sub-cap entry; only a hand-edited baseline can.

Open questions — what the audit could not settle

#1741 Whether CLI 2.105.0/2.95.4 remain installable and whether anything else in the toolchain now forces an upgrade before 2026-10-30. Also, the ground-truth grant snapshot the migration must reproduce has not been captured. Close both with: `supabase --version` in a fresh worktree, and `docker exec supabase_db_group-mind psql -U postgres -c "select grantee, table_name, privilege_type from information_schema.role_table_grants where table_schema='public' order by 1,2,3" > grants-pre-2106.txt` on a pre-2.106 DB.
#2927 Whether any other test or production code reads `tenants.ms_tenant_id` and would observe the polluted value — I did not enumerate that population. Closing command: `git grep -n "ms_tenant_id" origin/main -- backend/ client/ supabase/migrations/`.
#2996 Whether the race branch ever actually fires in production. Close with: `select count(*) from ...` is not available (no counter); instead grep worker logs — `python3 .claude/tools/flylogs/flylogs.py mawja-api --since 7d --grep 'DuplicateKeyError|_refetch_after_race' --context 5`.
#3004 Whether the message-side FTS branch is currently functioning in production at all (an uncovered branch could already be broken). Close with a real-DB exercise rather than inspection: seed two messages with equidistant embeddings and disjoint lexemes and call `MessageRepository.hybrid_search` — i.e. write the test the issue asks for; there is no read-only query that answers it.
#3015 I did not re-run the mutation (insert `return {}` at the top of compute_idf_batch) to confirm 6/6 still passes — I closed the claim by reading the assertions instead. To close by execution: cd backend && sed -i '' 's/^$ tenant_id = self._require_tenant_id()$$/ return {}\n\1/' app/repositories/suggested_questions_repository.py (at the compute_idf_batch occurrence only) && poetry run pytest tests/integration/test_suggested_questions_e2e.py, then restore by rewriting the file.
#3071 Whether a future hand-edit or a fail_loc raise re-opens the window. Closed by: `python3 -c "import json;d=json.load(open('backend/scripts/hooks/debt_baseline.json'));print([k for k,v in d['file_size'].items() if v<=d['file_size_fail_loc']])"` run at that time.

Not yet assessed — filed after the audit

#3902 [colleague] greetingKey is duplicated in thread.tsx and colleague-web.tsx
#5106 test(backend): seen-name-matching test fails on every re-run (fixed name 'Amina Unique'…
#5263 Integration tests hardcode the shared test DB port in ~20 raw connections
#5994 test(backend): one shared migration-statement splitter for integration tests (three…
#6123 Shared local test DB (port 55322) is 31 migrations behind origin/main

10 assessed issues closed since the audit and are not shown — a closed issue's evidence is history, and printing it as current is how a page starts lying.

Standing rulings

None yet. track:test-truth's decided list in track-order.json is empty. A decision that should bind later sessions goes in that list; a question awaiting a ruling is raised via the needs:ruling label rather than resolved inline.

History & forensics

The only p1 shipped. #3016 (suggested-questions node-side tenant_id predicate unproven) closed 2026-08-31. Fix: backend/tests/integration/test_suggested_questions_e2e.py now carries TestSuggestedQuestionsTenantScopedPredicates, seeding a real second tenant and covering all three predicates the issue named — fetch_viewer_edges, compute_idf_batch, and fetch_org_wide_candidates — each with a positive control alongside the cross-tenant assertion, inside the @pytest.mark.integration suite the required "Backend: Integration Tests" check runs.

The top silent-failure p2 shipped. #2928 (search repos swallow every query error into an empty result) closed 2026-09-02, resolved by PR #3745 — "search failures raise and render as unavailable, never as 'no matches'".