enable pull request limits

[don-petry]

https://github.blog/open-source/maintainers/how-pull-request-limits-are-cutting-down-the-noise/

[don-petry]

📋 Initiative planned by the BMAD Scrum Master (Bob).

Epic #505 — Enable GitHub pull request limits to cut automation-PR noise

5 stories created (inert — labelled initiative, NOT initiative:auto):

• [Phase 1] ADR: pull-request-limits mechanism + policy decision #506 (M) — [Phase 1] ADR: pull-request-limits mechanism + policy decision
• [Phase 2a] Encode the PR-limit config as a machine-readable single source of truth #507 (M) — [Phase 2] Encode the PR-limit configuration in the apply mechanism + tests
• [Phase 3] Apply path: enforce the limit on target repo(s) + tests #508 (M) — [Phase 3] Apply path: enforce the limit on target repo(s) + tests
• [Phase 3] Document the PR-limits standard + exemption rationale #509 (S) — [Phase 3] Document the PR-limits standard + exemption rationale
• [Phase 4] Measure the noise reduction (success-metric instrumentation) #510 (M) — [Phase 4] Measure the noise reduction (success-metric instrumentation)

Open questions for review:

• What is the final numeric pull-request limit, and which actors are exempt (e.g. first-party automation: dev-lead, auto-rebase, Dependabot)? Story 1 proposes candidates and the config is built parameterized; a human must confirm the value and exemption list before Story 3 enforces it on a live repo.
• What is the rollout scope - pilot the limit on a single repo (e.g. .github-private) first, or roll out org-wide via the central petry-projects/.github standards repo? This determines the apply path's target scope (Story 3) and the report's coverage (Story 5).
• [reviewability] All story references resolve in the .github-private checkout the planner used, but the planning context's repo is petry-projects/.github and that is where apply-plan.sh materializes the epic. Confirm which repo the automation scripts (apply-repo-settings.sh, list-prs.sh, .github/rulesets/) actually live in / will be edited in, so stories do not point dev-lead at paths absent in the target repo.

---

Review the epic and its sub-issue DAG, adjust as needed, then add initiative:auto to epic #505 to hand it to initiative-driver for auto-implementation.

[github-actions[bot]]

Enhancement: Pull Request Limits — Implementation Complete + Platform Update

Sharper Problem Framing

This idea has been fully implemented and shipped. The initiative (epic #505, stories #506–#510) is closed. The enforcement is live via scripts/lib/pr-limit-gate.sh with a signed-off org-wide cap of 50 concurrent open automation PRs, documented in standards/pr-limits.md and machine-readable in standards/pr-limits.json. A daily success-metric report runs via pr-limits-report.yml.

This enhancement documents what GitHub shipped since the original idea, confirms the implementation aligns, and identifies potential next actions.

Prior Art & Platform Update (June–July 2026)

GitHub shipped a native PR limits feature on June 17, 2026 (changelog), but it targets a different problem than what this org implemented:

Dimension	GitHub Native PR Limits	petry-projects Implementation
Target	External contributors without write access	Internal automation (dev-lead, auto-rebase, CI agents)
Scope	Per-repository setting	Org-wide soft ceiling
Mechanism	Platform-enforced hard block	Source-side admission gate (plg_admission_gate)
Exemptions	Write-access users auto-exempt	Dependabot, security labels, org admins (configurable)
Problem solved	Low-quality external/AI-generated spam PRs	Internal automation PR fan-out cost

Key insight: The native feature does not replace the org's source-side cap. It solves a complementary problem (external spam) that this org may also benefit from.

Also new — PR Dashboard GA (July 9, 2026): GitHub shipped a new pull requests dashboard with saved views, logical AND/OR filters, and a review-state filter. This could improve visibility into the automation PR queue that the pr-limits-report.yml currently surfaces as a CI summary.

Options for Next Actions

Option	What	Value	Effort
A. Enable native PR limits	Set per-repo PR limit for non-write-access users	Blocks external spam PRs (low risk for this org since most repos are org-internal, but useful for any public repos)	Low — repo settings toggle
B. Adopt PR Dashboard saved views	Create an org-wide "Automation PR Queue" saved view	Replaces or supplements the daily pr-limits-report.yml summary with a live dashboard	Low — UI configuration
C. Add per-source sub-caps	Configure per_source_caps in pr-limits.json for high-volume sources (e.g., dev-lead ~30 open PRs)	Finer-grained control; prevents one source from consuming the entire 50-PR budget	Med — config + testing
D. Close this discussion	Mark as complete — implementation shipped	Clean up the backlog	Trivial

Risks & Unknowns

1. Native PR limits have no org-wide toggle yet — must be set per-repo. GitHub has indicated org-level controls are under consideration.
2. The 50-PR cap has not been stress-tested during a compliance blitz — blitzes can generate 27+ issues in a day, which may spawn automation PRs that approach the ceiling.
3. PR Dashboard does not expose an API — cannot replace the CI-based pr-limits-report.yml for programmatic monitoring.

Recommendation

This discussion can be closed as complete. The core idea (enable PR limits to reduce noise) is fully implemented with a more sophisticated source-side approach than the platform's native feature. Consider enabling native PR limits on public repos (Option A) and creating PR Dashboard saved views (Option B) as low-effort follow-ons tracked separately.