.coderabbit.yaml

# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
language: "ko-KR"
tone_instructions: "프래그먼트 MVP의 PRD/SPEC/stack 문서를 기준으로 구체적이고 실행 가능한 피드백을 제공하세요. 제품 범위 밖 확장 요구는 지양하고, 단일 조직 근무 스케줄 관리 흐름과 프로젝트 컨벤션 위반을 명확하게 지적하세요."
early_access: false

reviews:
  profile: "assertive"
  request_changes_workflow: false
  high_level_summary: true
  high_level_summary_in_walkthrough: false
  poem: false
  review_status: true
  collapse_walkthrough: false
  sequence_diagrams: false
  estimate_code_review_effort: true
  assess_linked_issues: false
  related_issues: false
  related_prs: false
  suggested_labels: false
  auto_apply_labels: false
  suggested_reviewers: false

  auto_review:
    enabled: true
    auto_incremental_review: true
    drafts: false
    base_branches:
      - "develop"
      - "main"
    ignore_title_keywords:
      - "WIP"
      - "[WIP]"
      - "DO NOT MERGE"

  labeling_instructions:
    - label: "feat"
      instructions: "새로운 기능이 추가된 PR"
    - label: "fix"
      instructions: "버그를 수정하는 PR"
    - label: "refactor"
      instructions: "기능 변경 없이 코드 구조를 개선하는 PR"
    - label: "chore"
      instructions: "빌드 설정, 패키지 관리, CI 수정 등 PR"
    - label: "docs"
      instructions: "문서를 추가하거나 수정하는 PR"
    - label: "test"
      instructions: "테스트 코드를 추가하거나 수정하는 PR"

  path_filters:
    - "!**/node_modules/**"
    - "!**/.next/**"
    - "!**/dist/**"
    - "!**/.expo/**"
    - "!**/build/**"
    - "!**/coverage/**"
    - "!**/*.lock"
    - "!**/.turbo/**"

  path_instructions:
    - path: "apps/api/src/**/*.ts"
      instructions: |
        Express 백엔드 코드 리뷰 기준:

        [제품 범위]
        - PRD/SPEC의 MVP 범위(회원가입/로그인, 단일 조직, 인력, 가능 시간, 최소 인원 조건, 스케줄 추천/조정/확정, 보관함/export)와 맞는지 확인
        - MVP는 계정 1개당 조직 1개만 허용하며, 조직이 없는 계정은 조직 생성 외 운영 API에 접근할 수 없어야 함
        - 운영 화면 API는 인증 및 조직 존재 여부를 확인해야 함

        [라우터 구조]
        - Express Router → Service → Prisma 계층을 기본으로 하는지 확인
        - Router는 요청/응답 처리와 미들웨어 연결만 담당하고, 도메인 로직은 service 함수에 위치해야 함
        - 별도 Repository 추상화는 중복 제거 필요성이 명확할 때만 허용
        - 공통 미들웨어는 middlewares/, 공통 에러 클래스는 errors/, 공통 상수는 common/ 아래에 모아 재사용

        [Prisma 사용]
        - apps/api 내부에 Prisma 관련 파일(schema, migration, seed) 직접 생성 금지
        - apps/api에서는 packages/database에서 export하는 `createPrismaClient()`만 사용
        - `prisma` singleton 직접 import/use 금지
        - 앱 시작점에서 `createPrismaClient()`로 client를 생성하고 app/router/service에 주입
        - Prisma 생성 타입을 그대로 사용; 별도 타입 재정의 금지
        - 스키마/마이그레이션 변경은 packages/database에서 관리

        [인증 및 인가]
        - JWT Access Token 유효기간 15분, Refresh Token 7일 HTTP-only 쿠키 방식 준수 확인
        - 브라우저 저장소(localStorage/sessionStorage)에 토큰 저장 금지
        - 단일 조직 범위를 벗어난 데이터 접근이 불가능한지 확인

        [유효성 검증]
        - 요청 body, params, query는 Zod schema로 검증
        - 공유 가능한 입력/응답 schema는 packages/shared에서 정의하고 웹/API가 함께 사용
        - 날짜, 시간, 인원 수, 이메일, 비밀번호 확인 등 SPEC의 필수 검증 누락 여부 확인

        [에러 응답]
        - 에러 응답 형식 준수 여부 확인: { statusCode, errorCode, message }
        - errorCode는 반드시 common/constants/error-codes.ts 상수 사용; 하드코딩 금지

        [스케줄 도메인]
        - 스케줄 상태는 DB에 `DRAFT`, `CONFIRMED`만 저장; `스케줄 없음`은 UI 표시값으로만 사용
        - 추천 생성 전 조직, 인력 1명 이상, 선택 기간의 가능 시간 1개 이상, 최소 인원 조건 1개 이상을 검증
        - 같은 입력 조건으로 이미 생성된 DRAFT가 있으면 중복 생성하지 않아야 함
        - 추천 생성은 미충족 조건(날짜/시간대)을 기록할 수 있어야 함
        - DRAFT는 추가/수정/삭제 가능, CONFIRMED는 대시보드/보관함 조회 및 CSV export 대상
        - 종료 시간이 시작 시간보다 빠르면 익일 종료로 처리하고, 같으면 저장 차단
        - 가능 시간은 조직 운영 시간 기준 30분 단위이며, 휴무일에는 입력/저장할 수 없어야 함

    - path: "apps/api/src/**/*.spec.ts"
      instructions: |
        Express/Jest 단위 테스트 리뷰 기준:
        - Service 단위 테스트는 Prisma 등 외부 의존성을 Jest mock으로 격리
        - describe/it 블록 명칭이 테스트 의도를 명확히 표현하는지 확인
        - 스케줄 추천 조건 검증, DRAFT/CONFIRMED 상태 전환, 가능 시간/최소 인원 조건 검증을 우선 커버
        - 날짜/시간 경계(익일 종료, 30분 단위, 휴무일)를 테스트하는지 확인

    - path: "apps/api/test/**/*.ts"
      instructions: |
        API 통합 테스트 리뷰 기준:
        - Supertest로 Express app의 HTTP 요청/응답을 검증
        - Prisma는 fake/mocked client를 주입해 프로덕션 DB 접근을 차단
        - 실제 DB를 사용하는 테스트를 추가하는 경우 DATABASE_URL_TEST 환경 변수와 테스트 전후 DB 초기화 로직 포함 여부 확인
        - 인증 후 조직 존재 여부에 따른 접근 제어와 리다이렉트/오류 흐름 확인

    - path: "apps/web/**/*.tsx"
      instructions: |
        Next.js 운영 웹 컴포넌트 리뷰 기준:

        [제품 범위]
        - PRD/SPEC의 화면 범위(`/signup`, `/login`, `/organization/new`, `/dashboard`, `/organization`, `/workers`, `/availability`, `/staffing-rules`, `/schedules`, `/schedule-history`)와 흐름을 준수하는지 확인
        - MVP에서는 웹이 전체 사용자 화면을 담당하므로 모바일/태블릿/데스크톱에서 핵심 기능이 가능해야 함
        - 데스크톱 전용 액션이나 모바일에서 가로로 깨지는 달력/타임테이블/테이블 UI를 지적

        [라우팅 및 렌더링]
        - pages/ 디렉터리 사용 금지; App Router(app/)만 허용
        - "use client" 선언은 필요한 최소 범위에만 적용
        - 초기 데이터 로드는 서버 컴포넌트(RSC)에서 처리; 이후 인터랙션은 TanStack Query

        [상태 관리]
        - 서버 데이터(조직, 인력, 가능 시간, 최소 인원 조건, 스케줄)는 TanStack Query 사용
        - UI 전역 상태(필터 조건, 선택된 조직 ID, 모달 상태 등)만 Zustand 사용
        - 서버 데이터를 Zustand에 저장하거나 폼 상태를 전역 store에 두는 패턴 지적

        [폼 및 유효성 검증]
        - 모든 폼은 React Hook Form + Zod 조합 사용
        - Zod 스키마는 packages/shared에서 import; 웹 내부 별도 정의 금지
        - SPEC의 입력 검증(필수값, 이메일 형식, 비밀번호 확인, 날짜 범위, 시작/종료 시간, 1명 이상/1 이상의 숫자)을 UI와 schema가 함께 처리하는지 확인

        [스타일링]
        - Tailwind CSS 유틸리티 클래스만 사용; 인라인 style 속성 금지
        - @moyeorak/design-system을 1순위로 사용하고, 없는 컴포넌트만 shadcn/ui/Radix로 보완
        - 반복되는 arbitrary pixel value는 globals.css token 승격을 권장
        - 같은 역할의 버튼/입력 컴포넌트를 한 화면에서 디자인 시스템과 shadcn으로 중복 혼용하지 않도록 확인

        [인증]
        - JWT는 HTTP-only 쿠키에 저장; localStorage 저장 절대 금지
        - 미인증 접근 처리는 Next.js middleware에서 처리
        - 조직이 없는 로그인 사용자는 `/organization/new` 흐름으로 보내야 함

        [UI 컴포넌트]
        - shadcn/ui는 components/ui/ 소스 복사 방식만 사용; npm 패키지 직접 import 금지
        - 도메인 특화 컴포넌트(스케줄 달력, 가능 시간 타임테이블, 최소 인원 조건 폼)는 features/ 아래 위치
        - 가능 시간 UI는 조직 운영 시간 기준 30분 단위와 휴무일 비활성화를 표현해야 함
        - 보관함과 대시보드의 확정 스케줄은 조회/export 중심이며 CONFIRMED 최종본임을 흐름에서 보장

        [에러 처리]
        - API 에러는 TanStack Query onError 또는 error boundary에서 처리
        - 사용자에게 보이는 검증/예외 메시지는 SPEC의 예외 처리 의미와 어긋나지 않아야 함

    - path: "apps/web/**/*.ts"
      instructions: |
        Next.js 웹 TypeScript 코드 리뷰 기준:
        - any 타입 사용 자제; 구체적인 타입 또는 packages/shared 타입 사용
        - API 요청/응답 타입은 packages/shared/src/types/api/에서 import
        - 날짜/시간 계산은 시작/종료 경계, 익일 종료, 30분 단위, 휴무일 처리를 명시적으로 다룰 것
        - 서버 데이터 캐시/Mutation 로직은 TanStack Query 패턴을 따를 것

    - path: "packages/database/prisma/schema.prisma"
      instructions: |
        Prisma 스키마 리뷰 기준:
        - 단일 조직 MVP에 필요한 계정, 조직, 운영 시간/휴무일, 인력, 가능 시간, 최소 인원 조건, 스케줄/DRAFT/CONFIRMED 모델 관계 확인
        - 스케줄 상태는 `DRAFT`, `CONFIRMED`만 저장하고 UI 표시값인 `스케줄 없음`을 enum/model에 추가하지 않도록 확인
        - 인력 사번은 시스템 자동 생성 기준으로 설계되어야 하며 사용자 직접 입력 의존 금지
        - 가능 시간/스케줄/최소 인원 조건은 시작 시간이 종료 시간과 같을 수 없고, 익일 종료 표현이 가능한 datetime 구조인지 확인
        - 마이그레이션 안전성: 기존 데이터 손실 위험이 없는지 확인
        - 인덱스: 자주 조회되는 필드(외래키, 복합 조건)에 @@index 적용 여부
        - 관계 정합성: 올바른 onDelete/onUpdate 정책 적용 여부
        - 모든 모델에 createdAt, updatedAt 필드 포함 여부 확인

    - path: "packages/database/prisma/migrations/**"
      instructions: |
        Prisma 마이그레이션 파일 리뷰 기준:
        - 파일명에 변경 목적이 명확히 기재되어 있는지 확인
        - DROP, ALTER COLUMN 등 데이터 손실 가능 작업 경고
        - NOT NULL 컬럼 추가 시 기존 데이터 처리 방식(DEFAULT 값 등) 확인
        - 롤백 시나리오 고려 여부

    - path: "packages/shared/src/**/*.ts"
      instructions: |
        공유 패키지 코드 리뷰 기준:
        - 새로운 타입/스키마/유틸은 반드시 packages/shared/src/index.ts에서 re-export
        - Zod 스키마에서 타입을 z.infer<>로 추출; 별도 interface/type 선언 금지
        - 순수 함수로만 구현 (사이드 이펙트 없음, 외부 의존성 없음)
        - 웹·API 모두에서 사용 가능한 범용적 구현인지 확인
        - PRD/SPEC의 공통 입력 검증(회원가입, 조직 운영 시간, 인력, 가능 시간, 최소 인원 조건, 스케줄 수정)을 schema로 재사용 가능하게 정의
        - 날짜/시간 유틸은 timezone/익일 종료/30분 단위 경계를 호출자가 오해하지 않도록 명확한 이름과 테스트를 둘 것

    - path: ".github/workflows/**/*.yml"
      instructions: |
        GitHub Actions 워크플로우 리뷰 기준:
        - 시크릿 하드코딩 금지; secrets.* 또는 vars.* 참조 사용
        - actions/* 버전 고정 (SHA 또는 semver 태그 명시)
        - pnpm 워크스페이스 명령어 형식 확인: pnpm --filter @fragment/<app> <command>
        - develop 브랜치와 main 브랜치 보호 규칙 일치 여부 확인

    - path: "packages/database/prisma/seed.ts"
      instructions: |
        시드 파일 리뷰 기준:
        - 개발/테스트 전용 데이터만 포함; 실제 사용자 데이터 포함 금지
        - 프래그먼트 MVP의 단일 조직/인력/가능 시간/최소 인원 조건/샘플 스케줄 도메인과 맞는 데이터만 포함
        - upsert 사용으로 멱등성 보장 여부 확인 (중복 실행 안전)

  tools:
    # TypeScript / JavaScript
    eslint:
      enabled: true
    oxc:
      enabled: true

    # 보안 스캐닝
    gitleaks:
      enabled: true
    trufflehog:
      enabled: true
    semgrep:
      enabled: true
    trivy:
      enabled: true

    # DB / Prisma
    prismaLint:
      enabled: true

    # 인프라 / DevOps
    actionlint:
      enabled: true
    hadolint:
      enabled: true
    shellcheck:
      enabled: true
    dotenvLint:
      enabled: true

    # 문서 / 마크업
    markdownlint:
      enabled: true
    yamllint:
      enabled: true

    # CI 연동
    github-checks:
      enabled: true
      timeout_ms: 300000

  finishing_touches:
    docstrings:
      enabled: false
    unit_tests:
      enabled: true

chat:
  auto_reply: true

knowledge_base:
  opt_out: false
  web_search:
    enabled: false
  code_guidelines:
    enabled: true
    filePatterns:
      - "CLAUDE.md"
      - "apps/api/CLAUDE.md"
      - "apps/web/CLAUDE.md"
      - "docs/stack.md"
      - "docs/PRD.md"
      - "docs/SPEC.md"
      - "docs/API.md"
      - "docs/ERD.md"
      - "docs/SWAGGER.md"
      - "docs/openapi.yaml"
  learnings:
    scope: local
  issues:
    scope: local
  pull_requests:
    scope: local

code_generation:
  docstrings:
    enabled: false
  unit_tests:
    path_instructions:
      - path: "apps/api/src/**/*.ts"
        instructions: "Jest와 Supertest 사용. Service 단위 테스트는 Prisma 등 외부 의존성을 Jest mock으로 격리하고, API 통합 테스트는 Express app의 요청/응답을 검증."
      - path: "apps/web/**/*.tsx"
        instructions: "Vitest와 React Testing Library 사용. 테스트 파일은 대상 파일 옆에 코로케이션하고, API mocking은 테스트 범위가 확정된 경우 MSW 도입 여부를 함께 판단."