create-claude-pipeline 0.1.0

package/template/.claude/skills/write-qa-report/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: write-qa-report
+description: "QA 엔지니어가 검증 완료 후 최종 QA 보고서를 작성할 때 참조하는 skill. PM이 배포 결정을 내릴 수 있는 수준의 보고서를 context/qa_report.md로 저장한다. 검증 범위, 결과 요약, 버그 목록, 심각도별 분석, 미검증 항목, 배포 권고까지 포함한다. QA Agent가 테스트를 모두 마치고 보고서를 작성할 때, PM에게 QA 결과를 전달할 때, 배포 승인 여부를 판단해야 할 때 반드시 사용한다. 'QA 보고서 작성', 'qa_report 생성', '테스트 결과 정리', '배포 가능 여부 판단', 'QA 완료 보고' 등의 상황에서 트리거된다."
+---
+
+# Write QA Report
+
+QA 엔지니어가 검증을 마친 후 최종 보고서를 작성하는 skill이다.
+
+이 보고서의 독자는 PM이다. PM은 이 보고서 하나만 보고 "배포해도 되는가?"를 판단해야 한다. 따라서 보고서는 기술적 세부사항보다 **의사결정에 필요한 정보**에 집중한다. 버그가 몇 개이고, 얼마나 심각하고, 해결됐는지, 배포해도 안전한지를 명확하게 전달하는 것이 목적이다.
+
+---
+
+## 작성 절차
+
+### 1. 테스트 결과 수집
+
+보고서를 작성하기 전에 아래 정보를 정리한다:
+
+- 실행한 테스트 케이스 전체 목록과 결과 (통과/실패/보류)
+- 발견된 버그 목록과 현재 상태 (수정됨/미수정/재현불가)
+- 기획안(`context/01_plan.md`)에서 명시된 기능 중 검증하지 못한 항목
+- 검증 과정에서 발견한 위험 요소
+
+### 2. 보고서 작성
+
+아래 템플릿에 따라 `context/qa_report.md`를 작성한다.
+
+---
+
+## 보고서 템플릿
+
+```markdown
+# QA 보고서
+
+> 작성일: YYYY-MM-DD
+> 검증 대상: (기능/버전 명시)
+> 기준 문서: context/01_plan.md
+
+---
+
+## 1. 검증 범위
+
+- 테스트 케이스: **N개**
+- 검증 기준: context/01_plan.md 기획안 + context/03_api_spec.md API 명세
+- 검증 기간: YYYY-MM-DD
+
+---
+
+## 2. 결과 요약
+
+| 구분 | 수량 |
+|------|------|
+| 전체 | N |
+| ✅ 통과 | N |
+| ❌ 실패 | N |
+| ⏸ 보류 | N |
+
+**통과율: N%**
+
+---
+
+## 3. 버그 목록
+
+| ID | 심각도 | 제목 | 대상 | 상태 |
+|----|--------|------|------|------|
+| BUG-001 | 🔴 Critical | 결제 시 금액 0원 처리 | BE - payments API | ✅ 수정됨 |
+| BUG-002 | 🟠 High | 로그인 후 리다이렉트 실패 | FE - auth | ✅ 수정됨 |
+| BUG-003 | 🟡 Medium | 목록 빈 상태 UI 미표시 | FE - orders | ⏳ 미수정 |
+| BUG-004 | 🔵 Low | 날짜 포맷 불일치 | FE - common | ⏳ 미수정 |
+
+발견된 버그가 없으면 "발견된 버그 없음"으로 작성한다.
+
+---
+
+## 4. 심각도별 분석
+
+### 🔴 Critical (서비스 불가 수준)
+- BUG-001: 결제 시 금액 0원 처리 → **수정 완료, 재검증 통과**
+
+### 🟠 High (핵심 기능 장애)
+- BUG-002: 로그인 후 리다이렉트 실패 → **수정 완료, 재검증 통과**
+
+### 🟡 Medium (불편하지만 우회 가능)
+- BUG-003: 목록 빈 상태 UI 미표시 → 배포 후 처리 가능 (기능 동작에 영향 없음)
+
+### 🔵 Low (사소한 개선)
+- BUG-004: 날짜 포맷 불일치 → 배포 후 처리 가능
+
+해당 심각도의 버그가 없으면 "없음"으로 작성한다.
+
+---
+
+## 5. 미검증 항목
+
+| 항목 | 미검증 이유 |
+|------|------------|
+| (항목 없으면 "모든 기획 항목 검증 완료" 작성) | |
+
+미검증 항목이 있으면 PM이 리스크를 판단할 수 있도록 이유를 명확히 작성한다.
+예: "외부 결제 API 연동 — 테스트 환경에서 실제 결제 불가"
+
+---
+
+## 6. 배포 권고
+
+(아래 두 가지 중 하나를 선택하여 작성한다)
+
+### ✅ 배포 가능
+
+**판단 근거:**
+- Critical/High 버그 0건 (또는 모두 수정 완료)
+- 통과율 N%
+- 미수정 버그는 Medium/Low만 N건 — 배포 후 처리 가능
+
+### ❌ 배포 불가
+
+**미해결 차단 버그:**
+- BUG-XXX: (제목) — Critical/High, 미수정
+- BUG-YYY: (제목) — Critical/High, 미수정
+
+**배포를 위해 필요한 조치:**
+1. (구체적 수정 사항)
+2. (재검증 필요 범위)
+```
+
+---
+
+## 판단 기준
+
+배포 권고를 결정할 때 아래 기준을 따른다:
+
+| 조건 | 배포 권고 |
+|------|----------|
+| Critical/High 미수정 0건 | ✅ 배포 가능 |
+| Critical 미수정 1건 이상 | ❌ 배포 불가 |
+| High 미수정 1건 이상 | ❌ 배포 불가 (PM 판단에 따라 예외 가능) |
+| Medium/Low만 미수정 | ✅ 배포 가능 (배포 후 처리 명시) |
+| 미검증 항목 있음 | 리스크 명시 후 PM 판단에 위임 |
+
+이 기준은 기본값이다. PM이 비즈니스 상황에 따라 다르게 판단할 수 있으므로, 보고서는 판단의 **근거**를 제공하는 데 집중한다.
+
+---
+
+## 작성 규칙
+
+- 버그 ID는 `BUG-001`부터 순번으로 매긴다
+- 심각도 이모지를 일관되게 사용한다: 🔴 Critical, 🟠 High, 🟡 Medium, 🔵 Low
+- 상태 이모지를 일관되게 사용한다: ✅ 수정됨, ⏳ 미수정, 🔄 재현불가
+- "배포 가능"이라도 미수정 Medium/Low가 있으면 반드시 목록을 남긴다
+- 파일 저장 경로: `context/qa_report.md`

package/template/.claude/skills/write-security-report/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: write-security-report
+description: "보안 리뷰어가 검토 완료 후 최종 보안 보고서를 작성할 때 참조하는 skill. OWASP Top 10 체크 결과와 발견된 취약점을 PM이 배포 결정에 사용할 수 있는 형식으로 context/security_report.md에 작성한다. Security Agent가 취약점 탐색을 마치고 보고서를 작성할 때, PM에게 보안 검토 결과를 전달할 때, 배포 전 보안 승인이 필요할 때 반드시 사용한다. '보안 보고서 작성', 'security_report 생성', '보안 검토 결과 정리', '배포 보안 승인', 'OWASP 체크 결과 보고' 등의 상황에서 트리거된다."
+---
+
+# Write Security Report
+
+보안 리뷰어가 검토를 완료한 후 최종 보안 보고서를 작성할 때 따르는 패턴이다.
+
+보안 보고서의 핵심 목적은 PM이 "이 코드를 프로덕션에 배포해도 되는가?"를 판단할 수 있게 하는 것이다. 기술적 세부 사항을 나열하는 것이 아니라, 심각도별로 정리된 취약점 목록과 명확한 배포 권고를 제공한다.
+
+보고서는 `context/security_report.md`에 저장한다.
+
+---
+
+## 보고서 구조
+
+아래 6개 섹션을 순서대로 작성한다.
+
+### Section 1: 검토 범위
+
+검토 대상과 기준을 명시한다. PM이 "무엇을 검토했는지"를 한눈에 파악할 수 있어야 한다.
+
+```markdown
+## 1. 검토 범위
+
+| 항목 | 내용 |
+|------|------|
+| 검토 대상 | FE (Next.js) + BE (Express) + Infra (Docker, CI/CD) |
+| 검토 기준 | OWASP Top 10 (2021) |
+| 검토 일시 | 2026-03-23 |
+| 검토 방법 | 정적 분석 (패턴 기반 코드 탐색) |
+| 검토 범위 외 | 의존성 취약점 (npm audit 별도), 인프라 네트워크 보안 |
+```
+
+### Section 2: 결과 요약
+
+심각도별 발견/수정/미해결 건수를 한 테이블로 보여준다. PM이 이 테이블만 보고도 전체 상황을 파악할 수 있어야 한다.
+
+```markdown
+## 2. 결과 요약
+
+| 심각도 | 발견 | 수정완료 | 미해결 |
+|--------|------|---------|--------|
+| Critical | 1 | 1 | 0 |
+| High | 2 | 2 | 0 |
+| Medium | 3 | 2 | 1 |
+| Low | 2 | 0 | 2 |
+| **합계** | **8** | **5** | **3** |
+```
+
+### Section 3: 취약점 상세
+
+발견된 모든 취약점을 테이블로 나열한다. 심각도 높은 것부터 정렬한다.
+
+```markdown
+## 3. 취약점 상세
+
+| ID | 심각도 | 제목 | 대상 파일 | OWASP | 상태 |
+|----|--------|------|----------|-------|------|
+| SEC-001 | Critical | DB 비밀번호 하드코딩 | src/config/db.ts:15 | A07 | 수정완료 |
+| SEC-002 | High | 관리자 API 인증 미들웨어 누락 | src/routes/admin.ts:42 | A01 | 수정완료 |
+| SEC-003 | High | 사용자 응답에 password 필드 포함 | src/controllers/users.ts:28 | A01 | 수정완료 |
+| SEC-004 | Medium | dangerouslySetInnerHTML 사용 | src/components/Comment.tsx:35 | A03 | 미해결 |
+| SEC-005 | Medium | 와일드카드 CORS 설정 | src/app.ts:12 | A05 | 수정완료 |
+| SEC-006 | Medium | process.env 직접 참조 | src/services/email.ts:8 | A05 | 수정완료 |
+| SEC-007 | Low | HTTP URL 사용 | src/utils/api.ts:22 | A02 | 미해결 |
+| SEC-008 | Low | console.log에 요청 데이터 출력 | src/middleware/logger.ts:15 | A09 | 미해결 |
+```
+
+각 취약점에 대해 필요하면 상세 설명을 추가한다:
+
+```markdown
+### SEC-004: dangerouslySetInnerHTML 사용 (Medium)
+- **위치:** src/components/Comment.tsx:35
+- **설명:** 사용자 입력 댓글을 dangerouslySetInnerHTML로 렌더링. sanitize 처리 없이 사용하면 XSS 공격 가능.
+- **권장 조치:** DOMPurify 등으로 sanitize 처리 추가, 또는 마크다운 라이브러리로 교체
+- **현재 상태:** 미해결 — BE에서 sanitize 후 저장하는 방식으로 변경 예정
+```
+
+### Section 4: OWASP Top 10 체크 결과
+
+OWASP Top 10 각 항목에 대해 검토 결과를 표시한다. "검토하지 않았다"와 "문제 없었다"를 구분하는 것이 중요하다.
+
+```markdown
+## 4. OWASP Top 10 체크 결과
+
+| # | OWASP 항목 | 결과 | 비고 |
+|---|-----------|------|------|
+| A01 | Broken Access Control | ⚠️ 발견 (수정완료) | SEC-002, SEC-003 |
+| A02 | Cryptographic Failures | ⚠️ 발견 (미해결) | SEC-007 |
+| A03 | Injection | ⚠️ 발견 (미해결) | SEC-004 |
+| A04 | Insecure Design | ✅ 문제 없음 | |
+| A05 | Security Misconfiguration | ⚠️ 발견 (수정완료) | SEC-005, SEC-006 |
+| A06 | Vulnerable Components | ➖ 검토 범위 외 | npm audit 별도 실행 필요 |
+| A07 | Identification Failures | ⚠️ 발견 (수정완료) | SEC-001 |
+| A08 | Software/Data Integrity | ✅ 문제 없음 | |
+| A09 | Logging Failures | ⚠️ 발견 (미해결) | SEC-008 |
+| A10 | SSRF | ✅ 문제 없음 | |
+```
+
+범례:
+- ✅ 문제 없음 — 검토했고 위험 패턴 미발견
+- ⚠️ 발견 — 취약점 발견됨 (수정완료/미해결 구분)
+- ➖ 검토 범위 외 — 이번 검토에서 다루지 않음
+
+### Section 5: 미해결 취약점
+
+미해결 항목이 있으면 별도로 모아서 PM이 즉시 판단할 수 있게 한다.
+
+```markdown
+## 5. 미해결 취약점
+
+| ID | 심각도 | 제목 | 미해결 사유 | 위험 평가 |
+|----|--------|------|-----------|----------|
+| SEC-004 | Medium | dangerouslySetInnerHTML | BE 수정 후 적용 예정 | 현재 관리자만 댓글 작성 가능 — 즉시 위험 낮음 |
+| SEC-007 | Low | HTTP URL 사용 | 개발 환경 전용 | 프로덕션에서는 HTTPS 강제 — 실제 위험 없음 |
+| SEC-008 | Low | console.log 데이터 출력 | 다음 스프린트에서 로거 교체 예정 | 민감 데이터 포함 여부 확인 필요 |
+```
+
+미해결 항목이 없으면:
+
+```markdown
+## 5. 미해결 취약점
+
+미해결 취약점 없음.
+```
+
+### Section 6: 배포 권고
+
+PM이 배포 결정을 내릴 수 있도록 명확한 권고를 제공한다.
+
+```markdown
+## 6. 배포 권고
+
+### 판단: ✅ 배포 가능
+
+**근거:**
+- Critical 미해결: 0건
+- High 미해결: 0건
+- Medium 미해결: 1건 (SEC-004 — 현재 위험 낮음, 다음 스프린트에서 해결 예정)
+- Low 미해결: 2건 (운영 영향 없음)
+
+**조건:**
+- SEC-004는 다음 스프린트에서 반드시 수정할 것
+- 프로덕션 배포 전 `npm audit` 실행하여 의존성 취약점 확인할 것
+```
+
+---
+
+## 배포 권고 판단 기준
+
+| 조건 | 판단 |
+|------|------|
+| Critical 미해결 ≥ 1 | ❌ 배포 불가 |
+| High 미해결 ≥ 1 | ❌ 배포 불가 |
+| Medium 미해결만 있음 | ⚠️ PM이 판단 (위험 평가 포함) |
+| Low 미해결만 있음 | ✅ 배포 가능 (조건부) |
+| 미해결 없음 | ✅ 배포 가능 |
+
+배포 불가 판단 시:
+
+```markdown
+### 판단: ❌ 배포 불가
+
+**근거:**
+- Critical 미해결: 1건 (SEC-001 — DB 비밀번호 하드코딩)
+- 해당 취약점이 수정되기 전까지 배포를 진행하면 안 됩니다.
+
+**필요 조치:**
+1. SEC-001 수정 → BE Agent에게 전달 완료
+2. 수정 후 재검토 필요
+```
+
+---
+
+## 보고서 작성 체크리스트
+
+1. [ ] **검토 범위** — 대상, 기준, 방법, 범위 외 항목이 명시됐는가
+2. [ ] **결과 요약** — 심각도별 발견/수정/미해결 수가 정확한가
+3. [ ] **취약점 상세** — 모든 발견 항목에 ID, 심각도, 파일:라인, OWASP 분류가 있는가
+4. [ ] **OWASP 체크** — 10개 항목 전체가 체크됐는가 (검토 범위 외도 표시)
+5. [ ] **미해결 취약점** — 미해결 사유와 위험 평가가 있는가
+6. [ ] **배포 권고** — 가능/불가 판단과 근거가 명확한가
+7. [ ] **저장 위치** — `context/security_report.md`에 저장했는가

package/template/.claude/skills/write-test-cases/SKILL.md

@@ -0,0 +1,234 @@
+---
+name: write-test-cases
+description: "QA 엔지니어가 기획안을 기반으로 테스트 케이스를 작성할 때 참조하는 skill. 기능 테스트, 엣지케이스, E2E, API 검증으로 분류해서 작성하며 누락 없이 기획안을 커버한다. QA Agent가 04_task_QA.md를 받고 검증을 시작할 때, 테스트 케이스를 처음 작성할 때, 또는 기획안이 수정되어 TC를 업데이트해야 할 때 반드시 사용한다. '테스트 케이스 작성', 'TC 작성', 'QA 시작', '검증 준비', '테스트 시나리오 만들기' 등의 상황에서 트리거된다."
+---
+
+# Write Test Cases
+
+QA 엔지니어가 기획안(01_plan.md)을 기반으로 테스트 케이스를 작성할 때 따르는 패턴이다.
+
+테스트 케이스가 기획안을 빠짐없이 커버하지 않으면 검증에 구멍이 생긴다. 기획안에 "비밀번호 찾기" 기능이 있는데 TC가 없으면 해당 기능은 아무도 검증하지 않은 채 배포된다. 이 skill은 기획안의 각 섹션에서 TC를 체계적으로 도출하고, 마지막에 누락 여부를 대조 검증하는 절차를 제공한다.
+
+---
+
+## TC 도출 원칙: 기획안 Section → TC 분류
+
+기획안(01_plan.md)의 각 섹션이 특정 유형의 TC로 매핑된다. 이 매핑을 따르면 기획안의 모든 내용이 자연스럽게 TC로 변환된다.
+
+| 기획안 섹션 | TC 분류 | 도출 방법 |
+|------------|---------|----------|
+| Section 2 (유저 스토리) | E2E 시나리오 | 각 유저 스토리를 처음부터 끝까지 흐름으로 변환 |
+| Section 3 (기능 명세) | 기능 테스트 | 각 기능의 정상 동작을 개별 TC로 작성 |
+| Section 5 (API 목록) | API 검증 | 각 API의 요청/응답을 검증하는 TC 작성 |
+| Section 6 (엣지케이스) | 엣지케이스 테스트 | 기획안에 명시된 예외 상황을 TC로 작성 |
+
+---
+
+## TC 작성 형식
+
+모든 TC는 아래 형식으로 작성한다. "기준" 필드가 핵심이다 — 기준이 없는 TC는 검증 기준이 모호해서 통과/실패를 판단할 수 없다.
+
+```
+TC-001
+분류: 기능 / 엣지케이스 / E2E / API / 보안
+제목: 로그인 성공 시 대시보드로 이동
+전제 조건: 유효한 계정(test@example.com / password123)이 존재함
+테스트 순서:
+  1. 로그인 페이지 접속
+  2. 이메일: test@example.com 입력
+  3. 비밀번호: password123 입력
+  4. 로그인 버튼 클릭
+기대 결과: 대시보드 페이지(/dashboard)로 이동, 헤더에 사용자 이름 표시
+기준: 01_plan.md Section 3.1 - 로그인 기능
+```
+
+### 번호 규칙
+
+| 분류 | 번호 범위 | 예시 |
+|------|----------|------|
+| 기능 테스트 | TC-001 ~ TC-099 | TC-001, TC-002 |
+| 엣지케이스 | TC-100 ~ TC-199 | TC-100, TC-101 |
+| E2E 시나리오 | TC-200 ~ TC-299 | TC-200, TC-201 |
+| API 검증 | TC-300 ~ TC-399 | TC-300, TC-301 |
+| 보안 | TC-400 ~ TC-499 | TC-400, TC-401 |
+
+---
+
+## STEP 1: 기능 테스트 TC 도출 (Section 3 → TC-0XX)
+
+기획안 Section 3의 각 기능마다 최소 2개 TC를 작성한다:
+- **정상 동작** TC: 올바른 입력으로 기대 결과 확인
+- **실패 동작** TC: 잘못된 입력이나 조건 불충족 시 에러 처리 확인
+
+**예시 — "게시글 작성" 기능:**
+
+```
+TC-010
+분류: 기능
+제목: 게시글 작성 성공
+전제 조건: 로그인 상태
+테스트 순서:
+  1. 글쓰기 페이지 접속
+  2. 제목 입력: "테스트 게시글"
+  3. 본문 입력: "본문 내용입니다."
+  4. 작성 버튼 클릭
+기대 결과: 게시글 상세 페이지로 이동, 작성한 제목/본문 표시
+기준: 01_plan.md Section 3.4 - 게시글 작성
+
+TC-011
+분류: 기능
+제목: 비로그인 상태에서 게시글 작성 시도
+전제 조건: 로그아웃 상태
+테스트 순서:
+  1. 글쓰기 URL 직접 접속
+기대 결과: 로그인 페이지로 리다이렉트
+기준: 01_plan.md Section 3.4 - 게시글 작성 (인증 필요)
+```
+
+---
+
+## STEP 2: 엣지케이스 TC 도출 (Section 6 → TC-1XX)
+
+기획안 Section 6에 명시된 엣지케이스를 TC로 변환한다. 추가로, 기획안에 명시되지 않았더라도 아래 항목은 반드시 포함한다 — 이런 케이스에서 버그가 가장 자주 발생하기 때문이다.
+
+### 반드시 포함해야 할 엣지케이스
+
+| 카테고리 | TC 내용 | 왜 필요한가 |
+|---------|---------|-----------|
+| 빈 값 입력 | 모든 입력 폼에 빈 값으로 제출 | 서버 에러 방지, 유효성 검사 확인 |
+| 최대 길이 초과 | 제목 100자+, 본문 10000자+ | DB 에러, 화면 깨짐 방지 |
+| 특수문자/이모지 | `<script>alert(1)</script>`, 이모지 | XSS 방지, 인코딩 확인 |
+| 중복 데이터 | 동일 이메일 회원가입, 동일 제목 게시글 | 유니크 제약조건 확인 |
+| 인증 없이 접근 | 인증 필요한 모든 API/화면에 토큰 없이 접근 | 보안 확인 |
+| 권한 없는 접근 | 다른 사용자의 데이터 수정/삭제 시도 | 인가 확인 |
+| 동시 요청 | 같은 데이터에 동시에 수정 요청 | 데이터 무결성 확인 |
+
+**예시:**
+
+```
+TC-100
+분류: 엣지케이스
+제목: 게시글 제목 빈 값 제출
+전제 조건: 로그인 상태, 글쓰기 페이지
+테스트 순서:
+  1. 제목 비워둠
+  2. 본문 입력: "본문"
+  3. 작성 버튼 클릭
+기대 결과: "제목을 입력해주세요" 에러 메시지 표시, 게시글 미생성
+기준: 01_plan.md Section 6 - 입력값 검증
+```
+
+---
+
+## STEP 3: E2E 시나리오 TC 도출 (Section 2 → TC-2XX)
+
+기획안 Section 2의 유저 스토리를 처음부터 끝까지 이어지는 시나리오로 변환한다. E2E는 개별 기능이 아니라 "사용자가 실제로 하는 일련의 행동"을 검증하는 것이 목적이다.
+
+각 단계에서 확인할 것:
+- 화면 전환이 올바른가
+- 이전 단계의 데이터가 다음 단계에 반영되는가
+- 중간에 실패하면 적절한 복구가 되는가
+
+**예시:**
+
+```
+TC-200
+분류: E2E
+제목: 신규 사용자 회원가입 → 로그인 → 게시글 작성 → 확인
+전제 조건: 없음 (완전히 새로운 사용자)
+테스트 순서:
+  1. 회원가입 페이지 접속
+  2. 이메일/비밀번호/이름 입력 후 가입
+  3. 가입 성공 메시지 확인
+  4. 로그인 페이지에서 방금 가입한 계정으로 로그인
+  5. 대시보드 접근 확인
+  6. 게시글 작성 페이지 이동
+  7. 제목/본문 입력 후 작성
+  8. 게시글 목록에서 방금 작성한 글 확인
+기대 결과: 모든 단계 정상 완료, 게시글 목록에 새 글 표시
+기준: 01_plan.md Section 2.1 - 신규 사용자 시나리오
+```
+
+---
+
+## STEP 4: API 검증 TC 도출 (Section 5 → TC-3XX)
+
+기획안 Section 5의 API 목록과 API 명세(03_api_spec.md)를 기준으로 각 API마다 최소 3개 TC를 작성한다:
+
+| TC 유형 | 확인 내용 |
+|---------|----------|
+| 정상 요청 | 올바른 입력 → 기대 응답 형식, 상태 코드 |
+| 인증 없이 요청 | 토큰 없이 → 401 반환 |
+| 잘못된 입력 | 필수 필드 누락/형식 오류 → 400 또는 422 반환 |
+
+**예시:**
+
+```
+TC-300
+분류: API
+제목: POST /api/posts - 게시글 생성 정상 요청
+전제 조건: 유효한 JWT 토큰
+테스트 순서:
+  1. POST /api/posts 요청
+     Header: Authorization: Bearer {token}
+     Body: { "title": "테스트", "content": "본문" }
+기대 결과:
+  - 상태 코드: 201
+  - 응답: { "success": true, "data": { "id": "...", "title": "테스트", ... } }
+기준: 03_api_spec.md - POST /api/posts
+
+TC-301
+분류: API
+제목: POST /api/posts - 인증 없이 요청
+전제 조건: 토큰 없음
+테스트 순서:
+  1. POST /api/posts 요청 (Authorization 헤더 없음)
+     Body: { "title": "테스트", "content": "본문" }
+기대 결과:
+  - 상태 코드: 401
+  - 응답: { "success": false, "error": { "code": "UNAUTHORIZED" } }
+기준: 03_api_spec.md - 인증 정책
+```
+
+---
+
+## STEP 5: 누락 검증 (Coverage Check)
+
+모든 TC를 작성한 후, 기획안의 기능 목록과 대조하여 빠진 것이 없는지 확인한다. 이 단계를 건너뛰면 "TC를 열심히 작성했지만 핵심 기능이 빠졌다"는 상황이 발생한다.
+
+### 대조 방법
+
+1. 기획안 Section 3의 기능 목록을 뽑는다
+2. 각 기능에 대응하는 TC가 있는지 체크한다
+3. 누락된 기능이 있으면 TC를 추가한다
+
+### 출력 형식
+
+```markdown
+## 커버리지 매트릭스
+
+| 기획안 기능 | 기능 TC | 엣지 TC | E2E TC | API TC | 커버 여부 |
+|------------|---------|---------|--------|--------|----------|
+| 회원가입 | TC-001 | TC-100,101 | TC-200 | TC-300,301 | ✅ |
+| 로그인 | TC-002 | TC-102,103 | TC-200 | TC-302,303 | ✅ |
+| 게시글 작성 | TC-010 | TC-110,111 | TC-200 | TC-310,311 | ✅ |
+| 게시글 수정 | - | - | - | - | ❌ 누락 |
+| 비밀번호 찾기 | TC-020 | TC-120 | - | TC-320 | ✅ |
+
+### 누락 항목
+- 게시글 수정: TC 추가 필요 (기능 + 엣지케이스 + API)
+```
+
+누락 항목이 있으면 TC를 추가한 뒤 다시 매트릭스를 갱신한다. 모든 기능이 ✅가 될 때까지 반복한다.
+
+---
+
+## TC 작성 체크리스트
+
+1. [ ] **기능 테스트** — Section 3의 모든 기능에 정상/실패 TC가 있는가
+2. [ ] **엣지케이스** — Section 6의 모든 항목이 TC로 변환됐는가
+3. [ ] **필수 엣지케이스** — 빈 값, 인증 없음, 권한 없음, 중복 데이터 TC가 있는가
+4. [ ] **E2E 시나리오** — Section 2의 모든 유저 스토리가 시나리오로 변환됐는가
+5. [ ] **API 검증** — Section 5의 모든 API에 정상/인증/입력오류 TC가 있는가
+6. [ ] **커버리지 매트릭스** — 모든 기능이 ✅인가
+7. [ ] **기준 명시** — 모든 TC에 기획안 기준 섹션이 명시됐는가

package/template/.claude-pipeline/dashboard/.env.example

@@ -0,0 +1 @@
+PIPELINES_DIR=../pipelines

package/template/.claude-pipeline/dashboard/.eslintrc.json

@@ -0,0 +1,3 @@
+{
+  "extends": ["next/core-web-vitals", "next/typescript"]
+}

package/template/.claude-pipeline/dashboard/README.md

@@ -0,0 +1,36 @@
+This is a [Next.js](https://nextjs.org) project bootstrapped with [`create-next-app`](https://nextjs.org/docs/app/api-reference/cli/create-next-app).
+
+## Getting Started
+
+First, run the development server:
+
+```bash
+npm run dev
+# or
+yarn dev
+# or
+pnpm dev
+# or
+bun dev
+```
+
+Open [http://localhost:3000](http://localhost:3000) with your browser to see the result.
+
+You can start editing the page by modifying `app/page.tsx`. The page auto-updates as you edit the file.
+
+This project uses [`next/font`](https://nextjs.org/docs/app/building-your-application/optimizing/fonts) to automatically optimize and load [Geist](https://vercel.com/font), a new font family for Vercel.
+
+## Learn More
+
+To learn more about Next.js, take a look at the following resources:
+
+- [Next.js Documentation](https://nextjs.org/docs) - learn about Next.js features and API.
+- [Learn Next.js](https://nextjs.org/learn) - an interactive Next.js tutorial.
+
+You can check out [the Next.js GitHub repository](https://github.com/vercel/next.js) - your feedback and contributions are welcome!
+
+## Deploy on Vercel
+
+The easiest way to deploy your Next.js app is to use the [Vercel Platform](https://vercel.com/new?utm_medium=default-template&filter=next.js&utm_source=create-next-app&utm_campaign=create-next-app-readme) from the creators of Next.js.
+
+Check out our [Next.js deployment documentation](https://nextjs.org/docs/app/building-your-application/deploying) for more details.

package/template/.claude-pipeline/dashboard/next.config.mjs

@@ -0,0 +1,6 @@
+/** @type {import('next').NextConfig} */
+const nextConfig = {
+  transpilePackages: ["react-markdown", "react-syntax-highlighter"],
+};
+
+export default nextConfig;