validate-task.yml hardcodes Python 3.13, so adopting it silently drops a repo's other interpreter legs #1475

Found while planning ptr727/aiopurpleair's adoption of the hub gates (ptr727/aiopurpleair#100). Third sibling of #1472 and #1473, but unlike those two this is a capability gap rather than stale prose.

The finding

validate-task.yml pins the interpreter in both places that use one, and exposes no input to change it. Read on main at 8195c43:

.github/workflows/validate-task.yml:196    python-version: "3.13"   # lint job
.github/workflows/validate-task.yml:308    python-version: "3.13"   # unit-test job

The workflow_call block declares markdown-exclude-globs, repo-gate-exclude-globs, and the CODECOV_TOKEN secret. There is no python-versions input, and the unit-test job has no strategy: matrix.

Why that blocks an adoption rather than merely narrowing it

aiopurpleair's carried validate-task.yml runs a real matrix:

strategy:
  fail-fast: false
  matrix:
    python-version: ['3.13', '3.14']

with the Codecov upload keyed per leg (flags: python-${{ matrix.python-version }}) so the two interpreters stay distinct in the dashboard. Its pyproject.toml declares requires-python = ">=3.13", so 3.14 is a runtime the package claims to support.

Adopting the hub task as it stands drops the 3.14 leg entirely. Nothing fails and nothing warns: the required check goes green on 3.13 alone, the repository keeps claiming >=3.13, and it simply stops proving the claim. That is the same silent-narrowing shape #1472 and #1473 have, arriving through a workflow input instead of through prose.

To be clear about what is not lost: the 100% fail_under gate survives, because it lives in the repository's own pyproject.toml addopts and the hub task runs uv run pytest --cov-report=xml over it. Coverage measurement is fine (#1199 settled that). What is lost is interpreter coverage and the per-leg Codecov flag.

Suggested remedy

A python-versions input, a JSON array defaulting to ["3.13"], that the unit-test job fans out over with fail-fast: false, and a Codecov flags: keyed on the leg so multi-leg repos stay legible in the dashboard. A repo naming one version gets exactly today's behavior, so nothing changes for current adopters.

Whether the lint job needs the same treatment is a separate call. Linting on one interpreter is defensible, and this repository lints on one today, so the unit-test job alone would unblock the adoption.

Workarounds considered and why they are worse

Moving the 3.14 leg into the repository's own .github/actions/validate hook would work mechanically, but it splits one test matrix across two mechanisms, gives the two legs different reporting shapes, and puts a generic language test in the hook documented for a repo's domain checks (an ESPHome compile, a Hugo build, a KiCad ERC). It would also be invisible to any fleet measurement that reads the hub task's matrix.

Not filed here

No audit report or registry change is being written back. aiopurpleair's other adoptions are unaffected and already open; this one is held pending a decision here, since adopting first and restoring the leg afterwards means shipping a period where the repository tests one interpreter and claims two.