Validate stacked pull requests before consolidation #96

Superseded

Closed unmerged on 2026-09-16. Focused WebScene work now targets main directly or uses native GitHub stacks whose dependent pull requests target the preceding focused branch. GitHub's native stack execution supplies cumulative validation for dependent layers without adding the temporary consolidation branch to repository workflow allowlists.

Current evidence: native Stack #170 is #166 → #169 → #161. The top layer #161 targets #169 and started exact cumulative CI run 35132417195 and NuGet-package run 35132417202. Earlier dependent layers in Stacks #156 and #164 were also qualified and merged through the native stack path.

Draft consolidation PR #76 already targets main; it remains open, draft, and unmerged. Its branch is no longer a base for focused integration work. Adding that branch to permanent workflow triggers would retain superseded review infrastructure and consume runner capacity without closing a current validation gap.

Problem

Pull requests stacked on a consolidation branch do not receive the repository’s required full validation. CI.yml and native-runtime-packages.yml only match pull requests whose base is main or release/*. As a result, focused pull requests targeting feature/code-oss-browser-compatibility skip full CI, and native runtime/package validation is skipped even when a focused change touches runtime packaging inputs.

This creates a validation gap before the focused commits are consolidated. The failure is in the base-branch event filter, before any path filter is evaluated.

Proposed fix

• Add feature/code-oss-browser-compatibility to the pull_request.branches allowlist for full CI and native runtime/package validation.
• Keep push triggers unchanged (main, release/*, and release tags as currently configured).
• Keep NuGet publishing disabled for pull requests. A stacked pull request should build, test, pack, and verify artifacts only.
• Add a repository policy regression that checks the stacked base, trusted push/release triggers, and publish guard.

Acceptance criteria

• An internal pull request targeting the consolidation branch starts full CI.
• Runtime-affecting changes targeting the consolidation branch start the native runtime/package workflow.
• Pull-request runs cannot publish packages.
• Main and release validation/publishing gates remain unchanged.
• Workflow syntax and policy regressions pass locally and in CI.