WORKFLOW.md Sections 3 and 4 Carry Further Statements the Tree Contradicts #1524

Defect

A third round of whole-unit review of WORKFLOW.md while settling #1521 found these statements contradicted by the tree or by the document itself. None was introduced there, and #1522 and #1523 hold the earlier rounds' findings. Each wants checking before it is fixed, since a finding against prose can be a reading the text does not intend.

Section 3, Architecture

• The parameter contract claims every leaf. "Every leaf and the release task take ref, branch (the logical branch that drives config/tags/prerelease), and where relevant smoke." The filesystem leaf the same section describes, deploy-site-task.yml, takes environment, release-id, and site-url and runs as its own dispatch, so "Branch-derived config keys off inputs.branch" cannot hold for it. The build leaves miss it the other way: the release task hands each composite leaf and hook branch, smoke, and semver2 but no ref, since the calling job checks out GitCommitId itself, so the contract names an input they lack and omits the version seam every one of them receives.
• The add/drop recipe omits expect_release_assets. Neither the surface list nor the library worked example mentions it, while D6.4 requires flipping it on the first file target added or the last dropped. A Docker-only or PyPI-only repo following the example keeps false, so the release task's asset download stays skipped and fail_on_unmatched_files stays off, and the new asset is silently never attached. Dropping the last file target without the flip fails every release create.
• Resource Lifecycle misstates D5.2. "the delete is gated to the half of the consumption whose failure would leave it not yet redundant (D5.2 names the two halves)". D5.2 names two kinds of consumer rather than halves, and for a package push it deletes on the failed-push path, where the artifact is still needed for a re-run, stating that cost. A reader applying this sentence keeps that artifact, the opposite of what D5.2 prescribes.

Section 4, Behavioral Contract

• D2.4: "e.g. the docker-readme task's repositories XOR manifest+manifest-jq". publish-docker-readme-task.yml accepts neither source and defaults to the calling repository, refusing only both at once or a half-filled manifest pair, so the rule is at most one rather than exactly one, and a reader taking the example literally fails a valid call.
• D4.4: "They run and the server dedupes (dotnet nuget push --skip-duplicate turns a 409 into success, and PyPI does the same under skip-existing: true)". The server rejects the duplicate and the client flag is what turns that into success, so without the flag a no-op re-run fails its push. Crediting the server invites dropping the flags as redundant.
• D7.2: "A callee's extra scope (e.g. actions: write for cleanup, or id-token: write for OIDC) is granted by the caller and appears at exactly the one entry point that needs it." No reusable callee needs id-token: write any longer, since both package pushes moved into the caller's own publish jobs, and build-release-task.yml and docs/reusable-workflows.md both say no call to the task needs it. The example now points a reader at the grant the docs forbid.
• D4.5: "A package target's separate publish job needs its own gate for the same reason". "The same reason" points at the !failure() && !cancelled() guard github-release carries, while the package publish job correctly carries no if: and relies on success() through its needs:, as the stub's own comment says. Copying that guard onto it runs the job when plan declines to publish, where it fails at the download.
• D8.3: "The main pin push publishes via the release gate, while a develop pin does not auto-publish." That holds only for a publisher with a push trigger reaching the state file, which neither D8.3 nor D4.1 requires, and the documented Docker shape has no push trigger at all, so a wrapper on that shape publishes the pin only at its next schedule or dispatch.