fix(ci): merge-order-guard 가 스택 PR 을 수명 내내 red 로 남긴다 — blocker 를 base 브랜치가 닫는 경우 #1059

📜 Overview (Required)

merge-order-guard 는 base 가 develop/main 이 아닌 스택 PR 에 대해 base 검사는 경고로만 남긴다. 워크플로 주석이 이유를 명시한다 — «실패로 올리면 스택 PR 이 수명 내내 X 로 남아 목록에서 진짜 CI 실패와 구분되지 않으므로».

그런데 뒤이은 blocked_by 검사는 base 와 무관하게 그대로 실패시킨다. blocker 이슈를 닫는 PR 이 바로 그 스택 PR 의 base 브랜치일 때 는 머지 순서 위반이 성립할 수 없는데도 red 가 되고, 경고로 낮췄던 바로 그 증상이 되돌아온다.

실례 — #863

• [ci] #849 release AAB·R8·크기 preflight 추가 #863 은 release(ci): main 병합 전 release AAB·R8·크기 preflight 추가 #849 를 닫는다. release(ci): main 병합 전 release AAB·R8·크기 preflight 추가 #849 는 열린 chore(release): Google Play 공식 배포에 앱 서명·자동 무결성 보호 적용 #735 에 blocked → 가드 실패.
• chore(release): Google Play 공식 배포에 앱 서명·자동 무결성 보호 적용 #735 를 닫는 PR 은 [chore] #735 Play 출시 런북과 AAB 검증 추가 #741, head 브랜치가 feat/735.
• [ci] #849 release AAB·R8·크기 preflight 추가 #863 의 base 가 바로 그 feat/735 다. 즉 [chore] #735 Play 출시 런북과 AAB 검증 추가 #741 이 먼저 머지되지 않으면 [ci] #849 release AAB·R8·크기 preflight 추가 #863 은 애초에 develop 로 들어갈 수 없다 — 순서는 스택 구조가 이미 보장한다.
• [chore] #735 Play 출시 런북과 AAB 검증 추가 #741 이 draft 라 [ci] #849 release AAB·R8·크기 preflight 추가 #863 은 그때까지 계속 red 로 남는다.

제안

BASE_REF 가 develop/main 이 아니면 blocked_by 위반도 error 대신 warning 으로 낮춘다. base 가 develop 로 이관되는 순간 가드가 다시 돌아 검사하므로 develop 진입 게이트는 그대로 유지된다.

더 좁게 가려면, blocker 이슈를 닫는 PR 의 head 가 이 PR 의 base 와 같을 때만 면제하는 방식도 가능하다.

📌 Child Issue(Optional)

No response

📍 Note (Optional)

• base 가 develop 인 PR 은 이 변경의 영향을 받지 않는다. 예: refactor(afternote): data/mapper 를 레포 표준 명명·평면 배치로 정리 (closes 932) [base: chore/676] #1050 은 base 가 develop 이고 선행 PR refactor(afternote): 상세 응답 DTO 를 BE 실코드에 동기화 (closes 676) [base: develop] #972 가 미머지라 red 인 것이 정상 동작이다.
• 원 설계 chore(ci): PR 머지 순서 가드 — blocked_by 미해소·비develop base 시 check 실패 #660 은 «비develop base 시 check 실패» 였으나 이후 경고로 완화됐다. 이 이슈는 그 완화가 blocked_by 경로에는 반영되지 않은 부분을 맞추자는 것.