Integration guide

Build with GitHub and keep repository work reviewable

Build with GitHub and keep repository work reviewable means treating the provider as an authorised external system—not a decorative logo. Xroga reports what the connected account allowed and what evidence the operation returned.

Illustrated repository review workspace with files, checks, and a side-by-side diff
Public product illustration of repository review state; no customer or private repository data is shown.Evidence verified September 22, 2026

01

What belongs in the project

Keep code, configuration names, and provider-facing adapters reviewable in the repository. Keep secret values in the provider or deployment environment.

02

What must be verified

Confirm permissions, environment selection, failure behaviour, and the user-visible result. A successful API response and a working product are separate checks.

03

What Xroga will not assume

Xroga does not invent credentials, bypass provider policy, or report a deployment or integration as live without evidence from the authorised account.

04

Direct answer: how Xroga works with GitHub

Xroga works against the repository and branch the user actually authorised. It reads the remote state, prepares focused changes, runs applicable validation, and uses the atomic write path only when write authority is explicit. Repository access does not imply permission to merge or deploy.

05

At a glance

Repository identity, selected branch, expected remote state, validation evidence, and resulting commit identity remain separate facts. If the remote branch changes during preparation, Xroga must re-evaluate rather than silently overwriting that change.

06

How the Xroga boundary works

The user authorises GitHub server-side. Xroga resolves the active repository and actual selected branch, reads the remote state, prepares focused changes, and uses atomic write controls. A successful write is reported with remote commit evidence; protected branches and organisation policy remain authoritative.

07

Common failures and limitations

These blockers are provider or policy evidence, not reasons to claim the work was published. Merging and production deployment remain separate decisions.

  • Repository or organisation not granted to the GitHub app.
  • Selected branch does not exist or is protected.
  • Remote HEAD changed while a write was being prepared.
  • Token scope permits reading but not the requested mutation.

08

Next action

Connect a repository you control, select the intended branch, and begin with a focused task whose changed files and checks can be reviewed.

Primary sources

Product capabilities change. These official pages were used for the factual statements above; verify them again before making a purchasing decision.