Narrow the `.github/workflows/**` full-rebuild fail-safe in the change classifier

Problem

Any change under .github/workflows/ sets selection.full = True unconditionally (posit_bakery/config/changeset.py:368, _FULL_PREFIXES). Because pr.yml invokes bakery-build-pr.yml three times — production, development, content — one workflow edit triggers three full matrices.

This is the only unconditional-full rule left in a classifier that narrows everywhere else:

It fires often. Over 60 days, images-connect had 25 commits touching .github/workflows/, much of it Renovate bumping action SHAs in workflows that cannot affect image content.

Where the value is

Dropping the non-build workflows buys only 3 of 25. The prize is that 20 of 25 touch exactly one build workflow, and each currently rebuilds production and development and content in full.

Proposal

Layer 1 — drop workflows that cannot build. Detect by scanning for a uses: of bakery-build*.yml or a direct bakery build / bakery dgoss invocation (images-specialized calls bakery from run: steps, so both signals are needed). ~12% of cases, unambiguous.

Layer 2 — narrow to what the changed workflow actually builds. Parse the caller's with: block for dev-versions, matrix-versions, image-name and map to a MatrixSelection. A production.yml edit rebuilds production only. Roughly a two-thirds reduction on 20 of the 25 cases. pr.yml stays full, since it invokes all three.

Not proposed: semantic diffing of workflow YAML. Workflows have far more ways to affect a build indirectly than bakery.yaml does, and the failure mode is silent.

Non-negotiable design rule

Ignore-list semantics, never allow-list. "These workflows are build-irrelevant" fails toward more building when a new file is forgotten. "These workflows trigger full" fails toward less. Parse failures, unrecognised files, and unexpected YAML shapes must all fail toward building more.

Why this is not a new class of risk

Every other path already accepts narrowing risk. And the backstop exists: BASE_REF is set only on push (bakery-build-native.yml:216), so schedule runs always build the full matrix. Worst case for a misclassification is drift until the next weekly rebuild — identical to the bound already accepted for every other rule.

Worth stating plainly: push to main is also change-aware, so a misclassification is not caught at merge either. The weekly cron is the only catch.

Validation

The classifier was built for this — its docstring notes the classifiers "are pure so they can be unit-tested with synthetic inputs", there are already 45 tests in test/config/test_changeset.py, and bakery ci matrix --changed-files-from accepts a synthetic file list.

1. Replay history offline. Extract changed-file sets from the last few hundred merged PRs across the product repos, run both classifiers, diff. Every strict subset is a candidate saving to inspect by hand; anything that is not a subset is a bug.
2. Extend the test suite first — every workflow filename per repo, plus unparseable YAML, a missing with: block, an unrecognised workflow, and a workflow calling bakery from run:. Each asserting the fail-safe direction.
3. Canary: compute the narrowed selection, still build the full matrix, report the delta to the job summary for 2–4 weeks.
4. Flip it, keeping the weekly rebuild as the documented backstop.

Note

Changes to images-shared itself — reusable workflows, composite actions, posit-bakery — are invisible to a product repo's classifier, since they arrive via uses: @main. That hole exists today and is a stronger argument for keeping the weekly full rebuild than anything here.

Start in posit_bakery/config/changeset.py around line 368 and read the existing classifiers, then inspect test/config/test_changeset.py and run its tests. Use bakery ci matrix --changed-files-from for synthetic validation, including the listed fail-safe cases. Done means workflow changes narrow safely where specified, failures still select more work, and replay or canary validation shows no broadened selection.