openclaw-landable-bug-sweep

OpenClaw 可合并修复问题清理

用于生成用户所需的一批可合并 OpenClaw 修复 PR URL 的自主维护者工作流。 适用于标准较高、交付物为 PR 而非备注的大范围问题/PR 清理。 不要用于插件 SDK/API 边界工作；此类工作需要单独进行架构审查。

强制编排约定

• 只有面向原始用户的根对话才是控制平面。它负责拆解工作、明确分配问题/PR/文件的所有权、直接启动范围受限的协作工作者和独立验证者、协调安全事项、跟踪完成情况，并报告经工作者实际验证的最终结果。
• 委派的协作子 Agent 是亲自执行工作的负责人，而不是另一个面向用户的根编排者。它应直接执行分配给它的工作；本约定不得以递归方式阻止工作者行动。只有获得根对话明确授权，并由根对话跟踪容量、所有权和完成情况后，才可启动嵌套工作者。不要创建单独的 Codex 应用任务或线程。
• 工作者负责所有发现、源码/依赖/Codex 检查、复现、问题/PR 调查、编辑/重构、测试/证明/CI、GitHub 读写、评论、关闭、提交、推送，以及任何单独获授权的合并。作出 Codex 判断前，执行该工作的工作者必须亲自验证依赖约定，并检查同级目录中的 ../codex。
• 根对话负责协调检出和文件所有权、串行处理共享 Git/ref/index 变更及相互冲突的测试/编辑活动、跟踪精确的 head，并通过分配给工作者的任务落实授权、来源可信度、安全、所有权和合并门槛。即使工作者停滞、失败或缺乏能力，根对话也不得从编排切换为执行；应重新分配范围受限的工作。

请求的授权范围

• 默认交付物是经验证的可合并 PR URL，而不是已合并的 PR。明确要求“修复并准备”的清理任务，授权工作者在所请求范围内修复、重构、验证、提交、推送和更新 PR；除非明确要求合并，否则不授权合并。
• 单独的 review、triage、list 或 landable-shortlist 仍属于只读操作：不得擅自推送、公开评论、关闭、创建替代 PR 或合并。
• 对指定条目明确提出自主 process、resolve 或 fix-and-land 请求，也授权工作者关闭已证明已在当前 main 上修复的条目，并通过 $openclaw-pr-maintainer 和仓库原生的 scripts/pr 工作流合并已验证的修复。保留精确 head 和所有权门槛。
• 明确授予的全权无人值守执行授权，是对指定清理范围内所有有证据支持工作的持续批准，包括必要的任务专属或仓库管理的 PR 工作树、署名的 PR 修复/替换、证明性评论、精确 head 的 CI 修复、范围限定的发布、已证明在当前 main 上修复条目的关闭，以及用户要求的原生合并。不要询问常规审批问题，也不要干扰无关的脏改动；根对话始终只负责编排，工作者负责执行直至验证完成。保留来源可信度、执行工作的工作者直接检查 Codex、必要的精确 head CI/安全/所有者门槛，以及对超过 50 项关闭/重新打开操作的明确数量/范围批准。
• 只有在用户明确放宽要求时，才可用其他验证方式替代不可用的可选提供方/渠道实时证明：使用失败/通过的、聚焦且绑定所有者边界的回归测试，直接检查生产方/调用方/同级模块/依赖源码的证据，独立审查，以及通过的精确 head 必需 CI；并披露缺失的实时/升级验证。绝不得放弃强制要求的外部 API、安全敏感、风险要求或用户明确要求的实时验证。

目标

使用请求中的 batch_size，默认值为 5，上限为 20。 最多返回指定数量的合格 PR URL，每个都包含：

• Bug 摘要
• 修复为何风险较低
• 证明：精确提交头的本地/Testbox/线上命令或运行 ID
• autoreview：在所示精确提交头上结果无问题
• CI：在精确推送的 PR 提交头上状态为绿色
• 问题/重复项清理已完成或仍待处理

这些 URL 可以指向已审查/修复的现有 PR，也可以指向基于问题/问题集群创建的新 PR。 在精确的已发布提交头完成收尾测试、autoreview 结果无问题且线上 GitHub CI 验证为绿色之前，不要提供 PR URL。 仅在出现实际冲突、精确提交头检查或仓库原生守卫失败、用户明确要求，或已证明存在实质性陈旧基线风险时，才刷新 PR 分支；绝不要仅因 main 前进而变基。 如果 autoreview 后生产代码、测试或受审提交头发生变化，请在提供 URL 前重新运行 autoreview。 如果限定范围搜索找到的合格 PR 少于指定数量，不要凑满该批次。

输入

• batch_size：请求的可落地 PR 数量；默认值为 5，最大值为 20。
• source_mode：discovery 或 provided-prs；默认值为 discovery。
• provided_prs：当 source_mode=provided-prs 时提供的显式 PR 引用。

在 provided-prs 模式下，仅检查所提供的 PR 以及直接关联的重复项/主项引用，除非需要更广泛的检索来证明最佳修复方案。

配套技能

使用 $gitcrawl 进行检索/聚类，使用 $openclaw-pr-maintainer 遵循线上 GitHub 操作规则，需要评估贡献者可信度时使用 $github-author-context，使用 $openclaw-testing 选择证明方式，发布/落地前使用 $autoreview，使用 $crabbox 进行广泛/E2E/线上验证。

候选准入标准

仅当以下所有条件都满足时才接受：

• Bug 或小缺陷，而不是功能/产品/支持/仅文档类事项
• 已在当前代码中证明根因
• 在相关情况下，已通过上游文档/源码/类型检查依赖项行为
• 生产/运行时变更量要小，最好远低于 500 LOC，且始终低于 500 LOC
• 可行时，生产代码 LOC 净持平或净减少；测试单独计数，并为生产代码的任何增量提供理由
• 测试代码量可以更大，但应聚焦
• 不新增依赖项
• 不新增配置项
• 不存在向后不兼容的行为
• 无需作出安全/产品/所有者边界决策
• 不涉及插件 SDK、公开插件 API 或 src/plugin-sdk/** 的边界变更
• 所有重构均须限定在已证明的根因、所有者边界和小范围扫描风险限制内
• 可进行聚焦验证
• 必要时能安全更新现有分支，或能证明采用获授权的替代分支是合理的

良好示例：

• 根据依赖项/API 契约证明了提供方参数不匹配
• CLI 命令的行为与相邻命令不一致
• 范围狭窄的运行时状态/序列化 Bug，且有失败的测试
• 当前 main 上的问题已修复，并有证明且重复项可关闭

拒绝：

• 功能请求、新增调节项、迁移、发布工作、工作流策略或支持工作
• 插件 SDK/API 边界变更，包括兼容层、新 SDK 方法、SDK 导出或面向插件的通道/提供方接缝
• 认证/安全边界变更，除非明确指派处理
• 对于强制的外部 API、安全、 风险要求或明确请求的线上验证需要不可用凭据的 Bug
• CI 为红色的 PR，除非你修复问题、按需更新提交头、推送并重新检查至绿色
• 变更后的提交头未推送，或未在线验证精确提交头 CI 的 PR
• 最终提交头尚未通过 $autoreview 的 PR
• 需要作出超范围的产品、架构或所有权决策的修复
• 没有可复现/可证明原因的推测性报告
• 需要产品判断的 UI/UX 变更

巡检循环

1. 从干净状态开始：
   • git status -sb
   • 仅在确有需要且获得根级授权时，使用 git pull --ff-only 更新干净且专属于你的基础检出
   • 当同级工作进程仍在运行时，绝不对共享检出执行拉取、切换或修改
   • 验证分支符合预期，通常为 main
2. 构建候选集群：
   • 使用 gitcrawl 打开 issue/PR、邻接项及搜索
   • 实时执行 gh issue/pr view
   • 纳入从 issue 链接到的 PR 和重复项
3. 对每个集群：
   • 读取 issue/PR 正文、评论、标签、关联引用、当前源码和邻近测试
   • 若 created_at 距今不足 14 天，则排除由拥有广泛访问权限的维护者创建的 PR；只有明确指定某个 PR 或维护者明确要求处理时才可覆盖此规则
   • 确定发起者/作者并保留署名
   • 作出决定：repair-existing-pr、create-new-pr、fixed-on-main、duplicate 或 reject；仅在获得授权后关闭
4. 修改前先证明：
   • 提供失败测试、针对性复现、日志/源码证据或依赖契约证据
   • 如果 main 上已经修复，则使用当前源码、测试或提交加以证明；仅在获得授权后礼貌关闭
5. 修补：
   • 即使传入的实现形态不正确，也应先重写/重构现有可编辑 PR，使其成为符合所有者边界的正确修复
   • 仅当原分支不可编辑或更新不安全时，才创建已获授权的替代 PR；保留署名，并且只有替代 PR 已存在且关闭操作获得授权后，才关闭源 PR
   • 如果不存在 PR，仅在发布获得授权时创建一个
   • 适用时添加回归测试
   • 在 PR 正文或提交消息中提供面向用户的修复的发布说明上下文；已知时为人类报告者或贡献者保留署名
6. 审查、验证并发布：
   • 仅在出现实际冲突、精确 head 检查或包装器防护失败、收到明确请求，或证实基础分支确有严重陈旧风险时，才刷新 PR 分支
   • 解决实际冲突或 CI 失败，而不是将 PR 视为已准备就绪
   • 正常巡检 PR 中不要添加 CHANGELOG.md；发布自动化工具会根据 PR 和提交生成它
   • 使用能够证明缺陷的最小且有意义的本地、Testbox 或实时命令，对精确的候选 head 执行 left-test
   • 在创建、更新或提供 PR URL 之前，运行 $autoreview，直到不再存在已接受或可操作的发现
   • 获得授权后，使用实际正文和证据字段创建或更新 PR
   • 仅当已授权的变更需要发布时，才推送经过审查的精确 head
   • 验证实时 GitHub CI 对该已推送 head 的状态为绿色；不要将处于等待中、失败、有未提交改动、有冲突或受外部阻塞的 PR 计入这五项
7. 收尾清理：
   • 仅在关闭操作获得授权时，才根据证据关闭重复项以及在 main 上已修复的 issue/PR；否则报告证据
   • 仅当明确授权的有界范围包含相关项时，才可在一个集群中修改超过五项；超过 50 次关闭或重新打开操作仍需单独获得精确数量/范围的批准
   • 评论必须友善、具体，并包含证据、PR 或提交链接
8. 重复执行，直到 batch_size 个可合入的 PR URL 准备就绪，或限定范围内的合格队列耗尽。

PR 正文证明

使用仓库的 PR 模板。包含自行编写的 ## What Problem This Solves 和 ## Evidence 部分。保持正文聚焦于意图和最有用的验证 证据；在判断正确性之前，检查代码、测试和 CI。

现有 PR 规则

• 在信任代码路径之前，审查差异范围之外的代码。
• 如果 PR 质量良好：修复具体问题，对确切的 head 执行 left-test 和自动审查，发布已授权的变更，并在展示之前要求确切的 head 上 CI 通过。
• 如果 PR 不完整或改动层级错误，但可以编辑：在根因所属位置重写/重构现有 PR，保留作者署名，并验证修正后的 head。
• 如果 PR 重复或已在当前 main 上修复：提供证据评论，仅在已获关闭授权时关闭；否则报告证据。
• 如果源分支无法编辑或更新不安全：仅在已获授权时创建替代 PR，保留有用的提交/署名，并且仅在替代 PR 已存在且已获关闭授权后关闭原 PR。
• 如果本地验证通过后 CI 变为红色，将其视为正常情况：检查失败的任务，修复或拒绝，重新运行，并且仅在 CI 通过后计入该 PR。

输出台账

持续维护一份动态台账：

accepted:
- PR URL:
  source refs:
  bug:
  root cause:
  fix:
  production LOC:
  test LOC:
  risk:
  head/base status:
  left-test:
  autoreview:
  CI:
  credit/thanks:
  cleanup:

rejected:
- ref:
  reason:

closed:
- ref:
  reason:
  proof/comment:

最终答案：

• 符合请求数量的已接受 PR URL；若数量不足，则给出实际合格数量及搜索已穷尽的原因
• 每个 PR 的 2-4 句说明
• 每个 PR 的证据/CI 状态
• 已关闭的重复项/已在 main 上修复的引用
• 当前分支/状态