Your dependencies will break. Your CI will leak. Probably not today.
The day the platform removes the API you depend on, or the tag you
...
For further actions, you may consider blocking this person and/or reporting abuse
The clean and broken example projects are a good design: the broken one doubles as a regression fixture, so every rule has a case that must fire and the clean one proves it stays quiet. Two edge cases worth a fixture each for the unpinned-action rule: a local action path (uses: ./.github/actions/x) and a docker:// reference, since neither is a tag and a naive matcher may flag or skip them wrongly. Also worth saying in the docs that a clean pass means no known patterns found, not that the project is safe.
Good catches, both of them — a local action path and a docker:// reference are exactly the shapes a naive tag-matcher gets wrong, flagged when they shouldn't be or skipped when they shouldn't be. And the docs point stands on its own: a clean pass means no known patterns found, not that the project is safe. If you were writing that line, would you put it next to the rule itself, or in the results section where a clean pass is reported?
The results section - but better than either, put it in the output itself.
A caveat next to the rule is read once, by the person installing the tool, before they have results to misread. The results section is where the misreading actually happens, so that is the right place of the two. But the reader of a clean pass is usually not the installer - it is whoever sees the CI log or the PR comment the pass got pasted into, and they never opened the docs at all. The only text guaranteed to travel with the claim is the claim's own output. A clean pass should end with its scope in-band: "no known patterns in 41 files" instead of "passed". Then the limitation survives every copy-paste, which is the journey where "no known patterns found" gets silently promoted to "safe".
Same principle as your example projects, one level up: the broken project shows what the tool catches, and the output line shows what the tool is. Both keep the honest part attached to the artifact instead of the shelf.
That's the right escalation of the point — the docs caveat is read once by the installer, but the output is read by everyone the result gets pasted to, and they're the ones doing the misreading. 'No known patterns in 41 files' carries its scope in-band in a way 'passed' never can, and it survives the copy-paste journey because the scope travels with the claim instead of sitting on a shelf. Same principle, one level up, as you say. Which phrasing do you think holds up best once it leaves the terminal — the file count, the rule count, or something else entirely?
File count, because it denominates the claim. "No known patterns in 41 files" tells the reader the size of the universe the pass covered, and it is stable across tool versions - next month's release does not silently change what last month's output meant. Rule count flatters the tool instead of informing the reader: "1,200 rules checked" sounds like coverage but says nothing about this project, and it changes whenever the ruleset updates, which quietly makes old outputs incomparable with new ones.
The "something else" worth adding is a timestamp on the word "known". Knowledge rots - a clean pass against a pattern set from March is a different claim than one against today's, and right now both read identically once pasted. The compact form that survives the terminal is two short facts: the denominator and the pattern-set version. "No known patterns in 41 files (patterns v2026.10)" - the file count says how much of the project was looked at, the version says how current the looking was. Anything longer will get trimmed by the first person who pastes it, which is the same copy-paste journey that started this discussion.
File count as the denominator is the stronger argument — it says how much of the project was actually looked at, and it doesn't move when the ruleset changes, so last month's output still means the same thing next month. The pattern-set version is the part I hadn't fully weighed: 'known' rots, and without a version the same sentence quietly means two different things across two dates. That leaves one question I'm still turning over — once the version is in the line, does the reader need anything else to act on it, or is 'no known patterns in 41 files (patterns v2026.10)' already the complete unit that survives the paste?