ALL-ARCH1006 · maintenance_hotspot
Judge whether change pressure and structural risk form a maintenance hotspot.
This is a contextual rule for all languages. Read its implementation.
Definition
Section titled “Definition”Combine churn, authorship, complexity, coupling, defects, tests, and current project role. High complexity alone or high churn alone does not establish a hotspot. The criteria keep change frequency, structural risk, verification, ownership, and transient work independent.
Evidence
Section titled “Evidence”Findings cite history windows, structural metrics, defect links, ownership, and test evidence.
Exceptions
Section titled “Exceptions”Generated sources, migrations, and short-lived coordinated rewrites may be transient.
Examples
Section titled “Examples”A complex pricing module changed weekly with weak mutation results is a hotspot. A parser
changed once for a protocol revision is stable_complex. A module that is complex and quiet,
or busy and simple, is healthy, since neither half establishes a hotspot on its own.
References
Section titled “References”- Cites “Your Code as a Crime Scene”
- Cites “CodeScene documentation”, behavioral code analysis concepts
- Cites “Use of Relative Code Churn Measures to Predict System Defect Density”