Eight more WORKFLOW.md section 4 claims the workflows falsify or a reader cannot act on

[ptr727]

Eight claims in WORKFLOW.md section 4 are contradicted by the workflow files they govern, or state a rule a reader cannot act on. Found by the whole-unit canonical passes on PR #1198 and deferred out of it, whose scope was the seven claims already filed. Each needs a contract decision rather than a wording fix.

WORKFLOW.md is carried at intent, so every fleet repository reads these.

1. D2.2 names the one dependent that disproves its own claim

github-release carries validate-release in needs: and does not opt out, so a job-level skip there would couple the release to smoke through a second path

github-release's condition is if: ${{ inputs.github && !inputs.smoke && !failure() && !cancelled() }} (.github/workflows/build-release-task.yml:291). It contains status-check functions, so the implicit success() is suppressed and a skipped validate-release would not skip it. The file's own comment says exactly that. The jobs that would skip are dotnet-publish, build-nuget and build-pypi, whose if: is a bare inputs.enable_*.

2. D4.4's Output is falsified three sentences later

Output: nothing is re-pushed

and then

Docker always re-pushes the image (base-image refresh), independently of the release-create skip

The stated Output is false for any Docker target the item also claims to govern. PR #1198 scoped D4.4's input to a schedule or push re-run, which settles the dispatch leg and leaves this one.

3. D4.1 states a gate whose outputs are strings

A first plan job (publish-plan-task.yml) decides once and every job gates on it

publish and stable are the strings 'true'/'false', and publish-plan-task.yml:16 warns that "A bare if: ${{ needs.plan.outputs.publish }} is always truthy, since a non-empty string is truthy in an Actions expression". Following D4.1 literally with a bare gate publishes on every run. D7.3 covers boolean inputs only, so no item covers this coercion.

4. D9.3 restates a multi-line rule as universal

Bash run: blocks start set -Eeuo pipefail.

Section 2, which D9's own heading routes to, scopes this to "every multi-line bash run:". As restated it is violated by roughly eighteen single-line run: steps in this repository's own tree. A carrier following D9.3 literally fails its own audit.

5. D9.5 lets a CRLF repo read workflow YAML as exempt

Line endings follow .editorconfig.

Section 2 says "Workflow YAML is LF (Actions and Dependabot rewrite it that way). Other files follow .editorconfig." A fleet repository not yet migrated off a CRLF default reads D9.5 as authorizing CRLF workflow YAML, which section 2 forbids unconditionally.

6. D6.4's job-name pattern does not match the .NET target

the enable_<target> input, the build-<target> job

The .NET input is enable_dotnet_publish and the job is dotnet-publish, not build-dotnet-publish (build-release-task.yml:153). Only build-nuget, build-pypi and build-docker match the stated pattern. The same mismatch reaches the operational-vs-release-workflow skill, which tells a repository its build hook lives at .github/actions/build-<target>, where the hub actually resolves .github/actions/dotnet-publish, docker-prepare, docker-build-base, docker-readme-transform, resolve-upstream, validate and deploy. A repository overriding the .NET publish at build-dotnet-publish is never seen by the hashFiles probe, so the hub default runs and the override looks ignored.

7. D3.3 attaches its maintainer-bump clause to the wrong value

NBGV appends the git height as the patch, bumped only for a functional change by the maintainer.

The git height increments automatically on every commit. The maintainer-bumped value is version.json's major.minor floor, named in the preceding sentence.

8. D3.4 asserts a sort guarantee PEP 440 does not give

The develop .dev0 build must remain pip install --pre-selectable and sort above the default release (NBGV git height in the release segment keeps develop ahead)

M.N.P.B.dev0 sorts below M.N.P.B under PEP 440, so develop leads only while its git height exceeds main's. Immediately after a develop -> main promotion, main's height is at or above develop's and the stable release outsorts the develop prerelease until the next develop commit. Nothing in the pipeline enforces the stated MUST.

Also, minor

• D6.1 ends "Canonical for single-target." A fragment with no subject or verb, making no claim a reader can check.
• D1.6's .gitignore example gives coverage/ and *.cobertura.xml, both C# names, while the Python path the same item documents writes coverage.xml at the repository root, which neither pattern matches. This repository's own .gitignore lists it separately.

Related

• validate-task.yml runs pytest --cov-report=xml with no --cov, so Python coverage is never collected #1199, the pytest --cov defect from the same passes, filed separately because it is a live CI defect rather than a contract claim.

[ptr727]

Three more section 4 claims, from a whole-unit pass run while fixing D4.5's recovery phrasing for #1213.

D5.2's "that same condition" is not literal. The item says the delete "carries that same condition" as the conditional consumer it follows. The shipped delete step's if: is the create step's condition plus inputs.expect_release_assets &&, so it is narrower rather than identical. A reader auditing for literal equality between the two if: expressions records a defect where the workflow is correct.

D4.5's Docker clause understates the ordering. It reads "Docker, which needs every other build, skips with it", which puts Docker and github-release in the same skip. Docker is a needs: of github-release, so it skips before, and its skip is part of what skips the release rather than a companion to it. The distinction matters to an auditor tracing which job's guard actually admits a disabled target.

D1.6's publisher-stub claim is unconditional and this repository's own file appears to falsify it. The item says "The publisher stub's validation job names the secret", and this hub's publish-release.yml validate job passes no secrets: key at all, even though validate-task.yml declares CODECOV_TOKEN. The hub is exempt by its registry types, source-only and docs, so the claim is not wrong about the repositories it governs, but a reader checking it against the nearest available example finds a counterexample with nothing saying why. Low confidence, and a scoping fix rather than a content one.

Recorded here rather than fixed, since #1213 is scoped to the one non-executable recovery phrasing that promotion #1203 introduced.