Repository navigation
Closed
Labels
area:automationScheduled tasks and automationScheduled tasks and automationenhancementNew feature or requestNew feature or request
Description
Related: #349, #401, #396, #397, #351. Competitor frame: Anthropic Scion (agent-scale source control) — learn principles, do not replace Git yet.
Why
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.
- Daily tag cadence (Release cadence: at least one tag per day, small and stable #351) stays the merge rhythm; budget is about open concurrency, not ship speed.
-
Task lock
- One issue → at most one open PR (same Bot or handoff with explicit unlock).
- Branch naming:
bot/<name>/<issue>(or equivalent); no shared scratch onmain. - Lock visible in Agent inbox / Needs-you ([Feature RFC] Agent inbox board: one place for tasks, approvals and failures (personal first, team second) #349).
-
Decision card before world-act
- 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.
- Relayed “approve” does not count (Safety: decision log for rejected options (tried but not used) #396 / safety RFC RFC: layered safety for always-on Bots (grants, action gates, visible channels, decision log) #386).
- Unexpected Bot-to-Bot coordination outside logged surfaces → Safety: detect unexpected Bot-to-Bot side channels #397.
Acceptance
- With N Bots running, open PR count stays under the configured repo budget.
- Opening a second PR on a locked issue is blocked or queued with a Needs-you item.
- A Bot cannot merge or force-push protected refs without a card (or recorded grant).
- Digest (RFC: merged Bot output digest and acceptance (reduce human orchestration load) #401) can list blocked/queued PR attempts with evidence.
Out of claim / Later
- Replacing Git with an agent-native forge (Scion-class): Later, only if merge/checkout volume actually breaks GitHub.
- Global merge-queue redesign, post-merge-only CI: discuss, not Now.
Open questions
- Default caps (per Bot / per repo)?
- Who unlocks a stuck task lock: owner, assigner, or timeout?
- Does “draft PR” consume budget the same as ready-for-review?
- Webhook-first vs poll for PR state (cost)?
Process: implementation via OpenCode + Codex review.
Metadata
Metadata
Assignees
Labels
area:automationScheduled tasks and automationScheduled tasks and automationenhancementNew feature or requestNew feature or request
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.