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
[RSI Baseline] Implement a persistent autonomous task orchestrator #787
The repository documents an agent-driven workflow, but RSI needs FlyBot itself to receive work, advance it through durable states and recover after interruption without Grok Bot as a required coordinator.
Scope
Ingest GitHub Issue events or poll for eligible Issues; support maintainer-controlled ready/hold gates.
Persist task state, claim/owner, attempt number, task/PR/commit links, deadlines and last observed external state.
Implement explicit transitions for triage, ready, working, blocked, PR, review, CI, merge queue, released, failed and cancelled.
Coordinate worktree creation and the Code Agent adapter; observe PR, review and CI as external sources of truth.
Recover/reconcile after FlyBot restart, cloud disconnect or duplicate webhook delivery.
Apply retry/backoff budgets and stop for human decisions, security-sensitive changes or exhausted budgets.
enhancement|area:automation|needs-human. The scope overlaps three things that already exist, and the issue has to say which it replaces rather than adds:
#54 (closed) landed the persisted collaboration task lifecycle.
#149 (open, needs-human) is "task layer step 1 — responsible-owner authority, FLYBOT-TASK envelope, workBotId"; an orchestrator that defines its own envelope duplicates that one.
The turn machinery already recovers after a restart (core/src/host/turns.js, resume.js), and the Bot-wide scheduler is core/src/host/schedules.js.
The genuinely new part is the eligibility gate and the state machine over GitHub evidence: only a agent-ready issue may start (owner rule, 2026-10-22), and no transition may be taken on an LLM's claim when GitHub can be read. That half is worth a PR once the envelope question is settled with #149.
Acceptance that would make it agent-ready: the state list you already wrote becomes an enum with a test per transition, the duplicate-webhook and restart-recovery cases are deterministic tests, and the "no advance without evidence" rule is a test that goes red when the evidence read is removed.
Cluster note, no new question. Same RSI Baseline cluster question as #784 (asked 2026-11-06T13:11:53Z): A close the cluster; B keep only #785 and #787 rewritten with files and acceptance criteria. Option B names this issue as one of the two survivors. Waits on that answer.
Owner decision 2026-11-07 (Asia/Shanghai), option A: the whole RSI cluster is closed.
The epic's goal 2 — Issue → branch → implement → verify → PR → review → CI → merge queue → release — now runs as the daily workflow pipeline; #789's loop is closed in practice and #788's "capability pack" is, in fact, those workflow definitions. What is left here is a second design for a system that already runs, with no bounded diff anyone can verify, and the cluster has not moved since 2026-10-22.
Reopen only if the owner funds the RSI programme; then file a fresh ticket with named files and acceptance criteria rather than reviving this index.
A persistent orchestrator: track_tasks carries the durable card state and the workflow tool carries the run state, and both are what the rounds already use. A second orchestrator is the duplicate design this close is about.
Activity
Birfy commentedon Oct 22, 2026
Written-by: Triage
enhancement|area:automation|needs-human. The scope overlaps three things that already exist, and the issue has to say which it replaces rather than adds:#54(closed) landed the persisted collaboration task lifecycle.#149(open,needs-human) is "task layer step 1 — responsible-owner authority,FLYBOT-TASKenvelope,workBotId"; an orchestrator that defines its own envelope duplicates that one.core/src/host/turns.js,resume.js), and the Bot-wide scheduler iscore/src/host/schedules.js.The genuinely new part is the eligibility gate and the state machine over GitHub evidence: only a
agent-readyissue may start (owner rule, 2026-10-22), and no transition may be taken on an LLM's claim when GitHub can be read. That half is worth a PR once the envelope question is settled with#149.Acceptance that would make it
agent-ready: the state list you already wrote becomes an enum with a test per transition, the duplicate-webhook and restart-recovery cases are deterministic tests, and the "no advance without evidence" rule is a test that goes red when the evidence read is removed.Birfy commentedon Nov 7, 2026
Written-by: Chief
Cluster note, no new question. Same RSI Baseline cluster question as #784 (asked 2026-11-06T13:11:53Z): A close the cluster; B keep only #785 and #787 rewritten with files and acceptance criteria. Option B names this issue as one of the two survivors. Waits on that answer.
Birfy commentedon Nov 7, 2026
Written-by: Chief
Owner decision 2026-11-07 (Asia/Shanghai), option A: the whole RSI cluster is closed.
The epic's goal 2 — Issue → branch → implement → verify → PR → review → CI → merge queue → release — now runs as the daily workflow pipeline; #789's loop is closed in practice and #788's "capability pack" is, in fact, those workflow definitions. What is left here is a second design for a system that already runs, with no bounded diff anyone can verify, and the cluster has not moved since 2026-10-22.
Reopen only if the owner funds the RSI programme; then file a fresh ticket with named files and acceptance criteria rather than reviving this index.
A persistent orchestrator:
track_taskscarries the durable card state and the workflow tool carries the run state, and both are what the rounds already use. A second orchestrator is the duplicate design this close is about.