You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
RFC: multi-Bot × GitHub — PR budget, task lock, decision card (not a new Git) #408
Many Bots operating at once stress GitHub the forge, not Git the VCS: too many open PRs, review/CI queues, branch-protection races, notification storms, API list/poll cost. Numbers on PRs are fine; concurrent open PRs are the problem.
Scope (Now)
PR budget
Soft/hard caps: open PRs per Bot, per human owner, per repo.
Prefer push-to-existing PR over opening a second PR for the same task.
Opening a PR, force-pushing protected branches, merging, and mass-labeling count as world acts: require a visible decision card (owner/assigner) unless a standing grant covers that exact action.
Triage on main 7b9e90b, 2026-10-19 ~12:10 Asia/Shanghai: needs-human, not agent-ready. RFC. Question for the owner: adopt a PR budget and a one-issue-one-PR lock as repo policy (in AGENTS.md / routine), and if yes, which caps?
Triage 2026-10-19 18:03 Asia/Shanghai (main 245be0b). Concrete proposal for the owner to confirm:
Expected behaviour / scope (Now = policy, docs only): write the practice FlyBot maintenance already follows into AGENTS.md:
Task lock: claiming an issue = assignee + agent-working; one open PR per issue; follow-ups push to the existing PR. A stuck lock is released by the owner, or automatically after 24 h with no commits.
PR budget: at most 3 new agent PRs per maintenance run; no new development PRs while 6 or more agent PRs sit in awaiting-approval. Draft PRs count.
Decision card = the risk tiers we already have: T0/T1 merge via the merge queue without approval; T2/T3 need the owner's approval with an explicit GitHub review button (never a typed or relayed "approve"); Bots never force-push protected branches.
Later (not now): enforcing this in the controller (blocking a second PR on a locked issue), webhook-based PR state, an agent-native forge.
Question: (a) codify the current practice in AGENTS.md with the caps above, (b) also build controller enforcement now, or (c) park the RFC? Recommendation: (a). If (a), are 3 per run / 6 waiting the right caps?
Owner decision (2026-10-19 18:36 Asia/Shanghai): closing. The PR budget and task lock are already handled by the current label workflow: one PR per issue, locked by assignee + agent-working; at most ~3 new PRs per maintenance run; T2/T3 PRs get awaiting-approval and need the owner's GitHub approval; the live controller applies risk:T*; no force-push. No separate doc or controller enforcement needed for now.
Activity
Birfy commentedon Oct 19, 2026
Triage on main
7b9e90b, 2026-10-19 ~12:10 Asia/Shanghai: needs-human, not agent-ready. RFC. Question for the owner: adopt a PR budget and a one-issue-one-PR lock as repo policy (in AGENTS.md / routine), and if yes, which caps?Birfy commentedon Oct 19, 2026
Triage 2026-10-19 18:03 Asia/Shanghai (main 245be0b). Concrete proposal for the owner to confirm:
Expected behaviour / scope (Now = policy, docs only): write the practice FlyBot maintenance already follows into AGENTS.md:
agent-working; one open PR per issue; follow-ups push to the existing PR. A stuck lock is released by the owner, or automatically after 24 h with no commits.awaiting-approval. Draft PRs count.Later (not now): enforcing this in the controller (blocking a second PR on a locked issue), webhook-based PR state, an agent-native forge.
Question: (a) codify the current practice in AGENTS.md with the caps above, (b) also build controller enforcement now, or (c) park the RFC? Recommendation: (a). If (a), are 3 per run / 6 waiting the right caps?
Birfy commentedon Oct 19, 2026
Owner decision (2026-10-19 18:36 Asia/Shanghai): closing. The PR budget and task lock are already handled by the current label workflow: one PR per issue, locked by assignee +
agent-working; at most ~3 new PRs per maintenance run; T2/T3 PRs getawaiting-approvaland need the owner's GitHub approval; the live controller appliesrisk:T*; no force-push. No separate doc or controller enforcement needed for now.