Hosted reviews

Install the GitHub App. Doomer reviews new and updated pull requests with hosted inference. You do not add a workflow file, run the CLI in CI, or store a model API key in the repository.

Setup is in Getting started. This page is what a hosted review does after a repository is enabled.

What Doomer runs

Each hosted review executes the official signed review/code package and the specialists it composes. The worker checks out the recorded base and head commits with a repository-scoped read-only token. Customer hooks, workflows, dependency installation, and build scripts are not executed.

Model calls use the provider and model a platform administrator configured for the project. That choice is not shown in project settings. Changing it is an admin action; an in-progress review is cancelled on the next lease check if the project is disabled or its inference settings change.

Review tracks choose whether that run is standard, adversarial, or both. Hosted reviews do not run a package you pick from the public catalog or from Private adversaries. Those packages are for the CLI and CI path.

When a review starts

GitHub notifies Doomer on opened, reopened, synchronize, and ready_for_review for an open, non-draft pull request in the same repository. Drafts do not run automatically, but an owner, organization member, or collaborator can comment /doomer run to request a review-only run. Installation and enablement do not backfill existing open pull requests.

Automatic reviews are on by default. Uncheck Automatic reviews for a repository in Repos to stop these event-triggered reviews and periodic reconciliation reviews while keeping /doomer run and explicit reruns available. The repository must remain enabled. Reviews already queued or running continue.

For each eligible event Doomer:

Queues one review for that base and head.
Creates a queued Doomer check on the head commit, then moves it to in progress when a worker claims the job.
Refreshes linked issue context when intent capture is enabled for the deployment. A failed issue fetch is shown as a source gap and does not block the code review. See Intent and provenance.
Runs the review.
Posts an informational GitHub review (COMMENT) and completes the check.

Webhook delivery is the fast path. Workers also reconcile repositories with automatic reviews enabled about every 15 minutes and enqueue the same deduplicated job if a delivery was missed.

A new commit cancels an in-flight job for the old head. The new SHA is reviewed on synchronize when automatic reviews are on; otherwise, request a review with /doomer run. Closed pull requests and drafts are cancelled before comments are published. Redelivered events for the same repository, pull request, base, and head do not start a second run.

GitHub Re-run on the App check queues that same check again after installation, repository, and entitlement are rechecked.

An owner, organization member, or repository collaborator can comment /doomer run on an open pull request, including a draft. Doomer replies that it queued the latest review or that one is already queued or running. A draft run posts only the informational check and review comments: it does not dismiss approvals, resolve earlier conversations, or enter automatic approval or merge evaluation. Marking the pull request ready starts a normal review, including when the commit SHA did not change. Contributor and other untrusted comments are ignored.

What lands on GitHub

Outcome	Doomer check	GitHub review
No findings posted	Success	Short review that no issues were found. When the model can phrase it, the note includes a brief compliment based on the diff.
Findings posted	Neutral	Informational review. Inline comments on the diff; other findings in the review body.
Review did not finish	Failure	No clean-review comment. A provider failure is a failed review for that commit, not a silent pass.
Findings exist but the posting threshold hides all of them	Not a clean pass	No “no issues” comment. The hidden findings stay on the Doomer review page.

Summary comments are on by default. Turning them off omits the aggregate assessment and still posts inline and off-diff findings. The posting threshold is separate. See Repos.

Comment wording follows PR comment voice. The finding does not change. See Overrides.

After a later successful review, Doomer resolves older App-authored threads whose finding identity is absent from the new result. Recurring findings stay open. That update needs Contents: write on the installation. Until an existing installation approves it, the review still completes and the check says earlier conversations could not be updated.

The review page

Open /review/<project>/<owner>/<repo>/<number>. While a review is running, the page refreshes. Sections:

Findings — the default page, including findings withheld because they are below the repository posting threshold.
Intent — inferred purpose and constraints, saved clarifications, and source coverage notes.
Impact — experimental service-map matches. A path match is possible impact, not proof that runtime behavior changed.
Attack paths — entry, path, possible impact, the finding used as evidence, and what is still uncertain. An empty list does not mean the change is safe.
Sources — linked issues, search coverage, and source gaps. Issue text is shown as source text, not as an approved statement of intent.
Provenance — Git AI notes for this head, when captured. The public review link (/review/...) does not include this section.

A failed review explains the likely cause and shows the run ID. Technical detail is collapsed. Runs (/team/<namespace>/runs) lists the same hosted jobs next to any CLI activity for the project.

Recommended: record code provenance

Developers can install Git AI so agent and model attribution is stored in refs/notes/ai. Doomer reads notes that were pushed for the pull request and shows the recorded agent and model on the review page. Missing notes mean provenance is unknown. They do not block the review, and Doomer does not use provenance to choose reviewers or approval.

Publish the notes ref if the page is empty but Git AI recorded notes locally:

git log -1 --show-notes=ai
git push origin refs/notes/ai

Use the remote that hosts the pull request. The push can include notes for other commits. If the remote ref moved, synchronize the notes and push again; do not force-push. Provenance is captured automatically with review context; there is no separate manual refresh action.

Capture supports up to 100 commits and needs Contents read on the App. Larger pull requests are still reviewed, without a provenance summary. Full behavior is in Intent and provenance.

Limits you will notice

One enabled project per installation. Training may link the same installation to several projects. Hosted reviews require exactly one project with hosted inference enabled. Extra enabled projects pause reviews until an administrator turns one off.
Forks. The pull request must target the repository the App is installed on.
No backfill. Open pull requests are reviewed on the next qualifying event, /doomer run, or the periodic reconcile.
Custom adapters are not served. Custom training does not change the model a hosted review calls.
Stampy is separate. Completing a review does not approve or merge unless Stampy Stamp allows it for that repository and those authors.