Design framework-owned trigger admission and closure coordination

Author: MariusStorhaug

docs/content/specification/design.md

@@ -17,6 +17,13 @@ passes the required secrets. The full caller template is in
 [Repository setup](../get-started/repository-setup.md#3-add-the-caller-workflow), and the interface it targets is
 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.
+
 ### Composed reusable workflows
 
 The main workflow composes work across specialized reusable workflows, each owning a pipeline stage:
@@ -110,6 +117,7 @@ independently; the main workflow pins versions explicitly. The full list is in
 ## Where this connects
 
 - [Spec](spec.md) — the requirements this design delivers.
+- [Workflow triggers](workflow-triggers/index.md) — scheduling requirements and the event-routing design.
 - [Pipeline stages](../reference/pipeline-stages.md) — detailed breakdown of each job.
 - [Calling the workflow](../guides/calling-the-workflow.md) — how to invoke it.
 - [Settings](../reference/settings.md) — the settings file reference.

docs/content/specification/index.md

@@ -13,4 +13,5 @@ delivered. They are aimed at people maintaining Process-PSModule itself. Module
 | --- | --- |
 | [Spec](spec.md) | Requirements — an end-to-end pipeline guaranteeing build, testing, quality gates, documentation, and versioned publication. |
 | [Design](design.md) | How the spec is delivered — a single reusable workflow composing sub-workflows, and the settings contract. |
+| [Workflow triggers](workflow-triggers/index.md) | Production queuing, pull-request supersession, and optional closure cleanup, with a dedicated spec and design. |
 | [Principles and practices](principles-and-practices.md) | The versioning, branching, and colocation principles behind the design. |

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}
 
-Only one release process MUST run against a given version of the codebase at a time. Concurrent releases to the same ref MUST be prevented, so the tag, version counter, and published artifact remain consistent.
+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.
 
 ### NFR3 — Single production authority {#nfr3}
 
@@ -73,7 +73,7 @@ Pipeline failures MUST be visible in the pull request and block merge. Contribut
 
 ### NFR5 — Reproducible and auditable {#nfr5}
 
-The entire pipeline and its decisions MUST be stored in git, so the build is reproducible and auditable from the commit alone. No external configuration, API calls, or out-of-band decisions.
+Pipeline policy and configuration MUST be version-controlled. Each run MUST record its triggering revision and the authenticated event, release, and configuration metadata used for its decisions, so queuing or later metadata changes do not erase the decision trail.
 
 ## Success Criteria
 
@@ -151,6 +151,7 @@ Scenario: Handle documentation generation failure
 ## Where this connects
 
 - [Design](design.md) — how these requirements are delivered.
+- [Workflow triggers](workflow-triggers/index.md) — production, pull-request, and closure scheduling.
 - [Pipeline stages](../reference/pipeline-stages.md) — the job-by-job breakdown of the workflow.
 - [Calling the workflow](../guides/calling-the-workflow.md) — how to invoke the workflow.
 - [Settings](../reference/settings.md) — the settings file and its options.