Verify ~48 non-component orphans (hooks, lib, utils) surfaced by the #82 graph

[TortoiseWolfe]

Follow-up to #82. That sweep deleted 24 dead component directories; the same module-graph analysis surfaced ~48 non-component modules that appear unreachable from any app entry point.

This is a lead, not a delete manifest. Only a sample was individually confirmed. Verify each before removing anything — #82 itself was wrong in both directions until the graph was rebuilt properly.

Method to reproduce

BFS over static from '…', import(…) and require(…) edges, rooted at the 51 app-router entry files (page.tsx/layout.tsx/route.ts/not-found/error/sitemap/manifest) plus src/middleware.ts and src/pages/_document.tsx. Barrels are ordinary nodes, so a barrel only keeps a symbol alive if the barrel is itself reachable. Tests, stories, __tests__/, src/tests/ and src/mocks/ are never roots.

Candidates

Hooks (17) — useApplicationRealtime, useCodeBlockPreferences, useConversationRealtime, useConversationRealtimeSync, useEmployerRealtimeSync, useEscapeKey, useFormValidation, useMetroAreas, useOfflineStatus, useOnlineStatus, useResumeDownload, useSharedCompaniesInBounds, useTeamMembers, useTileProviders, useVisibilityChange, useWindowResize, useWorkerProfileForEmployer

_{*already deleted in #82 as exclusive dependencies of deleted components}

Worth noting: useOnlineStatus is the FR-006 consolidation hook, and both it and two of the three hooks it was written to replace are unreachable. Also — useWindowResize and useVisibilityChange are the two hydration hazards flagged in #88; if they are dead, that issue's urgency drops accordingly.

src/lib/ (27) — including all four src/lib/seo/* (content, keywords, readability, technical, zero importers anywhere), map/marker-builders.ts, map/index.ts, map/tile-provider-service.ts, messaging/decrypt-message.ts, messaging/decryption-cache.ts, auth/protected-route.tsx, auth/oauth-state.ts, supabase/server.ts, routes/route-export.ts, companies/index.ts, companies/seed-service.ts, companies/company-identity.ts, analytics/index.tsx, validation/index.ts

src/utils/ (3) — codeblock-utils.ts, map-colors.ts, performance.ts

Verify carefully

Two entries deserve a second look before anyone deletes them:

• lib/messaging/decrypt-message.ts / decryption-cache.ts — Message reliability: five undiagnosed E2E-encryption bugs #69 identifies clearDecryptionCaches() in that file as the live cause of message loss after key rotation. If it is genuinely unreachable that changes Message reliability: five undiagnosed E2E-encryption bugs #69's diagnosis; if the graph is wrong here, it is wrong elsewhere. Either outcome is worth knowing.
• lib/supabase/server.ts — dead by construction under output: 'export', same root cause as the API route removed in Dead code sweep: 15 orphaned components, 2 deprecated modules, 1 unreachable API route #82.

Suggested approach

Confirm in small batches with a build between each, exactly as #82 was done — the production build is the real check, since a missed importer fails compilation.

[TortoiseWolfe]

Resolved 2026-08-02: the messaging flag was the graph being right, not wrong

The body flags one entry as needing resolution before anything is deleted:

lib/messaging/decrypt-message.ts / decryption-cache.ts — #69 identifies clearDecryptionCaches() in that file as the live cause of message loss after key rotation. If it is genuinely unreachable that changes #69's diagnosis; if the graph is wrong here, it is wrong elsewhere.

The graph is right. #69's diagnosis was wrong. Corrected there: #69 (comment).

What the verification found

Four of this issue's listed orphans form a single closed island — they import each other, and nothing outside imports any of them:

useConversationRealtime.ts   (no importers at all)
  ├── useConversationRealtimeSync.ts  (:24)
  │     └── decrypt-message.ts        (:22)
  ├── decrypt-message.ts              (:23)
  │     └── decryption-cache.ts       (:21)
  └── decryption-cache.ts             (:19)

Checked beyond static imports: no import( with a matching specifier, no string-built module paths. The only surviving references anywhere in src/ are doc comments pointing into the island (key-service.ts:51, decryption-cache.ts:6, decrypt-message.ts:4) — comments describing behaviour that no longer runs, which is what made #69 look plausible.

The live messaging path is a different architecture: src/app/messages/page.tsx uses messageService + realtimeService and does a full refetch (loadMessages()) on every realtime event, on reconnect, and on a 10s poll. The island implements incremental upsertMessage with a decryption cache — an earlier design that was superseded and left in place.

Confidence transfer to the rest of the list

This was the entry most likely to expose a systematic graph error, because an independent source (#69) contradicted it. It resolved in the graph's favour, and it resolved for a reason that raises confidence in the method: the graph tracked imports while #69 tracked names and docstrings, and the imports were correct.

Promoting these four from "lead" to confirmed dead, safe to delete:

• src/hooks/useConversationRealtime.ts
• src/hooks/useConversationRealtimeSync.ts
• src/lib/messaging/decrypt-message.ts
• src/lib/messaging/decryption-cache.ts

…each with its tests. The remaining ~44 entries are still individually unverified — this resolves one cluster, not the list. The verification that worked here is cheap and worth repeating per entry: grep for non-test importers, then for dynamic imports, then for string paths.

One thing to note before deleting

The island holds the only dedupe-by-id and sort-by-sequence_number logic in the codebase (decrypt-message.ts:235-266). The live path doesn't need it — dedupe is structural under full refetch, and ordering comes from .order('sequence_number') at message-service.ts:613. But if incremental updates ever return (full refetch on every event is not free), that logic would have to be rewritten. Git history preserves it; flagging so the deletion is a known trade rather than a surprise later.

Also worth recording: keyManagementService.onKeysChanged() (key-service.ts:64) exists to notify the island's cache and now has no live subscribers. It isn't in this issue's list — it's a live file — but it is dead surface inside one. Candidate for a follow-up sweep for public APIs whose only consumers were dead code.

[TortoiseWolfe]

Deletion of the four confirmed-dead messaging modules is now tracked in #92, together with knip in CI — which is the mechanical fix for this whole class of finding and would have surfaced this list without a hand-built graph.

The remaining ~44 entries here are still individually unverified.