GitHub missions¶

A mission is an issue you have marked as work for an agent. Barista Cloud watches a repository you connect, and when an issue gets the trigger label it starts a worker with that issue as its subject.

The reason to run it this way is that you already have a place to watch long-running work: the issue is the queue, the thread is the conversation, and a pull request is the review and the sign-off. There is nothing new to learn and no second dashboard to keep an eye on.

Connecting a repository¶

Connecting takes two decisions, made by two different people at two different times, so they are two steps.

An org admin installs the Barista GitHub App on the repositories it may act on. This is a GitHub App installation, not a personal login: it acts as the app, its permission is granted per repository by an admin, and it keeps working after the person who installed it leaves. The console login you use to sign in to Barista Cloud is a different credential and is never used to act on a repository.
You say what a mission runs — which worker, and what command inside it. There is no default. A repository with no worker configured records the refusal and starts nothing, because a default command would mean running work nobody asked for.

The trigger label¶

Connecting a repository does not mean every issue anyone files runs an agent. An issue becomes a mission only when it is explicitly marked:

add the trigger label (barista by default, configurable) to an issue, or
open a comment with the command (/barista … by default).

The label is revocable consent. Remove it and the issue stops being a mission — later events on it are no longer treated as mission events. Work already running is left to finish; removing a label is not a kill switch.

Exactly one mission is bound to an issue. Labelling it twice does not start a second run, and neither does GitHub redelivering the same event.

What the product will do to a repository¶

Read the issue that was marked, and start a worker for it.
Open a pull request with the change the work produced.
Post progress into the issue thread, summarized at state transitions.

What it will not do¶

It is not a CI system. It does not run tests on every push, and it does not gate your merges with checks of its own. It runs missions a human asked for.
It does not treat the repository as the source of truth. What a mission did lives in its own event journal; GitHub mirrors it. Closing an issue by hand does not mark a mission complete, and reopening one does not revive a mission that has finished. The single exception is deliberate: merging is the approval, because that is the decision you actually want to make in GitHub.
It does not act on unrecognized events. The receiver understands a small fixed set of event kinds and acknowledges everything else without doing anything. Anything it will not act on is recorded so you can see that it arrived and was declined.
It does not act on a delivery it cannot verify. Every delivery is checked against the shared webhook secret before its contents are read, and a valid signature is not by itself permission to start work: the account that labelled the issue must also be permitted for the tenant that connected the repository.

Not yet¶

Two parts of the surface are recognized but deliberately refused rather than half-implemented, and the refusal is recorded so you are not left guessing:

A comment as an answer to a waiting mission. A mission cannot yet be in a "waiting for a human" state, so there is nothing for a comment to resume. A comment intended as input is refused with that reason.
Merging a pull request as the mission's completion. Recognized, not yet wired up.