ai-* 标签从 ai-ready 走到 ai-merged，而这些标签本身就是交付记录。
Orbi Cloud 不另外维护一份「真相面板」。你 Issue 上的标签、Orbi 留下的评论、它提交的 pull request，就是一次交付的全部状态 —— 这意味着你只靠 GitHub 就能读取、审计和纠正所有东西。
状态机
每个标签的含义
有两个标签只由人来打，Orbi 从不打：
时间
Orbi 按定时器工作，不是即时反应，所以你加上ai-ready 之后认领最多要五分钟。同样的 tick 间隔适用于每一次状态转移：修复中轮次的交付要等下一个 tick 才继续。
认领之后一次交付要跑多久，完全取决于任务的大小。一个小而清晰的改动几分钟就能完成；大的要更久，还可能经过好几轮修复。一旦交付上报了用量，状态页会按工作项显示运行时长、模型请求数和重启次数。
独立评审
评审 pull request 的那个会话不是写它的那个会话。它从头读 diff，重新跑测试，然后要么给出干净结论，要么提交发现的问题。 提交了问题之后，Orbi 修掉它们，pull request 再进下一轮。这个循环是有界的：如果轮次用尽仍然没拿到干净结论，Issue 会被标成ai-blocked，而不是无限循环下去。发生这种情况时 pull request、分支和工作区全部保留，什么都不会丢。
只有干净结论才能进入合并门禁，而合并的是被评审的那个 commit 本身 —— 不是重建或 rebase 过的版本。
让正在跑的交付转向
你不用等一次交付跑完才能纠正它。Issue 处于ai-in-progress 时，加一条写着新决定的评论，或者改 Issue 正文。两条通道等价，正在跑的会话会带着你的纠正重启 —— 通常一分钟内。
这就是给跑偏的工作重新定向的正规做法，你不需要取消任何东西。
有两个限制值得知道：
转向是有界的。 一次交付默认接受 3 次转向重启。超过之后，后续的纠正不会再重启它 —— 让这次交付跑完，把修订后的范围放进一张后续 Issue。
只有可信的评论者能让它转向。 来自仓库 owner、maintainer、成员和协作者的评论能让一个 run 转向；来自任意公众评论者的评论按设计被忽略，否则任何能在你 Issue 下评论的人都能改变 agent 在做什么。
ai-blocked 是决策点，不是失败
ai-blocked 是一个终态，意思是必须由人决定接下来怎么办。Orbi 在 Issue 上留下的评论会说明为什么自动恢复做不到。
「决定下一步」真的是指任何下一步：改代码、重写 Issue 的验收标准，或者直接关票。只摘掉标签不会重启任何东西 —— 先修掉根本问题，再重新打上 ai-ready 把 Issue 放回队列。
怎么读一条 blocked 评论，见问题排查。
任务类型
ai-ready 是所有类型任务的执行开关。第二个标签决定跑哪套 playbook：
还有一个标签影响的是顺序而不是行为：
p0 把一张 Issue 标为紧急，Orbi 认领打了 p0 的 Issue 优先于打了 bug 标签的，后者又优先于没打标的。
这一页讲的是你在 Cloud 上看到的生命周期。引擎自己的参考 —— 每一次状态转移、接续（resume）的确切语义、完整的配置面 —— 在 docs.orbi.build/zh/workflow。