changes.md 작성 가이드

changes.md는 현재 릴리즈 버전의 변경사항만 기록하는 파일입니다. suneditor-demo 데모 업데이트, 릴리즈 노트 작성 시 참고 자료로 활용됩니다. 릴리즈 완료 후 내용을 비우고 다음 버전을 위해 새로 작성합니다.

---

목적

---

기록 시점

• 새 기능 추가 (feat) — 데모에서 보여줄 수 있는 기능
• 버그 수정 (fix) — 사용자에게 영향이 있는 수정
• 동작 변경 (refactor, perf) — 외부 동작이 달라지는 리팩토링/최적화
• Breaking Change — API, 옵션, 플러그인 인터페이스 변경
• 기록하지 않는 것: 내부 코드 정리(style), 문서(docs), 테스트(test), CI/빌드 설정(ci, chore, build) 등 사용자에게 직접 영향이 없는 변경

---

작성 형식

### feat

- 기능 설명 (`관련 파일 또는 플러그인`)
- 기능 설명 (#이슈번호)

### fix

- 수정 내용 (`관련 파일 또는 플러그인`)

### change

- 동작 변경 설명

### breaking

- ⚠️ 변경 내용 — 마이그레이션 방법

규칙

1. 현재 버전의 변경사항만 기록 — 이전 버전 히스토리는 남기지 않음
2. 커밋 타입별 그룹: feat, fix, change, breaking
3. 한 줄 요약 — 짧고 명확하게 (커밋 메시지 스타일)
4. 관련 파일/플러그인명 또는 이슈 번호를 괄호로 표기
5. Breaking Change는 breaking 섹션에 별도 기재하고 마이그레이션 방법 포함
6. 영어 또는 한국어 — 릴리즈 노트 언어에 맞춰 작성

---

릴리즈 시 처리

1. changes.md 내용을 GitHub Release 본문 / npm 릴리즈 노트에 복사
2. suneditor-demo 업데이트 목록으로 활용
3. 릴리즈 완료 후 changes.md 내용을 모두 비움 (파일은 유지, 내용만 삭제)
4. 다음 버전 개발 시 새로 기록 시작

---

Agent 지침

Agent가 직접 코드를 수정한 경우

수정 완료 후 changes.md를 업데이트:

1. 현재 changes.md를 읽는다
2. 해당 커밋 타입 그룹(feat/fix/change/breaking)에 항목 추가
3. 그룹이 없으면 새로 생성
4. 중복 항목 확인 — 이미 기록된 내용은 추가하지 않음
5. style, docs, test, chore, ci, build 타입은 기록하지 않음

사용자가 직접 수정 후 changes.md 업데이트를 요청한 경우

1. git diff (staged + unstaged)를 실행하여 변경된 코드를 확인한다
2. 변경 없으면 git diff HEAD~1로 최근 커밋의 변경사항을 확인한다
3. diff 내용을 분석하여 사용자에게 영향이 있는 변경사항을 판별한다
   • 새 기능, 옵션 추가 → feat
   • 버그 수정 → fix
   • 기존 동작 변경, 스타일 변경 등 사용자 체감 변화 → change
   • API/옵션 호환성 깨짐 → breaking
   • 내부 리팩토링, 테스트, 문서, CI 등 → 기록하지 않음
4. 현재 changes.md를 읽고, 중복되지 않는 항목만 적절한 그룹에 추가한다
5. 판단이 애매한 변경은 사용자에게 확인 후 추가한다