co-evolution-audit

Co-Evolution Audit

Role: worker. Reads git history, pairs production files to their test files, and reports stale-coverage pairs. Does not edit any code or tests.

The Problem

A file that churns repeatedly while its tests never change is a high-risk signal: the tests are likely passing for structural reasons (they still compile and run) rather than because they verify current behavior. This divergence is invisible to coverage tools — coverage stays green even as the behavioral gap widens with every production change.

Parse Arguments

Arguments: $ARGUMENTS

Flag	Default	Meaning
--since <date|N-days>	90 days ago	Lookback window. Accepts ISO date (2025-01-01) or relative (90 days ago).
--max-commits <N>	200	Cap on commits scanned. The window is the earlier of --since and --max-commits.
--min-churn <N>	3	Minimum production-file change count to flag a pair.
--max-test-churn <N>	1	Maximum test-file change count for a pair to be flagged. A pair is flagged when production churn ≥ --min-churn AND test churn ≤ --max-test-churn.

Graceful skip conditions

If any of the following is true, print a one-line notice and exit cleanly (do not fail):

• The working directory has no .git directory and is not inside a git repository (git rev-parse --git-dir fails).
• git log returns zero commits in the requested window.
• The repository is a shallow clone with fewer than 10 commits.

Step 1: Collect churn data

Run git log to collect per-file change frequency over the window:

git log --since="90 days ago" --max-count=200 --name-only \
    --pretty=format:"" -- . | grep -v '^$' | sort | uniq -c | sort -rn

This produces a frequency table: how many commits touched each file.

Alternatively, --stat can be used for a combined view:

git log --since="90 days ago" --max-count=200 --stat \
    --pretty=format:"COMMIT:%H"

Parse the output into a map: file_path → commit_count. Exclude merge commits (--no-merges) to avoid inflating counts from merge-heavy workflows.