[RSI Baseline Epic] Build FlyBot as an Autonomous Software Engineering System #784

Activity

1. Birfy

   added

   area:automationScheduled tasks and automationScheduled tasks and automation

   enhancementNew feature or requestNew feature or request

   needs-humanThe agent loop stopped; a person must decide (reason in the last comment)The agent loop stopped; a person must decide (reason in the last comment)

   on Oct 22, 2026
2. Birfy commented on Oct 22, 2026

   

   Birfy

   on Oct 22, 2026

   Collaborator

   More actions

   Written-by: Triage

   enhancement|area:automation|needs-human, and not agent-ready — an epic is never agent-ready. AGENTS.md rules out a tracking/umbrella issue for that label, and this one is the umbrella: it has no single expected behaviour to verify and no bounded diff. The eight children can each be judged; this stays open as their index.

   Three things before the children are worth judging

   1. Language. AGENTS.md: "User-facing text in the plugin is English" and the repository's text rule is English for issues, PRs, comments, commits, changelog and docs. This body and all eight children are written in Chinese. I will not rewrite someone else's text, and it is not a reason to block the work — but every PR that lands from this programme has to be English, or the review will spend its time translating instead of checking.
   2. A large part of this already exists and works. The loop in your acceptance criterion ran today, on this repository, without Grok Bot: an issue (#779) was triaged and marked ready, a Bot claimed it, opened PR #783, a second Bot reviewed, the merge queue ran merge_group, and v0.2.4 shipped (177d0ffa, release 21:37Z, 39 changelog entries). So #789 (Issue-to-release) and #787 (orchestrator) are not greenfield: the gap is where that loop is manual and where its state is not durable, and each of those needs to say which step it replaces. A sibling issue that reimplements the loop as a second pipeline would leave two paths that disagree.
   3. Who is the author, and what may they write? These arrive from zy95-12 and ask for a running instance, cloud Runner access and repository write permission (#785, #786, #792). Nothing in this repository can grant that; the owner (Danyang / Birfy) has to decide who gets an instance, which Runner, and what may be written. That is why each child is needs-human rather than agent-ready.

   What each child has to answer before it can become agent-ready — that is the real triage work, and it is in each issue now. In short:

   • A named existing thing it extends or replaces ([Feature RFC] Agent inbox board: one place for tasks, approvals and failures (personal first, team second) #349 was closed by the Agent Inbox work, [Team] Persist a minimal collaboration task lifecycle #54 by the task lifecycle, Timeline: a team run report (digest) #582/Timeline: durable alerts (open once, resolve when cleared) #584 by the Timeline digest and alerts, Deployment step 1: official image and one isolated instance per person #352/Proactive reminders 3/3: 24/7 runtime and Slack/email delivery #355 by the deployment and 24/7 runtime) — otherwise it is a duplicate.
   • One expected behaviour an independent person can check, not a capability ("the dashboard").
   • Which of the existing gates it must not weaken: merge-gate, enqueue-guard, review-gate, the risk:T* recomputation, and the rule that only a person removes hold.

   Sub-issue structure. I linked the eight children to this epic as GitHub sub-issues rather than only as a bulleted list, so the board and the API can see the relationship. Please keep that link when new children arrive.
3. Birfy

   added sub-issues on Oct 22, 2026

   • [RSI Baseline] Provide a persistent FlyBot instance for integration experiments #785
   • [RSI Baseline] Add cloud Runner and Code Agent lifecycle adapters #786
   • [RSI Baseline] Implement a persistent autonomous task orchestrator #787
   • [RSI Baseline] Package Repository Engineering as a reusable capability pack #788
   • [RSI Baseline] Close the GitHub Issue-to-Release automation loop #789
   • [RSI Baseline] Build a project dashboard for autonomous engineering #790
   • [RSI Baseline] Define baseline metrics and controlled evaluation protocol #791
   • [RSI Baseline] Validate clean-repository bootstrap and end-to-end autonomous release #792