프롬프트 집약체
Sonnet을 한 체급 위로

[작업]
(여기에 작업 내용을 쓴다)

진행 방식 — 반드시 이 순서를 지켜라:

1. 코드를 수정하기 전에 관련 파일을 먼저 읽고 현재 동작을 파악해라.
   grep/검색으로 호출부·유사 구현·기존 컨벤션까지 확인해라.
2. 파악이 끝나면 구현 전에 다음 형식으로 보고해라:
   - 변경 파일 목록: 파일별로 "무엇을 왜" 한 줄씩
   - 영향 범위: 이 변경이 건드릴 수 있는 다른 기능
   - 불확실한 점: 확신 없는 부분은 추측하지 말고 여기에 명시
   - 대안: 더 단순한 방법이 있으면 함께 제시
3. 내가 "진행"이라고 답하기 전에는 구현을 시작하지 마라.
4. 구현 중 계획에 없던 파일을 수정해야 하면 멈추고 이유부터 보고해라.

금지사항:
- 파일에서 존재를 확인하지 않은 함수/API/설정 사용 금지
- "아마 ~일 것이다" 기반 수정 금지 — 반드시 코드로 확인
- 요청 범위 밖의 리팩토링·포맷 변경 금지 (제안은 가능, 실행은 금지)

구현이 끝났다고 판단되면, 완료 보고 전에 아래를 스스로 수행해라:

1. [셀프 리뷰] 변경한 diff 전체를 처음 보는 리뷰어의 눈으로 다시 읽어라.
   - 로직 오류, 빠뜨린 호출부, 깨질 수 있는 기존 기능을 찾아라
   - 발견하면 조용히 고치지 말고 "셀프 리뷰에서 발견: ..."으로 보고 후 수정해라
2. [실행 검증] 빌드/테스트/린트를 실제로 실행해라.
   - 실패하면 원인을 분석해 수정하고 재실행해라 (최대 3회, 그래도 실패면 상태 그대로 보고)
   - 실행할 수 없는 환경이면 "검증 못 함"을 명시해라. 통과한 척 금지.
3. [엣지 케이스] 이 변경이 깨질 수 있는 입력·상황 3가지를 나열하고,
   각각 현재 코드가 처리하는지 코드 근거(파일:라인)와 함께 확인해라.
4. [최종 보고] 다음 3항목으로만 보고해라:
   - 변경한 것 / 검증한 것(실행 결과 포함) / 남은 리스크·확인 못 한 것

"모든 게 완벽합니다" 류의 보고는 금지. 리스크 0인 변경은 없다.

[버그 리포트]
- 증상: (무엇이 잘못되는가)
- 재현 절차: (어떻게 하면 발생하는가)
- 기대 동작: (원래 어때야 하는가)

디버깅 규칙 — 원인 확정 전에는 코드 수정 금지:

1. [증거 수집] 관련 코드 경로를 추적하고, 로그·에러 메시지·데이터 흐름에서
   사실만 수집해라. 이 단계에서는 해석하지 마라.
2. [가설 수립] 원인 가설을 3개까지 세우고 가능성 순으로 정렬해라.
   각 가설마다 "이게 맞다면 ~에서 ~가 관찰되어야 한다"는 예측을 달아라.
3. [실험] 가설별로 가장 싼 검증 방법(로그 추가, 단위 재현, 값 확인)을 실행해
   가설을 기각하거나 채택해라. 결과를 표로 보고해라.
4. [수정] 원인이 확정되면 최소 수정을 해라. 증상 은폐(try-catch로 덮기,
   조건문 덧대기)가 아니라 원인을 제거해라.
5. [재검증] 원래 재현 절차로 버그가 사라졌는지 + 주변 기능이 안 깨졌는지 확인해라.

원인을 못 찾으면 "가장 유력한 가설 + 추가로 필요한 정보"를 보고해라.
찍어서 고치는 것보다 그게 낫다.

이 변경사항을 리뷰해라. 규칙:

1. 지적은 심각도 순으로 정렬해라:
   - [치명] 버그, 데이터 손실, 보안 문제 — 머지 전 반드시 수정
   - [주의] 엣지 케이스, 성능, 유지보수 함정 — 수정 권장
   - [제안] 더 나은 방법 — 선택 사항
2. 모든 지적에는 증거를 달아라: 파일:라인 + 문제가 되는 시나리오.
   "~할 수도 있다"가 아니라 "입력이 X면 Y에서 Z가 발생한다"로 써라.
3. 확신 없는 지적은 별도로 "확인 필요" 섹션에 분리해라.
4. 스타일·네이밍은 프로젝트의 기존 컨벤션과 다를 때만 지적해라.
   개인 취향 지적 금지.
5. 지적할 게 없으면 없다고 해라. 억지로 채우지 마라.
6. 마지막에 한 줄 판정: 머지 가능 / 수정 후 머지 / 재작업 필요

리뷰 전에 변경된 파일뿐 아니라 그 코드를 호출하는 쪽도 읽어라.
diff만 보고 하는 리뷰는 반쪽짜리다.

[큰 작업]
(여기에 작업 내용을 쓴다)

이 작업은 한 번에 하지 말고 체크포인트 방식으로 진행해라:

1. 작업을 3~7개 단계로 분해해라. 각 단계는:
   - 그 단계만 끝나도 빌드가 깨지지 않고 동작하는 상태여야 한다
   - 독립적으로 검증 가능한 결과물이 있어야 한다
2. 분해안을 먼저 보고하고 내 승인을 받아라.
3. 승인 후 한 단계씩 진행하며, 단계가 끝날 때마다:
   - 완료한 것 / 실행 검증 결과 / 다음 단계 예고를 3줄로 보고해라
   - 계획과 달라진 게 있으면 그 이유를 명시해라
4. 진행 중 새로운 문제를 발견하면 즉석에서 해결하려 들지 말고,
   "발견 사항"으로 기록해 보고하고 현재 단계에 집중해라.
5. 전체 완료 시: 단계별 결과 요약 + 남은 발견 사항 목록으로 마무리해라.

이 방식의 목적: 어느 시점에 중단돼도 쓸 수 있는 상태를 유지하는 것.

# 프로젝트: (이름)

## 한 줄 설명
(이 프로젝트가 무엇이고 누가 쓰는지 — 모델이 판단 기준으로 삼는다)

## 명령어 — 반드시 이것을 사용
- 빌드: `(명령)`
- 테스트: `(명령)`   ← 코드 수정 후 반드시 실행
- 린트/포맷: `(명령)`
- 로컬 실행: `(명령)`

## 아키텍처 (모델이 길을 잃지 않게)
- 진입점: (파일)
- 핵심 디렉토리: src/api(...) · src/core(...) · src/ui(...)
- 데이터 흐름: (예: 요청 → 라우터 → 서비스 → 저장소)

## 컨벤션
- (예: 에러는 반드시 AppError로 래핑해서 던진다)
- (예: API 응답은 반드시 responses.ts의 헬퍼를 쓴다)
- (예: 날짜는 전부 UTC, 표시할 때만 로컬 변환)

## 작업 규칙
1. 코드 수정 전 관련 파일을 먼저 읽는다. 추측 수정 금지.
2. 완료 보고 전 테스트를 실행하고 결과를 보고에 포함한다.
3. 요청 범위 밖 리팩토링 금지 — 발견한 개선점은 보고만 한다.
4. 확신이 없으면 구현 대신 질문한다.

## 건드리면 안 되는 것
- (예: migrations/ 폴더 — 수동 관리)
- (예: legacy/ — 참조만, 수정 금지)

# 품질 게이트 — "완료"라고 말하기 위한 조건

작업 유형과 무관하게, 아래 게이트를 통과하지 못하면 완료가 아니다.
보고 시 각 게이트의 통과 여부를 명시한다.

## Gate 1 — 실행 증거
- [ ] 빌드가 통과한다 (출력 확인)
- [ ] 테스트가 통과한다 (신규 로직이면 테스트 추가)
- [ ] 실제로 한 번 실행해봤다 (핵심 시나리오 1개 이상)
- 실행 못 한 항목은 "미검증"으로 보고에 명시

## Gate 2 — 변경 위생
- [ ] diff에 요청과 무관한 변경이 없다
- [ ] 디버그 출력·주석 처리된 코드·TODO를 남기지 않았다
- [ ] 하드코딩된 값에는 이유가 있다 (없으면 설정/상수로)

## Gate 3 — 엣지 케이스
- [ ] 빈 값/null/0/음수 입력을 확인했다
- [ ] 에러 경로를 확인했다 (실패 시 무슨 일이 일어나는가)
- [ ] 이 변경으로 깨질 수 있는 기존 기능을 확인했다

## Gate 4 — 보고 형식
완료 보고는 반드시: 변경한 것 / 검증한 것(증거 포함) / 남은 리스크
"완벽하다", "문제없다" 같은 표현 대신 확인한 사실만 쓴다.

# 금지 패턴 — 이 문서의 위반은 버그로 취급한다

## 1. 추측 코딩
- 존재를 확인하지 않은 함수/필드/설정을 사용하는 것
- 교정: 사용 전 반드시 정의를 읽는다. 없으면 "없음"을 보고한다.

## 2. 조기 완료 선언
- 실행해보지 않고 "완료됐습니다"라고 말하는 것
- 교정: 실행 증거 없는 완료 보고 금지. 미검증은 미검증이라 쓴다.

## 3. 샷건 수정
- 원인 파악 없이 여기저기 고쳐보며 증상이 사라지길 바라는 것
- 교정: 원인을 한 문장으로 설명할 수 있을 때만 수정한다.

## 4. 증상 은폐
- try-catch로 덮기, 조건문 덧대기, 타입 단언으로 컴파일러 침묵시키기
- 교정: 에러를 숨기는 수정은 수정이 아니다. 원인을 제거한다.

## 5. 범위 초과
- 요청받지 않은 리팩토링, 스타일 변경, "김에 개선"
- 교정: 발견한 개선점은 보고 목록으로만. diff는 요청 범위만.

## 6. 컨텍스트 무시
- 프로젝트에 이미 있는 유틸/패턴을 두고 새로 만드는 것
- 교정: 구현 전에 유사 기능을 grep으로 찾는다. 있으면 재사용.

## 7. 침묵하는 가정
- "일단 이렇게 가정하고 진행했습니다"를 나중에 말하는 것
- 교정: 가정이 생기는 순간 보고한다. 중대하면 진행 전에 묻는다.

# 시스템 아키텍처 — AI 어시스턴트용 지도

> 목적: 이 문서만 읽으면 "어디에 무엇이 있고, 새 코드는 어디에 넣어야
> 하는지" 알 수 있게 한다. 코드가 바뀌면 이 문서도 갱신한다.

## 시스템 개요
(3~5줄: 무엇을 하는 시스템이고, 큰 구성요소가 무엇인지)

## 디렉토리 지도
| 경로 | 역할 | 새 코드를 넣는 기준 |
|------|------|--------------------|
| src/api/ | HTTP 엔드포인트 | 새 API 추가 시 |
| src/services/ | 비즈니스 로직 | 도메인 로직은 전부 여기 |
| src/repos/ | DB 접근 | SQL/쿼리는 여기 외 금지 |
| (계속) | | |

## 핵심 흐름 (대표 시나리오 1~2개)
예) 주문 생성: POST /orders → OrderService.create()
   → 재고 확인(InventoryService) → OrderRepo.insert() → 이벤트 발행

## 경계와 규칙
- 레이어 규칙: api → service → repo 단방향. 역방향 import 금지
- 외부 연동: (무엇과 통신하는지, mock은 어디 있는지)
- 상태/캐시: (어디에 뭘 저장하는지)

## 함정 목록 (신규 투입자가 반드시 밟는 지뢰)
- (예: 이 테이블은 soft delete라 where deleted_at is null 필수)
- (예: 이 API는 레거시 호환 때문에 응답 필드를 빼면 안 됨)

# 표준 작업 프로토콜

모든 비자명한 작업은 아래 5단계로 진행한다.
단계를 건너뛰려면 그 이유를 먼저 보고한다.

## 1단계 — 탐색 (코드 수정 금지)
- 요구사항과 관련된 파일·호출부·유사 구현·테스트를 읽는다
- 기존 컨벤션과 재사용 가능한 코드를 찾는다
- 산출: 현재 상태 요약 3~5줄

## 2단계 — 계획
- 변경 파일 목록(무엇을·왜), 영향 범위, 불확실한 점을 정리한다
- 접근이 여러 개면 트레이드오프 비교 후 추천안을 낸다
- 복잡한 작업이면 사용자 승인을 받고 진행한다

## 3단계 — 구현
- 계획 순서대로, 한 번에 하나의 관심사만 변경한다
- 계획에 없던 수정이 필요해지면 멈추고 보고한다
- 각 변경 후 빌드가 깨지지 않는 상태를 유지한다

## 4단계 — 검증
- 빌드·테스트·린트 실행 (프로젝트 명령 사용)
- 핵심 시나리오 1개 이상 실제 실행
- diff 전체를 셀프 리뷰 (quality-gates.md 기준)

## 5단계 — 보고
- 변경한 것 / 검증한 것(증거) / 남은 리스크 3항목
- 발견했지만 범위 밖이라 안 한 개선점은 별도 목록으로