Block unsafe or unevaluated release decisions before merge #112

Outcome

As a maintainer of a release-managed repository, I can trust that an unsafe or unevaluated release decision prevents merge, while a valid current decision still follows the repository's normal independent review requirements.

Acceptance scenarios

Scenario: A current valid decision is eligible for normal review
  Given a pull request targeting a release-managed route
  And its current source, settings, caller overrides, and owned labels resolve a valid decision
  When its merge eligibility is evaluated
  Then the decision is visibly evaluated for those inputs
  And existing independent approval and conversation requirements still apply
  And successful validation does not itself authorize publication or merge

Scenario: Invalid or conflicting decisions block merge
  Given invalid supplied settings or conflicting owned release signals
  When the pull request's merge eligibility is evaluated
  Then merge is blocked
  And a warning or an unrelated successful test cannot replace the failed decision

Scenario: Missing or pending evaluation blocks merge
  Given the current release decision has no completed valid evaluation
  When manual or automated merge is considered
  Then merge is blocked whether the result is missing or still pending

Scenario: Changed inputs invalidate earlier evidence
  Given an earlier successful release decision
  When the source, target route, release settings, caller overrides, or owned labels change
  Then that earlier result does not validate the new inputs
  And the current decision must be evaluated before merge becomes eligible

Scenario: Unrelated successful runs do not stand in for a PR decision
  Given a successful manual or scheduled test that did not evaluate this PR's current release inputs
  When this PR's merge eligibility is evaluated
  Then the unrelated result cannot satisfy its release-decision requirement

Scenario: Skip remains an evaluated successful decision
  Given a valid release:skip decision on a release-managed route
  When the pull request is evaluated
  Then validation succeeds without publication
  And the decision is not bypassed because the change will not produce a release

Scope and authorization

This issue owns the merge-confidence outcome, not a second release algorithm or a relaxation of review controls. It does not authorize changing live permissions, policy, approval requirements, auto-merge, labels, releases, or tags. Any operational governance action needs its own authorization and independent evidence.

Design and supporting evidence

• Required pre-merge decision behavior, the confirmed design candidate in Pull request guidance describes complete source-bound records MSXOrg/docs#209.
• Resolver delivery and observed readiness gap, Release decisions use owned labels and effective settings #109.
• Independent stable-publication delivery, 🌟 [Major]: Support push-authoritative releases and moving workflow tags #108.

The chosen enforcement mechanism, exact check identity, operational procedure, and verification artifacts belong in the design and eventual delivery/audit evidence, not in these consumer acceptance scenarios.

Technical decisions and readiness

• Reuse the existing action/settings/decision resolver. The observed gap spans .github/workflows/Action-Test.yml and main-branch enforcement: the current Action-Test - [Default] job also runs on non-PR events, while main declares no required-status-check rule.
• A completed non-PR smoke test must not be accepted as current PR decision evidence. The chosen PR-specific check must evaluate the candidate source, target route, effective settings, supported caller overrides and current owned labels, including valid skip.
• Preserve CODEOWNERS, last-push approval and conversation-resolution requirements. Do not compensate for absent enforcement by enabling auto-merge or weakening another gate.
• This Task is not implementation/operation-ready until the governance owner confirms the stable check identity, enforcement representation, authorized operational scope and independent verifier. Record those choices in linked design/delivery evidence before execution.

Implementation plan

• Read live main-branch rules and identify the absent enforcement/current non-PR check ambiguity.
• Confirm the authorized governance owner, check-producing identity, exact required check name and independent verifier.
• Write failure/pending/absence/stale-input and unrelated-success cases before changing check wiring or policy representation.
• Update the existing PR validation wiring in its separately scoped repository delivery, using the shared resolver and unchanged review gates.
• After separate explicit authorization, apply the minimal enforcement change and retain its audit evidence.
• Independently verify every acceptance scenario, including valid skip and unchanged human-approval requirements.
• Update design/documentation/links and distinguish repository delivery evidence from the operational completion record before closing this Task.