Release guidance uses keyed release types by MariusStorhaug · Pull Request #196 · MSXOrg/docs

Marius Storhaug (MariusStorhaug) · 2026-08-29T12:30:41Z

Release guidance maps configured branches through ReleaseType.Stable, ReleaseType.Prerelease, and ReleaseType.ReleaseCandidate. The stable route defaults to the repository default branch; the other routes are optional. Each branch has one effective routing assignment.

This changes documentation, not a released producer, settings loader, caller input, branch configuration, or publication. Authors implementing the canonical protocol use the keyed shape below. Existing consumers keep their producer's declared interface until a compatible implementation and its exact adoption instructions are released.

Changed: Release branches are keyed by the type they publish

The guidance replaces the release-branches list example with one ReleaseType object whose only supported keys are Stable, Prerelease, and ReleaseCandidate. Each key has at most one Branch. Unknown keys fail. Branch-assignment validation resolves inherited defaults first and then rejects any branch assigned to several routing types, whether the assignments are explicit or inherited.

Stable.Branch is the only stable-production authority. An omitted stable route inherits the repository default branch, and that assignment still participates in duplicate validation: an explicit prerelease or candidate assignment to the same branch is invalid. A configured candidate route publishes its own -rc.N series without stable publication or promotion to latest. Prerelease and ReleaseCandidate are routing types that both publish prereleases, not a third semantic-version mode or another owned release label. The VS Code framework points to the same shared routing contract.

# .github/release.settings.yml
DefaultBump: patch
ReleaseType:
  Stable:
    Branch: main
  Prerelease:
    Branch: dev
  ReleaseCandidate:
    Branch: rc

The existing effective-default contract remains: DefaultBump accepts patch, minor, or major; the shared default is patch; repository settings and explicitly supplied supported caller overrides refine it; one owned bump label overrides the valid effective default. Invalid supplied values and conflicting owned signals fail rather than fall back. Skip alone validates without publication, and prerelease mode uses the resolved explicit or default bump.

The canonical .github/release.settings.yml filename and its naming/input boundaries are already on main. This remaining diff does not rename another file or grant an older producer support for a different path. ConfigurationFile, supported explicit custom paths, the .github/PSModule.yml / SettingsPath exception, and the existing .github/vscode-extension.yml template interface remain governed by their owning producer or solution. No executable consumer migration is performed here.

Technical details

Current source: 3f48c8b391d8af9952b9d4e851e8c56afd36b03b on default-release-bump, compared with actual main 9453587dbf34e888d057848a867c48778c62b4e7. The remaining delivery contains four documentation pages, with 72 insertions and 51 deletions. The branch includes that main source and has no unresolved conflicts. Earlier ce9ca513, 105d53f, d9d35ab, and 99fd558 records are historical, not final-head review evidence.

Changed surface	Standards checked	Framework docs checked	Result
Release Management design	Documentation Model, Natural Language, Markdown	Effective defaults, keyed routing, inherited validation, stable authority	Aligned
Release Management spec	Specification/design separation, Natural Language, Markdown	Closed routing-key contract, applicability, owned decisions, required validation	Aligned
Release Management index	Documentation Model, generated navigation	Current spec/design descriptions	Aligned
VS Code framework design	Documentation Model, Natural Language, Markdown	Shared release resolver and configuration surface	Aligned
User-directed test-policy fix	Testing, PowerShell test discovery	Functional validation versus prose-edit assertions	Fixed in this PR

Test-policy correction: d9d35ab removes only the added ReleaseSettingsDocumentation.Tests.ps1 suite. Its five cases searched documentation strings rather than executing a supported runtime interface, contrary to the functional-testing policy now on main. All functional suites, assertions, required checks, linters, link validation, and build configuration are unchanged and match the accepted base. No replacement phrase, heading, or source-shape guard is added.

Concrete review corrections: the complete review 5743140913 on d9d35ab identified inherited stable-assignment and candidate-publication ambiguities. 99fd558 corrected both, with fix-linked resolved replies for inherited stable validation and candidate publication mode. The complete review 5743210606 confirmed those fixes and requested the existing fixed-key/inheritance guarantees in the normative spec. 3f48c8b adds those guarantees and has a fix-linked resolved reply. These clarify the existing intended routing constraints; they do not implement a reader or change the settings/input/runtime scope.

Final-head validation: all five required contexts succeed on 3f48c8b391d8af9952b9d4e851e8c56afd36b03b: Lint, Build, Test, and Links, plus Cross-repository links. The run identity was verified as a pull-request run for this exact source. Its Ubuntu Test job passes all 64 functional tests in six suites using pinned Pester 6.0.1, with none skipped. The site build and Markdown/static checks pass; the PR-only Publish job is skipped as intended. Local functional suites, Markdown lint, patch checks, relative links across 127 pages, and all seven cross-repository links also pass. No older green run is counted for this head.

Final complete review disposition: the explicitly requested round 5743289293 is COMMENTED on 3f48c8b391d8af9952b9d4e851e8c56afd36b03b, with no new inline comments, no requested changes, and no open issues. Its complete summary was read, not reduced to the script's successful exit code: it still says Needs a closer look and asks for human verification because this normative cross-document routing proposal has no compatible producer, executable resolver, or consumer migration delivered with it. That is the intentionally retained documentation-only boundary, not runtime validation or an approving review. The keyed/inherited-default runtime behavior remains unexecuted coverage. A complete paginated thread read-back confirms no unresolved threads. An independent reviewer must assess and accept the contract; the last-push approval gate remains unsatisfied and is not self-granted or bypassed.

Preserved canonical composition and holds: landed #209 supplied the complete PR-record, release-range-first, sufficient-upgrade-history, and no-PR-template-file contracts. Landed #233 supplied the single settings-name convention, supported custom-path boundary, and PSModule/VS Code exceptions. This branch retains those accepted sources while keeping its keyed-route proposal. No unmerged producer or documentation delivery is copied into the branch. Native prerequisite #166 is closed; #208 remains a separate overlapping delivery. If main advances again, reconcile the surviving branch against the actual landed source and repeat exact-head validation/review before readiness.

The older review 5723060562 also retained a generic human-assessment caution about default/skip paths. Nineteen anonymous written-contract cases were checked on that older source, not a runtime resolver; the decision table and ordering survived the reconciliations. That caution is not an approval or a governance waiver. The later Windows-path allegation in review 5728271684 was disproven by its exact-head Ubuntu run and received an evidence-linked resolved reply. The now-removed prose suite and older reviews do not establish final-head runtime coverage.

Task plan and convergence: the original default/override, label, framework, and conflict-reconciliation steps in #225 are complete. The user-directed author-side readiness revision is complete: prose-only assertions removed, functional validation retained, current-source PR record refreshed, concrete review findings corrected, and final-head CI/full automated review disposition recorded. Independent contract assessment and last-push approval remain external gates, not completed author work. The scoped convergence sweep covered release/default/filename issues: only #225 is closed by this delivery. #232 is the separate canonical filename Task; #203 remains the broader consumer-upgrade procedure/gate work. No additional closing links, producer migration, date-based versioning, or historical/fleet cleanup are included.

This repository's target route builds and deploys an unversioned documentation site. It does not publish a versioned immutable consumer artifact, so no artifact-publication baseline is invented and no Release decisions block or release:* label applies. The scoped main-to-candidate comparison above is implementation/reviewer evidence, not a fabricated release range.

Existing human/source/lineage/prerequisite holds are not waived. Agent merge remains maintenance-only with merge_pr=false, and GitHub auto-merge remains off. The PR target and existing draft state are unchanged. This fix authorizes no merge, enqueue, publication, package, live producer, label, pin, or governance mutation.

Related references

Resolves MSXOrg/docs#225
References MSXOrg/docs#209
References MSXOrg/docs#233
References MSXOrg/docs#208
References MSXOrg/docs#166

Copilot

Pull request overview

This PR updates the MSX documentation set to introduce a configurable repository-wide default semantic version bump (DefaultBump) for release automation, while keeping owned release:* labels as explicit overrides and updating prerelease semantics to reuse the resolved bump.

Changes:

Define DefaultBump (defaulting to patch) and the override / conflict rules in Release Management spec + design.
Update Ways of Working guidance (PR format, CD/release, branching/promotion, automation labels) to reflect “policy-first” bump selection and prerelease behavior.
Align the VS Code Extension Framework spec/design with the Release Management contract.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/docs/Ways-of-Working/PR-Format.md	Documents how `release:pre-release` interacts with `DefaultBump` and owned bump-label overrides.
src/docs/Ways-of-Working/Continuous-Delivery-And-Release.md	Updates CD/release “decision at the gate” language to reference resolved release policy and `DefaultBump`.
src/docs/Ways-of-Working/Branching-and-Merging.md	Updates promotion-model guidance to use the resolved policy / `DefaultBump` with explicit overrides.
src/docs/Ways-of-Working/Automation-Labels.md	Reframes label meanings around `DefaultBump` + owned label overrides and conflict handling.
src/docs/Coding-Standards/Natural-Language.md	Updates example language/error-message guidance to reflect conflicting owned bump labels and `DefaultBump`.
src/docs/Capabilities/vscode-extension-framework/spec.md	Updates framework requirements/success criteria to match policy-driven bump selection.
src/docs/Capabilities/vscode-extension-framework/design.md	Updates pipeline/design narrative to reference release policy and `DefaultBump` in version resolution.
src/docs/Capabilities/release-management/spec.md	Defines the normative `DefaultBump` rules, override precedence, prerelease behavior, and label conflict handling.
src/docs/Capabilities/release-management/index.md	Updates the section index descriptions to match the refreshed spec/design framing.
src/docs/Capabilities/release-management/design.md	Documents configuration surface and pipeline behavior for resolving `DefaultBump` + owned label overrides.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Copilot

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Copilot

🟢 Approval recommended

The documentation updates appear internally consistent across all touched pages and align with the stated DefaultBump/owned-label override/prerelease/skip contract.

Review details

Files reviewed: 10/10 changed files
Comments generated: 0 new
Review effort level: Lite

Copilot

🟢 Approval recommended

The changes are documentation-only and appear internally consistent with the new DefaultBump/ReleaseType contract, with only a minor wording nit noted.

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/docs/Capabilities/release-management/spec.md:3

The front-matter description repeats “driven” twice (“policy-driven … releases driven …”), which reads awkwardly in generated index tables and summaries. Consider rephrasing the second instance (and then regenerating the affected INDEX tables).

Files reviewed: 10/10 changed files
Comments generated: 0 new
Review effort level: Lite

Marius Storhaug (MariusStorhaug) · 2026-09-06T09:06:51Z

Coordination for #202: I am adding incremental consumer evidence and complete-note publication rules in PR Format and the release-management spec/design. This work leaves version selection, label names, DefaultBump, and ReleaseType ownership with this PR. The release-impact record reports the effective resolver decision and its source, so it remains compatible with either merge order. I will reference this PR and will not edit its branch or description.

Marius Storhaug (MariusStorhaug) · 2026-09-06T11:10:39Z

Coordination from #204: the user confirmed that a release level can come from an explicit owned bump label or a repository-configured DefaultBump, but chose to fail when both are absent. The missing-decision error must also fail a required pre-merge CI check. This differs from the implicit patch fallback proposed here. I am aligning the release evidence contract and its dependent guidance in #204 with that confirmed rule, reusing the DefaultBump setting name. I am not changing this branch, its ReleaseType redesign, or its label rename; the default-fallback portion here needs reconciliation before merge to avoid restoring a conflicting rule.

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>

Copilot

🟡 Changes recommended

The critical documentation test suite uses backslashes that are treated literally on Ubuntu, causing every case to fail before validating filenames.

1 open issue

Use platform-neutral path separators in Document values · New

_{Review effort: Lite}

Solution-owned settings use the conventional filename `<name>.settings.yml`. The release solution uses `.github/release.settings.yml`; module repositories retain `.github/PSModule.yml` through `SettingsPath`, including module release settings. The documentation-content test file and CI documentation-index drift gate are removed. Functional tooling tests, linting, link validation, and site builds remain; no module migration or runtime loader is implemented here.  ## Removed: Tests that lock documentation content `tests/PR-Format.Tests.ps1` is deleted in full at the user's request, including its PR-format, filename, naming, and repository-policy assertions. No replacement tests of checked-in documentation or workflow content are added. The Naming standard no longer claims test coverage for its prose. The follow-up audit covers all six remaining suites and both workflows. The remaining suites exercise scripts on temporary fixtures, PowerShell engine behavior, and plugin metadata/schema validity. They do not lock the actual documentation's wording or assert the actual workflows' contents. The user explicitly chose to retain these functional tool tests, together with linting, link validation, and site builds. <details> <summary>Technical details</summary> The entire 329-line documentation suite is absent, including all 39 assertions it contained. Historical audit comments and earlier test totals describe preceding iterations, not tests present in this candidate. No replacement prose or workflow-content tests were introduced. The complete scoped comparison is accepted main `aa9b5cecc69f4cbe6aa04a5dd70ff9cdadeeac3d` to candidate `8daf026a14036dee04786d371883e8871b5ec2f4`. The [latest bounded change](3d7c58e...8daf026) removes drift enforcement without changing any test suite or index-generator logic. | Changed surface | Standards checked | Framework or domain docs checked | Result | | --- | --- | --- | --- | | `tests/PR-Format.Tests.ps1` (deleted) | User-directed removal and test discovery | Existing Pester suite discovery | Aligned | | Naming enforcement statement | Naming, Natural Language, Markdown | None (no framework-specific docs) | Aligned | All 64 tests in the six retained functional suites pass on the current head, verified from the completed CI job. The six index-tool fixture cases also pass locally; these exercise optional diagnostics, regeneration, and line endings on temporary files, not drift in this repository's actual docs. No suite is rewritten to inspect the checked-in documentation or workflows. The [fresh exact-head review](#233 (review)) approves `8daf026a14036dee04786d371883e8871b5ec2f4` with zero new inline comments. All five required checks pass: [Lint](https://github.com/MSXOrg/docs/actions/runs/41497449037/job/125456000472), [Build](https://github.com/MSXOrg/docs/actions/runs/41497449037/job/125456000462), [Links](https://github.com/MSXOrg/docs/actions/runs/41497449037/job/125456000312), [Test](https://github.com/MSXOrg/docs/actions/runs/41497449037/job/125455999512), and [Cross-repository links](https://github.com/MSXOrg/docs/actions/runs/41497448823/job/125455993357). The earlier consistency thread remains resolved. Publishing is intentionally skipped for this PR. </details> <details> <summary>Related references</summary> - Resolves #232 </details> ## New: Solution-owned settings filenames identify their owner Use the owning solution's name for its conventional settings filename. The Naming standard defines this once; repository, YAML, and release guidance link to it. The rule does not rename tool-mandated manifests, lockfiles, workflow filenames, or arbitrary YAML files, and it does not impose one directory on every solution. Supported explicit custom paths remain governed by each reader's existing input contract. Module repositories keep `.github/PSModule.yml` through `SettingsPath`, including module release settings. The PSModule initiative records this supported exception and links to the framework's actual input and settings references. No module filename migration, second release settings file, or caller-input change is required here. The VS Code framework design retains `.github/vscode-extension.yml` as an explicit supported naming exception. Its settings keys and interface are unchanged; a filename change requires a verified reader and separate template/caller migration. <details> <summary>Technical details</summary> | Changed surface | Standards checked | Framework or domain docs checked | Result | | --- | --- | --- | --- | | `src/docs/Coding-Standards/Naming.md` | Naming, Natural Language, Markdown, standard template | None (no framework-specific docs) | Aligned | | `src/docs/Coding-Standards/YAML.md` | YAML, Naming, Markdown | None (no framework-specific docs) | Aligned | | `src/docs/Ways-of-Working/Repository-Standard.md` | Repository Standard, Naming, Markdown | Repository Governance required-files model | Aligned | | `src/docs/Initiatives/PSModule.md` | Documentation Model, Natural Language, Markdown | Process-PSModule workflow inputs and settings | Aligned | `Naming.md#solution-settings-files` owns the rule; `PSModule.md#module-settings` and the VS Code configuration surface own the supported exceptions. Related guidance links to those owners rather than defining another rule. The directly related obsolete framework overview link is corrected to its actual canonical site route. The module default was verified from Process-PSModule source `105e4dcefe1946782066aa50a5c7d3658319895a` and the [published workflow-input reference](https://psmodule.io/Process-PSModule/reference/workflow-inputs/). The [settings reference](https://psmodule.io/Process-PSModule/reference/settings/) owns module keys and defaults. Neither the workflow, its input, schema, nor enriched runtime settings object changes here. The earlier VS Code consistency finding remains addressed by its owning-guide exception, independently of the deleted assertion. The scoped issue-convergence search finds no additional complete ask satisfied by this naming slice; broader default-bump/keyed-route and lifecycle work stays separate. </details> ## Changed: Release settings use the release solution's canonical filename The optional release-solution file is `.github/release.settings.yml`, replacing the documented `release.config.yml` convention. Its `.github` location, settings keys, schema, defaults, precedence, omission behavior, applicability, and required decision validation are unchanged. All 17 original current-guidance substitutions remain. This repository has no settings file or runtime loader to rename. The former `.github/auto-release.yml` is migration evidence for the separately owned Release-GHRepository reader change, not a current alternative convention. `ConfigurationFile` remains the public input, distinct from its conventional default filename. This documentation PR does not deliver or release that reader. Consumers verify their producer revision and its migration record before adopting a changed default; module release settings remain under the supported `PSModule.yml` interface. <details> <summary>Technical details</summary> | Changed surface | Standards checked | Framework or domain docs checked | Result | | --- | --- | --- | --- | | Release Management spec and design | Documentation Model, Naming, Markdown | Applicability, defaults, overrides, and decision validation | Aligned | | VS Code framework design | Documentation Model, Naming, Markdown | Existing extension interface and release configuration | Aligned | | Automation Labels and PR Format | Natural Language, Markdown, owning standards | Release-route applicability and complete-record ownership | Aligned | The accepted release-range-first analysis, complete description example with one summary boundary, conditional release/default rules, Task/Bug planning, and repository-owned no-PR-template policy are preserved without tests of their prose. Runtime default/migration work belongs to PSModule/Release-GHRepository#109, not this source. No module file, loader, public input, Build/metadata/runtime schema, publisher, pin, permission, ruleset, marketplace, or consumer fleet change is included. </details> <details> <summary>Related references</summary> - References PSModule/Release-GHRepository#109 - References #196 - References #208 - References #209 </details> ## Changed: Documentation builds regenerate indexes without a drift gate CI generates documentation indexes before building the site instead of rejecting an out-of-date generated table. A documentation edit no longer needs to satisfy an index-drift gate. The generator updates only the build checkout; this change adds no bot commit or source synchronization. Optional local `-Check` diagnostics and functional tests of the generator remain available. Linting, link validation, and site builds still run. The contribution guide and script help describe this distinction; no tests inspect the actual workflow to enforce its contents. <details> <summary>Technical details</summary> | Changed surface | Standards checked | Framework or domain docs checked | Result | | --- | --- | --- | --- | | `.github/workflows/Docs.yml` | GitHub Actions, YAML | Existing documentation build pipeline | Aligned | | `.github/scripts/Update-DocumentationIndex.ps1` (help only) | PowerShell, Natural Language | Existing index generator interface | Aligned | | `.github/CONTRIBUTING.md` | Markdown, contribution guidance | Documentation authoring and build flow | Aligned | The index step runs normal generation with no `-Check` flag. The index-generator implementation and all functional test suites are unchanged. The local generation-then-build path succeeds with repository-pinned Zensical 0.0.59; the changed contribution guidance is lint-clean and the scoped diff has no whitespace errors. The exact-head CI Build job also successfully executes `Generate documentation indexes` followed by the site build. Temporary build environments and output are cleaned without changing shared dependencies. The Task records the audit, the user's selected boundary, and the completed verification. Its implementation and review gates are complete; the Task remains open for reviewed integration. This PR remains draft; native maintenance has `merge_pr=false`, GitHub auto-merge is off, and no live publication or merge is authorized. A later main change requires a refreshed comparison and exact-head validation. </details>

Co-authored-by: MariusStorhaug <17722253+MariusStorhaug@users.noreply.github.com>

Copilot

🟡 Changes recommended

The change still has two active documentation issues: it must clarify that the inherited stable mapping participates in duplicate-assignment validation and that release candidates remain prerelease publications rather than becoming a third release type.

2 open issues

1 resolved since last review

Use platform-neutral path separators in Document values

_{Review effort: Lite}

Copilot

🟡 Changes recommended

The specification still needs to explicitly reject unknown ReleaseType keys and validate the inherited Stable route after resolution, leaving room for implementations to accept invalid configurations.

1 open issue

Specify fixed route keys and validate duplicates after inheritance · New

2 resolved since last review

_{Review effort: Lite}

Copilot

🔵 Needs a closer look

Human verification is needed because the PR changes a normative cross-document release-routing contract without a compatible producer, executable resolver, or consumer migration, leaving keyed protocol and inherited-default semantics unvalidated.

No open issues 🎉

1 resolved since last review

Specify fixed route keys and validate duplicates after inheritance

_{Review effort: Lite}

…rds (#208) Release guidance defines durable intent, phase-aware recovery, complete source-bound consumer records, and settings-driven decisions. It preserves the accepted keyed release routing, `.github/release.settings.yml` convention, solution-specific path exceptions, and release-range-first PR records while defining the lifecycle contract. This delivery changes documentation, not a producer runtime. It creates no settings file, legacy filename fallback, versioned release, live caller change, consumer installation, or governance change. Existing immutable-version consumers need no action. Implementation owners verify the invoked producer's actual interface and conformance before adopting any documented setting or lifecycle control.  ## New: Owned moving-tag recovery keeps one explicit trust boundary Use the procedure only for an intentionally moved MSX-owned major or minor alias that the consumer's artifact-specific pinning standard permits. Ownership alone does not authorize mutable references: the owned Action/reusable-workflow major-tag exception does not permit minor aliases. Exact version tags are immutable; their movement is an integrity incident, not routine recovery. SHA- or exact-version-pinned consumers require no action for this documentation delivery. If a trusted, permitted alias is stale, verify the intended remote and back up needed local-only tags outside `refs/tags/` before refreshing. Renaming a tag within that namespace does not preserve it from pruning. A verified `git bundle create owned-tags-backup.bundle --tags` followed by `git bundle verify owned-tags-backup.bundle` can retain original tag objects and reachable history; keep the backup private and outside checked-in paths. The whole-namespace refresh is `git fetch --tags --force --prune --prune-tags origin`. Force replaces local tag values with that explicitly selected remote's values, and tag pruning removes local tags absent there. Accept that complete scope deliberately, review the output, and do not normalize an altered exact version tag. Naming `origin` prevents another upstream from choosing the source of this operation. For ongoing controlled movement, inspect `remote.origin.fetch` and add `+refs/tags/*:refs/tags/*` once only when absent. Set clone-local `remote.origin.prune` and `remote.origin.pruneTags` to true, not clone-wide pruning defaults that can affect other remotes. Fetch explicitly from origin. Compare the local alias's tag-object hash with `git ls-remote --refs origin refs/tags/<alias>`, then resolve its exact release and immutable source before use. A stale or unverifiable result blocks use. This is a general conditional operating procedure, not version-specific migration history. No actual consumer tag, configuration, or history is changed by this PR. <details> <summary>Technical details</summary> | Changed surface | Standards checked | Framework docs checked | Result | | --- | --- | --- | --- | | Accept Moved Release Tags guide | Guide structure, Natural Language, Markdown | Owned-alias trust, tag pruning, immutable-source verification | Aligned | | GitHub Actions owned-tag link | Owning coding standard, Markdown | Allowed major-tag exception and consumer recovery | Aligned | | Capability indexes and navigation | Front matter, generated indexes | Documentation Model | Aligned | The earlier isolated anonymous Git experiment reproduced implicit upstream selection and pruning of a renamed local-only tag. Complete 40-character identities confirmed that an independent bundle retains the pruned ref, explicit origin restores the intended alias, and origin-scoped pruning does not remove origin-owned tags when another remote is fetched. The verification repositories contained only empty commits and test tags; no repository tags or releases were changed. The accepted-main reconciliation leaves that operating procedure intact. </details> ## Changed: Durable lifecycle and native targets require verified conformance The numbered specification retains fixed approved source and notes, permanent reservations after a successful build or external visibility, one retained artifact through verification and publication, destination progress, phase-aware retries, retirement and withdrawal, stable/candidate authority, current discovery, optional aliases, and independent post-completion announcements. Version computation uses permanent reservations and the reviewed aggregate minimum bump. Consumer record coverage separately starts from the actual latest successful artifact publication for each product, target, and channel. Authors resolve publication coverage before writing a release-bound record: verify the actual artifact and publication receipt, its immutable source provenance, and the exact candidate; compare those source trees and retain the scoped PR-base comparison separately. Include earlier merged, skipped, direct, and otherwise unshipped changes in the applicable consumer range. Successful Gallery publication advances module note coverage even if later GitHub completion fails. Completing that older GitHub record preserves its original snapshot and does not make its already-published module changes new again. These authoring baselines do not change aggregate approval, version reservations, or completed-state discovery. Consumers compose every applicable source-bound record after their actual consumed baseline through the target in release order. Notes retain prerequisites, ordering, required intermediate operations, verification, or an explicit no-action result with its compatibility basis. Reading a record does not itself require installing that version. PRs and diffs provide optional depth; resource docs describe supported target-state usage, not another migration history. Missing publication provenance or required instructions blocks the affected publication rather than becoming a no-action result. Implementation owners verify the invoked immutable producer and actual controls before relying on them. A requirement or configuration example does not prove that an older runtime implements recovery, manual release creation, candidate routing, alias reconciliation, or announcement journaling. Exact producer adoption actions belong in its own PR/release record. Existing operators retain their released interface; an incomplete release is not repaired by rebuilding under an exposed version or re-resolving changed metadata. This documentation delivers no broad lifecycle engine, history backfill, downstream propagation, or Discord sender. A duplicate or phase-aware retry reuses its original logical intent, approved source, frozen version, and retained artifact. A separately approved corrective release has a distinct immutable approved request identity, even when reviewed source is unchanged; it receives a new intent/version and preserves its relationship to the earlier attempt. Do not reuse a retry key to suppress that newly approved request, supersede an exposed intent, or reuse a reserved version. An affected product integration template requires its repository, compatible immutable commit, producer-source compatibility evidence, and delivered work or a justified no-change result. This docs-only delivery changes no producer or integration template, so concrete runtime/template adoption values do not apply here. Native publishing identities remain explicit. A PowerShell prerelease uses numeric `ModuleVersion` plus `PrivateData.PSData.Prerelease`: canonical `2.5.0-alpha` is core `2.5.0` and label `alpha`, not prerelease text in `ModuleVersion`. Validate the selected client's suffix syntax and reject or explicitly map unsupported forms without collisions or lost ordering. Native bounded ranges, where supported, can express major/minor update policies without aliases. A field without a native range resolver can retain immutable patch updates when permitted bounded selection exists outside that field. A SHA-pinned Action or reusable workflow does not need or acquire permission to retain a minor alias for that policy. Git/container reference fields do not evaluate range-like strings. Require a permitted matching alias only when no other permitted resolver supplies the bound; if none can express it, fail without widening to latest or another boundary. Retain the exact version, full SHA, or digest required by the artifact's pinning standard and trust policy. The owning VS Code framework declares stable/prerelease native mappings together before enabling Marketplace publication. Numeric versions and a native channel do not imply direct conversion from every canonical SemVer. An odd-minor convention requires reserved stable space and proven series/counter allocation. Unsupported mappings or collisions fail before publication; an enabled required destination is not silently skipped. This PR specifies the conformance boundary, not a new allocator or Marketplace publisher. <details> <summary>Technical details</summary> | Changed surface | Standards checked | Framework docs checked | Result | | --- | --- | --- | --- | | Release Management spec/design and index | Specification/design separation, Natural Language, Markdown | Durable intent, aggregate minima, distinct publication/version baselines, complete records, conformance | Aligned | | Publishing-target contract | Owning target requirements, Markdown | Two-field module mapping, native coordinates, immutable bounded selection | Aligned | | Parent/capability indexes and navigation | Generated-index conventions | Documentation Model | Aligned | The earlier native PowerShell manifest verification established numeric `ModuleVersion` and separate prerelease data; prerelease text does not parse as `System.Version`. Official Git, PowerShell, and Marketplace documentation grounded the mapping and trust corrections. No runtime publication or invented allocator is claimed. Written consumer-policy cases cover omitted policy retaining the strongest immutable reference, native minor bounds without aliases, permitted SHA-pinned patch selection without changing major/minor or retaining a minor alias, the owned-major exception not authorizing minor aliases, unsupported resolution failing without widening, immutable external latest selection, opaque range strings, and patch-only pre-1.0 selection staying inside its chosen minor. These are written conformance cases, not evidence of a delivered resolver runtime. **Current immutable candidate:** `a37884419c6c5ec4da56222be27238ee192b4cd1`. **Scoped implementation base:** accepted main `bdb581f68fddd84bc129394a94388671d1d14356`, containing delivered #209, #235, #233, and #196. The complete base-to-head comparison contains eight existing lifecycle, target, guide, and navigation files. Current canonical format, naming, testing, solution-specific exceptions, repository policy, CI configuration, and VS Code framework guidance match accepted main without an additional PR delta. This repository's Docs route is documentation validation and Pages deployment, not a versioned Release Management artifact route; no release-publication baseline or `Release decisions` block is fabricated for this PR. Local validation of the composed candidate passes all **64 functional/tooling Pester tests in six suites**, normal index regeneration, relative links across 128 pages, seven cross-repository links, exact-file Markdown lint across eight relevant pages, patch checks, and a clean build with manifest-pinned Zensical **0.0.59**. The unavailable pinned build version was restored only in an isolated temporary environment, which was removed afterward. No dependency manifest was changed. The accepted testing policy is preserved; no prose-drift tests were added or restored. The inherited-routing scenario documents the requirement but does not claim an implemented resolver test. **New-head required CI was running at handoff:** [Lint](https://github.com/MSXOrg/docs/actions/runs/41675815774/job/126055996866), [Links](https://github.com/MSXOrg/docs/actions/runs/41675815774/job/126055996479), [Test](https://github.com/MSXOrg/docs/actions/runs/41675815774/job/126055996962), [Build](https://github.com/MSXOrg/docs/actions/runs/41675815774/job/126055996918), and [Cross-repository links](https://github.com/MSXOrg/docs/actions/runs/41675815839/job/126055998868). All five checks identify `a37884419c6c5ec4da56222be27238ee192b4cd1`. Earlier green checks are not represented as a result for this new head; current status is shown by the PR checks. The previous full automated review [5728246486](#208 (review)) approved `f68927e94a31520c4db482aa8f2359cc999b80aa` with no active concerns. It is an earlier checkpoint, not a review of this candidate. This tick began with all review threads resolved and no changes-requested review, but with approval blocked. No reviewer was requested or approval manufactured during conflict maintenance. The exact resolution review preserves lifecycle authority, reservations, immutable artifact recovery, source-bound records, and consumer policy while integrating the accepted keyed-routing rules. The closing Task's original implementation-plan evidence remains in the prior delivery history. This maintenance resolves the accepted-main composition gate and leaves new-head required CI and GitHub's remaining approval/protection requirements as acceptance gates. Producer implementation, consumer execution, date strategies, historical correction, and live governance remain outside this Task. No PR merge, merge enqueue, retarget, release, or artifact promotion was performed; automatic landing remains off. </details> <details> <summary>Related references</summary> - Resolves [#227](#227) - References [#166](#166) - References [#209](#209) </details> ## Changed: Keyed routing and settings retain their accepted boundaries The lifecycle retains `ReleaseType.Stable`, `ReleaseType.Prerelease`, and `ReleaseType.ReleaseCandidate`, each with at most one branch. The stable route inherits the default branch when the routing object or stable key is omitted. Validate the effective mapping after inheritance: unknown keys and duplicate branch assignments fail, including a candidate or prerelease route assigned to the inherited stable branch. Prerelease and release-candidate routes publish only their assigned prerelease series, not stable releases or stable discovery/aliases. Configured branches retain their push-driven series, and open PRs retain `release:prerelease` using one explicit owned bump label or the valid effective `DefaultBump`. Candidate versions retain `rc` and increasing counters; promotion to stable uses the stable version resolver without carrying either prerelease counter over. An unreviewed direct push to the stable line still validates without publishing. The release solution's optional path remains `.github/release.settings.yml` under the accepted Naming standard. The convention does not implement a reader, rename a public input, require a shared directory, or restrict otherwise supported explicit custom paths. Verify the immutable producer revision's declared settings input and default before adoption. `ConfigurationFile`, where exposed, remains that producer's settings-path input. PSModule retains `.github/PSModule.yml` through `SettingsPath`, including module release settings; module repositories do not need a separate release-solution settings file. The VS Code template retains `.github/vscode-extension.yml` and its settings keys. Both owning exceptions are preserved from accepted main. This documentation does not authorize a reader, template, or live-caller migration, and creates no legacy fallback. `DefaultBump` still accepts `patch`, `minor`, or `major`, with shared `patch` as the documented default. Repository settings and explicitly supplied supported caller overrides resolve before one owned bump-label override. Omitted caller inputs preserve repository policy; invalid supplied settings and conflicting signals fail even when another input supplies a valid level. A compatible effective default needs no per-PR bump label. Skip and out-of-scope work validate without publication. The owned set remains exactly `release:patch`, `release:minor`, `release:major`, `release:prerelease`, and `release:skip`. Prerelease uses the resolved bump; skip combines with no other signal. Candidate and announcement behavior uses supported settings rather than extra labels. A route without versioned release behavior carries neither release metadata nor any release label. Authors retain the finalized PR record, release-range-first procedure, complete source-bound notes, and scoped supporting evidence already delivered on main. The no-PR-template-file policy remains in Repository Standard and its owning governance guidance, not PR Format. Product integration template evidence and genuine repository-specific contribution instructions remain separate and intact. Existing runtime consumers do not rename live files or install software because this guidance changed. Producer support and any required adoption actions must be verified and delivered by the relevant implementation owner. <details> <summary>Technical details</summary> | Changed surface | Standards checked | Framework docs checked | Result | | --- | --- | --- | --- | | Lifecycle routing requirements and design | Specification/design separation, Natural Language, Markdown | Accepted fixed routing keys, inherited defaults, branch collisions, prerelease sources and stable-only authority | Aligned | | Lifecycle settings and configuration sections | Natural Language, Markdown, Naming | Optional release-solution file, verified reader/input boundary, unchanged defaults and typed overrides | Aligned | | Accepted-base composition | Current PR Format, Testing, Repository Standard | Release-range-first records, no-template ownership, preserved PSModule and VS Code exceptions | Aligned | Conflict maintenance merges only accepted main `bdb581f68fddd84bc129394a94388671d1d14356` into the existing branch. It resolves conflicts in release spec/design/index without importing an unmerged delivery or restoring the older `release-branches` schema. The lifecycle's artifact, aggregate-approval, recovery, discovery, announcement, version-reservation, settings-precedence, and optional-file contracts remain intact. Accepted keyed-routing requirements are expressed within the existing numbered specification and design; the inherited-default collision scenario makes the effective-mapping rule explicit. Shared canonical pages and the VS Code framework match accepted main exactly. The #233 and #196 sequential-composition gates are resolved against their delivered merges, not their superseded development candidates. No other branch, historical record, live label, consumer pin, governance setting, or producer runtime was changed. New-head CI and remaining GitHub acceptance gates are still required; Agent merge maintenance does not authorize automatic landing. </details> <details> <summary>Related references</summary> - References [#196](#196) - References [#233](#233) - References [#235](#235) </details> --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Epic and PBI authors describe the consumer's need, motivation, expectation, and observable behavior instead of prescribing an implementation. Task and Bug authors retain technical decisions and test-first delivery plans. Completion verifies current design and documentation, updating affected content and recording evidence when it already matches the delivered result. This changes guidance, not repository-inventory functionality, existing issue bodies, community files, or release automation. No new BDD tool, plugin reinstall, or configuration change is required.  ## Changed: Consumer expectations survive planning and completion When authoring or deliberately refining an Epic or PBI, identify the consumer and motivation, then state observable acceptance examples using Given / When / Then or an equally clear scenario. Keep architecture choices, component inventories, file/function lists, and implementation checklists in the current design and Task/Bug delivery leaves. The issue skill and agent instruction route still reach one canonical issue-planning rule; they do not acquire a duplicate BDD process. Completion verifies relevant current specifications, designs, documentation, examples, links, and instruction routes against delivered behavior. Update the owning artifacts where the change requires it. When an artifact already describes the result correctly, link it and record why no update is needed rather than editing it to satisfy a checkbox. Missing required documentation remains unfinished work. Native children still own aggregate progress, native dependencies still gate genuine prerequisites, and a delivery PR cannot close a PBI or Epic. | Issue altitude | Representative expectation or plan | | --- | --- | | Epic | Given maintainers assess fleet health across organizations, every repository in the agreed scope is accounted for and coverage gaps are explicit before they act. | | PBI | Given a caller can access 137 repositories, an unlimited inventory returns all 137 exactly once; unreadable coverage is not presented as a complete success. | | Task/Bug | Keep local consumer context, repository paths, implementation/root-cause decisions, and executable verification-before-implementation plans in the delivery leaf. | <details> <summary>Technical details</summary> The [immutable delivery head](1c8f98c) contains three ordinary commits on a main-based topic branch. The complete diff changes 19 documentation pages and no plugin, workflow configuration, community file, legal/ownership file, or release record. The existing single issue-index skill pointer is unchanged, so the plugin version is not bumped. **Implementation-plan progress:** all five #228 steps are complete: current-guidance comparison, representative scenarios and leaf counterexamples, canonical altitude/completion ownership, affected routes, and existing documentation checks plus complete-diff/summary review. The Task remains open until its reviewed PR is merged. **Validation and review:** 64 existing Pester tests and 10 focused session checks pass. The focused checks detected the aggregate-authoring/completion contradictions before the edits and the missing README/agent routes before their correction. Generated indexes are current; documentation links resolve across 127 scanned files; all seven cross-repository links resolve; Markdown lint passes for all 19 changed pages; the actual Zensical site builds with no reported issues. Rendered HTML contains the new anchors and three Gherkin scenarios. All five live required checks—Build, Links, Test, Cross-repository links, and Lint—are successful at the immutable head. The explicitly requested Copilot round approved that exact head with zero new inline comments and no open review issues; complete diff, summary, and supporting evidence have been self-reviewed. No auto-merge is enabled. **Standards and framework alignment:** | Changed surface | Standards checked | Framework/domain documentation | Result | | --- | --- | --- | --- | | Issues/Process/Planning | Consumer altitude, test-first delivery, native decomposition | Documentation Model and Spec-Driven Development | Fixed in this PR | | Issues/Process/Format and Lifecycle | Body ownership, audit trail, type-specific readiness and closure | Issue Planning and Definition of Ready and Done | Fixed in this PR | | Issues/Process/index and Issues/index | Generated navigation, thin-pointer discovery | Documentation Model and existing issue skill | Fixed in this PR | | Epic and PBI types | Consumer context/scenarios, aggregate acceptance | Issue Planning and native hierarchy/relationships | Fixed in this PR | | Task and Bug types | Consumer context, technical decisions, test-first/regression plans | Issue Planning and completion evidence | Aligned; technical plans preserved | | Definition of Ready and Done | Type-specific gates and combined-outcome evidence | Documentation Model | Fixed in this PR | | Documentation Model | Artifact ownership and evergreen evidence | Spec-Driven Development | Fixed in this PR | | Coding-Standards/Documentation and README-Driven Context | Current README evidence without forced edits | Completion evidence and existing repository README | Fixed in this PR | | Workflow and Define | Correct issue altitude and delivery-leaf handoff | Issue Planning and native relationships | Fixed in this PR | | Implement and Review | Executable leaf plans and documentation verification | Completion evidence and Contribution Workflow | Fixed in this PR | | Spec-Driven Development Templates | Durable artifact templates, not issue plans | Issue Planning and completion evidence | Fixed in this PR | | Agent Interaction | Intent/implementation separation without removing leaf plans | Canonical issue planning and existing agentic-development spec/design | Fixed in this PR | | All changed Markdown | Markdown, Natural Language, front matter, index/link/site checks | Documentation Model | Aligned | The existing repository README and thin client/skill routes remain correct for this change and are verified rather than churned. Spec-Driven Development already owns implementation-free durable requirements and technical designs; no second specification or BDD skill is added. **Composition and ownership:** the release owner handed off the shared guidance pages. Read-only three-way compositions against complete #209 at `27ffab8ad89cf41147dc25ba2f6bd300b01b938f`, #196 at `e2e4b7d428badfce35e6511afd6aaedb77280613`, and #208 at `9f92fa1ad8f8f4d56e79f52a40acee09a3bdbad4` all succeed. Each composition preserves exactly the same 19 changed paths and added/removed guidance lines; the complete PR Format scaffold remains byte-identical to its release candidate. Composed trees are `435eb4220addb34c0c308318054cf48e09085507`, `40456e7f0d04707125ecc28e7fa6a0f045515858`, and `dc6888519fe271b0e36fce6e22b5561f4d6a17fb`, respectively. No release changes are copied into this PR. The agreed human landing order is #209, #196, #208, this PR, then #229. Remaining branches need reconciliation and repeated CI/full review when main advances. Complete release-record/scaffold/conditional-decision and Task/Bug plan-progress contracts are preserved. No merge, retarget, native-dependency edit, or auto-merge action is performed. **Issue convergence:** searches scoped to Epic/PBI, issue planning, and community/contribution identify #96, #154, and #229 as related but not fully delivered. #96 asks for broader removal of technical issue plans, contrary to this clarified Epic/PBI-only scope; #154 adds a separate premise-verification procedure; community inheritance stays in #229. Only #228 is closed by this PR; historical issues are not rewritten. **External intake follow-up:** the Project will give separate narrow delivery surfaces to the inherited [MSXOrg/.github Feature form](https://github.com/MSXOrg/.github/blob/main/.github/ISSUE_TEMPLATE/10-feature.yml) and [PSModule/.github Feature form](https://github.com/PSModule/.github/blob/main/.github/ISSUE_TEMPLATE/10-feature.yml). Their descriptions should ask for consumer need, motivation, and observable scenarios and link canonical issue planning and native-type routing instead of soliciting implementation framing. These source-owned intake forms are not copied or edited here; Bug forms, Task/Bug technical plans, and unrelated YAML/CI policy are preserved. #229 will use a separate coordinator-created issue session; this tracked workspace and PR remain scoped to #228. The main documentation route builds and publishes the Zensical site; its two workflows do not invoke Release Management. Release-decision blocks and all `release:*` labels are therefore absent. The title/description follows the complete handed-off #209 audience-first scaffold without changing that PR. </details> <details> <summary>Related references</summary> - Resolves #228 - Followed by #229 - References #96 - References #154 - References #209 - References #196 - References #208 </details>

Every initiative must provide `.github/CONTRIBUTING.md` in its public `.github` community repository, even if the file is blank. Ordinary repositories inherit that shared guidance and keep a local contribution guide only for genuine repository-specific instructions or a documented exception. This corrects the standards, not repository files across the fleet. Initiative maintainers must ensure the central source file exists; blank content is allowed. Consumers do not need generic local copies. This repository's build, Pester, index-generation, and link-check instructions remain intact.  ## Fixed: Required initiative sources do not require local consumer copies Organization Standard now requires a contribution source in every initiative community repository. Repository Standard, the governance source matrix, README/readiness guidance, and agent specification/design/router examples consistently distinguish that source requirement from a conditional consumer-local guide. Missing source files are corrected in the initiative community repository, not by manufacturing consumer placeholders. When a source guide is blank, the shared Contribution Workflow still defines the process and agent routes also link there. Source validation checks file presence, not a nonempty body. Local guides describe repository-specific steps and link back to shared guidance; such steps are not automatically policy exceptions. Other community defaults and the landed prohibition on PR-template files retain their separate rules. No files are deleted, copied, or distributed in other repositories. Legal terms, CODEOWNERS, actual agent/client routes, live governance settings, labels, permissions, non-community configuration, and released framework behavior are unchanged. The central Feature intake-form follow-ups remain separate. <details> <summary>Technical details</summary> **Delivered head:** `cdf10a47479406c80fbca742ed13b954cde2a095` on `community-guidance-inheritance`. The branch contains actual main at `8c9d9353eb154d6072b3ed1d825a78d58a4665d3`. Its complete diff is eleven modified documentation pages, 127 added lines and 62 removed lines. The tracked worktree is clean. The main refresh is separate merge commit `daa9dec0379eb1a04b6d65c518ff7a2dd62ba12d`. The required-even-blank source rule is the small commit `cdf10a47479406c80fbca742ed13b954cde2a095`. No history rewrite or PR retargeting was used. **User-directed clarification:** "All initiatives should supply one, even if it's blank. The requirement is that initiatives have this." The central rule is therefore MUST/Required, not SHOULD/Recommended or optional. The ordinary-repository local-guide rule remains conditional. **Source verification:** live GitHub API reads confirm public `MSXOrg/.github` and `PSModule/.github` each contain `.github/CONTRIBUTING.md`, at source blobs `9ff70648eb1cc0a455f8362b5d1b81ba538b7f38` and `de229578ad918895b63b14331fb6eed7e6cc5711`. The previously verified Distributor example established a consumer without a local contribution guide whose community profile resolves to the organization source. Blank content is explicitly permitted by the clarified contract; no live blank-file inheritance experiment is claimed. **Actual landed composition:** all agreed prerequisites are merged: #209 at `aa9b5cecc69f4cbe6aa04a5dd70ff9cdadeeac3d`, #196 at `bdb581f68fddd84bc129394a94388671d1d14356`, #208 at `adf98af340639f46f0a7aecf34720d6ef26f515b`, and #230 at `8c9d9353eb154d6072b3ed1d825a78d58a4665d3`. The real current main was integrated cleanly. The earlier prospective-only correspondence and unlanded-prerequisite blockers are superseded. Current main's actual contribution guide, PR Format, and Task/Bug documents are unchanged by this PR. Repository-specific commands, the no-PR-template-file policy, actual-record/release-range ownership, and #228's current-documentation/no-unnecessary-churn evidence remain intact. No obsolete scaffold requirement is restored. **Validation:** all 64 current native Pester tests pass, with zero failed or skipped. The native index generator, relative-link checker (128 documentation files), cross-repository checker (seven links in 132 Markdown files), all eleven changed pages' Markdown lint, and the actual Zensical build pass. All five required GitHub checks pass at `cdf10a47479406c80fbca742ed13b954cde2a095`. The explicitly requested automated review round is clean on that head (`COMMENTED`, zero new inline comments), and no review thread remains unresolved. The complete scoped diff and source contracts were self-reviewed. No source-string or prose-snapshot tests were added; current validation uses functional suites and real documentation tooling. **Standards and framework alignment:** | Changed surface | Standards checked | Framework/domain docs checked | Result | | --- | --- | --- | --- | | Repository and Organization Standards (2 pages) | Documentation Model, Markdown, Natural Language | Required initiative source, conditional consumer-local rule, blank versus missing boundary | Fixed in this PR | | Repository Governance spec, design, and types (3 pages) | Specification/design ownership | Required source-file presence and effective consumer guidance | Fixed in this PR | | README-Driven Context and Ready/Done (2 pages) | README ownership, readiness, no-unnecessary-churn evidence | Conditional contribution rule and landed #230 evidence gate | Fixed in this PR | | Agentic Development spec, design, and router template (3 pages) | Thin pointers, real destinations, canonical process | Required initiative contribution source; blank-guide process link; missing-source reporting | Fixed in this PR | | Maintain Workflow Guidance (1 page) | Link-not-inline workflow maintenance | Agentic Development pointer model | Fixed in this PR | **Task progress and convergence:** all Task #229 implementation steps are complete, including the user-directed mandatory source clarification and final validation. The native Task remains open until merge; technical planning and native dependency edges are unchanged. The scoped convergence sweep covered `community` and `contribution`: #228 is separately delivered by #230, and #123/#150 are not delivered by this diff. Only Task #229 is closed here. Its existing artifact #1 now holds current source and landed-composition evidence. **Remaining readiness:** no agreed prerequisite remains unlanded. Exact-head checks and automated review are complete; the automated round is not human approval. Human review remains. No merge or auto-merge is performed or enabled. The Docs route publishes the site without invoking Release Management, so no Release decisions block or release labels are added. </details> <details> <summary>Related references</summary> - Resolves #229 - References #228 and #230 - References the landed neighboring contracts in #209, #196, and #208 - [GitHub default community-file behavior](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file) </details>

Consumers gain one staged procedure for upgrading from the upstream source they actually use to a fixed target, with every applicable release accounted for. Use producer-owned discovery to establish the baseline, compose the required actions, preserve local intent, and verify the result; a version bump or the newest release note alone is not evidence of adoption. The shared `msx` plugin adds an optional discovery shortcut. Connected guidance explains qualification, automated-update gates, safe propagation, and completion ownership. This change delivers documentation and a thin skill pointer, not a consumer migration or an updater, publisher, or evidence-validator implementation.  ## New: Consumers can compose a complete upgrade The [Consumer Upgrades procedure](https://github.com/MSXOrg/docs/blob/main/src/docs/Ways-of-Working/Consumer-Upgrades.md) gives humans and agents one method for dependencies, frameworks, Actions, reusable workflows, and other versioned products. It connects immutable provenance, complete release history, an applicability-aware action ledger, the compatible target template, existing validation, and an explicit completion outcome. Each consumer establishes its own baseline even when a fleet shares one target. Follow these stages when adopting an upstream change: 1. Inventory the consumed references and establish the exact upstream version and authoritative immutable identity that actually resolved or ran. Distinguish that identity from the consumer's own package version. Use full commits for Git-distributed sources and authoritative digests or equivalent immutable identities for artifact-only products; do not invent Git mappings. A floating alias's present destination does not prove its past destination. Unknown baseline provenance blocks the upgrade. 2. Resolve and record one target: latest stable by default under the producer's version ordering and stable lineage, or an explicit stable/prerelease target. Exhaust paginated discovery and inspect every applicable release in `(baseline, target]`, in semantic and lineage order rather than API order or timestamps. Include no-action records; exclude unrelated backports and prerelease streams. Older targets use immutable target-era source, documentation, release snapshots, and templates, not today's aliases or final PR body. 3. Compose the required actions and record each disposition: completed with evidence, not applicable with a reason, no action required, or blocked with an owner. Reconcile renames, reversals, and superseded steps without deleting their evidence. Preserve mandatory intermediate conversions, installations, or runs; reading the complete history does not require installing every intermediate version. Equivalent authoritative external evidence is accepted without requiring MSX headings or tables. 4. Compare the consumer with the target's recorded compatible immutable template, distinguishing required integration surfaces, optional scaffolding, and intentional local differences. Never copy a template wholesale. Preserve consumer-owned code, tests, configuration intent, secrets, documentation, and assets. Record secret names and provisioning obligations, never values. If no template applies, state why; missing compatibility evidence is not a no-template result. 5. Run the existing relevant consumer tests, builds, linting, and integration checks against the exact target identity. Reconcile every ledger entry with the final diff and observed results, including no-action ranges. Keep introduced and pre-existing failures distinct; missing or failed required validation blocks readiness. 6. Carry the proven range, identities, complete release links, reconciled actions, template comparison, validation outcomes, and remaining blockers into the upgrade PR. Keep the consumer's release decision separate from its upstream target. Record review, merge, publication, and completion as distinct milestones. An identical target is already current; a lower target is superseded, not permission to downgrade. Retain the proven baseline, target, comparison, and reason in the delivery issue. Close only an unneeded open leaf with no remaining local work as not planned, without an empty PR or a shipped-upgrade claim. Preserve existing closed records, and reconcile an existing PR or unmet local acceptance criteria with its owner before changing its disposition. <details> <summary>Technical details</summary> The implementation adds the common playbook and routes existing discovery and adoption guidance to it. Missing provenance, release/action evidence, applicable template compatibility, or required prerequisites remains a stop condition. Changed inputs invalidate affected downstream evidence; the target is not silently changed. | Evidence | Source or scope | | --- | --- | | Exact candidate | MSXOrg/docs at `a8cecfddaf1a80efd6d5758e159844572d2b1e66`, branch `consumer-upgrades`. | | Current target observed during metadata revision | `main` at `5f64e8253b7bc2838c8c2bfb90e8ccd0a9d0e08d`. | | Scoped implementation comparison | Merge base `180f78a0b75b59149edca07280eca055ea303d82` through the candidate; the actual PR delta contains 19 files. This is PR evidence, not a fabricated consumer-publication baseline. | | Actual publication route | The candidate and current target use the native `Docs` workflow to build and deploy Pages. No versioned immutable artifact publication or Release Management decision path is configured in these workflows. Pages publication alone does not establish a managed release. | | Integration template | Not applicable to this documentation and thin-pointer delivery. Authoring structures are standards, not a product integration template; no pilot consumer or producer/template repository is modified. | No managed release decision or predicted release coordinate is asserted. The existing release-label mismatch remains a format-finalization blocker because this revision is limited to title and description. The first five implementation-plan steps in #203 are recorded complete. Walkthrough reconciliation, alignment, and scoped convergence evidence is retained here; the final normal review/handoff item remains incomplete. This metadata revision does not complete it or claim that the candidate contains later changes from `main`. The earlier eighteen documentation walkthroughs are retained in the issue's [range cases](#203 (comment)), [review edge cases](#203 (comment)), [conditional flows](#203 (comment)), [evidence isolation](#203 (comment)), and [entry gates](#203 (comment)). They exercise the written procedure, not a real consumer, pilot, live delegation, or security evaluation. | Cases | Required outcome | | --- | --- | | No-action patch and skipped releases | Retain every applicable record, reconcile the range, and run relevant existing validation. | | Breaking transition and renamed/reversed actions | Preserve local values and mandatory intermediate operations; classification does not hide incompatible behavior, including before 1.0. | | Prerelease and non-latest targets | Use source-specific snapshots and target-era evidence without merging unrelated streams or substituting final-PR prose. | | Floating baselines and artifact-only sources | Require past-execution provenance; accept authoritative immutable artifact identities without invented Git mappings. | | Missing evidence/template and no-template applicability | Block unknown required facts; distinguish justified non-applicability from missing evidence. | | Equal/lower targets and changed inputs | Record no-upgrade outcomes without empty PRs or downgrades; invalidate stale evidence without silently retargeting. | | Changed surface | Standards checked | Framework docs checked | Result | | --- | --- | --- | --- | | Consumer Upgrades playbook | Natural Language, Markdown, orchestration-playbook structure, evidence trust boundaries | PR Format; Release Management; Dependencies; Contribution Workflow | Aligned | | Navigation and discovery indexes | Existing front matter, navigation, and generated-index conventions | Documentation Model | Aligned | Source-bound validation remains available in the [earlier verification record](#205 (comment)). For the exact candidate above, the [Docs run](https://github.com/MSXOrg/docs/actions/runs/41505041468) and [cross-repository-links run](https://github.com/MSXOrg/docs/actions/runs/41505041504) completed successfully; Pages publication was skipped for the PR event. Earlier local checks and review records describe their tested revisions, not a newly added documentation-content assertion or index-drift enforcement policy. The recorded convergence search covered consumer, template, and downstream work. #143 needs separate standard-to-artifact inventory/enforcement, #136 owns Gallery updater delivery, and #187 needs router/published-URL enforcement. No additional issue was fully delivered by this diff; only #203 is a closing reference. </details> <details> <summary>Related references</summary> - Resolves #203 - References #202 - References #204 - References #143 - References #136 - References #187 </details> ## New: A shared skill exposes the procedure without owning producer discovery `msx-ways-of-working-consumer-upgrades` adds a thin pointer to the common procedure. Once the candidate is available through the marketplace, plugin consumers can refresh `msx@msxorg` to discover the intent; humans and agents can also follow the procedure directly without installing anything. Existing skill names remain supported. Producer or initiative guidance still owns authoritative repositories and registries, version/source mapping, release lineages, target-era guidance, and compatible immutable template discovery. The shared skill contains neither initiative-specific authority nor version-specific migration instructions. Its version does not prove template compatibility or that any producer implements the documented controls. <details> <summary>Technical details</summary> The eight-line skill points to one canonical document. Plugin and marketplace-entry metadata both change from `0.1.2` to `0.2.0` in the scoped comparison. These are repository manifest values, not evidence that a package or GitHub Release has been published, and not a selected consumer upstream target. | Changed surface | Standards checked | Framework docs checked | Result | | --- | --- | --- | --- | | Plugin README, skill, and manifests | Natural Language, Markdown, existing names/layout/version conventions | Plugin Marketplaces; Plugin Distribution; existing marketplace validation | Aligned | | Plugin Marketplaces and Plugin Distribution | Natural Language, Markdown, thin-pointer ownership | Agentic Development; Agent Plugins and Agent Skills | Aligned | Existing marketplace validation covers source resolution, synchronized versions, unique plugin names, and valid skill metadata. No new runtime or plugin installation is required by this PR. </details> ## Changed: Update and fleet guidance qualifies work before implementation Dependency and fleet guidance now routes each actual consumer through the complete procedure instead of treating a reference change or the newest note as adoption. For a fleet upgrade, establish the pre-upgrade baseline and fixed target before creating or adopting a branch/PR. Do not use an existing PR's proposed references as proof of what the consumer consumed, discard unmet local acceptance work, or copy another consumer's edits. When implementing automated dependency-update handling, create proposals as drafts or immediately convert them to draft if the native updater cannot do so. Keep them draft until the normal readiness gate holds. Before enabling automatic readiness, approval, or merge, bind adoption verification to an existing required PR check, or a separate required check when none owns it. Missing, stale, pending, or failed evidence must hold those actions even if builds pass; keep automation outside those actions until enforcement exists. The draft flag preserves the review signal but is not that independent enforcement mechanism. A proven no-upgrade outcome needs no reference-change campaign or empty PR. Campaign issues retain their prefix, PRs retain reader-facing titles and verified native Development links, and target-specific issue-linking/closure rules still apply. Advancing a controlled compatible owned-major alias alone does not require a consumer reference-change campaign; deliberate pinned upgrades and breaking-major adoption still need per-consumer evidence. <details> <summary>Technical details</summary> This PR specifies adoption and automation gates; it does not implement a required evidence validator, updater, receiving workflow, ruleset change, or consumer campaign. The documented green-build/incomplete-evidence case must remain blocked in a conforming implementation. | Changed surface | Standards checked | Framework docs checked | Result | | --- | --- | --- | --- | | Dependency Updates spec/design | Natural Language, Markdown, existing spec/design structure | Consumer Upgrades; Release Management; Merge Automation; review readiness | Aligned | | Fleet Orchestration | Natural Language, Markdown, fleet and delivery-leaf conventions | Consumer Upgrades; controlled owned-major policy; native issue linking; completion ownership | Aligned | The fleet view distinguishes integration, an evidenced not-needed result, and delivery completion. A merged reference bump or automatically closed issue alone does not prove required publication, deployment, or template work. </details> ## Changed: Propagation guidance preserves stable targets and isolated evidence Downstream-propagation guidance qualifies the actual consumer before Build and uses one durable delivery identity for a producer version and dependent. Implementations must validate stable release kind at both release-triggered and manual-backfill entry points, before fan-out or issue creation: skip prerelease events and reject prerelease backfill requests with a clear error. Keep the event or explicit backfill target fixed; delayed notifications never authorize downgrades. Standalone consumer prerelease upgrades do not widen this stable-only capability. The notifier creates or reuses the Task or Bug before engaging an agent. If authoritative provenance already proves no upgrade is needed, record that outcome without delegation. Otherwise use the producer's configured mode. Issue-first uses issue pickup only after delegation is selected. Task-first starts a read-only qualification task with `create_pull_request: false`, then creates or reuses one correlated PR-delivery task with `create_pull_request: true` only for a verified needed upgrade. That task uses the same issue and qualified plan and produces the closing PR, which remains draft until readiness. For retries, serialize discovery and handoff for that producer version and dependent; verify the issue's immutable target and retain execution correlation there. Issue existence, request acceptance, and task completion alone are not successful handoff. Reuse active execution and any matching PR or verified no-upgrade outcome. Retain an `idle` task for designated-owner re-engagement; a `waiting_for_user` task needs an authorized answer in that same task. Neither permits replacement. Failed, timed-out, canceled, missing, or uncertain outcomes require reconciliation before a safe retry; preserve partial consumer work rather than creating duplicate issues, tasks, or PRs. Carry the complete source-bound release record and publication envelope losslessly as untrusted evidence, separate from application-owned task instructions. A runtime data/attachment boundary or collision-safe quotation must prevent embedded directives or delimiters from changing scope, permissions, secret handling, or validation/review gates. Extract proposed actions and validate them against the consumer's governing instructions. A summary cannot replace the complete record or the consumer's full crossed range; unsafe isolation blocks delegation rather than truncating content or trusting it as instructions. For implementations, keep `PROPAGATION_TOKEN` as the explicitly passed secret name, scoped only to necessary dependents, with `Issues: write`, `Pull requests: read`, and mode-specific permissions. Task-first also needs the Agent Tasks API's accepted user credential with `Agent tasks: write`; Issue-first uses its configured pickup mechanism instead of unconditional task creation. Keep least-privilege workflow permissions and do not use `secrets: inherit`. The notification credential does not itself push or open PRs; execution does that in its own session. This documentation change provisions no credential, permission, setting, or task. <details> <summary>Technical details</summary> The spec/design and capability indexes now describe both a needed-upgrade PR and an evidenced no-upgrade outcome. The issue is durable identity; live execution state and actual handoff are read from their platform, not maintained in a second status store. Missing provenance, required actions, template evidence, or validation remains blocking; genuinely independent work alone can move to a follow-up. The recorded conditional-flow, adversarial-record, backfill, and paused-task walkthroughs distinguish the notifier, qualification, PR delivery, retries, and final consumer completion. They are documentation reasoning, not proof of an implemented Agent Tasks integration or runtime security control. | Changed surface | Standards checked | Framework docs checked | Result | | --- | --- | --- | --- | | Downstream Release Propagation spec/design/index and capability discovery | Natural Language, Markdown, evidence trust boundaries | Consumer Upgrades; qualification/idempotency; configured delegation; Continuous Practices | Aligned | </details> ## Changed: Completion guidance keeps evidence and publication separate Review readiness now explicitly requires complete consumer evidence; an upgrade also reconciles its full baseline-to-target range. Applicable producer/template work needs demonstrated compatibility with an immutable reviewed identity. Verified candidate or prerelease evidence can support review without inventing final coordinates, creating a circular pre-merge prerequisite, or waiving a native blocker. Before review, name the issue and responsible owner for the whole required outcome. If source integration and necessary template or other delivery work span separate leaves, use a PBI with required native children and keep it open until the combined criteria are verified; each PR closes only its own Task or Bug and references the PBI without closing it. For a single leaf awaiting its own publication/deployment without an aggregate owner, the owner reopens it if PR closure precedes that evidence, then closes it only after verification. Reconcile template compatibility with the actual published producer identity and deliver necessary linked template changes before claiming completion; rerun affected validation when that identity differs. The existing Implement alignment pass carries these obligations in its normal PR sections and evidence rows, without a second checklist. Keep resource documentation current and retain release-specific transitions, migration history, and delivery plans in their GitHub records. Decision records and research retain their distinct purposes. A normative contract is not proof of implementation or CI enforcement; consumers adopting older targets still need immutable historical source/docs and release records. <details> <summary>Technical details</summary> | Changed surface | Standards checked | Framework docs checked | Result | | --- | --- | --- | --- | | Definition of Ready and Done; Implement | Natural Language, Markdown, readiness and issue hierarchy | PR Format; Release Management; Consumer Upgrades; Task/PBI completion | Aligned | | Documentation Model | Natural Language, Markdown, artifact tiers | Spec-Driven Development; source-bound release evidence | Aligned | #203, assigned to MariusStorhaug, remains the completion owner for this single-leaf documentation delivery and its required Pages publication. If PR closure precedes publication evidence, the owner follows the reopen path. No applicable integration template or additional delivery leaf calls for a PBI here. The old governance exception is resolved: #166 is closed, and current effective `main` rules require Lint, Links, Test, Build, and Cross-repository links. Passing candidate runs do not establish publication, complete the Task's remaining handoff item, or authorize merging. The PR is currently non-draft; this title/body revision leaves that state, labels, source, and native maintenance settings unchanged. The existing release-label mismatch on the Pages-only route is still a format blocker, not a supported release decision. Current canonical PR Format and Release Management, including the accepted defaults, keyed routing, lifecycle, and producer-conformance boundaries, govern finalization instead of the Task's historical kickoff policy. The scoped candidate diff changes no release resolver, PR Format, issue-type or community-file policy, tests, validation script, or workflow. This metadata revision does not restore documentation-content assertions or index-drift enforcement, change producer behavior, or claim conformance from documentation or plugin version numbers. Out of scope remain PSModule pilot selection/execution, historical release or PR backfill, version-specific skills, updater/publisher/validator implementations, automatic template synchronization, and unrelated governance changes. </details> <details> <summary>Related references</summary> - References #166 - References #196 - References #208 - References #230 - References #231 </details>

Define configurable default release bump

4ea1324

Marius Storhaug (MariusStorhaug) self-assigned this Aug 29, 2026

Marius Storhaug (MariusStorhaug) added the release:skip Validate the change without publishing a release. label Aug 29, 2026

Marius Storhaug (MariusStorhaug) added 2 commits August 29, 2026 14:32

Align release policy guidance

7e6fa0c

Align VS Code release defaults

f635b0d

Marius Storhaug (MariusStorhaug) requested a lite review from Copilot August 29, 2026 12:35

Copilot started reviewing on behalf of Marius Storhaug (MariusStorhaug) August 29, 2026 12:36

View session

Copilot AI reviewed Aug 29, 2026

View reviewed changes

Clarify owned release label overrides

935a2a4

Marius Storhaug (MariusStorhaug) requested a lite review from Copilot August 29, 2026 12:40

Copilot started reviewing on behalf of Marius Storhaug (MariusStorhaug) August 29, 2026 12:41

View session

Copilot AI reviewed Aug 29, 2026

View reviewed changes

Marius Storhaug (MariusStorhaug) marked this pull request as ready for review August 29, 2026 12:43

Marius Storhaug (MariusStorhaug) enabled auto-merge (squash) August 29, 2026 12:43

Correct prerelease label qualifier

e90082b

Marius Storhaug (MariusStorhaug) mentioned this pull request Sep 4, 2026

Release decisions use owned labels and effective settings PSModule/Release-GHRepository#109

Draft

Marius Storhaug (MariusStorhaug) requested a lite review from Copilot September 4, 2026 16:32

Copilot started reviewing on behalf of Marius Storhaug (MariusStorhaug) September 4, 2026 16:33

View session

Copilot AI reviewed Sep 4, 2026

View reviewed changes

Key release branches by release type

38af068

Marius Storhaug (MariusStorhaug) requested a lite review from Copilot September 4, 2026 16:55

Copilot started reviewing on behalf of Marius Storhaug (MariusStorhaug) September 4, 2026 16:55

View session

Copilot AI reviewed Sep 4, 2026

View reviewed changes

Marius Storhaug (MariusStorhaug) mentioned this pull request Sep 6, 2026

Make release impact and user adoption explicit in PR release notes #202

Closed

11 of 12 tasks

Marius Storhaug (MariusStorhaug) mentioned this pull request Sep 6, 2026

📖 [Docs]: Release notes carry complete consumer adoption evidence #204

Merged

This was referenced Sep 6, 2026

Define the evergreen consumer upgrade procedure and completion gates #203

Closed

Consumer upgrades use complete release-range evidence #205

Merged

Marius Storhaug (MariusStorhaug) mentioned this pull request Nov 1, 2026

Solution settings use canonical filenames #233

Merged

Reconcile release default guidance with current main

ce9ca51

Marius Storhaug (MariusStorhaug) requested a lite review from Copilot November 1, 2026 13:22

Copilot started reviewing on behalf of Marius Storhaug (MariusStorhaug) November 1, 2026 13:22

View session

Copilot AI reviewed Nov 1, 2026

View reviewed changes

Comment thread tests/ReleaseSettingsDocumentation.Tests.ps1 Resolved

Marius Storhaug (MariusStorhaug) assigned Copilot Nov 1, 2026

Copilot started work to resolve merge conflicts on behalf of Marius Storhaug (MariusStorhaug) November 2, 2026 19:59

View session

Merge main and reconcile release settings documentation

105d53f

Co-authored-by: MariusStorhaug <17722253+MariusStorhaug@users.noreply.github.com>

Copilot finished work on behalf of Marius Storhaug (MariusStorhaug) November 2, 2026 20:02

Marius Storhaug (MariusStorhaug) unassigned Copilot Nov 2, 2026

Remove prose-only release documentation tests

d9d35ab

Marius Storhaug (MariusStorhaug) changed the title ~~Release guidance uses configurable default bumps~~ Release guidance uses keyed release types Nov 2, 2026

Marius Storhaug (MariusStorhaug) requested a lite review from Copilot November 2, 2026 20:47

Copilot started reviewing on behalf of Marius Storhaug (MariusStorhaug) November 2, 2026 20:47

View session

Copilot AI reviewed Nov 2, 2026

View reviewed changes

Comment thread src/docs/Capabilities/release-management/design.md Resolved

Comment thread src/docs/Capabilities/release-management/spec.md Resolved

Clarify effective release routing constraints

99fd558

Marius Storhaug (MariusStorhaug) requested a lite review from Copilot November 2, 2026 20:53

Copilot started reviewing on behalf of Marius Storhaug (MariusStorhaug) November 2, 2026 20:53

View session

Copilot AI reviewed Nov 2, 2026

View reviewed changes

Comment thread src/docs/Capabilities/release-management/spec.md Resolved

Specify inherited release routing validation

3f48c8b

Marius Storhaug (MariusStorhaug) requested a lite review from Copilot November 2, 2026 20:59

Copilot started reviewing on behalf of Marius Storhaug (MariusStorhaug) November 2, 2026 20:59

View session

Copilot AI reviewed Nov 2, 2026

View reviewed changes

Marius Storhaug (MariusStorhaug) merged commit bdb581f into main Nov 3, 2026
22 checks passed

Marius Storhaug (MariusStorhaug) deleted the default-release-bump branch November 3, 2026 16:30

Conversation

Marius Storhaug (MariusStorhaug) commented Aug 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changed: Release branches are keyed by the type they publish

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟢 Approval recommended

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟢 Approval recommended

Suppressed comments (1)

Uh oh!

Marius Storhaug (MariusStorhaug) commented Sep 6, 2026

Uh oh!

Marius Storhaug (MariusStorhaug) commented Sep 6, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🔵 Needs a closer look

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Marius Storhaug (MariusStorhaug) commented Aug 29, 2026 •

edited

Loading