feat: 프로젝트 세팅

docs/skills/color_system.md

@@ -0,0 +1,20 @@
+# VibeRoom Color System (3-Color Palette)
+
+본 문서는 VibeRoom 웹앱의 UI/UX 일관성을 유지하기 위해 엄격하게 제한된 3가지 핵심 색상 시스템을 정의합니다. AI(Cursor, Cline 등) 코딩 시 **이 3가지 색상과 기본 무채색(white, slate-50) 범위를 벗어난 임의의 색상 사용을 엄격히 금지**합니다.
+
+## 1. 색상 정의 및 용도
+빌드 캐시 에러를 원천 차단하기 위해 Tailwind의 JIT 헥스(HEX) 주입 방식(예: `bg-[#63adf2]`)을 기본으로 사용합니다.
+
+| 색상 코드 | Tailwind 적용 예시 | 역할 (Role) | 주요 사용처 |
+| :--- | :--- | :--- | :--- |
+| `#304d6d` | `text-[#304d6d]`, `bg-[#304d6d]` | **딥 네이비 (메인 텍스트 & 다크 배경)** | 묵직하고 차분한 색상. 본문 글씨, 제목, 선(border), 푸터(Footer), 강조 요금제 카드 등에 사용되어 화면의 무게중심을 잡아줍니다. |
+| `#63adf2` | `bg-[#63adf2]`, `text-[#63adf2]` | **소프트 코발트 (포인트 액션)** | 청명하고 기분 좋은 파란색. '무료로 시작하기', 추천 뱃지 등 유저가 액션을 취해야 하는 핵심 영역에만 포인트로 강조합니다. |
+| `#a7cced` | `bg-[#a7cced]`, `border-[#a7cced]` | **파스텔 스카이 (소프트 서페이스)** | 아주 연하고 부드러운 파란색. 기능 소개 카드의 은은한 배경이나 체크마크(`✓`), 호버 상태 등 편안한 포인트 요소에 사용됩니다. |
+
+## 2. AI 바이브 코딩 시 주의사항 (스타일 가이드)
+- **기본 배경:** 서비스의 기본 배경은 너무 파래서 답답하지 않도록 깨끗한 `slate-50`(`bg-slate-50`) 또는 `white`(`bg-white`)를 사용합니다.
+- **투명도(Opacity) 활용:** 이 3가지 색상만으로 디자인을 구성하되, 농도를 조절해야 할 때는 Tailwind의 투명도 문법을 활용하세요. 
+  - *예시 (텍스트 흐리게):* `text-[#304d6d]/70`
+  - *예시 (배경 옅게):* `bg-[#a7cced]/10`
+  - *예시 (테두리 연하게):* `border-[#304d6d]/20`
+- **테두리(Border):** 부드러운 느낌을 위해 각진 모서리는 피하고(`rounded-2xl`, `rounded-full` 권장), 선의 굵기보다 색상의 농도 조절로 구분감을 줍니다.

docs/skills/frontend_architecture.md

@@ -0,0 +1,43 @@
+# VibeRoom 프론트엔드 아키텍처 규칙 (Lite FSD)
+
+본 문서는 VibeRoom 웹앱의 프론트엔드 코드 작성을 위한 핵심 지침서입니다. AI(Cursor, Cline, Gemini 등)를 통한 코딩 시 반드시 본 문서의 아키텍처 원칙을 준수해야 코드가 얽히고 망가지는(Code Rot) 현상을 방지할 수 있습니다.
+
+## 1. 아키텍처 핵심 사상
+이 프로젝트는 **'도메인/피처 기반(Feature-Driven) 아키텍처'**를 채택했습니다. 복잡한 FSD(Feature-Sliced Design)를 단순화하여 백엔드 개발자와 AI가 모두 이해하기 쉬운 구조입니다.
+
+**핵심 철학: "한 기능(Domain)에 관련된 코드는 무조건 하나의 `features` 폴더에 모아둔다."**
+
+## 2. 폴더 구조 설명 및 엄수 사항
+
+```text
+src/
+├── app/                  # 진입점 (Routing & Pages)
+├── features/             # 도메인 로직 묶음 (비즈니스 핵심)
+├── shared/               # 공통 요소 (UI, Lib, Type - 도메인 종속성 0%)
+└── store/                # 글로벌 상태 관리 (최소한으로 사용)
+```
+
+### 🚨 [규칙 1] `app/` 폴더는 멍청한 조립 공장이다.
+- `app/**/page.tsx` 파일에는 절대 복잡한 비즈니스 로직(API 호출, 상태 관리)을 길게 작성하지 마세요.
+- 오직 `features/`나 `shared/`에서 완성된 컴포넌트들을 `import` 해와서 배치(Layout)하는 역할만 수행합니다.
+- 데이터 패칭이 필요하다면 SSR/RSC(React Server Components)의 장점을 살려 데이터를 가져온 후 하위 컴포넌트에 넘겨주는 선까지만 작성합니다.
+
+### 🚨 [규칙 2] `features/` 간의 상호 참조를 절대 금지한다.
+- `src/features/timer` 내부의 파일이 `src/features/space` 내부의 파일을 직접 `import` 해서는 안 됩니다.
+- 기능(도메인) 간의 결합도가 높아지면, AI가 한 도메인을 수정할 때 다른 도메인이 망가지는 나비효과가 발생합니다.
+- 만약 두 기능이 서로 통신해야 한다면 1) 부모 페이지 컴포넌트(`app/`)에서 상태를 내려주거나 2) `store/`의 전역 상태를 활용하세요.
+
+### 🚨 [규칙 3] `shared/`는 도메인을 몰라야 한다.
+- `src/shared/ui/Button.tsx`는 자기가 '로그인 버튼'인지, '타이머 시작 버튼'인지 절대 알면 안 됩니다.
+- 오직 범용적인 디자인 컴포넌트, 유틸 함수, 전역 타입만 위치합니다.
+- 이 폴더 안의 코드는 어떤 프로젝트에 복사/붙여넣기 해도 바로 동작할 만큼 순수(Pure)해야 합니다.
+
+### 🚨 [규칙 4] 컴포넌트 작성 시 '기능 중심' 사고방식
+- "버튼 하나 만들자" ➡️ `shared/ui`에 생성.
+- "로그인 폼 만들자" ➡️ `features/auth/components`에 생성.
+- "타이머 시작 함수 만들자" ➡️ `features/timer/api` 또는 `hooks`에 생성.
+- "사용자 데이터를 여러 화면에서 공유하자" ➡️ `store/globalStore.ts` (Zustand) 생성.
+
+---
+**※ AI 에이전트 지시사항 ※**
+코드를 생성하거나 리팩토링할 때 위 4가지 규칙 중 하나라도 위반하는 제안을 해서는 안 됩니다. 새로운 파일을 생성할 때는 반드시 이 폴더 트리 구조 중 어디에 속해야 하는지 명확히 설명하고 승인을 받으세요.