Repository navigation
[RSI Baseline] Add cloud Runner and Code Agent lifecycle adapters #786
Description
Parent Epic: #784
Why
Autonomous development and tests depend on cloud machines and the Code Agent installed on them. FlyBot must treat these as external, fallible resources with explicit lifecycle and state, rather than assuming an agent process or machine is always available.
Scope
- Define a provider-neutral Runner interface: connect/provision, health, execute, collect logs/artifacts, cancel and release.
- Define a Code Agent adapter: start task, query status, stream/poll events, cancel, retrieve result/evidence.
- Bind each run to a task ID, repository, commit SHA, workspace, environment/version and budget.
- Isolate workspaces per task; keep credentials out of prompts, logs and artifacts.
- Handle timeout, disconnect, host restart, duplicate requests, cancellation and stale callbacks.
- Persist execution state so FlyBot can reconcile remote state after restart.
- Record duration, retries, model/agent identity and cloud cost where available.
Non-goals
- Do not require one cloud vendor or one Code Agent.
- Do not let external agent text select arbitrary endpoints, credentials or tool permissions.
- Do not reimplement GitHub CI.
Acceptance criteria
- A fake adapter supports deterministic lifecycle tests.
- At least one cloud Runner + Code Agent path executes a harmless test task and returns evidence.
- Restart/disconnect/cancel cases have explicit tested outcomes.
- Per-task workspace and credential boundaries are documented.
Related
- [RFC] 跨运行时 Agent 对话与协作：以 OpenCode 为首个试点的目标、需求与两种方案 #198 cross-runtime collaboration
- Deployment step 1: official image and one isolated instance per person #352 isolated deployment
- Proactive reminders 3/3: 24/7 runtime and Slack/email delivery #355 24/7 runtime
GitHub automation identity
The autonomous path must not depend on a maintainer's personal GitHub credentials for routine repository operations.
- Prefer a repository-scoped GitHub App installation token for FlyBot automation; use only the minimum permissions needed for the configured repository.
- Keep GitHub identity/credentials separate from the cloud Runner and Code Agent process. Never place tokens in prompts, logs, artifacts or repository files.
- Document which component may create branches/PRs, comment, read checks, enqueue a merge, or publish a release. These permissions must be independently revocable.
- Keep the existing maintainer approval boundary for installing/configuring the App and granting repository access.
This issue defines the adapter and credential boundary; end-to-end PR/review/merge/release behavior is validated in #789 and #792.
Activity
Birfy commentedon Oct 22, 2026
Written-by: Triage
enhancement|area:automation|needs-human. It is a provider-neutral adapter layer with no chosen provider, so there is nothing to verify and nothing to bound: two people would build two different interfaces. That is a decision, not a task.For the PR that eventually lands, the useful anchor already in the tree is the scheduler and the turn machinery (
core/src/host/schedules.js,core/src/host/turns.js), which already own cancellation, restart recovery and per-Bot identity. A Runner adapter that invents a second notion of "task is running" next to those would give two sources of truth; the acceptance has to say which one wins.Before
agent-ready: name the first Runner and the first Code Agent (one each is enough), say what a task's identity is (task id + repo + SHA + workspace), and give the deterministic fake-adapter test as the deliverable, with the real one behind the owner's access grant (#785).