Enforce a real PR validation gate for PSModule community-default changes #83

Context and request

Community-default PRs need a real, required validation gate before they can meet the shared ready-for-review contract. PSModule/.github#82 has one successful Copilot review check on its pushed head, but no file-validation pipeline or required validation result. The applied organization GitHub Flow ruleset declares no required-status-check rule. Local validation and an explicitly requested automated review do not establish an enforced CI gate.

Deliver a separately authorized validation/enforcement fix for this repository. This follow-up records a discovered governance prerequisite; it is not permission to change workflows, rulesets, access, or organization settings during the scaffold delivery.

Acceptance criteria

• PRs that change inherited community files, including .github/pull_request_template.md and .github/CONTRIBUTING.md, produce an identifiable, completed validation result on the actual candidate head before review readiness.
• The protected target requires the exact validation result; a failed, pending, stale, or absent result cannot satisfy the gate.
• Draft PRs receive the intended validation. A manually dispatched or unrelated check is not accepted as a substitute for the PR event and affected paths.
• An independent maintainer can verify both workflow execution and the applied protection rule without waiving the shared readiness contract.
• No release publisher, consumer fleet, marketplace, or community policy behavior changes as a side effect.

Constraints and non-goals

Do not fold this independent governance change into the two-file scaffold PR. Changes to permissions or rulesets require separate authorization. No auto-merge, merge, release publication, tag movement, or label removal is authorized by this issue.

Technical decisions

Evidence: the live repository workflow list contains only dynamic Dependabot and Copilot review workflows; the checkout has no .github/workflows, test suite, dependency manifest, or lint configuration. The applied main rules from ruleset 19735208 include deletion, linear history, PR/conversation resolution, non-fast-forward, and Copilot-review rules, but no required_status_checks rule. Explicit Copilot review was requested for the scaffold draft; that does not configure required validation.

The governing contracts are Definition of Ready for Review and Required checks and auto-merge. Choose the minimal approved validation route and exact required check name during refinement, before implementing or authorizing enforcement. Reuse applicable shared validation rather than introducing an independent release resolver or treating a successful review as file validation.

Implementation plan

Deliver this bounded outcome through native sub-issues: one repository-code Task supplies the named read-only PR-event validation, and one separately authorized operational Task requires and independently verifies that exact result on the protected target. The native sub-issue inventory is the delivery plan and progress source; this aggregate has no direct implementation PR or inline delivery checklist.

The approved validation route measures Markdown syntax/style with the shared MSX rules. It does not certify the revised scaffold's authoring completeness, execute an unmerged source action, or authorize live governance changes. Code/fixture evidence, the unchanged legacy base scaffold, and the independent scaffold PR's later current-head run remain distinct.

Register the real named check on the code draft first so the governance owner can activate the separately approved repository-scoped requirement before readiness or merge. Do not require code-leaf closure before that activation: closure requires merge and would deadlock the readiness gate. After normal code integration, the scaffold owner refreshes its independent PR and obtains its own real PR-event result. Existing native blockers remain intact.

Close this PBI only after every required native child is complete and the aggregate acceptance criteria above are independently verified. Merely creating issues, publishing an advisory check, or passing local fixtures is not completion.