Architecture patterns / Contract Hubs
Draft
Contract hub exemplar pending — Next.js hub modules not yet packaged as a standalone proof narrative.
What are contract hubs in large codebases?
Contract hubs are modules that define shared types, config shapes, or API surfaces many other modules compile against. They are intentional concentration points — not accidental utilities.
Trust path: Homepage → Validation → Repository proof → Contract Hubs → Install
Why it matters
Framework and monorepo codebases need contract hubs. The merge risk is semantic drift: a “small” type change rewrites obligations for every dependent. ArcSight treats these as high fan-in / high blast-radius zones.
What it looks like in codebases
- Central config objects consumed by server, bundler, and devtools packages.
- Router or renderer type modules imported across feature folders.
- Shared constants that encode protocol versions or feature flags.
Real repository example
No indexed exemplar yet. See Next.js repository proof for the current flagship analysis while this pattern page is in draft.
How ArcSight detects it
- High fan-in plus stable, wide exports on a single module.
- arc explain shows “hub” or orchestrator roles in gravity-center output.
- Impact paths that fan out from one types module into unrelated subsystems.
$ arc explain src/shared/lib/app-router-types# Hub narrative
What to inspect first
- Export surface area — count public types and functions, not just fan-in.
- Versioning or compatibility comments; absent docs mean implicit contracts.
- Consumers in test-only vs production paths.
What to do next
- Split experimental types from stable contract hubs.
- Add impact checks to CI for hub modules on every PR that touches them.
- Prefer additive changes; use refusal output when evidence is incomplete.
Run ArcSight on your codebase
Install locally, run arc impact on the module you plan to change, and get structured evidence — before you merge.
npm install -g arcsightInstall →