docs: scope caller conformance

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

Author: MariusStorhaug

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

@@ -57,6 +57,10 @@ The uniform wrapper is a strong starting point, but it predates the two latest b
 - `v8.0.0` moves stable publication to a default-branch `push`, adds `unlabeled` routing, and requires non-cancelling
   pull-request-or-ref concurrency.
 
+The observed absence of additional jobs is inventory context, not a conformance requirement. The candidate standardizes
+the Process-PSModule reusable-workflow call and the shared top-level controls that govern that call, rather than the
+repository owner's entire workflow.
+
 No current caller has the `v8.0.0` trigger and concurrency contract. The fleet spans nine older versions:
 
 | Version | Repositories |
@@ -131,7 +135,7 @@ decisions before canonical guides, templates, or consumer workflows adopt it:
 
 | Decision | Candidate | Alternatives still open |
 | --- | --- | --- |
-| Wrapper scope | Exactly one reusable-workflow job. | Permit repository-specific jobs in the same file, or define pre/post extension jobs. |
+| Wrapper scope | Exactly one conforming Process-PSModule reusable-workflow call job plus the shared top-level controls that govern it. Repository-owned jobs may coexist in the same file or separate workflows when they do not weaken or bypass that boundary. | Decide only the placement of repository-owned jobs. |
 | 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 PR-number-or-ref key and cancel only superseded pull-request runs. | Use separate groups per event class or disable cancellation for all runs. |
@@ -174,7 +178,7 @@ fleet campaign. Branch names, `latest`, floating minor tags, and unqualified tar
 | Fork authorization | Leave the caller job unconditional. | Plan grants normal fork `pull_request` events only restricted read-only validation capabilities and rejects `pull_request_target` before credentials or repository-defined code run. |
 | 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 `PSGALLERY_API_KEY`, `GitHubAppClientId`, and `GitHubAppPrivateKey`; do not use `secrets: inherit`. | Satisfies the `v7+` contract and prevents unrelated secret inheritance. |
-| Scope | Keep the caller as a single delegation job. | Repository-specific automation remains independently understandable and maintainable. |
+| Scope | Require exactly one conforming Process-PSModule delegation job and its governing triggers, concurrency, permissions, Plan authorization, and credential boundary. | Repository-owned jobs may be reported for visibility but are not nonconforming merely by existing. |
 
 ## Candidate optional elements
 
@@ -202,8 +206,7 @@ approved organization policy until #514 records an approved structure:
 - missing `push` or `unlabeled` triggers;
 - a `cancel-in-progress` expression other than `github.event_name == 'pull_request'` or the old ref-only concurrency key;
 - trigger-level path filters that bypass Process-PSModule important-file evaluation;
-- unrelated additional jobs in the caller wrapper;
-- omitted documented permissions without a verified settings-based least-privilege profile.
+- omitted documented permissions without a verified settings-based least-privilege profile;
 - `with.Debug: true`, which is nonconforming because the reusable workflow default remains `false`.
 
 When required, the optional test-data mapping extends the candidate baseline without broadening it:
@@ -234,9 +237,11 @@ untrusted validation and build inputs; they cannot enable credentials, broaden p
 envelope. This permits ordinary fork contributors to receive the standard workflow green/red validation without
 configuring secrets.
 
-The candidate keeps repository-specific automation in a separate workflow file. That keeps the Process-PSModule wrapper
-identical enough for automated comparison while allowing modules to own unrelated schedules, generation, or integration
-tasks.
+The candidate requires exactly one conforming 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 exist in
+the same file or in separate workflows and are reported only for visibility. Their existence is not nonconforming, but
+they MUST NOT weaken or bypass the Process-PSModule call's trigger, concurrency, permissions, Plan authorization, or
+credential boundary.
 
 ## Rollout boundary
 

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

@@ -34,6 +34,14 @@ Plan resolves the caller event into one release classification before build and
 
 Plan records its classification and release decision in enriched Settings. Downstream jobs consume that Settings object and do not infer policy from events, labels, or repository settings again.
 
+## Candidate caller boundary
+
+The candidate standardizes exactly one Process-PSModule reusable-workflow call job and the shared top-level triggers,
+concurrency, permissions, Plan authorization, and credential boundary that govern it. It does not standardize the
+repository owner's entire workflow. Repository-owned jobs may coexist in the same workflow file or in separate workflows
+and are reported only for visibility. They must not weaken or bypass the Process-PSModule call's trigger, concurrency,
+permissions, Plan authorization, or credential boundary.
+
 ## Candidate event authorization
 
 The caller invokes the reusable workflow without a caller-level fork or event condition. Plan is the event-authorization
@@ -201,6 +209,7 @@ The lifecycle contract is exercised with event payload fixtures and publication
 | Stable aggregation | Bursts of main-push, manual-dispatch, and scheduled fixtures that replace an intermediate pending run and prove the later stable target aggregates all unreleased merged pull requests. |
 | Scoped caller permissions | Empty caller top-level permissions, the three job grants, built-in-token checkout/read, and standard Pages/OIDC verification. |
 | Caller credential contract | Explicit baseline mappings for `PSGALLERY_API_KEY`, `GitHubAppClientId`, and `GitHubAppPrivateKey`; rejected `secrets: inherit`; optional `TestData` JSON with separate `secrets` and `variables` maps; and no `with.Debug: true`. |
+| Caller boundary | Exactly one conforming Process-PSModule call job with governing shared top-level controls, plus repository-owned jobs in the same file and separate workflows that prove their presence is visible but does not weaken or bypass the call boundary. |
 | App authorization failure | Missing-App-token fixtures that prove user-facing operations fail closed without built-in token fallback. |
 | Token boundary | Fixtures that prove App tokens are step-scoped and built-in-token operations remain within the caller job's boundary. |
 | Event authorization | Normal-fork `pull_request` fixtures that prove the controlled upstream Plan derives restricted capabilities from immutable fork/base/head metadata before it consumes settings or checked-out code, then permits only checkout/build/lint/test with a green/red outcome and no configured secrets; `pull_request_target` fixtures prove Plan rejects before credentialed or repository-defined code, including for downstream `always()` jobs. |

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

@@ -15,9 +15,14 @@ This candidate defines the behavior required from a Process-PSModule workflow li
 
 ## Scope
 
-The candidate covers dispatch recovery, scheduled validation, pull-request validation and prerelease evaluation, closed-pull-request cleanup, and stable publication after a default-branch push.
+The candidate covers dispatch recovery, scheduled validation, pull-request validation and prerelease evaluation, closed-pull-request cleanup, stable publication after a default-branch push, and the Process-PSModule reusable-workflow caller boundary.
 
-It does not approve a caller layout, change module build or publication implementation, define label names, or prescribe release-note presentation. Those choices remain in the caller candidate, the existing versioning guidance, and the companion [candidate design](process-workflow-lifecycle-design.md).
+It standardizes exactly one conforming Process-PSModule reusable-workflow call job and the shared top-level controls that govern
+it; it does not standardize the repository owner's whole workflow. Repository-owned jobs may exist in the same workflow
+file or separate workflows, provided they do not weaken or bypass the call's trigger, concurrency, permissions, Plan
+authorization, or credential boundary. It does not change module build or publication implementation, define label
+names, or prescribe release-note presentation. Those choices remain in the caller candidate, the existing versioning
+guidance, and the companion [candidate design](process-workflow-lifecycle-design.md).
 
 ## Confirmed implementation baseline
 
@@ -309,6 +314,29 @@ 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}
+
+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 are not nonconforming merely by existing, but they MUST NOT
+weaken or bypass any of those controls for the Process-PSModule call.
+
+#### 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
+  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
+
+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 could weaken or bypass the Process-PSModule call's trigger, concurrency, permissions, Plan authorization, or credential boundary
+  Then the caller arrangement is nonconforming
+```
+
 ## Non-functional requirements
 
 ### NFR1 — Lifecycle mutations MUST be idempotent {#nfr1}
@@ -445,7 +473,7 @@ Scenario: Recover release notes after a missed main-push publication
   And a retry creates no duplicate publication
 ```
 
-### AC2 — Verifies: [FR2](#fr2), [FR4](#fr4), [FR5](#fr5), [FR6](#fr6), [FR8](#fr8), [FR9](#fr9), [FR10](#fr10), [FR11](#fr11), [FR12](#fr12), [NFR2](#nfr2), [NFR3](#nfr3), [NFR4](#nfr4), [NFR5](#nfr5), [NFR6](#nfr6), [NFR7](#nfr7)
+### AC2 — Verifies: [FR2](#fr2), [FR4](#fr4), [FR5](#fr5), [FR6](#fr6), [FR8](#fr8), [FR9](#fr9), [FR10](#fr10), [FR11](#fr11), [FR12](#fr12), [FR13](#fr13), [NFR2](#nfr2), [NFR3](#nfr3), [NFR4](#nfr4), [NFR5](#nfr5), [NFR6](#nfr6), [NFR7](#nfr7)
 
 ```gherkin
 Scenario: Lifecycle runs preserve release ownership after cancellation