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

What is a repository environment?

It is 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. Fletcher, the QA Worker, is what uses it. Fletcher 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.

The environment belongs to the Team, because that is where the repositories and the review norms already live.

How do you set one up?

1. Attach the repository to the Team. Workers reach repositories only through the workspace GitHub App installation you set up in Connections. If the installation covers the repo, the Team can run it.
2. Run 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, and the variables it reads. Edit anything it got wrong; the point is to skip the blank form, not to guess for you.
3. 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 manifest recording what actually ran. Each carries its own variables and services.
4. Add secrets and choose the auth mode. Store what the app needs to boot, then pick how a test session signs in. Google sign-in with a dedicated test user is supported today, and other modes are available on request.
5. Validate once, then let it run. The environment boots clean, and after that Fletcher uses it whenever a pull request on the Team’s repositories changes.

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 test cases follow the Team’s membership and its privacy setting, the same way the rest of its record does. A restricted Team’s videos are 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. If your app is hard to stand up from scratch, say so on the call: that shape is exactly what the work is aimed at.