Unblock required-workflow source repository PRs without weakening organization gates

[seonghobae]

Incident

The organization ruleset requires the OpenCode and Noema workflows sourced from ContextualWisdomLab/.github, and the ruleset also targets the .github repository's own default branch. A central bootstrap repair therefore cannot currently satisfy the two workflow contexts sourced from the same repository.

Exact example: PR #731, head c73ee47861fca21e6959ce80fdf57b434c715c9d.

• all eight repository-owned exact-head workflows have successful runs on the unchanged head: CodeQL, Semgrep, Security Scan, Python Security, OSV, Scorecard, Secret Scan, and SBOM;
• auto-merge is enabled;
• direct guarded merge reports: 2 of 15 required status checks are expected and New changes require approval from someone other than the last pusher;
• no OpenCode or Noema review/check was published after a fresh ready-for-review PR was opened on the exact head;
• comments requesting both reviewer Apps produced no review because their execution is workflow-driven.

GitHub's documented source-repository boundary

GitHub's ruleset troubleshooting documentation calls out required-workflow source repositories explicitly. For workflows intended to run through a ruleset, GitHub recommends choosing a deliberate source-repository configuration, such as adding an unconditional job condition, disabling the local workflow in the source repository, or disabling Actions there. It also recommends Evaluate mode or an authorized bypass for bootstrap situations where the required workflow cannot run.

Primary documentation:

• https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/troubleshooting-rules#supported-directory
• https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#using-evaluate-mode-for-ruleset-workflows

Required administrative decision

Choose and implement one fail-closed pattern for the .github source repository:

1. exclude only ContextualWisdomLab/.github from the organization required-workflow targets while keeping its direct CodeQL/Semgrep/Security/Python/OSV/Scorecard/Secret/SBOM checks plus independent review rules; or
2. put the required-workflow rules in Evaluate mode long enough to merge the validated bootstrap repair, then return them to Active after proving they execute; or
3. configure the source repository/local workflow behavior according to GitHub's supported-directory guidance so the same OpenCode/Noema contexts are actually emitted for .github PRs.

Do not synthesize statuses, remove independent review, or weaken the organization rules for target application repositories.

Acceptance evidence

• PR fix(ci): restore central review, security, snapshots, and hourly repair #731 publishes the exact expected OpenCode and Noema contexts on its current head;
• independent reviewer App approval is attached to that head;
• fix(ci): restore central review, security, snapshots, and hourly repair #731 merges through normal branch protection;
• newsdom-api#467 is then re-reviewed through the repaired central coverage path and merges without a manual bypass;
• the final configuration and rollback procedure are recorded in docs/org-required-workflow-rollout.md and covered by a contract test where repository-level configuration can be represented in source.

[seonghobae]

Fresh evidence on 2026-08-04: #731 is back on its clean exact source head c73ee47861fca21e6959ce80fdf57b434c715c9d. Seven of the eight direct PR workflows have a fresh successful run; the remaining CodeQL run is queued, while earlier exact-head CodeQL runs are successful. A guarded merge still reports New changes require approval from someone other than the last pusher plus four unsatisfied required contexts, including one expected ruleset workflow. GitHub's ruleset troubleshooting guidance also says ruleset workflows should not use cancel-in-progress; both current OpenCode and Noema entrypoints do. The source-repository configuration/evaluate-mode decision remains necessary before the clean bootstrap can merge without synthesizing statuses.

[seonghobae]

Fresh source-repository canary for the existing bootstrap/review deadlock, without changing ownership or requesting bypass.

Current protected central source: .github/main@24ee38b097dbfc1a895e1199ade48cff36431d05.
Current repair consumer: .github#897@4553da875f2799b39e1c89aeb89f552d9fb92564, Ready and mechanically mergeable against that exact base.

The product/security repair itself is exact-head GREEN: Security Scan 33141727347, dependency-review job 98753825077, checked out and verified the submitted head, the support probe succeeded, and the pinned Dependency review action executed success rather than being skipped.

The first remaining causal boundary is now the source-repository review path: required OpenCode run 33141725355, job 98755817116, fails closed because no authenticated APPROVED or CHANGES_REQUESTED OpenCode review is anchored to current head 4553da8.... The formal review inventory contains only predecessor-head OpenCode verdicts; none may transfer. A fresh @opencode-agent exact-head request has been posted on #897 and has not yet produced a current-head formal verdict.

RED acceptance for #732: an unchanged, technically clean .github source-repository PR can still reach the required OpenCode workflow with no current-head Reviews-API verdict, leaving the bootstrap repair non-integrable.

Smallest safe remedy/GREEN: make the supported central source-repository review/dispatch path emit a genuine exact-current-head formal verdict for 4553da8... (and the corresponding required context) under the existing reviewer identity and permissions. Do not synthesize a status, transfer a predecessor review, self-approve, use admin/ruleset bypass, or weaken the independent-review requirement. After that, refetch all current-head checks/reviews before any normal integration decision.