fix: reject non-boolean --matches-stack values instead of eating a positional

[alerizzo]

Follow-up to #45, which merged before this fix existed. The bug is on main but has not been released — the patterns-matches-stack changeset is still pending — so no user has seen it.

The bug

Commander's optional-value syntax ([value]) greedily consumes the next token, including one meant as a positional. patterns takes toolName as its 4th positional, so:

$ codacy patterns gh my-org my-repo --matches-stack eslint
Error: Ambiguous arguments for 'patterns'. Expected 1 or 4 positional arguments, got 3.

eslint was silently swallowed as the flag's value (matchesStack=true), and the error never mentions --matches-stack — so a user who did supply a tool name is told their positional count is wrong.

--matches-stack is the command's first optional-value option; every other option on patterns is either a plain boolean (never consumes a token) or a required-value <value> option (consumption is the point). Every test and doc example in #45 placed the flag after the tool name, so the broken ordering was never exercised.

The fix

A new strictBooleanOption() in src/utils/options.ts accepts only true/false and otherwise errors immediately:

error: option '-k, --matches-stack [value]' argument 'eslint' is invalid.
expected "true" or "false". If "eslint" was meant as an argument, place it
before --matches-stack, or pass --matches-stack on its own to mean true.

The three specified behaviours are unchanged: bare flag → true, true → true, false → false.

Also drops a redundant tri-state re-derivation in patterns.ts — Commander already yields exactly true | false | undefined, so the value is now passed through directly.

Deliberately not changed

issues --false-positives [value] uses the lax parseBooleanOption and has the same swallow hazard (issues --false-positives gh org repo would eat gh). Switching it would change existing, shipped behaviour — --false-positives banana currently means true — so it's left alone and flagged as a follow-up in SPECS/commands/tools-and-patterns.md. Happy to do it here if you'd rather.

Test plan

• npm run check-types — clean
• npm test — 630 passing (was 625; +5)
• Regression test asserts the bad ordering now throws and never reaches the API
• Manual:

  codacy patterns gh org repo --matches-stack eslint   # clear error, names the flag
  codacy patterns eslint9 --matches-stack              # true
  codacy patterns eslint9 --matches-stack false        # false

Verified against codacy/codacy-cloud-cli / eslint9: true and false still return disjoint sets (100 vs 21 under --categories Security).

🤖 Generated with Claude Code

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 13 complexity · 0 duplication

Metric	Results
Complexity	13
Duplication	0

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

No merge-blocking issues were identified. Codacy reports the PR is up to standards. The only noted gap is missing coverage for forwarding --matches-stack values in bulk update mode while excluding the filter from the post-update overview request.

Test suggestions

• Strict parser accepts true and false, case-insensitively.
• Strict parser rejects non-boolean and empty values with a descriptive InvalidArgumentError.
• Misordered positional argument after --matches-stack fails before calling the patterns API.
• Bare, true, and false matches-stack values preserve tri-state behavior in patterns list mode.
• Matches-stack values are forwarded correctly in bulk update mode and excluded from the overview request.

Prompt proposal for missing tests

Consider implementing these tests if applicable:
1. Matches-stack values are forwarded correctly in bulk update mode and excluded from the overview request.

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