Workboard-only PR merges: make maintainer admin-override the zero-infra default; deeper, make review-evidence a REQUIRED check so required_approving_review_count can be 0 (no token/App/bypass needed)

[henrik-me]

Summary

Adopting v0.12.0's workboard-auto-approve.yml in henrik-me/sub-invaders surfaced that the
whole "auto-merge a workboard-only PR" problem — and the need for a WORKBOARD_MERGE_TOKEN PAT or a
GitHub App — exists only because of how the review requirement is wired, not because the merge
genuinely needs a bot credential. Filing the design observation.

Where the "second reviewer" on workboard PRs actually comes from

• The harness review-evidence gates (read-only-gates / review-gates) already skip for the
  workboard-only label — the harness does not require a second review for workboard PRs.
• The requirement that does block merge is the GitHub ruleset pull_request.required_approving_review_count: 1.
• GitHub rulesets cannot path-conditionally waive that approval (no per-path review rules), and
  the built-in GITHUB_TOKEN cannot create an approving review (platform restriction).
• Therefore the only ways to merge a workboard-only PR are: (a) maintainer admin-override
  (bypass), or (b) a credential that can approve/merge (an App or a WORKBOARD_MERGE_TOKEN
  PAT). (b) merely automates (a).

Recommendation A — make admin-override the documented, first-class, zero-infra default

The workflow already degrades to "owner/admin must merge manually" when no App/PAT is present — but
the surrounding docs (OPERATIONS.md #369, the workflow header) read as if the App/PAT is the
intended path and admin-merge is a fallback. It's the reverse: maintainer admin-override is the
sanctioned, zero-secret path (the repo-admin bypass is already in every harness ruleset), and the
PAT/App auto-merge is optional automation for higher-volume / multi-maintainer setups. Please
frame it that way so consumers don't think a secret is required.

Recommendation B — the deeper fix: enforce review via a REQUIRED status check, then drop the approval count

Today the harness's review-evidence gate is NOT a required status check (in this consumer the
required checks are ci, harness-lint, harness-sync-check, js-tests, dotnet-tests,
e2e-local; read-only-gates is not among them), so it cannot substitute for the ruleset approval —
which is why the approval requirement (and thus the workboard bypass dance) exists at all.

If review-gates / read-only-gates were a required status check and the ruleset set
required_approving_review_count: 0:

• Content PRs would be hard-gated by the required review-evidence check (recorded independent
  review + Copilot engagement + threads-resolved) — arguably stronger than a human "approve" click
  that admins bypass anyway.
• Workboard-only PRs (which skip that gate via the label) would merge with the built-in
  GITHUB_TOKEN and no bypass, token, App, or admin at all.

This eliminates the workboard-merge problem entirely. It relates to #393 (shipping review-gates
contexts as required checks) and would let the harness enforce "workboard updates don't need a
second reviewer" natively instead of via bypass. It is a deliberate branch-protection posture change,
so it should be opt-in/documented.

Recommendation C — branch-pattern gap for maintenance PRs

The validate-and-approve branch patterns (cs<NN>/(claim|close|close-out),
workboard/cs<NN>-(claim|close|close-out), docs/file-planned-cs<NN>(-<slug>)?) don't cover ad-hoc
workboard-allowlist maintenance PRs (e.g. a standalone CONTEXT.md / LEARNINGS.md correction),
which then fail the branch-name check and require admin-merge. Consider a general maintenance pattern
(e.g. workboard/* or docs/*) or explicitly document that maintenance edits use admin-merge.

Context

henrik-me/sub-invaders adopted workboard-auto-approve.yml in CS21; the maintainer opted for
admin-override rather than provisioning a PAT. Related: #392/#393 (CI-gate architecture), #394
(workflow content findings).

[henrik-me]

📋 Triaged into planned CS91 — partial: CS91 covers Rec A (frame maintainer admin-override as the zero-secret default) + Rec C (bounded workboard/maint-* branch pattern). Rec B (make review-evidence a REQUIRED status check + drop required_approving_review_count to 0) is a deliberate branch-protection posture change tracked as a separate follow-up CS (per decision C91-5).

So this issue is only fully resolved once both CS91 and the Rec-B follow-up land — it will not be auto-closed by CS91 alone. Filed in #401.
Plan: planned_cs91…