You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Pull request guidance describes complete source-bound records - #209
PR Format describes the actual title and complete body: audience-first results, release-range-first analysis, complete adoption/compatibility evidence, one announcement boundary and conditional release decisions. Repository file policy is owned separately by Repository/Organization/Governance guidance, not by the PR Format page.
Authors use canonical guidance for the resulting record. Repository standards exclude GitHub PR-template files from ordinary and central-default sources, while retaining other community defaults, genuine repository-specific contribution instructions and supported product-integration contracts. This delivery changes guidance and checks in MSXOrg/docs; separate owners remove their actual source/consumer files. No publisher, live caller, artifact, tag, governance setting or release history is changed here.
Changed: PR Format focuses on the complete authored record
Use one short reader-facing title and an audience-first summary, then ordered non-empty Breaking, Removed, New, Changed and Fixed results. Explain what changed, why, affected supported uses, compatibility and complete adoption actions or a justified no-action result in each result's prose. Keep prerequisites, ordering, verification and mandatory intermediate operations in the record itself, with supporting evidence and references scoped to the result they verify.
The complete in-document example is named Complete description example. Its anchor is now #complete-description-example, replacing #copy-the-complete-template. The single announcement boundary and full body remain unchanged in purpose; announcements do not truncate the published note. Maintained links adopt the new anchor. Existing skills still route to the same canonical PR Format page and its release-coverage analysis; no additional skill, file distributor or plugin installation is required for this correction.
PR Format contains no repository PR-template-file discussion: no file locations, copying/inheritance, local exceptions, presence/absence policy or deletion history. Those rules belong to the repository standards below. Product integration-template compatibility evidence remains distinct and required where a delivered result affects a supported integration.
Technical details
Changed surface
Standards checked
Framework docs checked
Result
PR Format complete example, record evidence and anchors
Natural Language, Markdown, Documentation Model, PR Format
Complete consumer record and source-range authoring
Aligned
Release Management result evidence
Specification/design separation, Markdown
Actual title/body/source coverage, retained product-integration compatibility
Aligned
Repository-specific contribution PR-format links
Markdown, canonical ownership
Full description example; existing local build/index/link instructions
Required structure, one boundary, five classifiers/evidence prompts and release-first order
Aligned
The tests separate record quality from repository file policy. Record tests verify the complete example and ordered classifiers, marker count, publication/candidate identity fields, five scoped release-evidence prompts, release-first analysis, and five affected-product integration prompts. They also reject GitHub PR-template-file discussion on this page without rejecting legitimate product integration contracts. File-policy tests inspect the owning repository/organization/governance pages, not PR Format. Five ownership/naming cases failed before the refinement and pass after it.
The old example link is a documentation-anchor transition, not a runtime migration. Required old-to-new consumer actions still belong in the relevant release record; product docs retain supported target-state usage rather than a migration hierarchy or changelog.
Changed: Repository standards require canonical adherence without PR-template files
Repository Standard owns the no-file rule for every MSX repository type and the special MSXOrg/.github and PSModule/.github sources. GitHub PR-template files, multiple-template directories, generated copies and local exceptions are not part of this contract. Organization Standard and Repository Governance reference that one owner; their former mandatory default-file rows and local PR-template exception are removed.
Authors and validators verify the actual title, complete body, source coverage, compatibility/adoption evidence and normal review gates. An inherited scaffold, file-presence check or similarity to a central copy does not prove adherence. The complete canonical record example remains in the docs. Other code-of-conduct/security/support/contribution/issue-intake defaults and genuine repository-specific contribution instructions are unaffected; this is not an organization-wide community-file cleanup.
Separate source and consumer owners remove existing PR-template files and revise their source docs/check expectations. This PR introduces no distributor, physically edits none of their workspaces and claims no pending deletion is merged. A missing file never substitutes for Markdown/source/head/containment validation or complete PR record quality.
Technical details
Changed surface
Standards checked
Framework docs checked
Result
Repository Standard no-file policy and PR/contribution guidance
Standard ownership, Markdown, Natural Language
One policy owner; canonical actual-record verification
Aligned
Organization Standard community/review/default rows
Standard ownership, Markdown
Other community defaults preserved; PR-file requirements/exceptions removed
Aligned
Repository Governance defaults and reconciliation evidence
Design ownership, Markdown
Required-source row removed without changing live controls
Aligned
Markdown linter comment
YAML/Markdown standards
Only obsolete PR-template commentary changed; parsed configuration values are identical
Aligned
Repository-policy regression block
PowerShell/Pester, source inventory
Own-policy links, no tracked PR file, case/extension/directory detection, unaffected issue forms
Aligned
The corrected regression checks were run against exported frozen guidance with no commits: five actual policy cases failed while eleven preservation/path cases passed. Current source checks recognize uppercase/lowercase PR file names, alternate extensions and multiple-template directories, while leaving issue forms and canonical PR Format docs unaffected. MSXOrg/docs contains no tracked GitHub PR-template file.
Independent full, non-truncated default-source reads confirmed these still-present files at the measured immutable sources:
Repository
Source
File
MSXOrg/.github
0c67251812ea306543f3a14ab473ae357cfb76ac
.github/pull_request_template.md
PSModule/.github
f424237c98b5b020f80e8c9563dbc37256fc1ec0
.github/pull_request_template.md
PSModule/Yml
93d2656563a719d99416b9e13a05e65f6f815498
.github/pull_request_template.md
PSModule/PSSemVer
1a621b14286331569f4d1ffd4643999c2a2a6ca8
.github/pull_request_template.md
These are measured source/consumer counterexamples with separate removal owners, not evidence that the new no-file state has already landed. The Project's complete 71-repository inventory additionally identified the stale PSModule/Template-PSModule#42 candidate as separately owned reconciliation. PSModule/Process-PSModule#525 tracks the bounded producer anatomy/audit requirement reconciliation; central/default validators have separate owners. Their publisher/Build/runtime behavior remains outside this documentation revision.
The MSXOrg/docs#231 owner confirmed its clean frozen branch and no pending overlapping edits. The exact community composition boundary is the PR-template rows/paragraphs only: preserve its conditional local-contribution rule and all other inherited defaults while adopting the new no-file policy links. No #196/#208/#230/#231 tracked branch was edited here.
Changed: Release-bound authoring starts from actual artifact publication
Before drafting the title, results, adoption actions or compatibility decision, resolve the actual latest successful artifact publication for the same product, target and channel and verify its immutable source. Pin that artifact/source and the exact candidate PR source, verify intended lineage and compare those source trees. The complete delivered range includes earlier merged, skipped or unshipped changes; the ordinary PR-base diff remains separate implementation/reviewer evidence, not the note boundary.
A GitHub Latest hint, moving tag, assumed highest version or overall failed run is not publication-baseline proof. Module publication to Gallery counts even when later GitHub completion fails: the next module record starts from its already-published source. Completing that older GitHub record does not make module changes new again. Multiple artifact targets/channels have independently pinned consumer baselines and applicability.
Resolve missing/unverifiable evidence, ambiguous scope and diverged lineage explicitly. A verified initial publication has reviewed whole-candidate coverage and initial adoption instructions, not a fabricated predecessor or no-action/patch assumption. Re-read publication and candidate identities before readiness/snapshot capture and refresh comparison, actions and compatibility when either changes. This is the preserved authoring procedure, not a new publisher/version resolver or Build/artifact-promotion design.
Technical details
Changed surface
Standards checked
Framework docs checked
Result
Publication-baseline-first procedure, five result prompts and readiness
PR Format, Markdown
Exact publication/candidate identities, complete range and scoped PR diff
Aligned
Release Management source binding and note evidence
Specification/design ownership
Actual artifact publication versus version/completion baselines
Aligned
Thin PR-format skill and paired plugin metadata
Plugin granularity/versioning, manifest tests
Prior 0.1.1 canonical entrypoint retained
Aligned
The anonymous Git experiment remains exact source-tree evidence: published A-to-candidate C includes earlier unshipped B and current C, while scoped B-to-C includes only the current PR. Simulated Gallery-success/GitHub-failure evidence for B keeps module coverage at B-to-C even after older GitHub completion. Changed candidate/publication pairs change coverage, and unrelated lineage is rejected. Receipts were simulated inputs, not a live publish or historical repair.
Local validation passes: all 80 Pester tests in seven suites, 127 documentation pages plus contribution-guide lint, indexes/relative anchors, seven cross-repository links, actual pinned Zensical 0.0.59 build and rendered new-anchor checks, zero PowerShell analyzer diagnostics, existing plugin-manifest validation, and patch checks. The parsed linter configuration remains unchanged. All five required hosted checks succeed on this exact head: Lint, Build, Test, Links, and Cross-repository links. Both completed pull_request runs identify this source head.
Complete current-head review:5725019918 is APPROVED on bc03a5992615f65d1d5346dc48e7506e80b8b6ca. The full summary records no active/open or suppressed concerns; all review threads are resolved and thread pagination is complete. The prior be8c340 approval was not used as approval of this correction. This is the automated author-side pass, not independent human approval or permission to merge.
All five existing Task #226 plan items are fulfilled: verified state/cases, bounded canonical authoring, directly coupled policy/evidence/link reconciliation, native checks/current-head full review, and final acceptance/immutable handoff. The scoped sweep covered PR authoring, source/default validation, release/consumer and community guidance; only Task #226 is the closing delivery leaf. The existing native prerequisite MSXOrg/docs#166 is completed. Its five-context required-check rule and the existing approval/thread constraints remain unchanged; no live merge attempt, injected failure or bypass was used.
Changed: Effective decisions and release-history ownership are preserved
DefaultBump still accepts patch/minor/major with documented shared patch, repository settings, explicitly supplied supported caller overrides and one explicit owned bump override in that order. Omitted inputs inherit valid policy; invalid supplied settings and conflicting owned signals fail even when another source supplies a level. An effective default removes the need for a per-PR bump label, not the need for compatibility evidence. The exact owned set remains release:patch, release:minor, release:major, release:prerelease and release:skip.
Verify actual native/shared producer controls or a supported adapter before using signals. Prerelease uses the resolved bump; skip combines with no other owned signal. Unmanaged routes omit all release metadata/labels; this repository deploys Pages without a versioned release artifact, so this PR retains neither a Release decisions block nor a release label. No undecided caller-override interface, allocator, publisher or live input is approved or implemented here.
Complete PR/release records remain the sufficient version-specific upgrade history; resource docs describe supported target-state usage. Mandatory intermediate operations and superseded actions remain explicit. Campaign/native associations and completion-aware issue links retain their established ownership. No migration-guide/changelog duplication, date strategy, native dependency mutation, publication, historical backfill, label/permission/rules edit, merge or auto-merge is performed.
Technical details
Changed surface
Standards checked
Framework docs checked
Result
Automation Labels, settings/decision rules, VS Code and continuous-delivery guidance
Owning standards/capabilities
Accepted default/signal, source validation and native mapping retained
Aligned
Documentation Model, Fleet, workflow/readiness and Task/Bug planning
Ways of Working, issue hierarchy, PR Format
Actual scoped implementation evidence and sufficient consumer record preserved
Aligned
The existing PRs stay separate on main. Eventual landing is one at a time with every remaining overlapping branch reconciled against advanced main and CI/full review repeated. Other owners must consume the refreshed immutable correspondence; their prior frozen example/file expectations are not claimed current. This PR does not edit their tracked candidates or waive their independent prerequisites.
Replace the icon-and-type schema with audience-first titles, evidence-based descriptions, and route-conditional MSX release decisions. Document the inherited organization template and refresh navigation and anchor references.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Keep workflow mechanics in their owning pages, make release decisions conditional on route invocation, and preserve campaign identity without polluting reader-facing pull request titles.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Replace the channel-specific Slack boundary with the approved announcement marker while preserving exact once-only placement.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
This documentation-only PR establishes audience-first pull request guidance across MSX and makes release records the authoritative source of consumer upgrade instructions.
Changes:
Replaces prefixed titles and global evidence blocks with reader-facing results, ordered classifiers, and section-scoped evidence.
Defines conditional release metadata, release defaults, and native-producer applicability.
Aligns workflow, fleet, dependency, and documentation guidance with the canonical PR format.
File
Description
src/docs/Ways-of-Working/Workflow.md
Clarifies PR descriptions as durable, release-ready records.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
The promotion guidance conflicts with caller-override precedence and could cause authors to record a bump that differs from the resolver’s effective DefaultBump.
This restricts promotion bumps to a label or the repository default, conflicting with the caller-override precedence in release-management/design.md:108–117. For example, repository DefaultBump: major with a supported explicit caller override of patch and no bump label resolves to patch, but this instruction tells the promotion author to record major. Refer to the valid effective DefaultBump, including shared defaults and supported caller overrides, so promotion records agree with the resolver.
Marius Storhaug (MariusStorhaug)
changed the title
Pull request guidance uses audience-first release notes
Pull request guidance starts from the published artifact source
Oct 31, 2026
Marius Storhaug (MariusStorhaug)
changed the title
Pull request guidance starts from the published artifact source
Pull request guidance describes complete source-bound records
Oct 31, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
documentationImprovements or additions to documentation
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Marius Storhaug (MariusStorhaug)
added
the
documentation
PR Format describes the actual title and complete body: audience-first results, release-range-first analysis, complete adoption/compatibility evidence, one announcement boundary and conditional release decisions. Repository file policy is owned separately by Repository/Organization/Governance guidance, not by the PR Format page.
Authors use canonical guidance for the resulting record. Repository standards exclude GitHub PR-template files from ordinary and central-default sources, while retaining other community defaults, genuine repository-specific contribution instructions and supported product-integration contracts. This delivery changes guidance and checks in MSXOrg/docs; separate owners remove their actual source/consumer files. No publisher, live caller, artifact, tag, governance setting or release history is changed here.
Changed: PR Format focuses on the complete authored record
Use one short reader-facing title and an audience-first summary, then ordered non-empty Breaking, Removed, New, Changed and Fixed results. Explain what changed, why, affected supported uses, compatibility and complete adoption actions or a justified no-action result in each result's prose. Keep prerequisites, ordering, verification and mandatory intermediate operations in the record itself, with supporting evidence and references scoped to the result they verify.
The complete in-document example is named Complete description example. Its anchor is now
#complete-description-example, replacing#copy-the-complete-template. The single announcement boundary and full body remain unchanged in purpose; announcements do not truncate the published note. Maintained links adopt the new anchor. Existing skills still route to the same canonical PR Format page and its release-coverage analysis; no additional skill, file distributor or plugin installation is required for this correction.PR Format contains no repository PR-template-file discussion: no file locations, copying/inheritance, local exceptions, presence/absence policy or deletion history. Those rules belong to the repository standards below. Product integration-template compatibility evidence remains distinct and required where a delivered result affects a supported integration.
Technical details
The tests separate record quality from repository file policy. Record tests verify the complete example and ordered classifiers, marker count, publication/candidate identity fields, five scoped release-evidence prompts, release-first analysis, and five affected-product integration prompts. They also reject GitHub PR-template-file discussion on this page without rejecting legitimate product integration contracts. File-policy tests inspect the owning repository/organization/governance pages, not PR Format. Five ownership/naming cases failed before the refinement and pass after it.
The old example link is a documentation-anchor transition, not a runtime migration. Required old-to-new consumer actions still belong in the relevant release record; product docs retain supported target-state usage rather than a migration hierarchy or changelog.
Changed: Repository standards require canonical adherence without PR-template files
Repository Standard owns the no-file rule for every MSX repository type and the special
MSXOrg/.githubandPSModule/.githubsources. GitHub PR-template files, multiple-template directories, generated copies and local exceptions are not part of this contract. Organization Standard and Repository Governance reference that one owner; their former mandatory default-file rows and local PR-template exception are removed.Authors and validators verify the actual title, complete body, source coverage, compatibility/adoption evidence and normal review gates. An inherited scaffold, file-presence check or similarity to a central copy does not prove adherence. The complete canonical record example remains in the docs. Other code-of-conduct/security/support/contribution/issue-intake defaults and genuine repository-specific contribution instructions are unaffected; this is not an organization-wide community-file cleanup.
Separate source and consumer owners remove existing PR-template files and revise their source docs/check expectations. This PR introduces no distributor, physically edits none of their workspaces and claims no pending deletion is merged. A missing file never substitutes for Markdown/source/head/containment validation or complete PR record quality.
Technical details
The corrected regression checks were run against exported frozen guidance with no commits: five actual policy cases failed while eleven preservation/path cases passed. Current source checks recognize uppercase/lowercase PR file names, alternate extensions and multiple-template directories, while leaving issue forms and canonical PR Format docs unaffected. MSXOrg/docs contains no tracked GitHub PR-template file.
Independent full, non-truncated default-source reads confirmed these still-present files at the measured immutable sources:
0c67251812ea306543f3a14ab473ae357cfb76ac.github/pull_request_template.mdf424237c98b5b020f80e8c9563dbc37256fc1ec0.github/pull_request_template.md93d2656563a719d99416b9e13a05e65f6f815498.github/pull_request_template.md1a621b14286331569f4d1ffd4643999c2a2a6ca8.github/pull_request_template.mdThese are measured source/consumer counterexamples with separate removal owners, not evidence that the new no-file state has already landed. The Project's complete 71-repository inventory additionally identified the stale PSModule/Template-PSModule#42 candidate as separately owned reconciliation. PSModule/Process-PSModule#525 tracks the bounded producer anatomy/audit requirement reconciliation; central/default validators have separate owners. Their publisher/Build/runtime behavior remains outside this documentation revision.
The MSXOrg/docs#231 owner confirmed its clean frozen branch and no pending overlapping edits. The exact community composition boundary is the PR-template rows/paragraphs only: preserve its conditional local-contribution rule and all other inherited defaults while adopting the new no-file policy links. No #196/#208/#230/#231 tracked branch was edited here.
Related references
Changed: Release-bound authoring starts from actual artifact publication
Before drafting the title, results, adoption actions or compatibility decision, resolve the actual latest successful artifact publication for the same product, target and channel and verify its immutable source. Pin that artifact/source and the exact candidate PR source, verify intended lineage and compare those source trees. The complete delivered range includes earlier merged, skipped or unshipped changes; the ordinary PR-base diff remains separate implementation/reviewer evidence, not the note boundary.
A GitHub Latest hint, moving tag, assumed highest version or overall failed run is not publication-baseline proof. Module publication to Gallery counts even when later GitHub completion fails: the next module record starts from its already-published source. Completing that older GitHub record does not make module changes new again. Multiple artifact targets/channels have independently pinned consumer baselines and applicability.
Resolve missing/unverifiable evidence, ambiguous scope and diverged lineage explicitly. A verified initial publication has reviewed whole-candidate coverage and initial adoption instructions, not a fabricated predecessor or no-action/patch assumption. Re-read publication and candidate identities before readiness/snapshot capture and refresh comparison, actions and compatibility when either changes. This is the preserved authoring procedure, not a new publisher/version resolver or Build/artifact-promotion design.
Technical details
The anonymous Git experiment remains exact source-tree evidence: published A-to-candidate C includes earlier unshipped B and current C, while scoped B-to-C includes only the current PR. Simulated Gallery-success/GitHub-failure evidence for B keeps module coverage at B-to-C even after older GitHub completion. Changed candidate/publication pairs change coverage, and unrelated lineage is rejected. Receipts were simulated inputs, not a live publish or historical repair.
Final committed/pushed head:
bc03a5992615f65d1d5346dc48e7506e80b8b6ca. This ordinary commit refines the previousbe8c340...authoring correspondence without amendment or history discard. Canonical anchors are release-first analysis, complete description example, repository file policy, and defaults source guidance.Local validation passes: all 80 Pester tests in seven suites, 127 documentation pages plus contribution-guide lint, indexes/relative anchors, seven cross-repository links, actual pinned Zensical 0.0.59 build and rendered new-anchor checks, zero PowerShell analyzer diagnostics, existing plugin-manifest validation, and patch checks. The parsed linter configuration remains unchanged. All five required hosted checks succeed on this exact head: Lint, Build, Test, Links, and Cross-repository links. Both completed
pull_requestruns identify this source head.Complete current-head review: 5725019918 is APPROVED on
bc03a5992615f65d1d5346dc48e7506e80b8b6ca. The full summary records no active/open or suppressed concerns; all review threads are resolved and thread pagination is complete. The prior be8c340 approval was not used as approval of this correction. This is the automated author-side pass, not independent human approval or permission to merge.All five existing Task #226 plan items are fulfilled: verified state/cases, bounded canonical authoring, directly coupled policy/evidence/link reconciliation, native checks/current-head full review, and final acceptance/immutable handoff. The scoped sweep covered PR authoring, source/default validation, release/consumer and community guidance; only Task #226 is the closing delivery leaf. The existing native prerequisite MSXOrg/docs#166 is completed. Its five-context required-check rule and the existing approval/thread constraints remain unchanged; no live merge attempt, injected failure or bypass was used.
Changed: Effective decisions and release-history ownership are preserved
DefaultBumpstill accepts patch/minor/major with documented shared patch, repository settings, explicitly supplied supported caller overrides and one explicit owned bump override in that order. Omitted inputs inherit valid policy; invalid supplied settings and conflicting owned signals fail even when another source supplies a level. An effective default removes the need for a per-PR bump label, not the need for compatibility evidence. The exact owned set remainsrelease:patch,release:minor,release:major,release:prereleaseandrelease:skip.Verify actual native/shared producer controls or a supported adapter before using signals. Prerelease uses the resolved bump; skip combines with no other owned signal. Unmanaged routes omit all release metadata/labels; this repository deploys Pages without a versioned release artifact, so this PR retains neither a Release decisions block nor a release label. No undecided caller-override interface, allocator, publisher or live input is approved or implemented here.
Complete PR/release records remain the sufficient version-specific upgrade history; resource docs describe supported target-state usage. Mandatory intermediate operations and superseded actions remain explicit. Campaign/native associations and completion-aware issue links retain their established ownership. No migration-guide/changelog duplication, date strategy, native dependency mutation, publication, historical backfill, label/permission/rules edit, merge or auto-merge is performed.
Technical details
The existing PRs stay separate on main. Eventual landing is one at a time with every remaining overlapping branch reconciled against advanced main and CI/full review repeated. Other owners must consume the refreshed immutable correspondence; their prior frozen example/file expectations are not claimed current. This PR does not edit their tracked candidates or waive their independent prerequisites.
Related references