Pin Reusable-Workflow Stubs by Placeholder and Tick the PlexCleaner Gates Item

STANDUP.md

@@ -190,6 +190,8 @@ Choose the destination while scaffolding rather than after. Repo-specific conten
 
 Implement the Actions that satisfy [`WORKFLOW.md`][workflow] for the repo's type (its section 6 per-type walkthrough). Use the source-only subset for a source-only repo, the file-target leaf(s) for a publishing repo, and the two-workflow shape for an operational config repo. Reuse [`catalog/snippets/workflows/`][workflows] as the reference implementation, satisfying the contract by outcome rather than byte for byte.
 
+A caller stub copied from a snippet carries that snippet's minimum known-good hub pin. Resolve each hub `uses:` pin to the latest hub release before committing it, per [`docs/reusable-workflows.md`][reusable-workflows] "Pinning". Dependabot bumps it from there.
+
 ## 4. Apply Settings, Rulesets, and Secrets
 
 **Read the remote and the repository before running anything else here**. That is because this is the first step needing either and every step before it passes without both. The commands follow:
@@ -237,6 +239,7 @@ The same [`AUDIT.md`][audit] run is the on-demand audit for any known repo, and
 
 <!-- Workflow -->
 
+[reusable-workflows]: ./docs/reusable-workflows.md
 [workflows]: ./catalog/snippets/workflows/
 
 <!-- Repo -->

catalog/snippets/workflows/README.md

@@ -2,7 +2,7 @@
 
 The reusable build and publish workflow tasks serve code-shipping repositories. They are **inert reference here** because this repository is source-only. The hub's `.github/workflows/` directory contains both its own entry-point workflows and the reusable tasks downstream repositories reach by pin. Each row below names the canonical caller snippet for one or more `WORKFLOW.md` guarantees. The table intentionally lists snippets rather than every hub-hosted task. The audit checks that downstream Actions satisfy those guarantees, not that they match these bytes. Release-chain hooks are composite actions because each hook is repository-owned content. They are `dotnet-publish`, `build-nuget`, `build-pypi`, `docker-prepare`, and `docker-build-base`.
 
-A caller stub for a hub-hosted task carries no snippet of its own until the task ships in a release. The stub's `uses:` line would pin a commit no release carries yet, which the pin gate rejects. `test-pull-request.yml` and `run-periodic-codegen-pull-request.yml` gained theirs once `2.0.352` released `validate-task.yml` and `run-codegen-pull-request-task.yml`. `publish-release.yml` gained its own once a release carried the renamed .NET publish interface and the package push had moved to the caller's own job. `test-pull-request-smoke.yml` gained its own later, pinned at landing to the same `2.0.587` release as `publish-release.yml`. [`docs/reusable-workflows.md`][reusable-workflows] "Adopting the Type-Specific Tasks" carries the remaining stub shapes as reference until each has a snippet of its own. `get-version-task.yml` and `publish-plan-task.yml` below carry no snippet at all, for a different reason. Each is called as a job inside a larger stub rather than reached by its own top-level caller.
+A caller stub for a hub-hosted task carries no snippet of its own until the task ships in a release. The stub's `uses:` line would pin a commit no release carries yet, which the pin gate rejects. Each snippet's hub pin is a minimum known-good release, moved when the task's interface changes rather than with each release. An adopter resolves it to the latest release, per [`docs/reusable-workflows.md`][reusable-workflows] "Pinning". That document's "Adopting the Type-Specific Tasks" carries the remaining stub shapes as reference until each has a snippet of its own. `get-version-task.yml` and `publish-plan-task.yml` below carry no snippet at all, for a different reason. Each is called as a job inside a larger stub rather than reached by its own top-level caller.
 
 | File | Role | WORKFLOW.md guarantees |
 | --- | --- | --- |