D1.6 requires coverage for "every C# and Python repo that has tests" and names one non-application case, the lint-only profile. The hub validator's Python leg runs only where the tree carries pyproject.toml, tests/, and uv.lock. Those two sets do not line up, and the repos in the gap are neither exempt nor served.
The gap
.github/workflows/validate-task.yml attributes the uv.lock guard to one purpose: "The uv.lock guard excludes the lint-only Python profile ... which is stdlib-only, uvx-run, and carries no lockfile to sync from." That is true of lint-only, and it is not the only shape it excludes.
A build-profile Python repo with tests and no lockfile is also excluded, and D1.6 still requires coverage of it. spec/project-types.json carves out exactly such a shape as distinct from lint-only, "a non-uv Python repo (a Home Assistant integration on pip/requirements)", and registry/repos.json carries homeassistant-purpleair as ["python","homeassistant"] with no profile override. It has pyproject.toml and tests/ and no uv.lock.
So for that repo: the guarantee applies, every step of the validator's Python leg is guarded off with the test step, and no surface says how the guarantee is met or what checks it. In practice it meets D1.6 through its own workflows, which is a legitimate answer that the contract nowhere states.
#1215 made this sharper rather than causing it. That change adds a hard failure when the run wrote no coverage.xml, so the leg now has teeth for the repos it reaches, and the repos it does not reach get neither the coverage nor the failure they would expect from reading D1.6.
What needs deciding
- The exemption sentence widens. D1.6's non-application case becomes lint-only or a repo the validator's Python leg does not reach, and the contract says such a repo meets the guarantee through its own validation. That matches what
homeassistant-purpleair actually does.
- The guard narrows. The Python leg stops gating on
uv.lock and instead detects the dependency mechanism, so a pip/requirements repo with tests is served by the hub validator like any other. Larger, and it changes CI behaviour for a repo that currently passes.
- The registry carries it. The gap becomes a declared per-repo profile or
driftNote rather than a contract change, so the audit records why that repo's coverage is not the validator's to produce.
Option 1 is the smallest and is honest about today's state. Option 2 is the only one that makes D1.6's "every" literally true through one mechanism.
Related
Found by the adversarial passes on #1215, which states the precondition on all four surfaces but deliberately does not resolve which of the above is right. Related to #1134, whose gap 2 is the sibling problem for a Python project below the repo root, and whose gap 3 is the C# half of the produced-report assertion #1215 added for Python.
D1.6 requires coverage for "every C# and Python repo that has tests" and names one non-application case, the
lint-onlyprofile. The hub validator's Python leg runs only where the tree carriespyproject.toml,tests/, anduv.lock. Those two sets do not line up, and the repos in the gap are neither exempt nor served.The gap
.github/workflows/validate-task.ymlattributes theuv.lockguard to one purpose: "The uv.lock guard excludes the lint-only Python profile ... which is stdlib-only, uvx-run, and carries no lockfile to sync from." That is true of lint-only, and it is not the only shape it excludes.A build-profile Python repo with tests and no lockfile is also excluded, and D1.6 still requires coverage of it.
spec/project-types.jsoncarves out exactly such a shape as distinct from lint-only, "a non-uv Python repo (a Home Assistant integration on pip/requirements)", andregistry/repos.jsoncarrieshomeassistant-purpleairas["python","homeassistant"]with no profile override. It haspyproject.tomlandtests/and nouv.lock.So for that repo: the guarantee applies, every step of the validator's Python leg is guarded off with the test step, and no surface says how the guarantee is met or what checks it. In practice it meets D1.6 through its own workflows, which is a legitimate answer that the contract nowhere states.
#1215 made this sharper rather than causing it. That change adds a hard failure when the run wrote no
coverage.xml, so the leg now has teeth for the repos it reaches, and the repos it does not reach get neither the coverage nor the failure they would expect from reading D1.6.What needs deciding
homeassistant-purpleairactually does.uv.lockand instead detects the dependency mechanism, so a pip/requirements repo with tests is served by the hub validator like any other. Larger, and it changes CI behaviour for a repo that currently passes.driftNoterather than a contract change, so the audit records why that repo's coverage is not the validator's to produce.Option 1 is the smallest and is honest about today's state. Option 2 is the only one that makes D1.6's "every" literally true through one mechanism.
Related
Found by the adversarial passes on #1215, which states the precondition on all four surfaces but deliberately does not resolve which of the above is right. Related to #1134, whose gap 2 is the sibling problem for a Python project below the repo root, and whose gap 3 is the C# half of the produced-report assertion #1215 added for Python.