From 5b84d0f30a2a101773ead3f6d8527cb1b39f7d4f Mon Sep 17 00:00:00 2001 From: hyeonggil <> Date: Tue, 24 Mar 2026 22:26:10 +0900 Subject: [PATCH] =?UTF-8?q?=F0=9F=8F=97=EF=B8=8F=20chore:=20TaskMaster=20A?= =?UTF-8?q?I=20=EC=9E=91=EC=97=85=20=EA=B4=80=EB=A6=AC=20=EB=8F=84?= =?UTF-8?q?=EA=B5=AC=20=EC=B4=88=EA=B8=B0=20=EC=84=A4=EC=A0=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - TaskMaster 설정 파일 (config.json, state.json) - 작업 문서 및 템플릿 추가 - PRD 문서 디렉토리 구성 --- .taskmaster/config.json | 44 ++ .taskmaster/docs/prd.txt | 124 ++++++ .taskmaster/state.json | 6 + .taskmaster/tasks/tasks.json | 258 +++++++++++ .taskmaster/templates/example_prd.txt | 47 ++ .taskmaster/templates/example_prd_rpg.txt | 511 ++++++++++++++++++++++ 6 files changed, 990 insertions(+) create mode 100644 .taskmaster/config.json create mode 100644 .taskmaster/docs/prd.txt create mode 100644 .taskmaster/state.json create mode 100644 .taskmaster/tasks/tasks.json create mode 100644 .taskmaster/templates/example_prd.txt create mode 100644 .taskmaster/templates/example_prd_rpg.txt diff --git a/.taskmaster/config.json b/.taskmaster/config.json new file mode 100644 index 0000000..75c8952 --- /dev/null +++ b/.taskmaster/config.json @@ -0,0 +1,44 @@ +{ + "models": { + "main": { + "provider": "anthropic", + "modelId": "claude-sonnet-4-20250514", + "maxTokens": 64000, + "temperature": 0.2 + }, + "research": { + "provider": "perplexity", + "modelId": "sonar", + "maxTokens": 8700, + "temperature": 0.1 + }, + "fallback": { + "provider": "anthropic", + "modelId": "claude-3-7-sonnet-20250219", + "maxTokens": 120000, + "temperature": 0.2 + } + }, + "global": { + "logLevel": "info", + "debug": false, + "defaultNumTasks": 10, + "defaultSubtasks": 5, + "defaultPriority": "medium", + "projectName": "Task Master", + "ollamaBaseURL": "http://localhost:11434/api", + "bedrockBaseURL": "https://bedrock.us-east-1.amazonaws.com", + "responseLanguage": "English", + "enableCodebaseAnalysis": true, + "enableProxy": false, + "anonymousTelemetry": true, + "userId": "1234567890" + }, + "claudeCode": {}, + "codexCli": {}, + "grokCli": { + "timeout": 120000, + "workingDirectory": null, + "defaultModel": "grok-4-latest" + } +} \ No newline at end of file diff --git a/.taskmaster/docs/prd.txt b/.taskmaster/docs/prd.txt new file mode 100644 index 0000000..1f06023 --- /dev/null +++ b/.taskmaster/docs/prd.txt @@ -0,0 +1,124 @@ +# FE AI 표준화 방안 PRD + +## 프로젝트 개요 +프론트엔드(FE) 개발 전 주기에 AI를 활용한 표준화 방안을 수립하고 각 단계별 가이드라인과 실행 방안을 문서화한다. +대상 스택: Nuxt 4, TypeScript (strict), Tailwind CSS v4, shadcn-vue, Pinia + +--- + +## STEP 01 · 기획 (Planning) + +### 1-1. 스펙 검토 표준화 +- 플로우차트 기준으로 스펙 문서를 AI가 검토하는 프로세스 정의 +- 기능 요건 정의 템플릿 작성 +- AI 프롬프트 템플릿: 스펙 → 플로우차트 자동 생성 + +### 1-2. SEO 정보 표준화 및 검증 +- Nuxt 4 useSeoMeta / useHead 기반 SEO 메타 표준 정의 +- AI 기반 SEO 검증 도구 선정 (Lighthouse, 커스텀 스크립트 등) +- SEO 검증 프로세스 표준화 문서 작성 + +### 1-3. 번역코드 생성 표준화 (i18n) +- i18n 키 네이밍 컨벤션 정의 (예: `page.section.element`) +- AI를 활용한 i18n 키 자동 생성 프롬프트/스크립트 작성 +- 번역 파일 구조 표준화 (locale JSON 구조) + +--- + +## STEP 02 · 디자인 (Design) + +### 2-1. Figma 네이밍 규칙 +- Figma 컴포넌트 명명 규칙 가이드 작성 (PascalCase, BEM 등) +- AI 기반 Figma 네이밍 검수 프로세스 정의 +- Vue 컴포넌트명과 Figma 컴포넌트명 매핑 규칙 수립 + +### 2-2. EDM 마크업 표준화 +- 이메일 템플릿 규격 정의 (width, font, 지원 클라이언트 목록) +- 이메일 HTML 마크업 표준화 가이드 작성 (table 레이아웃, inline style) +- 이메일 검증 도구 선정 (Litmus, Email on Acid 등) +- AI 기반 이메일 검증 프로세스 표준화 + +### 2-3. 프로모션 마크업 표준화 +- 프로모션 페이지 필요 정보 입력 방식 정의 + - 이미지 URL, 프로모션 기간, 유의사항, 아이템 코드 +- AI 기반 프로모션 마크업 자동 생성 프롬프트 작성 +- 프로모션 컴포넌트 템플릿 표준화 + +--- + +## STEP 03 · 구현 (Implementation) + +### 3-1. AI 코딩 도구 표준화 +- Claude / Cursor 사용 가이드 작성 +- 팀 내 AI 코딩 도구 선정 및 라이선스 정책 수립 (Claude, Cursor 기준) +- 코드 자동 완성 활용 패턴 및 주의사항 문서화 + +### 3-2. 개발 컨벤션 표준화 +- i18n 사용 컨벤션 (useI18n, $t 사용 기준) +- 미들웨어 작성 컨벤션 (인증, 권한, 리다이렉트) +- 언어 정책 컨벤션 (다국어 라우팅, locale 전환) +- 점검 페이지 컨벤션 +- 인트로/스플래시 페이지 컨벤션 +- 에러 페이지 컨벤션 (404, 500, error.vue) + +### 3-3. 코드 리팩토링 표준화 +- AI 기반 리팩토링 제안 프로세스 정의 +- 리팩토링 체크리스트 작성 (컴포넌트 분리, 재사용성, 타입 안전성) +- 코드 품질 지표 정의 및 AI 분석 방법 + +### 3-4. 코드 리뷰 자동화 +- AI 코드 리뷰 도구 선정 및 설정 (GitHub Copilot PR Review 등) +- MR/PR 자동 요약 프롬프트/봇 설정 +- Git Conflict 처리 AI 보조 프로세스 정의 + +### 3-5. 파일 수정 표준화 (커밋 · 테스트) +- 커밋 메시지 표준 정의 (feat/fix/refactor/style/docs/test/chore) +- 단위 테스트 작성 표준 (Vitest + @nuxt/test-utils) +- AI 기반 테스트 코드 자동 생성 프롬프트/스크립트 + +### 3-6. CI 파이프라인 표준화 +- CI 파이프라인 스크립트 생성 가이드 (GitLab CI 기준) +- AI 기반 빌드 오류 분석 프로세스 +- CI 최적화 제안 체크리스트 + +### 3-7. 기술 문서 자동화 +- 기능별 플로우 다이어그램/ERD AI 작성 가이드 +- README 자동 생성 프롬프트 템플릿 +- 코드 주석 자동 생성 표준 (JSDoc / TSDoc) + +### 3-8. 보안 검수 표준화 +- AI 기반 취약점 자동 탐지 도구 선정 (Snyk, ESLint security plugin 등) +- 보안 패턴 검사 체크리스트 작성 +- 보안 검수 CI 단계 통합 방안 + +--- + +## STEP 04 · 검증 (Verification) + +### 4-1. 테스트 케이스 설계 +- AI 기반 테스트 케이스 자동 생성 프로세스 정의 +- 엣지 케이스 도출 방법론 및 프롬프트 작성 +- 테스트 케이스 템플릿 표준화 + +### 4-2. 기능·통합 테스트 자동화 +- E2E 테스트 자동화 스크립트 작성 (Playwright 등) +- AI 기반 이슈 자동 탐지 프로세스 +- 테스트 결과 리포트 표준화 + +### 4-3. 성능·보안 검토 +- 성능 취약점 자동 탐지 (Lighthouse CI, Web Vitals 기준) +- 병목 지점 AI 분석 방법론 +- 성능·보안 검토 체크리스트 작성 + +### 4-4. 버그 리포트·수정 자동화 +- AI 기반 버그 원인 분석 프로세스 +- 버그 수정 제안 프롬프트 템플릿 +- 자동 버그 리포팅 시스템 설계 + +--- + +## 공통 산출물 +- 각 단계별 AI 프롬프트 템플릿 모음 +- 표준화 가이드 문서 (Markdown) +- CI/CD 통합 스크립트 +- 팀 온보딩 자료 diff --git a/.taskmaster/state.json b/.taskmaster/state.json new file mode 100644 index 0000000..76b40c5 --- /dev/null +++ b/.taskmaster/state.json @@ -0,0 +1,6 @@ +{ + "currentTag": "master", + "lastSwitched": "2026-03-24T12:55:59.367Z", + "branchTagMapping": {}, + "migrationNoticeShown": false +} \ No newline at end of file diff --git a/.taskmaster/tasks/tasks.json b/.taskmaster/tasks/tasks.json new file mode 100644 index 0000000..a5da416 --- /dev/null +++ b/.taskmaster/tasks/tasks.json @@ -0,0 +1,258 @@ +{ + "master": { + "tasks": [ + { + "id": "1", + "title": "프로젝트 기본 구조 및 환경 설정", + "description": "Nuxt 4, TypeScript (strict), Tailwind CSS v4, shadcn-vue, Pinia 기반 프로젝트 초기 설정 및 기본 구조 구축", + "details": "1. Nuxt 4 프로젝트 초기화: `npx nuxi@latest init project-name`\n2. TypeScript strict 모드 설정: nuxt.config.ts에서 typescript: { strict: true }\n3. Tailwind CSS v4 설치 및 설정: npm install tailwindcss@next @tailwindcss/postcss@next\n4. shadcn-vue 설치: npx shadcn-vue@latest init\n5. Pinia 설치 및 설정: npm install pinia @pinia/nuxt\n6. 기본 폴더 구조 생성: components/, composables/, stores/, middleware/, plugins/, utils/\n7. 환경변수 파일 설정: .env.example, .env.local", + "testStrategy": "프로젝트 빌드 성공 확인, TypeScript 컴파일 오류 없음, 각 라이브러리 정상 동작 확인, 개발 서버 실행 테스트", + "priority": "high", + "dependencies": [], + "status": "cancelled", + "subtasks": [], + "updatedAt": "2026-03-24T13:16:43.852Z" + }, + { + "id": "2", + "title": "스펙 검토 표준화 프로세스 구축", + "description": "AI를 활용한 스펙 문서 검토 및 플로우차트 자동 생성 프로세스 정의", + "details": "1. 기능 요건 정의 템플릿 작성 (Markdown 형식)\n2. AI 프롬프트 템플릿 작성:\n - 스펙 문서 → 플로우차트 변환 프롬프트\n - Mermaid 다이어그램 생성 프롬프트\n3. 스펙 검토 체크리스트 작성\n4. 플로우차트 검증 기준 정의\n5. 문서화 도구 선정 (VitePress 또는 Nuxt Content)\n6. 스펙 검토 워크플로우 문서 작성", + "testStrategy": "샘플 스펙 문서로 플로우차트 생성 테스트, AI 프롬프트 정확도 검증, 생성된 플로우차트 품질 평가", + "priority": "high", + "dependencies": [ + "1" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "3", + "title": "SEO 메타데이터 표준화 및 검증 시스템", + "description": "Nuxt 4 useSeoMeta/useHead 기반 SEO 표준 정의 및 AI 검증 도구 구축", + "details": "1. SEO 메타데이터 표준 스키마 정의:\n - useSeoMeta() 표준 템플릿\n - useHead() 사용 가이드라인\n2. SEO 검증 컴포저블 작성: composables/useSeoValidation.ts\n3. Lighthouse CI 설정 및 통합\n4. AI 기반 SEO 점수 분석 프롬프트 작성\n5. SEO 체크리스트 자동화 스크립트\n6. 메타데이터 자동 생성 유틸리티 함수\n7. Open Graph, Twitter Card 표준 템플릿", + "testStrategy": "Lighthouse 점수 90+ 달성 확인, 메타데이터 누락 검증, 소셜 미디어 미리보기 테스트, SEO 검증 자동화 테스트", + "priority": "high", + "dependencies": [ + "1" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "4", + "title": "i18n 다국어 표준화 시스템", + "description": "i18n 키 네이밍 컨벤션 및 AI 기반 번역 키 자동 생성 시스템 구축", + "details": "1. @nuxtjs/i18n 모듈 설치 및 설정\n2. i18n 키 네이밍 컨벤션 정의: page.section.element 형식\n3. 번역 파일 구조 표준화:\n - locales/ko.json, locales/en.json\n - 중첩 객체 구조 정의\n4. AI 번역 키 자동 생성 스크립트:\n - 컴포넌트 스캔하여 번역 키 추출\n - 누락된 번역 키 자동 감지\n5. 번역 검증 유틸리티 작성\n6. 다국어 라우팅 설정 및 locale 전환 컴포넌트", + "testStrategy": "번역 키 중복 검사, 누락된 번역 키 감지 테스트, 언어 전환 기능 테스트, 번역 파일 구조 검증", + "priority": "medium", + "dependencies": [ + "1" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "5", + "title": "Figma 네이밍 규칙 및 컴포넌트 매핑 시스템", + "description": "Figma 컴포넌트와 Vue 컴포넌트 간 네이밍 규칙 표준화 및 AI 검수 프로세스", + "details": "1. Figma 컴포넌트 네이밍 컨벤션 가이드 작성:\n - PascalCase 기본 원칙\n - BEM 방법론 적용 가이드\n2. Vue 컴포넌트명 매핑 규칙 정의\n3. Figma API 연동 스크립트 작성\n4. AI 기반 네이밍 검수 프롬프트:\n - 일관성 검사\n - 네이밍 개선 제안\n5. 컴포넌트 매핑 테이블 자동 생성\n6. Figma 토큰 추출 및 Tailwind 변수 매핑", + "testStrategy": "Figma API 연동 테스트, 네이밍 규칙 준수 검증, 컴포넌트 매핑 정확도 확인, AI 검수 결과 품질 평가", + "priority": "medium", + "dependencies": [ + "1" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "6", + "title": "EDM 이메일 템플릿 표준화 시스템", + "description": "이메일 마크업 표준 정의 및 AI 기반 검증 프로세스 구축", + "details": "1. 이메일 템플릿 규격 정의:\n - 최대 width: 600px\n - 지원 클라이언트 목록 (Outlook, Gmail, Apple Mail)\n - 폰트 스택 표준화\n2. HTML 마크업 표준 가이드:\n - Table 기반 레이아웃\n - Inline CSS 스타일링\n - 이미지 최적화 가이드\n3. 이메일 템플릿 컴포넌트 작성\n4. AI 기반 이메일 검증 프롬프트\n5. 이메일 테스트 도구 통합 (Litmus API)\n6. 반응형 이메일 가이드라인", + "testStrategy": "주요 이메일 클라이언트 렌더링 테스트, HTML 유효성 검사, 이미지 로딩 테스트, 스팸 필터 통과 테스트", + "priority": "medium", + "dependencies": [ + "1" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "7", + "title": "프로모션 페이지 자동 생성 시스템", + "description": "프로모션 마크업 표준화 및 AI 기반 자동 생성 프로세스", + "details": "1. 프로모션 데이터 스키마 정의:\n - 이미지 URL, 프로모션 기간, 유의사항, 아이템 코드\n2. 프로모션 컴포넌트 템플릿 작성:\n - BasePromotion.vue\n - PromotionBanner.vue\n - PromotionModal.vue\n3. AI 마크업 자동 생성 프롬프트\n4. 프로모션 관리 인터페이스 (CMS 형태)\n5. 프로모션 유효성 검증 로직\n6. A/B 테스트 지원 구조", + "testStrategy": "프로모션 데이터 유효성 검사, 자동 생성된 마크업 품질 확인, 반응형 레이아웃 테스트, 성능 최적화 검증", + "priority": "medium", + "dependencies": [ + "1", + "4" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "8", + "title": "AI 코딩 도구 표준화 가이드", + "description": "Claude/Cursor 사용 가이드 및 팀 내 AI 도구 정책 수립", + "details": "1. AI 코딩 도구 비교 분석 문서 작성\n2. Claude 사용 가이드:\n - 효과적인 프롬프트 작성법\n - 코드 리뷰 활용 방법\n3. Cursor 설정 및 사용 가이드:\n - IDE 통합 설정\n - 코드 자동완성 최적화\n4. 라이선스 정책 및 비용 관리\n5. AI 도구 사용 시 주의사항 및 보안 가이드\n6. 팀 내 AI 도구 사용 모범 사례 수집", + "testStrategy": "AI 도구 설정 검증, 프롬프트 효과성 측정, 코드 품질 개선 정도 평가, 보안 정책 준수 확인", + "priority": "medium", + "dependencies": [ + "1" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "9", + "title": "개발 컨벤션 표준화 문서", + "description": "i18n, 미들웨어, 에러 페이지 등 개발 컨벤션 표준 정의", + "details": "1. i18n 사용 컨벤션:\n - useI18n() vs $t() 사용 기준\n - 번역 키 사용 패턴\n2. 미들웨어 작성 컨벤션:\n - 인증 미들웨어: middleware/auth.ts\n - 권한 체크: middleware/role.ts\n - 리다이렉트 로직 표준화\n3. 페이지 컨벤션:\n - 에러 페이지: error.vue, 404.vue\n - 점검 페이지: maintenance.vue\n - 스플래시 페이지: splash.vue\n4. 라우팅 컨벤션 및 다국어 라우팅\n5. 컴포넌트 구조 및 네이밍 가이드", + "testStrategy": "컨벤션 준수 검사 스크립트, 미들웨어 동작 테스트, 에러 페이지 렌더링 확인, 라우팅 테스트", + "priority": "high", + "dependencies": [ + "1", + "4" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "10", + "title": "AI 기반 코드 리팩토링 시스템", + "description": "코드 품질 분석 및 AI 리팩토링 제안 프로세스 구축", + "details": "1. 코드 품질 지표 정의:\n - 복잡도, 중복도, 타입 안전성\n - 컴포넌트 재사용성 점수\n2. AI 리팩토링 분석 프롬프트:\n - 코드 스멜 탐지\n - 성능 개선 제안\n - 타입 안전성 강화\n3. 리팩토링 체크리스트 자동화\n4. ESLint/Prettier 규칙 커스터마이징\n5. 코드 메트릭 수집 및 시각화\n6. 리팩토링 전후 성능 비교 도구", + "testStrategy": "리팩토링 제안 정확도 평가, 코드 품질 개선 정도 측정, 성능 벤치마크 비교, 타입 안전성 검증", + "priority": "medium", + "dependencies": [ + "1", + "9" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "11", + "title": "자동화된 코드 리뷰 시스템", + "description": "AI 기반 코드 리뷰 및 PR/MR 자동 요약 시스템 구축", + "details": "1. GitHub Actions 또는 GitLab CI 코드 리뷰 봇 설정\n2. AI 코드 리뷰 프롬프트:\n - 코드 품질 검사\n - 보안 취약점 탐지\n - 성능 이슈 식별\n3. PR/MR 자동 요약 기능:\n - 변경사항 요약\n - 영향도 분석\n4. Git Conflict 해결 AI 보조 도구\n5. 코드 리뷰 체크리스트 자동화\n6. 리뷰 결과 알림 시스템", + "testStrategy": "코드 리뷰 봇 동작 확인, AI 분석 정확도 검증, PR 요약 품질 평가, Conflict 해결 도구 테스트", + "priority": "medium", + "dependencies": [ + "1", + "10" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "12", + "title": "커밋 및 테스트 표준화 시스템", + "description": "커밋 메시지 표준 및 AI 기반 테스트 코드 자동 생성", + "details": "1. 커밋 메시지 컨벤션 정의:\n - feat/fix/refactor/style/docs/test/chore\n - Conventional Commits 표준 적용\n2. Commitizen 설정 및 커밋 템플릿\n3. Vitest + @nuxt/test-utils 테스트 환경 구축\n4. AI 테스트 코드 생성 프롬프트:\n - 단위 테스트 자동 생성\n - 컴포넌트 테스트 템플릿\n5. 테스트 커버리지 목표 설정 (80% 이상)\n6. 테스트 실행 자동화 스크립트", + "testStrategy": "커밋 메시지 형식 검증, 테스트 코드 품질 확인, 커버리지 목표 달성 검사, 테스트 실행 성공률 모니터링", + "priority": "high", + "dependencies": [ + "1" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "13", + "title": "CI/CD 파이프라인 표준화", + "description": "GitLab CI 기반 빌드 파이프라인 및 AI 오류 분석 시스템", + "details": "1. GitLab CI/CD 파이프라인 템플릿 작성:\n - .gitlab-ci.yml 표준 구조\n - 스테이지별 작업 정의 (build, test, deploy)\n2. Docker 컨테이너 기반 빌드 환경\n3. AI 기반 빌드 오류 분석:\n - 오류 로그 분석 프롬프트\n - 해결 방안 제안 시스템\n4. 성능 최적화 체크리스트:\n - 번들 크기 분석\n - 빌드 시간 최적화\n5. 배포 자동화 스크립트\n6. 롤백 전략 및 Blue-Green 배포", + "testStrategy": "파이프라인 실행 성공률 확인, 빌드 시간 측정, 오류 분석 정확도 검증, 배포 안정성 테스트", + "priority": "high", + "dependencies": [ + "1", + "12" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "14", + "title": "기술 문서 자동화 시스템", + "description": "플로우 다이어그램, README, 코드 주석 자동 생성 시스템", + "details": "1. 플로우 다이어그램 자동 생성:\n - Mermaid 다이어그램 생성 프롬프트\n - ERD 자동 생성 스크립트\n2. README 자동 생성 템플릿:\n - 프로젝트 구조 분석\n - API 문서 자동 추출\n3. JSDoc/TSDoc 표준 정의:\n - 함수/컴포넌트 주석 템플릿\n - AI 기반 주석 자동 생성\n4. API 문서 자동화 (OpenAPI/Swagger)\n5. 컴포넌트 스토리북 자동 생성\n6. 문서 버전 관리 및 배포 자동화", + "testStrategy": "생성된 문서 품질 검증, 다이어그램 정확도 확인, API 문서 동기화 테스트, 주석 완성도 평가", + "priority": "medium", + "dependencies": [ + "1", + "2" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "15", + "title": "보안 검수 자동화 시스템", + "description": "AI 기반 취약점 탐지 및 보안 패턴 검사 시스템", + "details": "1. 보안 도구 통합:\n - Snyk 취약점 스캔\n - ESLint security plugin 설정\n - OWASP ZAP 자동화\n2. AI 기반 보안 분석 프롬프트:\n - XSS, CSRF 취약점 탐지\n - 민감 정보 노출 검사\n3. 보안 체크리스트 자동화:\n - 의존성 취약점 검사\n - 환경변수 보안 검증\n4. CI 파이프라인 보안 단계 통합\n5. 보안 정책 문서 작성\n6. 보안 이슈 자동 리포팅", + "testStrategy": "취약점 탐지 정확도 검증, 보안 스캔 성능 테스트, False Positive 비율 확인, 보안 정책 준수 검사", + "priority": "high", + "dependencies": [ + "1", + "13" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "16", + "title": "AI 기반 테스트 케이스 자동 생성", + "description": "테스트 케이스 설계 및 엣지 케이스 도출 자동화 시스템", + "details": "1. 테스트 케이스 자동 생성 프롬프트:\n - 컴포넌트 분석 기반 테스트 시나리오\n - 사용자 스토리 기반 테스트 케이스\n2. 엣지 케이스 도출 방법론:\n - 경계값 분석\n - 예외 상황 시나리오\n3. 테스트 케이스 템플릿 표준화:\n - Given-When-Then 패턴\n - 테스트 데이터 관리\n4. E2E 테스트 자동화 (Playwright)\n5. 시각적 회귀 테스트 도구 통합\n6. 테스트 결과 분석 및 리포팅", + "testStrategy": "생성된 테스트 케이스 품질 평가, 엣지 케이스 커버리지 확인, E2E 테스트 안정성 검증, 테스트 실행 시간 최적화", + "priority": "medium", + "dependencies": [ + "1", + "12" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "17", + "title": "성능 및 통합 테스트 자동화", + "description": "성능 모니터링, 병목 분석 및 통합 테스트 자동화 시스템", + "details": "1. 성능 모니터링 도구 통합:\n - Lighthouse CI 설정\n - Web Vitals 측정 자동화\n - Bundle Analyzer 통합\n2. AI 기반 병목 분석:\n - 성능 이슈 자동 탐지\n - 최적화 제안 생성\n3. 통합 테스트 자동화:\n - API 통합 테스트\n - 데이터베이스 연동 테스트\n4. 성능 벤치마크 설정:\n - Core Web Vitals 목표 설정\n - 성능 회귀 탐지\n5. 모니터링 대시보드 구축\n6. 성능 알림 시스템", + "testStrategy": "성능 지표 목표 달성 확인, 병목 분석 정확도 검증, 통합 테스트 안정성 확인, 모니터링 시스템 동작 테스트", + "priority": "medium", + "dependencies": [ + "1", + "16" + ], + "status": "pending", + "subtasks": [] + }, + { + "id": "18", + "title": "버그 리포트 및 수정 자동화 시스템", + "description": "AI 기반 버그 분석, 자동 리포팅 및 수정 제안 시스템", + "details": "1. 버그 자동 탐지 시스템:\n - 에러 로그 분석\n - 사용자 행동 패턴 분석\n2. AI 기반 버그 원인 분석:\n - 스택 트레이스 분석 프롬프트\n - 코드 변경 이력 연관성 분석\n3. 자동 버그 리포팅:\n - 이슈 트래커 연동 (GitLab Issues)\n - 버그 재현 단계 자동 생성\n4. 버그 수정 제안 시스템:\n - 유사 버그 해결 사례 검색\n - 수정 코드 제안 프롬프트\n5. 버그 우선순위 자동 분류\n6. 수정 검증 자동화 테스트", + "testStrategy": "버그 탐지 정확도 검증, 원인 분석 품질 평가, 자동 리포팅 완성도 확인, 수정 제안 유효성 테스트", + "priority": "medium", + "dependencies": [ + "1", + "17" + ], + "status": "pending", + "subtasks": [] + } + ], + "metadata": { + "version": "1.0.0", + "lastModified": "2026-03-24T13:16:43.852Z", + "taskCount": 18, + "completedCount": 0, + "tags": [ + "master" + ] + } + } +} \ No newline at end of file diff --git a/.taskmaster/templates/example_prd.txt b/.taskmaster/templates/example_prd.txt new file mode 100644 index 0000000..194114d --- /dev/null +++ b/.taskmaster/templates/example_prd.txt @@ -0,0 +1,47 @@ + +# Overview +[Provide a high-level overview of your product here. Explain what problem it solves, who it's for, and why it's valuable.] + +# Core Features +[List and describe the main features of your product. For each feature, include: +- What it does +- Why it's important +- How it works at a high level] + +# User Experience +[Describe the user journey and experience. Include: +- User personas +- Key user flows +- UI/UX considerations] + + +# Technical Architecture +[Outline the technical implementation details: +- System components +- Data models +- APIs and integrations +- Infrastructure requirements] + +# Development Roadmap +[Break down the development process into phases: +- MVP requirements +- Future enhancements +- Do not think about timelines whatsoever -- all that matters is scope and detailing exactly what needs to be build in each phase so it can later be cut up into tasks] + +# Logical Dependency Chain +[Define the logical order of development: +- Which features need to be built first (foundation) +- Getting as quickly as possible to something usable/visible front end that works +- Properly pacing and scoping each feature so it is atomic but can also be built upon and improved as development approaches] + +# Risks and Mitigations +[Identify potential risks and how they'll be addressed: +- Technical challenges +- Figuring out the MVP that we can build upon +- Resource constraints] + +# Appendix +[Include any additional information: +- Research findings +- Technical specifications] + \ No newline at end of file diff --git a/.taskmaster/templates/example_prd_rpg.txt b/.taskmaster/templates/example_prd_rpg.txt new file mode 100644 index 0000000..5ad908f --- /dev/null +++ b/.taskmaster/templates/example_prd_rpg.txt @@ -0,0 +1,511 @@ + +# Repository Planning Graph (RPG) Method - PRD Template + +This template teaches you (AI or human) how to create structured, dependency-aware PRDs using the RPG methodology from Microsoft Research. The key insight: separate WHAT (functional) from HOW (structural), then connect them with explicit dependencies. + +## Core Principles + +1. **Dual-Semantics**: Think functional (capabilities) AND structural (code organization) separately, then map them +2. **Explicit Dependencies**: Never assume - always state what depends on what +3. **Topological Order**: Build foundation first, then layers on top +4. **Progressive Refinement**: Start broad, refine iteratively + +## How to Use This Template + +- Follow the instructions in each `` block +- Look at `` blocks to see good vs bad patterns +- Fill in the content sections with your project details +- The AI reading this will learn the RPG method by following along +- Task Master will parse the resulting PRD into dependency-aware tasks + +## Recommended Tools for Creating PRDs + +When using this template to **create** a PRD (not parse it), use **code-context-aware AI assistants** for best results: + +**Why?** The AI needs to understand your existing codebase to make good architectural decisions about modules, dependencies, and integration points. + +**Recommended tools:** +- **Claude Code** (claude-code CLI) - Best for structured reasoning and large contexts +- **Cursor/Windsurf** - IDE integration with full codebase context +- **Gemini CLI** (gemini-cli) - Massive context window for large codebases +- **Codex/Grok CLI** - Strong code generation with context awareness + +**Note:** Once your PRD is created, `task-master parse-prd` works with any configured AI model - it just needs to read the PRD text itself, not your codebase. + + +--- + + + +Start with the problem, not the solution. Be specific about: +- What pain point exists? +- Who experiences it? +- Why existing solutions don't work? +- What success looks like (measurable outcomes)? + +Keep this section focused - don't jump into implementation details yet. + + +## Problem Statement +[Describe the core problem. Be concrete about user pain points.] + +## Target Users +[Define personas, their workflows, and what they're trying to achieve.] + +## Success Metrics +[Quantifiable outcomes. Examples: "80% task completion via autopilot", "< 5% manual intervention rate"] + + + +--- + + + +Now think about CAPABILITIES (what the system DOES), not code structure yet. + +Step 1: Identify high-level capability domains +- Think: "What major things does this system do?" +- Examples: Data Management, Core Processing, Presentation Layer + +Step 2: For each capability, enumerate specific features +- Use explore-exploit strategy: + * Exploit: What features are REQUIRED for core value? + * Explore: What features make this domain COMPLETE? + +Step 3: For each feature, define: +- Description: What it does in one sentence +- Inputs: What data/context it needs +- Outputs: What it produces/returns +- Behavior: Key logic or transformations + + +Capability: Data Validation + Feature: Schema validation + - Description: Validate JSON payloads against defined schemas + - Inputs: JSON object, schema definition + - Outputs: Validation result (pass/fail) + error details + - Behavior: Iterate fields, check types, enforce constraints + + Feature: Business rule validation + - Description: Apply domain-specific validation rules + - Inputs: Validated data object, rule set + - Outputs: Boolean + list of violated rules + - Behavior: Execute rules sequentially, short-circuit on failure + + + +Capability: validation.js + (Problem: This is a FILE, not a CAPABILITY. Mixing structure into functional thinking.) + +Capability: Validation + Feature: Make sure data is good + (Problem: Too vague. No inputs/outputs. Not actionable.) + + + +## Capability Tree + +### Capability: [Name] +[Brief description of what this capability domain covers] + +#### Feature: [Name] +- **Description**: [One sentence] +- **Inputs**: [What it needs] +- **Outputs**: [What it produces] +- **Behavior**: [Key logic] + +#### Feature: [Name] +- **Description**: +- **Inputs**: +- **Outputs**: +- **Behavior**: + +### Capability: [Name] +... + + + +--- + + + +NOW think about code organization. Map capabilities to actual file/folder structure. + +Rules: +1. Each capability maps to a module (folder or file) +2. Features within a capability map to functions/classes +3. Use clear module boundaries - each module has ONE responsibility +4. Define what each module exports (public interface) + +The goal: Create a clear mapping between "what it does" (functional) and "where it lives" (structural). + + +Capability: Data Validation + → Maps to: src/validation/ + ├── schema-validator.js (Schema validation feature) + ├── rule-validator.js (Business rule validation feature) + └── index.js (Public exports) + +Exports: + - validateSchema(data, schema) + - validateRules(data, rules) + + + +Capability: Data Validation + → Maps to: src/utils.js + (Problem: "utils" is not a clear module boundary. Where do I find validation logic?) + +Capability: Data Validation + → Maps to: src/validation/everything.js + (Problem: One giant file. Features should map to separate files for maintainability.) + + + +## Repository Structure + +``` +project-root/ +├── src/ +│ ├── [module-name]/ # Maps to: [Capability Name] +│ │ ├── [file].js # Maps to: [Feature Name] +│ │ └── index.js # Public exports +│ └── [module-name]/ +├── tests/ +└── docs/ +``` + +## Module Definitions + +### Module: [Name] +- **Maps to capability**: [Capability from functional decomposition] +- **Responsibility**: [Single clear purpose] +- **File structure**: + ``` + module-name/ + ├── feature1.js + ├── feature2.js + └── index.js + ``` +- **Exports**: + - `functionName()` - [what it does] + - `ClassName` - [what it does] + + + +--- + + + +This is THE CRITICAL SECTION for Task Master parsing. + +Define explicit dependencies between modules. This creates the topological order for task execution. + +Rules: +1. List modules in dependency order (foundation first) +2. For each module, state what it depends on +3. Foundation modules should have NO dependencies +4. Every non-foundation module should depend on at least one other module +5. Think: "What must EXIST before I can build this module?" + + +Foundation Layer (no dependencies): + - error-handling: No dependencies + - config-manager: No dependencies + - base-types: No dependencies + +Data Layer: + - schema-validator: Depends on [base-types, error-handling] + - data-ingestion: Depends on [schema-validator, config-manager] + +Core Layer: + - algorithm-engine: Depends on [base-types, error-handling] + - pipeline-orchestrator: Depends on [algorithm-engine, data-ingestion] + + + +- validation: Depends on API +- API: Depends on validation +(Problem: Circular dependency. This will cause build/runtime issues.) + +- user-auth: Depends on everything +(Problem: Too many dependencies. Should be more focused.) + + + +## Dependency Chain + +### Foundation Layer (Phase 0) +No dependencies - these are built first. + +- **[Module Name]**: [What it provides] +- **[Module Name]**: [What it provides] + +### [Layer Name] (Phase 1) +- **[Module Name]**: Depends on [[module-from-phase-0], [module-from-phase-0]] +- **[Module Name]**: Depends on [[module-from-phase-0]] + +### [Layer Name] (Phase 2) +- **[Module Name]**: Depends on [[module-from-phase-1], [module-from-foundation]] + +[Continue building up layers...] + + + +--- + + + +Turn the dependency graph into concrete development phases. + +Each phase should: +1. Have clear entry criteria (what must exist before starting) +2. Contain tasks that can be parallelized (no inter-dependencies within phase) +3. Have clear exit criteria (how do we know phase is complete?) +4. Build toward something USABLE (not just infrastructure) + +Phase ordering follows topological sort of dependency graph. + + +Phase 0: Foundation + Entry: Clean repository + Tasks: + - Implement error handling utilities + - Create base type definitions + - Setup configuration system + Exit: Other modules can import foundation without errors + +Phase 1: Data Layer + Entry: Phase 0 complete + Tasks: + - Implement schema validator (uses: base types, error handling) + - Build data ingestion pipeline (uses: validator, config) + Exit: End-to-end data flow from input to validated output + + + +Phase 1: Build Everything + Tasks: + - API + - Database + - UI + - Tests + (Problem: No clear focus. Too broad. Dependencies not considered.) + + + +## Development Phases + +### Phase 0: [Foundation Name] +**Goal**: [What foundational capability this establishes] + +**Entry Criteria**: [What must be true before starting] + +**Tasks**: +- [ ] [Task name] (depends on: [none or list]) + - Acceptance criteria: [How we know it's done] + - Test strategy: [What tests prove it works] + +- [ ] [Task name] (depends on: [none or list]) + +**Exit Criteria**: [Observable outcome that proves phase complete] + +**Delivers**: [What can users/developers do after this phase?] + +--- + +### Phase 1: [Layer Name] +**Goal**: + +**Entry Criteria**: Phase 0 complete + +**Tasks**: +- [ ] [Task name] (depends on: [[tasks-from-phase-0]]) +- [ ] [Task name] (depends on: [[tasks-from-phase-0]]) + +**Exit Criteria**: + +**Delivers**: + +--- + +[Continue with more phases...] + + + +--- + + + +Define how testing will be integrated throughout development (TDD approach). + +Specify: +1. Test pyramid ratios (unit vs integration vs e2e) +2. Coverage requirements +3. Critical test scenarios +4. Test generation guidelines for Surgical Test Generator + +This section guides the AI when generating tests during the RED phase of TDD. + + +Critical Test Scenarios for Data Validation module: + - Happy path: Valid data passes all checks + - Edge cases: Empty strings, null values, boundary numbers + - Error cases: Invalid types, missing required fields + - Integration: Validator works with ingestion pipeline + + + +## Test Pyramid + +``` + /\ + /E2E\ ← [X]% (End-to-end, slow, comprehensive) + /------\ + /Integration\ ← [Y]% (Module interactions) + /------------\ + / Unit Tests \ ← [Z]% (Fast, isolated, deterministic) + /----------------\ +``` + +## Coverage Requirements +- Line coverage: [X]% minimum +- Branch coverage: [X]% minimum +- Function coverage: [X]% minimum +- Statement coverage: [X]% minimum + +## Critical Test Scenarios + +### [Module/Feature Name] +**Happy path**: +- [Scenario description] +- Expected: [What should happen] + +**Edge cases**: +- [Scenario description] +- Expected: [What should happen] + +**Error cases**: +- [Scenario description] +- Expected: [How system handles failure] + +**Integration points**: +- [What interactions to test] +- Expected: [End-to-end behavior] + +## Test Generation Guidelines +[Specific instructions for Surgical Test Generator about what to focus on, what patterns to follow, project-specific test conventions] + + + +--- + + + +Describe technical architecture, data models, and key design decisions. + +Keep this section AFTER functional/structural decomposition - implementation details come after understanding structure. + + +## System Components +[Major architectural pieces and their responsibilities] + +## Data Models +[Core data structures, schemas, database design] + +## Technology Stack +[Languages, frameworks, key libraries] + +**Decision: [Technology/Pattern]** +- **Rationale**: [Why chosen] +- **Trade-offs**: [What we're giving up] +- **Alternatives considered**: [What else we looked at] + + + +--- + + + +Identify risks that could derail development and how to mitigate them. + +Categories: +- Technical risks (complexity, unknowns) +- Dependency risks (blocking issues) +- Scope risks (creep, underestimation) + + +## Technical Risks +**Risk**: [Description] +- **Impact**: [High/Medium/Low - effect on project] +- **Likelihood**: [High/Medium/Low] +- **Mitigation**: [How to address] +- **Fallback**: [Plan B if mitigation fails] + +## Dependency Risks +[External dependencies, blocking issues] + +## Scope Risks +[Scope creep, underestimation, unclear requirements] + + + +--- + + +## References +[Papers, documentation, similar systems] + +## Glossary +[Domain-specific terms] + +## Open Questions +[Things to resolve during development] + + +--- + + +# How Task Master Uses This PRD + +When you run `task-master parse-prd .txt`, the parser: + +1. **Extracts capabilities** → Main tasks + - Each `### Capability:` becomes a top-level task + +2. **Extracts features** → Subtasks + - Each `#### Feature:` becomes a subtask under its capability + +3. **Parses dependencies** → Task dependencies + - `Depends on: [X, Y]` sets task.dependencies = ["X", "Y"] + +4. **Orders by phases** → Task priorities + - Phase 0 tasks = highest priority + - Phase N tasks = lower priority, properly sequenced + +5. **Uses test strategy** → Test generation context + - Feeds test scenarios to Surgical Test Generator during implementation + +**Result**: A dependency-aware task graph that can be executed in topological order. + +## Why RPG Structure Matters + +Traditional flat PRDs lead to: +- ❌ Unclear task dependencies +- ❌ Arbitrary task ordering +- ❌ Circular dependencies discovered late +- ❌ Poorly scoped tasks + +RPG-structured PRDs provide: +- ✅ Explicit dependency chains +- ✅ Topological execution order +- ✅ Clear module boundaries +- ✅ Validated task graph before implementation + +## Tips for Best Results + +1. **Spend time on dependency graph** - This is the most valuable section for Task Master +2. **Keep features atomic** - Each feature should be independently testable +3. **Progressive refinement** - Start broad, use `task-master expand` to break down complex tasks +4. **Use research mode** - `task-master parse-prd --research` leverages AI for better task generation +