Skip to content

[RSI Baseline] Implement a persistent autonomous task orchestrator #787

Closed as not planned

Description

@zy95-12

Parent Epic: #784

Why

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.
  • Expose a read API/event stream for the dashboard.

Acceptance criteria

  • Deterministic state-machine tests cover success, duplicate event, timeout, retry, cancellation and restart recovery.
  • No task advances based only on an LLM claim when GitHub/Runner evidence is available.
  • Hold, permissions and repository branch protections are respected.
  • A low-risk test Issue can advance to an open PR without Grok Bot orchestrating the flow.

Related

Activity

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

    @Birfy
    Collaborator

    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-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.

  3. Birfy commented on Nov 7, 2026

    @Birfy
    Collaborator

    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.

  4. Birfy commented on Nov 7, 2026

    @Birfy
    Collaborator

    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_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.

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 requestneeds-humanThe agent loop stopped; a person must decide (reason in the last comment)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions