`gradle`, `dotnet-build` and `uv-sync` filters can never activate — and `rtk verify` reports them green because the test harness never exercises `match_command`

Three of the 63 TOML filters cannot fire. Their inline tests all pass, so nothing surfaces the problem — the test harness validates the transformation but never the matching.

Provenance: AI-assisted source audit, human-directed, at v0.44.2 (700bdde). All 63 filter files were read; the regex claims were verified by executing the patterns. No wrapped tool was run.

Why the tests cannot catch it

src/core/toml_filter.rs:761:

for test in tests {
    let actual = apply_filter(compiled, &test.input);

The harness feeds test.input straight into apply_filter. match_command is never evaluated. So a filter whose pattern can never match a real command still reports every test green, in rtk verify and in CI.

1. gradle.toml:3 — the pattern requires the literal text twice

match_command = "^(gradle|gradlew|\./)gradlew?\b"

The alternation consumes gradle/gradlew/./, and then gradlew? demands another gradle or gradlew. Verified by executing the pattern:

• gradle build → no match
• gradlew build → no match
• ./gradlew build → matches

And even that last case does not reach the filter: src/main.rs:1306-1309 takes file_name() before lookup, which strips ./, and Commands::Gradlew (main.rs:814 → 2411) routes it to the Rust module first anyway.

Net: 35 lines of configuration and 3 always-green tests for a filter that cannot activate. The intended pattern is presumably ^(\./)?gradlew?\b.

2 & 3. dotnet-build.toml and uv-sync.toml are shadowed by clap subcommands

rtk dotnet build is handled by Commands::Dotnet (main.rs:282 → 1899-1900, dotnet_cmd::run_build), and rtk uv … by Commands::Uv (main.rs:780 → 2383). Clap routes both before run_fallback ever consults the TOML filters, so neither definition is reachable — 64 and 37 lines respectively, plus 5 green tests.

The guard that exists for exactly this is stale

src/core/toml_filter.rs:315-326 already warns about this situation:

// Shadow warning: if match_command matches a Rust-handled command, this filter
// will never activate (Clap routes before run_fallback). Warn the author.
for cmd in RUST_HANDLED_COMMANDS {
    if match_regex.is_match(cmd) { ... }
}

But RUST_HANDLED_COMMANDS (:250-300) has drifted from the clap enum. Comparing the two, these subcommands exist in Commands but are absent from the list:

dotnet, uv, gradlew, mvn, gt, sbt, oc, rg, jest, rake, rspec, rubocop, pest, ecs, pint, and the php* family.

That is why dotnet-build and uv-sync were not caught by the mechanism written to catch them.

Suggested directions (untested)

• Fix the harness first — have the test runner check match_command against a sample command (either a new test.command field, or by asserting the pattern matches at least one plausible invocation). Without that, this class recurs silently.
• Derive RUST_HANDLED_COMMANDS from the clap enum rather than maintaining it by hand, so it cannot drift again. If that is awkward, a test asserting every Commands variant name appears in the list would catch the drift.
• Then decide per filter: fix gradle.toml's pattern, and delete dotnet-build.toml / uv-sync.toml (or keep them as documentation with a comment saying they are shadowed).

One more in the same family

src/filters/gcc.toml:3 is ^g(cc|\+\+)\b. \b cannot follow +, so g++ -o a main.cpp does not match (verified). The gcc half works; the g++ half is dead while gcc.toml:2 describes the filter as handling "gcc/g++". Harmless — it falls through to raw passthrough — but the description overstates what it does.

Start with src/core/toml_filter.rs, especially the harness around line 761 and the shadow warning near lines 315-326, then compare RUST_HANDLED_COMMANDS with the Commands enum in src/main.rs. Run rtk verify and inspect gradle.toml, dotnet-build.toml, uv-sync.toml, and gcc.toml. Done means matching behavior is exercised, stale command coverage is detected, and the affected filters have tests reflecting their reachable behavior.