Adopt minimal caller concurrency policy

Author: MariusStorhaug

docs/content/get-started/repository-setup.md

@@ -54,7 +54,8 @@ on:
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
-  cancel-in-progress: false
+  queue: ${{ github.event_name == 'pull_request' && 'single' || 'max' }}
+  cancel-in-progress: ${{ github.event_name == 'pull_request' }}
 
 permissions:
   contents: read
@@ -75,6 +76,10 @@ the pull-request trigger handles CI, prereleases, and prerelease cleanup. See
 [Workflow inputs](../reference/workflow-inputs.md) for what each permission is used for, and
 [Calling the workflow](../guides/calling-the-workflow.md) for passing test secrets and variables.
 
+The caller-level concurrency block retains production and manual work while replacing obsolete work for the same pull
+request. The fallback expression uses the pull-request number for every pull-request action, including `closed`; other
+events use their Git ref. Keep its group distinct from the reusable workflow's prefixed group.
+
 ## 4. Add the settings file
 
 Create `.github/PSModule.yml`. An empty file is valid — every setting has a default:

docs/content/guides/calling-the-workflow.md

@@ -37,7 +37,8 @@ on:
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
-  cancel-in-progress: false
+  queue: ${{ github.event_name == 'pull_request' && 'single' || 'max' }}
+  cancel-in-progress: ${{ github.event_name == 'pull_request' }}
 
 permissions:
   contents: read
@@ -59,11 +60,10 @@ Stable releases are evaluated from a push to the default branch. A merged pull r
 release notes; a direct default-branch push or a manual dispatch uses the default `Patch` bump and commit-based notes.
 Keep the `pull_request` trigger for CI, prereleases, and prerelease cleanup.
 
-The concurrency key keeps a pull request distinct from a default-branch push, so the close-event cleanup and the
-resulting stable release do not serialize as one run. Keep `cancel-in-progress: false`: a release-capable run mutates
-the PowerShell Gallery, GitHub Releases, and tags, so later runs must queue rather than interrupt it.
-The reusable workflow uses its own prefixed concurrency group, so it cannot queue behind the caller while the caller
-waits for it to finish.
+The concurrency key keeps each pull request distinct from the default branch, so a close event interrupts only its own
+pull-request activity and does not block the resulting stable release. Pull-request events replace obsolete activity;
+all other events, including a manual default-branch release, retain the maximum native queue. The reusable workflow
+uses a distinct prefixed concurrency group. Do not give the caller the reusable workflow's group name.
 
 ## Passing test data
 

docs/content/specification/design.md

@@ -19,10 +19,10 @@ documented in [Workflow inputs](../reference/workflow-inputs.md).
 
 ### Trigger admission
 
-The [workflow trigger design](workflow-triggers/design.md) owns admission before processing: a retained production queue,
-replaceable pull-request activity, and protected closure coordination. Concurrency belongs to the reusable entry point,
-not to caller templates or individual processing stages. The complete processing call retains its admission slot through
-the final enabled stage; closure stops obsolete activity before optional prerelease cleanup.
+The [workflow trigger design](workflow-triggers/design.md) owns caller-level admission before processing: a retained
+production queue and replaceable pull-request activity. The caller's workflow-level group covers the complete reusable
+workflow call through its final enabled stage; the reusable workflow identifies closure and performs optional prerelease
+cleanup.
 
 ### Composed reusable workflows
 

docs/content/specification/spec.md

@@ -61,7 +61,7 @@ Versions MUST follow [SemVer 2.0.0](https://semver.org/) (`vMAJOR.MINOR.PATCH` o
 
 ### NFR2 — Serialized releases {#nfr2}
 
-Production pipelines MUST execute serially from planning through their final enabled stage, retaining pending work within the platform's maximum queue capacity. Pull-request updates MUST supersede obsolete activity without canceling production or closure cleanup. The [workflow trigger spec](workflow-triggers/spec.md) owns admission, ordering boundaries, and cleanup guarantees.
+Production pipelines MUST execute serially from planning through their final enabled stage, retaining pending work within the platform's maximum queue capacity. Pull-request updates MUST supersede obsolete activity without canceling production or work for other pull requests; closing a pull request supersedes its activity. The [workflow trigger spec](workflow-triggers/spec.md) owns admission, ordering boundaries, and cleanup guarantees.
 
 ### NFR3 — Single production authority {#nfr3}