repo-atlas

point it at a github org. a node pipeline reads each repository — tooling versions, dependencies, endpoints, deploy targets, test footprint, ownership — and a react flow app renders the result as a clustered, filterable diagram. formerly architecture-map; this is the open-source version, with nothing of the original estate left in it.

the idea

every architecture diagram i have seen was accurate on the day someone drew it. the decay is not a discipline problem. it is that the diagram lives somewhere the work does not, so keeping it true is a separate chore nobody is paid to do.

so there is no central spreadsheet here. a repository appears on the map, correctly, because its owner curated it where they already work: a description, a few topics, two or three custom properties. the pipeline re-reads all of it every night. the map is a projection of the estate rather than a drawing of it.

what it shows

• components clustered by team, with dependency, service-link and deployment edges.
• the same data as a sortable inventory, a per-application matrix, and an integrations list.
• drill-down into a client: its screens, and the backend endpoints each one calls.
• compliance against your own engineering standards, scored nightly and tracked over time.
• health — stale repositories, dependency version drift, open alerts, failing ci.

what i would keep

everything organisation-specific is configuration, and every field is optional. an unset field means “this does not apply here”, never “broken” — the test suite passes for an estate with no clusters, no design system and no standards document. that constraint was worth more than it cost: it is what made the thing portable at all.

the guard is the other half. the nightly run refuses to commit data that regressed, so a failed clone leaves yesterday’s good map in place instead of publishing a hole. a map that is quietly wrong is worse than one that is visibly stale.

the demo runs on a synthetic estate.