🔧 chore: .claude 문서 업데이트 및 아키텍처, 컨벤션, 개요 파일 수정

.claude/project/architecture.md

@@ -1,39 +1,46 @@
-# 아키텍처 (Sample)
+# 아키텍처
+
+> 이 파일은 `fe-common-rules/templates/project/architecture.md` 에서 복사된 양식입니다.
+> 프로젝트의 레이어 구조와 데이터 흐름을 간단히 설명해주세요.
 
 ## 레이어 구조
 
+<프로젝트의 레이어 구조를 그림 또는 텍스트로 그려주세요>
+
 ```
-┌───────────────────────────────────┐
+┌───────────────────────────────┐
-│           pages (Nuxt)            │  ← 라우팅, 데이터 페칭 진입점
+│        presentation           │  ← pages / components
-├───────────────────────────────────┤
+├───────────────────────────────┤
-│          components               │  ← 재사용 UI (도메인/공용 분리)
+│         logic                 │  ← composables / hooks / stores
-├───────────────────────────────────┤
+├───────────────────────────────┤
-│       composables (use*)          │  ← 상태 + 로직 (뷰 독립)
+│      data access              │  ← api wrapper / queries
-├───────────────────────────────────┤
+├───────────────────────────────┤
-│    composables/api (wrapper)      │  ← 서버 통신 단일 창구
+│         server                │  ← 서버 라우트 / BFF
-├───────────────────────────────────┤
+└───────────────────────────────┘
-│         server/api                │  ← Nuxt 서버 라우트
-└───────────────────────────────────┘
 ```
 
-## 규칙
+## 의존 규칙
 
-- 하위 레이어는 상위 레이어를 import 할 수 없습니다. (단방향 의존)
+- 상위 → 하위 **단방향 의존**만 허용
-- `components` 는 비즈니스 로직을 직접 수행하지 않고, composable 에 위임합니다.
+- 같은 레이어 간 순환 import 금지
-- 전역 상태는 필요한 경우에만 Pinia store 로 승격합니다.
+- <프로젝트 고유 규칙 추가>
 
 ## 데이터 흐름
 
-1. 사용자 이벤트 → `components` 에서 `composable` 호출
+1. <이벤트 발생부터 응답까지의 흐름을 간단히>
-2. `composable` → `composables/api` 래퍼 호출
+2. ...
-3. 래퍼 → `$fetch` 로 Nuxt `server/api` 또는 외부 API 요청
+3. ...
-4. 응답은 타입이 보장된 상태로 composable → component 로 전달
 
 ## 상태 관리 가이드
 
 | 상태 종류            | 권장 위치                |
 | -------------------- | ------------------------ |
-| 컴포넌트 로컬 상태   | `ref` / `reactive`       |
+| 컴포넌트 로컬 상태   | <예: ref / useState>     |
-| 페이지 단위 공유 상태| `provide/inject` 또는 composable |
+| 페이지 단위 공유 상태| <예: provide/inject>     |
-| 앱 전역 상태         | Pinia store              |
+| 앱 전역 상태         | <예: Pinia / Zustand>    |
-| 서버 데이터          | `useAsyncData`/`useFetch`|
+| 서버 데이터          | <예: useFetch / TanStack Query> |
+
+## 외부 의존성
+
+- 반드시 알아야 할 외부 서비스나 내부 API 를 나열
+- 장애 발생 시 fallback 정책이 있다면 함께 기술

.claude/project/conventions.md

@@ -1,34 +1,44 @@
-# 프로젝트 전용 컨벤션 (Sample)
+# 프로젝트 전용 컨벤션
 
-공통 지침(`.claude/common/`) 외에 **이 프로젝트에서만** 적용되는 규칙을 정의합니다.
+> 이 파일은 `fe-common-rules/templates/project/conventions.md` 에서 복사된 양식입니다.
-공통 지침과 충돌할 경우 이 문서가 우선합니다.
+> 공통 지침(`.claude/common/`) 외에 **이 프로젝트에서만** 적용되는 규칙을 작성하세요.
+> 공통 지침과 충돌할 경우 이 문서가 우선합니다.
 
 ## 디렉토리 규칙
 
-- `components/` — 재사용 컴포넌트. 도메인별 하위 폴더(`user/`, `order/`)로 분리
+- `components/` — <설명>
-- `composables/` — `useXxx` 형태의 재사용 로직
+- `composables/` 또는 `hooks/` — <설명>
-- `pages/` — Nuxt 파일 기반 라우팅
+- `pages/` 또는 `app/` — <설명>
-- `server/api/` — 서버 라우트 핸들러
+- `server/` 또는 `api/` — <설명>
-- `types/` — 전역/공통 타입 정의
+- `types/` — <설명>
 
-## 컴포넌트 규칙 (오버라이드)
+## 컴포넌트 규칙 (공통 규칙 오버라이드)
 
-- 이 프로젝트에서는 컴포넌트 파일 길이를 **150줄**로 제한합니다. (공통 200줄보다 엄격)
+<공통 규칙과 달리 이 프로젝트에서만 적용할 제약을 적어주세요>
-- 컴포넌트 당 `defineProps` 의 항목은 **최대 7개**. 초과 시 객체 props 로 묶습니다.
 
-## Tailwind
+- 예) 컴포넌트 파일 길이 제한: 150줄 (공통 200줄보다 엄격)
+- 예) Props 개수 최대 7개, 초과 시 객체 props 로 묶기
 
-- 색상은 `tailwind.config.ts` 의 `theme.extend.colors` 에 등록된 토큰만 사용합니다.
+## 스타일
-  (임의 색상 사용 금지)
-- 다크모드 클래스 prefix 는 `dark:` 를 사용합니다.
 
-## 네트워크
+- 색상/간격/타이포는 디자인 토큰만 사용하고 임의값 금지
+- 다크모드 prefix: `dark:`
+- 기타 프로젝트 고유 규칙: <작성>
 
-- API 호출은 반드시 `composables/api/` 의 래퍼를 통해 수행합니다.
+## 네트워크 / 데이터
-- 직접 `$fetch` / `fetch` 사용은 금지 (테스트 목적 제외).
+
+- API 호출 창구: <예: composables/api 의 wrapper 만 사용>
+- 인증 토큰 저장 위치: <예: httpOnly 쿠키>
+- 에러 핸들링 규칙: <작성>
+
+## 금지 사항
+
+- <예: 직접 $fetch 사용 금지>
+- <예: 전역 이벤트 버스 사용 금지>
+- <예: any 타입 사용 금지>
 
 ## 테스트
 
-- Vitest 를 기본 테스트 러너로 사용합니다.
+- 테스트 러너: <Vitest / Jest 등>
-- 테스트 파일은 소스 옆에 `*.spec.ts` 로 배치합니다.
+- 테스트 파일 위치: <소스 옆 / __tests__ 폴더>
-- 공통 유틸과 composable 은 테스트 커버리지 80% 이상을 유지합니다.
+- 최소 커버리지: <숫자>

.claude/project/overview.md

@@ -1,27 +1,39 @@
-# 프로젝트 개요 (Sample)
+# 프로젝트 개요
+
+> 이 파일은 `fe-common-rules/templates/project/overview.md` 에서 복사된 양식입니다.
+> 프로젝트 세팅 후 실제 내용으로 채워주세요.
 
 ## 서비스
 
-- **이름**: Sample Nuxt App
+- **이름**: <프로젝트 이름>
-- **설명**: fe-common-rules 도입 예시용 샘플 프로젝트
+- **설명**: <한 줄 설명>
-- **배포 환경**: 로컬 전용 (샘플)
+- **배포 환경**: <dev / staging / production URL 또는 환경>
+- **저장소**: <git 주소>
 
 ## 기술 스택
 
-- **Framework**: Nuxt 4
+- **Framework**: <예: Nuxt 4 / Next 15 / ...>
-- **UI**: Vue 3 (`<script setup lang="ts">`)
+- **UI**: <예: Vue 3 <script setup> / React 19 / ...>
 - **Language**: TypeScript (strict)
-- **Styling**: Tailwind CSS
+- **Styling**: <예: Tailwind CSS / styled-components / ...>
-- **상태관리**: Pinia (필요 시)
+- **상태관리**: <예: Pinia / Zustand / Redux Toolkit / ...>
-- **패키지매니저**: pnpm
+- **테스트**: <예: Vitest + Playwright / Jest + RTL / ...>
+- **패키지매니저**: <pnpm / npm / yarn>
 
-## 주요 기능 (예시)
+## 주요 기능
 
-- 메인 페이지 (`/`)
+- <기능 1>
-- 샘플 컴포넌트 `HelloCard.vue`
+- <기능 2>
-- 공통 지침을 활용한 린트/타입 검증
+- <기능 3>
 
 ## 팀 / 오너
 
-- Frontend Team
+- 오너: <팀 또는 담당자>
-- 문의: #fe-chapter (Slack)
+- 문의 채널: <Slack 채널 / 이메일>
+- 온콜/긴급 연락: <필요 시>
+
+## 참고 문서
+
+- 기획 문서: <링크>
+- 디자인 시스템: <링크>
+- API 스펙: <링크>

.cursorrules

@@ -0,0 +1,70 @@
+# Nuxt 프로젝트 — Cursor 규칙
+
+## 언어
+
+- 사용자와의 대화·설명·커밋 메시지 본문은 **한국어**를 사용한다.
+
+## Git 커밋 메시지 (필수)
+
+- **제목은 한 줄**, [Conventional Commits](https://www.conventionalcommits.org/) + **이모지**를 함께 쓴다.
+- 형식: `<이모지> <type>: <한글 설명>` (이모지·타입·콜론 뒤 공백 한 칸)
+- **설명(제목 본문)은 반드시 한글**로 작성한다. 영어 제목만 단독으로 쓰지 않는다.
+- **명령형** 어조 (`추가`, `수정` — `추가됨`, `수정함` 지양).
+- **첫 줄(제목)은 72자 미만**을 권장한다.
+- **원자적 커밋**: 한 커밋에 단일 목적만 담는다. 관련 없는 변경은 분할한다.
+- 커밋 생성 시 **Claude·AI 서명·Co-authored-by 등 메타 서명을 본문에 넣지 않는다.**
+
+### 커밋 생성 프로세스 (`/commit` 등 요청 시)
+
+1. **스테이지된 파일**이 있으면 그 파일만 대상으로 커밋한다. 없으면 사용자에게 스테이징 여부를 확인한다.
+2. `git diff` 등으로 **논리적 변경 덩어리**를 분석한다.
+3. 타입이 섞였거나 관심사가 다르면 **분할 커밋**을 제안한다.
+4. 아래 **이모지 맵**과 타입에 맞춰 제목을 만든다.
+
+### 타입 (type)
+
+| type | 용도 |
+|------|------|
+| `feat` | 새 기능 |
+| `fix` | 버그 수정 |
+| `docs` | 문서 |
+| `style` | 포맷팅·세미콜론 등 의미 없는 스타일 |
+| `refactor` | 리팩터링 |
+| `perf` | 성능 개선 |
+| `test` | 테스트 |
+| `chore` | 빌드·도구·잡무 |
+| `ci` | CI |
+| `build` | 빌드 시스템·번들러 |
+
+### 이모지 맵 (타입·맥락에 맞게 선택)
+
+✨ feat | 🐛 fix | 📝 docs | 💄 style | ♻️ refactor | ⚡ perf | ✅ test | 🔧 chore | 🚀 ci | 🚨 warnings | 🔒️ security | 🚚 move | 🏗️ architecture | ➕ add-dep | ➖ remove-dep | 🌱 seed | 🧑‍💻 dx | 🏷️ types | 👔 business | 🚸 ux | 🩹 minor-fix | 🥅 errors | 🔥 remove | 🎨 structure | 🚑️ hotfix | 🎉 init | 🔖 release | 🚧 wip | 💚 ci-fix | 📌 pin-deps | 👷 ci-build | 📈 analytics | ✏️ typos | ⏪️ revert | 📄 license | 💥 breaking | 🍱 assets | ♿️ accessibility | 💡 comments | 🗃️ db | 🔊 logs | 🔇 remove-logs | 🙈 gitignore | 📸 snapshots | ⚗️ experiment | 🚩 flags | 💫 animations | ⚰️ dead-code | 🦺 validation | ✈️ offline
+
+### 분할 제안 기준
+
+- 서로 다른 **관심사**가 한 diff에 섞인 경우
+- **타입**이 혼합된 경우 (예: `feat` + `fix`)
+- **파일 패턴**이 완전히 다른 영역(예: 앱 코드 vs 인프라만)인 경우
+- **변경량이 크고** 커밋 단위로 나눌 수 있는 경우
+
+### 예시
+
+- `✨ feat: 로그인 폼 유효성 검사 추가`
+- `♻️ refactor: 사용자 API 호출 로직을 composable로 분리`
+- `🐛 fix: 모바일에서 헤더가 겹치는 문제 수정`
+
+### 본문이 필요할 때
+
+- 제목 아래 빈 줄 후 본문을 한글 bullet 또는 문단으로 적는다.
+
+## 코드·작업 방식
+
+- 요청 범위 밖의 리팩터·포맷 일괄 변경·무관 파일 수정을 하지 않는다.
+- 기존 코드의 네이밍, import 스타일, 타입·주석 수준에 맞춘다.
+- 변경 이유가 드러나는 **작고 집중된 diff**를 선호한다.
+
+## Cursor 사용 시
+
+- 파일을 수정하기 전에 관련 맥락(주변 코드·설정)을 읽고 일관되게 맞춘다.
+- 사용자가 명시적으로 요청하지 않은 README·문서 파일은 새로 쓰거나 크게 늘리지 않는다.
+