Description
The root stale-identity guard parses git grep output by splitting only on "\n", then requires its line regex to consume the entire string. On Windows, git grep emits CRLF, leaving "\r" on every split line.
The regular expression does not consume that trailing carriage return, so the parser treats allowed legacy-cleanup matches as unparsed/unexpected. The final line happens to pass only because the preceding global .trim() removes its last "\r".
Code reference
rules/ast-grep/stale-identity.test.ts:10-15 enumerates four exact allowed cleanup matches.rules/ast-grep/stale-identity.test.ts:30-35 trims the complete output once, splits on "\n", and anchors the parser regex at the end of each remaining CRLF line.rules/ast-grep/stale-identity.test.ts:36 returns an unparsed line as unexpected.rules/ast-grep/stale-identity.test.ts:37-38 would correctly trim the captured contents, but the first three Windows lines never reach that comparison.
Reproduction
On Windows with Git configured to produce the repository's normal CRLF output:
.\node_modules\.bin\vitest.CMD run rules/ast-grep/stale-identity.test.ts --reporter=verbose
The test fails with three supposedly unexpected matches:
packages/sdk-python/scripts/build.py:18: "stagehand_v4-*.whl",\r
packages/sdk-python/scripts/build.py:19: "stagehand_v4-*.tar.gz",\r
packages/sdk-python/tests/test_build.py:12: "stagehand_v4-0.1.0-py3-none-any.whl",\r
The fourth allowed match is the last output line and passes because stdout.trim() removes its trailing carriage return.
Expected behavior
All four explicitly allowed legacy cleanup strings should be ignored regardless of whether git grep uses LF or CRLF.
Actual behavior
Three allowed entries are reported as forbidden identities on Windows, failing the root test gate.
Why it matters
This guard is part of the repository-wide tests. A line-ending artifact makes the gate deterministically fail for Windows contributors and distracts from actual stale-package identity violations.
Duplicate/history check
I searched open and closed issues and PRs for stale-identity, CRLF handling, git grep parsing, and the legacy package identity. PR #2497 introduced the guard and PR #2730 currently extends a neighboring AST regression test, but neither addresses CRLF parsing. I found no prior report for this failure.
Description
The root stale-identity guard parses
git grepoutput by splitting only on"\n", then requires its line regex to consume the entire string. On Windows,git grepemits CRLF, leaving"\r"on every split line.The regular expression does not consume that trailing carriage return, so the parser treats allowed legacy-cleanup matches as unparsed/unexpected. The final line happens to pass only because the preceding global
.trim()removes its last"\r".Code reference
rules/ast-grep/stale-identity.test.ts:10-15enumerates four exact allowed cleanup matches.rules/ast-grep/stale-identity.test.ts:30-35trims the complete output once, splits on"\n", and anchors the parser regex at the end of each remaining CRLF line.rules/ast-grep/stale-identity.test.ts:36returns an unparsed line as unexpected.rules/ast-grep/stale-identity.test.ts:37-38would correctly trim the captured contents, but the first three Windows lines never reach that comparison.Reproduction
On Windows with Git configured to produce the repository's normal CRLF output:
The test fails with three supposedly unexpected matches:
The fourth allowed match is the last output line and passes because
stdout.trim()removes its trailing carriage return.Expected behavior
All four explicitly allowed legacy cleanup strings should be ignored regardless of whether
git grepuses LF or CRLF.Actual behavior
Three allowed entries are reported as forbidden identities on Windows, failing the root test gate.
Why it matters
This guard is part of the repository-wide tests. A line-ending artifact makes the gate deterministically fail for Windows contributors and distracts from actual stale-package identity violations.
Duplicate/history check
I searched open and closed issues and PRs for
stale-identity, CRLF handling,git grepparsing, and the legacy package identity. PR #2497 introduced the guard and PR #2730 currently extends a neighboring AST regression test, but neither addresses CRLF parsing. I found no prior report for this failure.