GitHub integration
Stella Loop connects to GitHub through a GitHub App with least-privilege permissions. A project links one or more repositories; branches, pull requests, checks, and reviews mirror into the product in realtime; and the delivery half of the loop lands on real branches with coordinated merges.
Setup
- In organization settings → GitHub, install the Stella Loop GitHub App on the account that owns your repositories.
- In project settings → Repositories, link the repositories this project works on. Each repository chooses its version-control workflow at link time: git (default) or Jujutsu — jj runs colocated on git, so the GitHub side is unchanged while workspace commands speak jj’s vocabulary.
- If several projects share the app installation, map incoming GitHub issues to projects with connector rules (see Signal connectors).
For multi-repo epics, set the dependency order between repositories in settings — it drives merge orchestration.
Branch-sets and change sets
- When an epic candidate is created, Stella Loop creates its branch —
epic/EPC-12/candidate-a— in every repository in the epic’s scope. A single-repo candidate is just a branch-set of size one. - A change set is the reviewable unit: one pull request per branch-set member, treated as one thing. Its state is computed, never asserted: a change set becomes
approvedonly while every PR is approved, checks are green, and no review thread is unresolved — and it falls back toin reviewautomatically on any regression. - Merges execute in your declared dependency order, halting on the first failure with the position and reason recorded. Recovery is resume (continue from where it stopped) or rollback (revert PRs for the members that already merged). Cross-repo merges are ordered, not atomic — and the product says so rather than pretending.
Stella-managed pull requests carry their provenance: titles are prefixed [EPC-n], and the body contains a maintained block linking the epic, candidate, implemented tasks, and sibling PRs.
Webhooks are hints; the API is truth
Webhook deliveries are verified, deduplicated, and processed idempotently — and whenever a delivery is stale, contradictory, or truncated, Stella Loop re-fetches the truth from the GitHub API. An hourly reconciliation heals anything a webhook outage missed. Connection health is visible per repository (connected, degraded, disconnected, with the reason), and repositories with open change sets cannot be unlinked out from under their work.
Issues become signals
Newly arriving GitHub issues and their comments flow into signals automatically — deduplicated, with repository context attached. Pull-request events stay on the delivery side. There is deliberately no retroactive import of your existing issue backlog: imported tickets would bypass the discovery half of the loop.
Security posture
The App requests the minimum: contents and pull-request write (branches, PRs, merges), checks and statuses read, metadata read. Hosted agent sessions never receive write-capable tokens — their repository mounts are read-only at exact commits, and changes land only through a validated commit boundary. Webhook signatures are verified before any parsing.