<deploy_home>/orbi.toml（它设置了 ORBI_CONFIG）；CLI 依次读 --config PATH、$ORBI_CONFIG、当前目录下的 ./orbi.toml。只读命令（status、doctor、session、check）既没给 --config 也没设 ORBI_CONFIG、且 ./orbi.toml 不存在时，改为解析唯一已安装 unit 的 config。相对路径相对该文件解析。启动 tick 前运行 orbi check 校验配置。
仓库与路径
调度
模型 provider
这三行
review_pi_* 配置让独立评审运行在与实现不同的模型上——见 Reviewing with a different model。
Prompt 与上下文
交付行为
Steering
Steering 让 Runner 轮询 Issue 中的受信任修正，并带着修正重启正在进行的交付。steering_max_rounds 限制重启次数，避免交付被无限重定向。轮询失败属于纯旁路：会记录日志，但绝不会让交付失败。这三个键都可以写在仓库的 .github/orbi.toml 中；仓库声明的值优先，省略时回落到 host 值。steering_poll_seconds 必须是有限正数，不额外设置下限。
详见 Operations 中的 delivery_steered、steering_limit_reached、steering_poll_failed、steering_limit_notice_failed 行。
Health
通知
Orbi 可以把等待人的任务在 GitHub 之外告知队列负责人：当它新加上ai-blocked、ai-needs-detail 或 ai-awaiting-merge 时，向 Telegram（私聊或群）发送一条消息，写明状态、owner/repo#N <title> 和 Issue 链接。人工验收门禁（human_review_gate）也会发送一条消息——等您人工验收——每次交付仅一次：PR 打开、且清单要求人确认（栏二非空）时，与那份清单一起发送。栏二为空的交付不需要人介入，不发送；之后的 tick 也不会重复发送。人手加的标签是他自己的动作，不会发送。发送是纯旁路——失败只记 notify_failed journal 行（见 Operations），绝不使交付失败或改动标签。
需要人处理的问题消息——ai-blocked、ai-needs-detail 以及人工验收等待——结尾都带社区求助行 需要帮助？加入 Orbi 用户群：https://t.me/+kJRTTpFGBRU0M2Y9；普通交接（ai-awaiting-merge、合并通知、orbi notify test）不带。Orbi 的 GitHub 评论遵循同一规则：澄清评论、栏二非空的人工复核清单、以及 blocked 失败诊断，结尾都带这一行——绝不出现在没有要求人介入的评论里。
bot token 不是配置键：它只存在于
<deploy_home>/.orbi/env 的 ORBI_TELEGRAM_BOT_TOKEN=...，在 journal 中会被脱敏，也不会传入 Pi session 的环境变量。这层环境变量过滤就是全部保证：Pi 进程以 Runner 的用户身份运行，因此 session 仍可自行读取 <deploy_home>/.orbi/env。没有单独的通知语言：固定消息跟随主机级 message_language（Issue #1660，默认 en），而不用仓库的 .github/orbi.toml 覆盖值——消息是发给人的，不是写进仓库的。
ORBI_TELEGRAM_BOT_TOKEN=... 写入 <deploy_home>/.orbi/env，向 bot 发送 /start（私聊）或把 bot 拉进群并发一条消息，打开 https://api.telegram.org/bot<token>/getUpdates 复制 message.chat.id（群 id 以 - 开头），设置 telegram_chat_id，然后运行 orbi notify test。只有 chat id 没有 token 时，每个 tick 都会报告（notify_failed reason=not_configured），orbi doctor 和 orbi notify test 也会报告——但绝不阻塞交付，因为 .orbi/env 与 orbi.toml 是可能互相滞后的两个文件。
每个 tick 在启动时读取本配置，因此改动从下一个启动的 tick 起生效；已在运行的交付沿用启动时的设置。其他方式等待的票——已经带上人工专属 ai-human-review 标签的票、里程碑确认票——不会发送。
合并也会被通知：通知开启时，每个 tick 读取仓库最近更新的已合并 PR，并为自上次检查以来合并的、由 Orbi 开出的 PR（交付分支 orbi/<owner>-<repo>-issue-<n>；仅有 orbi/ 前缀、例如自建的 orbi/manual 不算）各发一条消息——Orbi · 代码已合并：owner/repo#N <title> 加 PR 链接，语言跟随主机 message_language。开启（或重新开启、或修复缺失 token）后的第一个 tick 不会补发此前已发生的合并：它用当前最新的合并建立水位文件 <repo_dir>/.orbi/notify-merged-since，之后才通知新的合并。关闭通知会删除该水位文件，因此之后重新开启不会重放这段空档；读取失败记一条 notify_failed reason=merged_check_failed journal 行，下一个 tick 重试。两个限制：两个 tick 之间更新超过 100 个 PR 时，某次合并可能被挤出读取页而不再被通知；单槽 Runner 忙于一次交付时，下一个 tick（以及消息）要等到该交付结束。