Onboarding a repo: readiness, baseline, go-live
Onboarding a repository is one closed settings surface, slipstream_onboard, operated by an agent over the MCP server. Reading it always returns a fresh readiness report; writing it changes the go-live switches. Anything that turns production behavior ON requires explicit confirmation — anything that turns it OFF does not, so rollback is never gated.
Legend: readiness is report-only — a red score never blocks the platform; it tells you exactly what to fix before flipping switches.
The readiness report
Every slipstream_onboard read evaluates eight checks against the live repo and returns pass/fail with a one-line fix per check:
| Check | What it verifies | Severity |
|---|---|---|
| Allowlisted | The repo is enabled on the platform | blocker |
| Recipe | .slipstream.json resolves against the validating schema | blocker |
| Required check | The default branch requires RunsGreen pinned to the RunsGreen GitHub App (app id 4244269) | blocker |
| Private repo | The repo is private (trust boundary) | blocker |
| Zombie checks | Every other required check context actually runs — a required context that never runs wedges PRs | warning |
| Auto-merge allowed | "Allow auto-merge" is enabled in repo settings | warning |
| Merge commit allowed | The regular merge method is enabled | warning |
| CI baseline | A baseline of your previous CI has been frozen | info |
The rollup is red (any blocker fails), amber (any warning fails or is unknown), or green. The dashboard's fleet view shows the same readiness as a green/amber/red dot per repo. Readiness is informational by design: it never gates webhook intake, runs, checks, or deploys, and Agentic Pipeline never writes to your repo's GitHub settings — readiness only reads.
The frozen baseline
The first time a repository is connected, Agentic Pipeline reads up to 100 successful runs of its configured GitHub Actions workflow and freezes the elapsed-time sample — count, average, median, minimum, maximum. That baseline is immutable: later onboarding calls never re-query or replace it. Every "faster than your old CI" number the dashboard shows compares live Agentic Pipeline runs against that fixed snapshot, so the comparison cannot be quietly re-based.
Go-live switches
The write side of slipstream_onboard covers the closed set of onboarding settings: the platform allowlist, CI mode, ship-on-green mode, live/version URLs for deploy health checks, and the deploy recipe override. Production-enabling writes (turning ship-on-green on, enabling auto-merge) require an explicit confirmation step; rollback, off, and clear writes do not.
Auto-merge is one of those opt-in switches. When enabled for a repo, the moment a CI run records success, Agentic Pipeline merges the open PR whose head commit matches that run — skipping drafts and PRs labeled hold — with a regular merge commit. GitHub branch protection remains the actual guard: a PR that is not otherwise mergeable fails cleanly and the reason is recorded. There is no retry loop; a PR that becomes mergeable later is picked up on its next push.
What your repo ships
Opting in is two files and one branch-protection rule: a recipe in .slipstream.json (CI), optionally a deploy recipe in .slipstream-deploy.json (see ship on green), and the RunsGreen required check on your default branch. PRs, reviews, and merge gates stay exactly as they are.