The delivery lifecycle

An Issue moves through the ai-* labels from ai-ready to ai-merged, and the labels themselves are the delivery record. Orbi Cloud keeps no separate dashboard of truth. The labels on your Issue, the comments Orbi leaves, and the pull request it opens are the complete state of a delivery — which means you can read, audit and correct everything from GitHub alone.

​

The state machine

​

What each label means

The right-hand column is the chip the status page shows for that label in Task history. An Issue closed without a merge shows Closed, not merged. These labels record a task type or a human decision: The engine’s human acceptance gate, which makes a delivery wait for a person to confirm a checklist, is not turned on in Orbi Cloud, so a delivery does not stop to wait for ai-human-review. Anything waiting on you — Blocked, Awaiting approval, Needs detail — is also pulled to the top of the status page, with its reason and available action.

​

Timing

With the environment ready, quota available, the task in scope and execution capacity free, Orbi usually starts within about a minute of ai-ready. The label event wakes the runner, with a five-minute timer as fallback. This is not a five-minute maximum for queued tasks: earlier work, unresolved dependencies and version scope can keep them waiting. After pickup, duration depends on the task and repair rounds. Once usage is reported, Task history shows elapsed time, AI calls and tokens, including cache.

​

The independent review

The session that reviews the pull request is not the session that wrote it. It reads the diff fresh, runs the tests again, and either returns a clean verdict or files findings. When it files findings, Orbi repairs them and the pull request goes back for another round. This loop is bounded: if rounds are exhausted without reaching a clean verdict, the Issue is marked ai-blocked rather than looping forever. The pull request, branch and workspace all stay intact when that happens, so nothing is lost. Only a clean verdict reaches the merge gate. If the base branch advances without conflicts, the Runner can absorb that update and wait for the new head’s CI without repeating the independent review. Outside changes to the PR head require review again. The gate checks the current head and base before merging; see the engine’s review and merge reference.

​

Steering a delivery that is already running

You do not have to wait for a delivery to finish to correct it. While an Issue is ai-in-progress, add a comment with the new decision, or edit the Issue body. Both channels are equivalent, and the running session restarts with your correction — normally within a minute. This is the intended way to redirect work that is going the wrong way; you do not need to cancel anything. Two limits are worth knowing: Steering is bounded. A delivery accepts 3 steering restarts by default. After that, further corrections do not restart it — let the delivery finish and put the revised scope into a follow-up Issue. Only trusted commenters can steer. Comments from people with write permission in the repository steer a run; a comment from an arbitrary public commenter is ignored by design, because otherwise anyone who can comment on your Issue could redirect what the agent does.

​

ai-blocked is a decision point, not a failure

ai-blocked is a terminal state that means a human must decide what happens next. The comment Orbi leaves on the Issue states why automatic recovery was not possible. Some pauses resume on their own, with no label change from you: when the base branch’s own checks are failing, Orbi continues once they turn green (see troubleshooting); when the missing permission to read checks is granted; and when you correct a base branch that does not exist in Cloud, the affected tickets are queued again. Deciding the next step can mean changing the code, rewriting the acceptance criteria or closing the Issue. To resume after repairing the cause, replace ai-blocked with ai-fix-needed if its PR is still open, or ai-ready if it has no PR. Removing the blocked label alone does not restart it. See troubleshooting for how to read a blocked comment.

​

Sharing a delivery

When a delivery merges, Orbi comments on the pull request with ✅ Delivered by Orbi · View delivery proof → (in Chinese when Orbi’s message language is Chinese). The link opens a page at orbi.build/proof/<owner>/<repo>/<issue> that shows the Issue, the pull request, the review and, once it ships, the version it was Released in. For a merged delivery in a public repository, the page has Copy link and Share on X buttons. For a public repository anyone with the link can open it; for a private repository it only opens for someone who signs in with a GitHub account that can read that repository, so sharing the link does not expose private code. For a project’s delivery history, open orbi.build/proof/<owner>/<repo>. It lists the most recent merged result per Issue, up to 100 rows, with the total count above. Public records are open; private records require GitHub sign-in and repository access. Public real projects also offer a README badge.

​

Task types

ai-ready is the execution switch for every kind of task. A second label chooses which playbook runs: One more label affects ordering rather than behaviour: p0 marks an Issue urgent, and Orbi picks up p0-labelled Issues before bug-labelled ones, which come before plain ones.