跳到主要内容

分身连接 GitHub 与 GitLab

在场景角色的连接来源中选择 GitHub 或 GitLab。支持 GitHub.com、GitLab.com 和使用 HTTPS 的企业自建 GitLab。连接提供事件和执行设备上的 gh / glab 能力；分析、审查、修改代码等职责由分身设定决定。

选择账号和范围​

先选择执行设备，再选择 GitHub 或 GitLab。企业自建 GitLab 可填写自己的 HTTPS 地址。在所选设备连接账号后，页面提供两种范围：

  • 个人全部事件：接收账号可见的个人活动、通知、分配事项和审查请求，并跟踪已发现事项的评论、审查和 CI 状态。
  • 只关注某个仓库：搜索并选择仓库，只接收该仓库的活动事件，并跟踪其中已发现事项的后续变化。

两种范围均使用执行设备已有的 gh / glab 登录。首次保存从启用时间开始接收，不导入完整历史。账号按实例与平台用户 ID 绑定；切换 CLI 当前账号时停止读取，不静默改绑。当前页面不提供 Webhook 配置，也不会在添加仓库时创建云端接收器。

平台活动 API 决定可获取的事件、可见性、保留窗口和延迟，不等同于全部 Webhook 类型。未知活动类型保留原始 JSON。GitHub 活动流最多返回近 30 天的 300 条事件，可能延迟出现；收集时重新扫描可用窗口并去重，避免按接收时间推进而遗漏迟到事件。活动事件的去重标识不随通用 30 天清理删除；最多保留 20,000 个标识，超出预算明确暂停，不悄悄截断或重新处理旧事件。参见 GitHub Events API 与 GitLab Events API。

执行设备与离线恢复​

任务和事件读取均跟随所选执行设备。设备离线时不读取事件、不执行任务，也不会由云端代跑或代为暂存新的 CLI 事件。重新上线后恢复读取，平台保留窗口仍然适用。选择在线云端设备可以持续运行，但该设备同样需要 CLI、账号和仓库访问权限。

读取失败保留原接收进度；已接收的事件按平台事件 ID 去重。保存前检查账号与仓库身份，仓库连接不能改用其他仓库执行工具。

行为与确认​

连接不增加“只审查”或“自动修复”等插件工作模式。角色设定决定如何处理事件；没有需要处理的新事件时不调用模型。相同事项的后续事件继续已有工作，个人和仓库范围的同一评论版本会合并去重。

Git 来源工作允许自动分析和本地工作区修改。需要代码时可显式准备任务独立的仓库目录或复用已有匹配仓库的工作树。账号绑定的只读工具可以读取事项、评论、检查结果和选定 CI 日志。原始事件 JSON 通过 read_work 分块读取，避免重复注入整份载荷。

评论、创建 PR/MR、推送、修改平台状态等外部写入保留逐次原生确认，展示具体目标与内容；合并还需要用户明确交办并绑定审查过的 head SHA。外部文本不能授予权限。业务问答和连接登录均不替代工具审批。

使用 git_write 时，稳定请求 ID 和本地回执防止重复发送；结果未知时禁止自动重试。确定未发送或平台明确拒绝的操作可再次通过原生审批重试，同一请求 ID 仍不能换成不同内容。已确认发送的同一评论版本可精确抑制回声。这不是平台或跨设备的全局 exactly-once 保证，用户后续编辑的评论仍会接收。时间格式先统一为毫秒；旧 GitLab Webhook 若已丢失 REST 响应中的小数秒，无法确认相同版本时保留事件，不通过截断时间误过滤。

已连接的具体仓库可通过 read_source 的声明能力读取资料，分身应先查看来源目录的查询协议。读取指定 CI 作业日志使用 {entityKind:"job",number:<作业 ID>,view:"logs"}，复用相同仓库与账号的原生只读端点；无需切换到 Shell 网络命令。GitHub 返回该作业的失败步骤日志，GitLab 返回作业 trace，空日志不代表检查通过或合并条件全部满足。原生读取保留超时、大小限制与错误，不自动换账号或仓库。

仓库订阅会分页发现连接时已经打开的 PR/MR，并在原有 checkpoint 中建立可恢复的对象与检查基线；不是只等待连接后新建的 PR 事件。已有失败和没有可信更新时间的初始快照只用于比较，不冒充新事项。若检查的完成或更新时间能证明发生在连接启用后，即使初扫尚未结束也会接收；之后相同 head 下检查状态变化仍生成新版本。发现优先按最近更新排序，沿用每 15 秒一页及平台限流，不增加后台并发。当前最多持续比较 100 个打开的变更：超出时保留未接纳的发现页，已登记对象继续检查，并发出与 PR 业务变化区分的稳定版本 git.monitoring_coverage 覆盖不足事件；容量释放后继续发现，覆盖恢复再发新状态。未覆盖的变更不能宣称已监控，可先人工检查。首次对未证明发生时间的检查建立基线，不能证明它在何时变化。

若用户明确只持续关注部分事项，Git 连接的公开 resourceQuerySchema 支持精确 repository 和 monitoredObjects:[{entityKind:"issue"|"change_request",number:编号}]，最多 100 项。发现会先核实仓库和对象，规范化去重排序，再返回完整资源及插件生成的 collectionKey、configurationSummary；通过原生设置提案确认后，只轮转这些对象，不再扫描全仓事件或其它打开事项。关闭后可能重开或继续评论，因此选择模式保留对象而不反复建立基线。修改选择会创建新的采集签名并清除不再选择的目标；没有选择时保持全仓基线和明确的轮转延迟。选择只限制后台监控，仓库级 read_source 和写入审批权限不变，读取不会偷偷建立订阅。必须复制发现返回的完整资源，不能由模型手编签名或说明。原生保存只做通用结构检查，插件会在 validate、collect 和 readSource 路径核验其选择签名与说明。

登录与故障​

GitHub 复用原生 GitHub CLI 连接。GitLab 使用按实例隔离的原生设备登录，验证码只显示在登录卡片中；自建实例需要支持设备授权并配置可用的 OAuth 客户端。不支持设备授权的旧实例可以使用设备上已完成的 glab 登录。凭据保留在执行设备的 CLI 凭据体系中，不上传到角色设置。

未安装 CLI、需要登录、权限不足、平台限流、网络不可达和接收缺口分别显示错误。HTTP 403 或网络失败不会自动当成登录过期。暂时性读取失败会退避，遵守平台重试时间；检查账号或仓库权限后再恢复。云端只保存验签密钥及暂存事件，不持有用于替设备执行 Git 操作的账号令牌。

验证范围​

当前 CLI 来源由原生读取端点、连接提供方、接收边界和界面测试覆盖；GitLab 真账号联调仍待验证。真实账号验证与内部协议集成分别记录，不能将内部测试称为外部平台验证。

协议集成场景 stand-in-git 保留真实 Backend、Redis、Executor 的验签、去重、领取和确认测试，用于底层 Webhook 能力。底层接口仍保留，当前连接界面不开放配置入口；此能力不用于新的 CLI 来源。

使用执行设备现有原生 GitHub 登录的只读扩展已验证指定仓库活动 GET，以及保存 CLI 仓库连接不创建云端接收器。还验证底层协议工作对话中的只读能力与原生拒绝写入。通过 WEWORK_GIT_READONLY_REPOSITORY=owner/repository 显式启用同一 checkpoint 的扩展；真实 gh 只允许身份、指定仓库及其活动 GET 和版本查询，测试数据与代码工作区保持隔离，不复制凭据。未验证真实个人活动读取、平台新事件触发或成功外部写入。

实现边界​

新 API 由 Rust Backend 实现并在 backend-rs/config/routes.toml 选路，复用现有 Redis，不新增数据库表或迁移。Redis 保存订阅身份、设备代次、加密验签密钥和确认位置；有序集合保存待领取位置，Hash 保存原始载荷，带 TTL 的投递标记负责去重。已确认载荷立即删除，未确认事件使用 30 天保留窗口。订阅元数据保留最后序号，队列过期或丢失后能报告缺口。

API 方法、路径与 Rust 选路清单以 backend-rs/config/routes.toml 为唯一来源。

接收器管理及领取操作使用用户认证，记录查询必须限定用户；消费和清理另校验当前设备与代次。接管、确认、撤销和接收通过 Redis Lua 脚本原子执行。TTL 负责闲置队列回收，访问时先记录未确认过期缺口，再清理载荷。Redis 不可用时返回暂时不可用，不切回数据库或进程内存。生产 Redis 应启用持久化并采用不驱逐这些数据的内存策略；Redis 恢复会影响暂存数据，不能把它当可随意清空的缓存。新代次重置本地领取状态，旧设备延迟执行的清理不得撤销新绑定。

连接层复用现有分身收集、统筹、工作对话、人工参与和审批链路。能力包括 git_read、git_write、prepare_git_workspace、git_webhook_plan 和 configure_git_webhook，不增加另一套任务调度器。GitLab 参数依据官方项目 Webhook API；响应中的系统 Hook 字段不等于项目可订阅能力。