#736 declared .github/workflows/validate-task.yml at appliesTo: "*". Eight repositories do not carry one, so spec/audit.py now reports a LETTER on each, and they went from zero letters to one without anything changing in them.
LETTER file: .github/workflows/validate-task.yml absent on main (verify intent per AUDIT.md section 7)
Measured on a full spec/audit.py run against hub 79f4f17: 13 downstream repositories carry one and 8 do not.
|
repositories |
| carry one |
Utilities, LanguageTags, aiopurpleair, Financial-Modeling, PlexCleaner, ESPHome-NonRoot, VSCode-Server-DotNetCore, NxWitness, HomeAutomation-Config, PhotoCleaner, MediaTools, AudioCleaner, Blog |
| carry none |
homeassistant-purpleair, KiCadLibrary, EspDinIoT, ESPHome-Config, HomeAssistant-Config, DevKitCIoT, Vantage-Config, HolidayLights |
That 13/8 split is exactly what the accepted ledger entry #736 deleted had already measured and settled:
As publish-release.yml, and settled in the same 2026-08-15 read (14 copies read, the hub's own included, so 13 downstream repos carry one and 8 carry none). ... The 8 that carry none inline their validation instead, and no selector separates them, since source-only repos again sit on either side.
The reasoning still holds against the current data. eda is 3 for 3 among the non-carriers, but source-only plus operational splits both ways: HomeAutomation-Config carries one while ESPHome-Config, HomeAssistant-Config and Vantage-Config do not. No appliesTo selector separates them.
The asymmetry inside #736 is what suggests an oversight rather than a decision. publish-release.yml landed with appliesTo: ["two-phase", "dispatch-only", "publish-on-merge"], which selects its carriers and produces no letters. validate-task.yml landed at "*" in the same change.
Why the letters are not the repositories' fault
A repository that inlines its validation satisfies D1 without a reusable task. ESPHome-Config's test-pull-request.yml runs lint unconditionally (D1.2), a changes paths filter (D1.1, D1.4), two change-gated compile jobs, and the single ruleset-bound check-workflow-status aggregator that needs: them (D1.5). Nothing in that file uses workflow_call, because nothing calls a task. By AUDIT.md section 7 that is letter miss, intent satisfied, so a drift finding rather than a defect, and the repository stays operational. The mechanical run cannot make that call, so it reports the letter and the count reads as a defect.
Left alone, the likely outcome is eight repositories each extracting a reusable task they have no caller for, to satisfy a manifest entry, which is the improvisation the ledger entry was written to prevent.
What would fix it
Either an appliesTo that selects the carriers, if one exists that the previous read missed, or reverting to the accepted disposition with the reasoning restored. The fixed part of D1 is already covered elsewhere and needs no second entry: test-pull-request.yml is declared at interface fidelity with requiredCheckName, and the ruleset binds that check by name.
Found during the ESPHome-Config resync, audit run against hub 79f4f17.
#736 declared
.github/workflows/validate-task.ymlatappliesTo: "*". Eight repositories do not carry one, sospec/audit.pynow reports aLETTERon each, and they went from zero letters to one without anything changing in them.Measured on a full
spec/audit.pyrun against hub79f4f17: 13 downstream repositories carry one and 8 do not.That 13/8 split is exactly what the
acceptedledger entry #736 deleted had already measured and settled:The reasoning still holds against the current data.
edais 3 for 3 among the non-carriers, butsource-onlyplusoperationalsplits both ways: HomeAutomation-Config carries one while ESPHome-Config, HomeAssistant-Config and Vantage-Config do not. NoappliesToselector separates them.The asymmetry inside #736 is what suggests an oversight rather than a decision.
publish-release.ymllanded withappliesTo: ["two-phase", "dispatch-only", "publish-on-merge"], which selects its carriers and produces no letters.validate-task.ymllanded at"*"in the same change.Why the letters are not the repositories' fault
A repository that inlines its validation satisfies D1 without a reusable task. ESPHome-Config's
test-pull-request.ymlrunslintunconditionally (D1.2), achangespaths filter (D1.1, D1.4), two change-gated compile jobs, and the single ruleset-boundcheck-workflow-statusaggregator thatneeds:them (D1.5). Nothing in that file usesworkflow_call, because nothing calls a task. By AUDIT.md section 7 that is letter miss, intent satisfied, so a drift finding rather than a defect, and the repository stays operational. The mechanical run cannot make that call, so it reports the letter and the count reads as a defect.Left alone, the likely outcome is eight repositories each extracting a reusable task they have no caller for, to satisfy a manifest entry, which is the improvisation the ledger entry was written to prevent.
What would fix it
Either an
appliesTothat selects the carriers, if one exists that the previous read missed, or reverting to theaccepteddisposition with the reasoning restored. The fixed part of D1 is already covered elsewhere and needs no second entry:test-pull-request.ymlis declared at interface fidelity withrequiredCheckName, and the ruleset binds that check by name.Found during the ESPHome-Config resync, audit run against hub
79f4f17.