@su-record/vibe 2.0.0 → 2.0.1

package/.vibe/constitution.md

@@ -1,184 +1,184 @@
-# Project Constitution
-
-이 문서는 프로젝트의 핵심 원칙과 코딩 표준을 정의합니다.
-
----
-
-## 언어 설정
-
-**기본 언어**: 한국어 (ko)
-
-변경하려면 `.sutory/config.json`에서 수정:
-```json
-{
-  "language": "ko"  // "en"으로 변경 가능
-}
-```
-
----
-
-## 1. 프로젝트 원칙
-
-### 가치 (Values)
-1. **사용자 중심**: 사용자 경험을 최우선으로
-2. **품질**: 빠른 것보다 올바른 것
-3. **간결함**: 복잡함보다 단순함
-4. **협업**: 개인보다 팀
-
-### 의사결정 기준
-1. 보안 > 성능 > 편의성
-2. 명확함 > 영리함
-3. 테스트 가능 > 추상적 설계
-
----
-
-## 2. 코딩 표준
-
-### 공통 원칙
-- **DRY**: Don't Repeat Yourself
-- **SRP**: Single Responsibility Principle
-- **YAGNI**: You Aren't Gonna Need It
-- **함수 ≤30줄** (권장), ≤50줄 (허용)
-- **Cyclomatic Complexity ≤10**
-- **Cognitive Complexity ≤15**
-
-### 네이밍 규칙
-- 변수: 명사 (`userData`, `userList`)
-- 함수: 동사+명사 (`fetchData`, `updateUser`)
-- Boolean: `is/has/can` (`isLoading`, `hasError`)
-- 상수: `UPPER_SNAKE_CASE` (`MAX_RETRY_COUNT`)
-
----
-
-## 3. 품질 기준 (TRUST 5)
-
-### T - Test-first
-- ✅ Contract Testing (최우선)
-- ✅ Integration Testing (70%+ 커버리지)
-- 🔵 Unit Testing (순수 함수만)
-
-### R - Readable
-- 한국어 주석 및 docstring
-- 명확한 변수명
-- 복잡한 로직은 주석으로 설명
-
-### U - Unified
-- 일관된 코딩 스타일
-- 프로젝트 전체 동일한 패턴
-
-### S - Secured
-- SQL Injection 방지
-- XSS 방지
-- 민감 정보 환경 변수로 관리
-
-### T - Trackable
-- Git commit 메시지 명확히
-- TODO/FIXME 주석 활용
-- 중요 결정사항 문서화
-
----
-
-## 4. 기술 스택
-
-### Backend
-- Language: TypeScript/Node.js
-- Framework: Express/Fastify
-- Database: (프로젝트에 맞게 설정)
-
-### Frontend
-- Framework: {Flutter / React / etc.}
-- State Management: (프로젝트에 맞게 설정)
-
-### Infrastructure
-- Hosting: (프로젝트에 맞게 설정)
-- CI/CD: (프로젝트에 맞게 설정)
-
----
-
-## 5. Git 워크플로우
-
-### 브랜치 전략
-- `main`: 프로덕션
-- `develop`: 개발 (기본 브랜치)
-- `feature/{기능명}`: 새 기능
-- `fix/{버그명}`: 버그 수정
-
-### Commit 메시지 규칙
-```
-feat: 새 기능 추가
-fix: 버그 수정
-docs: 문서 수정
-refactor: 리팩토링
-test: 테스트 추가/수정
-chore: 빌드, 설정 변경
-```
-
-### PR 규칙
-1. SPEC 기반 개발
-2. 코드 리뷰 필수
-3. 테스트 통과 확인
-4. SPEC 검증 완료
-
----
-
-## 6. 코드 리뷰 기준
-
-### 필수 체크
-- [ ] SPEC 요구사항 충족
-- [ ] TRUST 5 준수
-- [ ] 테스트 작성 및 통과
-- [ ] 문서화 완료
-- [ ] 보안 이슈 없음
-
-### 권장 사항
-- [ ] 성능 최적화 고려
-- [ ] 확장성 고려
-- [ ] 에러 처리 완비
-
----
-
-## 7. 문서화 규칙
-
-### 코드 주석
-- 모든 함수: 한국어 docstring
-- 복잡한 로직: 인라인 주석
-- TODO/FIXME: 이슈 번호 포함
-
-### API 문서
-- OpenAPI (Swagger) 자동 생성
-- 예시 Request/Response 포함
-
-### README
-- 프로젝트 개요
-- 설치 및 실행 방법
-- 주요 기능 설명
-
----
-
-## 8. 보안 정책
-
-### 인증
-- JWT 기반 인증
-- Refresh 토큰 사용
-
-### 권한
-- Role-based Access Control
-- 최소 권한 원칙
-
-### 데이터 보호
-- 개인정보 암호화
-- HTTPS 필수
-- 환경 변수로 비밀 관리
-
----
-
-## 9. 성능 목표
-
-### 응답 시간
-- API: P95 < 500ms
-- 웹페이지: FCP < 1.5s
-
-### 가용성
-- Uptime: 99.9%
-- RTO: 1시간
-- RPO: 15분
+# Project Constitution
+
+이 문서는 프로젝트의 핵심 원칙과 코딩 표준을 정의합니다.
+
+---
+
+## 언어 설정
+
+**기본 언어**: 한국어 (ko)
+
+변경하려면 `.sutory/config.json`에서 수정:
+```json
+{
+  "language": "ko"  // "en"으로 변경 가능
+}
+```
+
+---
+
+## 1. 프로젝트 원칙
+
+### 가치 (Values)
+1. **사용자 중심**: 사용자 경험을 최우선으로
+2. **품질**: 빠른 것보다 올바른 것
+3. **간결함**: 복잡함보다 단순함
+4. **협업**: 개인보다 팀
+
+### 의사결정 기준
+1. 보안 > 성능 > 편의성
+2. 명확함 > 영리함
+3. 테스트 가능 > 추상적 설계
+
+---
+
+## 2. 코딩 표준
+
+### 공통 원칙
+- **DRY**: Don't Repeat Yourself
+- **SRP**: Single Responsibility Principle
+- **YAGNI**: You Aren't Gonna Need It
+- **함수 ≤30줄** (권장), ≤50줄 (허용)
+- **Cyclomatic Complexity ≤10**
+- **Cognitive Complexity ≤15**
+
+### 네이밍 규칙
+- 변수: 명사 (`userData`, `userList`)
+- 함수: 동사+명사 (`fetchData`, `updateUser`)
+- Boolean: `is/has/can` (`isLoading`, `hasError`)
+- 상수: `UPPER_SNAKE_CASE` (`MAX_RETRY_COUNT`)
+
+---
+
+## 3. 품질 기준 (TRUST 5)
+
+### T - Test-first
+- ✅ Contract Testing (최우선)
+- ✅ Integration Testing (70%+ 커버리지)
+- 🔵 Unit Testing (순수 함수만)
+
+### R - Readable
+- 한국어 주석 및 docstring
+- 명확한 변수명
+- 복잡한 로직은 주석으로 설명
+
+### U - Unified
+- 일관된 코딩 스타일
+- 프로젝트 전체 동일한 패턴
+
+### S - Secured
+- SQL Injection 방지
+- XSS 방지
+- 민감 정보 환경 변수로 관리
+
+### T - Trackable
+- Git commit 메시지 명확히
+- TODO/FIXME 주석 활용
+- 중요 결정사항 문서화
+
+---
+
+## 4. 기술 스택
+
+### Backend
+- Language: TypeScript/Node.js
+- Framework: Express/Fastify
+- Database: (프로젝트에 맞게 설정)
+
+### Frontend
+- Framework: {Flutter / React / etc.}
+- State Management: (프로젝트에 맞게 설정)
+
+### Infrastructure
+- Hosting: (프로젝트에 맞게 설정)
+- CI/CD: (프로젝트에 맞게 설정)
+
+---
+
+## 5. Git 워크플로우
+
+### 브랜치 전략
+- `main`: 프로덕션
+- `develop`: 개발 (기본 브랜치)
+- `feature/{기능명}`: 새 기능
+- `fix/{버그명}`: 버그 수정
+
+### Commit 메시지 규칙
+```
+feat: 새 기능 추가
+fix: 버그 수정
+docs: 문서 수정
+refactor: 리팩토링
+test: 테스트 추가/수정
+chore: 빌드, 설정 변경
+```
+
+### PR 규칙
+1. SPEC 기반 개발
+2. 코드 리뷰 필수
+3. 테스트 통과 확인
+4. SPEC 검증 완료
+
+---
+
+## 6. 코드 리뷰 기준
+
+### 필수 체크
+- [ ] SPEC 요구사항 충족
+- [ ] TRUST 5 준수
+- [ ] 테스트 작성 및 통과
+- [ ] 문서화 완료
+- [ ] 보안 이슈 없음
+
+### 권장 사항
+- [ ] 성능 최적화 고려
+- [ ] 확장성 고려
+- [ ] 에러 처리 완비
+
+---
+
+## 7. 문서화 규칙
+
+### 코드 주석
+- 모든 함수: 한국어 docstring
+- 복잡한 로직: 인라인 주석
+- TODO/FIXME: 이슈 번호 포함
+
+### API 문서
+- OpenAPI (Swagger) 자동 생성
+- 예시 Request/Response 포함
+
+### README
+- 프로젝트 개요
+- 설치 및 실행 방법
+- 주요 기능 설명
+
+---
+
+## 8. 보안 정책
+
+### 인증
+- JWT 기반 인증
+- Refresh 토큰 사용
+
+### 권한
+- Role-based Access Control
+- 최소 권한 원칙
+
+### 데이터 보호
+- 개인정보 암호화
+- HTTPS 필수
+- 환경 변수로 비밀 관리
+
+---
+
+## 9. 성능 목표
+
+### 응답 시간
+- API: P95 < 500ms
+- 웹페이지: FCP < 1.5s
+
+### 가용성
+- Uptime: 99.9%
+- RTO: 1시간
+- RPO: 15분

package/.vibe/rules/core/communication-guide.md

@@ -1,104 +1,104 @@
-# 💬 커뮤니케이션 가이드
-
-## ⚠️ 최우선 규칙: 한국어로 응답
-
-**모든 대화, 설명, 주석은 한국어로 작성합니다.**
-
-- ✅ AI 응답: 한국어
-- ✅ 코드 주석: 한국어
-- ✅ 문서: 한국어
-- ✅ 에러 메시지: 한국어
-- ⚠️ 예외: 코드 자체 (함수명, 변수명 등)는 영어
-
-## 3.1 코드 제공 형식
-
-```markdown
-### 작업 범위
-
-"요청하신 대로 UserProfile 컴포넌트의 상태 관리 로직만 수정했습니다."
-
-### 변경 사항 요약
-
-주문 상태 업데이트 로직 개선 - Optimistic updates 적용
-
-### 코드
-
-[완전한 코드 블록]
-
-### 참고사항
-
-- 에러 발생 시 자동 롤백
-- 네트워크 재시도 3회
-```
-
-## 3.2 리뷰 응답 형식
-
-```markdown
-### 개선점
-
-1. memoization 누락 (성능)
-2. error boundary 미적용 (안정성)
-
-### 권장사항
-
-useMemo 적용 및 ErrorBoundary로 감싸기
-```
-
-## 3.3 에러 보고 형식
-
-```markdown
-### 문제
-
-[발생한 문제 명확히 설명]
-
-### 원인
-
-[분석된 원인]
-
-### 해결 방법
-
-[구체적인 해결 단계]
-
-### 예방책
-
-[향후 방지 방법]
-```
-
-## 3.4 변경사항 설명 원칙
-
-- **명확성**: 무엇을 왜 변경했는지 명확히
-- **간결성**: 핵심만 전달
-- **완전성**: 부작용과 주의사항 포함
-- **추적성**: 관련 이슈/요청 참조
-
-## 3.5 특수 명령어 실행
-
-- **"optimize"**: 성능 개선 (memoization, 번들 크기 등)
-- **"enhance accessibility"**: ARIA, 키보드 지원 등 추가
-- **"strengthen types"**: any 제거, 타입 안전성 향상
-- **"cleanup"**: 불필요한 코드 제거 (요청 시에만)
-- **"split"**: 컴포넌트/함수 분리 (요청 시에만)
-
-## 3.6 질문 형식
-
-### 명확성이 필요할 때
-
-```markdown
-다음 사항을 확인해주세요:
-
-1. [구체적인 질문 1]
-2. [구체적인 질문 2]
-
-이 정보가 있으면 더 정확한 구현이 가능합니다.
-```
-
-### 대안 제시
-
-```markdown
-요청하신 방법 외에 다음 대안도 가능합니다:
-
-**방법 A**: [설명] - 장점: [장점], 단점: [단점]
-**방법 B**: [설명] - 장점: [장점], 단점: [단점]
-
-어떤 방식을 선호하시나요?
-```
+# 💬 커뮤니케이션 가이드
+
+## ⚠️ 최우선 규칙: 한국어로 응답
+
+**모든 대화, 설명, 주석은 한국어로 작성합니다.**
+
+- ✅ AI 응답: 한국어
+- ✅ 코드 주석: 한국어
+- ✅ 문서: 한국어
+- ✅ 에러 메시지: 한국어
+- ⚠️ 예외: 코드 자체 (함수명, 변수명 등)는 영어
+
+## 3.1 코드 제공 형식
+
+```markdown
+### 작업 범위
+
+"요청하신 대로 UserProfile 컴포넌트의 상태 관리 로직만 수정했습니다."
+
+### 변경 사항 요약
+
+주문 상태 업데이트 로직 개선 - Optimistic updates 적용
+
+### 코드
+
+[완전한 코드 블록]
+
+### 참고사항
+
+- 에러 발생 시 자동 롤백
+- 네트워크 재시도 3회
+```
+
+## 3.2 리뷰 응답 형식
+
+```markdown
+### 개선점
+
+1. memoization 누락 (성능)
+2. error boundary 미적용 (안정성)
+
+### 권장사항
+
+useMemo 적용 및 ErrorBoundary로 감싸기
+```
+
+## 3.3 에러 보고 형식
+
+```markdown
+### 문제
+
+[발생한 문제 명확히 설명]
+
+### 원인
+
+[분석된 원인]
+
+### 해결 방법
+
+[구체적인 해결 단계]
+
+### 예방책
+
+[향후 방지 방법]
+```
+
+## 3.4 변경사항 설명 원칙
+
+- **명확성**: 무엇을 왜 변경했는지 명확히
+- **간결성**: 핵심만 전달
+- **완전성**: 부작용과 주의사항 포함
+- **추적성**: 관련 이슈/요청 참조
+
+## 3.5 특수 명령어 실행
+
+- **"optimize"**: 성능 개선 (memoization, 번들 크기 등)
+- **"enhance accessibility"**: ARIA, 키보드 지원 등 추가
+- **"strengthen types"**: any 제거, 타입 안전성 향상
+- **"cleanup"**: 불필요한 코드 제거 (요청 시에만)
+- **"split"**: 컴포넌트/함수 분리 (요청 시에만)
+
+## 3.6 질문 형식
+
+### 명확성이 필요할 때
+
+```markdown
+다음 사항을 확인해주세요:
+
+1. [구체적인 질문 1]
+2. [구체적인 질문 2]
+
+이 정보가 있으면 더 정확한 구현이 가능합니다.
+```
+
+### 대안 제시
+
+```markdown
+요청하신 방법 외에 다음 대안도 가능합니다:
+
+**방법 A**: [설명] - 장점: [장점], 단점: [단점]
+**방법 B**: [설명] - 장점: [장점], 단점: [단점]
+
+어떤 방식을 선호하시나요?
+```

package/.vibe/rules/core/development-philosophy.md

@@ -1,53 +1,53 @@
-# 🏛️ 개발 철학과 원칙 - "왜"에 대한 답
-
-## 1.1 🥇 최우선 순위: 수술적 정밀도
-
-> **⚠️ 이것은 모든 작업에 앞서는 TORY의 첫 번째 원칙입니다.**
->
-> **요청받지 않은 코드는 절대 수정/삭제하지 않습니다.**
-
-### 원칙
-
-- **엄격한 범위 준수**: 사용자가 명시적으로 요청한 파일과 코드 블록만 수정
-- **기존 코드 보존**: 작동하는 코드를 임의로 리팩토링하거나 제거하지 않음
-- **스타일 존중**: 기존 네이밍, 포맷팅, 주석 스타일 유지
-
-## 1.2 핵심 철학
-
-### 🎯 개발의 황금률
-
-- **한국어 우선**: 모든 커뮤니케이션은 명확한 한국어로
-- **단순함의 미학**: 코드가 적을수록 좋은 코드
-- **DRY 원칙**: 반복하지 말고 재사용
-- **단일 책임**: 하나의 함수는 하나의 목적만
-- **실용주의**: 완벽보다 실용, YAGNI 정신
-
-### 🎨 코드 품질 기준
-
-- **가독성**: 코드는 사람을 위한 것
-- **예측 가능성**: 코드에서 놀라움은 금물
-- **유지보수성**: 미래의 나를 배려
-- **테스트 가능성**: 검증 가능한 구조
-
-## 1.3 아키텍처 원칙
-
-### 🏗️ 설계의 지혜
-
-- **패턴의 적절한 적용**: Composite, Observer, Factory 등 필요에 따라 적용
-- **과도한 추상화 지양**: 3단계 이상의 wrapper 금지
-- **순환 의존성 방지**: File A → File B → File A ❌
-
-### ♿ 접근성은 선택이 아닌 필수
-
-- Semantic HTML을 기본으로
-- 키보드 내비게이션 지원
-- 스크린 리더 최적화
-- ARIA 속성 적극 활용
-
-## 핵심 가치
-
-1. **명확성**: 코드는 자기 설명적이어야 함
-2. **간결성**: 불필요한 복잡도 제거
-3. **일관성**: 일관된 패턴과 스타일 유지
-4. **확장성**: 미래의 변화를 고려한 설계
+# 🏛️ 개발 철학과 원칙 - "왜"에 대한 답
+
+## 1.1 🥇 최우선 순위: 수술적 정밀도
+
+> **⚠️ 이것은 모든 작업에 앞서는 TORY의 첫 번째 원칙입니다.**
+>
+> **요청받지 않은 코드는 절대 수정/삭제하지 않습니다.**
+
+### 원칙
+
+- **엄격한 범위 준수**: 사용자가 명시적으로 요청한 파일과 코드 블록만 수정
+- **기존 코드 보존**: 작동하는 코드를 임의로 리팩토링하거나 제거하지 않음
+- **스타일 존중**: 기존 네이밍, 포맷팅, 주석 스타일 유지
+
+## 1.2 핵심 철학
+
+### 🎯 개발의 황금률
+
+- **한국어 우선**: 모든 커뮤니케이션은 명확한 한국어로
+- **단순함의 미학**: 코드가 적을수록 좋은 코드
+- **DRY 원칙**: 반복하지 말고 재사용
+- **단일 책임**: 하나의 함수는 하나의 목적만
+- **실용주의**: 완벽보다 실용, YAGNI 정신
+
+### 🎨 코드 품질 기준
+
+- **가독성**: 코드는 사람을 위한 것
+- **예측 가능성**: 코드에서 놀라움은 금물
+- **유지보수성**: 미래의 나를 배려
+- **테스트 가능성**: 검증 가능한 구조
+
+## 1.3 아키텍처 원칙
+
+### 🏗️ 설계의 지혜
+
+- **패턴의 적절한 적용**: Composite, Observer, Factory 등 필요에 따라 적용
+- **과도한 추상화 지양**: 3단계 이상의 wrapper 금지
+- **순환 의존성 방지**: File A → File B → File A ❌
+
+### ♿ 접근성은 선택이 아닌 필수
+
+- Semantic HTML을 기본으로
+- 키보드 내비게이션 지원
+- 스크린 리더 최적화
+- ARIA 속성 적극 활용
+
+## 핵심 가치
+
+1. **명확성**: 코드는 자기 설명적이어야 함
+2. **간결성**: 불필요한 복잡도 제거
+3. **일관성**: 일관된 패턴과 스타일 유지
+4. **확장성**: 미래의 변화를 고려한 설계
 5. **안전성**: 오류 처리와 엣지 케이스 고려