CI recovery

When a claimed GitHub pull request has a failing check, Tallpine records it and sends a recovery message to the worker that owns the PR.

The flow

1. Tallpine checks the claimed PR on GitHub.
2. Tallpine records new failing checks and sends their names and links to the owning session.
3. The session receives the message in Chat or Terminal UI.
4. The desktop updates the PR summary with the same check information.

Tallpine compares the check list with the previous one. It does not resend an unchanged failure on every poll. A changed list can trigger another message.

Make sure the PR is linked

PRs created by a session are discovered and associated through normal observation. To attach an existing PR explicitly:

tallpine session claim-pr <pr-number-or-url>
# From outside the worker, target it explicitly:
tallpine session claim-pr <session-id> <pr-number-or-url>

Inside a worker, the one-argument form uses TALLPINE_SESSION_ID automatically.

Or claim it while creating a session:

tallpine spawn --project my-project --name fix-pr-42 \
  --claim-pr 42 --mode chat

Use --no-takeover if the operation should fail when another active session already owns the PR.

Claiming records ownership, but does not check out the PR branch. Prepare the matching workspace before asking the worker to make a fix.

tallpine report sends a worker update to an existing orchestrator. It does not claim PR ownership.

What the agent receives

The message includes the failing check names, available run URLs, and PR identity. Tallpine does not copy raw CI logs into the desktop app. The agent can follow the links or use the repository host's CLI to read the logs.

Follow progress

Open the session inspector to see the PR, CI state, and failing-check links. The notification center is for human attention such as input requests and merge readiness; CI recovery itself is routed to the agent session.

Current limits

• This example covers GitHub checks. Tallpine also observes GitLab, but check and review details depend on the provider.
• CI messages are built in. You cannot configure them through a reactions: YAML block or set a retry budget. See Automation reference for current behavior.
• Tallpine uses the pull-request status reported by the repository host for draft and required-check status.

If automatic delivery is unavailable, open the owning Chat or Terminal UI session and send a follow-up directly with the desktop composer or tallpine send.