Module delivery_friction 

delivery-friction analysis — where technical debt actively slows delivery.

Combines three signals at the file level:

• Churn (revisions): files touched more often are higher-risk per the standard hotspot model.
• Lead time (median committer-date minus author-date in days): files where individual commits sit longer between author and merge — proxy for “review bottleneck” or “PR thrash”. Needs the schema v3 commits.committer_date column populated; pre-v3 this analysis returns zero across the board. Commits where committer_date <= date (clock-skew or timezone artefacts) are excluded from the lead-time statistics — matching delivery_metrics’s documented exclusion.
• Complexity (max cognitive): files where the per-function gnarly-ness is highest are slower to change correctly.

The composite friction_score = pr(revs) × pr(lead_time) × pr(cog) × 100 is in [0, 100]. A file scoring high on ALL THREE percentile ranks lights up; one dominant signal alone does not. This is the deliberate contrast with hotspots (revs × complexity) and code-health (complexity-led composite) — delivery-friction is the analysis that answers “where is technical debt actually slowing us down right now?”.

wip_age_days is reported alongside (days since last commit) so callers can tell whether a high-friction file is also stale-but- still-touched (worst case) or hot-but-recently-active (manageable).

Structs

DeliveryFrictionRow

One row per file with above-threshold revision count.

Functions

run_delivery_friction

Run the delivery-friction analysis. Returns rows ranked by composite friction score (highest first).