Skip to content

docs(merge-policy): explain why PR Governance / Canonical issue and evidence are absent from gate 2 #1766

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
Copilot wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

docs(merge-policy): explain why PR Governance / Canonical issue and evidence are absent from gate 2 #1766

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ed70f4c
Initial plan
Copilot Sep 8, 2026
5777d80
docs(merge-policy): document PR Governance/Canonical issue topology r…
Copilot Sep 8, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions MERGE_POLICY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -123,6 +123,23 @@ weakening introduced by the rewrite that set out to make this gate precise.
> above. Selecting the capitalised one requires a check that never passes —
> precisely the trap the confirmation rule below exists to catch.

> **`PR Governance` / `Canonical issue and evidence` (#1436).** Neither name
> appears in the required list above, and that is deliberate, not an
> omission. `pr-governance.yml` was the sole source of both check-run names,
> and on its escape paths (draft PRs, Dependabot) only its own custom
> `PR Governance` check reported the honest `neutral`; the job-level
> `Canonical issue and evidence` check still reported `success`, because the
> escape never called `core.setFailed`. Requiring the descriptive-sounding
> `Canonical issue and evidence` name alone would have made every draft and
> every Dependabot PR read as "contract satisfied" instead of "not
> evaluated" — the exact trap the confirmation rule below exists to catch,
> and worse here because nothing in the picker hints which of the two names
> carries the real signal. The workflow was retired outright (#1665) rather
> than fixed, so the trap no longer exists to fall into. If a canonical-issue
> gate is reintroduced, whichever check carries the three-state signal must
> be the one required, and that must be spelled out here before it is added
> to branch protection — not discovered afterward on a green draft PR.

**Conditionally required — never require these unconditionally:**

- `Generate and Upload Coverage` — does not run on documentation-only changes.
Expand Down