ci(platform): PR 대표 Issue 는 Closes 로만 연결한다 — Refs 도피로를 닫아 Issue 분리를 강제 #1748

작업 유형

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

주 담당 모듈

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

개요

문제 — validate-pr-issue-link.mjs 는 PR 제목의 대표 Issue 를 본문에서 Closes 또는 Refs 로 연결하면 통과시킨다. 정책 테스트 pr-issue-link-policy.test.mjs 가 «한 Issue 에 PR 여러 개, 마지막만 Closes» 를 허용으로 잠가 두고 있고, PR 템플릿도 - Refs # 를 기본으로 준다. 그 결과 대표 Issue 를 Refs 로 내리는 PR 이 2026-09-02 실측 20건이었다(열린 PR 27건 중). 사유는 둘뿐이었다 — ① Issue 에 열린 blocked_by 가 있어 merge-order-guard 가 Closes 를 막으니 Refs 로 내려 머지하고 Issue 는 손으로 닫는다(가드 취지 우회), ② Issue 의 일부만 하고 남는 몫을 본문 산문에 적는다(아무도 추적 안 함). 같은 날 16건을 손으로 정리했다(#1725~#1745).

merge-order-guard 는 Closes 대상에 열린 blocked_by 가 있으면 막지만, Refs 는 그 관문 밖이다. 도피로가 이 조항 하나다.

변경

• validate-pr-issue-link.mjs — 대표 Issue 는 closing 키워드(close[sd]/fix(e[sd])/resolve[sd], GitHub auto-close 규격과 동일)로 연결돼야 통과. 다른 Issue 를 곁들이는 Refs 는 그대로 허용. 봇 PR(dependabot)은 대표 Issue 를 Refs 로 거는 현행을 유지한다 — 의존성 갱신 Issue 하나를 여러 봇 PR 이 공유하는 구조라 Closes 를 강제하면 첫 PR 이 Issue 를 닫는다.
• pr-issue-link-policy.test.mjs — «여러 PR 이 한 Issue 공유» 허용 단언을 «대표 Issue 를 Refs 로 걸면 거부» 로 뒤집고, 나머지 시나리오의 본문을 Closes 로 맞춘다.
• .github/PULL_REQUEST_TEMPLATE.md — 기본 줄을 - Closes # 로, 안내를 «일부만 하면 Issue 를 분리해 그것을 대표 Issue 로» 로 바꾼다.

효과 — 블로커가 열린 Issue 에 PR 을 열면 merge-order-guard 가 빨개지고, 풀 방법은 블로커 대기·선행 PR 위 스택·관계 해제·Issue 분리 넷뿐이 된다. 일부 착수의 유일한 통로가 «착수 가능한 몫을 새 Issue 로 뗀다» 가 된다.

완료 조건

• 대표 Issue 를 Refs 로만 건 사람 PR 은 Repository Quality 가 실패하고, 오류 문구가 «Issue 를 분리해 대표 Issue 로 삼으라» 고 안내한다
• 대표 Issue 를 Closes/Fixes/Resolves 로 건 PR 과, 곁들인 Refs #M 이 있는 PR 은 통과한다
• 봇 PR 은 종전대로 Refs 로 통과한다
• 정책 테스트가 위 셋을 잠그고 node --test .github/scripts/*.test.mjs 통과
• PR 템플릿이 새 규칙을 안내한다

참고

• 배경: 2026-09-02 Refs-only PR 정리(test(receiver): 재진입 갱신 결선 소실을 konsist 가드로 막고 이동 잔재 import 를 지운다 (#701 분리) #1725~fix(afternote): 곡 없는 임시저장을 발행 상세와 분리해 조회한다 #1745). 대표 Issue 를 Refs 로 내리지 않는다는 규칙은 같은 날 확정.
• 머지 시점에 대표 Issue 를 Refs 로 건 열린 PR 5건이 빨개진다 — fix(core-ui,app): 다크 팔레트 확정까지 팔레트·시스템바를 라이트로 잠근다 (#1873) #1723·refactor(mindrecord): 읽기 실패 계측을 선별해 승격한다 (#1874) #1714·refactor(mindrecord): 임시저장·주간 리포트의 다중 Repository 정책을 UseCase 경계로 (#1875) #1711(Sadturtleman), fix(timeletter): 서버 실패 상태와 재시도 처리 (#714) #1365·feat(setting): 고객센터 화면 구현 (#783) #882(koongmai). 본문 수정만으로 재검증이 돈다.
• 관련: PR 작성자와 대표 Issue 담당자 대조 게이트 도입 #1366(작성자↔담당자 대조 게이트), merge-order-guard(chore(ci): PR 머지 순서 가드 — blocked_by 미해소·비develop base 시 check 실패 #660).