WORKFLOW.md and the Release Skill Carry Further Statements the Tree Contradicts, Found Settling #1540 #1543

Defect

Whole-unit review while settling #1540 and #1539 found these statements contradicted by the tree or by WORKFLOW.md. None was introduced there, and #1524, #1527, #1531, and #1536 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.

WORKFLOW.md section 3, the Orchestration bullet

• "Orchestration is generic and forms the standardization baseline at the job level: the single-branch publisher, the get-version, validate-release, and github-release jobs, and the changes -> smoke-build -> aggregator shape of the PR workflow. These job bodies should not need per-repo edits." The next bullet has the repo edit the publisher (the enable_<target> value it passes, its on.push.paths, a publish-<target> job) and the changes filter entry, output, and smoke-build enable-forward, all inside the job bodies this sentence says need none, and D6.4 says "verbatim" never reaches the paths-filter. The catalog publisher stub calls itself the NuGet-library shape that a Docker or PyPI repo varies. The "verbatim" the next bullet then scopes has no antecedent in the section either.
• The Release Model's "a first plan job (publish-plan-task.yml) decides once and every job gates on it" is the section 3 twin of WORKFLOW.md Sections 4 and 6 Carry Further Statements the Tree Contradicts, Found Settling #1522 #1527's D4.1 item. The hub's own .github/workflows/publish-release.yml runs assert-dispatch-ref first, with plan needing it, and that job refuses a bad ref before plan decides anything, while the catalog stub does start with plan.

WORKFLOW.md D4.5

• "Input: a real publish where one enabled build fails. Output: nothing publishes." does not hold when the build that fails is Docker's. The Docker leaf builds and pushes in one step per matrix leg with no cross-leg gate, and the docker-build-base hook receives push and runs before the image legs, so in a multi-image or build-base repo a failing leg can leave base images or another leg's image already pushed while github-release skips. That is the partial publish the item's Prevents: line rules out. The item's gating argument covers Docker waiting on the other builds, never a failure inside Docker itself.

The release skill's "Per-target subsetting" section

• "A repo still curates, in test-pull-request.yml, its path-filter entry, that filter's output, and the smoke-build enable-forward, all three together per D6.4 ... And, for a package target, the publish-nuget or publish-pypi job" in .agents/skills/operational-vs-release-workflow/references/release-publish-mechanics.md restates D6.4's add/drop list and omits two of its items: the publisher's on.push.paths entries and expect_release_assets where the change adds the first file target or drops the last. A reader dropping the last file target by this list keeps expect_release_assets at its default true, missing the no-asset shape D4.3 requires. The neighbouring "Orchestration vs. build: the override seam" section is now a pointer to WORKFLOW.md section 3 for the same list, so this one could point there too rather than restating it.