Jern Cloud docs

Start work from GitHub.

Work starts where it is asked for. Three GitHub events open or continue a session, under settings a workspace admin turns on, and every one of them acts as the person who asked.

The three triggers

Event	What happens
A label, `jern` by default, goes on an issue or pull request	A session opens on the repository with the issue's title and body as its first message.
A comment starting with `/jern` on an issue or pull request	On a session's own pull request, the comment becomes the session's next turn. Anywhere else, a session opens with the comment as its first message and the issue as context.
A check fails on a session's pull request	If the workspace opted in, the session gets a turn asking it to fix the failure, at most three per session. The Jern receipt check itself never triggers.

Jern Cloud answers on the issue or pull request with a comment naming the session, and the pull request the session opens carries its receipt as a check like any other. Work that should start on the clock rather than on an event is a schedule.

Who may trigger

A trigger acts as a workspace member, never as the App. The GitHub user who added the label or wrote the comment must have signed in to Jern Cloud, be a member of the workspace the repository is connected to, and have had write access to the repository at their last sign-in. For a comment they must also be an owner, member, or collaborator of the repository in GitHub's own terms. Anyone else is ignored, and the refusal is in the workspace audit log.

Everything the dashboard enforces applies unchanged: the approval requirement, the concurrency limit, the monthly allowance, the cap per attempt, the plan, and the provider keys. A trigger with no model configured, or for a model whose provider has no key, is refused and audited, never started.

Turning triggers on

Under Settings › Triggers, a workspace admin sets:

Setting	Meaning
Enabled	Off by default. Nothing happens until an admin turns it on.
Model	The model triggered sessions run on; required.
Cap per triggered session	Tokens a triggered session may spend per attempt, never above the workspace's cap per attempt, which bounds it.
Label	The label name that starts a session; `jern` by default.
Retry failed checks	Opt in to the failed-check turn.

When a trigger cannot start a session

A label or comment may reach a workspace that cannot take the work: the trigger model's provider has no key on the plan, the trial has ended, no trigger model is set, the token budget is above the cap, or the plan's concurrency is used up. The session opened for it then carries one notice line saying why and closes, so nobody finds an empty session, and Jern Cloud comments on the issue with the same reason and what would let the work through. The refusal is a workspace notification and an audit event.

When the pull request is merged

The App also hears when a session's pull request closes. A merge is recorded on the session with who merged it, writes a line into the transcript, closes the session unless an attempt is still running, and is a workspace notification. The session list and header show Merged. A pull request closed without merging leaves the session open, since it may be reopened or asked for changes.

Idempotency and audit

Every GitHub delivery is recorded once by its delivery id, and a session message keyed by that id is appended at most once, so GitHub's redeliveries never start duplicate work. Each start, turn, and refusal is an audit event: trigger.session_started, trigger.turn_appended, trigger.refused.

What the App needs

The repository permission Issues: Read and write, to receive issue and comment events and to answer with a comment, and the event subscriptions Issues, Issue comment, and Check run. Pull request comments arrive as issue comment events; check run events arrive through the checks permission the receipt check already needs.