Whole-Unit Passes Over WORKFLOW.md Sections 4 and 5 Raise Twelve Pre-Existing Contract Defects

[ptr727]

Two whole-unit adversarial passes over WORKFLOW.md section 4 and section 5, run as the carried-content pass on the branch settling #1221, #1224 and #1218, raised findings against text that change does not touch. Filed here rather than fixed there, to keep that change to the three issues it was scoped to. Companion to #1231, which tracks the same class.

Neither pass read a diff. Each read its unit whole, the way a repository carrying it for the first time reads it.

Section 4 (Behavioral Contract: Expected Outcomes)

1. D1.6's "every C# and Python repo that has tests" is falsified by the detection the same item describes. The C# guard is hashFiles('**/*Tests*.csproj') and the Python guard needs a repo-root pyproject.toml and tests/. A repo whose test project is named Foo.Test.csproj, or whose Python subtree sits below the root (the csharp+python shape the registry records), has tests and is owed coverage while the leg never runs. The item owes a sentence separating what the contract requires from what the hub mechanism reaches.

2. D1.6's written-report check guards one leg of two. The item mandates the Python missing-coverage.xml failure because "nothing downstream of it can tell an absent report from an uploaded one", and leaves the identical hole open on the C# leg: the prefix loop tolerates an empty directory ([ -e "$report" ] || continue) and the upload is best-effort, so the sub-18.9.0 per-project --results-directory resolution the item itself documents yields an empty ./coverage and a green job.

3. D1.6's MTP pin is described as staying put while Dependabot moves it. "A repo whose test project is not yet MTP-based keeps the VSTest collector and its existing pin on the reusable validator" is an instruction the fleet's own bots defeat: dependabot.yml runs github-actions on both branches with a patterns: ["*"] group covering reusable-workflow uses: pins, and D8.1 auto-merges every tier. No ignore rule is named, and the item never says what dotnet test --coverage does against a VSTest project once the pin moves.

4. D1.6's Dependabot-store justification is inert on the shipped shape, and "skip silently" mis-describes the failure. The same item says every pull request stub's validation job passes no secrets: key at all, so no token reaches the validator on any pull request until the repo adds the mapping, yet the dependabot-store requirement is stated unconditionally. Separately, an absent token does not skip the upload step; the step runs and its failure is swallowed by fail_ci_if_error: false.

5. D1.6's codecov-cli finder claim is unversioned and unverifiable. The whole report-prefixing step rests on "a name codecov-cli's own file finder does not match", with nothing saying which finder version behaves that way or why the coverage- prefix is matched, so a carrier cannot tell a required workaround from an incidental one when the finder changes.

6. D1.6's "with .gitignore the full source of truth" is ambiguous. Source of truth for the exclusion list, for the three examples, or for coverage paths generally. A reader cannot act on it.

7. D1.1's negation-filter claim is stated generally and holds only in a sub-case. "A filter written the other way round ... satisfies D1.4 and violates this item" is true only where the negation list happens to exclude .github/workflows/**. A negation filter omitting workflow paths violates D1.4 as well, so satisfying D1.4 is not a property of negation filters.

8. D4.5's re-dispatch recovery is an unguarded time-of-check-to-time-of-use race presented as a decision procedure. The operator reads the branch tip, then dispatches. A push landing in that window redirects the build to a different commit and a different NBGV version, and nothing pins the dispatch to the observed commit or fails the run on a mismatch, D2.3 forbidding a commit dispatch. The failure is a green publish of the wrong version while the failed one stays unpublished.

9. D4.5's 30-day re-run window is stated as a fixed constant. Re-run availability also depends on the run's logs still existing, and log retention is a per-repository setting that can be far below 30 days. A repository with short retention loses the recovery earlier than the item promises, and nothing tells the reader to check.

10. D9.1's "sole exception: the documented lagging-tag tool" names no tool. A reader with only this unit cannot tell which pin may lag and so cannot audit the exception.

Section 5 (Test Methodology)

These come from the section 5 pass. They are recorded as that pass stated them, and each still wants its own verification before a fix.

11. The 5A D1.6 bullet's N/A instruction is scoped per repository where the requirement is per type. "Record the whole item N/A for a repo with no tests" would drop the C# leg entirely on a mixed repo whose C# side has tests and whose Python side does not. The applicability the audit computes is per type, and the prose should match it.

12. A repository can hold CODECOV_TOKEN in both stores, pass every 5A clause, and still upload tokenless, because no shipped pull request stub passes a secrets: key, so the 5A bullet's secret-name check is satisfied by a token nothing forwards.

13. The remaining section 5 findings from that pass concern the walkthrough and scenario prose rather than a single item, and are held here as one line rather than split, since each needs the same verification pass before it is worth wording.

Not in scope here

Two findings from these passes were dispositioned rather than filed. The 5C carve-out that leaves a trivial-change pull request for the maintainer to open is settled: an agent may open a pull request, the carve-out covering workflow dispatches and real publish re-runs only. And the D7.3 both-forms finding was verified and fixed in the change these passes ran against, since it fell inside that change's own scope.

[ptr727]

One more surface, found by the diff pass on #1255 rather than by the whole-unit passes above.

WORKFLOW.md section 2, "Workflow Style Conventions" still states the claim #1255 disproved: that workflow_dispatch delivers a boolean input as a string through the inputs context, and that any if: consuming one therefore compares both forms. #1255 rewrote D7.3 in section 4 of the same file to say the opposite, so WORKFLOW.md now contradicts itself across two sections, and section 2 is the one an agent is routed to for conventions.

Measured against @actions/expressions, GitHub's own implementation of the expression language: inputs.flag == true is true and inputs.flag == 'true' is false for a declared boolean, while github.event.inputs.flag == true is false and github.event.inputs.flag == 'true' is true for the same input. Only the github.event.inputs context stringifies, and within it the == true half can never fire.

Section 2 was left alone in #1255 because it is a separate canonical unit and editing it would have pulled another whole-unit pass into a change already scoped to three issues. The same claim in GOVERNANCE.md "Workflow YAML Conventions" is #1197 item 3, and the workflow-ci-contract skill's copy is #1240, so fixing all three together is the coherent unit of work.

[ptr727]

Rolled up per #1315 into the unit tracker(s) #1369, #1370: every finding this issue enumerates appears there as a numbered line naming this issue. Closing as a duplicate of those trackers so no finding is lost and this bundle stops being a unit of work.