GitHub App

The DACIP GitHub App runs the contract gate on every pull request. It is a thin wrapper around the same deterministic engine as the CLI: it clones your PR, runs dacip diff between the base and head refs, and reports what the PR introduced. No LLM anywhere in the pipeline — every claim is re-derivable from the two refs.

What happens on each PR

On every push to a PR, the App:

Clones the repo (shallow) and checks out the head commit.
Runs dacip diff against the PR's base ref — so findings are strictly what this PR introduced, not pre-existing debt.
Sets a check run named dacip/contract-gate. It fails only if the PR introduced at least one contract break.
Posts one PR comment with the findings — file, line, and a runnable repro command for each. When you push a fix, the same comment is edited in place: fixed findings move into a collapsed "Fixed by this PR" section and the check flips to green. One comment for the PR's lifetime, never a thread of bot noise.
Uploads SARIF to GitHub code scanning, so findings also appear in the repo's Security tab.

If your PR is clean, the App is silent: a green check with a one-line summary, no comment. You will never get an "LGTM" from a bot.

Every comment includes a coverage block — how many routes were resolved, how many calls were matched, and what DACIP could not see. Absence of findings in code DACIP couldn't parse is not the same as "clean", and the comment says so.

If the engine itself errors, the check goes neutral with the error stated — the gate fails open, loudly, rather than blocking your merge on a tooling problem.

Diff semantics

The gate compares the PR's base and head refs directly. After a PR merges, a push to the default branch refreshes the stored baseline, so the next PR again shows only its own new deltas. Same head SHA plus same engine version produces byte-identical output, which is what makes the edit-in-place comment idempotent.

One job runs per repo at a time; if you push again while a job is queued, the newer head SHA supersedes it. Jobs have a hard 5-minute budget; typical runs finish well under 90 seconds.

Clone lifecycle and what is stored

Repos are cloned shallow, per job, and the clone directory is deleted when the job ends. No source code survives a job.
The App never runs npm install or any other code from your repo — the analysis parses source, it does not execute it. Not installing dependencies from untrusted PR branches is deliberate.
What persists per installation: finding fingerprints and statuses, coverage stats, run metadata. Never stored: source code, diffs, or file contents. See the privacy page for the plain-language version.

Permissions requested: contents: read, pull_requests: write, checks: write, security_events: write (for SARIF).

Configuration

For monorepos, commit a .dacip.yml at the repo root:

scope: all            # or backend / frontend
include: ["api/**", "frontend/src/**"]
max_findings: 10

It is committed and reviewable, same trust posture as the baseline file.

Seats and metering

Team is $15 per active contributor per month: a unique GitHub login that authored at least one PR DACIP gated in a private repo of the installation, within the UTC calendar month. One person active across five repos is one seat. Bot logins ([bot] suffix, plus dependabot, renovate, github-actions) never count. Public repos never count.

If a new contributor pushes you past your purchased seats:

Their PR is still gated normally — the product is never degraded silently — and a 14-day grace window starts.
During grace, a one-line notice is appended to the existing PR comment: seats: 12 active this month / 10 purchased — grace until <date>.
After grace expires, already-counted contributors keep full gating. PRs from new logins get a neutral check reading "seat limit reached — this PR was not gated". An ungated PR is always visibly ungated — never a fake green.
DACIP never auto-charges, never disables the installation, and never blocks merges over billing state.