示例与适用场景
Orbit 是独立教程项目，包含 index.html 和三个本地文本下载文件，没有真实安装包。叮叮负责实现，芝士使用只读智能体配置负责审查，两人面对同一组项目文件。
目标较小且你能直接验收时，用一位队员即可。需要按明确条件进行独立检查时，再拆分实现与审查。并行工作要分开文件范围，或让一位只读审查，避免两人同时写同一文件。
协作怎样连接起来
准备两位参与者
- 在“队员”中为实现和审查分别设置职责，并保存各自智能体配置。
- 为独立 Orbit 目录新建会话，选择叮叮和芝士，把叮叮设为队长。
- 打开会话顶部“队员”确认参与名单。长期名册与本次会话名单是两层关系。
- 明确范围：叮叮可以改页面与检查脚本；芝士只读审查。两次请求都留在同一会话。
发起实现请求
完善 Orbit 下载页。分别展示 Apple Silicon、Intel 和 Windows x64，并指向现有 downloads/orbit-*.txt 文件。明确说明这是教程演示文件，不是安装包。补充对应说明、窄屏布局和键盘焦点样式。只修改当前项目。检查实际链接和页面结构，最后列出改动文件、实际完成的检查，以及仍未验证的部分。
选择真正的接收对象
查看实际执行
阅读实现交付
这次真实执行修改了 index.html，并新增 styles.css 和 verify.mjs；通过 node verify.mjs、node --check verify.mjs 和 git diff --check。原有下载文本文件保留。
实现队员说明 Chrome 访问被拒绝，因此没有声称完成浏览器视觉检查。它还报告显式消息发送命令失败，但最终回复仍出现在会话中。这些限制保留在本次记录里。
主动请另一位队员审查
独立审查 Orbit 当前改动。检查平台名称、演示文件链接、HTML 基础可访问性、键盘焦点和窄屏规则。读取文件并运行现有检查，暂时不要修改。问题要给出具体文件位置；没有发现问题就如实说明。区分代码检查和真正完成的浏览器检查。
这次交接由用户发起
真实审查意见
根据意见发起小范围修复
核实实际 CSS 中的页脚对比度。如果确认不足，只加深该文字颜色使其达到至少 4.5:1，并在 verify.mjs 加入数值检查。重新运行已有检查，不重新设计、提交或发布。报告修改前后的比值和变更文件。
检查修复与交付
按实际验证范围验收
最终交付包含 index.html、styles.css、verify.mjs 以及三个原有文本文件。文档采集时独立重新运行了 Node 检查，结果通过。智能体此前浏览器访问被拒绝的事实仍保留在记录中。
如果你的审查没有发现问题，就以验收结果收尾，不需要编造缺陷凑流程。需要继续修改时，基于当前事实发送新请求，并保留之前的过程。
按审查意见决定，再查看文件
先读真实审查意见，再决定是否继续修改。确定的缺陷可以交给实现队员作小范围修复；建议项可能需要你作产品决定。没有发现缺陷时，就继续验收交付，不为凑闭环虚构修复。
从实现回复下方的“文件变更”展开路径和差异，再用浏览器打开 index.html 查看页面。执行成功或审查队员回复都不等于代码已经合入或发布。
下一条消息由谁接收？
- 没有显式接收对象
- 通常由队长接收。但你明确发给一位非队长队员后，输入区可能显示继续发给该队员。以可见的接收提示为准；取消延续后再使用正常路由。
- 选择一位或多位队员
- 同一消息会给每位选中队员建立待处理工作。多人接收不会自动形成“先实现、后审查”的顺序；有先后依赖时，等待前一结果，再发送后续请求。
- 回复队员消息
- 回复会增加原消息引用；原作者仍是可参与队员时，会把它加入接收对象。检查全部已选提及，已有接收对象可能仍保留。原作者不可用时需要另选接收者。
- 回复用户或系统消息
- 引用提供上下文，用户或系统本身不是智能体接收者；需要确认你在请哪位队员处理。
- 默认队长
- 提供默认接收对象，并拥有产品规定的任务责任操作。这个称谓不保证自动规划和分配每条请求。
- 队员之间的主动交接
- 智能体可使用 Rovai 的显式发送能力，把具体后续工作交给在场队员。以消息展示的接收对象和后续执行为准；普通叙述中的名字、感谢或一句“等待审查”都不能证明已发生交接。
下一次怎样继续
重新打开原会话，先读最新交付和未完成任务，再说明此后发生了哪些变化。用新消息界定剩余工作。
只有长期约定值得整理成记忆，例如项目的平台命名。临时审查要求和本次完成状态留在会话或任务里。
在 Rovai 中打开交付页面
