Resolve repository releases from owned decisions and effective settings #111

Outcome

As a repository or workflow maintainer, I can release at the level selected by my effective policy and deliberate pull-request decisions, without dependency metadata or ambiguous defaults unexpectedly changing the repository version.

Acceptance scenarios

Scenario: An inherited policy supplies the automatic release level
  Given a release-managed pull request with no owned bump or skip decision
  When its release decision is evaluated
  Then its valid effective DefaultBump supplies patch, minor, or major
  And the selected level and its source are visible to the maintainer
  And omitting all overrides retains the documented patch default

Scenario: Deliberate invocation and pull-request decisions take precedence
  Given a valid repository default and an explicit CallerOverrides value
  When the pull request is evaluated
  Then the invocation override supplies the effective default
  And an explicit owned bump overrides that default
  And omitting CallerOverrides does not mask the repository setting
  And supported false and empty text overrides retain their meaning

Scenario: Unowned metadata cannot select a bump
  Given dependency, bare, retired, or unrelated labels
  When the pull request is evaluated
  Then those labels do not select a repository release level
  And the valid effective default or owned decision remains authoritative

Scenario: Invalid or conflicting intent cannot publish
  Given an invalid supplied setting or conflicting owned release decisions
  When the pull request is evaluated
  Then validation fails with an actionable explanation
  And a valid narrower override cannot hide the invalid value
  And no release is published as a fallback

Scenario: Skip is successful validation without publication
  Given release:skip without another owned release signal
  When the pull request is evaluated
  Then validation succeeds without a new version or release
  And a valid non-prerelease branch is not rejected for lacking a prerelease identifier

Scenario: Prerelease behavior respects reviewed source and cleanup boundaries
  Given an open pull request requesting a valid prerelease
  When it is published
  Then the prerelease targets its exact reviewed head commit
  And a branch-name collision cannot select another source
  When its configured cleanup is evaluated after closure
  Then only matching prereleases are eligible
  And stable releases are never cleanup candidates

Scenario: Conventional settings use the verified release reader
  Given valid settings in .github\release.settings.yml
  When ConfigurationFile is omitted
  Then that file supplies the repository policy
  And documented defaults remain valid when the file is intentionally absent
  When the removed conventional path exists or is explicitly selected
  Then evaluation fails with a precise coordinated filename/reader migration explanation
  And no policy is silently substituted and no publication is attempted
  Given an intentional existing custom settings path
  When it is selected through ConfigurationFile
  Then that explicit path is honored without a legacy discovery alias

Scenario: Consumers receive a sufficient adoption record
  Given the delivery is prepared for review
  When a maintainer reads its complete PR title and body
  Then changed interfaces, compatibility, required adoption actions, and their evidence are available
  And the effective release decision and unresolved prerequisites are explicit
  And a draft candidate is not presented as a production dependency

Scope

This issue owns the release-decision/settings deliverable in the existing #109. Push-authoritative stable publication, controlled aliases, the full durable/RC lifecycle, historical relabeling, and live publication/governance actions are separate outcomes. Date versioning and Discord sending are not requested.

Design and delivery evidence

• Release decisions and settings design, the confirmed design candidate in Pull request guidance describes complete source-bound records MSXOrg/docs#209.
• Implementation, caller adoption, bootstrap evidence, and review record, Release decisions use owned labels and effective settings #109.
• Candidate action usage (not a published dependency).

Implementation choices, repository paths, test counts, and review progress stay in the linked design/PR evidence rather than in these consumer acceptance scenarios.

Technical decisions

• Preserve the five owned labels and the validated patch/minor/major DefaultBump contract. Resolve settings and decisions through the shared helpers, not a second bump algorithm.
• action.yml declares shared defaults. Scalar inputs retain file-over-input compatibility; the explicitly selected CallerOverrides YAML/JSON string mapping is the invocation-over-repository channel. Validate every supplied scope before combining values.
• src/Release-GHRepository.Helpers.psm1 owns configuration/decision resolution, label definitions, validated prerelease context and cleanup selection. src/main.ps1 wires them to the existing PR-state publication path. Push-specific context, exact stable source/record binding, retries and controlled aliases remain 🌟 [Major]: Support push-authoritative releases and moving workflow tags #108.
• Cleanup compares the identifier after the first version core case-sensitively, excluding later embedded identifiers and invalid cores. Skip never parses a latest version; retain raw release listing required for configured cleanup.
• Keep the complete migration/bootstrap instructions and source/template evidence in the linked PR. An unpublished candidate is not a production dependency; templates, governance and publication require their separately scoped delivery.

Implementation plan

• Inspect the existing PR, released reader, actual supported inputs, live checks and ownership.
• Write missing settings/controller cases first and preserve the exhaustive owned-label matrix.
• Implement typed overrides, strict supplied-scope validation, provenance and valid non-prerelease contexts.
• Verify the eight anonymous immutable-v2 bootstrap cases and record caller ordering requirements.
• Attach the complete source-bound PR record and update target-state README guidance.
• Reproduce cleanup-separator/case and skip-version review findings with tests before implementation.
• Fix those findings within the shared helper/controller boundary and verify all 150 repository cases plus eight bootstrap cases.
• Update the final candidate identity, source-bound record, documentation links and hosted review evidence.
• Run final-head existing CI and a fresh complete hosted review, including summaries and every in-scope thread.
• Keep draft state for any unresolved prerequisite or unmet readiness gate.

Earlier resolver implementation evidence

The earlier resolver candidate was b8767c4; the filename revision and current source are recorded below. All 150 repository cases, eight released-reader bootstrap cases, and final-head CI pass. Both complete hosted-review rounds were evaluated; the three inline findings are fixed/resolved. The final summary's tag-authentication caution was checked against the actual dependency and two anonymous bootstrap experiments, without changing checkout security or publishing. This implementation plan is complete, but the Task stays open and the existing PR stays draft because the native decision-enforcement prerequisite is unresolved. The reviewed code is not a production dependency until an authorized immutable engine release exists.

Settings filename revision

The user-directed follow-up changes the actual ConfigurationFile default to .github\release.settings.yml. This supersedes the earlier documentation-only instruction that left auto-release.yml untouched. Typed CallerOverrides, setting names/precedence, the resolver/label contract, environment namespaces and the separate push-authority scope remain unchanged. The user explicitly selected rejection of the removed conventional path even when supplied through ConfigurationFile; legitimate unrelated custom paths remain controllable.

• Inspect the released and candidate defaults, actual reader, caller examples, tests and native prerequisites.
• Add test-first cases for new-default loading without injected ConfigurationFile, valid absence, legacy-only/conflicting conventional files, normalized explicit old paths, legitimate custom selection, invalid new data, precedence and no mutation.
• Implement the single declared release.settings.yml default and actionable migration guard with no legacy reader fallback or alias.
• Update target-state README and complete source-bound release record, including exact filename/reference/caller ordering and canonical immutable correspondence.
• Run existing full validation and old-reader bootstrap controls, push small ordinary commits, evaluate current-head full hosted review/CI and report the new ownership boundary.
• Retain draft status and genuine production/governance prerequisites; maintenance-only Agent merge stays merge_pr=false and GitHub auto-merge off.

Filename revision evidence: the actual reader/default revision is committed at 03e20b8. All 167 repository cases and eleven immutable-v2 bootstrap cases pass. The complete PR record explains coordinated filename/reader/caller adoption; current-head review and the broader canonical convention correspondence remain pending. The independent push-authority input handoff is linked at #108 (comment); no distinct #108 owner or working-copy incorporation is claimed.

Final filename result: all 180 cases pass at 03e20b8 and current-head hosted CI is green. The complete review #109 (review) reports no open issues but defers live end-to-end publication assessment; it is not automated approval. Canonical correspondence is verified against MSXOrg/docs#233 at 734145479ede01a7ccdeb4eb29950d405ed99a09, including https://github.com/MSXOrg/docs/blob/734145479ede01a7ccdeb4eb29950d405ed99a09/src/docs/Coding-Standards/Naming.md#solution-settings-files and the PSModule.yml/SettingsPath exception. No production dependency, release/tag, module settings or live governance change is performed. The native #112 prerequisite keeps readiness blocked.