[ryanbr]

tools-python.yml carried a Tools/** path filter, so a change touching no Python never ran it.

The workflow already argued against its own filter

Its header says, verbatim:

NOT path-filtered, and that is deliberate. It used to fire only on Tools/**.py, on the premise that a suite can only break when its own source changes. That is false for test_home_i18n.py, which asserts on the CONTENTS of app and package files. A Swift-only commit broke it (#1671) and the filter meant this job never ran, so main sat red until a contributor touching Tools/ for something unrelated tripped over it in their own PR (#1691).

And the on: block directly below it re-added paths: ['Tools/**'].

The reason it was re-added was sound on its own terms: a Windows runner billed at twice a Linux minute should not run on the many pull requests that touch no Python. The remedy was not, because it silenced the Linux leg too, and the Linux leg is the one that reads product source.

It then cost the same thing a second time. On 2026-09-24 an Android-only commit changed the hero label padding test_home_i18n.py asserts on, this job did not run, and main carried a red suite through nine merges until a commit that happened to touch Tools/ finally tripped it. One of those nine was an outside contributor's.

The split

paths is workflow-level, not job-level, so one filter had to serve two jobs with different inputs. They are now two workflows:

workflow	runs	filter
tools-python.yml	Tools/linux-capture decoders and the core Tools/ suites	none: the core suites read product source, so no path list can describe its inputs. Ubuntu, ~25s, every PR and every push to main.
tools-python-windows.yml	only the Tools/linux-capture tests, under legacy Windows console encodings	Tools/linux-capture/**: those tests read nothing outside their own package, so the cost argument is true here, and answered here.

Job names are unchanged, linux-capture and windows-capture, so the check names are too.

The test that pinned the old filter

test_core_tools_filter_covers_every_governance_tool_path asserted the old paths exactly. Repinned to the new shape rather than dropped:

• the core workflow must carry no path filter, and must still run the core Tools/ step
• the Windows workflow must carry exactly the linux-capture filter, and must not run the core step

Reinstating Tools/** on the core leg now turns it red, verified by doing so. That is what both previous rounds of this lacked: the header said what should be true and nothing enforced it.

Parity governance is deliberately untouched

Its filter is intentional, a test asserts it excludes product globs, and it already carries a daily schedule on main for exactly the authority staleness a path filter cannot see. I had earlier described it as silently skipped; that was wrong, and the schedule is why.

The documentation was already describing the state this restores

Two contributor-facing docs asserted the unfiltered behaviour while the filter was in place:

• CONTRIBUTING.md check table: linux-capture … every PR
• docs/CONTRIBUTING.md: source-hygiene, tools-python and i18n-coverage have no path filter, so all three run on everything

Both were false under the filter. That is worse than the header contradiction, because contributors were told a gate covered their change while it was silently skipped. Both are true again now, with no edit needed.

AGENTS.md was the one that was accurate ("active, path-filtered") and is updated, plus a row for the new Windows workflow its table never carried. CONTRIBUTING.md's table gains the windows-capture check it never listed either. Yesterday a stale AGENTS.md workflow row sent three contributors chasing the wrong thing, which is why these were checked rather than left.

Testing

Core Tools suite 130 tests, no failures. Governance acceptance 49 tests, no failures. The repin mutation-tested by reinstating the filter.