A change is in front of you because it is waiting on you. The review is drafted before you open it. Nothing reaches GitHub until you say so, and when it does it goes under your name.
An agent writes one JSON file into storage you already own.
That is the whole integration. There is no API, no upload and no notification. The agent writes into a folder on your computer or a bucket you control, and it is the only author of the file it wrote.
The path is derived, never listed.
The app asks GitHub which pull requests await your review, derives a path for each, and requests it. A pull request owns a directory, drafts/<owner>--<repo>-<number>/, with its draft at review.json and any media beside it. A missing file means nothing has been drafted yet. A draft left behind after its review request is gone is simply never asked for, so the queue stays accurate without anyone tidying it.
Every lens is shown, including the clean ones.
Each carries a line on what was actually checked. Hiding the clean ones makes a review look shorter and makes thoroughness unprovable. The difference between checked and clean, and not looked at, is the entire value of a review.
Drop what is wrong. Edit what is nearly right.
Findings are staged, not sent. A dropped finding is marked rather than deleted, so it can be restored and what the agent said stays readable. An edited one keeps the agent's original words alongside yours.
You post it, under your own name.
The verdict, the body and the findings you kept go up as one review. A tool that posts on its own behalf has quietly moved the accountability somewhere nobody agreed to.
Sections are whatever the agent decides they are. The app does not know what a review is made of and does not need to: it renders the sections it is handed, in the order given, and offers each as a filter over the findings.
A lens with nothing flagged is the most useful thing on the page.
An agent reviewing a schema migration can emit data loss, rollback and locking. One reviewing copy can emit tone and grammar. Nothing is declared in advance, and nobody has to bend a review into four fixed headings that were right for one codebase.
A finding is one comment on one line. It carries a path, a line, an optional badge, and a body written as it would be posted. It can carry a replacement for the line, which GitHub renders with an Apply button. Ordering is the agent's, so the most important one goes first.
QA evidence shows the change was driven, not only read. A recording of the app being exercised is a fact. A claim in a summary is a claim.
A draft can carry one paragraph on what was actually driven, and a scenario for each run: the route it drove, what it proves, a verdict, and a recording sitting beside the draft. A failing scenario is evidence rather than an error, and it is the most valuable thing a review carries, so it is shown first.
None of it is posted. It is there so you can see what was exercised before deciding how much of the review to trust.
A recording named by a draft has to stay inside the drafts directory. An absolute path, or one climbing out, is refused. A draft cannot make the app open an arbitrary file.
The app never writes to a draft. What you drop, edit, post, dismiss and read is kept in the app's own append-only log, one file per device, in the same storage the drafts came from.
Two things follow. The agent and the app can never race for the same bytes, so an agent is free to rewrite its draft while you are part way through reading it. And a second device folds the same log and picks up where you left off, because the log is yours and it is already where you keep things.
That is also why sync is sold as a client rather than as a pipe. The bytes ride storage you already own. There is no tier at which we hold your files.