LC-2838 Sprint 17

.claude/behavioral.md

@@ -0,0 +1,70 @@
+# CLAUDE.md
+
+Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.
+
+**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
+
+## 1. Think Before Coding
+
+**Don't assume. Don't hide confusion. Surface tradeoffs.**
+
+Before implementing:
+
+- State your assumptions explicitly. If uncertain, ask.
+- If multiple interpretations exist, present them - don't pick silently.
+- If a simpler approach exists, say so. Push back when warranted.
+- If something is unclear, stop. Name what's confusing. Ask.
+
+## 2. Simplicity First
+
+**Minimum code that solves the problem. Nothing speculative.**
+
+- No features beyond what was asked.
+- No abstractions for single-use code.
+- No "flexibility" or "configurability" that wasn't requested.
+- No error handling for impossible scenarios.
+- If you write 200 lines and it could be 50, rewrite it.
+
+Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
+
+## 3. Surgical Changes
+
+**Touch only what you must. Clean up only your own mess.**
+
+When editing existing code:
+
+- Don't "improve" adjacent code, comments, or formatting.
+- Don't refactor things that aren't broken.
+- Match existing style, even if you'd do it differently.
+- If you notice unrelated dead code, mention it - don't delete it.
+
+When your changes create orphans:
+
+- Remove imports/variables/functions that YOUR changes made unused.
+- Don't remove pre-existing dead code unless asked.
+
+The test: Every changed line should trace directly to the user's request.
+
+## 4. Goal-Driven Execution
+
+**Define success criteria. Loop until verified.**
+
+Transform tasks into verifiable goals:
+
+- "Add validation" → "Write tests for invalid inputs, then make them pass"
+- "Fix the bug" → "Write a test that reproduces it, then make it pass"
+- "Refactor X" → "Ensure tests pass before and after"
+
+For multi-step tasks, state a brief plan:
+
+```
+1. [Step] → verify: [check]
+2. [Step] → verify: [check]
+3. [Step] → verify: [check]
+```
+
+Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
+
+---
+
+**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.

.claude/settings.json

@@ -38,6 +38,7 @@
   },
   "enabledPlugins": {
     "code-review@claude-plugins-official": true,
+    "andrej-karpathy-skills@karpathy-skills": true,
     "typescript-lsp@claude-plugins-official": true,
     "playwright@claude-plugins-official": true,
     "commit-commands@claude-plugins-official": true,

.cursor/rules/domain-folder-structure.mdc

@@ -0,0 +1,121 @@
+---
+description: Domain-based folder structure rules - MUST follow when creating or moving files
+globs:
+alwaysApply: true
+---
+
+# 도메인 기반 폴더 구조 규칙 (최우선 적용)
+
+> 이 규칙은 파일 생성, 이동, 리팩토링 시 반드시 따라야 하는 최우선 규칙이다.
+
+## 프로젝트 구조
+
+```
+src/
+├── app/                    # Next.js App Router — 라우팅만 담당
+├── domain/                 # 도메인 기반 기능 모듈 (핵심 코드가 여기에 위치)
+│   ├── about/
+│   ├── admin/
+│   ├── auth/
+│   ├── blog/
+│   ├── career-board/
+│   ├── challenge/
+│   ├── faq/
+│   ├── home/
+│   ├── mypage/
+│   ├── program/
+│   ├── program-recommend/
+│   ├── report/
+│   └── review/
+├── common/                 # 3개 이상 도메인에서 사용하는 범용 UI 컴포넌트
+├── api/                    # API 클라이언트 (도메인별 하위 폴더)
+├── hooks/                  # 3개 이상 도메인에서 사용하는 공유 훅
+├── store/                  # Zustand 전역 스토어
+├── types/                  # 공유 타입 정의
+├── utils/                  # 3개 이상 도메인에서 사용하는 공유 유틸리티
+├── lib/                    # 라이브러리 설정
+├── context/                # React Context 프로바이더
+└── schema.ts               # 중앙 Zod 스키마
+```
+
+## 파일 배치 결정 규칙 (이 순서대로 판단)
+
+### 1. 단일 도메인 전용 → `domain/{도메인}/` 안에 배치
+
+컴포넌트, 훅, 유틸 모두 해당 도메인 폴더 안에 둔다.
+
+```
+domain/challenge/
+├── MyChallengeCard.tsx          # 컴포넌트
+├── hooks/useMissionSubmit.ts    # 도메인 전용 훅
+├── utils/calcMissionScore.ts    # 도메인 전용 유틸
+├── section/DailyMissionSection.tsx
+└── ui/MissionBadge.tsx
+```
+
+### 2. 인접 2~3개 도메인 공유 → 상위/핵심 도메인 폴더에 배치
+
+- `program`과 `challenge` 공유 → `domain/program/` (상위 개념)
+- `mypage`와 `review` 공유 → `domain/mypage/` (호스트 역할)
+- `home`과 `blog` 공유 → 더 핵심인 도메인에 배치
+
+### 3. 3개 이상 도메인에서 광범위하게 사용 → `common/`, `hooks/`, `utils/`
+
+완전히 범용적이고 특정 도메인에 속하지 않는 것만.
+
+```
+common/button/BaseButton.tsx    # 범용 UI
+hooks/useDebounce.ts            # 범용 훅
+utils/formatDate.ts             # 범용 유틸
+```
+
+## 절대 금지
+
+1. **도메인 간 직접 import 금지**
+   ```typescript
+   // BAD: domain/challenge/에서 domain/program/ 직접 참조
+   import { ProgramCard } from '@/domain/program/ProgramCard';
+
+   // GOOD: 공유가 필요하면 common으로 올리거나 상위 도메인에 배치
+   ```
+
+2. **타입별 flat 구조 금지** — 모든 컴포넌트를 `src/components/`에 넣지 않음
+
+3. **순환 의존 금지** — 도메인 A → B → A 형태 금지
+
+4. **기존 파일 불필요한 이동 금지** — 새 파일에만 규칙 적용. 기존 구조를 함부로 바꾸지 않음
+
+## 도메인 폴더 내부 패턴
+
+```
+domain/{기능}/
+├── {ComponentName}.tsx         # 루트 컴포넌트
+├── section/                    # 페이지 섹션별 분리
+│   ├── {Feature}Section.tsx
+│   └── {Feature}SkeletonSection.tsx
+├── ui/                         # 도메인 전용 UI (button, card, modal 등)
+├── hooks/                      # 도메인 전용 훅
+├── utils/                      # 도메인 전용 유틸리티
+├── modal/                      # 도메인 전용 모달
+└── {하위기능}/                  # 서브 기능별 폴더
+```
+
+## 삭제 용이성 원칙
+
+**도메인 폴더를 통째로 삭제해도 다른 도메인에 영향이 없어야 한다.**
+
+- 도메인 전용 코드는 반드시 해당 도메인 폴더에 위치
+- 공유 코드 생성 전 "정말 필요한가?" 확인
+- 성급한 추상화보다 적절한 중복이 낫다
+
+## 의존 방향
+
+```
+common / hooks / utils (공유 레이어)
+        ↑
+domain/{각 도메인} (비즈니스 로직)
+        ↑
+app/ (라우팅, 페이지 조립)
+```
+
+상위 레이어가 하위 레이어를 참조한다. 역방향 참조 금지.

.gemini/styleguide.md

@@ -1,14 +1,75 @@
 <!--
-  출처: 토스 프론트엔드 가이드라인 기반으로 만든 Cursor rule
-  https://gist.github.com/toy-crane/dde6258997519d954063a536fc72d055
+  출처: 토스 프론트엔드 가이드라인 + Vercel React Best Practices 기반
 -->
 
 # Frontend Design Guideline
 
-> **Gemini review language:** All code review feedback must be provided in korean.
+> **Gemini review language:** All code review feedback must be provided in Korean.
 
 This document summarizes key frontend design principles and rules, showcasing
-recommended patterns. Follow these guidelines when writing frontend code.
+recommended patterns. Follow these guidelines when writing and reviewing frontend code.
+
+---
+
+# 도메인 기반 폴더 구조 (최우선 리뷰 항목)
+
+> 파일이 올바른 위치에 있는지를 가장 먼저 확인한다.
+
+## 프로젝트 구조
+
+```
+src/
+├── app/                    # Next.js App Router — 라우팅만 담당
+├── domain/                 # 도메인 기반 기능 모듈 (핵심 코드)
+│   ├── about/     ├── admin/      ├── auth/
+│   ├── blog/      ├── career-board/ ├── challenge/
+│   ├── faq/       ├── home/       ├── mypage/
+│   ├── program/   ├── program-recommend/
+│   ├── report/    └── review/
+├── common/                 # 3개+ 도메인에서 사용하는 범용 UI
+├── api/                    # API 클라이언트 (도메인별 하위 폴더)
+├── hooks/                  # 3개+ 도메인에서 사용하는 공유 훅
+├── store/                  # Zustand 전역 스토어
+├── types/                  # 공유 타입
+├── utils/                  # 3개+ 도메인에서 사용하는 공유 유틸
+└── schema.ts               # 중앙 Zod 스키마
+```
+
+## 파일 배치 규칙 (리뷰 시 반드시 확인)
+
+### 1. 단일 도메인 전용 → `domain/{도메인}/` 안에 배치
+### 2. 인접 2~3개 도메인 공유 → 상위/핵심 도메인 폴더에 배치
+### 3. 3개+ 도메인에서 범용 사용 → `common/`, `hooks/`, `utils/`
+
+## 도메인 폴더 내부 구조
+
+```
+domain/{기능}/
+├── {ComponentName}.tsx         # 루트 컴포넌트
+├── section/                    # 페이지 섹션
+├── ui/                         # 도메인 전용 UI
+├── hooks/                      # 도메인 전용 훅
+├── utils/                      # 도메인 전용 유틸
+├── modal/                      # 도메인 전용 모달
+└── {하위기능}/                  # 서브 기능 폴더
+```
+
+## 리뷰 시 반드시 지적할 패턴
+
+1. **도메인 간 직접 import** — `domain/A/`에서 `domain/B/`를 import하는 코드
+2. **타입별 flat 구조** — 새 컴포넌트를 `src/components/`에 넣는 코드
+3. **순환 의존** — 도메인 A → B → A 형태
+4. **도메인 전용 코드가 common에 있는 경우** — 한 도메인에서만 쓰는데 common에 있으면 지적
+
+## 의존 방향
+
+```
+common / hooks / utils (공유)  ←  domain/{각 도메인} (비즈니스)  ←  app/ (라우팅)
+```
+
+역방향 참조 금지. 도메인 폴더를 통째로 삭제해도 다른 도메인에 영향이 없어야 한다.
+
+---
 
 # Readability
 
@@ -736,3 +797,13 @@ When reviewing React and Next.js code, also refer to the comprehensive performan
 - Minimize serialization at RSC boundaries
 
 Always consider both the design principles in this document AND the performance best practices from Vercel when providing code review feedback.
+
+## Other Detailed Rule References
+
+| File | Content |
+|---|---|
+| `.cursor/rules/full-stack-rule.mdc` | Full-stack development practices (RSC, error handling, optimization, testing) |
+| `.cursor/rules/domain-folder-structure.mdc` | Domain-based folder structure detailed rules |
+| `.cursor/rules/commit-convention.mdc` | Commit message convention (Korean, Conventional Commits) |
+
+**이 문서와 위 상세 파일이 충돌할 경우, 이 문서(styleguide.md)의 내용을 우선한다.**

.github/copilot-instructions.md

@@ -0,0 +1,101 @@
+# Copilot Instructions — Let's Intern Client
+
+> 이 프로젝트의 모든 AI 도구가 따라야 할 핵심 규칙입니다.
+
+## Tech Stack
+
+Next.js 15 (App Router), React 18, TypeScript, Tailwind CSS, Zustand, TanStack React Query, React Hook Form + Zod, Vitest.
+
+## 도메인 기반 폴더 구조 (최우선 규칙)
+
+### 구조 개요
+
+```
+src/
+├── app/          # Next.js App Router — 라우팅만 담당
+├── domain/       # 도메인 기반 기능 모듈 (핵심)
+├── common/       # 3개+ 도메인에서 사용하는 범용 UI
+├── api/          # API 클라이언트 (도메인별)
+├── hooks/        # 3개+ 도메인에서 사용하는 공유 훅
+├── store/        # Zustand 전역 스토어
+├── types/        # 공유 타입
+├── utils/        # 3개+ 도메인에서 사용하는 공유 유틸
+└── schema.ts     # 중앙 Zod 스키마
+```
+
+### 파일 배치 규칙
+
+1. **단일 도메인 전용** → `domain/{도메인}/` 안에 배치
+2. **인접 2~3개 도메인 공유** → 상위/핵심 도메인 폴더에 배치
+3. **3개+ 도메인에서 범용 사용** → `common/`, `hooks/`, `utils/`
+
+### 도메인 폴더 내부
+
+```
+domain/{기능}/
+├── {ComponentName}.tsx     # 루트 컴포넌트
+├── section/                # 페이지 섹션
+├── ui/                     # 도메인 전용 UI
+├── hooks/                  # 도메인 전용 훅
+├── utils/                  # 도메인 전용 유틸
+└── {하위기능}/              # 서브 기능 폴더
+```
+
+### 현재 도메인 목록
+
+about, admin, auth, blog, career-board, challenge, faq, home, mypage, program, program-recommend, report, review
+
+### 금지 패턴
+
+- 도메인 간 직접 import (`domain/A/` → `domain/B/`) 금지
+- 타입별 flat 구조 금지 (모든 컴포넌트를 `src/components/`에 넣지 않음)
+- 순환 의존 금지
+- 기존 파일 불필요한 이동 금지
+
+### 의존 방향
+
+`common/hooks/utils` ← `domain/` ← `app/` (역방향 금지)
+
+## 코딩 스타일
+
+- PascalCase: 컴포넌트 (`ProgramCard.tsx`)
+- camelCase: 함수/변수 (`useProgramStore`)
+- kebab-case: 라우트 폴더 (`program-detail/`)
+- UPPER_SNAKE_CASE: 상수 (`ANIMATION_DELAY_MS`)
+- 함수형/선언적 프로그래밍, class 금지
+- `'use client'`, `useEffect`, `setState` 최소화 — RSC 우선
+- Prettier: 2 spaces, semicolons, single quotes, width 80
+
+## 코드 품질 (Toss Frontend Fundamentals)
+
+1. **가독성** — 매직넘버 네이밍, 위에서 아래로 읽히는 코드, 복잡한 조건에 이름 부여
+2. **예측 가능성** — 일관된 반환 타입, 숨겨진 부수 효과 없음
+3. **응집도** — 함께 수정되는 코드는 같은 위치에
+4. **결합도** — 성급한 추상화보다 적절한 중복. 영향 범위 최소화
+
+## 성능 (Vercel React Best Practices)
+
+- `Promise.all()` for independent async (워터폴 제거)
+- barrel file import 지양
+- 무거운 컴포넌트 dynamic import
+- 서드파티 지연 로딩
+
+## 커밋
+
+- **한국어**, Conventional Commits (`feat:`, `fix:`, `refactor:` 등), 72자 이내
+
+---
+
+## 상세 규칙 참조 (반드시 함께 읽을 것)
+
+코드 작성 및 리뷰 시, 아래 파일들의 상세 규칙도 함께 따른다:
+
+| 파일 | 내용 |
+|---|---|
+| `.cursor/rules/toss-frontend.mdc` | Toss Frontend Fundamentals 상세 코드 예시 (매직넘버, 가드패턴, 조건부렌더링, Form Cohesion, Props Drilling, 추상화 등) |
+| `.cursor/rules/full-stack-rule.mdc` | 풀스택 개발 프랙티스 (RSC, 에러 핸들링, 최적화, 테스트 등) |
+| `.cursor/rules/domain-folder-structure.mdc` | 도메인 기반 폴더 구조 상세 규칙 |
+| `.cursor/rules/commit-convention.mdc` | 커밋 메시지 컨벤션 상세 |
+| `.github/skills/vercel-react-best-practices/AGENTS.md` | Vercel React 성능 최적화 40+ 규칙 상세 |
+
+**이 문서의 요약과 위 상세 파일이 충돌할 경우, 상세 파일의 내용을 따른다.**