ALL-ARCH1005 · change_locality
Judge whether representative behavior changes remain architecturally local.
This is a contextual rule for all languages. Read its implementation.
Definition
Section titled “Definition”Require representative history and an identified behavior boundary. Separately establish repeated unrelated edits, necessary public protocol adoption, and bounded transient work. One large commit or one cross-file edit cannot establish scattered change.
Evidence
Section titled “Evidence”Findings cite compact graph paths, commit or change-set identifiers, the named behavior, and the components touched by each representative change.
Exceptions
Section titled “Exceptions”Public protocol migrations, generated sources, and migrations with removal plans may spread a change intentionally.
Examples
Section titled “Examples”Adding one payment state through six unrelated switches across four packages is scattered.
Updating every generated client after a versioned schema change is an
intentional_protocol_change. A change that stays inside the package owning the behavior is
localized.
References
Section titled “References”- Cites “On the Criteria To Be Used in Decomposing Systems into Modules”
- Cites “Your Code as a Crime Scene”, temporal coupling
- Cites “A Philosophy of Software Design”, information hiding