feat: wire JSON contact data files into handlers

[camlambert2000]

Summary

Wires the three verified JSON data files into the VA codebase. All contact data now comes from authoritative sources rather than being hardcoded inline.

Commits

• chore: add housing-pathway-endpoints.json to lib/data
• feat: wire housing-pathway-endpoints.json into serviceMatcher — LA-specific navigator, DV, and immigration orgs
• chore: add safeguarding-endpoints.json to lib/data
• feat: wire safeguarding-endpoints.json into SA and DV exits in crisis.ts
• refactor: extract endpoint lookups into standalone functions — navigator, DV, immigration orgs wired via terminal builder
• fix: wire profile.dv from session safeguarding state

Testing

All 39 tests pass.

Reviewer note

Pre-push audit confirmed: profile.dv was ungated (dead code) — fixed before push. navigatorOrgs confirmed appearing exactly once in terminal builder. getLocalSupportOrgs and getSpecialistOrgs confirmed clean.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
street-support-va-staging	Ready	Preview, Comment	Mar 10, 2026 10:47am
streetsupport-platform-va	Ready	Preview, Comment	Mar 10, 2026 10:47am

[james-cross]

The direction here is solid and the structured JSON approach makes a lot of sense for data that needs to stay current. A couple of things need resolving before this merges though: dvDisclosed appears to never be set (so the DV path in terminal services may not work as intended), and isDropIn is hardcoded for all navigator orgs when that's not always accurate. The duplicate contact data between the two JSON files is also worth addressing before it drifts further.

[james-cross]

Just noticed that dvDisclosed is initialised as null in session state but I can't find anywhere it gets set to true. If that's the case, profile.dv will only even be true via the safeguarding path and the DV section in the terminal builder won't fire for anyone who disclosed DV elsewhere. Could we either wire this up in the relevant handler, or remove the field and simplify profile.dv to just check safeguardingType === 'DOMESTIC_ABUSE'?

[james-cross]

isDropIn: true is hardcoded for every org returned here, but some of these have availability notes like "Monday evenings only". Worth considering whether we should carry isDropIn in the JSON data itself rather than assuming. A user acting on that being wrong could be a real problem.

[james-cross]

This file and la-contacts.json seem to overlap significantly and they've already diverged, P3 Coventry has different phone numbers in each. For crisis contact data, two sources of truth is a risk. Could we consolidate or at least document clearly which is canonical? This looks like the more complete file right now.

[camlambert2000]

totally agree. they should be merged that was always the intention. It does require updating the Safeguarding Contract but in a way that under the new decision framework you can sign off as technical lead rather than it being a matter for the board. Shall we finish this PR5 first and then do the consolidation in the next one. It re-opens the file structure and touches import references in crisis.ts and shared.ts.

[james-cross]

There's quite a few any types in the new lookup functions. The JSON structure is stable and well-defined so it should be straightforward to type.

In general, any types are best avoided because it hinders the compilers ability to spot typo's. I'll add some stricter type checking to the project so they're picked up automatically as we go.

[james-cross]

Not blocking but the "VERIFY BEFORE USE" strings for the Blue Sky Centre could surface to users if this data is read without checking _status. Worth considering null instead, which would be harder to accidentally display.

[james-cross]

We've added TypeScript type checking (tsc --noEmit) and ESLint with @typescript-eslint/no-explicit-any to the project, both wired into CI.

The lint rules are set to warn at present so they don't block current work. Once the warnings are addressed, we'll switch them to error.