Software forensics
Where the risk actually is, from how the code has changed
Static analysis tells you how the code looks today. Version-control history tells you where the effort goes, what changes together, and which parts of the system only one person still understands. This package runs the complete investigation from Adam Tornhill's Your Code as a Crime Scene: it mines the history, then chains eight analyses, and ends in one report where every recommendation is corroborated by at least two independent findings.
The deterministic work — mining, metrics, the visual hotspot map — runs in shipped helpers. The model does the judgment: which hotspot names tell the truth, why two modules keep changing together, whether a complexity trend is growth or decay. It is read-only on the repository, except for the report, which sits behind an approval gate.
Code as Crime Scene
Free
Team and up · included with your license
Teams planning a refactor who want to spend it where the history says the pain is, and anyone inheriting a large system who needs to know which parts are fragile before touching them.
What runs
The workflows inside
Code as a Crime Scene
Mines the version-control history, then chains eight analyses: hotspots (change frequency times complexity, with a visual map), complexity trends per hotspot, temporal coupling and architectural decay, architecture-level change patterns, the automated-test safety net, the organizational metrics (fractal figures, knowledge map, Conway cross-reference, knowledge loss), and code churn.
CSA Hotspot Analysis
Ranks hotspots by merging change frequency with size and indentation complexity, renders a self-contained visual map, judges each hotspot by its name and opens the ambiguous ones.
CSA Temporal Coupling
Finds the module that changes with most of the system, measures which modules share commits and how strongly, reads the shared commits to explain why each couple exists, and separates normal evolution from architectural decay with a two-point trend.
CSA Social Analysis
The organizational metrics that outperform code metrics as defect predictors: how many people work on each module, how fragmented that effort is, who holds the context, which coupled modules are owned by different people, and which code has lost its author — framed as properties of modules, never of people.
How a run goes
Step by step, in the order the engine enforces
- 1
Mine the history
Step one of eight normalizes the git log into the data every later step reads. Set the period, and name departed contributors so knowledge loss can be measured.
- 2
Find the offenders
Hotspots are ranked and mapped. The agent judges each by the power of its name and reads the distribution of change for clusters and stable islands.
- 3
Interview the codebase
Complexity trends, temporal coupling, architectural patterns, the test safety net, the social metrics and churn — each its own step, each building on the mined data.
- 4
One corroborated report
Every recommendation is backed by at least two independent findings. Writing the report is the only change to the repository, and it waits for your approval.
What you get
At the end of a run
- ✓A prioritized report where each recommendation is corroborated by two or more analyses
- ✓A visual hotspot map of the codebase
- ✓Temporal-coupling findings with the reason for each couple, a knowledge map, and a churn classification
Read next
Related packages
- Team Review →
A team-process health check from git history across six categories — volume, flow, quality, collaboration, ownership, data integrity. Never individual scores.
- Architecture Basic →
A twenty-nine chapter Clean Architecture assessment of your codebase — SOLID, components, boundaries — every checklist item a verified step. Free from Pro.