PR 베이비시터

PR 베이비시터은(는) 무엇을 하나요?

목표

다음 종료 결과 중 하나가 발생할 때까지 PR을 지속적으로 모니터링합니다:

• PR이 병합 또는 닫힘.
• 사용자 도움이 필요한 상황 발생 (예: CI 인프라 문제, 재시도 예산 소진 후 반복되는 변덕스러운 실패, 권한 문제, 안전하게 해결할 수 없는 모호성).
• 선택적 중간 이정표: PR이 현재 녹색(통과) + 병합 가능 + 리뷰 클린 상태. 이는 진행 상태로 간주하며, PR이 열려 있는 동안 늦게 도착하는 리뷰 코멘트가 신속하게 표시되도록 모니터링을 중단하지 않습니다.

단일 스냅샷이 검사가 아직 진행 중인데 idle을 반환한다고 해서 중단하지 마십시오.

입력

다음 중 하나를 허용합니다:

• PR 인자 없음: 현재 브랜치에서 PR을 추론 (--pr auto)
• PR 번호
• PR URL

핵심 워크플로

1. 사용자가 PR을 "모니터링"/"감시"/"베이비시팅"하도록 요청하면, 의도적으로 일회성 진단 스냅샷을 수행하지 않는 한 감시자의 연속 모드(--watch)로 시작합니다.
2. 감시자 스크립트를 실행하여 PR/리뷰/CI 상태를 스냅샷으로 캡처합니다 (또는 --watch에서 각 스트리밍 스냅샷을 소비합니다).
3. JSON 응답의 actions 목록을 검사합니다.
4. diagnose_ci_failure가 있으면 실패한 실행 로그를 검사하고 실패를 분류합니다.
5. 실패가 현재 브랜치로 인한 것 같으면 코드를 로컬에서 패치하고, 커밋하고, 푸시합니다. 변덕스러운 테스트, CI 인프라, 종속성 중단, 실행자 문제 또는 브랜치와 관련 없는 기타 실패는 패치하지 마십시오.
6. process_review_comment가 있으면 표시된 게시된 리뷰 항목을 검사하고 이를 처리할지 결정합니다.
7. 리뷰 항목이 실행 가능하고 올바르면 코드를 로컬에서 패치하고, 커밋하고, 푸시한 다음, 아래 GitHub 상태 변경 정책에서 허용하는 경우에만 연결된 리뷰 스레드를 해결합니다.
8. 사용자가 정확한 응답을 명시적으로 확인하지 않는 한 인간이 작성한 리뷰 코멘트/스레드에 답글을 게시하지 마십시오. 인간 리뷰 항목이 실행 불가능하거나, 이미 처리되었거나, 유효하지 않은 경우 GitHub에 답글을 게시하는 대신 항목과 권장 응답을 사용자에게 표시합니다.
9. 실패가 변덕스럽거나 관련이 없으며 retry_failed_checks가 있으면 --retry-failed-now로 실패한 작업을 다시 실행합니다.
10. 실행 가능한 리뷰 피드백과 retry_failed_checks가 모두 있으면 리뷰 피드백을 우선 처리합니다. 새 커밋이 CI를 다시 트리거하므로, 의도적으로 리뷰 변경을 지연하지 않는 한 이전 SHA에서 변덕스러운 검사를 다시 실행하지 않습니다.
11. 각 루프에서 CI 실패 또는 병합 가능 상태에 대해 작업하기 전에 새로 표시된 리뷰 피드백을 찾은 다음, CI와 함께 병합 가능성/병합 충돌 상태를 확인합니다 (예: gh pr view 사용).
12. 푸시 또는 재실행 작업 후 즉시 1단계로 돌아가 업데이트된 SHA/상태를 계속 폴링합니다.
13. 패치/커밋/푸시를 위해 일시 중지하기 전에 --watch를 사용 중이었다면, 푸시 직후 같은 턴에서 --watch를 다시 시작합니다 (사용자가 스킬을 다시 호출할 때까지 기다리지 않습니다).
14. stop_pr_closed가 나타나거나 사용자 도움이 필요한 차단기에 도달할 때까지 폴링을 반복합니다. 녹색 + 리뷰 클린 + 병합 가능한 PR은 진행 이정표일 뿐, PR이 열려 있는 동안 감시자를 중단하는 이유가 아닙니다.
15. 터미널/세션 소유권 유지: 베이비시팅이 활성화되어 있는 동안 같은 턴에서 감시자 출력을 계속 소비합니다. 분리된 --watch 프로세스를 실행 중인 상태로 두고 마치 모니터링이 완료된 것처럼 턴을 종료하지 마십시오.

명령

일회성 스냅샷

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --once

연속 감시 (JSONL)

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --watch

변덕스러운 재시도 트리거 (감시자가 표시할 때만)

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --retry-failed-now

명시적 PR 대상

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr <number-or-url> --once

CI 실패 분류

재실행을 결정하기 전에 gh 명령을 사용하여 실패한 실행을 검사합니다.

• gh run view <run-id> --json jobs,name,workflowName,conclusion,status,url,headSha
• gh api repos/<owner>/<repo>/actions/runs/<run-id>/jobs -X GET -f per_page=100
• gh api repos/<owner>/<repo>/actions/jobs/<job-id>/logs > /tmp/codex-gh-job-<job-id>-logs.zip
• gh run view <run-id> --log-failed (전체 워크플로 실행이 완료된 후 대체 방법)

gh run view --log-failed는 워크플로 실행 범위이며, 전체 실행이 완료될 때까지 실패한 작업 로그를 노출하지 않을 수 있습니다. 더 빠른 진단을 위해 먼저 실행의 작업을 폴링하고, 특정 작업이 실패하는 즉시 Actions 작업 로그 엔드포인트에서 해당 작업의 로그를 직접 가져옵니다. 감시자는 GitHub이 노출할 때 각 실패한 작업의 job_id 및 logs_endpoint가 포함된 failed_jobs 목록을 포함합니다.

실패한 작업 로그가 변경된 코드(영향을 받는 영역의 컴파일/테스트/린트/타입체크/스냅샷/정적 분석)를 가리킬 때 실패를 브랜치 관련으로 처리하는 것을 선호합니다.

로그가 일시적인 인프라/외부 문제(시간 초과, 실행자 프로비저닝 실패, 레지스트리/네트워크 중단, GitHub Actions 인프라 오류)를 보여줄 때 실패를 변덕스럽거나 관련 없는 것으로 처리하는 것을 선호합니다.

로그가 PR 브랜치에 실패를 명확히 연결하지 않는 한, 변덕스럽거나 관련 없는 실패를 수정하기 위해 테스트, 빌드 스크립트, CI 구성, 종속성 핀 또는 인프라 인접 코드를 변경하려고 시도하지 마십시오. 변덕스럽거나 관련 없는 실패의 경우, 감시자가 retry_failed_checks를 권장할 때만 재실행하고, 그렇지 않으면 사용자 도움을 기다리거나 중단합니다.

분류가 모호한 경우, 재실행을 선택하기 전에 한 번의 수동 진단 시도를 수행합니다.

간결한 체크리스트는 .codex/skills/babysit-pr/references/heuristics.md를 읽으십시오.

리뷰 코멘트 처리

감시자는 다음에서 리뷰 항목을 표시합니다:

• PR 이슈 코멘트
• 인라인 리뷰 코멘트
• 리뷰 제출 (COMMENT / APPROVED / CHANGES_REQUESTED)

게시된 피드백에 대해서만 작업하십시오. GitHub의 PENDING 상태인 리뷰 제출 및 해당 보류 리뷰에 첨부된 인라인 코멘트는 무시하십시오. 보류 중인 리뷰 피드백을 본 것으로 표시하지 마십시오. 리뷰어가 리뷰를 제출한 후 표시될 수 있어야 합니다.

인간 리뷰어 피드백 외에도 Codex 리뷰어 봇 피드백(예: chatgpt-codex-connector[bot]의 코멘트/리뷰)을 의도적으로 표시합니다. 대부분의 관련 없는 봇 노이즈는 여전히 무시해야 합니다. 안전을 위해, 감시자는 신뢰할 수 있는 인간 리뷰 작성자(예: 리포지토리 OWNER/MEMBER/COLLABORATOR 및 인증된 운영자)와 승인된 리뷰 봇(예: Codex)만 자동으로 표시합니다. 새 감시자 상태 파일에서, 기존의 미해결 게시된 리뷰 피드백이 즉시 표시될 수 있습니다(모니터링 시작 후 도착하는 코멘트만이 아닙니다). 이는 이미 열려 있는 리뷰 코멘트를 놓치지 않도록 의도된 것입니다.

코멘트에 동의하고 실행 가능한 경우:

1. 코드를 로컬에서 패치합니다.
2. codex: address PR review feedback (#<n>)로 커밋합니다.
3. PR 헤드 브랜치로 푸시합니다.
4. 푸시가 성공한 후, 아래 GitHub 상태 변경 정책에서 허용하는 경우에만 연결된 GitHub 리뷰 스레드를 해결합니다.
5. 새 SHA에서 즉시 감시를 재개합니다(푸시를 보고한 후 중단하지 않음).
6. 모니터링이 --watch 모드로 실행 중인 경우, 같은 턴에서 푸시 직후 --watch를 다시 시작합니다. 사용자가 다시 요청할 때까지 기다리지 마십시오.

인간이 작성한 GitHub 리뷰 코멘트/스레드에 자동으로 답글을 게시하지 마십시오. 인간 코멘트에 동의하지 않거나, 실행 불가능/이미 처리되었다고 생각하거나, 질문에 답해야 하는 경우 항목을 사용자에게 제안된 응답과 함께 보고하고 GitHub에 게시하기 전에 명시적 확인을 기다리십시오. 사용자가 응답을 승인하면 [codex] 접두사를 붙여 응답이 자동화되었으며 인간 사용자가 보낸 것이 아님을 명확히 합니다. 감시자가 나중에 인증된 운영자를 신뢰할 수 있는 리뷰 작성자로 취급하기 때문에 승인된 답글을 표시하는 경우, 해당 자체 작성 항목을 이미 처리된 것으로 간주하고 다시 답글을 게시하지 마십시오. 코드 리뷰 코멘트/스레드가 GitHub에서 이미 해결된 것으로 표시된 경우, 새로운 해결되지 않은 후속 피드백이 나타나지 않는 한 실행 불가능한 것으로 간주하고 안전하게 무시하십시오.

GitHub 상태 변경 정책

모니터링에 필요한 모든 PR 상태를 읽을 수 있습니다. 쓰기는 이 정책을 준수해야 합니다.

검토 중인 코드를 업데이트하거나 위에서 설명한 대로 CI 재실행을 강제하기 위해 PR을 푸시할 수 있습니다.

베이비시팅을 요청한 인간 또는 Codex 리뷰 봇의 리뷰 코멘트 스레드를 해결할 수 있습니다. 해결할 때 [from Codex]: 접두사가 있는 코멘트를 남기고 어떤 변경을 했으며 어떤 커밋에 포함되는지 설명하십시오. 베이비시팅을 요청한 사용자 외에 다른 인간이 참여한 리뷰 스레드는 건드리지 마십시오.

변경을 하기 전에 PR 감시자 스크립트의 출력에 의존하지 말고 직접 PR 상태를 가져오십시오.

명시적으로 요청하지 않는 한 다음을 수행하지 마십시오:

• 다른 인간의 리뷰 스레드에 코멘트하고, 대신 채팅에서 사용자와 소통합니다.
• 사용자 외의 다른 인간의 리뷰 스레드를 해결합니다.
• 사용자 외의 다른 인간과 상호 작용합니다.
• PR을 초안 또는 검토 준비 상태로 표시합니다.
• PR을 닫거나 다시 엽니다.

일반적으로, 다른 인간이 볼 수 있는 작업을 당신이 했는지 사용자가 했는지 구분하기 어렵게 만드는 방식으로 GitHub에서 행동하지 마십시오. 의심스러운 경우 채팅에서 사용자에게 명확히 요청하십시오.

Git 안전 규칙

• PR 헤드 브랜치에서만 작업하십시오.
• 파괴적인 git 명령을 피하십시오.
• 컨텍스트를 복구해야 하는 경우가 아니면 브랜치를 전환하지 마십시오.
• 편집하기 전에 관련 없는 커밋되지 않은 변경 사항이 있는지 확인하십시오. 있는 경우 중단하고 사용자에게 물어보십시오.
• 각 성공적인 수정 후 커밋하고 git push한 다음 감시자를 다시 실행하십시오.
• 수정을 위해 라이브 --watch 세션을 중단한 경우, 같은 턴에서 푸시 직후 --watch를 다시 시작하십시오.
• 동일한 PR/상태 파일에 대해 여러 개의 동시 --watch 프로세스를 실행하지 마십시오. 하나의 감시자 세션을 활성 상태로 유지하고 중단되거나 의도적으로 다시 시작할 때까지 재사용하십시오.
• 푸시는 최종 결과가 아닙니다. 엄격한 중지 조건이 충족되지 않는 한 모니터링 루프를 계속하십시오.

커밋 메시지 기본값:

• codex: fix CI failure on PR #<n>
• codex: address PR review feedback (#<n>)

모니터링 루프 패턴

라이브 Codex 세션에서 이 루프를 사용하십시오:

1. --once 실행.
2. actions 읽기.
3. 먼저 PR이 병합되었거나 닫혔는지 확인하고, 그렇다면 해당 최종 상태를 보고하고 즉시 폴링을 중단합니다.
4. CI 요약, 새 리뷰 항목, 병합 가능성/충돌 상태를 확인합니다.
5. CI 실패를 진단하고 브랜치 관련 vs 변덕스럽거나 관련 없음으로 분류합니다. 전체 실행이 아직 진행 중이지만 failed_jobs에 이미 실패한 작업이 포함된 경우, 전체 워크플로 실행이 완료될 때까지 기다리지 않고 해당 작업의 로그를 가져와 즉시 진단합니다. 실패가 브랜치 관련인 경우에만 패치합니다.
6. 다른 작성자의 표시된 각 리뷰 항목에 대해, 실행 가능하면 패치/커밋/푸시한 다음, 위의 GitHub 상태 변경 정책에서 허용하는 경우에만 해결합니다. 실행 불가능하거나, 이미 처리되었거나, 서면 답변이 필요한 경우, 자동 게시 대신 제안된 응답과 함께 사용자에게 표시합니다. 이후 스냅샷이 승인된 답글을 표시하는 경우, 정보 제공용으로 간주하고 다시 응답하지 않고 계속 진행합니다.
7. 실행 가능한 리뷰 코멘트가 있는 경우, 변덕스러운 재실행보다 먼저 처리합니다. 리뷰 수정에 커밋이 필요한 경우 푸시하고 이전 SHA에서 실패한 검사를 다시 실행하지 않습니다.
8. retry_failed_checks가 있고 현재 SHA를 리뷰/CI 수정 커밋으로 대체하려는 경우가 아닌 경우에만 실패한 검사를 다시 실행합니다. CI를 녹색으로 만들기 위해 관련 없는 변덕 또는 인프라 실패에 대한 코드 변경을 하지 마십시오.
9. 커밋을 푸시하거나, 적격 리뷰 스레드를 해결하거나, 재실행을 트리거한 경우, 작업을 간략히 보고하고 계속 폴링합니다(중단하지 않음). 인간 리뷰 코멘트에 GitHub에서 서면 답변이 필요한 경우, 중단하고 게시 전에 확인을 요청합니다.
10. 리뷰 수정 푸시 후, 엄격한 중지 조건이 이미 충족되지 않은 경우 같은 턴에서 자동으로 연속 모니터링(--watch)을 다시 시작합니다.
11. 모든 것이 통과 중이고, 병합 가능하며, 필수 리뷰 승인에 차단되지 않고, 해결되지 않은 리뷰 항목이 없는 경우 PR이 현재 병합 준비가 되었다고 보고하지만, PR이 열려 있는 동안 새 리뷰 코멘트가 빠르게 표시되도록 감시자는 계속 실행합니다.
12. 사용자 도움이 필요한 문제(인프라 중단, 변덕 재시도 소진, 불명확한 리뷰어 요청, 권한)에 차단된 경우 차단기를 보고하고 중단합니다.
13. 그렇지 않으면 아래 폴링 주기에 따라 대기하고 반복합니다.

사용자가 명시적으로 PR을 모니터링/감시/베이비시팅하도록 요청할 때는 --watch를 선호하여 하나의 명령으로 자율적으로 폴링을 계속합니다. 반복적인 --once 스냅샷은 디버깅, 로컬 테스트 또는 사용자가 명시적으로 일회성 확인을 요청하는 경우에만 사용하십시오. 폴링을 계속할지 사용자에게 묻기 위해 중단하지 마십시오. 엄격한 중지 조건이 충족되거나 사용자가 명시적으로 중단할 때까지 자율적으로 계속하십시오. 리뷰 수정 푸시 후 새 SHA가 생성되었다고 해서 사용자에게 제어권을 넘기지 마십시오. 감시자를 다시 시작하고 폴링 루프에 재진입하는 것은 동일한 베이비시팅 작업의 일부입니다. --watch 프로세스가 여전히 실행 중이고 엄격한 중지 조건이 충족되지 않은 경우, 베이비시팅 작업은 여전히 진행 중입니다. 턴을 종료하는 대신 감시자 출력을 계속 스트리밍/소비하십시오.

폴링 주기

리뷰 폴링을 적극적으로 유지하고 CI가 녹색이 된 후에도 모니터링을 계속하십시오:

• CI가 녹색이 아닌 경우(진행 중/실행 중/대기 중 또는 실패): 1분마다 폴링.
• CI가 녹색이 된 후: PR이 열려 있는 동안 기본 주기로 계속 폴링하여 새로 게시된 리뷰 코멘트가 긴 녹색 상태 백오프를 기다리지 않고 신속하게 표시되도록 합니다.
• 변경 사항이 있을 때마다(새 커밋/SHA, 검사 상태 변경, 새 리뷰 코멘트, 병합 가능성 변경, 리뷰 결정 변경) 즉시 주기를 재설정합니다.
• CI가 다시 녹색이 아닌 경우(새 커밋, 재실행 또는 회귀): 기본 폴링 주기를 유지합니다.
• 폴링에서 PR이 병합되었거나 닫힌 것으로 표시되면 즉시 폴링을 중단하고 최종 상태를 보고합니다.

중지 조건 (엄격)

… (번역을 위해 잘림)