git log --stat drops summary line on 4+ file commits; omit marker conflates file rows with metadata

Summary

rtk git log --stat (verified on v0.38.0, latest stable) silently drops the N files changed, X insertions(+) summary line for any commit with ≥4 files in the stat block. The summary line is critical correctness data — the canonical ground-truth file count for verifying commit scope — is exactly 1 line so its removal yields zero token savings, and its disappearance is undisclosed: the omit marker [+N lines omitted] lumps it together with truncated file rows, so the consumer cannot tell whether N omits are all files, files+summary, or something else.

This conflicts with two principles stated in CONTRIBUTING.md:

1. Correctness VS Token Savings — "When in doubt, preserve correctness." A 1-line summary is the canonical correctness anchor; dropping it yields no savings and breaks scope-verification flows.
2. Transparency — "RTK's output must be a valid, useful subset of the original tool's output." A subset that drops the summary while keeping rows is not a useful subset; an LLM parsing git log --stat expects the summary line.

Environment

• rtk 0.38.0 (fresh brew upgrade rtk; bug also present on 0.30.0)
• macOS Darwin 25.3.0, zsh
• Hook-based rewrite via Claude Code's Bash tool

Reproducer

mkdir /tmp/rtk-stat-repro && cd /tmp/rtk-stat-repro
git init -q
git config user.email test@local
git config user.name Repro

# 3-file commit (under threshold)
echo a > a.txt && echo b > b.txt && echo c > c.txt
git add . && git commit -q -m "3 files"

# 4-file commit (boundary)
for i in 1 2 3 4; do echo $i > w$i.txt; done
git add . && git commit -q -m "4 files"

# 10-file commit (well over threshold)
for i in 1 2 3 4 5 6 7 8 9 10; do echo $i > y$i.txt; done
git add . && git commit -q -m "10 files"

rtk git log -3 --stat

Observed Behavior

Commit size	RTK shows	Omit marker	Summary line
3 files	3 file rows + summary	(none)	present
4 files	4 file rows	[+1 lines omitted]	dropped
5 files	4 file rows	[+2 lines omitted]	dropped (1 file + 1 summary)
7 files	4 file rows	[+4 lines omitted]	dropped (3 files + 1 summary)
10 files	4 file rows	[+7 lines omitted]	dropped (6 files + 1 summary)

Threshold is a hardcoded 4-line body cap. Above it, both file rows AND the summary line fold into the omit count without distinction.

Behavior is deterministic — verified the same output across direct invocation, rtk -v verbose, RTK_DISABLE=1, piped to cat, and linear refs (HEAD, HEAD~N). Not slash-related (#1431 territory).

Expected Behavior

1. Always preserve the summary line. Exactly 1 line, contains canonical metadata, used by LLMs for scope verification, compresses to zero savings.
2. Disambiguate the omit marker. For example: [+6 file rows omitted, summary preserved] (preferred), or [+6 file rows + summary omitted] (if summary remains suppressed).
3. (Stretch) Make the body cap configurable via [limits] in config.toml, like existing status_max_files, grep_max_results. Currently silent and unconfigurable.

Real-World Impact

A Claude Code agent was verifying a 5-file commit (Cloudflare Pages Function setup: function + tsconfig split + lockfile + package.json + root tsconfig). RTK output showed only 2 file rows on v0.30.0 (no marker at all); on v0.38.0 the marker exists but is ambiguous. The agent concluded "implementer reported 5 files but only 2 are committed → missing 3 files" and almost re-dispatched the implementer to add files that were already there. Recovery required command git log main..HEAD --name-only to bypass RTK.

This bites typical feature commits (most exceed 4 files) and the silent-summary failure mode is dangerous for agent workflows: the summary line is exactly the data an agent needs to confirm scope; trusted-but-ambiguous filter output compounds into confidently-wrong reasoning.

Workaround

command git log -1 --stat (or \git log -1 --stat) bypasses RTK. Token savings on git log --stat are minimal anyway (#611 reports ~0.8% savings even without truncation).

Related

• #1486 (closed) — git diff --stat | <pipe> silent empty output. Different root cause (/-in-ref path heuristic in normalize_diff_args, fixed in #1431). Current bug is in the git log filter, threshold-based, no piping.
• #611 (open) — git log --stat passed through uncompressed in v0.29. v0.38 switched to truncation-with-marker; that addresses #611 partially but introduces the summary-drop and ambiguous-count issues reported here.
• v0.38.0 changelog fix: grep false negatives, output mangling, and truncation annotations (de41533) appears to be the origin of the new marker — it added the annotation but did not address summary-line preservation or count disambiguation.

Suggested Fix Direction

The minimum fix: detect the summary line (e.g. ^\s*\d+\s+files?\s+changed) and exclude it from truncation; update the omit marker to count only file rows. Open to feedback on direction from maintainers familiar with the git_log filter module.