Seventy-two housekeeping pull requests merged in a single backfill day, each one a single line in `blog/registry.md` or a new post file, and each one running the full CI suite anyway: type-check, unit tests, a production build, and an end-to-end job that spins up its own Postgres container. None of it had anything to check. The blog's own registration pipeline was paying for a full test run every time it filed paperwork.

The first fix skipped the whole workflow for anything under `blog/`, on the reasoning that `main` had no branch protection, checked directly against the API and confirmed by a 404. No branch protection meant no risk of a required check going unreported forever, or so it seemed. That reasoning had a hole in it: branch protection and repository rulesets are two separate systems, and a 404 on one says nothing about the other. `main` had a ruleset requiring four checks by their exact job names, and skipping the workflow entirely would have meant those four names never got reported at all for a blog-only PR, stuck forever on a check GitHub was still waiting to hear from.

The corrected version keeps the workflow triggering on every push and adds one cheap job that looks at what changed, then gates the four real jobs on its answer. When nothing outside `blog/` changed, each of those jobs reports itself as skipped rather than never running, and a ruleset accepts a skipped check as a passing one. Rather than trust the logic and move on, the next real blog PR got watched instead: the four jobs ran in full, exactly as if nothing had changed at all.

The filter's default behavior matches a file against any one pattern in its list, and `'**'` matches everything, so the negation never excluded anything; the "not blog" signal came back true no matter what changed. The fix is one added line:

```yaml
- uses: dorny/paths-filter@v4
  id: filter
  with:
    predicate-quantifier: every
    filters: |
      non_blog:
        - '**'
        - '!blog/**'
```

`predicate-quantifier: every` requires a file to match every pattern, negation included, before it counts, documented upstream as the pattern for exactly this "ignore one subtree" case, just not the default one.

Watching the same PR again after that fix landed showed the four jobs reporting skipped this time, the ruleset satisfied, the merge going through clean. The registration pipeline's own pull requests no longer cost a real test run, and the two workflows that never needed job-level gating in the first place, a reminder comment and a word-list comment, keep the simpler version: skip the whole trigger, since nothing requires their names by string.