Pull request guidance uses audience-first release notes

.github/CONTRIBUTING.md

@@ -2,7 +2,9 @@
 
 Every change lands through a pull request — nothing goes directly to `main`. See the
 [Contribution Workflow](https://msxorg.github.io/docs/Ways-of-Working/Contribution-Workflow/)
-for the full process: draft first, the Copilot review loop, then human review.
+for the full process: draft first, the Copilot review loop, then human review. Write the
+title and description according to
+[PR Format](https://msxorg.github.io/docs/Ways-of-Working/PR-Format/).
 
 Everything here is a work in progress and can be improved. Fix a small problem when it is
 directly in scope; register a larger or unrelated one as an issue in the repository that
@@ -50,6 +52,17 @@ owns it.
 7. Open the pull request as a draft and follow the
    [Contribution Workflow](https://msxorg.github.io/docs/Ways-of-Working/Contribution-Workflow/).
 
+## Pull request template
+
+This repository intentionally has no local pull request template. GitHub inherits
+the [MSX organization
+template](https://github.com/MSXOrg/.github/blob/main/.github/pull_request_template.md)
+from the special `MSXOrg/.github` repository. Treat that template as a starting
+scaffold; the canonical [PR
+Format](https://msxorg.github.io/docs/Ways-of-Working/PR-Format/) controls the
+final title and description. Start from its
+[complete description template](https://msxorg.github.io/docs/Ways-of-Working/PR-Format/#copy-the-complete-template).
+
 ## Authoring conventions
 
 The docs are built for recursive navigation, so a reader or an agent can start at the top
@@ -113,6 +126,6 @@ conventional-commit prefixes. See
 Push every commit, so the remote branch, CI, and the draft pull request always reflect the
 current state of the work.
 
-See the [README](README.md) for what this repository is and how it is laid out, and the
+See the [README](../README.md) for what this repository is and how it is laid out, and the
 [Ways of Working](https://msxorg.github.io/docs/Ways-of-Working/) for the conventions every
 pull request follows — issue format, PR format, branching, and review etiquette.

src/docs/Capabilities/dependency-updates/design.md

@@ -80,14 +80,16 @@ flowchart TD
   pr --> ci["Required checks run<br/>(same gate as any PR)"]
   ci --> review["Review and merge"]
   review --> merged["Merged"]
-  merged --> release["Separate release decision<br/>see Release Management"]
+  merged --> release["Conditional release decision<br/>see Release Management"]
 ```
 
 ### Release decision
 
-Dependency changes are collected before the repository release decision is
-made. The repository-wide effect follows [Release
-Management](../release-management/design.md).
+Dependency changes are collected before any repository release decision is
+made. When the target route invokes [Release
+Management](../release-management/design.md), that capability resolves the
+repository-wide effect. Otherwise the pull request omits the `Release decisions`
+block and all `release:*` labels.
 
 ## Review and merge
 
@@ -97,8 +99,8 @@ gates. Automatic merge, where configured, never bypasses those gates.
 ## Security updates
 
 Raised on advisory disclosure, independently of the schedule, and
-**prioritised**. They otherwise follow the same review policy and release path as
-any other update.
+**prioritised**. They otherwise follow the same review policy and any applicable
+release path as another update.
 
 ## Configuration surface
 
@@ -108,7 +110,7 @@ any other update.
 | Unsupported ecosystems | Central exception register | Centrally managed shared mechanism |
 | Schedule (`interval`, `day` and `time`, or `cronjob`) and `timezone` | `.github/dependabot.yml` | Organization configuration |
 | Cooldown | Updater default (three days); explicit mapping only for a deliberate non-default duration | Organization configuration |
-| Release decision | Release Management | Decided for the collected repository change |
+| Release decision | Release Management, when invoked for the target route | Decided for the collected repository change |
 | Merge policy | Branch protection and merge automation | Organization configuration |
 | Security updates | Repository security settings | On by default |
 
@@ -121,6 +123,6 @@ rather than overwrite.
 
 - [Spec](spec.md) — the requirements this design delivers.
 - [Repository Governance](../repository-governance/design.md#drift-detection-and-reconciliation) — the reconciliation that compares generated configuration against what is committed.
-- [Release Management](../release-management/design.md) — the release an update PR cuts.
+- [Release Management](../release-management/design.md) — the conditional release decision and output for an update pull request.
 - [Downstream Release Propagation](../downstream-release-propagation/design.md) — the internal counterpart; propagation PRs are dependency updates too.
 - [GitHub Actions](../../Coding-Standards/GitHub-Actions.md#keep-pinned-actions-current) — the Action-pin specifics this builds on.

src/docs/Capabilities/dependency-updates/spec.md

@@ -11,15 +11,18 @@ Every repository pins dependencies by version — Action SHAs, image digests,
 package versions, provider constraints. Those pins age: a newer version fixes a
 bug the repository still carries, and a disclosed advisory turns a safe pin into
 a vulnerability. Keeping them current MUST be automatic and driven on the GitHub
-platform, producing ordinary pull requests that are reviewed and released
-through the same gate as any change — never a side channel that bypasses review.
+platform, producing ordinary pull requests that are reviewed through the same
+gate as any change — never a side channel that bypasses review. When the target
+route invokes Release Management, its release decision and publication path are
+resolved separately from the updater; a route without that invocation carries
+no `release:*` metadata.
 
 ### Principles
 
 This capability rests on the [Principles](../../Ways-of-Working/Principles/index.md):
 
 - **[Everything as Code](../../Ways-of-Working/Principles/Engineering-Practices.md#everything-as-code).** What is checked and how often is version-controlled configuration, not a manual audit.
-- **[Decision before change](../../Ways-of-Working/Principles/AI-First-Development.md#decision-before-change).** Every update is a pull request; its review gate approves the bump, while its release impact is decided separately.
+- **[Decision before change](../../Ways-of-Working/Principles/AI-First-Development.md#decision-before-change).** Every update is a pull request; its review gate approves the dependency change, while any applicable release decision is resolved separately.
 - **[Least-privilege](../../Ways-of-Working/Principles/Purpose-and-Direction.md#least-privilege).** The updater and any auto-merge automation carry only the permissions they need.
 - **[Extensible by default](../../Ways-of-Working/Principles/Software-Design.md#extensible-by-default).** Adding a package ecosystem is a configuration entry, not new machinery.
 
@@ -31,9 +34,9 @@ other ecosystem the repository actually uses. Two questions are asked of every p
 **currency** (is a newer version available?) and **security** (does the pinned
 version carry a known advisory?).
 
-Out of scope: what an update *does* to the artifact. That is the release the update
-produces, and it is governed by [Release
-Management](../release-management/spec.md).
+Out of scope: what an update *does* to the artifact. Where the target route
+invokes [Release Management](../release-management/spec.md), that capability
+governs the release decision and output.
 
 ## Requirements
 
@@ -69,7 +72,7 @@ Management](../release-management/spec.md).
 ### Review and release
 
 - **FR10 — One reviewed pull request per update.** Each dependency update is a pull request that passes the full check suite before merge. Nothing is applied unreviewed, and no update takes a side channel around the gate.
-- **FR11 — Release impact is decided separately.** The dependency updater MUST NOT choose the repository's release bump. After dependency changes are collected, the repository-wide effect is decided according to [Release Management](../release-management/spec.md).
+- **FR11 — Release decisions stay independent.** The dependency updater MUST NOT choose the repository's release bump or apply `release:*` labels. After dependency changes are collected, the repository-wide effect is decided according to [Release Management](../release-management/spec.md) only when the target route invokes it.
 - **FR12 — Review and merge follow the repository gate.** An update MUST pass the repository's normal review and required-check policy before merge.
 - **FR13 — Automatic merge is never a bypass.** Where automatic merge is configured, it MUST preserve review requirements and required checks.
 
@@ -83,12 +86,12 @@ Management](../release-management/spec.md).
 
 - An outdated or vulnerable pin produces a pull request with no human trigger.
 - An ecosystem added to a repository without a corresponding updater entry is a detectable finding, not a silent gap.
-- The repository-wide release impact of dependency changes is decided separately under Release Management.
+- When the target route invokes Release Management, the repository-wide release decision for dependency changes is resolved separately under that capability.
 - No dependency pull request merges without passing the same checks as any other pull request.
 
 ## Where this connects
 
 - [Design](design.md) — the updater, review, and automatic-merge policy.
-- [Release Management](../release-management/spec.md) — the separate repository-wide release decision for merged dependency changes.
+- [Release Management](../release-management/spec.md) — the conditional, separate repository-wide release decision for merged dependency changes.
 - [Repository Governance](../repository-governance/spec.md) — the reconciliation that detects an uncovered ecosystem.
 - [GitHub Actions](../../Coding-Standards/GitHub-Actions.md#keep-pinned-actions-current) — keeping pinned Actions current.

src/docs/Capabilities/merge-automation/design.md

@@ -103,5 +103,5 @@ approval to the eligible set the ruleset actually lets it satisfy.
 - [Spec](spec.md) — the requirements this design delivers.
 - [GitHub Actions](../../Coding-Standards/GitHub-Actions.md#gate-merges-with-a-named-status-check) — authoring the named checks this consumes.
 - [Dependency Updates](../dependency-updates/design.md) — the auto-merge policy this generalises; dependency update PRs are the canonical eligible set.
-- [Release Management](../release-management/design.md) — the release a merge triggers.
+- [Release Management](../release-management/design.md) — the release a merge triggers on an invoked route.
 - [Branching and Merging](../../Ways-of-Working/Branching-and-Merging.md) — pull-request-only integration and readable history.