Tracker: `WORKFLOW.md > 4. Behavioral Contract: Expected Outcomes`

[ptr727]

Tracker for WORKFLOW.md > 4. Behavioral Contract: Expected Outcomes. Filed under #1315's roll-up of the open prose backlog: every finding a bundle issue enumerated against this unit is listed here once, one line each, naming the issue it came from, and the bundle is closed as a duplicate of this tracker so the finding is not lost and the bundle stops being a unit of work. A new pre-existing finding on this unit gathers here per pr-review-conduct's Merge Gate, numbering continuing this list. This tracker closes when the unit is rewritten and each line below is settled or superseded.

1. D1.6 names the hub's spec/secrets.json typeMechanisms mapping, which the hub-hosted-tool exception does not cover, since it is data a workflow reads rather than a script a reader runs. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (7 more carried-content defects from a downstream PR review (merge-and-release, python-codestyle, GOVERNANCE.md, WORKFLOW.md) #1092)
2. dotnet test under the exact D1.6 MTP configuration reports zero tests locally while CI reports 21 on the same SDK, reading to a migrator as a broken repo rather than a broken driver. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (D1.6 MTP config: dotnet test reports zero tests locally while CI reports 21, same SDK #1122)
3. D1.6 states the CI invocation and nothing about a supported local one, and the plain dotnet test its docs asserted is unverified and demonstrably fails on at least one machine. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (D1.6 MTP config: dotnet test reports zero tests locally while CI reports 21, same SDK #1122)
4. The net10.0 versus net10.0|x64 target string is a cheap diagnostic separating 'driver resolved no architecture' from 'tests did not register' and is written down nowhere. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (D1.6 MTP config: dotnet test reports zero tests locally while CI reports 21, same SDK #1122)
5. D1.6 does not mention UseMicrosoftTestingPlatformRunner, though without it the built executable is not an MTP host, so the fleet should decide it deliberately. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (D1.6 MTP config: dotnet test reports zero tests locally while CI reports 21, same SDK #1122)
6. D1.6 says CODECOV_TOKEN reaches the reusable validator via secrets: inherit, which validate-task.yml's explicit secrets: block and a live carrier falsify. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (WORKFLOW.md D1.6 says secrets: inherit while reusable-workflows.md says it is never used, and the carried file is the wrong one #1173)
7. D4.5 names a required "gate" for a package publish job and supplies only a needs: edge, while the shipped publish-nuget stub says no separate release gate is needed. [WORKFLOW.md > D4 - Release / Publish] (Six more WORKFLOW.md section 4 and 5 claims a carrier cannot act on #1219)
8. D5.1's MAY exemption for an intermediate consumed within the same run covers the whole population its MUST binds, since section 3 defines every artifact as intra-run. [WORKFLOW.md > D5 - Resource Cleanup] (Six more WORKFLOW.md section 4 and 5 claims a carrier cannot act on #1219)
9. D5.2 bills the package-artifact deletion as costing the Re-run failed jobs route and credits the same deletion in its Prevents clause. [WORKFLOW.md > D5 - Resource Cleanup] (Six more WORKFLOW.md section 4 and 5 claims a carrier cannot act on #1219)
10. Section 4's preamble scopes Input: to a trigger or state, but D1.6's and D2.4's Input: are repo or workflow shapes it assigns to items carrying none. (Six more WORKFLOW.md section 4 and 5 claims a carrier cannot act on #1219)
11. D1.6's "the publisher stub's validation job names the secret" is false of this repository's own publish-release.yml, which passes no secrets: key. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Six more WORKFLOW.md section 4 and 5 claims a carrier cannot act on #1219)
12. D4.5's re-dispatch recovery is a TOCTOU: workflow_dispatch resolves github.sha at dispatch, so a push in the window mints a new release rather than erroring. [WORKFLOW.md > D4 - Release / Publish] (Six more WORKFLOW.md section 4 and 5 claims a carrier cannot act on #1219)
13. D1.6's 'every C# and Python repo that has tests' is falsified by its own detection: Foo.Test.csproj and a non-root Python subtree have tests the leg never reaches. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Whole-Unit Passes Over WORKFLOW.md Sections 4 and 5 Raise Twelve Pre-Existing Contract Defects #1242)
14. D1.6's written-report check guards the Python leg only; the C# prefix loop tolerates an empty directory and the best-effort upload leaves a green job. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Whole-Unit Passes Over WORKFLOW.md Sections 4 and 5 Raise Twelve Pre-Existing Contract Defects #1242)
15. D1.6 says a non-MTP repo keeps its existing pin, which Dependabot's patterns: ['*'] github-actions group and D8.1 auto-merge defeat, with no ignore rule named. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Whole-Unit Passes Over WORKFLOW.md Sections 4 and 5 Raise Twelve Pre-Existing Contract Defects #1242)
16. D1.6's Dependabot-store justification is inert since no shipped PR stub passes a secrets: key, and 'skip silently' mis-describes a step that runs and is swallowed by fail_ci_if_error: false. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Whole-Unit Passes Over WORKFLOW.md Sections 4 and 5 Raise Twelve Pre-Existing Contract Defects #1242)
17. D1.6's codecov-cli finder claim is unversioned and unverifiable, so a carrier cannot tell a required workaround from an incidental one. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Whole-Unit Passes Over WORKFLOW.md Sections 4 and 5 Raise Twelve Pre-Existing Contract Defects #1242)
18. D1.6's 'with .gitignore the full source of truth' is ambiguous over the exclusion list, the three examples, or coverage paths generally. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Whole-Unit Passes Over WORKFLOW.md Sections 4 and 5 Raise Twelve Pre-Existing Contract Defects #1242)
19. D1.1's negation-filter claim holds only where the negation list excludes .github/workflows/**; a filter omitting workflow paths violates D1.4 too. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Whole-Unit Passes Over WORKFLOW.md Sections 4 and 5 Raise Twelve Pre-Existing Contract Defects #1242)
20. D4.5's re-dispatch recovery is an unguarded TOCTOU race: a push between reading the branch tip and dispatching publishes a different commit and version. [WORKFLOW.md > D4 - Release / Publish] (Whole-Unit Passes Over WORKFLOW.md Sections 4 and 5 Raise Twelve Pre-Existing Contract Defects #1242)
21. D4.5's 30-day re-run window is stated as a constant, but re-run availability also depends on per-repository log retention, which can be far shorter. [WORKFLOW.md > D4 - Release / Publish] (Whole-Unit Passes Over WORKFLOW.md Sections 4 and 5 Raise Twelve Pre-Existing Contract Defects #1242)
22. D9.1's 'sole exception: the documented lagging-tag tool' names no tool, so a reader with only this unit cannot audit the exception. [WORKFLOW.md > D9 - Style / Static (See Section 2)] (Whole-Unit Passes Over WORKFLOW.md Sections 4 and 5 Raise Twelve Pre-Existing Contract Defects #1242)

[ptr727]

Pre-existing findings from #1385's whole-unit reads of this section, three reads of WORKFLOW.md section 4 and three of the same text as workflow-ci-contract carries it. One line each, numbered on from item 22, with the item the reader named. Repeats of item 8 (D5.1's MAY exemption), item 22 (D9.1's unnamed tool), #1200 item 2 (D4.4's Output against Docker), and #1200 item 4 (D9.3's scope) were raised again and are not listed.

23. D1.6 says every pull request stub's validation job passes no secrets: key and a repo whose coverage must reach Codecov "adds the mapping there itself", which read with "Required for every C# and Python repo that has tests" makes every conforming repo hand-patch the shipped stub, and a stub-faithful repo skips the upload silently, the failure the item's Prevents: clause rules out. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
24. D1.6's "its existing pin on the reusable validator" has no antecedent, since nothing in the unit says a caller pins the validator to a ref. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
25. D1.6's reason for the lint-only exemption, "nothing there is built or packaged to report on", is false against spec/project-types.json python.coverage.codecov, where the lint-only suite runs under coverage and only the upload is absent. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
26. D1.6's "Required for every C# and Python repo that has tests" is contradicted in the same item by the lint-only exemption "whatever tests it carries", and the unit never says which wins. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
27. "Shipped stub" in D1.2 and D1.6 is never defined or located in the unit, so a reader cannot check the job name or the secrets: shape it asserts. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
28. D2.2's "github-release ... does not opt out" is contradicted by D4.5, where github-release carries !failure() && !cancelled(), which D7.4 names as a status-check function admitting a skipped needs: job, and the preceding sentence names always() as the only opt-out where D7.4 names two. [WORKFLOW.md > D2 - Input/State Validation at Entry] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
29. D3.3's "bumped only for a functional change by the maintainer" binds to the patch, which git height increments on every commit, where the clause belongs to the major.minor floor in the previous sentence. [WORKFLOW.md > D3 - Versioning and Classification] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
30. D4.4's "records this item's skip leg as unreachable rather than failed" names a recording scheme the unit never introduces, and section 5B's table records that leg as N/A. [WORKFLOW.md > D4 - Release / Publish] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
31. D4.5's "--failed works in that case alone" leaves that route unbounded while D5.4's retention-days: 1 expires the surviving artifact within a day, where the full re-run gets its 30-day bound in the same paragraph. [WORKFLOW.md > D4 - Release / Publish] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
32. D4.5's "a disabled or unchanged target (skipped, not failed) still lets docker push" names a per-target "unchanged" skip the publish path does not produce, since the paths filter lives in the pull request workflow under D1.1 and the release task gates leaves on enable_<target> alone. [WORKFLOW.md > D4 - Release / Publish] (Six D4 items in the condensed catalog drop the clause that carries their meaning #1212, via Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
33. D4.3's "the release-create step fails on unmatched files" may name the wrong failing step, since with expect_release_assets left true and no release-asset-* produced the download step's empty pattern errors first, flagged rather than asserted. [WORKFLOW.md > D4 - Release / Publish] (Six D4 items in the condensed catalog drop the clause that carries their meaning #1212, via Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
34. D6.1's "Canonical for single-target." is a subjectless fragment with two opposite readings for a multi-target repo, which D6.4 hands the same verbatim github-release body. [WORKFLOW.md > D6 - Seam / Architecture Conformance] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
35. D7.3 contradicts WORKFLOW.md section 2 "Boolean inputs" on whether workflow_dispatch delivers strings and whether an if: compares both forms, and the fix belongs at section 2. [WORKFLOW.md > D7 - Concurrency, Permissions, Safety] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
36. D9.4's "only on push" reads as the push event, under which the schedule and dispatch publishes D4.1 names never write the cache. [WORKFLOW.md > D9 - Style / Static] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
37. D5.5's Prevents: clause, D8.1, and D9.4 each carry a semicolon in prose, one root cause across three items. [WORKFLOW.md > D5 - Resource Cleanup, D8 - Bots / Automation, D9 - Style / Static] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)

[ptr727]

One more from #1385's later reads of the same unit, numbered on from item 37. The rest of those reads repeated items 26, 28, 29, 30, and 34, and #1200 item 8.

38. D1.6 requires CODECOV_TOKEN in the Dependabot secret store so a bot pull request's run does not skip the upload, while the item's own default shape three sentences later is that "every pull request stub's validation job passes no secrets: key at all", under which no pull request run reads any store. The Dependabot-store requirement holds only once a repo has opted into pull request coverage, and the unit never says it is conditional on that. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)

[ptr727]

Eleven more from #1385's fifth read of this unit, numbered on from item 38. Correction to item 37: the semicolon is in D5.6's Prevents: clause, not D5.5's.

39. D1.6's "a token and a codecov.yml would then gate on a report nothing produces" contradicts the same item, where the upload is best-effort and codecov.yml sets informational: true, so a token and a codecov.yml gate on nothing. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
40. D1.6's "Two details of the invocation are equally load-bearing" is followed by one detail of the invocation and one rename step after it, so a reader counting details cannot tell what the second failure is. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
41. D3.4's Prevents: "a renamed/extra branch silently getting a plain version" is not prevented by its Output, which appends .dev0 on develop only, so a renamed branch gets exactly the plain version, and D2.3's ref gate is what prevents it. [WORKFLOW.md > D3 - Versioning and Classification] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
42. D4.3's "The release-create step fails when no assets exist" cannot fire if the README and LICENSE its Output attaches count as assets, and the unit never says whether they do. [WORKFLOW.md > D4 - Release / Publish] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
43. D4.5's failed-push recovery describes a run where every build succeeded, a state the item's Input: ("one enabled build fails") excludes and its Output: ("nothing publishes") contradicts, so a reader routing by Input: never reaches it. [WORKFLOW.md > D4 - Release / Publish] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
44. D6.4's "updates all of" list omits expect_release_assets, which dropping the last file target or adding the first also flips per D4.3, so a caller following the list literally lands on D4.3's release-create failure. [WORKFLOW.md > D6 - Seam / Architecture Conformance] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
45. D7.3's Prevents: "a comparison against the boolean true, which can never fire" contradicts the item's own statement that inputs.<name> == true fires on both paths and is merely redundant. [WORKFLOW.md > D7 - Concurrency, Permissions, Safety] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
46. D8.3's "It ships via a develop dispatch (prerelease) or the next promotion to main" contradicts D4.1, under which the promotion merge ships nothing and the pin ships on the next main publish after it. [WORKFLOW.md > D8 - Bots / Automation] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
47. D8.3's "The main pin push publishes via the release gate" is unverifiable from the unit, since D4.1 admits a push publish only under the codegen App or Dependabot actor and the unit never says the tracker's resolver or the merge-bot pushes under one of those. [WORKFLOW.md > D8 - Bots / Automation] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
48. D8.4 states its applicability as an unlabeled clause before Output: where the section's intro reserves Input: for that, the only item in the section to do so, so a reader routing by label reads it as binding every run. [WORKFLOW.md > D8 - Bots / Automation] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
49. D8.4's scope names a PR-author comparison, which is the merge-bot's own gate, and then makes the annotation optional for the merge-bot two sentences later, so the item's MUST and its exemption cover the same gate. [WORKFLOW.md > D8 - Bots / Automation] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)

[ptr727]

Two more from #1385's fifth read of the same text as the skill carries it, numbered on from item 49. That read also confirmed item 37's semicolon is in D5.6.

50. D9.5's "Line endings follow .editorconfig" drops the YAML-is-LF half of WORKFLOW.md section 2's rule, "Workflow YAML is LF ... Other files follow .editorconfig", so a CRLF-default repo with no [*.yml] override satisfies D9.5 with workflow files section 2 forbids. [WORKFLOW.md > D9 - Style / Static] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)
51. D1.6's "the hub's spec/secrets.json typeMechanisms mapping is not claimed for that repo, and the absence is not drift" is contradicted by that file's own note, which says a csharp or python repo must carry the mapped mechanism regardless of opt-in, with no tests or profile condition. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Carry WORKFLOW.md Section 4 Into workflow-ci-contract as an Include #1385)

[ptr727]

Appended from the class 6 whole-unit reads of this section and of its generated include in workflow-ci-contract (#1388), numbering continuing the list above. Two notes on existing items: item 35's and item 50's "WORKFLOW.md section 2" now reads as GOVERNANCE.md "Workflow YAML Conventions", since section 2 points there rather than restating it, and item 50's "Workflow YAML is LF" half has its home in the comment-and-doc-style Skill's line-endings reference, which GOVERNANCE.md "Documentation Style Conventions" routes to.

52. D2.4's example "repositories XOR manifest+manifest-jq" names the pair as exclusive-or, while the hub's docker-readme task accepts neither source and defaults to the calling repository, so the all-empty case passes by design where the item says a half-filled combination fails fast. [WORKFLOW.md > D2 - Input/State Validation at Entry] (Cut WORKFLOW.md Section 2 to a Pointer at Workflow YAML Conventions #1388)
53. D3.4's "NBGV git height in the release segment keeps develop ahead" does not hold right after a merge-commit promotion, where main's height is one above the develop tip it merged, so the .dev0 build sorts below the current release until develop accrues two further commits, and the MUST names no rule for that window. [WORKFLOW.md > D3 - Versioning and Classification] (Cut WORKFLOW.md Section 2 to a Pointer at Workflow YAML Conventions #1388)
54. D1.5's Prevents: "a paths-filter error letting a target-changing PR merge unbuilt" is contradicted by the same item's "treat a skipped smoke build as pass", since a filter entry missing a touched path skips the build and the aggregator passes, and D1.1 is the item that prevents the named failure. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Cut WORKFLOW.md Section 2 to a Pointer at Workflow YAML Conventions #1388)
55. D7.4's Output requires an explicit success/skipped allowlist paired with a status-check function, while D4.5 prescribes "the same !failure() && !cancelled() guard" alone for github-release and Docker, and the unit does not say whether D4.5's shape satisfies D7.4. [WORKFLOW.md > D7 - Concurrency, Permissions, Safety] (Cut WORKFLOW.md Section 2 to a Pointer at Workflow YAML Conventions #1388)
56. D8.3 requires the tracker's bump-branch-prefix and branches to match a merge-bot rule, while D8.1's Output enumerates the merge-bot's behavior for Dependabot alone and states no head/base rule, so a merge-bot conforming to D8.1 as written is one D8.3 says never fires. [WORKFLOW.md > D8 - Bots / Automation] (Cut WORKFLOW.md Section 2 to a Pointer at Workflow YAML Conventions #1388)
57. D5.6's Prevents: clause carries a semicolon in prose, where item 37 names D5.5, whose current text has none, so item 37's D5.5 reference may point at D5.6. [WORKFLOW.md > D5 - Resource Cleanup] (Cut WORKFLOW.md Section 2 to a Pointer at Workflow YAML Conventions #1388)

[ptr727]

Two more from a #1311 second-round pass (complete-brief whole-unit read, opus tier, no PR — read-only) over this section and its generated include in workflow-ci-contract, numbering continuing the list above. The reviewer was briefed with the full text of items 23-57 before reading, and confirmed all 35 still present as worded (0 resolved) without re-deriving any of them — these two are the only findings that did not match an existing item by meaning.

58. D2.3, D4.1, and D8.3 each hard-code main/develop as literals ("a dispatch from any ref other than main or develop fails fast"; "publish on a code-affecting bot push to main ... a dispatch of main/develop"; "The main pin push publishes via the release gate, while a develop pin does not auto-publish"), while D3.2 requires "The default-branch literal in the gate, the prerelease expression, and version.json MUST all name the repo's real default branch." D3.2's own wording admits a fleet repo's real default branch may not be main, and the section states no rule for reading main in D2.3/D4.1/D8.3 as "the repo's default branch" rather than as the literal itself, so a repo whose default branch isn't main cannot tell which reading of its own gate binds. [WORKFLOW.md > D2/D3/D4/D8] (Why the Backlog Grows: Prose Review Has No Fixed Point, and a Plan to Keep the Rigor Without It #1311 second round)
59. D1.4's Implication: ("a workflow-only change is not smoke-built, but actionlint still validates it in CI") rests on an actionlint gate that nothing else in the section requires. D1.2's validator description covers doc/repo gates plus dotnet test/pytest; D9.1-D9.5 cover SHA pinning, suffix rules, set -Eeuo pipefail, Docker cache, and line endings; none require actionlint. A repo can satisfy every applicable D-guarantee with no actionlint anywhere, at which point D1.4's stated reassurance for deliberately not smoke-building a workflow-only change is false for that repo. [WORKFLOW.md > D1 - PR Fast-Feedback (Smoke)] (Why the Backlog Grows: Prose Review Has No Fixed Point, and a Plan to Keep the Rigor Without It #1311 second round)

[ptr727]

D6.2 now stands unqualified, with the evidence two withdrawn attempts produced

#1394 collapsed 5A, and the text it deleted was the sole home of D6.2's publisher exception:
"The inputs.branch rule above binds a called leaf, while a publish-<target> job is in the
publisher and reads github.ref_name correctly." D6.2 now reads only "branch-derived config reads
inputs.branch, never github.ref_name."

This is filed rather than fixed because moving the carve-out into D6.2 was attempted twice in
#1394 and withdrawn twice, each time after a review disproved the wording rather than the intent.
Section 4 is pull request 2's, and the evidence below is what that pull request needs.

The rule as written is falsified by the tree in four places

• docs/reusable-workflows.md lines 507, 538, 568 and 584: the canonical publish-nuget and
  publish-pypi stubs key off github.ref_name.
• .github/workflows/publish-release.yml:25: the D2.3 dispatch guard can only be written against
  github.ref_name.
• publish-release.yml:63: branch: ${{ github.ref_name }} is how the logical branch comes into
  existence at all, so the rule forbids the expression that produces the value it mandates.
• reports/aiopurpleair/audit.md lines 48 and 85 show an auditor filing exactly this shape of D6.2
  finding while 5A's carve-out was still in place, so the carve-out was not preventing the false
  positive it existed for.

What each withdrawn attempt proved

1. Scoping the rule to "a called leaf" left the release task ungoverned, though section 3's
   Reusable-Task Parameter Contract says "Every leaf and the release task take ref, branch",
   and github-release holds the two largest pieces of branch-derived config in the contract
   (D4.3's prerelease and D6.1's release-asset-<branch>-* download, both inputs.branch in
   build-release-task.yml:317 and :355). Composite actions have the same problem.
2. Exempting a publish-<target> job by job name left D2.3's dispatch guard and the
   branch: pass-through outside the exemption, both of which the contract requires.
3. Justifying the exemption by the absence of an inputs.branch licenses github.ref_name in
   the PR entry workflow too, where a pull_request event makes it the merge ref rather than a
   branch. The fleet's own entry stub reads github.base_ref || github.ref_name for exactly that
   reason (docs/reusable-workflows.md:338).

So the discriminating property is the publisher's trigger ref always being the branch being built
(D4.1, D2.3), not the missing input, and the governed set is every surface handed the logical
branch: a called leaf, a composite action, and the release task. A fourth position, publish-plan-task.yml,
is a called orchestration task that is none of those three and derives stable from
inputs.ref_name rather than inputs.branch, so any wording has to decide it deliberately.

Also for section 4, from the same review

• D8.2 names no location for its evidence. It reads "Dependabot targets both branches, security
  PRs to default" and never names .github/dependabot.yml, which is the only place that is
  checkable. Every neighbouring item that needs a non-workflow file names it, so this is one gap
  rather than a missing convention.
• The preamble declares two optional clause labels (Input: and Prevents:) and the section
  ships two more it never admits, D1.4's Implication: and D3.5's Note:.
• D9's items break the preamble's own form. "Each is a MUST, stated as the output a
  conforming pipeline produces", and no D9 item carries an Output: clause at all.
• D6.1's "Canonical for single-target." has no subject or verb, so a reader cannot tell whether
  the pattern: download, the release-asset-<branch>-<target> name, or both are what is canonical.
• D6.4's two adjacent sentences conflict under a plain reading: "adding or dropping a target
  updates all of: ... the build-<target> job and its github-release ... needs: entries"
  against "The github-release job body stays verbatim". Section 3 reconciles them ("'Verbatim'
  applies to the github-release job and the version/publish-plan logic, not to the release task's
  job list"), and D6.4 does not carry that distinction.

Refs #1311, #1370, #1394

[ptr727]

Pre-existing findings on this unit from the three review rounds of the #1311 PRs 2/4/6 change,
numbering continuing the list above. None was fixed there, since each sits in text that change did
not rewrite.

60. D6.3's "artifact names are branch-suffixed" produces release-asset-nuget-main if followed
    literally, while D6.1's mandated name infixes the branch (release-asset-<branch>-<target>)
    and build-release-task.yml:317 downloads by pattern: release-asset-${{ inputs.branch }}-*.
    The branch is suffixed only in nuget-build-<branch> and pypi-build-<branch>. Section 3's
    Reusable-Task Parameter Contract carries the same wording, so the fix is one root cause on two
    surfaces. [WORKFLOW.md > D6 - Seam / Architecture Conformance]
61. D6.4's "the build-<target> job" is falsified by build-release-task.yml:153, where the
    dotnet target's job is dotnet-publish rather than build-dotnet-publish, while its input is
    enable_dotnet_publish and its artifact release-asset-<branch>-dotnet-publish. Section 3
    carries the same build-<target> wording. [WORKFLOW.md > D6]
62. D3.5's headline "Wrapper repos may use an external version" states a permission where the
    section preamble says "Each is a MUST". A wrapper repo not driving its version from a
    state file cannot tell whether it violates D3.5 or is outside it. [WORKFLOW.md > D3]

D6.2: the fourth attempt is also disproved, and the exception stays withdrawn

The #1311 PRs 2/4/6 change attempted the publisher exception a third time and withdrew it on the
maintainer's call, so D6.2 remains as develop has it. Recording what this attempt proved, since
the earlier comment on this issue records the first two.

The wording keyed the rule on entry-point count: a called workflow or composite action reads
inputs.branch because the github context in a callee resolves against the caller's run, while
an entry workflow derives the branch from its own event. That is disproved by
.github/workflows/get-version-task.yml, a called workflow whose branch classification comes from
the caller's GITHUB_REF rather than from any input, and D3.1 requires exactly that
("github.ref names it, so NBGV classifies it directly"). The wording left no carve-out for it.
publish-docker-readme-task.yml:90 and :134 (ref: ${{ inputs.ref || github.ref }}) sit in the
same undecided space.

Two further defects the same review found in that wording, worth recording because any fifth
attempt inherits them: the Output: sentence named inputs.branch while the prose cited
publish-plan-task.yml as conforming, and that task declares no branch input at all; and the
exemption's justification cited D2.3, whose own Input: is "a dispatch publish", so it covers one
of the three trigger shapes D4.1 admits for a publisher.

So four attempts have now been disproved, each by a different part of the tree: scoping to a called
leaf strands the release task and composite actions, exempting by job name strands D2.3's guard and
the branch: pass-through, justifying by a missing input licenses github.ref_name in the pull
request entry workflow, and keying on entry-point count contradicts D3.1.