feat: add --matches-stack filter to the patterns command

[alerizzo]

Summary

• Adds -k, --matches-stack [value] to codacy patterns, exposing the API's new matchesStack query param — narrows a tool's code patterns to those that do (or don't) match the repository's detected stack.
• Tri-state, matching the existing issues --false-positives: the bare flag or true sends matchesStack=true, false sends matchesStack=false, omitting it sends nothing. Read explicitly rather than by truthiness, so an explicit false stays distinct from "not requested".
• Applies in bulk mode too, so --enable-all / --disable-all can be scoped to the stack. The post-update toolPatternsOverview call deliberately stays unfiltered — its counts describe the whole tool, not the updated subset (there's a test pinning that).
• parseBooleanOption moved out of issues.ts into a shared src/utils/options.ts and is now imported by both commands.

The API bump is the risky part

matchesStack doesn't exist in the pinned spec — it first ships in 57.4.14, and 57.4.17 is the latest published build. Since src/api/client/ is generated (and prepublishOnly regenerates it), the pin in package.json had to move.

I diffed the two specs before bumping; the delta is purely additive:

Change	Impact
2 new operations (deleteRepositoryApiTokens, reanalyzeCommitCoverage)	none — unused
4 new schemas	none
matchesStackParam on listRepositoryToolPatterns / updateRepositoryToolPatterns / toolPatternsOverview	the point of this PR
stackTagsFilterParam on listOrganizationRepositories	none — the CLI calls ...WithAnalysis

One sharp edge: matchesStack is inserted mid-signature on listRepositoryToolPatterns (arg 12, before sort), not appended — so every full-positional-arg assertion in patterns.test.ts gained a trailing undefined. pattern.ts and issues.ts stop at search (arg 9) and were unaffected.

Repository-token whitelist re-verified

AGENTS.md requires this after every update-api. Two findings, both recorded in SPECS/repository-tokens.md:

• 57.4.x now declares the ProjectTokenAuth scheme in the spec (57.3.9 declared it nowhere), so the whitelist is machine-checkable — I added a verification command to the spec and confirmed it runs verbatim.
• The whitelist is 14 operations, not 13. The addition is searchAiInventoryCategories, which this CLI doesn't use. patterns stays fully whitelisted, so no new token guard was needed.

Test plan

• npm run check-types — clean
• npm test — 625 passing (was 614; +7 patterns, +4 utils/options)
• npm run build — clean
• npx ts-node src/index.ts patterns --help shows -k, --matches-stack [value]
• End-to-end (verified against codacy/codacy-cloud-cli, tool eslint9, --categories Security):
  • bare --matches-stack and --matches-stack true return identical pattern sets
  • the true and false sets are fully disjoint (0 overlap; false → 21 patterns, true → 100, the page cap)

codacy patterns eslint9 --matches-stack          # only patterns matching the repo stack
codacy patterns eslint9 --matches-stack false    # only patterns that don't
codacy patterns eslint9 --disable-all --matches-stack false

Note: --enable-all / --disable-all mutate repo configuration, so the bulk path was verified with mocked tests rather than against a live repo.

🤖 Generated with Claude Code

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 15 complexity · 2 duplication

Metric	Results
Complexity	15
Duplication	2

View in Codacy

AI Reviewer: first review requested successfully. AI can make mistakes. Always validate suggestions.

_{TIP This summary will be updated as you push new changes.}

[codacy-production]

Pull Request Overview

The generated API client/spec changes for the new matchesStack parameter are not present in the supplied diff, so compatibility with the new request signature cannot be verified. This should be resolved before merging.

The required issues-command regression scenario is missing. Codacy reports the PR as up to standards, with no new issues, but coverage data is unavailable.

About this PR

• Add a regression test confirming that the issues command continues using the shared parseBooleanOption implementation.
• Please include or otherwise verify the generated API client/spec changes required for the new matchesStack parameter before merging.

Test suggestions

• List mode sends matchesStack=true for the bare flag.
• List mode sends matchesStack=true for explicit true.
• List mode sends matchesStack=false for explicit false.
• List mode omits the parameter when the option is absent.
• The -k alias supports the tri-state filter.
• Bulk enable/disable passes the stack filter to updateRepositoryToolPatterns.
• Bulk update calls toolPatternsOverview without stack filtering.
• parseBooleanOption handles case-insensitive false/true and other values.
• The issues command continues using the extracted shared boolean parser.

Prompt proposal for missing tests

Consider implementing these tests if applicable:
1. The `issues` command continues using the extracted shared boolean parser.

_{TIP How was this review? Give us feedback}