# 프로젝트: [프로젝트명]

## 기술 스택
- Backend: Spring Boot 3.2, Java 21
- Frontend: React 18, TypeScript
- Database: PostgreSQL 15
- Infra: Docker, AWS

## Git 워크플로우

### 브랜치 전략
- main: 프로덕션
- develop: 개발 통합
- feature/*: 기능 개발
- hotfix/*: 긴급 수정

### 커밋 컨벤션 (Conventional Commits)
- feat: 새 기능
- fix: 버그 수정
- refactor: 리팩토링
- docs: 문서
- test: 테스트
- chore: 기타

예시: `feat(auth): add JWT token refresh`

### PR 규칙
- 제목: 커밋 컨벤션 따름
- 본문: 변경사항, 테스트 방법, 스크린샷 포함
- 리뷰어: 최소 1명 승인 필요

## 코딩 규칙

### CRITICAL (절대 지켜야 함)
- NEVER: SQL 문자열 직접 조합
- ALWAYS: PreparedStatement 또는 JPA
- NEVER: 민감정보 로그 출력
- ALWAYS: 예외는 CustomException으로

### IMPORTANT (매우 중요)
- 모든 API는 @Valid로 입력 검증
- Service 메서드는 @Transactional
- 200줄 넘는 메서드는 분리
- 테스트 커버리지 80% 유지

### RECOMMENDED (권장)
- JavaDoc 주석 작성
- TODO는 Jira 티켓 번호 포함
- Magic Number는 상수로

## AI 도구 사용 가이드

### Claude Code
- 복잡한 기능: Plan Mode 사용
- 커밋 전: /commit 실행
- 하루 마무리: /devlog 실행

### Codex
- PR 생성 전: --effort high
- 배포 전: --effort xhigh
- 개발 중: --effort medium

### Antigravity
- 다중 페이지 개발: Manager View
- UI 검증: Browser Subagent

---
description: "현재까지의 작업을 논리적 단위별로 나눠서 커밋"
---

현재까지 작업한 내용을 작업 단위별로 나눠서 커밋해주세요.

## 수행 단계

### 1. 현재 변경사항 분석
```bash
git status
git diff
git diff --staged
```

다음 정보를 파악:
- 수정된 파일 목록
- 각 파일의 변경 내용
- 변경사항 간의 관계

### 2. 변경사항을 논리적 단위로 그룹화

**좋은 예**:
```
그룹 1 (기능): UserService.java, UserRepository.java
그룹 2 (테스트): UserServiceTest.java
그룹 3 (문서): README.md, API.md
```

**나쁜 예**:
```
그룹 1: UserService.java, README.md, docker-compose.yml
(관련 없는 파일들이 섞임)
```

**그룹화 원칙**:
- 하나의 커밋 = 하나의 완성된 의미
- 관련 있는 파일끼리 묶기
- 다른 타입(기능/테스트/문서)은 분리

### 3. 각 그룹별로 순차 커밋

우선순위:
1. 핵심 기능 (feat)
2. 버그 수정 (fix)
3. 리팩토링 (refactor)
4. 테스트 (test)
5. 문서 (docs)
6. 기타 (chore)

각 커밋마다:
```bash
git add [관련 파일들]
git commit -m "type(scope): 간결한 설명

상세 설명 (선택):
- 변경 이유
- 영향 범위
- 관련 이슈 번호
"
```

**커밋 메시지 템플릿**:
```
feat(auth): JWT 토큰 갱신 기능 추가

- 만료된 토큰 자동 갱신
- Refresh Token 저장 (Redis)
- 보안: HttpOnly 쿠키 사용

Resolves: #123
```

### 4. 커밋 검증

```bash
# 커밋 이력 확인
git log --oneline -10

# 각 커밋이 의미있는지 확인:
# ✓ feat(auth): add JWT refresh
# ✓ test(auth): add JWT refresh tests
# ✓ docs(api): update authentication API docs
# ✗ update files (❌ 불명확)
```

### 5. 최종 상태 확인

```bash
git status
# 출력이 "nothing to commit, working tree clean"이어야 함

# 만약 남은 파일이 있다면:
# 1. 의도적으로 남긴 것인지 확인
# 2. 필요하면 추가 커밋
# 3. 또는 .gitignore 추가
```

## 특수 케이스

### 케이스 1: 파일이 너무 많을 때 (50개 이상)

```bash
# 파일 타입별로 그룹화
git add src/**/*.java  # Java 파일만
git commit -m "refactor: update service layer"

git add src/**/*Test.java  # 테스트만
git commit -m "test: update service tests"

git add *.md  # 문서만
git commit -m "docs: update documentation"
```

### 케이스 2: 실험적 변경사항이 섞여있을 때

```bash
# 안정적인 변경사항만 먼저 커밋
git add -p  # 인터랙티브 모드

# 각 hunk마다 선택:
# y: 이 변경사항 추가
# n: 스킵
# s: 더 작게 나누기
```

### 케이스 3: 민감한 정보가 포함된 경우

```bash
# 체크: 민감 정보 검색
git diff | grep -i "password\|secret\|key"

# 발견 시:
# 1. 해당 파일 수정 (민감정보 제거)
# 2. .gitignore 추가
# 3. 환경 변수로 대체
```

## 주의사항

### 절대 하지 말 것
- ❌ `git add .` (무분별한 전체 추가)
- ❌ 관련 없는 파일 한 커밋에
- ❌ "WIP", "update", "fix" 같은 불명확한 메시지
- ❌ .env, credentials, node_modules 커밋

### 반드시 할 것
- ✅ CLAUDE.md의 커밋 컨벤션 따르기
- ✅ 각 커밋은 독립적으로 의미 있게
- ✅ 커밋 메시지에 이유(why) 포함
- ✅ 큰 변경은 작은 커밋으로 분할

## 출력 형식

커밋 완료 후 다음 정보 출력:
```
✅ 커밋 완료 (총 3개)

1. feat(user): add profile update API
   - 파일: UserController.java, UserService.java
   - 변경: +89 -12

2. test(user): add profile update tests
   - 파일: UserControllerTest.java
   - 변경: +156 -0

3. docs(api): update user API documentation
   - 파일: API.md
   - 변경: +23 -5

📊 전체 변경: +268 -17
🔗 최신 커밋: 7a3b9c2
```

---
description: "논리적 단위별 커밋 후 원격 저장소에 푸시"
---

현재까지 작업한 내용을 커밋하고, 원격 저장소에 푸시해주세요.

### 1. 현재 변경사항 분석
(파일 수정을 위한 `git status`, `git diff` 분석)

### 2. 논리적 단위 그룹화 및 순차 커밋
(작업 단위별로 `git add` 및 Conventional Commits 기반 `git commit` 수행)

### 3. 최종 상태 및 충돌 확인
(로컬 커밋 완료 상태 확인 및 원격 브랜치와 비교)

### 5. 원격 브랜치 상태 확인

```bash
# 원격 브랜치 최신 정보 가져오기
git fetch origin

# 현재 브랜치 확인
CURRENT_BRANCH=$(git branch --show-current)
echo "현재 브랜치: $CURRENT_BRANCH"

# 원격 브랜치 존재 여부
git ls-remote --heads origin $CURRENT_BRANCH
```

### 6. 로컬/원격 비교

```bash
# 로컬이 원격보다 앞서있는지 확인
git rev-list origin/$CURRENT_BRANCH..$CURRENT_BRANCH

# 출력 분석:
# - 결과 있음: 로컬에 새 커밋 존재 (푸시 필요)
# - 결과 없음: 이미 동기화됨 (푸시 불필요)

# 원격이 로컬보다 앞서있는지 확인
git rev-list $CURRENT_BRANCH..origin/$CURRENT_BRANCH

# 출력 분석:
# - 결과 있음: 원격에 새 커밋 존재 (pull 필요)
# - 결과 없음: 로컬이 최신
```

### 7. 충돌 사전 감지

원격이 로컬보다 앞선 경우:

```bash
# 1. 원격 변경사항 확인
git log $CURRENT_BRANCH..origin/$CURRENT_BRANCH --oneline

# 2. 사용자에게 알림
echo "⚠️  원격 브랜치에 새 커밋이 있습니다:"
echo "$(git log $CURRENT_BRANCH..origin/$CURRENT_BRANCH --oneline)"
echo ""
echo "옵션:"
echo "1. pull 후 push (권장)"
echo "2. force push (위험 - 팀 작업 시 절대 금지)"
echo ""
read -p "선택 (1/2): " choice

if [ "$choice" = "1" ]; then
    # Pull (rebase 권장)
    git pull --rebase origin $CURRENT_BRANCH
    
    # 충돌 발생 시
    if [ $? -ne 0 ]; then
        echo "❌ 충돌 발생. 수동 해결 필요."
        echo ""
        echo "충돌 파일:"
        git diff --name-only --diff-filter=U
        echo ""
        echo "해결 후 다음 명령 실행:"
        echo "  git add [해결된 파일]"
        echo "  git rebase --continue"
        exit 1
    fi
fi
```

### 8. 푸시 실행

```bash
# 새 브랜치인 경우
if ! git ls-remote --heads origin $CURRENT_BRANCH | grep -q $CURRENT_BRANCH; then
    echo "📝 새 브랜치 생성 및 푸시"
    git push -u origin $CURRENT_BRANCH
else
    echo "📤 기존 브랜치 푸시"
    git push origin $CURRENT_BRANCH
fi

# 푸시 성공 확인
if [ $? -eq 0 ]; then
    echo "✅ 푸시 성공!"
    echo ""
    echo "원격 URL: $(git remote get-url origin)"
    echo "브랜치: $CURRENT_BRANCH"
    echo "커밋: $(git log -1 --oneline)"
else
    echo "❌ 푸시 실패"
    echo ""
    echo "가능한 원인:"
    echo "1. 권한 없음 (SSH 키 확인)"
    echo "2. 브랜치 보호 규칙"
    echo "3. 네트워크 문제"
    exit 1
fi
```

### 9. CI/CD 트리거 확인 (선택)

푸시 후 CI/CD가 자동 실행되는 경우:

```bash
# GitHub Actions인 경우
echo "🔄 GitHub Actions 확인 중..."
gh run list --branch $CURRENT_BRANCH --limit 1

# 또는 웹 브라우저로 열기
gh run watch
```

## 특수 케이스

### 케이스 1: Protected Branch (main, develop)

```bash
# Protected 브랜치로 직접 푸시 불가
if [ "$CURRENT_BRANCH" = "main" ] || [ "$CURRENT_BRANCH" = "develop" ]; then
    echo "⚠️  Protected 브랜치에는 직접 푸시 불가"
    echo ""
    echo "올바른 절차:"
    echo "1. feature 브랜치 생성"
    echo "2. 해당 브랜치에서 작업"
    echo "3. PR 생성"
    echo ""
    echo "자동으로 feature 브랜치를 만들까요? (y/n)"
    read answer
    
    if [ "$answer" = "y" ]; then
        FEATURE_NAME="feature/$(date +%Y%m%d)-auto"
        git checkout -b $FEATURE_NAME
        git push -u origin $FEATURE_NAME
        echo "✅ $FEATURE_NAME 생성 및 푸시 완료"
    fi
    exit 0
fi
```

### 케이스 2: Large Files (100MB+)

```bash
# Git LFS 필요한지 체크
LARGE_FILES=$(git diff --cached --name-only | xargs ls -lh 2>/dev/null | awk '$5 ~ /M$/ && $5+0 > 50')

if [ ! -z "$LARGE_FILES" ]; then
    echo "⚠️  큰 파일 발견 (50MB+):"
    echo "$LARGE_FILES"
    echo ""
    echo "Git LFS 사용을 권장합니다."
    echo "계속하시겠습니까? (y/n)"
    read answer
    
    if [ "$answer" != "y" ]; then
        echo "푸시 취소됨"
        exit 1
    fi
fi
```

### 케이스 3: Pre-push Hook

```bash
# .git/hooks/pre-push가 있는 경우 실행
if [ -x .git/hooks/pre-push ]; then
    echo "🔍 Pre-push 훅 실행 중..."
    .git/hooks/pre-push
    
    if [ $? -ne 0 ]; then
        echo "❌ Pre-push 훅 실패"
        echo "훅을 무시하고 푸시? (y/n)"
        read answer
        
        if [ "$answer" != "y" ]; then
            exit 1
        fi
    fi
fi
```

## 주의사항

### 푸시 전 반드시 확인
- ✅ 모든 테스트 통과
- ✅ .env, credentials 제외됨
- ✅ CLAUDE.md 규칙 준수
- ✅ 팀원과 충돌 여부

### 절대 하지 말 것
- ❌ `git push -f` (force push)
  - 예외: 자신만 쓰는 feature 브랜치
- ❌ 민감 정보 포함된 커밋 푸시
- ❌ 테스트 실패 상태로 푸시
- ❌ 빌드 깨진 상태로 푸시

## 출력 예시

```text
📋 커밋 요약 (3개)
─────────────────────────────────────
1. feat(auth): add JWT refresh
2. test(auth): add JWT refresh tests  
3. docs(api): update auth endpoints
─────────────────────────────────────

🔍 원격 브랜치 확인...
✓ origin/feature/auth-refresh 존재
✓ 로컬이 3 commits ahead
✓ 충돌 없음

📤 푸시 중...
Enumerating objects: 15, done.
Counting objects: 100% (15/15), done.
Delta compression using up to 8 threads
Compressing objects: 100% (8/8), done.
Writing objects: 100% (9/9), 2.14 KiB | 2.14 MiB/s, done.
Total 9 (delta 6), reused 0 (delta 0), pack-reused 0

To github.com:user/repo.git
   3a7b9c2..8f4d1e5  feature/auth-refresh -> feature/auth-refresh

✅ 푸시 성공!

📊 최종 상태
─────────────────────────────────────
브랜치: feature/auth-refresh
원격: github.com:user/repo.git
최신: 8f4d1e5 docs(api): update auth endpoints
앞서있음: 0 commits
뒤처짐: 0 commits
─────────────────────────────────────

💡 다음 단계
1. PR 생성: claude > /pr
2. CI 확인: gh run watch
```

---
description: "여러 Subagent로 병렬 개발"
---

다음 작업을 병렬로 실행해주세요:

Subagent 1 (Explore):
- src/ 디렉토리 구조 분석
- 주요 클래스와 의존성 파악
- 결과를 explore_result.md에 저장

Subagent 2 (Plan):
- explore_result.md 읽기
- 새 기능 추가 계획 수립
- 결과를 plan.md에 저장

Subagent 3 (Task):
- plan.md 읽기
- 1단계 구현 (서비스 레이어)
- 결과를 Git에 커밋

모든 Subagent가 완료되면 요약 리포트 생성.
```

**사용**:

```bash
claude
> /parallel-dev

# Claude가 3개 Subagent 동시 실행
# 각자 독립적으로 작업 후 결과 통합
```

---
description: "오늘 작업 내용을 정리해서 개발 일지 작성"
---

오늘({{ 현재 날짜 }}) 작업한 내용으로 개발 일지를 작성해주세요.

## 수집 정보

### 1. Git 커밋 이력
```bash
git log --since="today" --author="$(git config user.name)" --oneline
```

### 2. 변경된 파일
```bash
git diff --name-status HEAD@{yesterday}..HEAD
```

### 3. 세션 기록
- .devlog/ 디렉토리의 오늘 날짜 md 파일들 읽기
- 각 커밋 시 저장된 요약 통합

## 출력 형식

파일명: `.devlog/YYYY-MM-DD.md`

내용:
```markdown
# 개발 일지 - YYYY-MM-DD

## 📊 요약
- 커밋 수: X개
- 변경 파일: Y개
- 주요 작업: [간단 요약]

## ✅ 완료한 작업

### [기능/버그/개선]
- 작업 내용 1
  - 상세 설명
  - 커밋: abc1234
- 작업 내용 2

## 🔧 진행 중인 작업
- 작업 A (70% 완료)
- 작업 B (시작 단계)

## 🐛 발견한 이슈
- 이슈 1: 설명
  - 해결 방법: ...
  - 또는 TODO로 남김

## 💡 배운 점
- 기술적 인사이트
- 개선 아이디어

## 📝 내일 할 일
- [ ] 작업 1
- [ ] 작업 2

## 📈 통계
- 추가된 코드: +XXX줄
- 삭제된 코드: -YYY줄
- 테스트 커버리지: ZZ%
```

## 추가 작업

1. Slack에 요약 전송 (선택)
```bash
if [ -f .slack-webhook ]; then
    curl -X POST $(cat .slack-webhook) \
      -H 'Content-Type: application/json' \
      -d '{"text": "오늘의 개발 일지 작성 완료: [링크]"}'
fi
```

```bash
git add .devlog/$(date +%Y-%m-%d).md
git commit -m "docs: add devlog for $(date +%Y-%m-%d)"
```

---
description: "Codex로 빠른 코드 체크 (medium effort)"
---

현재 작업 중인 코드를 빠르게 체크해주세요.

실행:
```bash
codex --effort medium "
최근 변경사항을 간단히 체크해줘.

변경 파일:
$(git diff --name-only)

Diff:
$(git diff)

체크 항목:
- 명백한 버그
- 기본 코드 품질
- 간단한 개선 제안

결과는 3가지로 분류:
OK: 문제 없음
MINOR: 사소한 개선 가능
ISSUE: 즉시 수정 필요

각 파일별로 간단히 요약.
시간 제한: 30초
"
```

결과:
```text
✅ UserService.java - OK
⚠️  UserController.java - MINOR
   - Line 45: 매직 넘버 사용 (상수로 대체 권장)
❌ PaymentService.java - ISSUE
   - Line 78: NullPointerException 가능성
```

시간: 빠름 (10-30초)
용도: 개발 중 수시로 체크

---
description: "Codex로 PR 전 전문 리뷰 (high effort)"
---

PR 생성 전 전문적인 코드 리뷰를 수행해주세요.

실행:
```bash
BASE_BRANCH=${1:-develop}

codex --effort high "
이 PR을 리뷰해줘.

Base: $BASE_BRANCH
Head: $(git branch --show-current)

커밋:
$(git log $BASE_BRANCH..HEAD --oneline)

전체 변경사항:
$(git diff $BASE_BRANCH..HEAD)

리뷰 기준:
1. 보안 (XSS, SQL Injection, 권한)
2. 성능 (N+1, 메모리 누수, 알고리즘)
3. 테스트 (커버리지, 엣지 케이스)
4. 설계 (SOLID, DRY, 응집도)
5. 가독성 (네이밍, 주석, 구조)

우선순위별 분류:
- CRITICAL: 반드시 수정 (보안, 데이터 손실)
- HIGH: 강력 권장 (버그, 성능 저하)
- MEDIUM: 권장 (코드 품질)
- LOW: 선택 (스타일, 일관성)

각 이슈마다:
- 파일명과 라인
- 문제 설명
- 해결 방법
- 예시 코드

GitHub PR Comment 형식으로 출력.
"
```

결과 (GitHub Markdown):
```markdown
## 🔍 Codex Code Review

### ⚠️ CRITICAL (1)

**PaymentService.java:78**
```java
// ❌ 현재 코드
payment.setAmount(request.getAmount());
orderRepository.save(order);

// 문제: 트랜잭션 없음. 결제 실패 시 주문은 저장됨
```

**해결책:**
```java
@Transactional
public Payment processPayment(PaymentRequest request) {
    Payment payment = paymentRepository.save(...);
    Order order = orderRepository.save(...);
    return payment;
}
```

### 🔴 HIGH (3)

**UserController.java:45**
```java
// ❌ N+1 쿼리 발생
users.forEach(user -> {
    user.getOrders().size();  // 각 user마다 쿼리 실행
});
```

**해결책:**
```java
// ✅ Fetch Join
@Query("SELECT u FROM User u LEFT JOIN FETCH u.orders")
List<User> findAllWithOrders();
```

... (계속)
```

시간: 보통 (1-3분)
용도: PR 생성 전 필수

---
description: "Codex로 프로덕션 배포 전 최종 감사 (xhigh effort)"
---

프로덕션 배포 전 최종 보안 감사를 수행해주세요.

실행:
```bash
RELEASE_BRANCH=${1:-release/v1.0}

codex --effort xhigh "
프로덕션 배포 전 최종 감사.

릴리스 브랜치: $RELEASE_BRANCH
포함 커밋: $(git rev-list --count main..$RELEASE_BRANCH)개

전체 코드베이스:
$(find src -name '*.java' | xargs cat)

환경 설정:
$(cat application*.yml)

의존성:
$(cat pom.xml)

집중 검사 항목:
1. 보안 취약점
   - OWASP Top 10
   - 민감정보 노출
   - 권한 우회
   - API 키 하드코딩

2. 데이터 무결성
   - 트랜잭션 경계
   - 동시성 제어
   - 데이터 검증

3. 가용성
   - 에러 핸들링
   - Circuit Breaker
   - Retry 로직
   - Timeout 설정

4. 성능
   - 쿼리 최적화
   - 캐싱 전략
   - 리소스 관리

5. 모니터링
   - 로깅
   - 메트릭
   - 알람

CRITICAL 이슈만 보고.
각 이슈는 CVE 참조 포함.
배포 GO/NO-GO 판단 포함.

상세 보고서 형식.
"
```

결과:
```markdown
# 프로덕션 배포 전 보안 감사 리포트

## Executive Summary

- 검사 파일: 147개
- 발견 이슈: CRITICAL 2개, HIGH 0개
- **배포 권장: NO-GO**
- 예상 수정 시간: 2시간

## 🚨 CRITICAL Issues

### 1. SQL Injection 취약점
**파일:** UserRepository.java:67
**CVE:** CWE-89

**현재 코드:**
```java
String sql = "SELECT * FROM users WHERE name = '" + name + "'";
jdbcTemplate.query(sql, ...);
```

**위험도:** CRITICAL
- 공격자가 임의 SQL 실행 가능
- 전체 DB 노출 위험

**해결책:**
```java
String sql = "SELECT * FROM users WHERE name = ?";
jdbcTemplate.query(sql, new Object[]{name}, ...);
```

**검증 방법:**
```bash
# 테스트
curl "/users?name=' OR '1'='1"
# 예상: 400 Bad Request
# 현재: 전체 사용자 목록 노출 ❌
```

**우선순위:** P0 - 즉시 수정 필요

### 2. API 키 하드코딩
**파일:** PaymentConfig.java:23
**CVE:** CWE-798

**현재 코드:**
```java
private static final String API_KEY = "sk_live_abc123...";
```

**위험도:** CRITICAL
- API 키 Git 히스토리에 노출
- 무단 결제 가능

**해결책:**
```java
@Value("${payment.api.key}")
private String apiKey;
```

**추가 조치:**
1. Git 히스토리에서 제거
   ```bash
   git filter-branch --force --index-filter \
     "git rm --cached --ignore-unmatch PaymentConfig.java" \
     --prune-empty --tag-name-filter cat -- --all
   ```
2. API 키 즉시 교체
3. .env에만 저장
4. AWS Secrets Manager 사용 권장

**우선순위:** P0 - 즉시 수정 필요

## ✅ Passed Checks

- ✓ CSRF 보호 활성화
- ✓ HTTPS 강제
- ✓ 입력 검증 (대부분)
- ✓ 에러 핸들링
- ✓ 로깅 적절

## 📋 Recommendations

1. **즉시 수정 (배포 전 필수)**
   - SQL Injection 수정
   - API 키 제거 및 재발급

2. **단기 (1주 내)**
   - 전체 코드 정적 분석 (SonarQube)
   - 침투 테스트
   - 보안 교육

3. **중기 (1개월 내)**
   - WAF 도입
   - Secrets Manager 전환
   - 보안 CI/CD 파이프라인

## 배포 결정

**GO / NO-GO: NO-GO**

이유:
- CRITICAL 이슈 2건
- SQL Injection은 즉각적 위험
- 수정 후 재검증 필요

예상 타임라인:
- 수정: 2시간
- 테스트: 1시간
- 재검증: 30분
- 재배포 준비: 내일 오전 가능
```

시간: 느림 (5-10분)
비용: 높음 (토큰 10배)
용도: 프로덕션 배포 전 필수

---
description: "Claude 개발 + Codex 리뷰 자동 루프"
---

Claude와 Codex가 협업하여 개발-리뷰 루프를 돌립니다.

## 워크플로우

1. **Claude**: 기능 개발
2. **Codex**: 코드 리뷰 (high effort)
3. **판단**:
   - CRITICAL 있음 → Claude가 수정 → 2번으로
   - CRITICAL 없음 → 커밋 + 종료

최대 3회 반복.

## 실행

```bash
TASK="$1"
MAX_ITERATIONS=3

for i in $(seq 1 $MAX_ITERATIONS); do
    echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
    echo "  Iteration $i / $MAX_ITERATIONS"
    echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
    
    if [ $i -eq 1 ]; then
        # 첫 iteration: 개발
        echo "🤖 Claude: 개발 중..."
        claude "$TASK"
    else
        # 이후: 수정
        echo "🔧 Claude: 이슈 수정 중..."
        claude "
        Codex 리뷰 결과:
        $(cat /tmp/codex_review.txt)
        
        CRITICAL 이슈만 수정해줘.
        "
    fi
    
    # Codex 리뷰
    echo "👁️  Codex: 리뷰 중..."
    codex --effort high "
    코드 리뷰:
    
    변경사항:
    $(git diff)
    
    CRITICAL 이슈만 찾아줘.
    없으면: LGTM
    " > /tmp/codex_review.txt
    
    REVIEW=$(cat /tmp/codex_review.txt)
    
    if echo "$REVIEW" | grep -qi "LGTM"; then
        echo "✅ 리뷰 통과!"
        echo "커밋할까요? (y/n)"
        read answer
        
        if [ "$answer" = "y" ]; then
            claude "/commit"
        fi
        break
    else
        echo "⚠️  CRITICAL 이슈 발견 (Iteration $i)"
        echo "$REVIEW"
        
        if [ $i -eq $MAX_ITERATIONS ]; then
            echo "❌ 최대 반복 횟수 도달"
            echo "수동 개입 필요"
            exit 1
        fi
        
        echo "계속? (y/n)"
        read answer
        if [ "$answer" != "y" ]; then
            exit 0
        fi
    fi
done
```

## 사용

```text
claude
> /ai-pair "사용자 로그인 API 구현"

# 자동으로:
# 1. Claude 개발
# 2. Codex 리뷰
# 3. 이슈 있으면 Claude 수정
# 4. 통과할 때까지 반복
```

# 공통 컨텍스트 (모든 Workspace에 붙여넣기)

## 프로젝트 정보
- Framework: React 18 + TypeScript
- Styling: Tailwind CSS
- Icons: Lucide React
- Charts: Recharts

## 디자인 시스템
색상:
- Primary: #3B82F6 (blue-500)
- Success: #10B981 (green-500)
- Warning: #F59E0B (amber-500)
- Error: #EF4444 (red-500)

컴포넌트:
- Card: rounded-lg shadow-md p-6
- Button: px-4 py-2 rounded-md
- Input: border rounded-md px-3 py-2

## API 엔드포인트
Base URL: http://localhost:8080/api

GET /stats/dashboard - 대시보드 통계
GET /users?page=1&size=20 - 사용자 목록
GET /stats/charts?period=week - 차트 데이터

## 요구사항
- 반응형 (Desktop: 1920px, Mobile: 375px)
- 로딩 상태 표시
- 에러 처리
- Skeleton loader 사용

# Workspace 1: 대시보드 메인
컴포넌트명: Dashboard.tsx

기능:
1. 통계 카드 3개 (매출, 사용자, 주문)
   - 전일 대비 증감률 표시 (%, 화살표)
   - 로딩 시 Skeleton
2. 레이아웃: Grid (Desktop 3칼럼, Mobile 1칼럼)

테스트:
- Desktop에서 카드 3개 한 줄 배치 확인
- Mobile에서 세로 스택 확인
- API 로딩 동작 확인

# Workspace 2: 사용자 관리
컴포넌트명: UserManagement.tsx

기능:
1. 테이블 (이름, 이메일, 가입일, 상태)
2. 검색 (이름/이메일)
3. 필터 (상태: 전체/활성/비활성)
4. 페이지네이션 (20개씩)
5. 액션: 수정, 삭제

테스트:
- 검색어 입력 시 필터링 동작
- 페이지 전환 동작
- 모바일에서 가로 스크롤

# Workspace 3: 통계 차트
컴포넌트명: StatsCharts.tsx

기능:
1. 기간 선택 (일/주/월)
2. 꺾은선 그래프 (매출)
3. 막대 그래프 (사용자)
4. 도넛 차트 (주문 상태)

테스트:
- 기간 변경 시 데이터 업데이트
- 툴팁 표시
- 범례 클릭 시 토글

# Antigravity에 붙여넣기

Browser Subagent로 E2E 테스트를 수행해줘.

## 시나리오: 사용자 가입 → 로그인 → 프로필 수정

### Step 1: 회원가입
1. http://localhost:3000/signup 열기
2. 폼 입력:
   - 이메일: [email protected]
   - 비밀번호: Test1234!
   - 비밀번호 확인: Test1234!
3. "가입하기" 버튼 클릭
4. 검증:
   - URL이 /login으로 변경
   - 성공 메시지 표시

### Step 2: 로그인
1. 이메일/비밀번호 입력
2. "로그인" 클릭
3. 검증:
   - URL이 /dashboard로 변경
   - 사용자 이름 표시

### Step 3: 프로필 수정
1. 사이드바 "프로필" 클릭
2. 이름 변경: "홍길동"
3. "저장" 클릭
4. 검증:
   - 성공 메시지
   - 헤더에 "홍길동" 표시

## 캡처 요청
- 각 Step마다 Before/After 스크린샷
- 전체 플로우 비디오 (1분)
- 네트워크 탭 (API 호출 확인)
- 콘솔 (에러 없는지 확인)

---
description: "원격 브랜치 최신 변경사항 가져오기"
---

원격 브랜치의 최신 변경사항을 안전하게 가져와주세요.

## 수행 단계

### 1. 현재 상태 저장
```bash
# Stash (작업 중인 변경사항 임시 저장)
if ! git diff-index --quiet HEAD --; then
    echo "⚠️  작업 중인 변경사항 발견"
    echo "임시 저장 중..."
    git stash push -m "auto-sync $(date +%Y%m%d-%H%M%S)"
    STASHED=true
fi
```

### 2. 원격 정보 업데이트
```bash
git fetch origin
```

### 3. 현재 브랜치 확인
```bash
CURRENT=$(git branch --show-current)
echo "현재 브랜치: $CURRENT"

# Tracking 브랜치 확인
UPSTREAM=$(git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null)

if [ -z "$UPSTREAM" ]; then
    echo "⚠️  Upstream 브랜치 없음"
    echo "설정할까요? (y/n)"
    read answer
    
    if [ "$answer" = "y" ]; then
        git branch --set-upstream-to=origin/$CURRENT $CURRENT
        UPSTREAM="origin/$CURRENT"
    else
        exit 0
    fi
fi
```

### 4. 변경사항 비교
```bash
BEHIND=$(git rev-list --count HEAD..$UPSTREAM)
AHEAD=$(git rev-list --count $UPSTREAM..HEAD)

echo "상태:"
echo "  로컬이 $AHEAD commits ahead"
echo "  로컬이 $BEHIND commits behind"

if [ $BEHIND -eq 0 ]; then
    echo "✅ 이미 최신 상태"
    exit 0
fi
```

### 5. Merge vs Rebase 선택
```bash
echo ""
echo "동기화 방법:"
echo "1. merge (머지 커밋 생성)"
echo "2. rebase (히스토리 깔끔)"
echo ""
read -p "선택 (1/2, 기본: 2): " method
method=${method:-2}

if [ "$method" = "1" ]; then
    git merge $UPSTREAM
else
    git rebase $UPSTREAM
fi

if [ $? -ne 0 ]; then
    echo "❌ 충돌 발생"
    echo ""
    echo "충돌 파일:"
    git diff --name-only --diff-filter=U
    echo ""
    echo "해결 방법:"
    echo "1. 충돌 파일 수동 수정"
    echo "2. git add [파일]"
    
    if [ "$method" = "2" ]; then
        echo "3. git rebase --continue"
    else
        echo "3. git merge --continue"
    fi
    
    exit 1
fi
```

### 6. Stash 복원
```bash
if [ "$STASHED" = true ]; then
    echo "작업 내용 복원 중..."
    git stash pop
    
    if [ $? -ne 0 ]; then
        echo "⚠️  Stash 복원 중 충돌"
        echo "수동 해결 후: git stash drop"
    fi
fi
```

## 사용 예시

```text
claude
> /sync

# 자동으로:
# 1. 현재 작업 stash
# 2. 원격에서 fetch
# 3. Rebase (또는 Merge)
# 4. Stash 복원

✅ 동기화 완료!
로컬: 3 commits ahead, 0 behind
```

---
description: "머지된 로컬 브랜치 삭제"
---

이미 머지된 로컬 브랜치를 안전하게 정리해주세요.

## 수행 단계

### 1. 머지된 브랜치 찾기
```bash
# main에 머지된 브랜치
MERGED_TO_MAIN=$(git branch --merged main | grep -v "main" | grep -v "*")

# develop에 머지된 브랜치
MERGED_TO_DEVELOP=$(git branch --merged develop | grep -v "develop" | grep -v "*")

# 합치기 (중복 제거)
MERGED=$(echo "$MERGED_TO_MAIN $MERGED_TO_DEVELOP" | tr ' ' '\n' | sort -u)

if [ -z "$MERGED" ]; then
    echo "✅ 정리할 브랜치 없음"
    exit 0
fi
```

### 2. 삭제 목록 표시
```bash
echo "삭제할 브랜치:"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "$MERGED"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "총 $(echo "$MERGED" | wc -l)개"
echo ""
echo "삭제하시겠습니까? (y/n/개별 선택)"
read answer
```

### 3. 삭제 실행
```bash
if [ "$answer" = "y" ]; then
    # 전체 삭제
    echo "$MERGED" | xargs git branch -d
    echo "✅ 전체 삭제 완료"
    
elif [ "$answer" = "개별 선택" ] || [ "$answer" = "개별" ]; then
    # 개별 선택
    for branch in $MERGED; do
        echo ""
        echo "브랜치: $branch"
        echo "  마지막 커밋: $(git log -1 --oneline $branch)"
        echo "  커밋 날짜: $(git log -1 --format=%cd $branch)"
        echo ""
        read -p "삭제? (y/n): " delete
        
        if [ "$delete" = "y" ]; then
            git branch -d $branch
            echo "  ✓ 삭제됨"
        else
            echo "  ○ 보존됨"
        fi
    done
fi
```

### 4. 원격 브랜치도 정리 (선택)
```bash
echo ""
echo "원격 브랜치도 정리할까요? (y/n)"
echo "(주의: 팀원과 공유 중인 브랜치 확인 필요)"
read remote_answer

if [ "$remote_answer" = "y" ]; then
    # Prune: 원격에서 삭제된 브랜치 로컬 참조 제거
    git remote prune origin
    
    echo "원격에서 삭제된 브랜치 정리 완료"
fi
```

## 주의사항
- main, develop 브랜치는 절대 삭제하지 않음
- 현재 체크아웃된 브랜치는 삭제하지 않음
- -d 옵션으로 안전하게 삭제 (머지 안된 브랜치는 거부)

---
description: "현재 코드에 대한 테스트 자동 생성"
---

현재 변경된 코드에 대한 테스트를 생성하고 실행해주세요.

## 수행 단계

### 1. 변경된 파일 분석
```bash
# 변경된 Java 파일
CHANGED_FILES=$(git diff --name-only | grep '\.java$' | grep -v 'Test\.java$')

if [ -z "$CHANGED_FILES" ]; then
    echo "테스트할 Java 파일 없음"
    exit 0
fi

echo "테스트 대상:"
echo "$CHANGED_FILES"
```

### 2. 각 파일마다 테스트 생성
```bash
for file in $CHANGED_FILES; do
    echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
    echo "파일: $file"
    
    # 클래스명 추출
    CLASS_NAME=$(basename $file .java)
    TEST_FILE="src/test/java/$(dirname $file | sed 's|src/main/java/||')/${CLASS_NAME}Test.java"
    
    # 이미 테스트 존재하는지 확인
    if [ -f "$TEST_FILE" ]; then
        echo "⚠️  테스트 이미 존재: $TEST_FILE"
        echo "업데이트할까요? (y/n)"
        read answer
        if [ "$answer" != "y" ]; then
            continue
        fi
    fi
    
    # Claude에게 테스트 생성 요청
    echo "🤖 테스트 생성 중..."
    
    TEST_CODE=$(claude --quiet "
    다음 클래스의 테스트를 작성해줘.
    
    파일: $file
    코드:
    $(cat $file)
    
    요구사항:
    - JUnit 5 사용
    - Mockito 사용 (의존성 있는 경우)
    - 모든 public 메서드 테스트
    - 정상 케이스 + 예외 케이스
    - Given-When-Then 패턴
    - 한국어 테스트 이름
    
    출력: 순수 Java 코드만
    ")
    
    # 테스트 파일 저장
    mkdir -p $(dirname $TEST_FILE)
    echo "$TEST_CODE" > $TEST_FILE
    
    echo "✅ 생성 완료: $TEST_FILE"
done
```

### 3. 테스트 실행
```bash
echo ""
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "테스트 실행"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━"

# Maven
if [ -f "pom.xml" ]; then
    mvn test
    
# Gradle
elif [ -f "build.gradle" ] || [ -f "build.gradle.kts" ]; then
    ./gradlew test
fi

TEST_RESULT=$?
```

### 4. 결과 분석
```bash
if [ $TEST_RESULT -eq 0 ]; then
    echo "✅ 모든 테스트 통과!"
    
    # 커버리지 확인 (JaCoCo)
    if [ -f "target/site/jacoco/index.html" ]; then
        COVERAGE=$(grep -oP 'Total.*?(\d+)%' target/site/jacoco/index.html | grep -oP '\d+')
        echo "📊 코드 커버리지: $COVERAGE%"
        
        if [ $COVERAGE -lt 80 ]; then
            echo "⚠️  커버리지 목표 미달 (목표: 80%)"
        fi
    fi
    
    # 테스트 커밋
    echo ""
    echo "테스트를 커밋할까요? (y/n)"
    read commit_answer
    
    if [ "$commit_answer" = "y" ]; then
        git add src/test/
        git commit -m "test: add tests for changed classes"
    fi
else
    echo "❌ 테스트 실패"
    echo ""
    echo "실패한 테스트 수정할까요? (y/n)"
    read fix_answer
    
    if [ "$fix_answer" = "y" ]; then
        # Claude에게 수정 요청
        claude "
        테스트가 실패했어.
        
        실패 로그:
        $(cat target/surefire-reports/*.txt 2>/dev/null)
        
        테스트 코드를 수정해서 통과하도록 해줘.
        "
        
        # 재실행
        /test
    fi
fi
```

## 고급 옵션

### 특정 클래스만 테스트
```bash
claude
> /test UserService

# UserService.java만 테스트 생성
```

### 커버리지 리포트 자동 생성
```bash
# 테스트 실행 후
if [ -f "target/site/jacoco/index.html" ]; then
    # 브라우저로 열기
    open target/site/jacoco/index.html
    
    # 또는 Claude에게 분석 요청
    claude "
    JaCoCo 리포트를 분석해줘.
    
    HTML: $(cat target/site/jacoco/index.html)
    
    다음 정보 추출:
    - 전체 커버리지
    - 커버리지 낮은 클래스 Top 5
    - 개선 제안
    "
fi
```

---
description: "선택한 코드를 리팩토링"
---

지정한 파일 또는 클래스를 리팩토링해주세요.

## 수행 단계

### 1. 대상 선택
```bash
TARGET="$1"

if [ -z "$TARGET" ]; then
    echo "리팩토링 대상:"
    echo "1. 최근 변경된 파일"
    echo "2. 특정 파일 지정"
    echo "3. 전체 프로젝트"
    read -p "선택 (1/2/3): " choice
    
    case $choice in
        1)
            TARGET=$(git diff --name-only)
            ;;
        2)
            read -p "파일 경로: " TARGET
            ;;
        3)
            TARGET="src/"
            ;;
    esac
fi
```

### 2. 리팩토링 분석
```bash
echo "🔍 코드 분석 중..."

ANALYSIS=$(claude --quiet "
다음 코드를 분석해서 리팩토링 제안해줘.

코드:
$(cat $TARGET)

분석 항목:
1. 코드 스멜 (Long Method, Large Class, etc)
2. SOLID 원칙 위반
3. 중복 코드
4. 복잡도 (Cyclomatic Complexity)
5. 네이밍

제안 형식:
### [우선순위] 제목
- 현재 문제
- 리팩토링 방법
- 예상 효과
")

echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "$ANALYSIS"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
```

### 3. 우선순위 선택
```bash
echo ""
echo "리팩토링 실행할 항목:"
echo "1. HIGH만"
echo "2. HIGH + MEDIUM"
echo "3. 전체"
echo "4. 취소"
read -p "선택: " priority
```

### 4. 리팩토링 실행
```bash
if [ "$priority" != "4" ]; then
    echo "🔧 리팩토링 실행 중..."
    
    PRIORITY_FILTER=""
    case $priority in
        1) PRIORITY_FILTER="HIGH" ;;
        2) PRIORITY_FILTER="HIGH|MEDIUM" ;;
        3) PRIORITY_FILTER=".*" ;;
    esac
    
    claude "
    다음 분석 결과를 바탕으로 리팩토링을 실행해줘.
    
    분석:
    $ANALYSIS
    
    우선순위: $PRIORITY_FILTER 만
    
    원본 코드:
    $(cat $TARGET)
    
    주의사항:
    - 기능 변경 금지
    - 테스트 깨지지 않게
    - 한 번에 하나씩 변경
    - 각 변경마다 설명 코멘트
    "
    
    echo "✅ 리팩토링 완료"
fi
```

### 5. 검증
```bash
echo ""
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "검증"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━"

# 테스트 실행
echo "🧪 테스트 실행..."
mvn test

if [ $? -eq 0 ]; then
    echo "✅ 테스트 통과"
    
    # Diff 확인
    echo ""
    echo "변경사항:"
    git diff $TARGET
    
    echo ""
    echo "커밋할까요? (y/n)"
    read commit
    
    if [ "$commit" = "y" ]; then
        git add $TARGET
        git commit -m "refactor: improve code quality in $TARGET"
    fi
else
    echo "❌ 테스트 실패. 리팩토링 롤백할까요? (y/n)"
    read rollback
    
    if [ "$rollback" = "y" ]; then
        git checkout -- $TARGET
        echo "✅ 롤백 완료"
    fi
fi
```

## Codex 통합 버전

리팩토링 후 자동 리뷰:

```text
# 리팩토링 완료 후
echo "🤖 Codex 리뷰 중..."

REVIEW=$(codex --effort medium "
리팩토링된 코드를 리뷰해줘.

Before:
$(git show HEAD:$TARGET)

After:
$(cat $TARGET)

체크 항목:
- 기능 동일성
- 코드 품질 개선 여부
- 새로운 이슈 없는지
")

echo "$REVIEW"
```

---
description: "특정 팀원에게 리뷰 요청"
---

팀원에게 코드 리뷰를 요청하고 알림을 보냅니다.

## 수행 단계

### 1. PR 확인
```bash
# 현재 브랜치의 PR 찾기
PR_URL=$(gh pr view --json url -q .url 2>/dev/null)

if [ -z "$PR_URL" ]; then
    echo "❌ PR이 없습니다."
    echo "먼저 PR을 생성하세요: /pr"
    exit 1
fi

PR_NUMBER=$(gh pr view --json number -q .number)
echo "📝 PR #$PR_NUMBER"
```

### 2. 리뷰어 선택
```bash
# CODEOWNERS 기반 추천
if [ -f .github/CODEOWNERS ]; then
    SUGGESTED=$(grep -h "$(git diff --name-only main | head -1)" .github/CODEOWNERS | awk '{print $2}')
    echo "추천 리뷰어: $SUGGESTED"
fi

# 최근 기여자
echo ""
echo "최근 기여자:"
git log --format="%an" --since="1 month ago" | sort | uniq -c | sort -rn | head -5

echo ""
read -p "리뷰어 GitHub ID: " REVIEWER
```

### 3. 리뷰 포인트 자동 생성
```bash
echo "🤖 리뷰 포인트 생성 중..."

REVIEW_POINTS=$(claude --quiet "
이 PR의 리뷰 포인트를 정리해줘.

PR: $PR_URL
커밋:
$(git log main..HEAD --oneline)

변경사항:
$(git diff main --stat)

출력 형식:
## 주요 변경사항
- ...

## 리뷰 시 확인할 사항
- [ ] ...

## 테스트 방법
...
")
```

### 4. 리뷰 요청 및 알림
```bash
# GitHub에 리뷰어 지정
gh pr edit $PR_NUMBER --add-reviewer $REVIEWER

# PR에 코멘트 추가
gh pr comment $PR_NUMBER --body "
@$REVIEWER 리뷰 부탁드립니다! 🙏

$REVIEW_POINTS

---
/review-request 명령으로 자동 생성됨
"

# Slack 알림 (설정된 경우)
if [ -f .slack-webhook ]; then
    SLACK_URL=$(cat .slack-webhook)
    
    curl -X POST $SLACK_URL \
      -H 'Content-Type: application/json' \
      -d '{
        "text": "🔔 리뷰 요청",
        "blocks": [
          {
            "type": "section",
            "text": {
              "type": "mrkdwn",
              "text": "*@'$REVIEWER'* 리뷰 부탁드립니다!"
            }
          },
          {
            "type": "section",
            "text": {
              "type": "mrkdwn",
              "text": "<'$PR_URL'|PR #'$PR_NUMBER' 보기>"
            }
          }
        ]
      }'
fi

echo ""
echo "✅ 리뷰 요청 완료!"
echo "   리뷰어: @$REVIEWER"
echo "   PR: $PR_URL"
echo "   Slack 알림: ✓"
```

---
description: "어제-오늘-이슈 형식의 스탠드업 리포트"
---

스탠드업 미팅용 리포트를 생성합니다.

## 수행 단계

### 1. 어제 작업 수집
```bash
echo "📅 어제 작업 분석 중..."

YESTERDAY_COMMITS=$(git log --since="yesterday" --until="today" --author="$(git config user.name)" --oneline)

YESTERDAY_SUMMARY=$(claude --quiet "
어제 작업을 요약해줘.

커밋:
$YESTERDAY_COMMITS

변경사항:
$(git diff --stat HEAD@{yesterday}..HEAD@{today})

출력 형식:
- 작업1 (완료/진행 중)
- 작업2
")
```

### 2. 오늘 계획 입력
```bash
echo "📝 오늘 계획:"
echo "   (Enter를 두 번 누르면 완료)"
echo ""

TODAY_PLAN=""
while IFS= read -r line; do
    if [ -z "$line" ]; then
        break
    fi
    TODAY_PLAN="$TODAY_PLAN
- $line"
done
```

### 3. 이슈/블로커 확인
```bash
echo ""
echo "⚠️  이슈나 블로커가 있나요? (y/n)"
read has_blocker

BLOCKERS=""
if [ "$has_blocker" = "y" ]; then
    echo "이슈 설명:"
    while IFS= read -r line; do
        if [ -z "$line" ]; then
            break
        fi
        BLOCKERS="$BLOCKERS
- $line"
    done
fi
```

### 4. 리포트 생성
```bash
REPORT=$(cat <<EOF
# 스탠드업 - $(date +%Y년\ %m월\ %d일)

## ✅ 어제 한 일
$YESTERDAY_SUMMARY

## 📋 오늘 할 일
$TODAY_PLAN

## ⚠️ 이슈/블로커
${BLOCKERS:-없음}

---
작성자: $(git config user.name)
작성 시각: $(date +%H:%M)
EOF
)

echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "$REPORT"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
```

### 5. 공유
```bash
echo ""
echo "공유 방법:"
echo "1. Slack"
echo "2. 파일 저장만"
echo "3. 취소"
read -p "선택: " share_method

case $share_method in
    1)
        # Slack
        if [ -f .slack-standup-webhook ]; then
            curl -X POST $(cat .slack-standup-webhook) \
              -H 'Content-Type: application/json' \
              -d '{
                "text": "'"$REPORT"'"
              }'
            echo "✅ Slack 전송 완료"
        fi
        
        # 파일도 저장
        mkdir -p .standup
        echo "$REPORT" > .standup/$(date +%Y-%m-%d).md
        ;;
    2)
        mkdir -p .standup
        echo "$REPORT" > .standup/$(date +%Y-%m-%d).md
        echo "✅ 저장: .standup/$(date +%Y-%m-%d).md"
        ;;
esac
```

## 🔍 Code Review

### 🚨 Security Issues

**FileUploadController.java:45**
```java
@PostMapping("/upload")
public ResponseEntity<?> upload(@RequestParam MultipartFile file) {
    String filename = file.getOriginalFilename();
    file.transferTo(new File("/uploads/" + filename));  // ❌
}
```

**Issues:**
1. Path Traversal 취약점
   - `../../../etc/passwd` 같은 파일명 가능
2. 파일 확장자 검증 없음
   - 악성 스크립트 업로드 가능
3. 파일 크기 제한 없음
   - DoS 공격 가능

**Recommendation:**
```java
@PostMapping("/upload")
public ResponseEntity<?> upload(@RequestParam MultipartFile file) {
    // 1. 확장자 검증
    String ext = FilenameUtils.getExtension(file.getOriginalFilename());
    if (!ALLOWED_EXTENSIONS.contains(ext)) {
        throw new InvalidFileException();
    }
    
    // 2. 파일 크기 (5MB)
    if (file.getSize() > 5 * 1024 * 1024) {
        throw new FileTooLargeException();
    }
    
    // 3. 안전한 파일명
    String safeFilename = UUID.randomUUID() + "." + ext;
    Path uploadPath = Paths.get("/uploads").resolve(safeFilename);
    
    // 4. Path Traversal 방지
    if (!uploadPath.normalize().startsWith("/uploads")) {
        throw new SecurityException();
    }
    
    file.transferTo(uploadPath.toFile());
}
```

### ⚠️ Performance

**ImageService.java:67**
- 이미지 리사이징이 동기로 처리됨
- 대용량 파일 시 응답 지연

**Recommendation:**
```java
@Async
public CompletableFuture<String> resizeImage(String filename) {
    // 비동기 리사이징
}
```

### ✅ Good Points
- 테스트 작성됨 (FileUploadTest.java)
- S3 업로드 잘 구현됨
- 로깅 적절

### 📝 Minor
- 매직 넘버 (5MB, 1024x1024) → 상수로
- 주석 부족 (특히 파일 검증 로직)