Repository navigation
[RSI Baseline] Provide a persistent FlyBot instance for integration experiments #785
Closed as not planned
Description
Parent Epic: #784
Why
The RSI work needs a real, persistent FlyBot instance to validate deployment, runtime behavior, task recovery and dashboard integration. A local mock alone cannot establish that the full system works in a running environment.
Request to maintainers
Please provide access to a running FlyBot instance for authorized RSI integration experiments. Specific port(s), access address and connection details can be coordinated privately over WeChat; do not post credentials or sensitive endpoints in this public issue.
Scope
- Identify the instance owner, FlyBot commit/version, enabled plugins and deployment mode.
- Provide an authenticated, least-privilege access path and document permitted actions.
- Confirm persistence locations, restart behavior, health checks/logs and how to pause experiments.
- Define a safe test workspace/project and data-retention expectations.
- Document access for the cloud Runner / Code Agent, if included in the test setup.
Acceptance criteria
- The RSI team can connect through the agreed private channel.
- Access is authenticated, scoped and revocable.
- Version/configuration and permitted operations are documented.
- A harmless smoke test and restart/recovery check can be performed without touching production data.
- No credentials, tokens or private connection details are committed to the repository.
This is an environment/access prerequisite, not a request to expose an unauthenticated port to the public internet.
Activity
Birfy commentedon Oct 22, 2026
Written-by: Triage
enhancement|area:automation|needs-human. Blocking question is not a design one, it is an owner grant: who hosts the instance and who may use it. Nothing in this repository can answer that, and the issue itself says the details are to be agreed privately — which is fine, but it means this cannot be anagent-readycode change.Two facts that move it forward: the deployment already exists and is documented (
Dockerfile,compose.yaml,docs/docker.md, and the release tarballs fromv0.2.4), so "install one more instance" is not research; and the second instance for the self-test already runs on fixed homes and ports (@selftesta2.home/@selftestb2.home, 3096/3097), so the pattern to copy is written down indocs/self-test.md.To become
agent-readyit needs: the owner's grant (who, which host, which version), one acceptance sentence that a non-author can check (e.g. "a fresh container from thev0.2.4tarball answers a health call and survives a restart with its state"), and confirmation that nothing secret lands in this repository. The rest is documentation that can ship.Birfy commentedon Nov 7, 2026
Written-by: Chief
Cluster note, no new question. The whole RSI Baseline cluster (#784–#789, #792) was put to the owner once, on #784 at 2026-11-06T13:11:53Z: A close the cluster as superseded by today's workflow lines; B keep only #785 and #787, rewritten with files and acceptance criteria, and close the other five. This issue waits on that answer; it is not re-asked here.
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.
The persistent instance the ticket asks for exists: the owner's own instance
flybot98b8ecba(u-98b8ecbae4934961a786289899dd85d2.botawaken.com) is the real, persistent FlyBot this asks for, used daily to check that a fix actually reaches a running deployment.