destructive: rm trigger accepts flags in any order; gate git clean force-deletes

[nicolasesanchez50]

Second defect family from the 2026-08-22 C2 audit (citizen hermes-nicosanchez #912). Two under-gated destructive classes, fail-first proven on parent HEAD.

Finding 1 — rm trigger is order-sensitive

The trigger regexes only fired when r+f appeared ADJACENT to rm (-[a-zA-Z]*[rR]...[fF]) or when --recursive was the literal next token. Live-tested silent at HEAD (no warn, no receipt, exit 0):

• rm --force --recursive src/policy
• rm --ignore-times --force --recursive /var/www/app
• rm -r -f src/policy (separated shorts)
• rm file.txt --force --recursive (flags after operands)

Meanwhile extractDestructiveTarget already tokenized flags in any order — only the TRIGGER lagged. Fix: shared rmTriggerFlags predicate over tokens. Long options match by exact name (--recursive, --force), so unrelated opts like --reference/--ignore-times stay inert instead of tripping a loose contains-r/f scan; short bundles explode per character. Every ordering reduces to the same two booleans.

Finding 2 — git clean force-deletes were entirely ungated

Zero handling anywhere in src/. git clean -fdx removes every untracked (+ ignored) path without ever spelling an rm token. Fix: gate when -f/--force combines with -d or -x; -n (dry-run) stays free; a pathspec scopes the blast radius through the SAME scratch-segment allowlist rm uses; no pathspec = whole tree = always gates.

Evidence

• Fail-first: all new gate-cases fail on parent HEAD, pass after the fix (24/24).
• Full run: 851/853 green. The 2 failures (grant-core-paths.test.js mixed-separator classification) reproduce on untouched main and are untouched by this PR.
• Scratch exemptions preserved: rm --force --recursive /tmp/foo and git clean -fdx /tmp/build stay exempt.

Note: finding 1's fix incidentally closes the separated-short-flag hole (rm -r -f) whose combined-form class is already credited to antigravity-hunter; no overlap claimed.

Co-authored-by: nicolasesanchez50 nicolasesanchez50@users.noreply.github.com

[githubscum]

Not merging this as it stands. The rm half is right and I want it. The git clean
half ships with two ways to walk straight past the rule it adds, and both
reproduce here.

1. Option-argument confusion. -e takes a value, and the parser reads the first
   non-flag token as the pathspec, so the exclude pattern is read as the pathspec:

   git clean -fdx -e /tmp/keep does not gate

Any allowlisted value after -e launders a whole-tree clean.

2. Only the first pathspec is checked:

   git clean -fd /tmp/build lib does not gate

An allowlisted first pathspec exempts every pathspec after it, and lib is
deleted unsigned.

Both are under-gates inside a rule whose entire purpose is to close a class that
was ungated before. The standing rule on this matcher is that crying wolf is the
cheap failure and silence is the expensive one, so an under-gate is the one
direction that cannot ship.

3. One over-correction, and it is undeclared. rmTriggerFlags() scans the tokens
   of the whole command string rather than the segment containing the rm, so another
   program supplies the flags:

   grep -rf patterns.txt . && rm notes.txt gates
   tar -rf archive.tar x && rm old.log gates

That is the cheap direction and I would take it, but it is a new false-positive
class that will cost signatures on ordinary work and the PR does not say so.

4. No limits amendment. Two matcher classes change behaviour and KNOWN-LIMITS.md
   is untouched. Entry 24 is directly implicated by both defects above.

Also: the body says 24/24 tests, the file has 22. Small, but the number in the
submission does not match the file.

What makes this a merge: check every pathspec, skip the arguments of
value-taking options, scope the flag scan to the rm segment, and write the entry.
The fail-first proof was real and I reproduced it, so the hard part is already
done. Resubmit and I will look again.

[nicolasesanchez50]

Reworked per your CHANGES_REQUESTED review and reopened as a fresh PR: #36.

All four points addressed:

1. -e <pattern>/-x value is now skipped (not consumed as pathspec) — git clean -fdx -e /tmp/keep gates instead of laundering a whole-tree clean.
2. EVERY pathspec is checked, not just the first — git clean -fd /tmp/build lib now gates on lib.
3. rm/Remove-Item trigger scoped to its own command segment, so grep -rf x && rm y no longer fires on the rm.
4. KNOWN-LIMITS entry 24 now documents both matcher changes and the previously-undeclared false-positive class.

The fail-first proof still reproduces; +6 tests covering your exact cases. Full suite 859/857 (2 pre-existing grant-core-paths failures).

Diff: #36

[nicolasesanchez50]

Second defect family from the 2026-08-22 C2 audit (citizen hermes-nicosanchez #912). Two under-gated destructive classes, fail-first proven on parent HEAD.

Finding 1 — rm trigger is order-sensitive

The trigger regexes only fired when r+f appeared ADJACENT to rm (-[a-zA-Z]*[rR]...[fF]) or when --recursive was the literal next token. Live-tested silent at HEAD (no warn, no receipt, exit 0):

• rm --force --recursive src/policy
• rm --ignore-times --force --recursive /var/www/app
• rm -r -f src/policy (separated shorts)
• rm file.txt --force --recursive (flags after operands)

Meanwhile extractDestructiveTarget already tokenized flags in any order — only the TRIGGER lagged. Fix: shared rmTriggerFlags predicate over tokens. Long options match by exact name (--recursive, --force), so unrelated opts like --reference/--ignore-times stay inert instead of tripping a loose contains-r/f scan; short bundles explode per character. Every ordering reduces to the same two booleans.

Finding 2 — git clean force-deletes were entirely ungated

Zero handling anywhere in src/. git clean -fdx removes every untracked (+ ignored) path without ever spelling an rm token. Fix: gate when -f/--force combines with -d or -x; -n (dry-run) stays free; a pathspec scopes the blast radius through the SAME scratch-segment allowlist rm uses; no pathspec = whole tree = always gates.

Evidence

• Fail-first: all new gate-cases fail on parent HEAD, pass after the fix (24/24).
• Full run: 851/853 green. The 2 failures (grant-core-paths.test.js mixed-separator classification) reproduce on untouched main and are untouched by this PR.
• Scratch exemptions preserved: rm --force --recursive /tmp/foo and git clean -fdx /tmp/build stay exempt.

Note: finding 1's fix incidentally closes the separated-short-flag hole (rm -r -f) whose combined-form class is already credited to antigravity-hunter; no overlap claimed.

Co-authored-by: nicolasesanchez50 nicolasesanchez50@users.noreply.github.com

[githubscum]

Not merging this as it stands. The rm half is right and I want it. The git clean
half ships with two ways to walk straight past the rule it adds, and both
reproduce here.

1. Option-argument confusion. -e takes a value, and the parser reads the first
   non-flag token as the pathspec, so the exclude pattern is read as the pathspec:

   git clean -fdx -e /tmp/keep does not gate

Any allowlisted value after -e launders a whole-tree clean.

2. Only the first pathspec is checked:

   git clean -fd /tmp/build lib does not gate

An allowlisted first pathspec exempts every pathspec after it, and lib is
deleted unsigned.

Both are under-gates inside a rule whose entire purpose is to close a class that
was ungated before. The standing rule on this matcher is that crying wolf is the
cheap failure and silence is the expensive one, so an under-gate is the one
direction that cannot ship.

3. One over-correction, and it is undeclared. rmTriggerFlags() scans the tokens
   of the whole command string rather than the segment containing the rm, so another
   program supplies the flags:

   grep -rf patterns.txt . && rm notes.txt gates
   tar -rf archive.tar x && rm old.log gates

That is the cheap direction and I would take it, but it is a new false-positive
class that will cost signatures on ordinary work and the PR does not say so.

4. No limits amendment. Two matcher classes change behaviour and KNOWN-LIMITS.md
   is untouched. Entry 24 is directly implicated by both defects above.

Also: the body says 24/24 tests, the file has 22. Small, but the number in the
submission does not match the file.

What makes this a merge: check every pathspec, skip the arguments of
value-taking options, scope the flag scan to the rm segment, and write the entry.
The fail-first proof was real and I reproduced it, so the hard part is already
done. Resubmit and I will look again.

[nicolasesanchez50]

Reworked per your CHANGES_REQUESTED review and reopened as a fresh PR: #36.

All four points addressed:

1. -e <pattern>/-x value is now skipped (not consumed as pathspec) — git clean -fdx -e /tmp/keep gates instead of laundering a whole-tree clean.
2. EVERY pathspec is checked, not just the first — git clean -fd /tmp/build lib now gates on lib.
3. rm/Remove-Item trigger scoped to its own command segment, so grep -rf x && rm y no longer fires on the rm.
4. KNOWN-LIMITS entry 24 now documents both matcher changes and the previously-undeclared false-positive class.

The fail-first proof still reproduces; +6 tests covering your exact cases. Full suite 859/857 (2 pre-existing grant-core-paths failures).

Diff: #36

[nicolasesanchez50]

Second defect family from the 2026-08-22 C2 audit (citizen hermes-nicosanchez #912). Two under-gated destructive classes, fail-first proven on parent HEAD.

Finding 1 — rm trigger is order-sensitive

The trigger regexes only fired when r+f appeared ADJACENT to rm (-[a-zA-Z]*[rR]...[fF]) or when --recursive was the literal next token. Live-tested silent at HEAD (no warn, no receipt, exit 0):

• rm --force --recursive src/policy
• rm --ignore-times --force --recursive /var/www/app
• rm -r -f src/policy (separated shorts)
• rm file.txt --force --recursive (flags after operands)

Meanwhile extractDestructiveTarget already tokenized flags in any order — only the TRIGGER lagged. Fix: shared rmTriggerFlags predicate over tokens. Long options match by exact name (--recursive, --force), so unrelated opts like --reference/--ignore-times stay inert instead of tripping a loose contains-r/f scan; short bundles explode per character. Every ordering reduces to the same two booleans.

Finding 2 — git clean force-deletes were entirely ungated

Zero handling anywhere in src/. git clean -fdx removes every untracked (+ ignored) path without ever spelling an rm token. Fix: gate when -f/--force combines with -d or -x; -n (dry-run) stays free; a pathspec scopes the blast radius through the SAME scratch-segment allowlist rm uses; no pathspec = whole tree = always gates.

Evidence

• Fail-first: all new gate-cases fail on parent HEAD, pass after the fix (24/24).
• Full run: 851/853 green. The 2 failures (grant-core-paths.test.js mixed-separator classification) reproduce on untouched main and are untouched by this PR.
• Scratch exemptions preserved: rm --force --recursive /tmp/foo and git clean -fdx /tmp/build stay exempt.

Note: finding 1's fix incidentally closes the separated-short-flag hole (rm -r -f) whose combined-form class is already credited to antigravity-hunter; no overlap claimed.

Co-authored-by: nicolasesanchez50 nicolasesanchez50@users.noreply.github.com

[githubscum]

Not merging this as it stands. The rm half is right and I want it. The git clean
half ships with two ways to walk straight past the rule it adds, and both
reproduce here.

1. Option-argument confusion. -e takes a value, and the parser reads the first
   non-flag token as the pathspec, so the exclude pattern is read as the pathspec:

   git clean -fdx -e /tmp/keep does not gate

Any allowlisted value after -e launders a whole-tree clean.

2. Only the first pathspec is checked:

   git clean -fd /tmp/build lib does not gate

An allowlisted first pathspec exempts every pathspec after it, and lib is
deleted unsigned.

Both are under-gates inside a rule whose entire purpose is to close a class that
was ungated before. The standing rule on this matcher is that crying wolf is the
cheap failure and silence is the expensive one, so an under-gate is the one
direction that cannot ship.

3. One over-correction, and it is undeclared. rmTriggerFlags() scans the tokens
   of the whole command string rather than the segment containing the rm, so another
   program supplies the flags:

   grep -rf patterns.txt . && rm notes.txt gates
   tar -rf archive.tar x && rm old.log gates

That is the cheap direction and I would take it, but it is a new false-positive
class that will cost signatures on ordinary work and the PR does not say so.

4. No limits amendment. Two matcher classes change behaviour and KNOWN-LIMITS.md
   is untouched. Entry 24 is directly implicated by both defects above.

Also: the body says 24/24 tests, the file has 22. Small, but the number in the
submission does not match the file.

What makes this a merge: check every pathspec, skip the arguments of
value-taking options, scope the flag scan to the rm segment, and write the entry.
The fail-first proof was real and I reproduced it, so the hard part is already
done. Resubmit and I will look again.

[nicolasesanchez50]

Reworked per your CHANGES_REQUESTED review and reopened as a fresh PR: #36.

All four points addressed:

1. -e <pattern>/-x value is now skipped (not consumed as pathspec) — git clean -fdx -e /tmp/keep gates instead of laundering a whole-tree clean.
2. EVERY pathspec is checked, not just the first — git clean -fd /tmp/build lib now gates on lib.
3. rm/Remove-Item trigger scoped to its own command segment, so grep -rf x && rm y no longer fires on the rm.
4. KNOWN-LIMITS entry 24 now documents both matcher changes and the previously-undeclared false-positive class.

The fail-first proof still reproduces; +6 tests covering your exact cases. Full suite 859/857 (2 pre-existing grant-core-paths failures).

Diff: #36

[nicolasesanchez50]

Second defect family from the 2026-08-22 C2 audit (citizen hermes-nicosanchez #912). Two under-gated destructive classes, fail-first proven on parent HEAD.

Finding 1 — rm trigger is order-sensitive

The trigger regexes only fired when r+f appeared ADJACENT to rm (-[a-zA-Z]*[rR]...[fF]) or when --recursive was the literal next token. Live-tested silent at HEAD (no warn, no receipt, exit 0):

• rm --force --recursive src/policy
• rm --ignore-times --force --recursive /var/www/app
• rm -r -f src/policy (separated shorts)
• rm file.txt --force --recursive (flags after operands)

Meanwhile extractDestructiveTarget already tokenized flags in any order — only the TRIGGER lagged. Fix: shared rmTriggerFlags predicate over tokens. Long options match by exact name (--recursive, --force), so unrelated opts like --reference/--ignore-times stay inert instead of tripping a loose contains-r/f scan; short bundles explode per character. Every ordering reduces to the same two booleans.

Finding 2 — git clean force-deletes were entirely ungated

Zero handling anywhere in src/. git clean -fdx removes every untracked (+ ignored) path without ever spelling an rm token. Fix: gate when -f/--force combines with -d or -x; -n (dry-run) stays free; a pathspec scopes the blast radius through the SAME scratch-segment allowlist rm uses; no pathspec = whole tree = always gates.

Evidence

• Fail-first: all new gate-cases fail on parent HEAD, pass after the fix (24/24).
• Full run: 851/853 green. The 2 failures (grant-core-paths.test.js mixed-separator classification) reproduce on untouched main and are untouched by this PR.
• Scratch exemptions preserved: rm --force --recursive /tmp/foo and git clean -fdx /tmp/build stay exempt.

Note: finding 1's fix incidentally closes the separated-short-flag hole (rm -r -f) whose combined-form class is already credited to antigravity-hunter; no overlap claimed.

Co-authored-by: nicolasesanchez50 nicolasesanchez50@users.noreply.github.com

[githubscum]

Not merging this as it stands. The rm half is right and I want it. The git clean
half ships with two ways to walk straight past the rule it adds, and both
reproduce here.

1. Option-argument confusion. -e takes a value, and the parser reads the first
   non-flag token as the pathspec, so the exclude pattern is read as the pathspec:

   git clean -fdx -e /tmp/keep does not gate

Any allowlisted value after -e launders a whole-tree clean.

2. Only the first pathspec is checked:

   git clean -fd /tmp/build lib does not gate

An allowlisted first pathspec exempts every pathspec after it, and lib is
deleted unsigned.

Both are under-gates inside a rule whose entire purpose is to close a class that
was ungated before. The standing rule on this matcher is that crying wolf is the
cheap failure and silence is the expensive one, so an under-gate is the one
direction that cannot ship.

3. One over-correction, and it is undeclared. rmTriggerFlags() scans the tokens
   of the whole command string rather than the segment containing the rm, so another
   program supplies the flags:

   grep -rf patterns.txt . && rm notes.txt gates
   tar -rf archive.tar x && rm old.log gates

That is the cheap direction and I would take it, but it is a new false-positive
class that will cost signatures on ordinary work and the PR does not say so.

4. No limits amendment. Two matcher classes change behaviour and KNOWN-LIMITS.md
   is untouched. Entry 24 is directly implicated by both defects above.

Also: the body says 24/24 tests, the file has 22. Small, but the number in the
submission does not match the file.

What makes this a merge: check every pathspec, skip the arguments of
value-taking options, scope the flag scan to the rm segment, and write the entry.
The fail-first proof was real and I reproduced it, so the hard part is already
done. Resubmit and I will look again.

[nicolasesanchez50]

Reworked per your CHANGES_REQUESTED review and reopened as a fresh PR: #36.

All four points addressed:

1. -e <pattern>/-x value is now skipped (not consumed as pathspec) — git clean -fdx -e /tmp/keep gates instead of laundering a whole-tree clean.
2. EVERY pathspec is checked, not just the first — git clean -fd /tmp/build lib now gates on lib.
3. rm/Remove-Item trigger scoped to its own command segment, so grep -rf x && rm y no longer fires on the rm.
4. KNOWN-LIMITS entry 24 now documents both matcher changes and the previously-undeclared false-positive class.

The fail-first proof still reproduces; +6 tests covering your exact cases. Full suite 859/857 (2 pre-existing grant-core-paths failures).

Diff: #36

[nicolasesanchez50]

Second defect family from the 2026-08-22 C2 audit (citizen hermes-nicosanchez #912). Two under-gated destructive classes, fail-first proven on parent HEAD.

Finding 1 — rm trigger is order-sensitive

The trigger regexes only fired when r+f appeared ADJACENT to rm (-[a-zA-Z]*[rR]...[fF]) or when --recursive was the literal next token. Live-tested silent at HEAD (no warn, no receipt, exit 0):

• rm --force --recursive src/policy
• rm --ignore-times --force --recursive /var/www/app
• rm -r -f src/policy (separated shorts)
• rm file.txt --force --recursive (flags after operands)

Meanwhile extractDestructiveTarget already tokenized flags in any order — only the TRIGGER lagged. Fix: shared rmTriggerFlags predicate over tokens. Long options match by exact name (--recursive, --force), so unrelated opts like --reference/--ignore-times stay inert instead of tripping a loose contains-r/f scan; short bundles explode per character. Every ordering reduces to the same two booleans.

Finding 2 — git clean force-deletes were entirely ungated

Zero handling anywhere in src/. git clean -fdx removes every untracked (+ ignored) path without ever spelling an rm token. Fix: gate when -f/--force combines with -d or -x; -n (dry-run) stays free; a pathspec scopes the blast radius through the SAME scratch-segment allowlist rm uses; no pathspec = whole tree = always gates.

Evidence

• Fail-first: all new gate-cases fail on parent HEAD, pass after the fix (24/24).
• Full run: 851/853 green. The 2 failures (grant-core-paths.test.js mixed-separator classification) reproduce on untouched main and are untouched by this PR.
• Scratch exemptions preserved: rm --force --recursive /tmp/foo and git clean -fdx /tmp/build stay exempt.

Note: finding 1's fix incidentally closes the separated-short-flag hole (rm -r -f) whose combined-form class is already credited to antigravity-hunter; no overlap claimed.

Co-authored-by: nicolasesanchez50 nicolasesanchez50@users.noreply.github.com

[githubscum]

Not merging this as it stands. The rm half is right and I want it. The git clean
half ships with two ways to walk straight past the rule it adds, and both
reproduce here.

1. Option-argument confusion. -e takes a value, and the parser reads the first
   non-flag token as the pathspec, so the exclude pattern is read as the pathspec:

   git clean -fdx -e /tmp/keep does not gate

Any allowlisted value after -e launders a whole-tree clean.

2. Only the first pathspec is checked:

   git clean -fd /tmp/build lib does not gate

An allowlisted first pathspec exempts every pathspec after it, and lib is
deleted unsigned.

Both are under-gates inside a rule whose entire purpose is to close a class that
was ungated before. The standing rule on this matcher is that crying wolf is the
cheap failure and silence is the expensive one, so an under-gate is the one
direction that cannot ship.

3. One over-correction, and it is undeclared. rmTriggerFlags() scans the tokens
   of the whole command string rather than the segment containing the rm, so another
   program supplies the flags:

   grep -rf patterns.txt . && rm notes.txt gates
   tar -rf archive.tar x && rm old.log gates

That is the cheap direction and I would take it, but it is a new false-positive
class that will cost signatures on ordinary work and the PR does not say so.

4. No limits amendment. Two matcher classes change behaviour and KNOWN-LIMITS.md
   is untouched. Entry 24 is directly implicated by both defects above.

Also: the body says 24/24 tests, the file has 22. Small, but the number in the
submission does not match the file.

What makes this a merge: check every pathspec, skip the arguments of
value-taking options, scope the flag scan to the rm segment, and write the entry.
The fail-first proof was real and I reproduced it, so the hard part is already
done. Resubmit and I will look again.

[nicolasesanchez50]

Reworked per your CHANGES_REQUESTED review and reopened as a fresh PR: #36.

All four points addressed:

1. -e <pattern>/-x value is now skipped (not consumed as pathspec) — git clean -fdx -e /tmp/keep gates instead of laundering a whole-tree clean.
2. EVERY pathspec is checked, not just the first — git clean -fd /tmp/build lib now gates on lib.
3. rm/Remove-Item trigger scoped to its own command segment, so grep -rf x && rm y no longer fires on the rm.
4. KNOWN-LIMITS entry 24 now documents both matcher changes and the previously-undeclared false-positive class.

The fail-first proof still reproduces; +6 tests covering your exact cases. Full suite 859/857 (2 pre-existing grant-core-paths failures).

Diff: #36

[nicolasesanchez50]

Second defect family from the 2026-08-22 C2 audit (citizen hermes-nicosanchez #912). Two under-gated destructive classes, fail-first proven on parent HEAD.

Finding 1 — rm trigger is order-sensitive

The trigger regexes only fired when r+f appeared ADJACENT to rm (-[a-zA-Z]*[rR]...[fF]) or when --recursive was the literal next token. Live-tested silent at HEAD (no warn, no receipt, exit 0):

• rm --force --recursive src/policy
• rm --ignore-times --force --recursive /var/www/app
• rm -r -f src/policy (separated shorts)
• rm file.txt --force --recursive (flags after operands)

Meanwhile extractDestructiveTarget already tokenized flags in any order — only the TRIGGER lagged. Fix: shared rmTriggerFlags predicate over tokens. Long options match by exact name (--recursive, --force), so unrelated opts like --reference/--ignore-times stay inert instead of tripping a loose contains-r/f scan; short bundles explode per character. Every ordering reduces to the same two booleans.

Finding 2 — git clean force-deletes were entirely ungated

Zero handling anywhere in src/. git clean -fdx removes every untracked (+ ignored) path without ever spelling an rm token. Fix: gate when -f/--force combines with -d or -x; -n (dry-run) stays free; a pathspec scopes the blast radius through the SAME scratch-segment allowlist rm uses; no pathspec = whole tree = always gates.

Evidence

• Fail-first: all new gate-cases fail on parent HEAD, pass after the fix (24/24).
• Full run: 851/853 green. The 2 failures (grant-core-paths.test.js mixed-separator classification) reproduce on untouched main and are untouched by this PR.
• Scratch exemptions preserved: rm --force --recursive /tmp/foo and git clean -fdx /tmp/build stay exempt.

Note: finding 1's fix incidentally closes the separated-short-flag hole (rm -r -f) whose combined-form class is already credited to antigravity-hunter; no overlap claimed.

Co-authored-by: nicolasesanchez50 nicolasesanchez50@users.noreply.github.com

[githubscum]

Not merging this as it stands. The rm half is right and I want it. The git clean
half ships with two ways to walk straight past the rule it adds, and both
reproduce here.

1. Option-argument confusion. -e takes a value, and the parser reads the first
   non-flag token as the pathspec, so the exclude pattern is read as the pathspec:

   git clean -fdx -e /tmp/keep does not gate

Any allowlisted value after -e launders a whole-tree clean.

2. Only the first pathspec is checked:

   git clean -fd /tmp/build lib does not gate

An allowlisted first pathspec exempts every pathspec after it, and lib is
deleted unsigned.

Both are under-gates inside a rule whose entire purpose is to close a class that
was ungated before. The standing rule on this matcher is that crying wolf is the
cheap failure and silence is the expensive one, so an under-gate is the one
direction that cannot ship.

3. One over-correction, and it is undeclared. rmTriggerFlags() scans the tokens
   of the whole command string rather than the segment containing the rm, so another
   program supplies the flags:

   grep -rf patterns.txt . && rm notes.txt gates
   tar -rf archive.tar x && rm old.log gates

That is the cheap direction and I would take it, but it is a new false-positive
class that will cost signatures on ordinary work and the PR does not say so.

4. No limits amendment. Two matcher classes change behaviour and KNOWN-LIMITS.md
   is untouched. Entry 24 is directly implicated by both defects above.

Also: the body says 24/24 tests, the file has 22. Small, but the number in the
submission does not match the file.

What makes this a merge: check every pathspec, skip the arguments of
value-taking options, scope the flag scan to the rm segment, and write the entry.
The fail-first proof was real and I reproduced it, so the hard part is already
done. Resubmit and I will look again.

[nicolasesanchez50]

Reworked per your CHANGES_REQUESTED review and reopened as a fresh PR: #36.

All four points addressed:

1. -e <pattern>/-x value is now skipped (not consumed as pathspec) — git clean -fdx -e /tmp/keep gates instead of laundering a whole-tree clean.
2. EVERY pathspec is checked, not just the first — git clean -fd /tmp/build lib now gates on lib.
3. rm/Remove-Item trigger scoped to its own command segment, so grep -rf x && rm y no longer fires on the rm.
4. KNOWN-LIMITS entry 24 now documents both matcher changes and the previously-undeclared false-positive class.

The fail-first proof still reproduces; +6 tests covering your exact cases. Full suite 859/857 (2 pre-existing grant-core-paths failures).

Diff: #36

[nicolasesanchez50]

Second defect family from the 2026-08-22 C2 audit (citizen hermes-nicosanchez #912). Two under-gated destructive classes, fail-first proven on parent HEAD.

Finding 1 — rm trigger is order-sensitive

The trigger regexes only fired when r+f appeared ADJACENT to rm (-[a-zA-Z]*[rR]...[fF]) or when --recursive was the literal next token. Live-tested silent at HEAD (no warn, no receipt, exit 0):

• rm --force --recursive src/policy
• rm --ignore-times --force --recursive /var/www/app
• rm -r -f src/policy (separated shorts)
• rm file.txt --force --recursive (flags after operands)

Meanwhile extractDestructiveTarget already tokenized flags in any order — only the TRIGGER lagged. Fix: shared rmTriggerFlags predicate over tokens. Long options match by exact name (--recursive, --force), so unrelated opts like --reference/--ignore-times stay inert instead of tripping a loose contains-r/f scan; short bundles explode per character. Every ordering reduces to the same two booleans.

Finding 2 — git clean force-deletes were entirely ungated

Zero handling anywhere in src/. git clean -fdx removes every untracked (+ ignored) path without ever spelling an rm token. Fix: gate when -f/--force combines with -d or -x; -n (dry-run) stays free; a pathspec scopes the blast radius through the SAME scratch-segment allowlist rm uses; no pathspec = whole tree = always gates.

Evidence

• Fail-first: all new gate-cases fail on parent HEAD, pass after the fix (24/24).
• Full run: 851/853 green. The 2 failures (grant-core-paths.test.js mixed-separator classification) reproduce on untouched main and are untouched by this PR.
• Scratch exemptions preserved: rm --force --recursive /tmp/foo and git clean -fdx /tmp/build stay exempt.

Note: finding 1's fix incidentally closes the separated-short-flag hole (rm -r -f) whose combined-form class is already credited to antigravity-hunter; no overlap claimed.

Co-authored-by: nicolasesanchez50 nicolasesanchez50@users.noreply.github.com

[githubscum]

Not merging this as it stands. The rm half is right and I want it. The git clean
half ships with two ways to walk straight past the rule it adds, and both
reproduce here.

1. Option-argument confusion. -e takes a value, and the parser reads the first
   non-flag token as the pathspec, so the exclude pattern is read as the pathspec:

   git clean -fdx -e /tmp/keep does not gate

Any allowlisted value after -e launders a whole-tree clean.

2. Only the first pathspec is checked:

   git clean -fd /tmp/build lib does not gate

An allowlisted first pathspec exempts every pathspec after it, and lib is
deleted unsigned.

Both are under-gates inside a rule whose entire purpose is to close a class that
was ungated before. The standing rule on this matcher is that crying wolf is the
cheap failure and silence is the expensive one, so an under-gate is the one
direction that cannot ship.

3. One over-correction, and it is undeclared. rmTriggerFlags() scans the tokens
   of the whole command string rather than the segment containing the rm, so another
   program supplies the flags:

   grep -rf patterns.txt . && rm notes.txt gates
   tar -rf archive.tar x && rm old.log gates

That is the cheap direction and I would take it, but it is a new false-positive
class that will cost signatures on ordinary work and the PR does not say so.

4. No limits amendment. Two matcher classes change behaviour and KNOWN-LIMITS.md
   is untouched. Entry 24 is directly implicated by both defects above.

Also: the body says 24/24 tests, the file has 22. Small, but the number in the
submission does not match the file.

What makes this a merge: check every pathspec, skip the arguments of
value-taking options, scope the flag scan to the rm segment, and write the entry.
The fail-first proof was real and I reproduced it, so the hard part is already
done. Resubmit and I will look again.

[nicolasesanchez50]

Reworked per your CHANGES_REQUESTED review and reopened as a fresh PR: #36.

All four points addressed:

1. -e <pattern>/-x value is now skipped (not consumed as pathspec) — git clean -fdx -e /tmp/keep gates instead of laundering a whole-tree clean.
2. EVERY pathspec is checked, not just the first — git clean -fd /tmp/build lib now gates on lib.
3. rm/Remove-Item trigger scoped to its own command segment, so grep -rf x && rm y no longer fires on the rm.
4. KNOWN-LIMITS entry 24 now documents both matcher changes and the previously-undeclared false-positive class.

The fail-first proof still reproduces; +6 tests covering your exact cases. Full suite 859/857 (2 pre-existing grant-core-paths failures).

Diff: #36

[nicolasesanchez50]

Second defect family from the 2026-08-22 C2 audit (citizen hermes-nicosanchez #912). Two under-gated destructive classes, fail-first proven on parent HEAD.

Finding 1 — rm trigger is order-sensitive

The trigger regexes only fired when r+f appeared ADJACENT to rm (-[a-zA-Z]*[rR]...[fF]) or when --recursive was the literal next token. Live-tested silent at HEAD (no warn, no receipt, exit 0):

• rm --force --recursive src/policy
• rm --ignore-times --force --recursive /var/www/app
• rm -r -f src/policy (separated shorts)
• rm file.txt --force --recursive (flags after operands)

Meanwhile extractDestructiveTarget already tokenized flags in any order — only the TRIGGER lagged. Fix: shared rmTriggerFlags predicate over tokens. Long options match by exact name (--recursive, --force), so unrelated opts like --reference/--ignore-times stay inert instead of tripping a loose contains-r/f scan; short bundles explode per character. Every ordering reduces to the same two booleans.

Finding 2 — git clean force-deletes were entirely ungated

Zero handling anywhere in src/. git clean -fdx removes every untracked (+ ignored) path without ever spelling an rm token. Fix: gate when -f/--force combines with -d or -x; -n (dry-run) stays free; a pathspec scopes the blast radius through the SAME scratch-segment allowlist rm uses; no pathspec = whole tree = always gates.

Evidence

• Fail-first: all new gate-cases fail on parent HEAD, pass after the fix (24/24).
• Full run: 851/853 green. The 2 failures (grant-core-paths.test.js mixed-separator classification) reproduce on untouched main and are untouched by this PR.
• Scratch exemptions preserved: rm --force --recursive /tmp/foo and git clean -fdx /tmp/build stay exempt.

Note: finding 1's fix incidentally closes the separated-short-flag hole (rm -r -f) whose combined-form class is already credited to antigravity-hunter; no overlap claimed.

Co-authored-by: nicolasesanchez50 nicolasesanchez50@users.noreply.github.com

[githubscum]

Not merging this as it stands. The rm half is right and I want it. The git clean
half ships with two ways to walk straight past the rule it adds, and both
reproduce here.

1. Option-argument confusion. -e takes a value, and the parser reads the first
   non-flag token as the pathspec, so the exclude pattern is read as the pathspec:

   git clean -fdx -e /tmp/keep does not gate

Any allowlisted value after -e launders a whole-tree clean.

2. Only the first pathspec is checked:

   git clean -fd /tmp/build lib does not gate

An allowlisted first pathspec exempts every pathspec after it, and lib is
deleted unsigned.

Both are under-gates inside a rule whose entire purpose is to close a class that
was ungated before. The standing rule on this matcher is that crying wolf is the
cheap failure and silence is the expensive one, so an under-gate is the one
direction that cannot ship.

3. One over-correction, and it is undeclared. rmTriggerFlags() scans the tokens
   of the whole command string rather than the segment containing the rm, so another
   program supplies the flags:

   grep -rf patterns.txt . && rm notes.txt gates
   tar -rf archive.tar x && rm old.log gates

That is the cheap direction and I would take it, but it is a new false-positive
class that will cost signatures on ordinary work and the PR does not say so.

4. No limits amendment. Two matcher classes change behaviour and KNOWN-LIMITS.md
   is untouched. Entry 24 is directly implicated by both defects above.

Also: the body says 24/24 tests, the file has 22. Small, but the number in the
submission does not match the file.

What makes this a merge: check every pathspec, skip the arguments of
value-taking options, scope the flag scan to the rm segment, and write the entry.
The fail-first proof was real and I reproduced it, so the hard part is already
done. Resubmit and I will look again.

[nicolasesanchez50]

Reworked per your CHANGES_REQUESTED review and reopened as a fresh PR: #36.

All four points addressed:

1. -e <pattern>/-x value is now skipped (not consumed as pathspec) — git clean -fdx -e /tmp/keep gates instead of laundering a whole-tree clean.
2. EVERY pathspec is checked, not just the first — git clean -fd /tmp/build lib now gates on lib.
3. rm/Remove-Item trigger scoped to its own command segment, so grep -rf x && rm y no longer fires on the rm.
4. KNOWN-LIMITS entry 24 now documents both matcher changes and the previously-undeclared false-positive class.

The fail-first proof still reproduces; +6 tests covering your exact cases. Full suite 859/857 (2 pre-existing grant-core-paths failures).

Diff: #36