central-dependency-is-safely-contained

IN derived (depth 2)

Despite `network.py` being imported by virtually every module in the codebase, the three-layer architecture with clean boundaries ensures this central coupling does not create cross-cutting mutation paths — layer separation contains the dependency's blast radius so that the hub topology does not compromise architectural integrity.

Summary

Even though network.py is a hub that nearly everything depends on, this isn't a design problem because the three-layer architecture keeps that dependency safely boxed in. Each layer only interacts with network.py in a controlled way, so a change there won't ripple unpredictably across the whole system — the coupling is high but the blast radius is low.

Justifications

SL — clean layer boundaries contain the impact of the central network dependency (depth-2 from depth-0 + depth-1, integrates orphaned base belief)

Antecedents (all must be IN):

  • network-is-central-dependency — `network.py` is imported by essentially every other module — api, storage, import, export, compact, check_stale, and all test files — making it the central data structure of the project.
  • three-layer-stack-has-clean-boundaries — The architecture enforces strict layer separation: pure data model at bottom, context-managed API with dict returns in the middle, and pure-formatter CLI at the top

Dependents

These beliefs depend on this one:

Details