PR 合并入场

• 每条路线上的新鲜合并准入（普通、之前的 CI admin 和 Crabbox）仅在证明从观察到的和验证的主锚点下降并检查准备好的头合并树无冲突且非空之后才接受向前的主要运动。 PR 身份、头、基础、生命周期、草案状态和策略事实保持固定。可合并性预测可能会重新计算； UNKNOWN 在 60 秒窗口内稳定下来，并具有 2/4/8 秒上限的退避，然后 MERGEABLE 和所选路由的策略要求必须成立。经过验证的主光标与原始意图和登陆父审计锚点分开前进。 OPENCLAW_PR_STRICT_DRIFT=1 除了合并验证漂移门之外，还恢复观察和最终 Crabbox 验证期间的主更改中止。先前的 CI 权威保留其现有顺序：对于已选择的 REST，最后一次完整观察和主要实现先于最终的实时权威验证。 GraphQL 保留其权限后本地重读（无延迟或显式获取），拒绝新不可用的 main before 意图；后期 REST 后备保留该边界并重新检查权限。最终权威验证后不会实现。 OPEN/CLOSED/pending/uncertain 协调保留了 PR/main 快照的完全稳定性。只有经过验证的 MERGED 收据可以接受其两个观察之间的向前主要推进：每个 PR 事实必须保持相等，在本地不存在时通过相同的规范可信 URL 获取重读的确切主要提交，并证明原始观察到的主要是其祖先。相同的快照保持快速路径。两张快照均保持固定状态；切勿添加第三个重读循环。这完成了一个已经证明的合并，永远不会授予未来合并的权限；历史 tree/source-base 支票和 receipt/comment/cleanup 所有权保持不变。

• 本地对象可用性探测和严格保留记录读取使用命令范围的 GIT_NO_LAZY_FETCH=1。上游Git 2.45首先支持该环境变量；较旧的 Git 可能仍然隐式地水合对象，并且不能承诺仅限本地的探测。不可变头重用探针和最终的 GraphQL 先于 CI 本地检查也使用 Git 的显式 --no-lazy-fetch 开关：不受支持的 Git 回退到规范头获取或拒绝最终的主要高级优化。这不是新的全命令最小值或离线工作流程：显式规范获取和实际 tree/diff/archive/push/checkout 操作仍然可用。完整收据的正确性取决于固定事实和 ancestry/tree 证明，而不是这种下载回避。

• 新鲜的初始准入和后来的准入稳定性检查为UNKNOWN可合并性提供了一个60秒的稳定窗口，从第一个观察到的UNKNOWN开始，休眠2秒然后4秒，随后的暂停上限为8秒。远程读取和退避消耗了这个预算；已完成的本地 Git 物化和合并树证明则不然。单独的 900 秒管理权限截止日期仍然包括所有已用时间。在应用附带结算截止日期之前，每轮重新资格审核都会消耗其第一个新预测；在此观察之后，过期的预算仍然拒绝接纳。在完整的 REST 观察之间，仅投影提示使用选定的读取器，而不重复策略、检查套件或权限读取。 GraphQL 保持其单一请求完整观察结果，无需额外提示。一个已知的提示只需要另一个完整的观察；它永远不会更改保留的快照、选定的传输、主光标或权限，并且永远不会关闭或扩展设置窗口。完整的观察还必须通过每一个原始的头、主要、政策、预测和权威检查。 PR 和政策事实以及每个已知的预测均保持不变；已知的权威投影结束了 UNKNOWN 剧集。保留结果调节从不进行民意调查。在意图没有合并队列的 PR 之前，普通合并拒绝 gh 的 BLOCKED/BEHIND/DIRTY 拒绝，管理员合并拒绝 DIRTY；队列和自动保留其不同的准入合同。

• 在有效的 GraphQL 快照具有 UNKNOWN 投影之后， 显式先验 CI 准入可以选择完整的 REST 观察所有者。下一个观察必须保留每个已知的 PR/projection 事实； REST 重读保留存储库身份、准确的头、主要、规则和完整的所需检查证据，而无需将 BLOCKED 转换为 CLEAN。通过尝试，该读者仍然被选中。在活动的先验 CI 准入期间，完整 REST 读取的两个主要端点在标准化之前都经过相同的前向祖先和合并组合所有者；重新检查分支策略，并且瞬时读取边界永远不会进入保留的结果。最新验证的 main 与意图锚点分开跟踪。只有新的经过验证的向前推进才可以打开 60 秒的重新计算窗口（2/4/8 秒上限退避）；确切的 PR/policy/check 事实和原始已知投影值保持固定，每个后续主项必须从最新读取开始，并且 UNKNOWN 从未授权调度。最终已选择的 REST 窗口在权限验证（包括重新计算读取）之前实现两个端点和已验证的锚点。 GraphQL 和后期的 REST 后备保留其权限后仅限本地窗口。如果该 GraphQL 窗口观察到一个新的 main，其原始对象确实不存在，则它会丢弃主动权限证明并返回到该确切提示的预权限具体化。两个较早的引脚必须保持可读；查询失败、stderr、损坏、权限错误和不受支持的 Git 并不意味着不存在。每个新回合都会将观察到的提示保留为祖先下限，并根据原始证明指纹重复完整的实时 CI、头、审查、证据、安全和管理验证。权威重新资格限制为 900 秒和 32 轮，有轮次计时和在意图之前拒绝或在筋疲力尽时派遣；在合格的最终权限窗口内不会发生任何提取。在主动准入之外，OPEN/CLOSED 快照稳定性仍然严格。观察和新意图都记录了 REST 传输，而现有的先前 CI 验证者仍然拥有所有 CI 例外、强制审查和安全许可。已选择的 REST 在最终完整重读后、未更改的 evidence/artifact 检查和意图 CAS 之前运行一次；它不会重新开启多余的观察和核查窗口。未知或格式错误的 REST 预测、冲突、不支持的政策和变更的权限拒绝接纳。普通REST仍为合格-check/CLEAN-only； Crabbox 和保留结果调节没有获得新的调度权限。

• 当选择 GraphQL 时，普通立即挤压调度在一次最终显式合并前重新验证后直接使用所选写入器的精确头突变。它保留捕获的正文，省略标题，因此 GitHub 保留其现有默认值，并且无法排队或自动合并。它最初和最后的公开快照束缚了头脑；现有的 REST 源获取绑定了该分支，并且两个独立的派发后接收观察结果仍然是新鲜的。队列、自动、管理、合并和变基保留本机 gh pr merge 调度及其附加权限窗口。

• 新鲜直接PR/main读取和稳定重读窄赛；它们不提供全局一次性执行或基本 OID 合并前提条件。立即压缩拒绝 NO NET CHANGE，而不声明 PR 已合并或所有预期内容仍然存在。普通 squash/merge 收据在实际落地父节点处重建树；合并也需要有准备的祖先。变基和队列收据使用保留的 main/head 的唯一源叉基（而不是最终变基父级或记录的主本身）来验证历史登陆树中的聚合审查增量。缺失或不明确的源库无法关闭。后来的主要进展或恢复不授权重新申请。正常记录的南瓜在其着陆母体处是空的，警告进行调查；其收据仍处于确认状态，不会重新提交或自动恢复。

• 在记录意图之前，--auto-merge 为 MERGEABLE/CLEAN 选择立即固定挤压，或为 MERGEABLE/BEHIND 或 MERGEABLE/BLOCKED 选择自动，受所有准入门和队列策略的约束。已接受的 auto/queue 请求是可见的待处理结果，而不是完成。请求中携带--match-head-commit；确认仍然需要准确的尝试头。这是提交时的头部前提条件，而不是针对稍后协作者推送的服务器端冻结；如果GitHub合并了推送的头，则使用显式的merge-recover --merged-head <SHA> 收货路由。现有的或不明确的请求永远不会自动取消、重新准备或立即回退；明确调查的已接受自动请求使用 取消恢复 。普通gh pr merge在应用队列策略时可以入队。

• --auto-merge 仅在一次新的 scripts/watch-pr-ci.mjs --completion rollup --once 通过精确准备的头部退出 GREEN 后，才为 MERGEABLE/UNSTABLE 选择立即挤压； --once 无需等待即可评估一个附加和一个汇总观察，并且 --timeout 仅限制该传递的证据读取。 GitHub 的汇总和合并投影保留运行被在该头上运行的较新的相同 workflow/event/job-name 取代，例如在 ready_for_review 之后运行的草稿 opened ClawSweeper 调度。观察者的classifyRollup拥有取代会话；该通行证还需要附加的 ci.yml 运行才能成功。任何未被取代的失败、隐藏或分页上下文、缺少运行标识、待检查、移动头、冲突或观察者错误都会拒绝接纳；观察者现有的 auto-response 排除条款保持不变。这是一次性准入谓词，而不是固定快照事实：GitHub 仍然在调度时强制执行所需的检查，精确头部突变固定头部，最终稳定性重读固定 UNSTABLE 投影。固定汇总上下文将扩展 Octopool 允许的登陆快照查询和已绑定的风险服务器实施的保留结果模式。接受的边缘情况：不会重新检查传递和调度之间同一头上的新的非必需故障。保留的意图永远不会重新运行谓词或重新分派；显式恢复重新运行准入。

完整的检查套件读取

必需检查准入将完整套件库存限制在 1,000 个套件，符合 GitHub 的参考检查运行端点限制。使用一个完整的、分页的最新检查运行快照（不带名称过滤器）（按套件 ID 分组），然后使用第二个完整套件清单，证明所需应用程序中未呈现的不成功套件是不相关的。每个选定的套件必须具有准确的检查计数、唯一的检查身份、匹配的头和应用程序、不需要的上下文以及未更改的状态、结论、更新时间和计数。缺少或矛盾的页面以及更改的库存将拒绝入场。限制是套房，而不是支票运行；许多跳过或空的套件不需要每个套件 API 子流程。