@su-record/vibe 0.4.8 → 1.0.0

package/.claude/agents/explorer.md

@@ -0,0 +1,48 @@
+# Explorer Agent (Haiku 4.5)
+
+코드베이스 탐색 전문 서브에이전트입니다.
+
+## Role
+
+- 코드베이스 분석
+- 파일/패턴 검색
+- 의존성 확인
+- 관련 코드 수집
+
+## Model
+
+**Haiku 4.5** - 빠른 탐색에 최적화
+
+## Usage
+
+Task 도구로 호출:
+```
+Task(model: "haiku", subagent_type: "Explore")
+```
+
+## Process
+
+1. 프로젝트 구조 파악
+2. 관련 파일 검색 (Glob, Grep)
+3. 코드 읽기 및 분석
+4. 패턴/컨벤션 파악
+5. 결과 요약 반환
+
+## Output
+
+```markdown
+## 탐색 결과
+
+### 관련 파일
+- src/components/Button.tsx (UI 컴포넌트)
+- src/hooks/useAuth.ts (인증 훅)
+
+### 발견된 패턴
+- 컴포넌트: 함수형 + TypeScript
+- 상태관리: Zustand 사용
+- 스타일: Tailwind CSS
+
+### 의존성
+- react: ^18.2.0
+- zustand: ^4.4.0
+```

package/.claude/agents/implementer.md

@@ -0,0 +1,53 @@
+# Implementer Agent (Sonnet 4)
+
+핵심 구현 전문 서브에이전트입니다.
+
+## Role
+
+- 코드 구현
+- 파일 생성/수정
+- 리팩토링
+- 버그 수정
+
+## Model
+
+**Sonnet 4** - 구현 품질과 속도의 균형
+
+## Usage
+
+Task 도구로 호출:
+```
+Task(model: "sonnet", prompt: "SPEC에 따라 구현하세요")
+```
+
+## Rules Reference
+
+반드시 `.vibe/rules/` 규칙을 따릅니다:
+- `core/development-philosophy.md` - 수술적 정밀도
+- `standards/complexity-metrics.md` - 함수 ≤20줄, 중첩 ≤3단계
+- `quality/checklist.md` - 품질 체크리스트
+
+## Process
+
+1. SPEC 및 탐색 결과 확인
+2. 구현 계획 수립
+3. 코드 작성 (Edit/Write)
+4. 자체 검증
+5. 결과 반환
+
+## Output
+
+```markdown
+## 구현 결과
+
+### 생성된 파일
+- src/components/LoginForm.tsx ✅
+- src/hooks/useLogin.ts ✅
+
+### 수정된 파일
+- src/App.tsx (라우트 추가)
+
+### 검증
+- TypeScript 컴파일: ✅
+- 린트: ✅
+```

package/.claude/agents/tester.md

@@ -0,0 +1,49 @@
+# Tester Agent (Haiku 4.5)
+
+테스트 작성 전문 서브에이전트입니다.
+
+## Role
+
+- 테스트 코드 작성
+- BDD Feature 기반 테스트
+- 엣지 케이스 검증
+- 테스트 실행
+
+## Model
+
+**Haiku 4.5** - 빠른 테스트 생성
+
+## Usage
+
+Task 도구로 호출:
+```
+Task(model: "haiku", prompt: "구현된 코드의 테스트를 작성하세요")
+```
+
+## Process
+
+1. `.vibe/features/{기능명}.feature` 확인
+2. 구현된 코드 분석
+3. 테스트 케이스 작성
+4. 테스트 실행
+5. 결과 반환
+
+## Output
+
+```markdown
+## 테스트 결과
+
+### 생성된 테스트
+- src/__tests__/LoginForm.test.tsx
+- src/__tests__/useLogin.test.ts
+
+### 커버리지
+- Statements: 85%
+- Branches: 80%
+- Functions: 90%
+
+### 실행 결과
+✅ 12 passed
+⏭️ 0 skipped
+❌ 0 failed
+```

package/.claude/commands/vibe.run.md

@@ -5,7 +5,7 @@ argument-hint: "feature name" or --phase N
 
 # /vibe.run
 
-SPEC을 기반으로 구현합니다 (Implementation Agent).
+SPEC을 기반으로 구현합니다 (Implementation Agent with Multi-Model Orchestration).
 
 ## Usage
 
@@ -28,9 +28,92 @@ PTCF 구조의 SPEC 문서를 읽고 바로 구현을 실행합니다.
 
 > **PLAN, TASKS 문서 불필요** - SPEC이 곧 실행 가능한 프롬프트
 
+## 모델 오케스트레이션
+
+작업 유형에 따라 최적의 모델을 자동 선택합니다:
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│               Opus 4.5 (오케스트레이터)                       │
+│               - 전체 흐름 조율                                │
+│               - 최종 결정/검토                                │
+└─────────────────────────┬───────────────────────────────────┘
+                          │
+    ┌─────────────────────┼─────────────────────┐
+    ↓                     ↓                     ↓
+┌─────────┐         ┌─────────┐         ┌─────────┐
+│ Haiku   │         │ Sonnet  │         │ Haiku   │
+│ (탐색)  │         │ (구현)  │         │(테스트) │
+└─────────┘         └─────────┘         └─────────┘
+```
+
+### 역할별 Task 호출
+
+| 작업 유형 | 모델 | Task 파라미터 |
+|----------|------|---------------|
+| 코드베이스 탐색 | Haiku 4.5 | `model: "haiku"` |
+| 핵심 구현 | Sonnet 4 | `model: "sonnet"` |
+| 테스트 작성 | Haiku 4.5 | `model: "haiku"` |
+| 아키텍처 결정 | Opus 4.5 | 메인 세션 |
+| 최종 검토 | Opus 4.5 | 메인 세션 |
+
+### 외부 LLM 활용 (활성화 시)
+
+`.vibe/config.json`에서 외부 LLM이 활성화된 경우:
+
+| 역할 | 모델 | 조건 |
+|------|------|------|
+| 아키텍처/디버깅 | GPT 5.2 | `vibe gpt <key>` 실행 시 |
+| UI/UX 설계 | Gemini 3 | `vibe gemini <key>` 실행 시 |
+
+외부 LLM 활성화 시 해당 역할은 MCP를 통해 자동 호출됩니다:
+- `mcp__vibe-gpt__chat` - GPT 5.2 아키텍처 자문
+- `mcp__vibe-gemini__chat` - Gemini 3 UI/UX 자문
+
+## 시맨틱 코드 분석 (hi-ai MCP)
+
+구현 전 코드베이스를 정확히 파악하기 위해 hi-ai MCP의 시맨틱 도구를 활용합니다:
+
+| MCP 도구 | 용도 | 활용 시점 |
+|----------|------|----------|
+| `mcp__vibe__find_symbol` | 심볼 정의 찾기 | 클래스/함수 위치 파악 |
+| `mcp__vibe__find_references` | 참조 찾기 | 영향 범위 분석 |
+| `mcp__vibe__analyze_complexity` | 복잡도 분석 | 리팩토링 필요 여부 판단 |
+| `mcp__vibe__validate_code_quality` | 품질 검증 | 구현 후 품질 확인 |
+
+### 시맨틱 분석 흐름
+
+```
+구현 시작
+    │
+    ├─→ find_symbol: 수정할 함수/클래스 정확한 위치 파악
+    │
+    ├─→ find_references: 해당 심볼을 사용하는 모든 곳 확인
+    │
+    ├─→ analyze_complexity: 기존 코드 복잡도 확인
+    │
+    ↓
+구현 (영향 범위를 정확히 파악한 상태에서)
+    │
+    ↓
+validate_code_quality: 구현 후 품질 검증
+```
+
+### 컨텍스트 관리 (세션 연속성)
+
+| MCP 도구 | 용도 |
+|----------|------|
+| `mcp__vibe__start_session` | 세션 시작, 이전 컨텍스트 복원 |
+| `mcp__vibe__auto_save_context` | 현재 상태 자동 저장 |
+| `mcp__vibe__restore_session_context` | 이전 세션 컨텍스트 복원 |
+| `mcp__vibe__save_memory` | 중요 결정사항/패턴 저장 |
+
+**세션 시작 시**: `mcp__vibe__start_session`으로 이전 컨텍스트 자동 복원
+**세션 종료 시**: Hook이 `mcp__vibe__auto_save_context` 자동 실행
+
 ## Process
 
-### 1. SPEC 읽기
+### 1. SPEC 및 설정 읽기
 
 `.vibe/specs/{기능명}.md` 파싱:
 
@@ -43,18 +126,60 @@ PTCF 구조의 SPEC 문서를 읽고 바로 구현을 실행합니다.
 | `<output_format>` | 생성/수정할 파일 |
 | `<acceptance>` | 검증 기준 |
 
+`.vibe/config.json` 확인:
+- 외부 LLM 활성화 여부 (`models.gpt.enabled`, `models.gemini.enabled`)
+
 ### 2. Feature 파일 확인
 
 `.vibe/features/{기능명}.feature`:
 - BDD Scenarios 확인
 - 테스트 케이스로 활용
 
-### 3. Phase별 구현
+### 3. Phase별 구현 (Task 병렬 호출)
 
 `<task>` 섹션의 Phase 순서대로:
 
-1. **관련 코드 분석**: `<context>`의 관련 코드 읽기
-2. **파일 생성/수정**: `<output_format>` 기준
+```
+Phase 시작
+    │
+    ├─→ Task(haiku): 코드베이스 분석
+    │       "관련 파일과 패턴을 분석하세요"
+    │
+    ├─→ [GPT 활성화 시] MCP(vibe-gpt): 아키텍처 검토
+    │       "이 설계가 적절한지 검토해주세요"
+    │
+    ├─→ [Gemini 활성화 시] MCP(vibe-gemini): UI/UX 자문
+    │       "UI 구현 방향을 제안해주세요"
+    │
+    ↓
+Opus: 분석 결과 종합, 구현 방향 결정
+    │
+    ↓
+Task(sonnet): 핵심 구현
+    "SPEC에 따라 코드를 구현하세요"
+    │
+    ↓
+Task(haiku): 테스트 작성
+    "구현된 코드의 테스트를 작성하세요"
+    │
+    ↓
+Opus: 최종 검토 및 다음 Phase
+```
+
+**병렬 실행 예시:**
+```javascript
+// 독립적인 작업은 병렬로 Task 호출
+Task(haiku) - 코드 분석
+Task(haiku) - 의존성 확인
+// → 동시 실행
+
+// 순차적 작업
+Task(sonnet) - 구현 (분석 완료 후)
+Task(haiku) - 테스트 (구현 완료 후)
+```
+
+1. **관련 코드 분석**: Task(haiku)로 `<context>`의 관련 코드 탐색
+2. **파일 생성/수정**: Task(sonnet)로 `<output_format>` 기준 구현
 3. **제약 조건 준수**: `<constraints>` 확인
 4. **검증 실행**: 검증 명령어 실행
 

package/.claude/commands/vibe.spec.md

@@ -26,6 +26,34 @@ SPEC 문서를 작성합니다 (Specification Agent).
 
 > **PTCF**: Persona, Task, Context, Format - Google Gemini 프롬프트 최적화 프레임워크
 
+## 외부 LLM 연동 (선택적)
+
+`.vibe/config.json`에서 외부 LLM이 활성화된 경우 SPEC 작성 시 자동 활용:
+
+```
+/vibe.spec "복잡한 기능"
+      ↓
+[Claude Opus] SPEC 초안 작성
+      ↓
+[GPT 활성화?] → MCP(vibe-gpt)로 설계 교차 검토
+      ↓
+[Gemini 활성화?] → MCP(vibe-gemini)로 UI/UX 자문
+      ↓
+[Claude] 최종 SPEC 확정
+```
+
+| 외부 LLM | 역할 | 활용 시점 |
+|----------|------|----------|
+| GPT 5.2 | 아키텍처/설계 검토 | SPEC 초안 완성 후 |
+| Gemini 3 | UI/UX 자문 | 디자인 레퍼런스 논의 시 |
+
+**활성화 방법:**
+```bash
+vibe gpt <api-key>      # GPT 활성화
+vibe gemini <api-key>   # Gemini 활성화
+vibe status             # 현재 설정 확인
+```
+
 ## Process
 
 ### 1. 프로젝트 분석
@@ -134,11 +162,45 @@ SPEC 문서를 작성합니다 (Specification Agent).
 </acceptance>
 ```
 
-### 4. Feature 파일 생성 (BDD)
+### 4. Feature 파일 생성 (BDD) - 필수
+
+**반드시** `.vibe/features/{기능명}.feature` 파일을 생성합니다.
 
-`.vibe/features/{기능명}.feature` 생성:
-- SPEC의 Acceptance Criteria를 Scenario로 변환
-- Given-When-Then 형식
+**생성 규칙:**
+1. SPEC의 각 Acceptance Criteria → 하나의 Scenario로 변환
+2. Happy Path (정상 케이스) + Edge Case (예외 케이스) 포함
+3. Given-When-Then 형식 준수
+
+**Feature 구조:**
+```markdown
+# Feature: {기능명}
+
+**SPEC**: `.vibe/specs/{기능명}.md`
+
+## User Story
+**As a** {사용자}
+**I want** {기능}
+**So that** {가치}
+
+## Scenarios
+
+### Scenario 1: {Happy Path}
+\`\`\`gherkin
+Scenario: {제목}
+  Given {전제}
+  When {행동}
+  Then {결과}
+\`\`\`
+**검증 기준**: SPEC AC #1
+
+### Scenario 2: {Edge Case}
+...
+
+## Coverage
+| Scenario | SPEC AC | Status |
+|----------|---------|--------|
+| 1 | AC-1 | ⬜ |
+```
 
 ### 5. 품질 검증
 

package/.claude/commands/vibe.verify.md

@@ -5,7 +5,7 @@ argument-hint: "feature name"
 
 # /vibe.verify
 
-구현된 코드를 SPEC 요구사항에 대해 검증합니다.
+Feature 시나리오 기반으로 구현을 검증합니다.
 
 ## Usage
 
@@ -16,145 +16,133 @@ argument-hint: "feature name"
 ## Rules Reference
 
 **반드시 `.vibe/rules/` 규칙을 따릅니다:**
-- `quality/checklist.md` - 코드 품질 체크리스트 (필수)
+- `quality/checklist.md` - 코드 품질 체크리스트
 - `standards/complexity-metrics.md` - 복잡도 기준
-- `standards/anti-patterns.md` - 안티패턴 검출
 
-## Description
+## Process
 
-SPEC 문서의 모든 요구사항(REQ-001~N)과 비기능 요구사항(NFR)을 구현된 코드가 만족하는지 검증합니다.
+### 1. Feature 파일 로드
 
-## Process
+`.vibe/features/{기능명}.feature` 읽기
+
+### 2. 시나리오별 검증
+
+각 Scenario에 대해:
+
+1. **Given** (전제 조건) - 상태 확인
+2. **When** (행동) - 기능 실행
+3. **Then** (결과) - 예상 결과 검증
+
+### 3. 검증 방법
+
+**코드 검증:**
+- 해당 기능이 구현되어 있는지 확인
+- Given/When/Then 각 단계가 동작하는지 확인
+
+**테스트 실행 (있는 경우):**
+- `npm test`, `pytest`, `flutter test` 등 실행
+- BDD 테스트 프레임워크 결과 확인
 
-1. **SPEC 문서 읽기**: `.vibe/specs/{기능명}.md`
-2. **Feature 파일 읽기**: `.vibe/features/{기능명}.feature` (BDD Scenarios)
-3. **TASKS 문서 확인**: 모든 Task가 ✅ 완료 상태인지 확인
-4. **BDD Scenarios 검증**:
-   - Feature 파일의 모든 Scenario 실행
-   - Given-When-Then 각 단계 검증
-   - Step Definitions 실행 결과 확인
-5. **Contract Testing 검증**:
-   - Provider Contract 검증 (Backend)
-   - Consumer Contract 검증 (Frontend)
-   - Contract 일치 여부 확인 (Pact Broker)
-6. **요구사항별 검증**:
-   - REQ-001: 6개 알림 카테고리 정의 → DB 스키마 확인
-   - REQ-002: 설정 저장 (P95 < 500ms) → 성능 테스트
-   - REQ-003: 설정 조회 (P95 < 300ms) → 성능 테스트
-   - REQ-004: 알림 필터링 동작 → 통합 테스트
-   - REQ-005: 기본 설정 생성 → 유닛 테스트
-   - REQ-006: UI 피드백 → 위젯 테스트
-7. **비기능 요구사항 검증**:
-   - 성능 (Performance): Locust로 부하 테스트
-   - 보안 (Security): JWT 인증 확인
-   - 접근성 (Accessibility): WCAG AA 기준
-8. **검증 리포트 생성**: `.vibe/reports/{기능명}-verification.md`
-
-## Agent
-
-Quality Reviewer Agent
+**수동 검증:**
+- 테스트 코드가 없으면 코드 리뷰로 검증
+- 각 시나리오의 로직이 구현되었는지 확인
+
+### 4. 결과 리포트
+
+```markdown
+# Verification Report: {기능명}
+
+## Summary
+- **총 시나리오**: N개
+- **통과**: N개 ✅
+- **실패**: N개 ❌
+- **품질 점수**: XX/100
+
+## Scenario Results
+
+### ✅ Scenario 1: {제목}
+- Given: 확인됨
+- When: 구현됨
+- Then: 동작함
+- **검증**: AC-1 충족
+
+### ❌ Scenario 2: {제목}
+- Given: 확인됨
+- When: 구현됨
+- Then: **실패** - {이유}
+- **수정 필요**: {구체적 내용}
+
+## Code Quality
+- 복잡도: ✅ 적정
+- 테스트 커버리지: XX%
+- 에러 처리: ✅
+
+## Next Steps
+- {실패한 시나리오 수정 방법}
+```
 
 ## Input
 
-- `.vibe/specs/{기능명}.md` (SPEC 문서)
-- `.vibe/features/{기능명}.feature` (BDD Feature 파일)
-- `.vibe/tasks/{기능명}.md` (TASKS 문서)
-- 구현된 코드 (backend/, frontend/)
-- BDD Step Definitions (tests/steps/, test/bdd/)
-- Contract 파일 (pacts/, contracts/)
+- `.vibe/features/{기능명}.feature` - BDD 시나리오
+- `.vibe/specs/{기능명}.md` - SPEC 문서 (참조)
+- 구현된 소스 코드
 
 ## Output
 
-- `.vibe/reports/{기능명}-verification.md` - 검증 리포트
-- 통과/실패 요구사항 목록
-- 성능 테스트 결과
-- 개선 제안 사항
-
-## Verification Checklist
-
-### Functional Requirements
-- [ ] REQ-001: 6개 알림 카테고리 정의
-- [ ] REQ-002: 설정 저장 (P95 < 500ms)
-- [ ] REQ-003: 설정 조회 (P95 < 300ms)
-- [ ] REQ-004: 알림 필터링 동작
-- [ ] REQ-005: 기본 설정 생성
-- [ ] REQ-006: UI 피드백
-
-### Non-Functional Requirements
-- [ ] 성능: P95 응답 시간 목표 달성
-- [ ] 보안: JWT 인증, 권한 검증
-- [ ] 접근성: WCAG AA 기준 (4.5:1 대비, 48x48dp 터치)
-- [ ] 확장성: 새 카테고리 추가 용이
-- [ ] 가용성: 99.9% uptime
-
-### Code Quality (TRUST 5)
-- [ ] Test-first: Contract tests 작성
-- [ ] Readable: Docstring, Type hints
-- [ ] Unified: 일관된 스타일
-- [ ] Secured: 보안 고려
-- [ ] Trackable: Logging, Monitoring
-
-### Tests
-- [ ] **BDD Scenarios 모두 통과** (pytest-bdd, behave, cucumber)
-- [ ] **Contract Tests 모두 통과** (Pact, Spring Cloud Contract)
-- [ ] 유닛 테스트 커버리지 > 80%
-- [ ] 통합 테스트 통과
-- [ ] E2E 테스트 통과 (실제 푸시 수신)
-- [ ] 성능 테스트 통과 (Locust)
+- 검증 결과 리포트 (터미널 출력)
+- 통과/실패 시나리오 목록
+- 수정이 필요한 항목
 
 ## Example
 
 ```
-/vibe.verify "푸시 알림 설정 기능"
-```
+User: /vibe.verify "로그인"
 
-**결과:**
-```markdown
-# Verification Report: 푸시 알림 설정 기능
+Claude:
+# Verification Report: 로그인
 
 ## Summary
-- **전체 요구사항**: 12개
-- **통과**: 12개 ✅
-- **실패**: 0개
-- **품질 점수**: 95/100 (A+)
-
-## BDD Scenarios (5/5 통과)
-✅ Scenario 1: 알림 설정 조회
-✅ Scenario 2: 알림 카테고리 활성화
-✅ Scenario 3: 알림 카테고리 비활성화
-✅ Scenario 4: 기본 설정 생성
-✅ Scenario 5: 설정 저장 응답 시간 검증
-
-## Contract Tests (2/2 통과)
-✅ Provider Contract: Backend API 스키마 검증
-✅ Consumer Contract: Frontend 호출 규약 검증
-
-## Functional Requirements (6/6 통과)
-✅ REQ-001: 6개 알림 카테고리 정의
-✅ REQ-002: 설정 저장 (P95: 420ms < 500ms)
-✅ REQ-003: 설정 조회 (P95: 280ms < 300ms)
-✅ REQ-004: 알림 필터링 동작
-✅ REQ-005: 기본 설정 생성
-✅ REQ-006: UI 피드백
-
-## Non-Functional Requirements (4/4 통과)
-✅ 성능: P95 < 500ms
-✅ 보안: JWT 인증 적용
-✅ 접근성: WCAG AA 준수
-✅ 테스트 커버리지: 85%
-
-## 개선 제안
-- 캐시 히트율 80% 달성 (현재 75%)
+- **총 시나리오**: 4개
+- **통과**: 3개 ✅
+- **실패**: 1개 ❌
+- **품질 점수**: 85/100
+
+## Scenario Results
+
+### ✅ Scenario 1: 유효한 자격증명으로 로그인
+- Given: 사용자가 로그인 페이지에 있다 → ✅ LoginPage 컴포넌트 존재
+- When: 유효한 이메일/비밀번호 입력 → ✅ handleSubmit 구현됨
+- Then: 대시보드로 이동 → ✅ router.push('/dashboard')
+
+### ✅ Scenario 2: 잘못된 비밀번호로 로그인 시도
+- Given: 로그인 페이지 → ✅
+- When: 잘못된 비밀번호 → ✅
+- Then: 에러 메시지 표시 → ✅ "비밀번호가 일치하지 않습니다"
+
+### ✅ Scenario 3: 이메일 형식 검증
+- Given: 로그인 페이지 → ✅
+- When: 잘못된 이메일 형식 → ✅
+- Then: 유효성 에러 → ✅ zod validation
+
+### ❌ Scenario 4: 비밀번호 찾기 링크
+- Given: 로그인 페이지 → ✅
+- When: "비밀번호 찾기" 클릭 → ❌ 링크 없음
+- Then: 비밀번호 찾기 페이지로 이동 → ❌
+
+## Next Steps
+Scenario 4 수정 필요:
+- LoginPage에 "비밀번호 찾기" 링크 추가
+- /forgot-password 라우트 구현
 ```
 
 ## Next Step
 
 검증 통과 시:
 ```
-vibe deploy "푸시 알림 설정 기능"  # Staging 배포
+완료! 다음 기능을 진행하세요.
 ```
 
 검증 실패 시:
 ```
-/vibe.run "Task X-Y"  # 실패한 Task 재구현
+/vibe.run "기능명" --fix  # 실패한 시나리오 수정
 ```

package/.claude/{settings.local.json → settings.json}

@@ -42,7 +42,9 @@
       "Bash(gh release:*)",
       "Bash(npx @su-record/vibe@latest init:*)",
       "Bash(vibe version:*)",
-      "Bash(vibe update:*)"
+      "Bash(vibe update:*)",
+      "Bash(vibe status:*)",
+      "Bash(git rm:*)"
     ],
     "deny": [],
     "ask": []