maintenance(platform): base 브랜치 삭제로 자동 폐쇄된 PR 을 되살린다 — 승인된 #1626 이 흔적 없이 사라졌다 #2076

작업 유형

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

주 담당 모듈

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

개요

작업 브랜치를 지우면 그 브랜치를 base 로 하던 열린 PR 이 깃허브 정책에 따라 즉시 자동으로 닫힌다. 지금 저장소에는 이 자동 폐쇄를 되돌리거나 알리는 경로가 없어서, 승인까지 받은 PR 이 아무 흔적 없이 사라질 수 있다.

실제로 한 번 일어났다. 2026-09-11 22:17:52Z 에 feat/1762-draft-resume 가 삭제되면서 1초 뒤 PR #1626 이 닫혔다. 닫는 코멘트도 리뷰도 없고 base_ref_deleted → closed 두 이벤트만 남는다. #1626 은 Sadturtleman 의 APPROVED 를 받은 상태였고, 그 위에 #1839 #1837 #1838 #1971 #1972 #2021 #1768 일곱 건이 스택으로 쌓여 있었다. 밑단이 사라지면서 이 사슬 전체가 develop 에 도달할 경로를 잃었는데, 그 사실이 2026-09-13 까지 드러나지 않았다.

브랜치를 지운 쪽의 의도는 삭제가 아니라 이름 확보였다. feat/808-draft-resume 를 이슈 번호에 맞춰 feat/1762-draft-resume 로 옮기는 중이었고, 그 이름이 이미 다른 PR 의 base 라는 것을 확인하지 않았다.

#2068 이 고치는 403 과는 다른 층이다. #2068 은 닫힌 뒤 상위 PR 에 안내를 남기는 경로를 살리고, 이 이슈는 닫힘 자체를 되돌린다. 두 가지가 다 있어야 같은 사고에서 피해가 0 이 된다.

제안

on: delete 워크플로를 추가한다. 브랜치 삭제 이벤트를 받아, 그 브랜치를 base 로 하던 PR 중 삭제 직전에 미병합 상태로 닫힌 것을 찾아 자동으로 다시 연다. 되살릴 때 무엇이 왜 닫혔는지 코멘트로 남긴다.

• 삭제 자체는 막지 않는다. 룰셋의 삭제 제한을 작업 브랜치까지 넓히면 일상적인 정리가 막혀 비용이 더 크다.
• 되살릴 수 없는 경우가 있다. 삭제된 브랜치가 같은 이름으로 다시 밀리지 않으면 base 가 없어 reopen 이 실패한다. 그때는 되살리는 대신 이슈를 열어 사슬 구조와 끊긴 지점을 기록한다.
• 판정과 문구는 .github/scripts 에 두고 .test.mjs 로 고정한다. 워크플로 YAML 에 로직을 넣지 않는다.

완료 조건

1. 작업 브랜치를 지웠을 때, 그 브랜치를 base 로 하던 미병합 PR 이 자동으로 다시 열리고 경위 코멘트가 남는다.
2. 되살릴 수 없는 경우(브랜치가 복원되지 않음)에 조용히 지나가지 않고 추적 가능한 기록이 남는다.
3. 정책 테스트가 위 두 분기를 모두 고정한다.
4. 이미 머지된 PR 의 base 브랜치 삭제처럼 정상적인 정리에는 반응하지 않는다.

참고

• 사고 PR: fix(afternote): 수정 PATCH 가 안 건드린 필드를 싣지 않게 한다 (#1617) #1626 (2026-09-13 에 수동으로 다시 열어 사슬을 복구했다. diff 19 files +1463 -101 이 원본과 일치하는 것을 확인했다.)
• 같은 사고의 다른 층: fix(platform): 스택 안내 코멘트가 pull-requests 쓰기 권한 부족으로 403 에 막힌다 #2068 — 안내 코멘트가 403 으로 죽어 상위 PR 네 건에 아무 알림도 가지 않았다.
• 관련 워크플로: .github/workflows/stack-integrity-notify.yml