Skip to content

Release authors can write self-contained upgrade notes - #537

Open
Marius Storhaug (MariusStorhaug) wants to merge 7 commits into
mainfrom
release-note-standards
Open

Marius Storhaug (MariusStorhaug) wants to merge 7 commits into
mainfrom
release-note-standards

Conversation

@MariusStorhaug

@MariusStorhaug Marius Storhaug (MariusStorhaug) commented Sep 5, 2026 •

Copy link
Copy Markdown
Member

Release authors get documentation-guided, complete incremental upgrade records without a repository PR-template file. The guidance makes published notes the sufficient reference for what changed, why, affected uses, compatibility, and exact consumer actions or an explicit no-action result.

Use the authoring guide and canonical PR Format's in-document examples for the next release-bound PR. The optional authoring skill routes to the same evergreen sources; no Project Library plan is required. Existing consumers need no workflow, configuration, code, or invocation changes from this documentation-only PR.

New: Authors can write complete consumer upgrade records

The authoring guide applies the canonical MSX PR Format to Process-PSModule release authoring. Write the actual title and complete description directly in the pull request using the format's in-document examples. The guide is discoverable from documentation navigation, the index, versioning and configuration guides, repository-standard references, and the plugin README. The optional psmodule-release-note-authoring skill remains a thin pointer with agent-specific reporting and stop conditions, not another policy source.

For the next release-bound PR:

  1. Resolve the actual published-artifact-to-candidate range using canonical PR Format's publication and immutable-source checks. Reconcile the complete delivered range, including earlier merged, skipped, or unshipped deltas. Keep the ordinary PR-base comparison separate. State verified semantic impact and applicable effective configuration; leave final numeric coordinates to the publisher.
  2. Write an audience-first title and summary, retain the summary marker, and group applicable results in Breaking, Removed, New, Changed, then Fixed order. Put each result's rationale, applicability, compatibility, exact actions or explicit no-action result, prerequisites, order, verification, and necessary old-to-new examples in its reader-facing prose. Keep its implementation evidence and related references scoped to that result.
  3. Keep resource documentation focused on supported current behavior, inputs, outputs, and usage. Keep release-specific transitions in the release record; preserve legitimate decision and research records. Verify that the notes contain all required upgrade instructions without requiring PR or diff inspection.

Consumers read every applicable release after their actual baseline through the target in order and compose the actions. Reading a record does not require installing that version. Later supersession instructions explain which edits remain while preserving explicitly required intermediate installations or runs. Missing required instructions are evidence gaps, not implicit no-action results. PRs and commit diffs remain optional depth.

This adds authoring guidance and an optional prompt, not release-runtime behavior. Existing release-note settings, version resolution, labels, defaults, workflows, and publisher behavior remain unchanged. No product-integration template update applies because this change does not alter a producer runtime or caller contract. No intermediate installation or consumer upgrade is required to adopt the guidance. The repository-relative guide is available in this candidate; its published-page fallback depends on normal documentation delivery and is not published by this task.

Technical details
  • The exact candidate is PSModule/Process-PSModule at af22c475873b21b8afa5ba7ecb87cb2bf8efabd2. The scoped implementation comparison is against main merge base 3505ca4b68b5c79e0b2a3051d0c33f2e9b275358; it is not substituted for a published-artifact baseline.
  • The correction removes the automatic PR-template file introduced in candidate 05de7ee4fa55d6032e4d469bde575e51421b0a1b, its local starting-point link, the authoring skill's template requirement, both repository-standard required-file rows, and the v8 skill's template baseline/preservation references. The complete revised Git tree contains no automatic PR-template file, and no replacement file is added.
  • The canonical format owns the actual PR record. The guide owns its PSModule-specific application and short illustrative release replay. The thin skill uses the owning guide and standard, without requiring a Project Library plan or past handoff as lasting authority.
  • Canonical format and documentation ownership were checked against merged MSXOrg/docs#209 at aa9b5cecc69f4cbe6aa04a5dd70ff9cdadeeac3d. Older Library scaffold-distribution proposals are not authority for this correction.
  • The guide's existing release-range, audience, adoption, marker, supersession, runtime-setting, and distinct product-integration template evidence remains unchanged. The illustrative timeout walkthrough is not a change to Process-PSModule's runtime or release history.
  • The existing NoRelease label is retained, with no label or publisher changes. This scoped correction does not implement or verify a shared Release Management native-producer signal mapping, required decision check, or actual publication-to-candidate provenance. The owning producer must verify those prerequisites before any release-bound finalization; native producers are not declared unmanaged merely because they do not call a named shared workflow. No unsupported release:* labels or release-decision block are added here.
  • No publisher, Build, metadata, original-artifact promotion, historical release-note correction, Discord sending, or live-governance changes are included. Plugin and marketplace metadata remain unchanged.
Changed surface Standards checked Framework docs checked Result
docs/content/guides/** Canonical PR Format, Documentation Model, guide structure, Markdown, and en-US prose Existing release-note defaults, versioning, complete authoring instructions, and illustrative replay Aligned; local-template starting point removed
docs/content/reference/repository-standard.md Canonical documentation and PR-record ownership Existing module repository layout PR-template requirements removed; authoring routes to the owning documentation
.github/plugin/** Thin skill and plugin integration guidance Authoring guide, plugin discoverability, and v8 baseline Template requirements removed; guide links and metadata preserved
docs/zensical.toml, docs/content/index.md Documentation navigation Published documentation structure Authoring guide remains discoverable

Validation

Command or review Result
npx --no-install markdownlint-cli2 --config .github\linters\.markdown-lint.yml .github\plugin\README.md .github\plugin\psmodule\skills\psmodule-release-note-authoring\SKILL.md .github\plugin\psmodule\skills\psmodule-v8-upgrade\SKILL.md docs\content\guides\formatting-release-note-prs.md docs\content\guides\configuring-the-pipeline.md docs\content\guides\versioning-and-releases.md docs\content\index.md docs\content\reference\repository-standard.md Passed: all eight candidate Markdown files, zero issues.
npm exec --offline --yes --package=textlint --package=textlint-rule-terminology --package=textlint-filter-rule-comments -- textlint --config .github\linters\.textlintrc .github\plugin\README.md .github\plugin\psmodule\skills\psmodule-release-note-authoring\SKILL.md .github\plugin\psmodule\skills\psmodule-v8-upgrade\SKILL.md docs\content\guides\formatting-release-note-prs.md docs\content\guides\configuring-the-pipeline.md docs\content\guides\versioning-and-releases.md docs\content\index.md docs\content\reference\repository-standard.md Passed with the repository terminology configuration.
Set-Location .\docs; zensical build --clean Passed: complete site build, no issues. This does not publish the site.
Get-Content -Raw -LiteralPath .github\plugin\psmodule\plugin.json | ConvertFrom-Json | Out-Null and Get-Content -Raw -LiteralPath .github\plugin\marketplace.json | ConvertFrom-Json | Out-Null Passed: both manifests parse; their committed content is unchanged.
git --no-pager diff --check 3505ca4b68b5c79e0b2a3051d0c33f2e9b275358..HEAD Passed for the full revised candidate.
Complete candidate-tree scan using git ls-tree -r --name-only HEAD Passed: the no-file assertion failed on the earlier candidate and passes on af22c475873b21b8afa5ba7ecb87cb2bf8efabd2; no automatic PR-template file remains.
Relative-link and preservation checks Passed: all 10 relative links in the authoring skill, guide, and plugin README resolve. Existing authoring requirements, replay, product-integration evidence, runtime/settings, workflows/actions, and plugin metadata are preserved.
Full local diff and standards review Passed: the correction is limited to the automatic file and its dependent documentation/prompt references; no new policy copy, marketplace, or runtime surface is introduced.
gh pr checks 537 --repo PSModule/Process-PSModule --watch --interval 10 --fail-fast Passed on the revised head: documentation Build, documentation Lint, repository Lint, and CodeQL checks succeeded; publication was skipped.
Fresh full Copilot review on af22c475873b21b8afa5ba7ecb87cb2bf8efabd2 Identified stale template references in the earlier PR description, not a remaining source file. This description and validation table correct that feedback; follow-up review verifies the corrected record.

The illustrative content walkthrough reads the breaking v2.0.0 timeout-key transition and no-action v2.0.1 record from baseline v1.4.2. A consumer with timeout: 20 composes the notes, changes it to timeoutSeconds: 20 with the target upgrade, selects v2.0.1 directly, and verifies accepted configuration and timeout cancellation. A consumer omitting the key retains the 30-second default; a consumer already on v2.0.0 needs no configuration edit. No intermediate installation or PR/diff lookup is required. These are fictional published coordinates and a content check, not executed product tests or repository release history.

PowerShell/Pester tests, release publishers, and actual consumer upgrades were not run because this PR changes documentation and authoring prompts only. Publication-baseline and native-producer integration verification remain the owning publisher's separate prerequisites, not completed work in this correction.

Related references

Co-authored-by: GitHub Copilot <198982749+Copilot@users.noreply.github.com>
Co-authored-by: GitHub Copilot <198982749+Copilot@users.noreply.github.com>
@github-actions

github-actions Bot commented Sep 5, 2026 •

Copy link
Copy Markdown

Super-linter summary

Language Validation result
CHECKOV Pass ✅
CSS Pass ✅
CSS_PRETTIER Pass ✅
GITHUB_ACTIONS Pass ✅
GITHUB_ACTIONS_ZIZMOR Pass ✅
GITLEAKS Pass ✅
GIT_MERGE_CONFLICT_MARKERS Pass ✅
HTML Pass ✅
JAVASCRIPT_ES Pass ✅
JAVASCRIPT_PRETTIER Pass ✅
MARKDOWN Pass ✅
NATURAL_LANGUAGE Pass ✅
POWERSHELL Pass ✅
PRE_COMMIT Pass ✅
SPELL_CODESPELL Pass ✅
TRIVY Pass ✅
YAML Pass ✅

All files and directories linted successfully

For more information, see the GitHub Actions workflow run

Powered by Super-linter

Co-authored-by: GitHub Copilot <198982749+Copilot@users.noreply.github.com>
@MariusStorhaug Marius Storhaug (MariusStorhaug) changed the title 📖 [Docs]: Release notes now explain adoption and version impact 📖 [Docs]: Pull requests now control user-ready release notes Sep 5, 2026
Marius Storhaug (MariusStorhaug) added a commit to MSXOrg/docs that referenced this pull request Sep 6, 2026
Release-bound pull requests classify changes for their declared
user/integrator audience and describe the incremental actions that
audience needs to adopt them. Release levels come from an explicit
decision or an opt-in repository default; missing decisions must block
merge in CI. Published notes preserve the complete authored record and
its source/template evidence.

## Changed: Change type follows the target audience

Each initiative describes its audience and supported jobs; each
repository README states its audience or explicitly adopts that
definition and records any specialization. Users and integrators can be
the same people: PSModule module users integrate commands into their
work, and Process-PSModule users integrate the delivery workflow into
their module repositories.

Change type follows the highest impact on supported uses, not file
location, edit size, or the reviewer's perspective. An incompatible
output, runtime requirement, or caller interface remains breaking even
when an interactive command still works or only a manifest or `.github/`
file changes.

## Changed: Repository defaults are explicit policy decisions

For PR-driven releases, an owned bump label overrides the optional
`DefaultBump` in `.github/release.config.yml`. The setting accepts
`patch`, `minor`, or `major`. If neither supplies a level and no valid
`release:skip` is selected, the decision is missing: there is no
implicit patch fallback. Prerelease mode can use an explicit or
configured bump, but the mode alone is not a level. Invalid defaults and
conflicting owned labels fail rather than selecting a convenient
fallback.

The declared default is not evidence of compatibility: authors still
assess the audience impact and override the default when needed.
Release-label names, SemVer arithmetic, and pre-1.0 mapping remain
unchanged. The optional ad hoc dispatch keeps its existing explicit-bump
requirement.

## Changed: Missing decisions block merge, not only publication

The release contract requires a named PR decision-validation check,
enforced by the target branch's ruleset or protection. Missing, invalid,
or conflicting decisions fail it before merge. The check re-evaluates
source, release-label, and settings changes; a failed, pending, or
absent required result prevents manual and automatic merge. A valid skip
passes with a no-release outcome instead of skipping validation.
Publication validates its actual inputs again.

This PR documents that contract; it does not implement producer CI
workflows or change repository rulesets.

## Changed: Consumer adoption and publication evidence are complete

PR descriptions include Adopting this release and Release impact
sections, an applicability-aware consumer change record, and a verified
immutable template baseline where applicable. Public interfaces belong
in user-facing prose, and breaking behavior remains explicit
independently of version classification.

The release-management contract preserves the release-bound title and
complete description. Actual coordinates and provenance remain separate
from authored prose, and version-computation and consumer-change
baselines remain distinct. Bundled, optional ad hoc, and source-specific
prerelease records retain equivalent evidence. Metadata corrections
preserve an audit without changing artifacts or historical behavior.
Release filters reflect product contracts, not directory names alone.

## Adopting this release

1. Initiative owners declare their audience and supported jobs.
Repository maintainers state the audience, jobs, and interfaces in the
README, or explicitly adopt the initiative definition and record any
specialization. Detailed users and jobs stay in the linked capability
specification.
2. For each PR release decision, select an owned level or intentionally
configure `DefaultBump` in the release settings. An explicit level wins;
neither source is an error, not a patch default. Select `release:skip`
for a no-release decision. Verify the resolved level against the
audience impact.
3. Use the PR Format structure: ordered adoption or an explicit
no-action outcome, effective release impact and its source without
predicting a final version, and each changed surface's before/after
behavior, applicability, exact action, and verification. Include a
verified immutable template baseline where applicable, or explain why
none applies.
4. Producer CI maintainers run the same decision resolver during PR
validation, make its named check required in branch protection/rulesets,
and cover relevant source and metadata changes. Missing, invalid,
conflicting, pending, and absent results must not permit merge; a valid
skip must produce an explicit successful result.
5. Publisher maintainers preserve the complete source-bound record,
resolve actual publication coordinates, audit metadata corrections, and
keep consumer-facing interfaces in release filters. Implementation and
governance changes remain separately scoped in their owning
repositories.

## Release impact

| Field | Value |
| --- | --- |
| Effective decision | `release:skip`, documentation only. |
| Semantic effect | No versioned artifact release. The documented PR
decision contract permits an opt-in default and requires a
merge-blocking CI gate; it does not install that gate in producers. |
| Release/base coordinates | No version is produced by this PR. |

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

### Consumer change record

| Identifier / surface | Before | After | Applicability / prerequisites
| Consumer action | Verification |
| --- | --- | --- | --- | --- | --- |
| AUDIENCE-CONTEXT / initiative docs and READMEs | Audience context is
not required as an input to classification. | Explicit audience, jobs,
and interfaces anchor classification; user/integrator roles may overlap.
| Initiative owners, maintainers, and PR authors. | Adoption steps 1-2.
| Readers identify supported uses without inferring them from ownership
or filenames. |
| RELEASE-DECISION / release settings and PR CI | The spec forbids
defaults while PR evidence permits configured policy; missing decisions
lack an explicit required pre-merge check contract. | An explicit bump
overrides optional `DefaultBump`; neither source fails. Required CI
validates the decision and blocks merge on missing/invalid/conflicting
input. | Producers implementing Release Management and consuming
frameworks. | Adoption steps 2 and 4. |
Explicit/default/override/skip/mode/error cases agree; the decision
check is required, not merely advisory. |
| PR-EVIDENCE / release-bound PR bodies | Adoption may be scattered and
path/size heuristics can obscure impact. | Ordered adoption, resolved
release impact, consumer/template evidence, and highest-impact
classification are required. | Authors following MSX PR Format. |
Adoption steps 2-3. | Every changed surface records applicability,
action, and result; no-action and breaking cases stay explicit. |
| NOTE-PUBLICATION / publication contract | Complete-body,
source-snapshot, correction, and product-aware filter obligations are
not explicit. | Full authored records retain actual coordinates and
source identity; corrections preserve artifacts; filters include shipped
interfaces. | Publisher maintainers. | Adoption step 5. | Published
content matches its source-bound snapshot, and metadata corrections
leave artifact/source identities intact. |

### Template baseline

Not applicable: this PR changes shared standards, not a versioned
framework integration or its template. The PR-format skill remains an
unchanged thin pointer; no plugin metadata or version change is needed.

### Maintainer evidence

- Delivery: #202, refined to a native Task and updated with
the user's audience, opt-in default, and pre-merge CI requirements. The
initial contract is in `6c07314` / `354dd8c`, audience clarification in
`b1a8262` / `e55c80b`, and decision/gate correction in `fd32b41`.
- Copilot review `5124988102` identified the default-policy
contradiction in its suppressed summary. The earlier zero-inline-comment
verdict missed that concern. Review now includes the complete summary,
including suppressed comments; zero inline comments alone is not a clean
round.
- The shared resolver is defined in Release Management. PR Format,
Automation Labels, readiness/Implement wording,
promotion/continuous-delivery guidance, Natural Language error examples,
and the VS Code framework agree with it. Generated release navigation is
current.
- `DefaultBump` reuses the setting name from #196, but the
user explicitly rejected that PR's implicit patch fallback. Coordination
is recorded there. Its branch, release-type redesign, and label rename
remain untouched and need reconciliation before merge.
- The existing index, relative-link, and targeted Markdown checks pass.
CI uses the existing cross-repository-link and Pester jobs; no
validation toolchain or publisher implementation was added.
- Convergence: release/adoption/PR-format and audience issues were
inspected. #67 still needs repository-standard files,
#143 still needs downstream-artifact mapping/enforcement, and
#203 owns the common consumer procedure. No additional issue
is fully satisfied.
- **Repository gate:** #166 remains a native prerequisite of
#202 and tracks missing required CI enforcement. The user
marked this PR ready; this session preserves that state and leaves
auto-merge disabled rather than changing governance or bypassing the
prerequisite.
- Delivery B remains prepared as #203, with a native
dependency on #202. The PSModule pilot, fleet README rollout,
and historical backfill remain outside this delivery.

| Changed surface | Standards checked | Framework docs checked | Result
|
| --- | --- | --- | --- |
| PR Format and related workflow/gate guidance | Natural Language,
Markdown, Documentation Model, standard template, issue/PR conventions |
Release Management; Merge Automation; audience contract | Aligned |
| Release Management spec/design/index | Natural Language, Markdown,
Documentation Model, spec/design templates | PR Format; Merge Automation
| Aligned |
| VS Code framework spec/design | Natural Language, Markdown,
Documentation Model, spec/design templates | Shared Release Management
contract | Aligned |
| README/organization/repository standards and audience examples |
Natural Language, Markdown, README-Driven Context | MSX documentation
purpose; PSModule initiative boundary | Aligned |
| Natural Language error examples | Natural Language, Markdown |
Release-decision validation contract | Aligned |

The walkthroughs below assess the documentation contract, not a running
producer or the PSModule pilot:

| Case group | Reconciled outcome |
| --- | --- |
| No-action patch; pre-1.0 break | No-action is explicit; Minor mapping
does not hide breaking behavior or required actions. |
| Skipped releases; prerelease; non-latest target | Each applicable
delta and source/template identity remains recoverable; latest metadata
does not replace historical evidence. |
| Shared user/integrator roles; path/size; mixed changes; missing
audience | Supported audience impact controls classification; absent
audience context is resolved rather than guessed. |
| Explicit level; configured default; override | A valid explicit label
wins; a configured default supplies a missing bump and is recorded as
the source. |
| Missing/invalid/conflicting decisions | The required PR check fails
and merge is blocked. No built-in patch or conflict fallback is
permitted. |
| Skip; prerelease; unowned labels | Valid skip passes without a bump; a
mode needs a resolved bump; unowned labels never supply a decision. |
| Changed labels/settings/source | Validation re-evaluates the candidate
inputs; publication revalidates its actual inputs too. |

</details>

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

- Resolves #202

### Related work

- Depends on #166
- Followed by #203
- References #196
- References #143
- References #67
- References PSModule/Process-PSModule#537

</details>
@MariusStorhaug Marius Storhaug (MariusStorhaug) changed the title 📖 [Docs]: Pull requests now control user-ready release notes Release authors can write self-contained upgrade notes Oct 25, 2026
@MariusStorhaug
Marius Storhaug (MariusStorhaug) marked this pull request as ready for review October 31, 2026 22:40
Copilot AI balanced review requested due to automatic review settings October 31, 2026 22:40
Copilot AI previously approved these changes Oct 31, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approved

The release-note authoring guidance and scaffolding have no active review issues.

No open issues 🎉

What changed in this PR

Adds guidance and authoring scaffolding for self-contained, incremental release notes in Process-PSModule. This documentation-only change leaves workflows, version resolution, labels, and publisher behavior unchanged.

Changes:

  • Defines how authors document baselines, consumer impact, exact upgrade actions, and verification.
  • Adds a PR template and thin authoring skill that point to the shared guidance.
  • Connects the guide to documentation navigation, references, and release-note examples.
File Description
docs/​zensical.toml Adds the authoring guide to navigation.
docs/​content/​reference/​repository-standard.md Updates PR-template descriptions and links to the guide.
docs/​content/​index.md Adds the guide to the documentation index.
docs/​content/​guides/​versioning-and-releases.md Explains composing release records for upgrades.
docs/​content/​guides/​formatting-release-note-prs.md Defines the authoring contract and illustrative upgrade replay.
docs/​content/​guides/​configuring-the-pipeline.md Updates the release-note example and links to the contract.
.github/​PULL_REQUEST_TEMPLATE.md Adds classified results, upgrade instructions, and scoped evidence scaffolding.
.github/​plugin/​README.md Introduces the release-note authoring skill.
.github/​plugin/​psmodule/​skills/​psmodule-release-note-authoring/​SKILL.md Adds guide links and agent handoff and stop conditions.

Review effort: Balanced

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

The PR description and validation table reference a missing PR-template file, conflicting with the guide’s actual entry points and potentially misdirecting authors.

1 open issue

Review effort: Balanced

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approved

No active review issues are reported for this documentation-only change.

No open issues 🎉

1 resolved since last review

Review effort: Balanced

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants