【免费下载链接】NemoClawRun agents like Hermes, LangChain Deep Agents, and OpenClaw more securely inside NVIDIA OpenShell with managed inference项目地址https://gitcode.com/gh_mirrors/ne/NemoClaw点击查看免费下载NemoClaw 维护者技能 nemoclaw-maintainer-pr-comparator 用于在同一个 issue 存在多个竞争 PR 时基于审查证据比较候选并推荐合并或打捞salvage对象。其中 Tier 0 是整套比较流程的资格层——六道门禁全部通过PR 才可能被推荐合并任何一道失败PR 即被淘汰。本文以 Tier 0 — Eligibility Gates 为骨架结合仓库中collect-gates.sh、check-coderabbit-threads.sh两个脚本的源码实现逐条拆解六道门禁的判定规则、常见失败模式、底层调用链与输出结构并说明其如何联动 Tier 3 的降级模式degraded mode。Tier 0 在整个比较流程中的位置在进入门禁判定之前先厘清上下文。PR Comparator 的完整工作流见 SKILL.md共九步解析 issuegh issue view issue-number --json title,body,comments从正文和评论中提取验收标准用 find-candidates.sh 发现候选 PR先找显式关联 issue 的 PR不足 2 个时按文件路径、标题 token 的 Jaccard 相似度 ≥ 0.4 依次扩展最多 10 个用 parse-supersession.sh 检测被取代/转移工作关系Tier 0六道资格门禁本文主题Tier 1六项正确性检查tier-1-correctness.mdTier 2四项质量检查tier-2-quality.md加权打分Tier 1 每项权重 2.0Tier 2 每项权重 1.0满分 16.0Tier 3 排序tiebreakers.md输出裁决render-verdict.py verdict.md 模板。Tier 0 是硬性门槛All six gates are required. A PR that fails a gate cannot merge.六道门禁全部必需任一失败即不可合并。它把资格判定与质量打分严格分离只有六道门禁全部为true的 PR 才进入 happy-path 评分其余一律先被淘汰。六道门禁总览与运行方式六道门禁分别是门禁主题判定要点Gate 1PR state OPENstate必须为OPENGate 2CI passes on the PR SHA目标 SHA 上所有必需检查通过Gate 3Mergeable, no conflictsmergeable: MERGEABLE且mergeStateStatus: CLEANGate 4Contributor compliancePR 正文含Signed-off-by:且 GitHub 显示每个 commit 为VerifiedGate 5Branch protectionreviewDecision: APPROVED且分支保护检查全部通过Gate 6Automated reviewer threads resolved自动审查线程全部resolved: true运行方式两条命令分别覆盖 1–5 与 6scripts/collect-gates.sh pr # gates 1 到 5 scripts/check-coderabbit-threads.sh pr # gate 6其中collect-gates.sh位于 .agents/skills/nemoclaw-maintainer-pr-comparator/scripts/collect-gates.sh以 JSON 形式输出门禁状态供下游评分check-coderabbit-threads.sh位于 .agents/skills/nemoclaw-maintainer-pr-comparator/scripts/check-coderabbit-threads.sh专查自动审查线程。值得注意的安全细节技能要求所有辅助脚本从已 fetch 的 canonicalmaincheckout 执行或核实其可执行代码后再用被候选人改过的 helper 不得接触 GitHub 凭据。nemoclaw-maintainer-day技能中的 run-trusted-check-gates.sh 正是这一约束的实现——它会校验origin必须指向NVIDIA/NemoClaw、用临时 worktree 检出远端main并对check-gates.ts、shared.ts做逐字节比对cmp -s后才执行防止门禁脚本被本地污染。Gate 1PR 状态必须为 OPEN规则本身极简PR 的state字段必须是OPENCLOSED或MERGED的 PR 无论其他属性如何都不再是合法合并候选。这条门禁的动机在文档中写得很直白没有它排序可能选中一个 diff 与某个 open PR 匹配的 closed PR。例如两个 PR 内容逐字节相同旧的那个被关闭并标记为被取代若关闭状态不构成淘汰条件排序器可能在新鲜度等维度上误选已关闭的旧 PR。回测记录validation/backtest.md印证了这一来源Case where two PRs were byte-identical and the older one was closed-then-superseded → added Tier 0 gate PR state must be OPEN——正是这个历史案例催生了 Gate 1。在 collect-gates.sh 中实现非常直接通过gh pr view抓取state然后用字符串比较得出布尔值state$(printf %s $raw | jq -r .state) gate_state_open$([ $state OPEN ] echo true || echo false)脚本对 PR 号先做^[0-9]$正则校验非法输入会输出{pr: ..., error: invalid_pr_number}并直接返回避免把非法参数传给gh。Gate 2CI 在 PR SHA 上通过要求 PR 当前提交 SHA 上的所有必需检查全部通过。若作者又推了新 commit则记录其短 SHA 并等待该 commit 的检查结果——判定始终针对最新 SHA而不是历史上某次绿过的 commit。collect-gates.sh返回该 SHA 与每个检查的状态需要与 repo-policy.md 中声明的必需检查列表比对。从实现看Gate 2 的判定逻辑有四个层次全部采用fail-closed失败即关闭策略必需检查缺失即失败。脚本内置required_checks[checks,check-hash,changes,commit-lint,dco-check]用statusCheckRollup中的检查名集合求差集$required - $observed任何缺失都计入missing_check_count连同空 rollup 一起按失败处理。已完成但非成功的 CheckRun/StatusContext 按失败处理。ci_failing_checks用 jq 过滤状态上下文.state非SUCCESS/PENDING/EXPECTED即计入失败CheckRun 则要求status COMPLETED且conclusion不属于SUCCESS/NEUTRAL/SKIPPED才计入失败。未完成的检查按 pending 处理PENDING、EXPECTED或空状态都算。E2E 前向检查advisory豁免。旧有的 PR E2E 上下文E2E / PR Gate、E2E / PR Gate / Rollup、E2E / PR Gate Coordination被标记为 advisory但仅当workflowName不是E2E / PR Gate Controller时才豁免——这避免了历史遗留的 E2E 检查噪音误伤新 PR。最终gate_ci_green只有在失败数、pending 数、缺失检查数三者全部为 0 时才为true。这条门禁的失败即关闭哲学与仓库 CI 中已有的覆盖率只升不降ratchet约束一致——详见 repo-policy.md 中coverage_ratchet_enforced_via_ci: true的说明。Gate 3可合并、无冲突要求同时满足两个条件mergeable: MERGEABLEmergeStateStatus: CLEAN即 PR 必须能干净地合并进其目标基础分支。文档列出的常见失败模式CONFLICTING—— 基础分支已分叉产生冲突DIRTY—— 暂存变更阻碍合并通常是合并提交或 rebase 遗留的本地脏状态BLOCKED—— 必需检查失败或审查缺失。从实现看collect-gates.sh二者缺一不可mergeable$(printf %s $raw | jq -r .mergeable) merge_state$(printf %s $raw | jq -r .mergeStateStatus) gate_mergeable$([ $mergeable MERGEABLE ] [ $merge_state CLEAN ] echo true || echo false)与 Gate 1 一样gh pr view的--json mergeable,mergeStateStatus直接来自 GitHub API脚本只做判定不做推断。在输出 JSON 中mergeable与merge_state_status会被原样写入details段供维护者排查具体是哪一种失败模式。Gate 4贡献者合规这是唯一被归类为ineligible不合格不可打捞的门禁要求同时满足两点PR 正文必须包含贡献者的Signed-off-by:声明DCOGitHub 必须将每个 commit 显示为Verified签名已验证。文档强调A passing CI job does not replace either check.——CI 通过不能替代 DCO 或 commit 签名验证失败必须由贡献者自行纠正维护者不得替贡献者 amend、签名、force-push、approve 或 merge。从实现看DCO 声明用正则严格匹配 PR bodyprintf %s $raw | jq -r .body // | grep -Eq ^Signed-off-by:[[:space:]].[[:space:]][^[:space:]][^[:space:]][[:space:]]*$即必须以Signed-off-by:开头包含名字与合法的邮箱形式。唯一的例外是作者为app/dependabot或dependabot[bot]时dco_declaration_bypassedtrue——依赖机器人提交的 PR 豁免 DCO 正文要求它无法人工签署。这与 repo-policy.md 中dco_required: true、dco_location: pr_description、github_verified_signatures_required: true的策略一一对应且文档明确说明dco-checkworkflow、comparator 与 merge gate 三者都会检查 DCO形成多层防线。commit 验证则通过 REST API 单独拉取gh api repos/$repo_name/pulls/$pr/commits --paginate \ --jq .[] | {sha, verified: (.commit.verification.verified // false), reason: (.commit.verification.reason // unknown)}随后统计unverified_countverified ! true的 commit。只有DCO 存在或 dependabot 豁免且未验证 commit 数为 0 时gate_contributor_compliance才为true。fetch 失败或解析失败都会 fail-closed 置为false并分别记录commit_fetch_failed/commit_parse_failed标志以便排查。Gate 5分支保护要求reviewDecision: APPROVED且所有分支保护检查通过并用分支保护来强制执行 CODEOWNERS。Gate 4 依然独立负责 DCO 与 commit 签名验证——三层责任DCO、签名、分支保护彼此不替代。如果分支保护没有强制 CODEOWNERS则须在 repo-policy.md 中配置codeowners_enforced_via_branch_protection: false并另行配置团队检查team checks。实现上Gate 5 以reviewDecision作为分支保护的代理指标collect-gates.shreview_decision$(printf %s $raw | jq -r .reviewDecision) gate_branch_protection$([ $review_decision APPROVED ] echo true || echo false)注意reviewDecision为APPROVED意味着 PR 已获得满足仓库要求的批准GitHub 会综合 CODEOWNERS 与 required reviewers 计算因此技能信任分支保护已配置正确的审查团队repo-policy.md的默认值为codeowners_enforced_via_branch_protection: true。Gate 6自动审查线程全部解决每个自动审查automated review线程必须resolved: true。技术要点REST 评论接口不暴露线程解决状态必须通过 GraphQL 查询pullRequest.reviewThreads.isResolved。这正是check-coderabbit-threads.sh存在的理由其核心查询为query($owner: String!, $name: String!, $pr: Int!) { repository(owner: $owner, name: $name) { pullRequest(number: $pr) { reviewThreads(first: 100) { nodes { id isResolved comments(first: 1) { nodes { author { login } } } } } } } }实现细节check-coderabbit-threads.sh用 jq 过滤出首条评论作者等于配置的 bot 登录名的线程避免把人类审查线程也算进去统计total_bot_threads、unresolved_bot_threads与未解决线程的id列表gate_coderabbit_threads_resolved在未解决数为 0 时为true仓库与 bot 可分别用--repo OWNER/REPO与--bot LOGIN覆盖默认 bot 为coderabbitai。Bot 名单在 repo-policy.md 的auto_reviewers下配置默认即 CodeRabbitauto_reviewers: - login: coderabbitai is_bot: true require_resolution: true若仓库改用 Copilot、Gemini Code Assist 等把它们的 bot 登录名加进来即可脚本按此过滤。另外SKILL.md 明确要求 PR Review Advisor 的输出只能作为维护者审查的输入不能当作合并授权——自动审查线程解决状态是资格条件而非替代人类审查。输出结构逐门禁记录证据与失败分类对于每一道门禁技能记录三件事见 tier-0-gates.md通过/失败pass/fail证据短 SHA、检查名、合并状态、线程 ID失败性质分类ineligible / trivial / substantive。collect-gates.sh产出的 JSON 完整结构源码末尾分三部分{ pr: 2851, head_sha: full-sha, gates: { state_open: true, ci_green_sha: true, mergeable: true, contributor_compliance: true, branch_protection: true }, details: { state: OPEN, ci_failure_count: 0, ci_pending_count: 0, ci_failing_checks: [], ci_pending_checks: [], ci_missing_required_checks: [], mergeable: MERGEABLE, merge_state_status: CLEAN, dco_declaration_present: true, dco_declaration_bypassed: false, commit_count: 3, unverified_commits: [], commit_fetch_failed: false, commit_parse_failed: false, review_decision: APPROVED }, failures: [] }失败分类在脚本中直接生成collect-gates.shineligibleineligible:contributor_compliancePR 正文缺 DCO 或存在未验证 commitsubstantivesubstantive:not_open、substantive:ci_failuresN,pendingM,missing...、substantive:mergeable...,state...、substantive:review...trivial文档示例为缺失 issue 链接、基础分支过期等可轻量修复项脚本注释表明当前 Gate 1–5 中除 CI/合并/审查外的场景均按 substantive 处理trivial 主要来自门禁之外的检查维度如 stale base。失败分类如何驱动降级模式这个 ineligible/trivial/substantive 三分法直接喂给 Tier 3 的降级模式详见 tiebreakers.mdhappy mode至少一个 PR 六门全过淘汰一切未过 Tier 0 的 PR在幸存者中按 Tier 1–2 加权分排序再依次用更小 diff → 更优负向测试覆盖 → 更近活动 → 更小 PR 号四个平局裁决器degraded mode无 PR 通过 Tier 0ineligible 的 PR 直接拒绝而非参与打捞排序——Ineligible PRs are rejected rather than ranked for salvage. 因为 DCO/签名问题必须由贡献者重建合规历史不是维护者补丁能救的其余候选按离就绪的距离排序substantive 失败少者优先其次 trivial 少者再次看 Tier 1/2 加权分。裁决渲染器 render-verdict.py 对这套资格逻辑做了程序化强校验Tier 0 的六个键state_open、ci_green_sha、mergeable、contributor_compliance、branch_protection、coderabbit_threads_resolved必须齐全、无未知键、且值必须是布尔类型否则拒绝渲染并返回退出码 64winner必须是六门全过的候选closest_to_ready只能在 degraded 模式下指向open 且 contributor-compliant的候选。这些约束与 tier-0-gates.md 的规则逐条对应确保任何裁决结果都不可能绕过资格门禁。维护者在实战中的核查清单综合文档与源码运行 Tier 0 后建议按如下顺序核查先看failures数组出现ineligible:contributor_compliance时停止打分让贡献者补 PR 正文 DCO 或重建签名合规的 commit 历史维护者不得代劳Gate 2 关注head_sha与ci_missing_required_checks确认判定针对最新 SHA且checks、check-hash、changes、commit-lint、dco-check五项必需检查无一缺失旧 E2E advisory 上下文不应误伤Gate 3 区分merge_state_statusCONFLICTING需要 rebaseDIRTY需要清理本地暂存态BLOCKED往往与 Gate 2/5 的失败同源Gate 5/6 协同看reviewDecision非APPROVED时检查 CODEOWNERS 配置与codeowners_enforced_via_branch_protection开关Gate 6 则用check-coderabbit-threads.sh --bot login核实未解决线程 ID 列表落地到裁决用 templates/verdict.md 的输出形态把每道门禁的文件/行号或 SHA 证据 → 观察到的事实 → 推断 → 得分四要素写进 reasoning trace再交给render-verdict.py渲染渲染器退出码非 0 时禁止推荐合并。如果要在信任新决策前验证这套门禁自身的可靠性可参照 validation/backtest.md 用历史已收官的 PR 竞争回测目标误报率 10%、漏报率 5%、模糊率 10%——这既是技能质量的门禁也是 Tier 0 六道资格门禁持续演进的依据来源。赞分享【免费下载链接】NemoClawRun agents like Hermes, LangChain Deep Agents, and OpenClaw more securely inside NVIDIA OpenShell with managed inference项目地址https://gitcode.com/gh_mirrors/ne/NemoClaw点击查看免费下载相关推荐NemoClaw 风险代码区域清单PR 审查门禁与测试覆盖的判定依据NemoClaw 风险代码区域清单PR 审查门禁与测试覆盖的判定依据 NemoClaw 将一旦被改动就可能破坏安装、沙箱隔离、网络策略或凭证安全的代码归类NemoClaw PR 评审模型判定Tier 1 正确性六项检查的评分方法与证据规范NemoClaw PR 评审模型判定Tier 1 正确性六项检查的评分方法与证据规范 NemoClaw 开源仓库中内置了一套面向维护者的 PR 比较PR CNemoClaw 维护者 PR 审查优先级与合并门禁体系从硬门禁到每日发布节奏的完整操作手册NemoClaw 维护者 PR 审查优先级与合并门禁体系从硬门禁到每日发布节奏的完整操作手册 导读 NemoClaw 是一个在 NVIDIA OpenShel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考