GitHub — the agent opens a pull request and never merges it

Finding something wrong with a page is the easy half. The hard half is that the fix has to end up in the repository that produces the page, reviewed by somebody who can say no. This integration is that half.

What it actually is

A first-party GitHub App. Not an OAuth app, not a connector brokered by a third party. You install it into your own account or organisation, GitHub holds the list of repositories it can see, and you can inspect or remove it from GitHub's own settings at any time without asking us.

That distinction has a practical consequence people trip over: the App does not appear in Attensira's list of connected applications and cannot be revoked from there. Revoking an OAuth connection has no effect on it, and uninstalling it has no effect on anything in that list. They are separate systems with separate controls.

Three permissions, and nothing else

Contents, read and write, so it can read the files behind a page and push a branch. Pull requests, read and write, so it can open one and read its state afterwards. Metadata, read, which every GitHub App requires and which lists the repositories you granted.

There is no Actions permission, no Administration permission, and no access to secrets. That list is short enough to check on GitHub's consent screen, and the documentation is explicit that if the screen shows you something outside it, you are not installing our App.

Four rules that make the diff trustworthy

The App never merges. It never pushes to your default branch. It never pushes twice to the same branch. And it never touches CI configuration, workflow files, or anything that changes how your builds run.

Taken together those turn the pull request into the whole surface of the integration. Nothing we do can change after you start looking at it, which means reviewing the diff is reviewing the final thing rather than a snapshot of something still moving. That is a stronger property than it sounds, and it is the reason the rules are absolute rather than defaults.

The cost of that guarantee is visible when something goes wrong. A red build or a merge conflict is surfaced on the inbox row and left there. We do not push a fix, because a second push would break exactly the property that makes the first one safe to review.

From finding to branch

The sequence is short. The agent identifies something to fix on a page. It locates the file that produces that page in one of the attached repositories — and where it cannot find the source, that becomes an inbox row saying so rather than a speculative pull request. It writes the change onto a fresh branch used once. Then it opens the pull request against your default branch, with a body naming the page, the finding and why this edit answers it, and applies the attensira label.

Where a project requires approval before an outward write, none of that reaches GitHub until you have given it.

Several repositories is the normal case

A marketing site, a docs site and the application itself are commonly three repositories, and a finding on a pricing page belongs in a different one from a finding on a quickstart. Attach all of them and each pull request goes where its page lives. This is the ordinary configuration rather than an advanced one.

After the pull request

Attensira keeps watching. Whether the pull request was merged or closed, and what your CI said about it, both come back onto the inbox row it came from. That closes the loop between something being proposed and something being decided, which is the piece that is missing when the output of an analysis tool is a document.