PR 리뷰 처리 룰

원칙: 무비판적 반영 금지

PR 리뷰 코멘트 (Codex 자동 리뷰 등) 받으면 무조건 반영하지 말고, 컨텍스트 적합성 평가 먼저.

평가 프로세스

1. 단계 / 사용자 수 / 비용 vs 가치 로 적합성 평가
2. 합당한 지적 → 즉시 반영 + 인라인 reply ("commit X 에 반영")
3. 부적절한 지적 → 반박 + 인라인 reply 로 의사결정 근거 명시:

   gh api -X POST repos/{owner}/{repo}/pulls/{n}/comments/{comment_id}/replies \
     -f body="반박 근거..."

   • 반박 근거를 번호 매겨 명시 (단계, 영향 범위, 대안 비용, dev DX)
   • "결론: 변경 의도대로 진행" 으로 마무리
4. 사용자 보고 — 어떤 지적을 반박했고 근거가 무엇인지 요약 표

반박 정당화 패턴 (재사용)

1. Pre-launch

• 외부 사용자 0명 → API 호환성 코스트 < 깔끔한 설계 가치
• 의도적 breaking change 합당

2. Monorepo + 단독 개발

• 여러 PR 동시 머지 가능
• 과도기 호환성 불필요 (FE / BE 동기 머지)

3. Dual-path 부담

• flag / version 분기는 머지 후 cleanup PR 빚
• 가치 < 비용 일 때 거부

4. 본질 훼손

• 호환성 위해 잘못된 로직 잔존 같은 모순 발생 시 반박 정당
• 예: lazy reveal 도입했는데 "기존 자동 차감 dual path 유지" 제안 → 본질 훼손

사례

PR #30 (lazy reveal)

• Codex 가 "API 계약 깨짐" P1 두 번 제기
• 평가: pre-launch + monorepo + 단독 개발 = 의도적 breaking change 합당
• 반박 근거: dual-path 도입 시 본질 훼손 + cleanup PR 부담
• 결론: 변경 의도대로 진행
• 인라인 reply 예시: https://github.com/junhyeon47/dartbrief/pull/30#discussion_r3165194590

자동 흐름 (/review-pr)

/review-pr workflow 안에서는 review → fix → push → reply 자동 사이클. 각 코멘트마다:

1. Fetch top-level 인라인 코멘트
2. 정당성 평가
3. 정당 → 코드 수정 + 커밋 + push + reply
4. 부적절 → 반박 reply
5. 사용자에게 요약 보고