Skip to content

RFC: multi-Bot × GitHub — PR budget, task lock, decision card (not a new Git) #408

Closed

Description

@hsliuustc0106

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)

  1. PR budget

  2. Task lock

  3. Decision card before world-act

Acceptance

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

  1. Default caps (per Bot / per repo)?
  2. Who unlocks a stuck task lock: owner, assigner, or timeout?
  3. Does “draft PR” consume budget the same as ready-for-review?
  4. Webhook-first vs poll for PR state (cost)?

Process: implementation via OpenCode + Codex review.

Activity

  1. assigned and unassigned on Oct 19, 2026
  2. added
    enhancementNew feature or request
    area:automationScheduled tasks and automation
    needs-humanThe agent loop stopped; a person must decide (reason in the last comment)
    on Oct 19, 2026
  3. Birfy commented on Oct 19, 2026

    @Birfy
    Collaborator

    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?

  4. Birfy commented on Oct 19, 2026

    @Birfy
    Collaborator

    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:

    1. 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.
    2. 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.
    3. 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?

  5. Birfy commented on Oct 19, 2026

    @Birfy
    Collaborator

    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.

  6. removed
    needs-humanThe agent loop stopped; a person must decide (reason in the last comment)
    on Oct 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:automationScheduled tasks and automationenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions