Skip to content

Latest commit

 

History

History
35 lines (31 loc) · 2.46 KB

File metadata and controls

35 lines (31 loc) · 2.46 KB

AGENTS.md

기본 원칙

  • SOLID 원칙을 준수한다.
  • 패키지 매니저는 Bun으로 통일하고, bun.lock을 항상 커밋한다.
  • tsconfig는 strict 중심으로 유지하고, any/as 남용을 피한다.
  • React 컴포넌트는 props 타입을 명확히 하고, 상태는 최소화한다.
  • 비동기 상태 갱신은 낙관적 업데이트와 실패 롤백을 고려한다.
  • 스타일은 목적별 파일로 분리하고, 전역 스타일은 최소화한다.
  • UI의 색상 변경 시 모든 테마의 라이트/다크 모드를 모두 고려하여 변경한다.
  • 사용하는 텍스트는 한국어를 기본으로 사용하고, UTF-8 인코딩을 적용한다.
  • 다른 컨텐츠 위에 뜨는 메뉴나 팝오버, 팝업들은 자신 이외의 영역을 클릭했을 때 닫혀야 하며 배경색도 틴트 처리가 되어야 한다.
  • 접근성: 버튼/아이콘에 aria-label, 텍스트 대체를 제공한다.
  • 배포 용어: Cloudflare Pages 배포는 production, GitHub Pages 배포는 beta로 칭한다.

인코딩/텍스트 품질

  • 모든 소스 파일은 UTF-8 (BOM 없음)으로 저장한다.
  • 커밋 전 텍스트 깨짐 검사: rg -n "�" src, rg -n "[\u00C0-\u00FF]" src
  • UI 문자열에 한글 외의 CJK 문자가 섞여 있으면 원인을 확인하고 교체한다.
  • 분석을 위하여 파일을 읽을 때는 CJK 문자가 깨지지 않도록 해야 한다.

작업 플로우

  • 작업 시작 전: develop 최신화 → 새 feature 브랜치 생성.
  • 새로운 작업은 항상 develop 최신화 후 feature/{기능-이름} 브랜치에서 시작한다.
  • 브랜치 이름은 작업 내용에 맞게 스스로 정한다.
  • 브랜치 변경 시 미커밋 변경사항은 스태시 후 새 브랜치에 다시 적용하는 흐름을 우선한다.
  • 작업 종료(릴리즈 준비 요청): 커밋 → 푸시 → PR 생성까지 진행한다.
  • 브랜치 전략: develop은 beta 배포 기준 브랜치, main은 production 배포 기준 브랜치로 사용한다.

PR 작성 규칙

  • PR 본문은 마크다운이 깨지지 않도록 멀티라인(heredoc) 방식으로 작성한다.
  • PR 제목/본문의 한글 인코딩이 깨지지 않도록 UTF-8로 작성·확인한다.
  • PR URL은 코드 블록 없이 클릭 가능한 일반 텍스트로 제공한다.
  • PR 생성 시 feature/* 브랜치는 반드시 develop 브랜치를 베이스로 삼는다.
  • PR 생성 시 release/* 브랜치는 반드시 main 브랜치를 베이스로 삼는다.