spec/audit.py marks coverage applicable for every non-lint-only Python profile, while the hub validator runs the Python test and Codecov steps only where the repository root carries pyproject.toml, tests/, and uv.lock. A build-profile Python repository with no tests therefore fails the audit for a CODECOV_TOKEN secret and a codecov.yml it can never use, because nothing in its pipeline will ever produce a coverage report to upload.
The mismatch
python.coverage.codecov reads "Required for every Python repo with tests" and carries minProfile: build, so the prose already scopes itself to a repo that has tests. The applicability computation does not: it keys on the profile alone, and every build-profile Python repo is in scope regardless of whether a test suite exists.
A package-only Python repository, a library published to PyPI with its tests kept elsewhere or not yet written, is the reachable shape. It is a legitimate build profile, and it will be told to store a Codecov token in two secret stores and commit a codecov.yml whose statuses gate nothing.
Why now
Raised by CodeRabbit on #1223, backed by its own static analysis of spec/audit.py against spec/project-types.json and .github/workflows/validate-task.yml. Nothing in #1215 or #1223 introduced it, and neither touches spec/audit.py.
It is the mirror of #1221, which records the opposite direction: D1.6 requires coverage of tested Python repos that the validator's uv.lock guard excludes. Both are the same root disagreement, between who the contract says owes coverage and who the mechanism actually reaches, and they fall on opposite sides of it. Deciding one without the other risks moving the boundary twice.
What needs deciding
- Make applicability tests-aware.
coverage_active gains the same test-presence condition the prose already states, so a package-only build repo is N/A rather than failing.
- Revise the profile contract so a Python repo with no tests is not a build profile for coverage purposes at all, which is a larger change and touches how profiles are declared.
- Leave it and document it, on the grounds that a build-profile Python repo without tests is a shape the fleet does not intend to carry, in which case the audit finding is correct and the repo should gain tests.
Option 1 is the smallest and matches the contract's own wording, which already says "with tests". Whether it should be settled together with #1221 is the first question, since both move the same boundary.
spec/audit.pymarks coverage applicable for every non-lint-onlyPython profile, while the hub validator runs the Python test and Codecov steps only where the repository root carriespyproject.toml,tests/, anduv.lock. A build-profile Python repository with no tests therefore fails the audit for aCODECOV_TOKENsecret and acodecov.ymlit can never use, because nothing in its pipeline will ever produce a coverage report to upload.The mismatch
python.coverage.codecovreads "Required for every Python repo with tests" and carriesminProfile: build, so the prose already scopes itself to a repo that has tests. The applicability computation does not: it keys on the profile alone, and every build-profile Python repo is in scope regardless of whether a test suite exists.A package-only Python repository, a library published to PyPI with its tests kept elsewhere or not yet written, is the reachable shape. It is a legitimate build profile, and it will be told to store a Codecov token in two secret stores and commit a
codecov.ymlwhose statuses gate nothing.Why now
Raised by CodeRabbit on #1223, backed by its own static analysis of
spec/audit.pyagainstspec/project-types.jsonand.github/workflows/validate-task.yml. Nothing in #1215 or #1223 introduced it, and neither touchesspec/audit.py.It is the mirror of #1221, which records the opposite direction: D1.6 requires coverage of tested Python repos that the validator's
uv.lockguard excludes. Both are the same root disagreement, between who the contract says owes coverage and who the mechanism actually reaches, and they fall on opposite sides of it. Deciding one without the other risks moving the boundary twice.What needs deciding
coverage_activegains the same test-presence condition the prose already states, so a package-only build repo is N/A rather than failing.Option 1 is the smallest and matches the contract's own wording, which already says "with tests". Whether it should be settled together with #1221 is the first question, since both move the same boundary.