develop 병합 PR의 연결 Issue 자동 종료

[exijn]

작업 배경

• MUDDA는 main을 운영·배포 안정 브랜치이자 GitHub 기본 브랜치로 유지하고, 기능 PR 대부분을 develop에 병합하는 Git Flow를 사용합니다.
• GitHub 기본 closing keyword는 기본 브랜치 대상 PR에서만 자동으로 동작하므로, develop 대상 PR의 Closes #N, Fixes #N, Resolves #N이 병합 후에도 Issue를 종료하지 않는 문제가 있습니다.

목표

• develop을 base로 하는 PR이 실제로 병합된 pull_request.closed 이벤트에서만 동작합니다.
• PR 본문의 공식 closing keyword(close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved)를 대소문자와 콜론 표기 변형까지 인식합니다.
• 명시적으로 연결된 같은 저장소의 열린 Issue만 검증 후 completed 사유로 종료합니다.
• PR 본문에 없는 Issue 번호를 추측하지 않으며, PR 제목·브랜치·커밋 메시지의 번호는 사용하지 않습니다.

안전성 및 멱등성

• contents: read, pull-requests: read, issues: write만 사용합니다.
• GITHUB_TOKEN만 사용하고 PAT·추가 Secret을 사용하지 않습니다.
• pull_request_target을 사용하지 않고, PR Head 코드를 Checkout하거나 실행하지 않습니다.
• 코드 블록·인라인 코드·HTML 주석·URL·다른 저장소 참조와 비공식 축약형은 종료 대상으로 처리하지 않습니다.
• 닫힌 PR, develop 이외의 base, 미병합 PR, 이미 닫힌 Issue, Pull Request 번호는 건너뜁니다.
• 자동화 Comment marker로 동일 PR의 중복 Comment를 방지하고, 여러 keyword의 중복 Issue 참조도 한 번만 처리합니다.
• 처리 실패 Issue는 Job Summary와 로그에 남기고 Workflow를 실패 상태로 종료합니다.

구현 범위

• develop 병합 PR의 Issue 자동 종료 Workflow
• closing keyword 파싱·저장소/Issue/상태 검증 및 감사 Comment
• 파싱·조건·멱등성 테스트
• PR 템플릿의 Closes #이슈번호 사용 예시 보완
• Git Flow와 자동화 활성화 조건·운영 절차 문서화
• PR 잠금 캡슐 종단간 암호화와 Shamir 키 분산 구현 #33 ↔ Issue 결정 필요: 캡슐 암호화 모델 — 설계 문서(E2E)와 현재 구현(서버 봉투 암호화) 불일치 #32, PR Docker 기반 GSMSV 운영 배포 환경 구성 #35 ↔ Issue #34의 소급 정리

부트스트랩 제약

• Workflow가 기본 브랜치에 존재해야 안정적으로 활성화되므로 작업 브랜치와 PR base는 최신 main으로 합니다.
• develop의 미출시 기능을 main에 병합하지 않습니다.
• 자동화 PR이 main에 병합된 이후부터 Workflow가 활성화됩니다.
• 자동화 PR 병합 후 main → develop 동기화가 필요합니다.

검증 및 완료 조건

• Workflow YAML 문법과 권한을 검증합니다.
• 정상 종료·비정상 참조 Skip·보안·멱등성 시나리오를 테스트합니다.
• 기존 CI와 Git Flow에 영향을 주지 않는지 확인합니다.
• 실제 Secret·PAT·외부 테스트 Issue를 사용하지 않습니다.
• main 대상 Draft PR을 생성하고 병합하지 않습니다.

제외 범위

• 기본 브랜치 변경, develop 전체의 main 릴리스, Branch Protection 우회
• 기존 기능 코드·배포 파일·Docker 설정 변경
• GitHub Actions CD·Discord Webhook 변경
• PR 자동 병합, main·develop 직접 Push
• PR 제목·브랜치·커밋 기반 또는 비공식 Issue 참조 자동 종료

대상 브랜치: main