@su-record/vibe 0.1.7 → 0.2.0

package/.claude/commands/vibe.plan.md

@@ -20,10 +20,11 @@ SPEC 문서를 분석하여 기술 구현 계획(PLAN)을 작성합니다.
 ## Process
 
 1. **SPEC 문서 읽기**: `.vibe/specs/{기능명}.md` 분석
-2. **프로젝트 컨텍스트 파악**:
+2. **Feature 파일 읽기**: `.vibe/features/{기능명}.feature` 확인 (BDD)
+3. **프로젝트 컨텍스트 파악**:
    - `CLAUDE.md` 읽기 (기술 스택 확인)
    - `package.json` / `pyproject.toml` / `pubspec.yaml` 확인
-3. **PLAN 문서 작성**: 15개 섹션 포함
+4. **PLAN 문서 작성**: 15개 섹션 포함
    - 기술 스택 선정 (기존 스택 재사용 우선)
    - 아키텍처 설계
    - API 설계
@@ -33,13 +34,17 @@ SPEC 문서를 분석하여 기술 구현 계획(PLAN)을 작성합니다.
    - 성능 최적화
    - 에러 처리
    - 모니터링 및 로깅
-   - 테스트 전략
+   - **테스트 전략 (BDD/Contract Testing 포함)**
+     - BDD 도구 선정 (pytest-bdd, behave, cucumber 등)
+     - Contract Testing 도구 (Pact, Spring Cloud Contract 등)
+     - Feature 파일과 SPEC 매핑
+     - API Contract 스키마 정의
    - 배포 전략
    - 비용 예측
    - 마일스톤 (Phase별)
    - 리스크 및 완화 방안
    - 다음 단계
-4. **품질 검증**: 기술 선택 근거, 비용, 일정 현실성
+5. **품질 검증**: 기술 선택 근거, 비용, 일정 현실성, BDD 테스트 전략 타당성
 
 ## Agent
 
@@ -48,6 +53,7 @@ SPEC 문서를 분석하여 기술 구현 계획(PLAN)을 작성합니다.
 ## Input
 
 - `.vibe/specs/{기능명}.md` (SPEC 문서)
+- `.vibe/features/{기능명}.feature` (BDD Feature 파일)
 - `CLAUDE.md` (프로젝트 기술 스택)
 
 ## Output

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

@@ -46,7 +46,10 @@ TASKS 문서의 특정 Task를 읽고 구현 가이드를 생성한 후, 실제
   - Backend Python Expert: `~/.vibe/agents/backend-python-expert.md`
   - Frontend Flutter Expert: `~/.vibe/agents/frontend-flutter-expert.md`
 - TRUST 5 원칙 준수:
-  - Test-first (Contract Testing)
+  - **Test-first (BDD/Contract Testing 우선)**
+    - Contract 파일 먼저 작성 (Provider/Consumer)
+    - BDD Step Definitions 작성
+    - Unit Tests 작성
   - Readable (명확한 코드)
   - Unified (일관된 스타일)
   - Secured (보안 고려)
@@ -66,16 +69,19 @@ TASKS 문서의 특정 Task를 읽고 구현 가이드를 생성한 후, 실제
 
 | Task | Agent |
 |------|-------|
-| Task 1-1 ~ 1-8 (Backend) | Backend Python Expert |
-| Task 2-1 ~ 2-8 (Frontend) | Frontend Flutter Expert |
+| Task 1-1 ~ 1-9 (Backend + Contract Provider) | Backend Python Expert |
+| Task 2-1 ~ 2-9 (Frontend + Contract Consumer) | Frontend Flutter Expert |
 | Task 3-1 ~ 3-2 (FCM Backend) | Backend Python Expert |
-| Task 3-3 (E2E Test) | QA / Frontend Flutter Expert |
+| Task 3-3 (BDD Step Definitions) | QA / Backend/Frontend Expert |
+| Task 3-4 (Contract Verification) | QA |
+| Task 3-5 (E2E Test) | QA / Frontend Flutter Expert |
 
 ## Input
 
 - `.vibe/tasks/{기능명}.md` (TASKS 문서)
 - `.vibe/plans/{기능명}.md` (PLAN 참고)
 - `.vibe/specs/{기능명}.md` (SPEC 참고)
+- `.vibe/features/{기능명}.feature` (BDD Feature 파일 - Contract Test 매핑용)
 
 ## Output
 
@@ -109,8 +115,8 @@ TASKS 문서의 특정 Task를 읽고 구현 가이드를 생성한 후, 실제
 ```
 
 **동작:**
-- Phase 1의 8개 Task 순차 실행
-- Task 1-1 → 1-2 → ... → 1-8
+- Phase 1의 9개 Task 순차 실행
+- Task 1-1 → 1-2 → ... → 1-9 (Contract Provider 포함)
 - 각 Task마다 의존성 확인 후 실행
 
 ### 전체 실행
@@ -120,9 +126,10 @@ TASKS 문서의 특정 Task를 읽고 구현 가이드를 생성한 후, 실제
 ```
 
 **동작:**
-- 의존성 그래프에 따라 19개 Task 순차 실행
-- Phase 1 (8개) → Phase 2 (8개) → Phase 3 (3개)
-- 예상 시간: 24시간
+- 의존성 그래프에 따라 23개 Task 순차 실행
+- Phase 1 (9개) → Phase 2 (9개) → Phase 3 (5개)
+- BDD/Contract Testing 포함
+- 예상 시간: 28시간
 
 ## Verification
 

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

@@ -70,7 +70,13 @@ SPEC 문서를 작성합니다 (Specification Agent).
 
 3. **SPEC 문서 작성**: `.vibe/specs/{기능명}.md` 생성 (EARS 형식)
 
-4. **품질 검증**: TRUST 5 기준 자체 평가
+4. **Gherkin Feature 파일 생성** (BDD):
+   - `.vibe/features/{기능명}.feature` 생성
+   - SPEC의 각 요구사항(REQ-XXX)을 Scenario로 변환
+   - Given-When-Then 형식으로 작성
+   - Acceptance Criteria를 테스트 케이스로 변환
+
+5. **품질 검증**: TRUST 5 기준 자체 평가
 
 ## Agent
 
@@ -79,6 +85,7 @@ SPEC 문서를 작성합니다 (Specification Agent).
 ## Output
 
 - `.vibe/specs/{기능명}.md` - SPEC 문서 (EARS 형식)
+- `.vibe/features/{기능명}.feature` - Gherkin Feature 파일 (BDD)
 - 품질 점수 (0-100점)
 - 개선 제안 사항
 

package/.claude/commands/vibe.tasks.md

@@ -20,11 +20,12 @@ PLAN 문서를 분석하여 Phase별 구체적인 작업 목록(TASKS)을 생성
 ## Process
 
 1. **PLAN 문서 읽기**: `.vibe/plans/{기능명}.md` 분석
-2. **Phase별 Task 분해**:
-   - Phase 1: Backend 개발 (DB, API, Service, Repository, Tests)
-   - Phase 2: Frontend 개발 (Model, Service, Proviber, UI, Tests)
-   - Phase 3: 통합 및 테스트 (FCM, E2E)
-3. **각 Task마다 정의**:
+2. **Feature 파일 읽기**: `.vibe/features/{기능명}.feature` 확인 (BDD Scenarios)
+3. **Phase별 Task 분해**:
+   - Phase 1: Backend 개발 (DB, API, Service, Repository, Unit Tests, **Contract Provider**)
+   - Phase 2: Frontend 개발 (Model, Service, Provider, UI, Unit Tests, **Contract Consumer**)
+   - Phase 3: 통합 및 테스트 (FCM, E2E, **BDD Step Definitions**, **Contract Verification**)
+4. **각 Task마다 정의**:
    - 상태 (⬜ 대기 / 🟡 진행 중 / ✅ 완료)
    - 담당 Agent
    - 예상 시간
@@ -44,6 +45,7 @@ PLAN 문서를 분석하여 Phase별 구체적인 작업 목록(TASKS)을 생성
 
 - `.vibe/plans/{기능명}.md` (PLAN 문서)
 - `.vibe/specs/{기능명}.md` (SPEC 문서)
+- `.vibe/features/{기능명}.feature` (BDD Feature 파일)
 
 ## Output
 
@@ -59,9 +61,13 @@ PLAN 문서를 분석하여 Phase별 구체적인 작업 목록(TASKS)을 생성
 ```
 
 **결과:**
-- 19개 Task (Phase 1: 8개, Phase 2: 8개, Phase 3: 3개)
+- 23개 Task (Phase 1: 9개, Phase 2: 9개, Phase 3: 5개)
+  - **Phase 1:** DB, API, Service, Repository, Unit Tests, **Contract Provider 정의**
+  - **Phase 2:** Model, Service, Provider, UI, Unit Tests, **Contract Consumer 정의**
+  - **Phase 3:** FCM, E2E, **BDD Step Definitions**, **Contract Verification**
 - 의존성 그래프 포함
 - 각 Task별 Acceptance Criteria
+- BDD Scenarios와 매핑된 Contract Test Tasks
 
 ## Next Step
 

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

@@ -20,19 +20,28 @@ SPEC 문서의 모든 요구사항(REQ-001~N)과 비기능 요구사항(NFR)을
 ## Process
 
 1. **SPEC 문서 읽기**: `.vibe/specs/{기능명}.md`
-2. **TASKS 문서 확인**: 모든 Task가 ✅ 완료 상태인지 확인
-3. **요구사항별 검증**:
+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 피드백 → 위젯 테스트
-4. **비기능 요구사항 검증**:
+7. **비기능 요구사항 검증**:
    - 성능 (Performance): Locust로 부하 테스트
    - 보안 (Security): JWT 인증 확인
    - 접근성 (Accessibility): WCAG AA 기준
-5. **검증 리포트 생성**: `.vibe/reports/{기능명}-verification.md`
+8. **검증 리포트 생성**: `.vibe/reports/{기능명}-verification.md`
 
 ## Agent
 
@@ -41,8 +50,11 @@ Quality Reviewer Agent
 ## 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/)
 
 ## Output
 
@@ -76,6 +88,8 @@ Quality Reviewer Agent
 - [ ] Trackable: Logging, Monitoring
 
 ### Tests
+- [ ] **BDD Scenarios 모두 통과** (pytest-bdd, behave, cucumber)
+- [ ] **Contract Tests 모두 통과** (Pact, Spring Cloud Contract)
 - [ ] 유닛 테스트 커버리지 > 80%
 - [ ] 통합 테스트 통과
 - [ ] E2E 테스트 통과 (실제 푸시 수신)
@@ -97,6 +111,17 @@ Quality Reviewer Agent
 - **실패**: 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)

package/.claude/settings.local.json

@@ -6,7 +6,12 @@
       "Bash(sed:*)",
       "Bash(git add:*)",
       "Bash(git commit:*)",
-      "Bash(npm publish:*)"
+      "Bash(npm publish:*)",
+      "Bash(git push:*)",
+      "Bash(npm pack)",
+      "Bash(npm install:*)",
+      "Read(//private/tmp/test-vibe-bdd/.vibe/**)",
+      "Read(//private/tmp/test-vibe-bdd/.claude/commands/**)"
     ],
     "deny": [],
     "ask": []

package/README.md

@@ -247,9 +247,10 @@ $ vibe init
   .vibe/
   ├── config.json
   ├── constitution.md
-  ├── specs/
-  ├── plans/
-  └── tasks/
+  ├── specs/          # SPEC documents (EARS format)
+  ├── features/       # BDD Feature files (Gherkin)
+  ├── plans/          # Technical plans
+  └── tasks/          # Task breakdowns
 ```
 
 ### 2. Create Specification (Claude Code)
@@ -311,6 +312,7 @@ User: 1
 
 ✅ SPEC document created!
 📄 .vibe/specs/push-notification-settings.md
+📄 .vibe/features/push-notification-settings.feature (BDD scenarios)
 ```
 
 ### 3. Generate Plan (Claude Code)
@@ -326,8 +328,9 @@ SPEC을 분석하여 기술 계획을 작성하겠습니다.
 
 Summary:
 - 3 Phases: Backend → Frontend → FCM Integration
-- Timeline: 24 hours (3 days)
+- Timeline: 28 hours (3.5 days)
 - Cost: +$0.50/month (Redis + FCM)
+- Testing: BDD (pytest-bdd) + Contract Testing (Pact)
 ```
 
 ### 4. Decompose Tasks (Claude Code)
@@ -342,10 +345,10 @@ PLAN을 기반으로 Task를 생성하겠습니다.
 📄 .vibe/tasks/push-notification-settings.md
 
 Task Breakdown:
-- Total: 19 tasks
-- Phase 1 (Backend): 8 tasks
-- Phase 2 (Frontend): 8 tasks
-- Phase 3 (FCM): 3 tasks
+- Total: 23 tasks
+- Phase 1 (Backend): 9 tasks (includes Contract Provider)
+- Phase 2 (Frontend): 9 tasks (includes Contract Consumer)
+- Phase 3 (Integration): 5 tasks (includes BDD Steps + Contract Verification)
 ```
 
 ### 5. Execute Tasks (Claude Code)
@@ -417,6 +420,60 @@ Required Components:
 
 ---
 
+## BDD & Contract Testing Workflow
+
+Vibe integrates BDD (Behavior-Driven Development) and Contract Testing throughout the development lifecycle:
+
+### Workflow Overview
+
+```
+/vibe.spec "feature"
+  ↓ Generates SPEC (EARS) + Feature file (Gherkin)
+
+/vibe.plan "feature"
+  ↓ Analyzes Feature file, selects BDD tools (pytest-bdd, Pact, etc.)
+
+/vibe.tasks "feature"
+  ↓ Creates Contract Testing tasks (Provider, Consumer, Verification)
+
+/vibe.run "Task X-Y"
+  ↓ Implements test-first (Contract → Step Definitions → Code)
+
+/vibe.verify "feature"
+  ↓ Validates BDD Scenarios + Contract Tests
+```
+
+### Generated Files
+
+- **`.vibe/features/{feature}.feature`** - Gherkin scenarios (Given-When-Then)
+- **`tests/steps/`** - BDD step definitions
+- **`pacts/` or `contracts/`** - Contract test files (Provider/Consumer)
+
+### Testing Tools by Language
+
+| Language | BDD Tool | Contract Testing |
+|----------|----------|------------------|
+| Python | pytest-bdd, behave | Pact Python |
+| JavaScript/TS | cucumber, jest-cucumber | Pact JS |
+| Java/Kotlin | Cucumber JVM | Pact JVM, Spring Cloud Contract |
+| Dart/Flutter | gherkin, flutter_gherkin | Pact Dart |
+
+### Example Feature File
+
+```gherkin
+Feature: Push Notification Settings
+
+  Scenario: User enables comment notifications
+    Given the user is logged in
+    And the notification settings page is displayed
+    When the user toggles "Comments" notification to ON
+    Then the setting should be saved successfully
+    And the API should return status 200
+    And the response time should be less than 500ms
+```
+
+---
+
 ## Best Practices
 
 ### 1. Document Your Tech Stack

package/bin/vibe

@@ -106,6 +106,7 @@ function init(projectName) {
   // 폴더 생성
   fs.mkdirSync(vibeDir);
   fs.mkdirSync(path.join(vibeDir, 'specs'));
+  fs.mkdirSync(path.join(vibeDir, 'features'));
   fs.mkdirSync(path.join(vibeDir, 'plans'));
   fs.mkdirSync(path.join(vibeDir, 'tasks'));
 
@@ -169,6 +170,7 @@ ${isNewProject ? `프로젝트 위치:
   ├── config.json       # 프로젝트 설정 (언어: 한국어)
   ├── constitution.md    # 프로젝트 원칙
   ├── specs/            # SPEC 문서들
+  ├── features/         # BDD Feature 파일들 (Gherkin)
   ├── plans/            # 기술 계획들
   └── tasks/            # 작업 목록들
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@su-record/vibe",
-  "version": "0.1.7",
+  "version": "0.2.0",
   "description": "Vibe - Claude Code exclusive SPEC-driven AI coding framework",
   "main": "cli/index.js",
   "bin": {