# 릴리즈 노트 관리 정책

## 원칙

- MR은 반드시 `/mr` 또는 `/release` 스킬을 통해 생성한다
- 웹에서 직접 생성한 MR은 릴리즈 노트 누락으로 리뷰에서 반려한다
- 코드 리뷰 시 `docs/RELEASE-NOTES.md` 변경 여부를 확인한다

## 2계층 구조

### Tier 1: 내부 릴리즈 노트 — `docs/RELEASE-NOTES.md`
- 대상: 내부 개발자
- 형식: [Keep a Changelog](https://keepachangelog.com/ko/1.0.0/) 기반
- 관리: `/mr` → [Unreleased] 항목 추가, `/release` → 날짜 버전 전환 + 압축
- 모든 커밋 타입 기록

### Tier 2: 버저닝 릴리즈 노트 — `docs/VERSION-HISTORY.md`
- 대상: 개발자 + 비개발자 + 외부 공유
- 형식: Semantic Versioning, 사용자 관점의 변화 중심
- 관리: `/version` 스킬로 RELEASE-NOTES.md 기반 생성

## 변경 타입 매핑 (RELEASE-NOTES.md)

| Conventional Commits | 릴리즈 노트 섹션 |
|---------------------|-----------------|
| feat | **추가** |
| fix | **수정** |
| refactor, perf | **변경** |
| docs | **문서** |
| test | **테스트** |
| style, chore, ci | **기타** |

## 권한 기반 스킬 접근

- `/push`, `/mr`: `permissions.push` (write 이상)
- `/release`, `/version`: `permissions.admin` (프로젝트 관리자)
- 권한은 Gitea API `repos/{owner}/{repo}` → `permissions` 필드로 확인
- Gitea site admin이 아닌 **리포 단위 팀 권한** 기준