Review a changeset

A review is a patch set an agent produced, waiting on a human verdict. This page follows the changeset for SUM-15, Marcus’s fix for the elevation profile rendering one pixel tall on Safari.

Open one

Reviews in the command palette, or /app/reviews. The list is filtered by verdict: pending is the queue, and the rest are history. Each row names the changeset, the repository it targets, and its status. Open takes you to the diff.

Read the diff

The header carries what the review is about, the task it came from, the repository and base branch it applies to, and whether checks were required.

Under it: the size of the changeset (files, lines added, lines deleted, comments), and then the files themselves. Each file shows whether it was added, modified, or deleted, its own line counts, and its hunks with the surrounding context. The first file is open by default; select a file’s header to collapse or expand it.

Comment

Each file carries a comment box while the review is pending. A comment is attached to that file, is visible to everyone reading the review, and stays with it afterwards.

Maya’s comment on src/elevation.ts asks for a regression check at zero height, which is the kind of thing worth saying in the review rather than in a new task: the agent has the context loaded right now.

Decide

1. Approve accepts the changeset as it stands. If checks were required and did not pass, approving needs an override reason.

2. Request changes takes a one-line summary and the instructions to work from. Both are sent to the agent’s task chat, so the next attempt starts from your feedback rather than from a status change.

3. Reject takes a reason and closes the changeset. Use it when the approach is wrong rather than the code.

Each decision is appended to the review’s history at the foot of the page, with who took it and when.

Promote

An approved review can be promoted: the platform creates a branch from the base ref, applies the patch set as a commit, and opens a pull request. The review then reads promoted and carries a link to the pull request.

Promotion is the only action here that touches your remote, and it is authored as CommandChain rather than as a person, so an automated change is never disguised.

Promotion needs a GitHub-backed repository

Opening a pull request goes through the GitHub App installation. A project pointed at a plain git remote can be reviewed, commented on, and approved, but promotion will report that the remote is not configured for pull requests. Merge that work through the meeting’s coding pipeline instead.

Reviews and run gates are different queues

A run gate asks before work starts. A review asks after it is finished, about what it produced. An agent whose class runs at L3 still produces reviewable changesets, because the question “may this run” and the question “is this code right” are not the same question.

Next steps

• Work the approvals queue: the before-it-starts decisions.
• Ship code from a meeting: repositories, branches, merge, and release.
• Connect repositories: what a changeset can be promoted into.