Six D4 items in the condensed catalog drop the clause that carries their meaning

[ptr727]

A whole-unit canonical pass over ## D4: Release and Publish in .agents/skills/workflow-ci-contract/references/d-guarantees.md found six defects beyond the one #1212 fixes. Each is a condensation that drops the clause carrying the item's meaning, so a reader holding only the catalog reaches a different answer than WORKFLOW.md gives.

D4.4 asserts and denies the same output in one sentence

an unchanged version re-pushes nothing ... and Docker always re-pushes by design

WORKFLOW.md D4.4 resolves this and the condensation drops both resolvers: the NuGet and PyPI publish steps "are not statically gated on existence. They run and the server dedupes", and Docker's re-push happens "independently of the release-create skip". A unit-only reader gets a flat contradiction with nothing to settle it.

D4.4 drops the audit disposition for the reader most likely to need it

The source adds "which is why a dispatch-only publisher records this item's skip leg as unreachable rather than failed". This hub and every source-only repository in the fleet are dispatch-only, so the omission lands hardest on the common case. Adjacent to #1204, which is the same seam from the scenario side.

D4.5 names a per-target skip the publish path does not produce

so a disabled or unchanged target, skipped rather than failed, still lets the release be cut and the image pushed

"Unchanged" has no mechanism here. publish-plan-task.yml carries no paths filter, the changes job lives in the pull request workflow under D1.1, and the release task gates leaves on inputs.enable_* alone. Nothing in the publish path skips a target for being unchanged. This is carried verbatim from WORKFLOW.md D4.5, so the fix belongs at that source, and it would hold only for a downstream publisher that added a per-target filter, which nothing documents.

D4.3 may name the wrong failing step

or the release-create step fails on unmatched files

With expect_release_assets left true and no release-asset-* produced, the download step runs first, under if: ${{ inputs.expect_release_assets }} with pattern: release-asset-${{ inputs.branch }}-*, and actions/download-artifact errors on an empty match before the create step's fail_on_unmatched_files is ever evaluated. The pinned action's empty-pattern behavior was not confirmed offline, so this is flagged rather than asserted. WORKFLOW.md D4.3 carries the same claim, so the fix, if the behavior confirms it, belongs there.

D4.1 drops the source-only trigger case

It lists three publish triggers and omits "A source-only repo publishes on dispatch only", so a source-only repository, this hub included, reading only this unit expects a push and a schedule leg it does not have.

D4.6 drops its input scope

The source scopes it to "a deploy to a filesystem on a host the project owns". Without that, a unit-only reader cannot tell the item is deploy-repository-only rather than fleet-wide. The file's preamble does not repair this: its "an item names an input only where the guarantee applies to a particular trigger or state" describes WORKFLOW.md's labelled-clause convention, not this catalog, which is the defect #1205 covers.

Verified correct, listed so a later pass need not redo them

D4.2's target_commitish claim (build-release-task.yml:354 pins needs.get-version.outputs.GitCommitId), D4.3's prerelease rule and its no-file-target caller shape, D4.5's needs: topology and the !failure() && !cancelled() guards on both github-release and build-docker, and the publish-<target> job sitting in the publisher after the release task.

Related

Found while fixing the D4.5 recovery clause for #1212, raised by CodeRabbit on #1203. Related to #1205 (the same file's preamble), #1206, #1207, #1208 and #1201.

[ptr727]

Two corrections and one addition.

Correction to this issue's own text. It refers to "the one #1212 fixes" and "for #1212", which is this issue's own number. The fix is PR #1213. My error when filing, and the references are wrong rather than the substance.

Addition, from a second whole-unit pass. The D4.5 recovery clause contrasts against the wrong alternative. It warns a reader off cleanup, which nobody reaches for, while the move a maintainer actually reaches for on a failed push is GitHub's Re-run failed jobs, and WORKFLOW.md D5.2 documents that route as broken on exactly this path:

Deleting the nuget-build-* or pypi-build-* artifact on the failed-push path costs the run its Re-run failed jobs route, since the re-run's download finds nothing

That sentence survives in neither the condensed D4.5 item nor the condensed D5.2 item, so the whole catalog leaves the one destructive wrong move unnamed. A reader working from the condensed file alone hits Re-run failed jobs, the download finds nothing, and they learn the artifact is gone. Carrying the contrast into D4.5's clause, D5.2's item, or both would close it.

Two lower-confidence notes from the same pass, recorded so a later pass need not re-derive them. The condensed D4.5 drops the terminal state the source names, "publishes a further version and leaves the first one's release without its package", so a reader learns the recovery window expires but not that the first release is then permanently package-less. And "repairs that version" is slightly stronger than the source's "runs its push again", since a persisting outage or a still-wrong trusted-publishing policy fails again.

PR #1213 fixes only the non-executable recovery phrasing, in all four D4.5 copies. Everything above stays here.

[ptr727]

One more for this issue's class, and a decision worth making deliberately rather than by omission.

PR #1213 restructured WORKFLOW.md D4.5 so the branch-not-commit constraint leads rather than trails, after Copilot found that a trailing placement could reintroduce the operator mistake the change exists to prevent. The commit reclassified that placement from a style note to a correctness property of the item.

The condensed D4.5 does not carry that constraint at all. It reads:

The recovery is a re-dispatch rather than a cleanup, and it repairs that version only while the branch tip has not moved, since NBGV derives the version from git height, so a re-dispatch after the tip has moved publishes a further version and leaves the first release without its package.

So the catalog gives the bound and not the reason a commit-SHA dispatch is impossible. A reader holding only this file learns the recovery expires, and does not learn that workflow_dispatch cannot target a commit, which is the thing that stops them trying. An earlier pass on #1213 judged the omission legitimate condensation, on the reasoning that "the branch tip" implicitly anchors the dispatch to a branch. That reasoning is defensible and it is the opposite of the conclusion Copilot's finding reached about the authority.

The choice is between two consistent positions rather than between right and wrong:

1. The constraint is load-bearing wherever the recovery is stated, in which case the condensed item gains a clause naming it, roughly "a dispatch names a branch and never a commit".
2. The constraint is context for the authority only, in which case the condensed item stays as it is and the asymmetry is deliberate, since the file's preamble already routes a reader to WORKFLOW.md when exact wording decides a verdict.

What should not stand is the current state, where the two surfaces differ because one was reviewed and the other was not.

Also worth recording, from the same pass: the condensed item says the re-dispatch "repairs that version", which is looser than the authority's "refreshes the failed version's release". A version is not repaired, its release is.

The four findings already in this issue, and the three in the comment above, are unchanged. This is a fifth.