📖 [Docs]: Document trunk-based release flow (#454)

The documentation now keeps Process-PSModule releases trunk-based and
aligned with the workflow implementation.

## Changed: Release guidance follows the default branch

The documentation now states that feature branches are short-lived and
target `main` directly. Stable publication occurs only when a pull
request is merged to the repository default branch. A `Prerelease` label
remains available for previewing a feature pull request before merge.

The proposed release-branch promotion process and `release/**` trigger
have been removed. Dependent work may still use the canonical stacked
pull request model.

---
<details>
<summary>Technical details</summary>

- Removed the release-branch pattern added from PSModule/docs#90.
- Aligned the versioning guide, module standard, principles, bootstrap
guidance, and specification with trunk-based delivery.
- Corrected the specification from publication on a release branch to
publication on the default branch.
- No test/import/no-mocks guidance was duplicated.

</details>

<details>
<summary>Relevant issues (or links)</summary>

- PSModule/docs#90

</details>

---------

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

Author: MariusStorhaug

docs/content/get-started/module-bootstrap.md

@@ -60,6 +60,6 @@ A module bootstrapped this way:
 ## When to use this
 
 - The module has no usable release yet, and the load-bearing core hasn't landed.
-- Use this only for the initial bootstrap. Once `main` has a first release, ongoing feature work targets `main` directly with ordinary topic branches, or a [stacked pull request](https://msx.no/docs/Ways-of-Working/Branching-and-Merging/#stacked-pull-requests) when changes genuinely depend on each other.
+- Use this only for the initial bootstrap. Once `main` has a first release, ongoing feature work targets `main` directly with ordinary topic branches, or uses a [stacked pull request](https://msx.no/docs/Ways-of-Working/Branching-and-Merging/#stacked-pull-requests) when changes genuinely depend on each other.
 
 For the general branching and merge model, see [MSX Branching and Merging](https://msx.no/docs/Ways-of-Working/Branching-and-Merging/).

docs/content/guides/versioning-and-releases.md

@@ -44,19 +44,20 @@ The label names are configurable through `Publish.Module.MajorLabels`, `MinorLab
 
 ## Branch types
 
-- **Main (stable)** — pushes publish stable releases. A prerelease label on an open pull request publishes a prerelease.
-- **Development** — optional prerelease branch (for example `dev`). Its open, prerelease-labelled pull request to the
-  stable branch publishes previews when it is updated.
-- **Feature branch** — optional feature branch. Its open, prerelease-labelled pull request publishes a preview for
-  testing.
+- **Main (stable)** — the default branch and the only branch that publishes stable releases.
+- **Feature branch** — a short-lived topic branch with a pull request targeting `main`.
 
-Exactly one branch is authorized to publish stable releases, so consumers always have one unambiguous latest version.
+Exactly one branch is authorized to publish stable releases, so consumers always have one
+unambiguous latest version. Use a
+[stacked pull request](https://msx.no/docs/Ways-of-Working/Branching-and-Merging/#stacked-pull-requests)
+when changes genuinely depend on each other; independent changes remain separate
+short-lived pull requests targeting `main`.
 
 ## Prereleases
 
 A pull request labelled `Prerelease` publishes a prerelease version (for example `v1.2.3-pr.1.5`) that is installable
 but not promoted as latest. When that pull request is merged with a version label, the stable version is computed from
-the label and the current version on the release branch.
+the label and the current version on `main`.
 
 When a pull request closes, the prerelease versions and tags created for it are removed, so abandoned or promoted work
 leaves no orphaned prereleases. This is controlled by `Publish.Module.AutoCleanup`.
@@ -76,8 +77,7 @@ Release names and notes can be generated from the pull request — see
 
 Only a single linear ancestry of versions is maintained. Old versions are not patched: if a security issue is found on
 `2.1.3`, the fix ships on the latest version, not as a new `1.x` release. See
-[Principles and practices](../specification/principles-and-practices.md) for the reasoning and for the release-branch
-pattern used for larger efforts.
+[Principles and practices](../specification/principles-and-practices.md) for the reasoning.
 
 ## Related
 

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

@@ -115,10 +115,12 @@ The release process treats each important default-branch push as a release on a
 request supplies release metadata when its merge commit exactly matches that push. There is no patching of older
 versions — security fixes go on the current tip of `main` only.
 
-### Release and feature branches
+### Feature branches
 
-For large work, open a release branch and target it from feature branches. Apply the `Prerelease` label on the release
-branch PR to publish preview versions before its final merge creates the stable default-branch push.
+Keep feature branches short-lived and target `main` directly. Use a
+[stacked pull request](https://msx.no/docs/Ways-of-Working/Branching-and-Merging/#stacked-pull-requests)
+only when changes genuinely depend on each other. Apply the `Prerelease` label to a
+feature pull request to publish a preview before merging it to `main`.
 
 ## CI/CD pipeline
 
@@ -291,7 +293,7 @@ The publish step only runs when:
 
 - All tests and code coverage pass (or are skipped)
 - An important push reaches the default branch (stable release), or
-- The PR carries the `Prerelease` label (prerelease from the feature/release branch)
+- The PR carries the `Prerelease` label (prerelease from the feature branch)
 
 On any closed PR, the pipeline cleans up any prerelease tags created for that branch. A closed pull request cannot
 create a stable release.

docs/content/specification/principles-and-practices.md

@@ -12,12 +12,13 @@ back to patch and update old versions of the modules. This means that if we are
 patch the latest version with a fix, not releasing new versions based on older versions of the module, i.e. not updating the latest 1.x with the
 patch.
 
-## Release and feature branches
+## Trunk-based development
 
-If you need to work forth a bigger release, create a branch representing the release (a release branch) and open a PR towards `main` for this branch.
-For each topic or feature to add to the release, open a new branch representing the feature (a feature branch) and open a PR towards the release
-branch. Optionally add the `Prerelease` label on the PR for the release branch, to release preview versions before merging and releasing a published
-version of the PowerShell module.
+Keep feature branches short-lived and open pull requests directly toward `main`.
+Independent changes use separate branches; use a
+[stacked pull request](https://msx.no/docs/Ways-of-Working/Branching-and-Merging/#stacked-pull-requests)
+only when changes genuinely depend on each other. Add the `Prerelease` label to a
+feature pull request when a preview version is needed before merging to `main`.
 
 ## Colocation of concerns
 

docs/content/specification/spec.md

@@ -45,9 +45,9 @@ The pipeline MUST generate module documentation from the source (cmdlet help, RE
 
 The pipeline MUST read pull-request labels (`Major`, `Minor`, `Patch`, `Prerelease`, `NoRelease`) to decide the
 semantic-version bump when the merged pull request exactly matches a default-branch push. It MUST compute the next
-version automatically, never reading or writing a hand-edited version file. An important push to the release branch
-MUST trigger publication to the PowerShell Gallery and documentation site; a prerelease label MUST result in a
-prerelease version available for testing before stable release.
+version automatically, never reading or writing a hand-edited version file. An important push to the default branch MUST
+trigger publication to the PowerShell Gallery and documentation site; a prerelease label MUST result in a prerelease
+version available for testing before stable release.
 
 ### FR6 — Produce immutable, linkable releases {#fr6}
 
@@ -65,7 +65,7 @@ Only one release process MUST run against a given version of the codebase at a t
 
 ### NFR3 — Single production authority {#nfr3}
 
-Exactly one branch (typically `main`) MUST be authorized to publish stable releases. All other release branches MUST publish only prerelease versions. This ensures consumers have one unambiguous latest stable version.
+Exactly one branch (the repository default branch, typically `main`) MUST be authorized to publish stable releases. Feature branches MAY publish only prerelease versions. This ensures consumers have one unambiguous latest stable version.
 
 ### NFR4 — Rapid feedback on failure {#nfr4}