feat(vars): add pattern type to definitions.vars

[fohte]

Purpose

• Name a "command + leading global flags" prefix once (e.g. kubectl) and reuse it across multiple rules
  • The same prefix has to be repeated across 7+ allow rules today, so adding a new global flag means editing every rule
• Existing options cannot express this reuse
  • <flag:name> requires "at least one occurrence", so commands without any flag are not covered
  • <opts> does not absorb space-separated long-flag values (e.g. --context foo); foo is left as a positional
  • Existing definitions.vars (literal / path) only accepts a single token sequence or a canonicalised path, not pattern syntax such as [--flag *]

Approach

• Add a new pattern value to definitions.vars[<name>].type. Each value is written using the regular rule-pattern syntax

• A <var:name> reference inlines the matching pattern value at the position where it appears

• Reject the following at config validation time

  • Other placeholders nested inside a pattern value (<cmd>, <opts>, <vars>, <var:...>, <path:...>, <flag:...>)
  • [<var:pattern-typed>] (a pattern-typed var inside an optional group)

• Example:

  definitions:
    vars:
      kubectl:
        type: pattern
        values:
          - "kubectl [-n|--namespace *] [--context *] [--cluster *] [--user *] [--kubeconfig *]"
  rules:
    - allow: "<var:kubectl> get|describe|logs *"
    - allow: "<var:kubectl> top node|pod|nodes|pods *"
    - allow: "<var:kubectl> auth can-i|whoami *"

  With this definition, the first rule matches every one of kubectl get pods, kubectl --context foo get pods, and kubectl --kubeconfig ~/.kube/work --context prod get pods -A

Design decisions

How to express reusable global-flag prefixes

Decision	Design	Pros	Cons
Chosen	Add a pattern type to definitions.vars and expand the value as a rule pattern fragment in place	Orthogonal to the existing types; introduces no behaviour change for literal / path. Rule authors keep using <var:name> without caring whether it is pattern	Pattern values share the rule-pattern grammar, so users will be tempted to nest other placeholders inside (mitigated by an explicit validation reject)
Rejected	Extend <flag:name> with a "zero-or-more" mode	Reuses the existing mechanism	Breaks the contract that bool/value-flag aliases are captured through flag_groups
Rejected	Extend <opts> to absorb space-separated long-flag values	No new placeholder needed	Cannot express "the allowed flags for kubectl only" — there is no way to constrain the absorbed flag set

Whether pattern values can nest other placeholders

Decision	Design	Pros	Cons
Chosen	Reject nesting of <cmd>, <opts>, <vars>, <var:...>, <path:...>, and <flag:...> inside pattern values at validation time	Keeps semantics single-pass; sidesteps cycle detection and pre-parse cache invalidation	Reusing <flag:> and similar placeholders inside a pattern var requires a separate future design
Rejected	Allow nesting and expand recursively	More expressive	Cycle detection is required and the pre-parse cache (parsed_pattern_vars) design no longer holds

[codecov]

Codecov Report

❌ Patch coverage is 75.65543% with 65 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.75%. Comparing base (5dc8483) to head (c0b0c45).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
src/rules/pattern_matcher/mod.rs	40.25%	46 Missing ⚠️
src/config/model.rs	91.40%	11 Missing ⚠️
src/rules/pattern_matcher/token_matching.rs	90.56%	5 Missing ⚠️
src/rules/rule_engine.rs	66.66%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #334      +/-   ##
==========================================
- Coverage   89.04%   88.75%   -0.29%     
==========================================
  Files          53       53              
  Lines       11871    12131     +260     
==========================================
+ Hits        10570    10767     +197     
- Misses       1301     1364      +63     

Flag	Coverage Δ
Linux	88.57% <75.65%> (-0.29%)	⬇️
macOS	89.92% <75.65%> (-0.33%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gemini-code-assist]

Code Review

This pull request introduces a new pattern type for definitions.vars, enabling reusable command-prefix patterns that expand inline within rule patterns. The implementation includes matching engine updates for recursive expansion, prefix consumption logic, and validation to prevent nested placeholders or invalid usage in optional groups. Documentation and integration tests are also provided. I have no feedback to provide.