Problem
There is no at-a-glance picture of how this solution fits together. Working
out how a PDS search actually reaches NHS Digital — client → processing /
orchestration → foundation → broker → HTTP — means opening a dozen files, and
the parts that are not wired up (unused packages, unused constructor
dependencies, dead types) are invisible until someone trips over them.
Proposal
Add an interactive dependency graph under Documentation/DependencyGraph,
matching the one already added to NHSISL/LondonFhirService
(https://github.com/NHSISL/LondonFhirService/pull/176):
- A single self-contained
index.html — no build step, no npm, no runtime
dependencies — reading all data from a sibling graph-data.js.
- Two views behind one toggle: single copy (every component once, all
consumers converging on it) and per consumer (dependencies duplicated
per caller, each copy showing only the rows that caller uses).
- Click a component or a single method row to trace its full upstream and
downstream slice.
- Published to GitHub Pages so it can be linked from a review or a ticket.
- A
/update-dependency-graph skill so the snapshot can be refreshed when the
code moves, rather than rotting.
Scope
Documentation and CI only — no production code changes.
Documentation/DependencyGraph/ — index.html, graph-data.js, README.md
.github/workflows/pages.yml — publishes the folder to GitHub Pages
.claude/skills/update-dependency-graph/SKILL.md — refresh procedure
Follow-up
The scan surfaces several things worth deciding on separately (they are
recorded in the graph README, not changed here): ApiPlatformClientFacade is
dead code, PdsOrchestrationService injects a token broker it never calls,
and the three ISL.Providers.PDS.* package references are not used by any
source file.
GitHub Pages will need enabling once under Settings → Pages with the
source set to GitHub Actions before the deploy job can succeed.
Problem
There is no at-a-glance picture of how this solution fits together. Working
out how a PDS search actually reaches NHS Digital — client → processing /
orchestration → foundation → broker → HTTP — means opening a dozen files, and
the parts that are not wired up (unused packages, unused constructor
dependencies, dead types) are invisible until someone trips over them.
Proposal
Add an interactive dependency graph under
Documentation/DependencyGraph,matching the one already added to
NHSISL/LondonFhirService(https://github.com/NHSISL/LondonFhirService/pull/176):
index.html— no build step, no npm, no runtimedependencies — reading all data from a sibling
graph-data.js.consumers converging on it) and per consumer (dependencies duplicated
per caller, each copy showing only the rows that caller uses).
downstream slice.
/update-dependency-graphskill so the snapshot can be refreshed when thecode moves, rather than rotting.
Scope
Documentation and CI only — no production code changes.
Documentation/DependencyGraph/—index.html,graph-data.js,README.md.github/workflows/pages.yml— publishes the folder to GitHub Pages.claude/skills/update-dependency-graph/SKILL.md— refresh procedureFollow-up
The scan surfaces several things worth deciding on separately (they are
recorded in the graph README, not changed here):
ApiPlatformClientFacadeisdead code,
PdsOrchestrationServiceinjects a token broker it never calls,and the three
ISL.Providers.PDS.*package references are not used by anysource file.
GitHub Pages will need enabling once under Settings → Pages with the
source set to GitHub Actions before the deploy job can succeed.