claude-security-review: paths inputs document Actions paths: syntax but implement gitignore matching

[kyle-sexton]

Summary

claude-security-review.yml documents its paths / paths-file inputs as taking "GitHub Actions paths: filter syntax" (:155-156, :171-172 at c136b27), but :410-449 implements matching with git init + a root-anchored .gitignore + git check-ignore --stdin --no-index. Those are two different specifications.

Not a live behavior defect today — verified empirically below. Filing so the divergence is recorded before a consumer writes a pattern in the divergent set, because on claude-code-plugins this lane's check is REQUIRED, and a silently-non-matching pattern there means a security review that never fires.

Empirical result

I reproduced the workflow's pattern loop (:417-428) verbatim and ran git check-ignore against representative paths. The reproduction script and the anchoring logic are identical to the shipped implementation.

Anchoring works as intended for ordinary globs. Notably **/*.sh DOES match a root-level install.sh (gitignore treats a leading **/ as "any depth including root"), so the most obvious candidate defect does not exist:

FIRES     install.sh
FIRES     scripts/deploy.sh
FIRES     plugins/foo/hooks/x.js
FIRES     package.json
FIRES     sub/package.json
FIRES     .mcp.json
FIRES     REVIEW.md
FIRES     .github/workflows/ci.yml
NO-REVIEW docs/readme.md

Where the two specifications actually diverge

1. Negation (!) — the material one. Actions paths: supports negation with order-dependent semantics; the official docs state "A matching negative pattern (prefixed with !) after a positive match will exclude the path" and "The order that you define paths patterns matters." The implementation passes ! through to gitignore (:424), where order still matters but the containing-directory rule does not apply the same way. Measured:

patterns:  .github/**  then  !.github/docs/**
  FIRES  .github/docs/notes.md      <-- negation did NOT exclude it

A consumer writing an Actions-valid exclusion gets a pattern that silently does not exclude. On a repo where this check is required, that direction is at least fail-safe (more reviews, not fewer) — but it is not what the consumer wrote.

2. Character classes. [0-9] is undocumented for Actions paths: (the docs describe only * and **) but is fully supported by gitignore. Measured: src/file[0-9].ts matches src/file1.ts and not src/fileA.ts. A consumer could rely on behavior the documented spec does not promise.

3. Trailing-slash directory patterns. scripts/ is a gitignore directory-match idiom; Actions' docs do not address it. Measured as matching scripts/deploy.sh.

4. ? is listed for Actions branch/tag filters but omitted from the paths: description; gitignore supports it.

Live exposure: none today

melodic-software/claude-code-plugins ships the tuned paths file — 26 pattern entries (31 lines including 5 comment/blank). Checked every entry against all four divergent classes:

negation (!):        0
character class ([): 0
trailing-slash only: 0
question mark (?):   0

Every entry is an ordinary * / ** glob, where the two specifications agree. So this is a documentation defect, not a live behavior defect — but the gap is one ! line away from becoming one in the repo where the check is required.

Suggested fix

Correct the input descriptions to describe what is actually implemented. Options, in preference order:

1. Document the real matcher — say the patterns are matched as root-anchored gitignore patterns, note that ! negation does not behave as Actions documents it, and drop the "Actions paths: syntax" claim. Cheapest and honest.
2. Reject unsupported patterns loudly — fail the changes job on a ! line rather than silently mismatching. Fail-closed on a spec the implementation cannot honor.
3. Implement true Actions paths: semantics. Most faithful, most work; probably not worth it given zero live usage of the divergent set.

Recommend (1) plus (2): document reality, and make the one materially divergent class loud instead of silent.

Related

No linked issue.

🤖 Generated with Claude Code

https://claude.ai/code/session_013pLW2dybov9xvTFtx48Ueb

[kyle-sexton]

This was generated by AI during triage.

Triage lane claim — instance KYLE-DESKTOP-triage-20260729. Released; this marker is expired. Triage completed; no work executed, no files touched, nothing merged. 🤖

[kyle-sexton]

This was generated by AI during triage.

Triage verdict — real and verified, but already actioned. Not flipped to the autonomous frontier.

Read-only triage pass. This lane classifies and gate-decides only; it never executes work items, authors fixes, or merges.

Verified independently against c136b27

The divergence is real, and it is a documentation defect rather than a live behavior defect — exactly as reported:

• claude-security-review.yml:155-156 documents the paths input as taking "GitHub Actions paths: filter syntax"; :171-172 says paths-file content is "the same newline-separated pattern list". Confirmed.
• The changes job at :410-449 implements matching with git init into a scratch dir, a root-anchored .gitignore (each pattern prefixed with /), and git check-ignore --stdin --no-index. The '!'* case arm at :424 passes negation straight through to gitignore, where the containing-directory rule does not reproduce Actions' order-dependent exclusion semantics. Confirmed — two different specifications.

The issue's own empirical work (the reproduction of the :417-428 loop, the negation measurement, and the 26-entry audit of claude-code-plugins' live paths file showing zero patterns in any divergent class) is cited as authored evidence and was not re-run here; the structural claim it rests on is verified above.

Gate decision — briefed, but NOT agent-ready

The issue is fully specified and unblocked, and needs no human judgment call. Under the default rule that would make it agent-ready.

It is deliberately not being labelled agent-ready, because open PR #290 (fix(claude-security-review): reject ! negation and document the real path matcher) already carries Closes #289 and implements both halves of this issue's own preferred fix — option (1) document the real matcher, plus option (2) reject ! loudly. Putting this on the autonomous frontier would invite a duplicate fix PR against a branch that already exists.

Applying work-class: scoped (single-file, bounded, behavior-affecting) and removing priority: needs-triage.

Leaving this issue open. The native closing keyword on #290 closes it on merge; closing it by hand here would break that link and lose the evidence trail.

Handoff

Nothing for the work lane. This item's remaining state lives on #290 and belongs to the merge lane — its CI is green except one security-review check, which is out of scope for triage.

🤖

[kyle-sexton]

This was generated by AI during triage.

Triage lane claim released — instance KYLE-DESKTOP-triage-20260729. Triage complete; no work executed, no files touched, nothing merged. 🤖

[kyle-sexton]

This was generated by AI during triage.

Triage addendum

Priority tier assigned: priority: low. Documentation defect with zero live exposure — the issue's own audit of the only tuned consumer paths file (26 entries, claude-code-plugins) found no pattern in any divergent class — and the fix is already in flight on #290. Tier assigned so the item stays visible to priority:-keyed queue views while it waits on that PR.

🤖