Make PR release records self-contained for consumer upgrades #226

Context and request

Make the canonical PR format sufficient for consumer upgrade communication, using the existing work in MSXOrg/docs#209. Every applicable change must explain the outcome, rationale, affected uses, exact adoption or migration actions, ordering and verification, or an explicit no-action result. The complete PR title and body become the release record; consumers must not reconstruct missing instructions from diffs or repository migration guides.

The user-directed revision makes release-bound authoring release-range-first: compare the actual latest successful artifact publication for the same product/target/channel and its immutable source with the exact candidate PR source. Keep the ordinary PR-base diff separately for implementation and reviewer evidence, not as the release-note boundary.

Acceptance criteria

• The complete scaffold uses an audience-first summary, exactly one announcement boundary, ordered result groups, result-scoped evidence/references, and a final resolved decision on actual release-managed routes.
• Publication baseline and candidate identities are pinned before title, result, adoption-action and compatibility authoring; earlier merged/skipped/unshipped consumer changes remain in the complete delivered range.
• Module Gallery publication success counts even if later GitHub completion fails; finishing an older record does not make already-published changes new again. A GitHub Latest hint, moving tag, failed run or assumed highest version is not publication-baseline proof.
• Missing/unverifiable publication or source evidence, diverged lineage and changed comparison identities are resolved explicitly; a verified initial publication has reviewed full initial coverage rather than invented predecessor, no-action or patch facts.
• Required migration instructions remain in PR/release records; evergreen product documentation contains the supported current contract and the general communication protocol.
• Release decisions accept an effective documented DefaultBump and caller overrides, use release:prerelease, and agree with the owning resolver rather than infer a bump from prose.
• Repository/Organization/Governance guidance owns the no-PR-template-file policy for ordinary and central default sources, with no local/generated exceptions; PR Format remains focused only on the authored record.
• PR Format retains audience-first structure, release-range-first analysis, complete adoption/compatibility evidence, one announcement marker and conditional decisions, with a complete description example rather than file-policy discussion. Related anchors and tests reflect that ownership.
• Other community defaults, repository-specific contribution instructions and affected product-integration evidence remain distinct and unaffected.
• Dependent organization/repository/governance and contribution links agree with the no-file canonical authoring contract without conflicting mandates or obsolete anchors.
• Repository documentation, structural contract, skill-manifest and complete review checks pass before review readiness.

Technical decisions

Deliver this Task through existing PR #209, preserving its complete intent and separate neighboring PRs #196 and #208. Canonical ownership remains PR Format, Release Management, and Documentation Model. Reuse the existing smart-defaults principle; no Discord sender, date-based version strategy, publisher implementation, Build/artifact-promotion redesign, historical backfill, live labels or governance mutation belongs in this repository diff. The required CI enforcement remains separate operational work tracked by #166 through the native dependency.

The bounded revision updates only authoring/evidence, directly related canonical links and the thin PR-format entrypoint. The subsequent user-approved no-PR-template-file correction includes directly coupled organization/repository/governance and contribution guidance; separate source and validator owners remove their actual template files and file-presence expectations. This Task does not edit their workspaces or claim pending deletions are merged. Task/Bug technical planning remains scoped to the ordinary PR implementation, not expanded to earlier work merely covered by the release note. Other owners reconcile their branches from the new immutable correspondence; this Task does not edit their tracked PRs.

Implementation plan

• Establish current PR/Task state, the publication-baseline cases and the separate scoped PR comparison before editing.
• Align the canonical scaffold and consumer communication procedure with the user-confirmed release-range-first contract.
• Reconcile directly related release-evidence references and the single canonical skill pointer while preserving existing format/default/Task contracts.
• Run complete native documentation/test/skill validation and the new-head Copilot review loop; resolve scoped feedback.
• Record actual acceptance evidence in PR Pull request guidance describes complete source-bound records #209 and hand off the committed/pushed immutable correspondence for downstream reconciliation.