Framework contracts use direct en-US prose

docs/content/reference/pipeline-stages.md

@@ -5,19 +5,16 @@ description: The job-by-job breakdown of the Process-PSModule workflow, from Pla
 
 # Pipeline stages
 
-The Process-PSModule workflow composes its work from a set of reusable jobs. Each
-one is described below, in the order it runs, with a link to the workflow that
-implements it.
+The Process-PSModule workflow uses reusable jobs. The sections below describe the jobs in the order they run and link to their workflows.
 
-For which of these jobs run in a given trigger scenario, see the [scenario matrix](scenario-matrix.md).
+The [scenario matrix](scenario-matrix.md) defines which jobs run for each trigger scenario.
 
 ## Plan
 
 [workflow](https://github.com/PSModule/Process-PSModule/blob/main/.github/workflows/Plan.yml)
 
-The Plan job is the single decision point of the workflow. It reads the settings file (`.github/PSModule.yml`),
-collects event context from GitHub, and decides what should happen in the rest of the process. Using that
-situational awareness, it calculates the next module version.
+The Plan job is the workflow's single decision point. It reads the settings file (`.github/PSModule.yml`),
+collects GitHub event context, and decides what should happen in the rest of the process. It uses this context to calculate the next module version.
 
 The user-facing settings file stays in `.github/PSModule.yml`. The workflow enriches that input into an internal runtime
 `Settings` object passed between jobs. In this runtime contract, execution decisions are phase-owned (`*.Enabled`), test
@@ -65,7 +62,7 @@ suite matrices are computed under each owning test phase, and resolved version m
 
 - Tests the source code in parallel (matrix) using:
   - [PSModule framework settings for style and standards for source code](https://github.com/PSModule/Process-PSModule/tree/main/.github/actions/Test-PSModule/src/tests/SourceCode)
-- This produces a JSON-based report that is used by [Get-PesterTestResults](#get-test-results) evaluate the results of the tests.
+- Produces a JSON-based report that [Get-PesterTestResults](#get-test-results) uses to evaluate the test results.
 
 For the coding practices this step enforces, see [framework test IDs](framework-test-ids.md#source-code-tests).
 
@@ -75,7 +72,7 @@ For the coding practices this step enforces, see [framework test IDs](framework-
 
 - Lints the source code in parallel (matrix) using:
   - [PSScriptAnalyzer rules](https://github.com/PSModule/Invoke-ScriptAnalyzer)
-- This produces a JSON-based report that is used by [Get-PesterTestResults](#get-test-results) evaluate the results of the linter.
+- Produces a JSON-based report that [Get-PesterTestResults](#get-test-results) uses to evaluate the linter results.
 
 ## Framework test
 
@@ -84,7 +81,7 @@ For the coding practices this step enforces, see [framework test IDs](framework-
 - Tests and lints the module in parallel (matrix) using:
   - [PSModule framework settings for style and standards for modules](https://github.com/PSModule/Process-PSModule/tree/main/.github/actions/Test-PSModule/src/tests/Module)
   - [PSScriptAnalyzer rules](https://github.com/PSModule/Invoke-ScriptAnalyzer)
-- This produces a JSON-based report that is used by [Get-PesterTestResults](#get-test-results) evaluate the results of the tests.
+- Produces a JSON-based report that [Get-PesterTestResults](#get-test-results) uses to evaluate the test results.
 - **Code coverage for framework-generated code**: This step collects code coverage for framework-generated
   boilerplate. During the [build step](#build-module), [Build-PSModule](https://github.com/PSModule/Build-PSModule)
   injects boilerplate code into the compiled `.psm1` file — including type accelerator registration for public classes
@@ -106,7 +103,7 @@ For the checks this step enforces on the built module, see [framework test IDs](
   - `tests/BeforeAll.ps1`: Runs once before all module-local test matrix jobs to set up the test environment.
   - `tests/AfterAll.ps1`: Runs once after all module-local test matrix jobs complete to clean up the test environment.
 - The workflow checks only those exact repository-root paths; phase detection is non-recursive.
-- This produces a JSON-based report that is used by [Get-PesterTestResults](#get-test-results) to evaluate the results of the tests.
+- Produces a JSON-based report that [Get-PesterTestResults](#get-test-results) uses to evaluate the test results.
 
 How to write these tests, including the Pester version requirement and shared-infrastructure patterns, is covered in
 [Writing module tests](../guides/writing-module-tests.md).
@@ -116,7 +113,7 @@ How to write these tests, including the Pester version requirement and shared-in
 [workflow](https://github.com/PSModule/Process-PSModule/blob/main/.github/workflows/Get-TestResults.yml)
 
 - Gathers the test results from the previous steps and creates a summary of the results.
-- If any tests have failed, the workflow will fail here.
+- If any tests fail, the workflow fails here.
 
 ## Get code coverage
 
@@ -126,7 +123,7 @@ How to write these tests, including the Pester version requirement and shared-in
 - Aggregates coverage from the [Framework test](#framework-test) step (framework-generated boilerplate) and the
   [Test module](#test-module) step (module author code). A command executed in either step counts as covered, so
   framework-generated lines do not count against the module author's coverage target.
-- If the code coverage is below the target, the workflow will fail here.
+- If the code coverage is below the target, the workflow fails here.
 
 ## Publish module
 

docs/content/reference/powershell-module-standard.md

@@ -44,7 +44,7 @@ The framework treats `src/` as the source for the compiled module. Place code in
 Layout rules:
 
 - **One declaration per file.** Filename matches the declared symbol exactly, including casing.
-- **Group by domain.** Use resource or behaviour groups — not verb folders, not endpoint paths.
+- **Group by domain.** Use resource or behavior groups — not verb folders, not endpoint paths.
 - **Mirror public and private domains.** Public command under `src/functions/public/Projects/` has related private helpers under `src/functions/private/Projects/`.
 - **No nested functions.** Do not define helper functions inside other functions. Extract helper logic to a separate function file and decide whether it belongs in `src/functions/private/<Group>/` (internal-only) or `src/functions/public/<Group>/` (part of the module API).
 - **Declare dependencies where they are used.** Use `#Requires -Modules <Name>` at the top of each function file that needs an external module. Do not add `RequiredModules` to `src/manifest.psd1` — the build collects all `#Requires` declarations automatically and writes them into the compiled manifest. Entries in `src/manifest.psd1` are silently ignored for this purpose.
@@ -65,7 +65,7 @@ Layout rules:
 
 ## SOLID applied
 
-- **Single Responsibility.** One file, one function. One function, one user-visible behaviour. If the synopsis needs "and", split it.
+- **Single Responsibility.** One file, one function. One function, one user-visible behavior. If the synopsis needs "and", split it.
 - **Open/Closed.** Extend via parameter sets, private helpers, or new files — not boolean switches that fork large blocks.
 - **Liskov.** A derived class must work wherever the base is expected.
 - **Interface Segregation.** Narrow, intent-named parameter sets.
@@ -79,9 +79,9 @@ Every parameter that has a natural default should declare one. The most common u
 
 - Prefer `= 'main'` over making `-Branch` mandatory in commands that act on branches.
 - Prefer sensible page sizes, counts, or ranges over requiring callers to specify them.
-- Prefer `= $false` for switches rather than leaving the behaviour implicit.
+- Prefer `= $false` for switches rather than leaving the behavior implicit.
 
-This is a usability expression of the **Open/Closed** principle: the common path is open by default; callers that need different behaviour extend it by supplying alternatives — they are never forced to know the default just to get started.
+Parameter defaults apply the **Open/Closed** principle. The common path is open by default. Callers that need different behavior extend it with alternative inputs. They are never forced to know the default to get started.
 
 ### Object-first parameters
 
@@ -91,7 +91,7 @@ Parameters represent attributes of a real-world entity. Design them to reflect t
 - **Group flat parameters by their conceptual object.** When a typed object is not available, prefix each parameter with the name of the entity it belongs to: `$ServerHost`, `$ServerPort`, `$ServerTls` rather than `$Host`, `$Port`, `$Tls`. The prefix makes the grouping explicit, prevents collisions with unrelated parameters, and avoids shadowing PowerShell built-in variables (`$Host`).
 - **Offer both modes when callers need both.** A parameter set that accepts an object and a parallel parameter set that accepts its individual attributes are equally valid; use both when that genuinely serves users.
 
-This mirrors **Interface Segregation**: each parameter set represents one coherent input contract — not a flat list of loosely related knobs — so callers only touch what they need.
+This applies **Interface Segregation**: each parameter set represents one coherent input contract, not a flat list of loosely related inputs. Callers supply only the inputs they need.
 
 > Note: the rule "avoid repeating the noun" (e.g. `-ID` not `-ProjectID` in `Get-ContosoProject`) applies to a command's *own* noun. The object-prefix convention above applies when a single command spans *multiple* conceptual objects (`$ServerHost` vs `$ClientID`) — the prefix is the object name, not the command noun, so there is no conflict.
 

docs/content/reference/repository-standard.md

@@ -1,10 +1,10 @@
 # Repository Standard
 
-This is the PSModule organization's Repository Standard. It applies to the PSModule organization and is the standard for PowerShell module repositories. It describes what a newly created or maintained module repository should look like before module-specific code, tests, documentation, and managed repository files are considered.
+This standard defines repository requirements for PowerShell modules in the PSModule organization. It describes how a newly created or maintained module repository should look. It defines the baseline before module-specific code, tests, documentation, and managed repository files are considered.
 
-This standard operates at the same altitude as the [MSX Enterprise Repository Standard](https://msx.no/docs/Ways-of-Working/Repository-Standard/): MSX sets the enterprise-wide default, and this standard adds to and adjusts that default for PowerShell module repositories. Rules this standard does not change are inherited from the MSX default; where this standard adds or overrides a rule, it governs PowerShell module repositories.
+This standard complements the [MSX Enterprise Repository Standard](https://msx.no/docs/Ways-of-Working/Repository-Standard/). MSX defines the enterprise-wide default. This standard adds requirements and overrides for PowerShell module repositories. Unchanged MSX rules still apply. Additions and overrides on this page govern PowerShell module repositories.
 
-The implementation standard still lives in [PowerShell module standard](powershell-module-standard.md). Type-specific conventions for integration (API) and data modules live in [Module types](module-types.md). This page covers the repository standard for module repositories: files, metadata, README shape, release integration, placeholder handling, shared community files, and managed-file distribution.
+The implementation standard is in [PowerShell module standard](powershell-module-standard.md). Type-specific conventions for integration (API) and data modules are in [Module types](module-types.md). This page covers the repository standard for module repositories: files, metadata, README shape, release integration, placeholder handling, shared community files, and managed-file distribution.
 
 ## Scope
 
@@ -17,7 +17,9 @@ It does not apply directly to:
 - Template repositories other than `Template-PSModule`.
 - Test, archive, service, or infrastructure repositories that are not published as module artifacts.
 
-Two baseline expectations still apply to every PSModule repository, including the types listed above. Each repository stands on its own: it carries its own governance and community files instead of relying on the organization `.github` fallback, and each repository ships the [agent onboarding files](#agent-onboarding-files) so an agent can work in it without prior context. What differs by type is the concrete file set and layout: the required files, README shape, and framework wiring on the rest of this page are the module standard, and non-module repositories keep only the equivalent baseline appropriate to their own type. This documentation project, maintained in `PSModule/Process-PSModule`, follows those two baseline expectations itself.
+Two baseline expectations apply to every PSModule repository, including the types above. Each repository carries its own governance and community files instead of relying on the organization `.github` fallback. Each repository also ships the [agent onboarding files](#agent-onboarding-files) so an agent can work without prior context.
+
+The required file set, README shape, and framework wiring on this page apply to module repositories. Non-module repositories keep the equivalent baseline for their type. This documentation project, maintained in `PSModule/Process-PSModule`, also follows the two baseline expectations.
 
 Each initiative should keep its own repository standards in its central documentation repository. For the PSModule organization, this repository is the source of truth.
 
@@ -306,7 +308,7 @@ Keep, trim, or relocate content — do not delete it:
 - **Trim:** exhaustive command inventories, parameter tables, and repetitive examples that differ only by a parameter. These come from comment-based help — point to `Get-Help` and the documentation site instead of restating them.
 - **Keep content in a published home — never drop it:** long-form guides and unique conceptual content (authentication and setup walkthroughs, deep operational detail, end-to-end scenarios) belong in a surface that is actually published: a command group's overview page under `src/functions/public/<Group>/<Group>.md`, comment-based help, or published documentation in `docs/` or `examples/`. When no published home exists, keep the full content in the README to ensure it reaches users. A longer landing page is acceptable and expected for feature-rich modules; do not shorten by deleting.
 
-Retain upstream attribution and licensing context. Credit, acknowledgements, donation notes, and third-party license notices for wrapped or bundled work must stay in the README or appear in a clearly linked location. The rule below about community and policy sections does not apply to attribution the project is expected to carry.
+Retain upstream attribution and licensing context. Credit, acknowledgments, donation notes, and third-party license notices for wrapped or bundled work must stay in the README or appear in a clearly linked location. The rule below about community and policy sections does not apply to attribution the project is expected to carry.
 
 README pages should not duplicate generated command documentation. Do not add full command inventories, parameter tables, or long reference sections when those details are already produced from comment-based help.
 
@@ -357,7 +359,7 @@ For an implemented module, also confirm the README keeps a capabilities or usage
 
 ## Documentation ownership
 
-Command details belong in comment-based help and generated documentation. The README can showcase capability, then points to those sources for reference detail.
+Command details belong in comment-based help and generated documentation. The README can showcase capability, then point to those sources for reference detail.
 
 Use these defaults:
 

docs/content/reference/settings.md

@@ -5,8 +5,8 @@ description: The Process-PSModule settings file — every available setting in .
 
 # Settings
 
-The workflow is configured using a settings file in the module repository.
-The file can be a `JSON`, `YAML`, or `PSD1` file. By default, it will look for `.github/PSModule.yml`.
+The workflow uses a settings file in the module repository.
+The file can use `JSON`, `YAML`, or `PSD1`. The default path is `.github/PSModule.yml`.
 
 The settings listed on this page are the user-facing configuration contract in `.github/PSModule.yml`. During the
 Plan phase, Process-PSModule enriches this input into an internal runtime `Settings` object that downstream workflows