Skip to content

Require and independently verify the community validation check on main #85

Open
Task
Open
Require and independently verify the community validation check on main#85
Task

Description

@MariusStorhaug
Marius Storhaug (MariusStorhaug)
opened on Oct 31, 2026

Describe the change

Context and request

Make the file-validation result mandatory for PSModule community-default PRs before review readiness and merge. This is the separately owned operational-enforcement leaf of PSModule/.github#83, not authorization to mutate live governance from the validation-code assignment.

Acceptance criteria

  • A separately authorized governance maintainer requires the exact hosted check Community file validation and its verified GitHub Actions integration for refs/heads/main in PSModule/.github, without weakening or changing existing organization-wide rules or unrelated repositories.
  • Independently captured applied-rule evidence confirms that failed, pending, stale, or absent validation does not meet the required-check gate. Strict up-to-date enforcement and draft coverage are verified with anonymous fixtures; a manual workflow dispatch or Copilot review is not file validation.
  • The named check first exists from a real PR event at the validation-code candidate head. Its actual head, workflow path, check integration, execution, and non-empty affected-file scan are recorded before activation.
  • After code integration, the independently owned scaffold PR receives a real PR-event check on its refreshed current head. The unchanged legacy base template is not presented as proof of new-format completeness.
  • An independent verifier in a separate session that did not execute the rule change verifies every criterion and records durable audit evidence before this operational Task is closed. The user explicitly approved both sessions using the same linked GitHub account; this does not claim a second human identity or human code approval. The parent outcome stays open until its native children and aggregate criteria are complete.

Constraints and non-goals

Execution is not authorized by the code assignment. No organization-wide GitHub Flow ruleset mutation, permission expansion, release publisher, merge, auto-merge, publication, tag or label changes, or consumer rollout. Recording this issue or a proposed rule is not completion.

Technical decisions

The active rules for main are inherited from organization ruleset 19735208 and contain no required_status_checks rule. Preserve that organization's existing policy. Proposed minimal enforcement is an additive repository-scoped rule for this repository's main only, requiring Community file validation from the exact integration observed on the real candidate check, with strict up-to-date checking and no new bypass actor. The governance owner must obtain explicit approval for the exact target and consequence before making any change; this body is only the proposal.

Execution owner: this Project, acting through the linked Marius Storhaug (@MariusStorhaug) account after the user approved the exact repository-only strict rule. Independent verifier: the separately coordinated PSModule defaults/scaffold session, which did not implement this validation code or apply the rule. Both use the linked account, as explicitly disclosed and approved. Record distinct execution/verification sessions and their observed evidence; do not claim a second human account or an unperformed merge attempt.

Bootstrap ordering: register and verify the named check on the code draft, then activate and independently inspect the additive requirement before readiness or merge. Do not block rule activation on code Task closure: code closure requires merge, and that merge needs enforcement first. Once the workflow is integrated through normal review, the scaffold owner refreshes its independent PR and obtains fresh PR-event evidence. Native containment records the two deliverables; intermediate milestones do not create a false whole-issue dependency cycle.

Implementation plan

  • Obtain explicit authorization for the exact repository-scoped rule and name the execution owner and independent verifier.
  • Capture the real validation-code draft's current-head check name, GitHub Actions integration, PR event, and non-empty affected-file evidence.
  • Before activation, establish anonymous failed, pending, stale, and absent evidence cases and the expected rejection criteria without modifying another owner's PR.
  • Apply only the authorized additive main requirement and preserve the existing organization rules.
  • Independently verify the applied rules and rejection/success behavior, recording durable actor/time/target/evidence details.
  • After normal validation-code integration, obtain and inspect the scaffold's refreshed current-head PR-event check; verify aggregate readiness without a policy waiver.

Activity

  1. Marius Storhaug (MariusStorhaug)
    added the
    Task
    issue type on Oct 31, 2026
  2. Marius Storhaug (MariusStorhaug)
    added a parent issue on Oct 31, 2026

  3. MariusStorhaug commented on Oct 31, 2026

    @MariusStorhaug
    Marius Storhaug (MariusStorhaug)
    on Oct 31, 2026
    MemberAuthor

    Applied the user-approved additive repository-only rule at 2026-10-31T15:24:23.6522540Z, through the linked Marius Storhaug (@MariusStorhaug) account. The approved independent verifier is the separate scaffold session using that same linked account, not a claimed second human identity.

    Baseline: main inherited organization GitHub Flow ruleset 19735208 with its existing PR/review/thread/squash/linear-history/non-fast-forward policies and no required status check. No repository rule existed. A real PR-event Community file validation result from GitHub Actions app 15368 was completed successfully at #86 head 66cd708 before activation.

    Change: Added Community defaults validation, active only for refs/heads/main, requiring exactly Community file validation from integration 15368 with strict up-to-date checking. No bypass actor was added; the API reports current_user_can_bypass=never. No organization-wide rule was edited.

    Read-back: The repository ruleset/effective-main APIs include the exact check/source/strict setting and retain the inherited rules. A non-target community-validation-scope-control branch evaluation has no required-status-check rule. No merge, publication, tag/label change or CI result manipulation occurred.

    Independent applied-rule/context verification is pending. The operational Task remains open for its remaining verification and post-integration scaffold evidence; this activation does not close the code Task or parent PBI and does not claim human code approval.

  4. MariusStorhaug commented on Oct 31, 2026

    @MariusStorhaug
    Marius Storhaug (MariusStorhaug)
    on Oct 31, 2026
    MemberAuthor

    Independent applied-rule verification

    Observed from the separately coordinated scaffold session 76cee94d-69f3-43a9-8c92-4ffc79fff360 at 2026-10-31T15:27:05Z, with follow-up reads through the same verification window. gh api user confirms the linked MariusStorhaug account. This session did not apply the rule or implement the validation code. The user explicitly approved separate execution/verification sessions using this same account; this is not a second human identity, human code approval, or a merge attempt.

    Item Independently observed evidence Result
    Applied target Ruleset 26275706 is active, Repository-sourced from PSModule/.github, with only refs/heads/main included and no exclusions. Its only rule is required_status_checks. Exact approved main-only scope
    Context and source The one required context is exactly Community file validation, bound to integration 15368. Native check 124575660196 reports app 15368, slug github-actions, name GitHub Actions. Exact context/source; not any source or the Copilot check
    Strictness and bypass strict_required_status_checks_policy: true, do_not_enforce_on_create: false, bypass_actors: [], and current_user_can_bypass: never. Strict up-to-date requirement and no added bypass
    Main application GET repos/PSModule/.github/rules/branches/main includes the additive requirement and the five inherited rules from organization ruleset 19735208. Applied, not only a configured proposal
    Non-target controls Both community-validation-scope-control and this session's psmodule-pr-defaults return no required-status-check rule from the applied-branch API. No observed expansion beyond main
    Preserved review constraints Inherited PR rules retain squash-only merges, stale-review dismissal, required code-owner review, extra approval for unattributed changes, last-push approval, and thread resolution. The existing approving-review count remains 0; no new reviewer list is added. Deletion, linear-history, non-fast-forward and Copilot-on-push rules remain unchanged. Existing constraints preserved; this audit grants no review approval
    Current code candidate PSModule/.github#86 head a009b6216d7eed833383698035c6a1f467fc494e has completed successful named checks from the required integration. Run 41214354370 is pull_request, not dispatch, and its run/job/check head SHA agrees with the current PR head. Actual current-head positive case
    Freshness Both inspected PRs include current main f424237c98b5b020f80e8c9563dbc37256fc1ec0; GitHub compare reports behind_by: 0. Prior successful code checks on 66cd708ebf9270f264dd86f33b2bcee65d10c9fd are identified separately rather than reused as current evidence. Current code check and base freshness agree
    Draft and non-empty execution The code PR is draft, with no ready-for-review/convert-to-draft events in the inspected timeline. Its immutable workflow .github/workflows/Validate-Community-Files.yml has normal main-targeting pull_request triggers, no path or draft filter, actual-head checkout, and no skipped validation job. The current run records 21 passing fixture tests and Checked 10 Markdown files; result: passed, explicitly listing .github/pull_request_template.md and .github/CONTRIBUTING.md. Real draft PR-event scan, not an empty or skipped pass
    Independent scaffold PSModule/.github#82 remains draft at 90aee54bd9df1f3a716a5fb8a0707ccba4b56f22. Its native head checks contain only the Copilot review, not Community file validation; GitHub reports mergeable_state: blocked. Required file-validation evidence is absent; not ready

    Observable limits: all 11 inspected native validation PR-event runs are completed successes. No live failed or pending validation check, unexpected-app same-name check, or base-outdated current candidate was available for an independent causal rejection experiment. No failure/check injection, workflow dispatch, policy mutation, or merge attempt was performed. The configured required-check/source/strictness semantics and latest-SHA requirement reject those mismatched states, but this record does not claim a witnessed merge denial for them. The blocked scaffold with an absent required context is observable, but its draft and review constraints are also blockers; it is not an isolated experiment proving which rule alone caused blocked.

    The validator's existing anonymous fixture results demonstrate malformed, empty, missing-path, symlink and head-metadata rejection inside a successful job. They are not injected live GitHub failed/pending/stale-check tests and were not executed by this verification session. The run validates the unchanged central legacy scaffold in the code PR; it does not prove the independent new scaffold has run under the integrated workflow.

    Inheritance boundary: the two named inputs are the source community-default files owned by PSModule/.github, not a requirement for ordinary module repositories to add local copies. The rule is scoped only to this repository's main. The user's clarified organization inheritance policy is preserved.

    Readiness and ownership: the exact named-check/source and strict freshness conditions are observed satisfied on the current code candidate; overall code PR readiness/review remains its owner's responsibility. Task #85 stays open for the unavailable live cases/remaining verification and, after normal code integration, a refreshed current-head PR-event run on the separately owned scaffold. Native code Task #84, this operational Task, and parent PBI #83 remain distinct and open. The governing MSXOrg/docs#209 is now ready but unmerged at 27ffab8ad89cf41147dc25ba2f6bd300b01b938f; its complete scaffold is unchanged from the last requested 1ececb2bd9f1680c87cec15a45ac927a554fce9c pin and still matches the local scaffold. Nothing in this audit closes the aggregate or authorizes a merge.

    Read-only reproduction: gh api repos/PSModule/.github/rulesets/26275706; gh api repos/PSModule/.github/rules/branches/main; the corresponding applied-rule calls for both non-target controls; gh api repos/PSModule/.github/commits/a009b6216d7eed833383698035c6a1f467fc494e/check-runs; gh api repos/PSModule/.github/actions/runs/41214354370; and gh run view 41214354370 --repo PSModule/.github --log. All returned the evidence summarized above. GitHub's status-check guidance defines latest-commit, eligible-event and expected-app behavior; the observed run is a completed success with real validation steps, not a dispatch or skipped-job substitute.

  5. MariusStorhaug commented on Oct 31, 2026

    @MariusStorhaug
    Marius Storhaug (MariusStorhaug)
    on Oct 31, 2026
    MemberAuthor

    Head advance and code-readiness hold

    Follow-up observation at 2026-10-31T15:34:03Z: code PR #86 advanced from the earlier verified a009b6216d7eed833383698035c6a1f467fc494e to 6609aa54978b84680b0166ffa3cd5cc8e5994abc. The earlier successes are prior-head evidence, not reused as fresh checks. Native run 41215351580 independently reports a completed successful Community file validation check 124578606609 from app 15368 on the advanced SHA, triggered by pull_request; run, job/check, and PR head identities agree. The advanced candidate still includes current main with behind_by: 0. Its workflow is unchanged by the head advance.

    A passing check is not corrected-validator containment evidence or code-readiness approval. The coordinator relayed a reproduced parent-directory junction/symlink boundary defect and a test-first correction in the separately owned code delivery. Retain that explicit readiness hold and require the fresh reviewed corrected candidate for subsequent operational/scaffold milestones; pre-fix success is not sufficient. This verification records the applied rule/context/source and observed check identity, not a second review or signoff of the containment correction.

    Task #85 and parent PBI #83 remain open. The independent scaffold head still has no required named result and must receive its own fresh PR-event check after normal integration. No code, workflow, policy, check result, merge state, cleanup or approval was changed by this session.

  6. MariusStorhaug commented on Oct 31, 2026

    @MariusStorhaug
    Marius Storhaug (MariusStorhaug)
    on Oct 31, 2026
    MemberAuthor

    Observed at 2026-10-31T16:03:43.4362575+00:00 from the separate scaffold verification session.

    Reviewed correction and ready-event evidence

    The earlier code-readiness hold in this audit trail is resolved, not a current blocker. Independently re-read PSModule/.github#86 at 6609aa54978b84680b0166ffa3cd5cc8e5994abc: it is non-draft, unmerged, and has no auto-merge. The ready-for-review timeline event is 2026-10-31T15:46:36Z.

    The complete head-bound review 5723598524 is COMMENTED on that exact SHA and reports No open issues. Its generic caution that symlink resolution and dependency exclusions warrant human assessment is explicitly retained. The reproduced outside-parent junction/symlink regression was corrected at this reviewed head; do not continue reporting it as unfixed or carry the previous fresh-review hold forward. This review is automated code-feedback convergence, not a human approving review or a claim that this verification session reimplemented/reviewed the validator.

    Run 41216458562, created immediately after the ready event, is a real pull_request execution of .github/workflows/Validate-Community-Files.yml, not dispatch. Its native check 124581888168 is named exactly Community file validation, app 15368, completed successfully at 2026-10-31T15:47:04Z, and bound to the same current head. The logged checkout/head guard agrees with that SHA. npm run validate reports 23 passing fixtures, including rejection of Markdown reached through a parent link outside the repository, and a real non-empty 10-file Markdown scan. The other current-head validations are also successful. Earlier-head green results are not reused as corrected-candidate evidence.

    The additive main-only rule 26275706 remains active with exact context/app, strict freshness, no bypass and no changes by this verification session. Code PR #86 and canonical MSXOrg/docs#209 are not integrated; repository main remains f424237c98b5b020f80e8c9563dbc37256fc1ec0. Scaffold PSModule/.github#82 remains draft at 90aee54bd9df1f3a716a5fb8a0707ccba4b56f22 and still has no native Community file validation result.

    Operational Task #85 stays open for the remaining verification and the scaffold's own refreshed current-head PR-event check after actual authorized normal integration. No live failed/pending/wrong-source/base-stale causal rejection case was injected or witnessed; those earlier limits remain explicit. No integration, merge, check manipulation, policy change, cleanup, auto-merge or second human approval is performed or claimed. Both the independent verifier and execution owner use the linked account, under the user-approved separate-session arrangement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Task

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions