변경요청 뒤 작성자 무조치 PR 에 라벨을 붙인다 #1552

작업 유형

maintenance — CI·빌드·의존성·저장소 운영 유지보수

주 담당 모듈

platform — Android 앱·CI·빌드·릴리스·저장소 운영

개요

변경요청을 받은 뒤 작성자가 아무 조치도 하지 않은 PR 은 현재 어디서도 신호가 나지 않는다.

review-debt-guard.yml 은 설계상 리뷰어의 빚만 잡는다. 워크플로 주석이 명시하듯 "재요청이 없거나 최신 변경요청 뒤 새 커밋이 없으면 빚이 아니다" — 공이 작성자에게 있는 PR 은 리뷰어를 벌하지 않는다. 설계로는 맞지만, 결과적으로 이 축은 아무도 알려 주지 않는다.

가드는 이미 이 상태를 식별하고 버리고 있다:

else
  echo "#$pn — 변경요청 미반영, 공은 작성자에게"
fi

없던 판정을 새로 만드는 게 아니라, 버려지는 판정을 라벨로 남기는 일이다.

실측(8/30) — 열린 non-draft PR 29건 중 최신 판정이 CHANGES_REQUESTED 인 것은 9건이고, 그중 6건이 작성자 무조치(판정 이후 작성자 실질 커밋 0 · 응답 0)다.

정정. 이 이슈를 열 때 적었던 «9건 전부 무조치» 는 틀렸다. 손으로 돌린 확인 스크립트가 gh api --jq --arg ... 를 썼는데 gh 는 --jq 에 --arg 를 받지 않는다(accepts 1 arg(s), received 4). 그 오류를 2>/dev/null || true 가 삼켜 커밋·응답 집계가 전부 0으로 떨어졌다. #966·#1449·#1466 은 Sadturtleman 이 이미 반영한 상태였다. 위 6건은 이 이슈에서 만든 리컨사일러를 dry-run 으로 돌려 다시 뽑은 것이다.

이 축이 커버되고 있었다면 49일·22일짜리가 이렇게 남지 않는다. 오래 열려 있을수록 develop 이 전진해 충돌 비용이 커진다.

구현 방향

• conflict-label.yml(PR Label Reconcile)에 리컨사일러를 하나 더 얹는다. 새 워크플로를 세우지 않는다 — 트리거·concurrency·quota 처리가 이미 거기 있다.
• 리컨사일러 방식이라 붙이기와 떼기가 한 번의 차이 계산으로 처리된다. 붙이기만 하고 안 떼는 스테일 라벨이 구조적으로 생기지 않는다.
• 판정 조각(최신 판정 · 작성자 실질 커밋 · 빈 커밋 배제 · 응답 집계)은 review-debt-guard.yml 과 같은 기준이어야 한다. 두 판정이 갈리지 않도록 정책 테스트로 잠근다.

참고

review-debt-guard.yml 은 이 이슈에서 수정하지 않는다. 그 워크플로의 판정은 review-debt-policy.test.mjs 132줄이 YAML 텍스트 정규식으로 잠그고 있어, 인라인 bash 를 스크립트로 떼어내면 라벨 기능과 무관한 회귀 위험을 산다.

선행 맥락: #1136(가드 신설) · #1450(재요청 자동화) · #1459(리뷰어 빈 커밋 오탐) · #1532(이슈 쪽 pr-open 라벨, 같은 리컨사일러 패턴)