Repository navigation
[RSI Baseline] Validate clean-repository bootstrap and end-to-end autonomous release #792
Description
Parent Epic: #784
Why
The final acceptance criterion is portability: a clean FlyBot deployment must onboard a new repository and run the workflow without Grok Bot or hidden state inherited from the original FlyBot repository.
Scope
- Start from a clean cloud machine or documented reproducible environment.
- Install FlyBot Runtime and a pinned Repository Engineering capability-pack version.
- Configure least-privilege GitHub access, a cloud Runner and a supported Code Agent.
- Bootstrap repo policy: default branch, test/build/lint commands, required checks, risk policy, changelog/release convention and human approval boundaries.
- Run a real, low-risk pilot Issue through implementation, regression test, PR, independent review, CI, merge queue, release and post-release artifact verification.
- Populate dashboard records and capture a complete evidence bundle.
- Test a failure/restart path and confirm no duplicate PR or release is created.
Acceptance criteria
- Grok Bot is not needed to triage, coordinate or advance the pilot.
- No undocumented old-project state is required.
- Every state transition has supporting evidence and appears on the dashboard.
- The published release points to the expected commit and contains verified artifacts.
- Manual intervention is recorded and remaining automation gaps are listed.
Dependencies
Requires E2, E3, E4, E5, E6 and E7 to be sufficiently implemented for the acceptance path.
Dedicated automation identity
- Configure a repository-scoped GitHub App or other explicitly approved bot identity with least privilege; do not reuse a maintainer's personal GitHub token for routine writes.
- Demonstrate that the new repository can authorize/revoke the automation identity without inheriting credentials or secrets from the original FlyBot repository.
- Verify which operations the identity can perform under the repository's actual branch protection/ruleset and merge-queue configuration. Do not assume a Bot review automatically satisfies GitHub's required human-review rules.
- Preserve a documented human approval path for App installation, permission changes and other explicitly sensitive operations.
Acceptance criteria additions
- The cold-start pilot completes routine Issue/PR/CI/release operations with the dedicated automation identity.
- The Developer cannot forge a Reviewer verdict; review evidence is tied to the exact tested head SHA.
- All required permissions, secrets, manual steps and remaining automation gaps are documented, and credentials never appear in prompts, logs or artifacts.
Activity
Birfy commentedon Oct 22, 2026
Written-by: Triage
enhancement|area:automation|area:release|needs-human. This is the epic's acceptance test and it is mostly an environment and grant problem, which is why it cannot beagent-readyon its own: it needs a clean machine, a Runner, a Code Agent and a second repository — none of which this repository can provision.It also inherits every open question from its dependencies:
#785(instance and access),#786(Runner/Code Agent choice),#787(envelope and state machine, which must be settled against#149),#788(what a pack may contain as code),#790(which fields) and#791(which metrics). Running it before those are answered would produce a pilot that proves the pilot.The part that can be made concrete now: the clean start is already documented (
docs/docker.md,Dockerfile,compose.yaml, and thev0.2.4tarballs), and the repository's policy that a pack has to install —AGENTS.md,.github/labels.json,.github/agent/, the workflows anddocs/testing-layers.json.To become
agent-ready: name the clean host, the Runner, the Code Agent and the pilot repository, and make the deliverable one evidence bundle with a fixed list of fields (each state transition, its source, its timestamp) plus the failure case — a restart that creates no duplicate PR or release. Everything else is the other children's work.