Align .NET Publish Workflow Naming

[ptr727]

Summary

• Anchor the .NET release gate, inputs, job, hook, dependencies, project type, and artifact names on dotnet-publish.
• Use channel-anchored NuGet and PyPI artifact names throughout actions, workflow contracts, docs, specs, and generated skills.
• Replace the nonexistent caller hook lookup with .github/actions/dotnet-publish.
• Withdraw the version-pinned release caller snippet until a hub release carries the renamed interface.
• Document the release configuration contract covered by issue dotnet publish actions should set debug based on branch #810.

Why

The reusable release task mixed legacy target vocabulary with the dotnet-publish-default implementation. Its optional caller hook also referenced a path that does not exist under the consolidated naming contract.

Release-producing .NET paths select Release configuration on main and Debug otherwise. Tests and code generation retain their Debug/default configuration behavior.

Closes #810.

Verification

• actionlint
• shellcheck
• uvx coverage@latest run --source=scripts,spec,host-setup -m unittest discover -s scripts/tests (727 tests passed)
• uv run --no-project python scripts/build_dist.py --check
• uv run --no-project python spec/validate.py
• Diff-scoped prose and sentence-length checks
• EOL and diff checks
• markdownlint-cli2 (0 issues)

[Copilot]

Pull request overview

This PR standardizes the release-chain naming around the dotnet-publish target (replacing the older build-executable/enable_executable naming), updates the caller-hook lookup to the correct .github/actions/dotnet-publish path, and aligns the workflow/documentation surfaces and generated skill distributions to match that contract.

Changes:

• Renamed the reusable release task’s .NET publish target (inputs, job id, hook lookup, dependencies) and updated artifact naming to release-asset-<branch>-dotnet-publish.
• Updated workflow documentation and snippet stubs to use the new dotnet-publish naming and describe the Release-vs-Debug configuration rule.
• Regenerated skill distribution copies and their source digest to reflect the updated guidance text.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
WORKFLOW.md	Updates seam-contract Mermaid labels and per-project-type release-chain documentation to match dotnet-publish naming.
docs/reusable-workflows.md	Aligns the hook catalog, rollout narrative, and example caller input naming to dotnet-publish.
catalog/snippets/workflows/README.md	Refreshes the workflow snippet overview and hook list terminology.
catalog/snippets/workflows/publish-release.yml	Updates snippet caller inputs to enable_dotnet_publish.
.github/workflows/publish-release.yml	Updates hub’s own caller stub to enable_dotnet_publish.
.github/workflows/build-release-task.yml	Renames the .NET publish job/hook wiring and updates downstream needs: references.
.github/skills/operational-vs-release-workflow/references/release-publish-mechanics.md	Updates skill reference text to use dotnet-publish terminology.
.github/actions/dotnet-publish-default/action.yml	Renames the uploaded release-asset artifact to *-dotnet-publish and documents the config rule.
.claude-plugin/fleet-skills/skills/operational-vs-release-workflow/references/release-publish-mechanics.md	Regenerates the Claude skill distribution copy with updated terminology.
.claude-plugin/fleet-skills/.source-digest	Updates the distribution digest to reflect regenerated content.
.agents/skills/operational-vs-release-workflow/references/release-publish-mechanics.md	Regenerates the agent skill distribution copy with updated terminology.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated no new comments.

Suppressed comments (1)

WORKFLOW.md:82

• Mermaid seam-contract diagram uses release-asset-<branch>-nuget, but the NuGet default hook uploads release-asset-<branch>-nugetlibrary (see .github/actions/nuget-push-default/action.yml:113). This mismatch makes the diagram contradict the documented artifact naming contract and the actual implementation.

  nuget[build-nuget] -->|release-asset-<branch>-nuget| store

[ptr727]

Addressed suppressed Copilot finding in 45af97c: WORKFLOW.md:82 now uses the implemented NuGet artifact name, release-asset-<branch>-nugetlibrary, instead of release-asset-<branch>-nuget.

[ptr727]

Addressed in 45af97c. Suppressed finding: Mermaid seam-contract diagram uses release-asset-<branch>-nuget, but the NuGet default hook uploads release-asset-<branch>-nugetlibrary. The diagram now uses release-asset-<branch>-nugetlibrary.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated no new comments.

Suppressed comments (3)

WORKFLOW.md:284

• Docs: Update this console walkthrough to match the current dotnet-publish implementation. The hub default (.github/actions/dotnet-publish-default/action.yml) publishes all runtimes in a single composite-action job and then zips/uploads one release-asset artifact; it does not produce per-runtime publish-- artifacts or require a separate aggregation job.

- **Console / .NET publish application.** The target builds a per-runtime `dotnet publish` matrix. Configuration is Release on `main` and Debug otherwise. The target produces `release-asset-<branch>-dotnet-publish`, a 7z archive named from the project file stem unless `dotnet_publish_asset_name` overrides it. An aggregation job downloads the `publish-<branch>-<runtime>` intermediates with `pattern:` and `merge-multiple:`. It zips them and uploads the single asset. Smoke builds a strict subset of runtimes. The per-runtime upload and aggregation job are both gated `!smoke`, so smoke uploads nothing. The per-runtime intermediates rely on the `retention-days: 1` backstop. S1 smoke-builds the subset after a console change and uploads nothing. S7 attaches the 7z. The non-default leg sets `prerelease=true`, and the default leg sets `prerelease=false`. GitHub marks the stable default release "Latest" automatically.

docs/reusable-workflows.md:493

• Docs: This YAML example is pinned to hub release 2.0.352 (0b07a59...), but that release’s build-release-task interface would not accept the new input name enable_dotnet_publish (it used enable_executable). Copying this stub as written will fail workflow_call input validation. Either keep the 2.0.352-era input names here, or update the pinned SHA/comment (and any surrounding prose that references it) to a release that includes enable_dotnet_publish.

      github: true
      nuget: true
      enable_docker: false
      enable_pypi: false
      enable_dotnet_publish: false
      nuget_project: ./Widget/Widget.csproj

catalog/snippets/workflows/publish-release.yml:64

• Docs/snippet correctness: This catalog snippet still pins build-release-task.yml to hub release 2.0.352 (0b07a59...), but that release would not accept the renamed input enable_dotnet_publish (it used enable_executable). Downstream users copying this snippet will get a workflow_call input validation error unless the pin is updated to a release that contains the rename (or the old input name is kept for the 2.0.352 pin).

      nuget: true
      enable_docker: false
      enable_pypi: false
      enable_dotnet_publish: false
      nuget_project: ./Widget/Widget.csproj

[ptr727]

Addressed the three suppressed current-head findings in cd078c7:\n\n- : the console walkthrough now states that the default runs all runtimes sequentially in one composite-action job, zips the combined output, and uploads one release-asset artifact; it no longer describes per-runtime artifacts or an aggregation job.\n- : the example pinned to again uses that release's interface.\n- : the snippet pinned to again uses that release's interface. The live hub caller uses the renamed input.

[ptr727]

Addressed the three suppressed current-head findings in cd078c7. WORKFLOW.md line 284 now says the default runs all runtimes sequentially in one composite-action job, zips the combined output, and uploads one release-asset artifact; it no longer describes per-runtime artifacts or an aggregation job. The docs/reusable-workflows.md and catalog publish-release examples pinned to 2.0.352 again use the enable_executable interface accepted by that release. The live hub caller uses the renamed enable_dotnet_publish input.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (1)

docs/reusable-workflows.md:88

• Docs consistency (blocking): This table row updates the build-release hook name to dotnet-publish, but the same doc still shows a caller stub using the old enable_executable input (docs/reusable-workflows.md:492) and references the old build-executable-task.yml leaf naming (docs/reusable-workflows.md:425). The catalog snippet it points to also still uses enable_executable (catalog/snippets/workflows/publish-release.yml:63). This leaves the "Adopting the Release Chain" instructions inconsistent with the renamed workflow inputs in this PR.

| `build-release-task.yml` | `dotnet-publish`, `build-nuget`, `build-pypi` | `dotnet-publish-default`, `nuget-push-default`, `pypi-build-default` |

[ptr727]

Addressed the three suppressed findings from the prior head in 6000a06. The WORKFLOW walkthrough now matches the single composite-action job. The unreleased renamed release interface no longer has a catalog snippet pinned to 2.0.352, and the documentation uses a release placeholder until a compatible hub release exists. The same commit also completes the requested scrub of legacy .NET publish, NuGet, and PyPI target vocabulary across current contracts, actions, specs, docs, and generated skill surfaces.

[ptr727]

Addressed the suppressed docs consistency finding from cd078c7 in 6000a06. The adoption section no longer uses the old gate or leaf names, and the incompatible catalog release caller snippet has been removed until a hub release carries the dotnet-publish interface.

[Copilot]

Pull request overview

Copilot reviewed 22 out of 22 changed files in this pull request and generated no new comments.

Suppressed comments (3)

spec/project-types.json:18

• The nuget type's detect markers rely on an optional repo hook file or a command string that lives in hub-hosted actions. Under the reusable-workflow caller stub shape, a NuGet repo can be evidenced by the caller inputs (e.g. nuget_project:) even when no local hook exists, so detection should include that marker to avoid false "not detected" results.

            "detect": [".github/actions/build-nuget/action.yml", "dotnet nuget push"],

spec/project-types.json:26

• The pypi type's detect markers include an optional hook file and the publish action name, but they miss the caller-stub marker that should always be present for a PyPI repo using the default hub hook (pypi_project_dir:). Without it, detection can incorrectly report PyPI as "not detected" when the repo uses hub defaults and carries no local hook.

            "detect": [".github/actions/build-pypi/action.yml", "pypa/gh-action-pypi-publish"],

spec/project-types.json:58

• The dotnet-publish type's detect markers rely on an optional local hook file and System.CommandLine, which is not a reliable signal of a release-producing dotnet publish target under the reusable-workflow contract. Include the caller-stub input marker (dotnet_publish_project:) so detection can validate a declared dotnet-publish type even when the repo uses the hub default hook.

            "detect": [".github/actions/dotnet-publish/action.yml", "System.CommandLine"],

[ptr727]

Addressed all three suppressed detection findings from 6000a06 in 3dfd784. NuGet detection now includes nuget_project:, PyPI detection includes pypi_project_dir:, and dotnet-publish detection includes dotnet_publish_project:, so downstream caller stubs using hub defaults classify without optional local hooks.

[Copilot]

Pull request overview

Copilot reviewed 22 out of 22 changed files in this pull request and generated no new comments.

Suppressed comments (2)

WORKFLOW.md:237

• The .NET publish addendum says "Both sets run sequentially" inside the composite action, but the current dotnet-publish-default implementation selects either the smoke subset or the full runtime set based on inputs.smoke (it does not run both in one run). This wording is misleading relative to the actual behavior.

- **.NET publish:** the smoke runtime set is a strict non-empty subset of the full runtime set. Both sets run sequentially inside one composite-action job. A non-smoke run uploads one `release-asset-<branch>-dotnet-publish` artifact, while a smoke run skips the archive and upload steps.

catalog/snippets/devcontainer/python/post-create.sh:45

• This snippet checks for pyproject.toml relative to the current working directory. The shell style contract requires scripts to be self-locating and not depend on the caller's directory (.github/skills/shell-codestyle/SKILL.md:45-47), so this can silently skip the uv sync warm-up if invoked from a different CWD.

# Pre-warm the uv environment when this repository carries a Python project.
if [[ -f pyproject.toml ]]; then
    uv sync
fi

[ptr727]

Addressed both suppressed findings from 3dfd784 in f294f15. WORKFLOW.md now says the selected runtime set runs sequentially. The devcontainer Python post-create snippet now resolves its own directory, derives the repository root, checks that rooted pyproject.toml path, and passes the root explicitly to uv sync.

[Copilot]

Pull request overview

Copilot reviewed 22 out of 22 changed files in this pull request and generated no new comments.

Suppressed comments (1)

docs/reusable-workflows.md:478

• Docs (minor): In this Release Chain caller-stub example, plan and validate are still pinned to 2.0.352 while publish uses a <hub-main-commit-sha> placeholder. That mixes hub revisions in a single stub and undermines the intent to withdraw the version-pinned release-caller snippet until a hub release carries the renamed interface. Use the same placeholder pin for publish-plan-task.yml and validate-task.yml in this example so all hub workflows are pinned consistently.

    name: Publish project release job
    needs: [plan, validate]
    if: ${{ needs.plan.outputs.publish == 'true' }}
    uses: ptr727/ProjectTemplate/.github/workflows/build-release-task.yml@<hub-main-commit-sha> # <release-tag>
    secrets:

[ptr727]

Addressed the suppressed mixed-pin finding from f294f15 in 8fccb97. The release-chain caller example now uses the same hub-main commit and release-tag placeholders for publish-plan-task, validate-task, and build-release-task.

[Copilot]

Pull request overview

Copilot reviewed 22 out of 22 changed files in this pull request and generated no new comments.