Every open change of a Project in one list
Review state, checks, preview and the linked Task for each Change Request, including pull requests your developers opened by hand.
A Project connects one GitHub repository to your workspace. An agent works on the Task's own branch and opens a Change Request, so the request, the change and the decision stay together.
Works with GitHub through the GitHub App.
A reviewer who opens a diff cold has to guess what was asked. Here the branch is named after the Task, and the Change Request links back to it.
Connect GitHub once. A Project then points at exactly one repository in one Space, so work on morrow.shop stays in morrow.shop.
The draft branch takes the Task's id and title. Commits are pushed as the work happens and are never force-pushed. A later Run on the same Task continues on the same branch.
A green check on a pull request tells you little about what customers see. A Change Request keeps each stage apart and shows which one is true right now.
The checks GitHub reports, the review, whether it conflicts with the target branch, and a link to the preview of that exact version when the Project has previews set up. The diff is one click away in the repository.
Review requiredPublishing needs the publish permission in the Project's Space and applies to the version you opened. If the branch moved since, it is refused and you look again.
Merged, deployment awaiting verificationA merge alone proves nothing. The Change Request turns Published once a successful production deployment contains the merged commit.
PublishedThe request lives in the Task, the work in the Run and the result in the Change Request. Each one links to the other two.
Review state, checks, preview and the linked Task for each Change Request, including pull requests your developers opened by hand.
What was asked, who asked and what was decided along the way stay on the Task the branch is named after.
Ask another agent to review a Change Request at its exact version, or to resolve conflicts with the target branch.
Follow one decision from the spec to a scoped code change and its review.
A Project is the repository context: which repo, which default branch, which Space. A Task is one piece of work in it. A Task without a Project has no repository for an agent to work in.
GitHub repositories, through the GitHub App you install on your account or organisation. One Project points at one repository.
If its Role in that Space holds Publish Change Requests, yes. With the seeded Roles a Member does, person or agent. Give publish to the people who should decide. An agent without it asks, and the request waits for someone who has it.
Approving merges it. Your own pipeline deploys, and the Change Request shows Published once it sees a successful production deployment that contains the merge. Until then it reads "Merged, deployment awaiting verification".
No commit is dropped. The Run fetches the new head, replays its own commits on top and pushes again. If they cannot be replayed, they go to a recovery branch and the Run names it.
On a Work Machine you connect, in its own clone of the repository. Work Machines run on Linux today and macOS is in progress.
Give an agent one Task in it and review the Change Request that comes back. Free during the open beta.