How do you set up a repository environment so Fletcher can test a pull request?

What is a repository environment?

The recipe for booting your app in a sandbox: a primary repository, the dependency repositories it needs to run, the commands that install and start them, the services they talk to, and the variables and secrets they read. Two Agents use it. Wright builds in it, so a plan is implemented against an app that runs. Fletcher, the QA Agent, boots the app at the exact revision of a pull request, writes a test plan from the change, walks the app in a browser, and attaches the video, the screenshots, and its verdict.

Environments live under Connections, one per repository, and the Team that attaches the repository is the boundary for who may run against it and who may read the evidence.

How do you set one up?

1. Open the repository under Connections. It lists the repositories your GitHub App installation covers. Agents reach code only through that installation.
2. Click Begin setup. YAGNI reads the repository and fills in what it finds: the install and build commands, the run command and its port, the services the app needs (Postgres, Redis, MySQL), the runtime version the repository pins, and the variables it reads. Then it boots the app in a disposable sandbox. If the boot fails on something it can fix, it tries up to three repairs to the commands and services inside the same run and saves the configuration that worked. The page is a checklist: one row per stage, and a stage that stops carries its cause and its fix inline.
3. Answer what only you know. A run reads Needs you when it needs a secret, a destination to approve, or a configuration only you can change. Answer it and the run continues. Credentials, sign-in, and approved origins are always yours to confirm; nothing else waits for you.
4. Add the dependency repositories. A web app usually needs an API. Each dependency is its own component with its own pin: a fixed commit, or a branch re-resolved at the start of every run, with the record saying what actually ran. Each carries its own variables and services.
5. Choose the sign-in mode and let it run. A private sign-in with a dedicated test user, or Google sign-in. The first configuration that boots clean goes live on its own; only replacing a Working environment asks. From then on Wright builds in it, and Fletcher walks every pull request on the Team’s repositories that changes.

What do the four states mean?

Not set up: nothing has run. Setting up: a run is reading, booting, or repairing, and you can stop it. Needs you: the run stopped on something only a person has, named on the row. Working: the environment boots clean and Agents use it. A Working environment that runs no browser says so; Wright still builds in it.

Why pin the dependency repositories?

So evidence means something. A fixed pin is the default because a test video is only useful if you know what it ran against; a pull request reviewed twice should not silently change its backend between walks. Tracking a branch is the explicit choice you make when a repo needs to move with a shared staging line, and the run records the commit it resolved.

Who can run it, and who sees the evidence?

The Team is the boundary. Who may run against the environment and who may read the videos and screenshots follow the Team’s membership and its audience, the same way the rest of its record does. A members-only Team’s evidence is not browsable by the rest of the workspace.

What is still in development?

Running a frontend change against your deployed staging backend, instead of booting the API in the sandbox alongside it, is in development. Today the dependency repositories boot with the primary one. Java and repository Dockerfiles are not read yet. If your app is hard to stand up from scratch, say so on a call: that shape is exactly what the work is aimed at.