此为预览文档，正式版本尚未发布。
目标与准备
需要已部署的 Service、可用 Runtime Host、已登录的 provider、Git、GitHub CLI 和 JDK 17+。使用专门的练习仓库，准备开发者与独立审查者身份；项目管理员配置分支规则、必需检查和合并权限。Hosted 身份与 GitHub 身份分别配置，创建多个 Agent 不会自动创建多个 GitHub 账号。 下载以下文件，去掉末尾.txt，在练习仓库中放置：
样例是订单接口背后的 Java 查询逻辑，不包含 HTTP 服务。初始实现故意缺少筛选和分页：五项固定检查中三项失败；需求还要求 Developer 增加边界测试。将
out/ 写入练习仓库的 .gitignore，提交样例与 CI，再创建需求 Issue。初始 CI 失败是待实现功能的基线。
本地编译与验收命令为：
1. 建立四个 Hosted 角色
按Hosted 接入创建四个 Agent，逐个验证任务执行和协作工具。Developer 需要推送与创建 PR 的能力；Reviewer 需要读取代码和提交 Review；QA 需要读取 Actions 状态与日志；合并使用项目授权的身份。不同 GitHub 身份应通过隔离的 Host 用户、运行环境或工具凭据配置，避免多个进程共用一个会被切换的 CLI 登录状态。
在 DESIGN → Teams 选择 Hosted Leader，添加另外三个成员。团队 Instructions 可以直接使用：
2. 从 GitHub Issue 发起工作
在 WORK → Issues 创建工作，填写 GitHub Issue URL、仓库OWNER/REPO、目标分支、测试命令、验收标准以及“交付到可合并 PR”或“包括合并”的授权范围，选择该 Team 并要求人工验收。Leader 通过 GitHub 工具读取原始 Issue，记录链接和编号。
这条最小路径不要求先部署事件桥接。已有 GitHub Work Source 时，可以使用同步得到的 Service Issue；当前适配器处理 Issue 与评论同步，PR Review 和 CI 仍由 GitHub 工具查询，不因同步 Issue 自动接通整个流程。
在各自任务环境中，将 REPO、ISSUE_NUMBER、BASE_BRANCH 等变量设置为上述实际值。先确认当前 GitHub 身份：
3. 实现并创建 PR
Developer 在 Host 分配的任务目录中克隆练习仓库，创建本次工作专属分支。Host 不会自动把管理员本机打开的仓库作为输入。Reviewer 和 QA 使用各自 checkout，通过 Git 提交共享代码，通过 Comment / Artifact 共享报告。 执行原测试记录基线，完成实现和新增测试后记录新日志、退出码与提交。创建 PR 前，把需求、修改、测试结果和原 Issue 链接写到pr-body.md。需要合并后自动关闭 Issue 时，在正文写入实际的 Closes #编号。
4. Review、CI 与返工
Reviewer 与 QA 获取 PR 后，先记录其 head SHA，再分别 checkout 和检查：Integer.MAX_VALUE，避免 (page - 1) * size 的整数溢出。
有问题时，Reviewer 将具体文件、问题和验收要求写入 review.md，提交 Request changes；Leader 读取反馈并安排新的成员工作。Service Inbox 的 Request changes 不会自动启动返工。
gh pr checks --required 只查看仓库配置的必需检查；没有配置必需检查不能作为测试通过。检查仍在等待、被取消或缺失时都不能宣称交付已通过。检查命令说明。
5. Approve、合并与验收
Reviewer 在独立审查身份下复核最终提交，再提交 GitHub Approve：REVIEWED_SHA 是已完成检查的提交，不能在合并前临时取最新值绕过复核：
失败分支与事件驱动扩展
先跑通主动查询 CI 的闭环，再接入 Automation：事件桥接器校验 GitHub 事件，按仓库、PR 和提交关联原工作，并用 delivery ID 去重。通用 webhook 创建的新任务不会自动恢复原 Team；必须明确关联与后续派发方式。
练习结束后保留交付记录，清理练习分支与凭据，并检查仍在运行的 Host 任务。验收至少包含一次真实返工或失败恢复，而不只是顺利通过的截图。