OpenClaw Landable Bug Sweep

OpenClaw Landable Bug Sweep은(는) 무엇을 하나요?

자동화된 유지보수 워크플로우로서 요청된 배치 크기만큼의 머지 가능한 OpenClaw 버그 수정 PR URL을 생성합니다. 기준이 높고 출력이 PR(메모가 아님)이어야 하는 광범위한 이슈/PR 정리에 사용합니다. 플러그인 SDK/API 경계 작업에는 사용하지 마십시오. 해당 작업은 별도의 아키텍처 리뷰가 필요합니다.

Target

요청의 batch_size를 사용하며 기본값은 5, 최대값은 20입니다. 최대 그만큼의 적격 PR URL을 반환하며 각 항목마다 다음을 포함해야 합니다:

• 버그 요약
• 수정이 저위험인 이유
• 증거: 리베이스된 헤드의 로컬/Testbox/라이브 명령 또는 실행 ID
• 자동 리뷰: 표시되는 정확한 헤드에 대한 깔끔한 결과
• 푸시된 정확한 PR 헤드의 CI 초록색
• 이슈/중복 정리 완료 또는 보류 중 여부

URL은 검토/수정된 기존 PR이거나 이슈/클러스터에서 생성된 새 PR일 수 있습니다. 현재 main에서 새로고침되고, 왼쪽 테스트를 거치고, 자동 리뷰가 깔끔하게 통과되고, 푸시되고, 라이브 GitHub CI에서 초록색으로 확인될 때까지 유지보수 담당자에게 PR URL을 제시하지 마십시오. 자동 리뷰 후 코드, 테스트, 변경 로그, PR 본문 또는 브랜치 베이스가 변경되면 URL을 보여주기 전에 자동 리뷰를 다시 실행하십시오. 검색 범위 내에서 적격 PR이 더 적게 나오면 배치를 억지로 채우지 마십시오.

Inputs

• batch_size: 요청된 머지 가능한 PR 수; 기본값 5, 최대값 20.
• source_mode: discovery 또는 provided-prs; 기본값 discovery.
• provided_prs: source_mode=provided-prs일 때 명시적 PR 참조.

provided-prs 모드에서는 제공된 PR과 직접 연결된 중복/정규 참조만 검사합니다. 단, 최선의 수정을 증명하기 위해 더 넓은 탐색이 필요한 경우는 예외입니다.

Companion Skills

발견/클러스터링에는 $gitcrawl, 라이브 GitHub 변형 규칙에는 $openclaw-pr-maintainer, 기여자 신뢰도가 중요할 때는 $github-author-context, 증거 선택에는 $openclaw-testing, 게시/머지 전에는 $autoreview, 광범위/E2E/라이브 증거에는 $crabbox를 사용하십시오.

Candidate Bar

다음 모든 조건이 참일 때만 수락하십시오:

• 버그 또는 페이퍼 컷(paper cut)이며 기능/제품/지원/문서 전용이 아님
• 근본 원인이 현재 코드에서 입증됨
• 관련 종속성 동작이 상위 저장소 문서/소스/타입을 통해 확인됨
• 프로덕션/런타임 diff가 작고, 이상적으로는 500 LOC보다 훨씬 작으며 항상 500 LOC 미만
• 테스트는 더 클 수 있지만 집중적이어야 함
• 새로운 종속성 없음
• 새로운 설정 옵션 없음
• 하위 호환성을 깨는 동작 없음
• 보안/제품/소유자 경계 결정 불필요
• 플러그인 SDK, 공개 플러그인 API, 또는 src/plugin-sdk/** 경계 변경 없음
• 광범위한 리팩터링 냄새 없음
• 집중된 증명이 가능함
• 브랜치를 리베이스/새로고침하여 푸시할 수 있거나 대체 PR을 생성할 수 있음

좋은 예:

• 종속성/API 계약에 대해 입증된 공급자 매개변수 불일치
• CLI 명령이 인접 명령 동작과 다른 경우
• 실패하는 테스트가 있는 좁은 런타임 상태/직렬화 버그
• 현재 main에서 이미 수정되었으며 증거와 함께 닫을 수 있는 중복 이슈

거부:

• 기능 요청, 새로운 노브, 마이그레이션, 릴리스 작업, 워크플로우 정책, 지원
• 플러그인 SDK/API 경계 변경 (호환성 셰임, 새 SDK 메서드, SDK 내보내기, 또는 플러그인 직면 채널/공급자 이음새 포함)
• 명시적으로 할당되지 않은 인증/보안 경계 변경
• 라이브 자격 증명이 필요하지만 사용할 수 없는 버그
• CI가 빨간색인 PR (단, 직접 수정, 리베이스, 푸시, 재확인하여 초록색으로 만들지 않는 한)
• 로컬에서만 리뷰하고 새로고침/푸시/라이브 확인하지 않은 PR
• 최종 헤드가 $autoreview를 통과하지 못한 PR
• 더 큰 아키텍처 이동인 수정 형태
• 재현 가능/입증 가능한 원인 없는 추측성 보고서
• 제품 판단이 필요한 UI/UX 변경

Sweep Loop

1. 깨끗하게 시작:
   • git status -sb
   • git pull --ff-only
   • 브랜치가 예상된 것인지 확인 (보통 main)
2. 후보 클러스터 구축:
   • gitcrawl로 열린 이슈/PR, 이웃, 검색
   • 라이브 gh issue/pr view
   • 이슈와 중복에서 연결된 PR 포함
3. 각 클러스터에 대해:
   • 이슈/PR 본문, 댓글, 레이블, 연결된 참조, 현재 소스, 인접 테스트 읽기
   • 광범위 접근 권한이 있는 유지보수 담당자가 작성한 PR은 created_at이 최소 14일 지날 때까지 제외; 명명된 PR 또는 명시적 유지보수 담당자 작업 요청만 무시
   • 오프너/작성자 식별 및 크레딧 유지
   • 결정: repair-existing-pr, create-new-pr, close-fixed-on-main, close-duplicate, 또는 reject
4. 패치 전 증명:
   • 실패하는 테스트, 집중된 재현, 로그/소스 증명, 또는 종속성 계약 증명
   • 이미 main에서 수정된 경우 현재 소스/테스트/커밋으로 증명하고 친절하게 닫기
5. 패치:
   • 기존 PR이 괜찮고 쓰기 가능하면 선호
   • 쓰기 불가능하거나 형태가 잘못된 경우 자체 PR 생성하고 유용한 기여자 크레딧 유지
   • PR이 없으면 새로 생성
   • 적합할 때 회귀 테스트 추가
   • 사용자 대상 수정의 경우 PR 본문이나 커밋 메시지에 릴리스 노트 컨텍스트 포함; 알려진 경우 인간 보고자/기여자 크레딧 표시
6. 리뷰, 새로고침, 게시:
   • 현재 origin/main에 대해 PR 브랜치를 리베이스하거나 새로고침
   • 새로 드러난 CI 실패를 포함한 드리프트를 해결하고 PR을 준비된 것으로 간주하지 않음
   • 일반 스위프 PR 중에는 CHANGELOG.md를 추가하지 않음; 릴리스 자동화가 PR과 커밋에서 생성함
   • 리베이스된 헤드를 버그를 증명하는 가장 작고 의미 있는 로컬/Testbox/라이브 명령으로 왼쪽 테스트
   • $autoreview를 실행하여 PR URL을 생성/업데이트/제시하기 전에 수락되거나 실행 가능한 소견이 없을 때까지 반복
   • 실제 본문과 증거 필드가 있는 PR 생성/업데이트
   • 정확히 리뷰된 헤드를 푸시
   • 푸시된 헤드에 대해 라이브 GitHub CI가 초록색인지 확인; 보류 중, 빨간색, 더티, 충돌, 또는 외부 차단 PR은 다섯 개로 집계하지 않음
7. 위생:
   • 스위프 중 발견 즉시 중복 및 main에서 수정된 이슈/PR을 증거와 함께 닫기
   • 명시적 확인 없이 한 클러스터에서 5개 이상의 관련 항목을 변경하지 않음
   • 댓글은 친절하고 구체적이어야 하며 증거/PR/커밋 링크 포함
8. batch_size 개의 머지 가능한 PR URL이 준비되거나 한정된 적격 큐가 소진될 때까지 반복

PR Body Proof

저장소 PR 템플릿을 사용하십시오. ## What Problem This Solves 및 ## Evidence 섹션을 직접 작성하여 포함하십시오. 본문은 의도와 가장 유용한 검증 증거에 초점을 맞추십시오. 코드, 테스트, CI를 검사한 후 정확성을 판단하십시오.

Existing PR Rules

• 신뢰하기 전에 diff 너머의 코드 경로를 검토하십시오.
• PR이 좋다면: 현재 main에 리베이스/새로고침, 작은 문제 수정, 왼쪽 테스트, 자동 리뷰 깔끔, 푸시, CI 초록색 확보 후 보여주거나 집계.
• PR이 좋지 않지만 유용한 아이디어가 있다면: 로컬에서 재생성, 필요 시 공동 저자로 추가, 원본을 감사와 설명과 함께 닫기.
• PR이 중복이거나 main에서 수정되었다면: 증거와 함께 댓글 달고 닫기.
• 유지보수 담당자가 기여자 브랜치에 푸시할 수 없다면: 자체 브랜치/PR 생성, 유용한 커밋이나 크레딧 유지.
• 로컬 증명 후 CI가 빨간색으로 바뀌면 정상 작업으로 처리: 실패한 작업 검사, 수정 또는 거부, 재실행, PR이 초록색이 된 후에만 집계.

Output Ledger

실행 중인 원장을 유지하십시오:

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

rejected:
- ref:
  reason:

closed:
- ref:
  reason:
  proof/comment:

최종 답변:

• 요청된 수의 수락된 PR URL, 또는 더 작은 적격 개수와 검색 소진 이유
• PR당 2-4문장 설명
• PR당 증거/CI 상태
• 닫힌 중복/main에서 수정된 참조
• 현재 브랜치/상태