check-new-line-breaks (the composite action used by Morrison-Lab/gha/.github/workflows/check-new-line-breaks.yml and directly via Morrison-Lab/gha/check-new-line-breaks) is documented as diff-scoped: it "only flags lines a PR itself adds, so it can't reflag [pre-existing formatting] drift" (see the comment above the new-line-breaks job in Morrison-Lab/ai-config/.github/workflows/validate.yml).
That guarantee breaks on a file split: when a PR moves an existing block of lines from file A (still present, just trimmed) into a brand-new file B, git diff <base>...HEAD shows every line of B as freshly "added" -- there's no deletion of A to pair against for rename detection, since A still exists (modified, not deleted). The tool then flags every pre-existing, previously-compliant (or previously grandfathered) line in B as a new violation, even though none of that content is new.
Reproduction: Morrison-Lab/ai-config#2250 splits memories/github.md's ## gh (GitHub CLI) section into a new memories/gh-cli.md. The pull_request-triggered run of new-line-breaks (e.g. https://github.com/Morrison-Lab/ai-config/actions/runs/33007501706/job/98304952533) flagged 23 lines in gh-cli.md as needing semantic breaks. Every one of the 23 flagged lines exists verbatim in origin/main's current memories/github.md (e.g. line 145 there == the flagged "The @claude review bot's author name differs by API" line) -- they were never new, just relocated.
Suggested fix: run the diff with rename/copy detection (git diff -M -C or equivalent), or alternatively check whether each "added" line already exists verbatim anywhere in the base tree (e.g. via git log -S or a base-tree grep) before flagging it, so a pure content move doesn't get treated as new content.
Workaround applied for now: reformatted the 23 flagged (pre-existing) lines in gh-cli.md to satisfy the check, purely as a local unblock -- this is churn on content that was never actually new.
Posted by Claude Code (AI agent) --- not written by a human.
check-new-line-breaks(the composite action used byMorrison-Lab/gha/.github/workflows/check-new-line-breaks.ymland directly viaMorrison-Lab/gha/check-new-line-breaks) is documented as diff-scoped: it "only flags lines a PR itself adds, so it can't reflag [pre-existing formatting] drift" (see the comment above thenew-line-breaksjob inMorrison-Lab/ai-config/.github/workflows/validate.yml).That guarantee breaks on a file split: when a PR moves an existing block of lines from file A (still present, just trimmed) into a brand-new file B,
git diff <base>...HEADshows every line of B as freshly "added" -- there's no deletion of A to pair against for rename detection, since A still exists (modified, not deleted). The tool then flags every pre-existing, previously-compliant (or previously grandfathered) line in B as a new violation, even though none of that content is new.Reproduction: Morrison-Lab/ai-config#2250 splits
memories/github.md's## gh (GitHub CLI)section into a newmemories/gh-cli.md. Thepull_request-triggered run ofnew-line-breaks(e.g. https://github.com/Morrison-Lab/ai-config/actions/runs/33007501706/job/98304952533) flagged 23 lines ingh-cli.mdas needing semantic breaks. Every one of the 23 flagged lines exists verbatim inorigin/main's currentmemories/github.md(e.g. line 145 there == the flagged "The @claude review bot's author name differs by API" line) -- they were never new, just relocated.Suggested fix: run the diff with rename/copy detection (
git diff -M -Cor equivalent), or alternatively check whether each "added" line already exists verbatim anywhere in the base tree (e.g. viagit log -Sor a base-tree grep) before flagging it, so a pure content move doesn't get treated as new content.Workaround applied for now: reformatted the 23 flagged (pre-existing) lines in
gh-cli.mdto satisfy the check, purely as a local unblock -- this is churn on content that was never actually new.Posted by Claude Code (AI agent) --- not written by a human.