[Marius Storhaug (MariusStorhaug)]

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.

This changes canonical guidance, not runtime loaders or module configuration. Supported explicit custom paths and public caller inputs remain under each producer's existing contract.

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. A reader may expose a documented explicit path override without this convention restricting otherwise supported custom paths.

Module repositories keep .github/PSModule.yml through SettingsPath for module-pipeline configuration, including release settings. The PSModule initiative records this supported exception and links to the actual framework input/settings references. No module filename migration, second release settings file, or caller-input change is required here. Module naming alignment is separate work, not behavior implemented by this PR.

The VS Code framework design likewise records its existing .github/vscode-extension.yml template interface as a supported naming exception. Its settings keys and interface are unchanged; any filename change requires a verified reader and a separate template/caller migration. This avoids an unapproved configuration migration while keeping the common naming rule and its explicit exceptions consistent.

Technical details

The complete immutable comparison is accepted main aa9b5cecc69f4cbe6aa04a5dd70ff9cdadeeac3d to candidate 734145479ede01a7ccdeb4eb29950d405ed99a09. Five ordinary commits preserve the initial filename revision, add the broader regression-first naming rule, and address the owning-guide compatibility finding. e65b9e0 and f021418 are earlier iterations, not this final source.

The authoritative Naming subsection states the rule. PSModule module settings and the VS Code configuration surface own their supported exceptions. Related pages link to that rule rather than defining another copy; repository and release guidance link to the module boundary.

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
tests/PR-Format.Tests.ps1	PowerShell, Testing, Code Layout, Error Handling	PR-record, release-settings, and solution-settings documentation contracts	Aligned

The module default is verified from released Process-PSModule source 105e4dcefe1946782066aa50a5c7d3658319895a and the published workflow-input reference: SettingsPath defaults to .github/PSModule.yml. The settings reference owns module keys/defaults. This PR does not change that workflow, its input, settings schema, or enriched runtime settings object. The directly related obsolete framework overview link is corrected to its actual canonical site route.

Regression-first evidence: all 13 broader naming/boundary cases fail before the documentation changes while all 25 earlier checks pass. A further case reproduces the VS Code exception gap before its two-line guide correction. The corrected candidate passes all 39 focused checks and all 103 tests in seven existing Pester suites. Nine isolated deliberate regressions are rejected and pass after restoration, including a duplicate rule owner, broken discovery, unrequested directory/custom-path restrictions, forced module filename or second release file, and a false implemented-reader claim.

The first review finding is addressed by documenting the preserved VS Code interface; the inline reply records the fix and the thread is resolved. The fresh corrected-head review approves 734145479ede01a7ccdeb4eb29950d405ed99a09 with zero new inline comments. No review thread remains unresolved.

All five live required CI checks pass at that exact head: Lint, Test, Build, Links, and Cross-repository links. Publishing is intentionally skipped for this PR.

The changed Markdown/PowerShell surfaces are lint-clean. Documentation indexes are current, relative links resolve across 127 pages, and cross-repository links resolve on the changed pages. The pinned Zensical 0.0.59 site build succeeds with no issues; rendered output preserves the naming rule, module boundary, and explicit VS Code exception. Temporary build environments, output, and negative-test fixtures are cleaned without changing shared dependencies or reviewed source.

The Task's implementation, validation, and review-correction steps are complete. The focused convergence sweep covers open issues/PRs naming settings filenames and the common convention; no additional complete delivery ask converges with this diff. Broader default-bump/keyed-route and lifecycle work stays separate, with no unmerged scope imported. The Task remains open until human-reviewed integration; this PR stays draft under the integration hold, not because CI or automated review is incomplete.

Related references

• Resolves Standardize solution-owned settings filenames #232

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 are retained. This repository has no settings file or runtime loader to rename.

The former .github/auto-release.yml is only migration evidence for the separate Release-GHRepository reader change, not a current alternative convention. That producer's unmerged development candidate changes the conventional default to .github/release.settings.yml, rejects the removed conventional path even when explicitly selected, and retains ConfigurationFile as the public input with unrelated supported explicit custom paths intact. It provides migration diagnostics without legacy fallback. This documentation PR neither delivers nor releases that reader. Consumers verify the producer revision and follow its own migration record before adopting a changed default; module release settings remain in the supported PSModule.yml interface.

Technical details

Changed surface	Standards checked	Framework or domain docs checked	Result
src/docs/Capabilities/release-management/spec.md	Documentation Model, Natural Language, Markdown	Release applicability, defaults, overrides, and decision validation	Aligned
src/docs/Capabilities/release-management/design.md	Naming, Documentation Model, Markdown	Settings input/default separation and module exception	Aligned
src/docs/Capabilities/vscode-extension-framework/design.md	Documentation Model, Naming, Markdown	Existing extension settings interface and release configuration surface	Aligned
src/docs/Ways-of-Working/Automation-Labels.md	Automation Labels, Natural Language, Markdown	Release-route applicability	Aligned
src/docs/Ways-of-Working/PR-Format.md	PR Format, Natural Language, Markdown	Conditional release settings and complete-record ownership	Aligned

Release design links the naming rule and module exception, and separates a filename convention from an implemented reader or renamed input. Existing filename/semantic guards remain green. 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.

Separate runtime correspondence uses 03e20b8293dd8dfb41bead3255930a5edbb2e9bb in PSModule/Release-GHRepository#109, reverified as a draft, unmerged development candidate. It is not production behavior delivered here. Typed caller overrides, keys/precedence, helper exports, and environment namespaces remain outside this documentation change; the producer's review and delivery gates remain with its owner.

The docs main route builds and deploys an unversioned site, not a versioned immutable consumer artifact. No release-decision block, release label, fabricated publication baseline, or live publication applies to this PR. No module file, loader, public input, Build/metadata/runtime schema, publisher, label, pin, permission, ruleset, marketplace, or consumer fleet change is included.

The full ten-file corrected diff is self-reviewed against current main. #196 and #208 retain independent release-doc scopes and receive the new immutable source for sequential reconciliation; earlier correspondence does not prove this broader rule and supported exceptions. Any later main change requires a refreshed comparison and exact-head validation.

Native Agent merge is enabled only for review feedback, CI fixes, and conflict resolution with merge_pr=false. GitHub auto-merge is disabled. Remaining gates are human review/integration decisions and separately owned producer/module migration work; no merge or live publication is authorized.

Related references

• References Release decisions use owned labels and effective settings PSModule/Release-GHRepository#109
• References Release guidance uses configurable default bumps #196
• References Release guidance defines durable lifecycle and complete consumer records #208
• References Pull request guidance describes complete source-bound records #209

[Copilot]

🟢 Approved

There are no active review issues blocking the documentation filename standardization.

No open issues 🎉

What changed in this PR

Standardizes the optional Release Management settings filename as .github/release.settings.yml across canonical guidance. This is a documentation change; released producers’ inputs and runtime loading behavior remain unchanged.

Changes:

• Updates 17 filename references across five documentation pages.
• Adds five filename checks and four semantic guards covering existing settings and release-decision requirements.

File	Description
tests/​PR-Format.Tests.ps1	Adds canonical filename checks and guards for unchanged release semantics.
src/​docs/​Ways-of-Working/​PR-Format.md	Updates settings references in PR authoring guidance.
src/​docs/​Ways-of-Working/​Automation-Labels.md	Updates the optional settings path in release-label guidance.
src/​docs/​Capabilities/​vscode-extension-framework/​design.md	Updates configuration and template-layout references.
src/​docs/​Capabilities/​release-management/​spec.md	Updates settings references without changing applicability requirements.
src/​docs/​Capabilities/​release-management/​design.md	Updates settings paths in examples, precedence guidance, and configuration tables.

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

The new mandatory naming rule conflicts with the extension framework guide’s prescribed .github/vscode-extension.yml filename, without a documented exception or verified filename migration.

1 open issue

• Resolve extension settings filename conflict in VS Code guide · New

_{Review effort: Balanced}

[Copilot]

🟢 Approved

No active review issues block the settings-naming and release-guidance documentation changes.

No open issues 🎉

1 resolved since last review

• Resolve extension settings filename conflict in VS Code guide

_{Review effort: Balanced}