Module architecture_trend 

architecture-trend analysis — structural decay over the commit sequence.

The HEAD-only architecture metrics (architecture-metrics, dependency-cycles) answer “how tangled is the code now”. This answers the more useful question — “is it getting worse, and when did it start?” — by recomputing the structural-health metrics at a series of historical revisions and emitting one row per sample point.

How it samples history

Up to SAMPLE_POINTS commits are picked evenly across the full date-ordered history (the newest is always included). At each sampled rev the import graph is rebuilt from scratch in memory — no persistent table is touched:

1. files live at that rev come from the changes/commits history (latest change at-or-before the rev’s date that isn’t a deletion — the same date-anchored liveness code-age uses),
2. each live source blob is read at that rev (Repo::read_blob_at), parsed for imports, and resolved in memory with the same per-language resolvers the HEAD scan uses,
3. the resolved edges feed the shared SCC + reachability kernel.

Cost

This is the one analysis that re-parses source at many revisions, so it is markedly heavier than the SQL-only analyses (roughly SAMPLE_POINTS × a HEAD import scan). It is computed on demand and never cached.

Structs

ArchitectureTrendRow

One sampled point on the architecture-decay trend.

Constants

SAMPLE_POINTS

Maximum number of historical sample points on the trend.

Functions

run_architecture_trend

Run the architecture-trend analysis. Returns one row per sampled rev, oldest first. Needs repository access (it reads historical blobs), unlike the SQL-only analyses.