FixControl
GitHub integration

Patches delivered as PRs, reviewed by your team

FixControl reads repo and branch context, writes a patch, and opens a pull request with the diff and the evidence behind it. Merging and deploying stay with your team.

PR delivery onlyYour team mergesHealth per capability
What it does

From ticket to pull request

Repository & branch context

FixControl reads repository and branch context before proposing anything, so a patch is based on the code as it is. Reads stay scoped to the bound project and tenant.

Proposed pull requests

Where the GitHub App is installed, FixControl opens a pull request carrying the proposed patch. It opens PRs; it does not merge them.

Diff & evidence

The change lands as a normal PR diff with its supporting evidence attached. An engineer reviews it the same way they review any other PR.

Human merge & deploy

Merging and deploying are decisions your team makes in your own tooling. FixControl’s delivery ends at the open pull request.

Scoped permissions

The App acts only within the permissions you grant when you install it. Nothing outside the installation is reachable.

Evidence & audit

Opening a PR is an attributed, recorded action, so the repository history and the decision ledger line up.

Capabilities & health

Read health and write health are tracked separately

Repo read can be healthy while PR creation is not — the App may be installed on some repositories and not others, or with narrower permissions. FixControl probes each capability and reports it on its own.

Read repo & branch context
Supported

Reads repository and branch context within the bound project and tenant.

Open PR with proposed patch
Configuration-dependent

Requires the GitHub App installed on the target repository with permission to open pull requests. The write dispatches through the integration outbox.

Diff & evidence on the PR
Supported

Each proposed change ships as a reviewable diff with its evidence, on the PR itself.

Merging or deploying on its own
Not available — by design

Not a capability FixControl has. Delivery is PR-only; merge and deploy remain human actions in your own workflow.

A blanket ‘connected’ status
Not available — by design

Not shown. Repo read and PR-open are probed and reported separately, so a broken write path is visible.

When a PR fails to open

If the PR can’t be opened, you’ll know

One queue for every GitHub write
PR creation dispatches through the integration outbox: retries on transient errors, dead-letter on persistent ones, and a visible entry on the operational timeline either way. A person reviews the diff and merges; the approving decision is stored in the decision ledger with actor, role, channel, evidence, and consequence.
FAQ

GitHub questions

Does FixControl merge pull requests or deploy on its own?+
No. FixControl opens a pull request with the proposed patch and stops there. Merging and deploying happen in your workflow, by your team.
What does FixControl need to open a PR?+
The GitHub App installed on the target repository, with permission to open pull requests. If the App isn’t installed there, repo read may still work while PR-open reports unavailable.
How does an engineer review a proposed change?+
As an ordinary pull request: a diff, plus the evidence that produced it. Review happens in GitHub with your normal process.
What happens if opening a PR fails?+
The attempt stays in the outbox and retries; a persistent failure dead-letters and shows on the timeline. The PR either exists or the failure is visible — there’s no third state.
Are actions on GitHub audited?+
Yes. The decision that authorized the PR is in the decision ledger, and the PR itself is in your repository history. The two records match.

See a proposed PR land in your review queue

Book a demo: a ticket becomes a patch, the patch becomes a PR, and the approval trail is there to read.