06 Issue PR and Label Policy

Issue·PR·Label 운영 규칙

Label 구성

열린 Issue는 원칙적으로 다음 조합을 사용합니다.

type:* 1개
area:* 1개 이상
priority:* 0~1개
status:* 1개
security:privacy 필요 시 추가

Type

• type:bug: 재현 가능한 결함·계약 위반
• type:feature: 사용자 또는 Agent 기능
• type:integration: 외부 저장소·Provider 연동 자체가 주 작업
• type:test: 테스트 추가·수정 자체가 주 작업
• type:tooling: CI·검증·개발 도구
• type:refactor: 외부 동작을 바꾸지 않는 구조 개선
• type:experiment: 모델·검색·생성 실험
• type:docs: 문서
• type:chore: 설정·의존성·유지보수

한 Issue에 여러 Type을 붙이지 않습니다. 테스트나 연동이 일부 포함되어도 주 결과를 기준으로 하나만 선택합니다.

Area

• area:agent
• area:intent
• area:workflow
• area:language
• area:ocr
• area:documents
• area:data
• area:knowledge
• area:integration
• area:platform

Priority

• priority:P0: MVP·시연·운영 핵심 흐름 차단
• priority:P1: 다음 핵심 릴리스 전에 필요한 작업
• priority:P2: 일정에 따라 미룰 수 있는 보완

제목에 P0/P1이 있다면 라벨에도 반영합니다. 근거 없이 Priority를 추정하지 않습니다.

Status

status:backlog → status:ready → status:in-progress → status:in-review → close
                         ↘ status:blocked ↗

• status:blocked에는 선행 Issue·PR·외부 조건을 본문에 적습니다.
• PR이 Draft라는 사실과 Issue 상태는 별개로 관리합니다.
• 병합 후 남은 완료 조건이 있으면 Issue를 닫지 않습니다.

Issue 작성

권장 구조:

1. 배경과 재현 사실
2. 목표 계약
3. 작업 범위
4. 담당 저장소 경계
5. 범위 제외
6. 완료 조건
7. 관련 Issue·PR

계획이 아니라 현재 코드 사실을 먼저 적습니다.

PR 작성

PR 본문에는 다음을 포함합니다.

• 왜 필요한가요?
• 무엇이 바뀌나요?
• 요청·응답 또는 상태 흐름
• 영향 범위와 호환성
• 테스트·lint·build·smoke 결과
• 병합 전 확인할 항목

Branch 이름

이 저장소에서는 작업 성격에 맞는 prefix를 사용합니다.

• feat/<description>
• fix/<description>
• refactor/<description>
• docs/<description>
• chore/<description>
• test/<description>

자동화 도구 이름을 드러내는 agent/ prefix는 사용하지 않습니다.

완료와 종료

• PR이 병합되어도 Issue의 완료 조건이 모두 충족됐는지 확인합니다.
• develop 병합만으로 운영 배포 완료라고 보지 않습니다.
• Server·Client 계약 반영이 남아 있으면 관련 링크와 잔여 체크리스트를 유지합니다.
• 대체 PR을 만들면 기존 PR에 대체 링크를 남깁니다.