Require the canonical caller template

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Author: MariusStorhaug

docs/content/reference/process-workflow-fleet-standard.md

@@ -141,7 +141,7 @@ decisions before canonical guides, templates, or consumer workflows adopt it:
 
 | Decision | Candidate | Alternatives still open |
 | --- | --- | --- |
-| Contract scope | Standardize the `Process-PSModule` caller job and its shared workflow controls, not every job in the file. | Selected for the candidate; repository-owned jobs remain outside the caller contract. |
+| Contract scope | Keep the file identical to the canonical template except for optional `TestData`. | Selected for the candidate; repository-owned jobs use separate workflow files. |
 | Trigger ownership | The caller owns manual, schedule, default-branch push, and pull-request triggers. | Move some trigger policy into separate workflows or omit selected event classes. |
 | Pull-request activities | Keep all six listed activity types. | Reduce the activity list if a v8 behavior is intentionally unsupported. |
 | Concurrency | Use the workflow plus PR-number-or-full-ref key and cancel only pull-request runs. | Selected for the candidate: PR reconciliation must be resumable; non-PR runs serialize by full ref. |
@@ -189,17 +189,17 @@ fleet campaign. Branch names, `latest`, floating minor tags, and unqualified tar
 | Event gate | Keep the caller unconditional and authorize capabilities in `Plan`. | The reusable workflow owns execution policy; fork pull requests may validate but cannot obtain App credentials, publish, deploy, clean up, or mutate repository state. |
 | Reference | Use the intended internal floating major tag (`v8`) after tag governance is enforced. | Compatible owned releases roll out centrally; breaking releases require a new major and campaign. |
 | Credentials | Explicitly map the three required secrets. | Satisfies the `v7+` contract and prevents unrelated secret inheritance. |
-| Scope | Require one conforming `Process-PSModule` delegation job. | Additional repository-owned jobs do not change caller conformance. |
+| Scope | Require exactly the canonical `Process-PSModule` workflow file. | Repository-owned jobs use separate workflow files. |
 
 ## Allowed caller variation
 
 The only conforming variation from the canonical template is the optional `TestData` secret mapping shown above.
 Callers use it only when module-local tests need caller-defined secrets or variables, and expose only the required
 values in the documented `secrets` and `variables` maps.
 
-Every other field in the Process-PSModule caller contract matches the template exactly. Callers do not add `with:`
-inputs, change schedule timing, add `run-name`, add a caller condition, or broaden permissions. Repository-owned jobs
-may coexist because they are outside the Process-PSModule caller contract; they do not modify the canonical call.
+Every other field in the Process-PSModule workflow file matches the template exactly. Callers do not add jobs, `with:`
+inputs, change schedule timing, add `run-name`, add a caller condition, or broaden permissions. Repository-owned
+automation uses separate workflow files.
 
 ## Variations requiring a decision
 
@@ -214,6 +214,7 @@ an approved structure:
 - a concurrency key other than workflow plus PR number or full ref, or cancellation behavior other than pull-request-only;
 - a caller-level fork or event-authorization condition;
 - trigger-level path filters that bypass Process-PSModule important-file evaluation;
+- any additional job in `.github/workflows/Process-PSModule.yml`;
 - any `with:` input, including `Debug`, `ImportantFilePatterns`, `Prerelease`, `SettingsPath`, `Verbose`, `Version`, or
   `WorkingDirectory`;
 - a schedule other than the canonical `0 0 * * *`;
@@ -237,10 +238,8 @@ evaluating Settings. Privileged-context events such as
 `pull_request_target` remain unsupported unless separately designed to prevent untrusted code from crossing the
 credential boundary.
 
-The contract applies to the shared workflow controls and the `Process-PSModule` delegation job shown above. Repositories
-may define additional jobs in the same file or separate workflows. The inventory reports those jobs for visibility, but
-the contract does not prescribe their implementation. Additional jobs must not weaken or bypass the permissions,
-authorization, trigger, or concurrency controls governing the Process-PSModule call.
+The contract applies to the entire `.github/workflows/Process-PSModule.yml` file shown above. Repository-owned
+automation uses separate workflow files so the canonical caller remains directly comparable across the fleet.
 
 ## Rollout boundary
 

docs/content/reference/process-workflow-lifecycle-design.md

@@ -36,8 +36,8 @@ requested state.
 
 The [Process-PSModule caller contract](process-workflow-fleet-standard.md) contains exactly one reusable-workflow call
 job and the shared top-level triggers, concurrency, permissions, Plan authorization, and credential boundary that govern
-it. Repository-owned jobs MAY coexist in the same workflow file or in separate workflows. They are visible to
-conformance reporting and MUST NOT weaken or bypass the Process-PSModule call boundary.
+it. The file matches the canonical template except for optional `TestData`. Repository-owned automation uses separate
+workflow files.
 
 ## Event authorization
 
@@ -117,8 +117,7 @@ These explicit secret mappings are required. `secrets: inherit` is prohibited. T
 
 When present, `TestData` contains a JSON object with separate `secrets` and `variables` maps. It is omitted when
 unused. It is the only permitted variation from the canonical caller template. Callers do not declare `run-name`,
-alter the canonical schedule, add a caller condition, or pass `with:` inputs. Repository-owned jobs may coexist
-outside this caller contract.
+alter the canonical schedule, add jobs or caller conditions, or pass `with:` inputs.
 
 Built-in `GITHUB_TOKEN` authorizes checkout, repository-local reads, and standard Pages/OIDC deployment within the job
 boundary. Step-scoped GitHub App installation tokens authorize pull-request comments and labels, commit statuses and
@@ -194,7 +193,7 @@ The lifecycle is verified with event payload fixtures and publication fakes befo
 | Stable aggregation | Push, manual-dispatch, and scheduled bursts replace a pending run and prove all unreleased merged pull requests are aggregated. |
 | Caller authorization | Fixtures verify the explicit permissions and credential mappings, App-token failure, and no built-in-token fallback. |
 | Fork authorization | Fixtures verify immutable-metadata-first restricted Settings, no privileged operations, and `pull_request_target` rejection. |
-| Caller boundary | Fixtures verify repository-owned jobs remain visible without weakening or bypassing the reusable-workflow call boundary. |
+| Caller boundary | Fixtures verify exact canonical-template conformance with optional `TestData` as the only variation. |
 
 ## Related
 

docs/content/reference/process-workflow-lifecycle-specification.md

@@ -16,9 +16,8 @@ The lifecycle covers dispatch recovery, scheduled published-artifact validation,
 evaluation, closed-pull-request cleanup, and stable publication after a default-branch push.
 
 The [Process-PSModule caller contract](process-workflow-fleet-standard.md) requires exactly one reusable-workflow call
-job and the shared top-level controls that govern it. Repository-owned jobs MAY exist in the same workflow file or in
-separate workflows, provided they do not weaken or bypass the call's trigger, concurrency, permissions, Plan
-authorization, or credential boundary.
+job and the shared top-level controls that govern it. The workflow file MUST match the canonical template except for
+optional `TestData`. Repository-owned automation MUST use separate workflow files.
 
 ## Functional requirements
 
@@ -319,27 +318,24 @@ Scenario: Gate a privileged job for a restricted fork run
   And it does not create an App token or parse an absent publication configuration
 ```
 
-### FR13 — Caller conformance MUST be limited to the reusable-workflow boundary {#fr13}
+### FR13 — The caller workflow file MUST match the canonical template {#fr13}
 
-A conforming caller MUST contain exactly one Process-PSModule reusable-workflow call job and the shared top-level
-triggers, concurrency, permissions, Plan authorization, and credential boundary that govern it. Repository-owned jobs
-MAY coexist in the same workflow file or in separate workflows. They MUST NOT weaken or bypass any of those controls for
-the Process-PSModule call.
+A conforming `.github/workflows/Process-PSModule.yml` MUST match the canonical template exactly except for optional
+`TestData`. Repository-owned automation MUST use separate workflow files.
 
 #### Behavioral scenarios {#fr13-scenarios}
 
 ```gherkin
-Scenario: Retain a repository-owned job beside the reusable-workflow call
-  Given a workflow contains one conforming Process-PSModule reusable-workflow call job
-  And a repository-owned documentation job exists in the same workflow file
+Scenario: Keep repository-owned automation separate
+  Given a repository needs a documentation job
   When the workflow is evaluated for caller conformance
-  Then the documentation job is reported for visibility
-  And its existence does not make the Process-PSModule call nonconforming
+  Then the documentation job exists in a separate workflow file
+  And Process-PSModule.yml still matches the canonical template
 
-Scenario: Prevent a repository-owned job from bypassing the caller boundary
-  Given a repository-owned job exists beside or outside the caller workflow
-  When it weakens or bypasses the Process-PSModule call's trigger, concurrency, permissions, Plan authorization, or credential boundary
-  Then the caller arrangement is nonconforming
+Scenario: Reject any other caller variation
+  Given Process-PSModule.yml differs from the canonical template
+  When the difference is not the optional TestData mapping
+  Then the caller is nonconforming
 ```
 
 ## Non-functional requirements