blast-radius truncates changed files alphabetically and presents the subset as the whole diff #149

Version: 4.4.2 (Homebrew) · macOS

Summary

blast-radius caps the changed-file list at 20. Selection is by path sort order, not importance, and the [diff] panel then renders that subset with a header that reads like the complete change.

Repro

Any branch with more than 20 changed files vs its target:

codemap blast-radius --text --ref <target> .

Actual

[summary]
changed_files=20/52

[diff]
│ Changed: 20 files | +131 -112 lines vs <target> │

The real change was 52 files, +293 −305. The [diff] header states 20 files and the reduced line counts with no indication anything was dropped.

Which files get dropped

Selection is effectively sorted(paths)[:20], so the cut lands at whatever path prefix sits at position 20 — in my case mid-alphabet. Everything after it disappeared, including:

So the summary omitted the largest edit, the app entry point, and the navigation root — while including small files that happened to sort earlier. For a refactor whose risk is concentrated in exactly those files, the output is actively misleading.

Expected

Truncation is fine; silent, arbitrary truncation is not.

Suggested fix

1. Rank before truncating — by churn (added + removed), or by hub-ness (importer count), or both. The current order carries no information.
2. Label the truncation in the panel — Changed: 20 of 52 shown (ranked by churn). The [summary] block already says 20/52; the [diff] header contradicts it, and that header is the part a reader quotes.
3. Consider making the cap a flag (-max-changed-files) that's discoverable from blast-radius --help.