@su-record/vibe 0.1.4 → 0.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/commands/vibe.analyze.md +123 -0
- package/.claude/commands/vibe.diagram.md +174 -0
- package/.claude/commands/vibe.plan.md +81 -0
- package/.claude/commands/vibe.run.md +158 -0
- package/.claude/commands/vibe.spec.md +280 -0
- package/.claude/commands/vibe.tasks.md +83 -0
- package/.claude/commands/vibe.ui.md +133 -0
- package/.claude/commands/vibe.verify.md +153 -0
- package/.claude/settings.local.json +19 -0
- package/README.md +221 -109
- package/bin/vibe +96 -225
- package/package.json +3 -2
- package/skills/quality/bdd-contract-testing.md +388 -0
- package/templates/contract-backend-template.md +517 -0
- package/templates/contract-frontend-template.md +594 -0
- package/templates/feature-template.md +259 -0
- package/templates/spec-template.md +60 -3
|
@@ -0,0 +1,123 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Analyze project (code quality, architecture, dependencies)
|
|
3
|
+
argument-hint: --code or --deps or --arch (optional)
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# /vibe.analyze
|
|
7
|
+
|
|
8
|
+
프로젝트를 분석합니다 (코드 품질, 아키텍처, 의존성).
|
|
9
|
+
|
|
10
|
+
## Usage
|
|
11
|
+
|
|
12
|
+
```
|
|
13
|
+
/vibe.analyze
|
|
14
|
+
/vibe.analyze --code
|
|
15
|
+
/vibe.analyze --deps
|
|
16
|
+
/vibe.analyze --arch
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
## Process
|
|
20
|
+
|
|
21
|
+
### 1. 분석 범위 확인
|
|
22
|
+
|
|
23
|
+
사용자가 지정한 옵션에 따라 분석 범위를 결정합니다:
|
|
24
|
+
|
|
25
|
+
- **기본** (`/vibe.analyze`): 전체 분석 (코드 + 의존성 + 아키텍처)
|
|
26
|
+
- **--code**: 코드 품질 분석만
|
|
27
|
+
- **--deps**: 의존성 분석만
|
|
28
|
+
- **--arch**: 아키텍처 분석만
|
|
29
|
+
|
|
30
|
+
### 2. MCP 도구 사용
|
|
31
|
+
|
|
32
|
+
다음 MCP 도구를 사용합니다 (`@su-record/hi-ai` 기반):
|
|
33
|
+
|
|
34
|
+
#### 코드 품질 분석 (--code)
|
|
35
|
+
- `mcp__su-record-hi-ai__analyze_complexity`: 복잡도 분석
|
|
36
|
+
- `mcp__su-record-hi-ai__validate_code_quality`: 코드 품질 검증
|
|
37
|
+
- `mcp__su-record-hi-ai__check_coupling_cohesion`: 결합도/응집도 체크
|
|
38
|
+
|
|
39
|
+
#### 의존성 분석 (--deps)
|
|
40
|
+
- `package.json` / `pyproject.toml` / `pubspec.yaml` 읽기
|
|
41
|
+
- 버전 충돌, 보안 취약점, 업데이트 필요 패키지 분석
|
|
42
|
+
|
|
43
|
+
#### 아키텍처 분석 (--arch)
|
|
44
|
+
- `mcp__su-record-hi-ai__find_symbol`: 핵심 모듈 찾기
|
|
45
|
+
- `mcp__su-record-hi-ai__find_references`: 모듈 간 의존성 파악
|
|
46
|
+
- 순환 의존성, 레이어 위반 검출
|
|
47
|
+
|
|
48
|
+
### 3. 분석 리포트 생성
|
|
49
|
+
|
|
50
|
+
`.vibe/reports/analysis-{date}.md` 파일에 분석 결과 저장:
|
|
51
|
+
|
|
52
|
+
```markdown
|
|
53
|
+
# 프로젝트 분석 리포트
|
|
54
|
+
|
|
55
|
+
## 개요
|
|
56
|
+
- 분석 일시: 2025-11-17 15:30
|
|
57
|
+
- 분석 범위: 전체 (코드 + 의존성 + 아키텍처)
|
|
58
|
+
|
|
59
|
+
## 코드 품질 (85/100)
|
|
60
|
+
- 평균 복잡도: 8.2 (양호)
|
|
61
|
+
- 높은 복잡도 파일: 3개
|
|
62
|
+
- src/service.py (CC: 15)
|
|
63
|
+
- src/utils.py (CC: 12)
|
|
64
|
+
|
|
65
|
+
## 의존성 (92/100)
|
|
66
|
+
- 총 패키지: 42개
|
|
67
|
+
- 업데이트 필요: 3개
|
|
68
|
+
- express: 4.17.1 → 4.18.2
|
|
69
|
+
- lodash: 4.17.20 → 4.17.21 (보안)
|
|
70
|
+
|
|
71
|
+
## 아키텍처 (78/100)
|
|
72
|
+
- 순환 의존성: 2개 발견
|
|
73
|
+
- A → B → C → A
|
|
74
|
+
- 레이어 위반: 1개
|
|
75
|
+
- Controller가 직접 DB 접근
|
|
76
|
+
|
|
77
|
+
## 개선 제안
|
|
78
|
+
1. service.py 리팩토링 (복잡도 15 → 10 이하)
|
|
79
|
+
2. lodash 보안 패치 적용
|
|
80
|
+
3. 순환 의존성 제거
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
### 4. 개선 제안
|
|
84
|
+
|
|
85
|
+
분석 결과를 바탕으로 구체적인 개선 방안 제시:
|
|
86
|
+
- 리팩토링이 필요한 파일 목록
|
|
87
|
+
- 의존성 업데이트 명령어
|
|
88
|
+
- 아키텍처 개선 방향
|
|
89
|
+
|
|
90
|
+
## Example
|
|
91
|
+
|
|
92
|
+
```
|
|
93
|
+
User: /vibe.analyze --code
|
|
94
|
+
|
|
95
|
+
Claude: 코드 품질 분석을 시작합니다...
|
|
96
|
+
|
|
97
|
+
[MCP 도구 사용]
|
|
98
|
+
- analyze_complexity 실행 중...
|
|
99
|
+
- validate_code_quality 실행 중...
|
|
100
|
+
- check_coupling_cohesion 실행 중...
|
|
101
|
+
|
|
102
|
+
✅ 분석 완료!
|
|
103
|
+
|
|
104
|
+
📊 코드 품질 점수: 85/100 (B+)
|
|
105
|
+
|
|
106
|
+
**주요 발견사항:**
|
|
107
|
+
- 높은 복잡도: src/service.py (CC: 15)
|
|
108
|
+
- 낮은 응집도: src/utils.py (응집도: 0.3)
|
|
109
|
+
- 강한 결합: Controller ↔ Service (결합도: 0.8)
|
|
110
|
+
|
|
111
|
+
**개선 제안:**
|
|
112
|
+
1. src/service.py를 3개 모듈로 분리
|
|
113
|
+
2. src/utils.py의 관련 없는 함수 분리
|
|
114
|
+
3. Dependency Injection 패턴 도입
|
|
115
|
+
|
|
116
|
+
상세 리포트: .vibe/reports/analysis-2025-11-17.md
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
## Notes
|
|
120
|
+
|
|
121
|
+
- MCP 서버(`@su-record/hi-ai`)가 설치되어 있어야 합니다
|
|
122
|
+
- 대규모 프로젝트는 분석에 시간이 걸릴 수 있습니다 (1-5분)
|
|
123
|
+
- 분석 결과는 `.vibe/reports/` 폴더에 저장됩니다
|
|
@@ -0,0 +1,174 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Generate diagrams (architecture, ERD, flowchart)
|
|
3
|
+
argument-hint: --er or --flow (optional)
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# /vibe.diagram
|
|
7
|
+
|
|
8
|
+
다이어그램을 생성합니다 (아키텍처, ERD, 플로우차트).
|
|
9
|
+
|
|
10
|
+
## Usage
|
|
11
|
+
|
|
12
|
+
```
|
|
13
|
+
/vibe.diagram
|
|
14
|
+
/vibe.diagram --er
|
|
15
|
+
/vibe.diagram --flow
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
## Process
|
|
19
|
+
|
|
20
|
+
### 1. 다이어그램 타입 결정
|
|
21
|
+
|
|
22
|
+
- **기본** (`/vibe.diagram`): 아키텍처 다이어그램
|
|
23
|
+
- **--er**: ERD (Entity-Relationship Diagram)
|
|
24
|
+
- **--flow**: 플로우차트 (주요 프로세스)
|
|
25
|
+
|
|
26
|
+
### 2. 프로젝트 분석
|
|
27
|
+
|
|
28
|
+
#### 아키텍처 다이어그램
|
|
29
|
+
- 프로젝트 구조 파악 (폴더 구조)
|
|
30
|
+
- 주요 모듈 및 레이어 식별
|
|
31
|
+
- 의존성 관계 분석
|
|
32
|
+
|
|
33
|
+
#### ERD
|
|
34
|
+
- 데이터베이스 스키마 파일 찾기
|
|
35
|
+
- `backend/models/`
|
|
36
|
+
- `migrations/`
|
|
37
|
+
- `schema.sql`
|
|
38
|
+
- 테이블 간 관계 파악
|
|
39
|
+
|
|
40
|
+
#### 플로우차트
|
|
41
|
+
- 주요 비즈니스 로직 흐름
|
|
42
|
+
- 사용자 액션 → 시스템 응답
|
|
43
|
+
|
|
44
|
+
### 3. Mermaid 코드 생성
|
|
45
|
+
|
|
46
|
+
ASCII 아트 또는 Mermaid 코드로 다이어그램 생성:
|
|
47
|
+
|
|
48
|
+
#### 아키텍처 다이어그램 (Mermaid)
|
|
49
|
+
|
|
50
|
+
```mermaid
|
|
51
|
+
graph TB
|
|
52
|
+
Client[React Frontend]
|
|
53
|
+
API[FastAPI Backend]
|
|
54
|
+
DB[(PostgreSQL)]
|
|
55
|
+
Cache[(Redis)]
|
|
56
|
+
|
|
57
|
+
Client -->|HTTP| API
|
|
58
|
+
API -->|Query| DB
|
|
59
|
+
API -->|Cache| Cache
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
#### ERD (Mermaid)
|
|
63
|
+
|
|
64
|
+
```mermaid
|
|
65
|
+
erDiagram
|
|
66
|
+
USER ||--o{ FEED : creates
|
|
67
|
+
USER ||--o{ FOLLOW : follows
|
|
68
|
+
FEED }o--|| RESTAURANT : references
|
|
69
|
+
|
|
70
|
+
USER {
|
|
71
|
+
uuid id PK
|
|
72
|
+
string email
|
|
73
|
+
int tier
|
|
74
|
+
}
|
|
75
|
+
FEED {
|
|
76
|
+
uuid id PK
|
|
77
|
+
uuid user_id FK
|
|
78
|
+
uuid restaurant_id FK
|
|
79
|
+
text content
|
|
80
|
+
}
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
#### 플로우차트 (Mermaid)
|
|
84
|
+
|
|
85
|
+
```mermaid
|
|
86
|
+
flowchart TD
|
|
87
|
+
Start([사용자가 피드 작성])
|
|
88
|
+
GPS{GPS 인증}
|
|
89
|
+
Vision{Vision API 검증}
|
|
90
|
+
OCR{OCR 인증}
|
|
91
|
+
Save[피드 저장]
|
|
92
|
+
|
|
93
|
+
Start --> GPS
|
|
94
|
+
GPS -->|50m 이내| Vision
|
|
95
|
+
GPS -->|범위 밖| Fail
|
|
96
|
+
Vision -->|음식 감지| OCR
|
|
97
|
+
Vision -->|실패| Fail
|
|
98
|
+
OCR -->|선택| Save
|
|
99
|
+
Save --> End([완료])
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
### 4. 렌더링 안내
|
|
103
|
+
|
|
104
|
+
생성된 Mermaid 코드를 렌더링하는 방법 안내:
|
|
105
|
+
|
|
106
|
+
- **GitHub**: `.md` 파일에 붙여넣기 (자동 렌더링)
|
|
107
|
+
- **VSCode**: Mermaid 확장 프로그램 설치
|
|
108
|
+
- **온라인**: https://mermaid.live/
|
|
109
|
+
|
|
110
|
+
## Example
|
|
111
|
+
|
|
112
|
+
```
|
|
113
|
+
User: /vibe.diagram --er
|
|
114
|
+
|
|
115
|
+
Claude: ERD를 생성합니다...
|
|
116
|
+
|
|
117
|
+
프로젝트 분석 중...
|
|
118
|
+
- 데이터베이스 스키마 발견: backend/models/
|
|
119
|
+
- 테이블 수: 15개
|
|
120
|
+
- 주요 관계: USER, FEED, RESTAURANT
|
|
121
|
+
|
|
122
|
+
✅ ERD 생성 완료!
|
|
123
|
+
|
|
124
|
+
```mermaid
|
|
125
|
+
erDiagram
|
|
126
|
+
USER ||--o{ FEED : creates
|
|
127
|
+
USER ||--o{ FOLLOW : "follows/followed_by"
|
|
128
|
+
USER ||--o{ BOOKMARK : bookmarks
|
|
129
|
+
FEED }o--|| RESTAURANT : references
|
|
130
|
+
FEED ||--o{ COMMENT : has
|
|
131
|
+
FEED ||--o{ LIKE : has
|
|
132
|
+
|
|
133
|
+
USER {
|
|
134
|
+
uuid id PK
|
|
135
|
+
string email UK
|
|
136
|
+
string username UK
|
|
137
|
+
int tier
|
|
138
|
+
int points
|
|
139
|
+
timestamp created_at
|
|
140
|
+
}
|
|
141
|
+
|
|
142
|
+
FEED {
|
|
143
|
+
uuid id PK
|
|
144
|
+
uuid user_id FK
|
|
145
|
+
uuid restaurant_id FK
|
|
146
|
+
text content
|
|
147
|
+
geography location
|
|
148
|
+
boolean ocr_verified
|
|
149
|
+
timestamp created_at
|
|
150
|
+
}
|
|
151
|
+
|
|
152
|
+
RESTAURANT {
|
|
153
|
+
uuid id PK
|
|
154
|
+
string name
|
|
155
|
+
geography location
|
|
156
|
+
string category
|
|
157
|
+
timestamp created_at
|
|
158
|
+
}
|
|
159
|
+
```
|
|
160
|
+
|
|
161
|
+
**다이어그램 저장 위치:**
|
|
162
|
+
.vibe/diagrams/erd-2025-11-17.md
|
|
163
|
+
|
|
164
|
+
**렌더링 방법:**
|
|
165
|
+
1. GitHub에 푸시 (자동 렌더링)
|
|
166
|
+
2. VSCode에서 Mermaid 확장 프로그램 사용
|
|
167
|
+
3. https://mermaid.live/ 에서 확인
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
## Notes
|
|
171
|
+
|
|
172
|
+
- Mermaid는 GitHub, GitLab, VSCode 등에서 지원됩니다
|
|
173
|
+
- 복잡한 다이어그램은 수동 조정이 필요할 수 있습니다
|
|
174
|
+
- 생성된 다이어그램은 `.vibe/diagrams/` 폴더에 저장됩니다
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Create PLAN document with Planning Agent
|
|
3
|
+
argument-hint: "feature name"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# /vibe.plan
|
|
7
|
+
|
|
8
|
+
PLAN 문서를 작성합니다 (Planning Agent).
|
|
9
|
+
|
|
10
|
+
## Usage
|
|
11
|
+
|
|
12
|
+
```
|
|
13
|
+
/vibe.plan "기능명"
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
## Description
|
|
17
|
+
|
|
18
|
+
SPEC 문서를 분석하여 기술 구현 계획(PLAN)을 작성합니다.
|
|
19
|
+
|
|
20
|
+
## Process
|
|
21
|
+
|
|
22
|
+
1. **SPEC 문서 읽기**: `.vibe/specs/{기능명}.md` 분석
|
|
23
|
+
2. **Feature 파일 읽기**: `.vibe/features/{기능명}.feature` 확인 (BDD)
|
|
24
|
+
3. **프로젝트 컨텍스트 파악**:
|
|
25
|
+
- `CLAUDE.md` 읽기 (기술 스택 확인)
|
|
26
|
+
- `package.json` / `pyproject.toml` / `pubspec.yaml` 확인
|
|
27
|
+
4. **PLAN 문서 작성**: 15개 섹션 포함
|
|
28
|
+
- 기술 스택 선정 (기존 스택 재사용 우선)
|
|
29
|
+
- 아키텍처 설계
|
|
30
|
+
- API 설계
|
|
31
|
+
- DB 스키마
|
|
32
|
+
- 외부 서비스 통합
|
|
33
|
+
- 보안 설계
|
|
34
|
+
- 성능 최적화
|
|
35
|
+
- 에러 처리
|
|
36
|
+
- 모니터링 및 로깅
|
|
37
|
+
- **테스트 전략 (BDD/Contract Testing 포함)**
|
|
38
|
+
- BDD 도구 선정 (pytest-bdd, behave, cucumber 등)
|
|
39
|
+
- Contract Testing 도구 (Pact, Spring Cloud Contract 등)
|
|
40
|
+
- Feature 파일과 SPEC 매핑
|
|
41
|
+
- API Contract 스키마 정의
|
|
42
|
+
- 배포 전략
|
|
43
|
+
- 비용 예측
|
|
44
|
+
- 마일스톤 (Phase별)
|
|
45
|
+
- 리스크 및 완화 방안
|
|
46
|
+
- 다음 단계
|
|
47
|
+
5. **품질 검증**: 기술 선택 근거, 비용, 일정 현실성, BDD 테스트 전략 타당성
|
|
48
|
+
|
|
49
|
+
## Agent
|
|
50
|
+
|
|
51
|
+
`~/.vibe/agents/planning-agent.md`
|
|
52
|
+
|
|
53
|
+
## Input
|
|
54
|
+
|
|
55
|
+
- `.vibe/specs/{기능명}.md` (SPEC 문서)
|
|
56
|
+
- `.vibe/features/{기능명}.feature` (BDD Feature 파일)
|
|
57
|
+
- `CLAUDE.md` (프로젝트 기술 스택)
|
|
58
|
+
|
|
59
|
+
## Output
|
|
60
|
+
|
|
61
|
+
- `.vibe/plans/{기능명}.md` - PLAN 문서
|
|
62
|
+
- 예상 공수 (시간/일)
|
|
63
|
+
- 예상 비용 ($)
|
|
64
|
+
- Phase별 마일스톤
|
|
65
|
+
|
|
66
|
+
## Example
|
|
67
|
+
|
|
68
|
+
```
|
|
69
|
+
/vibe.plan "푸시 알림 설정 기능"
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
**결과:**
|
|
73
|
+
- 3 Phases (Backend → Frontend → FCM)
|
|
74
|
+
- 24시간 (3일)
|
|
75
|
+
- $0.50/월 추가 비용
|
|
76
|
+
|
|
77
|
+
## Next Step
|
|
78
|
+
|
|
79
|
+
```
|
|
80
|
+
/vibe.tasks "푸시 알림 설정 기능"
|
|
81
|
+
```
|
|
@@ -0,0 +1,158 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Execute task with Implementation Agent
|
|
3
|
+
argument-hint: "Task 1-1" or --phase N or --all
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# /vibe.run
|
|
7
|
+
|
|
8
|
+
Task를 구현합니다 (Implementation Agent).
|
|
9
|
+
|
|
10
|
+
## Usage
|
|
11
|
+
|
|
12
|
+
```
|
|
13
|
+
/vibe.run "Task 1-1" # 특정 Task 실행
|
|
14
|
+
/vibe.run --phase 1 # Phase 1 전체 실행
|
|
15
|
+
/vibe.run --all # 모든 Task 실행
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
## Description
|
|
19
|
+
|
|
20
|
+
TASKS 문서의 특정 Task를 읽고 구현 가이드를 생성한 후, 실제 코드를 작성합니다.
|
|
21
|
+
|
|
22
|
+
## Process
|
|
23
|
+
|
|
24
|
+
### 1️⃣ Task 정보 읽기
|
|
25
|
+
- `.vibe/tasks/{기능명}.md`에서 Task 찾기
|
|
26
|
+
- Task 메타데이터 확인:
|
|
27
|
+
- 담당 Agent (Backend Python Expert / Frontend Flutter Expert)
|
|
28
|
+
- 예상 시간
|
|
29
|
+
- 우선순위
|
|
30
|
+
- 의존성 (선행 Task 완료 여부 확인)
|
|
31
|
+
- Acceptance Criteria
|
|
32
|
+
|
|
33
|
+
### 2️⃣ 구현 가이드 생성
|
|
34
|
+
- `.vibe/guides/task-{N}-{M}.md` 생성
|
|
35
|
+
- 포함 내용:
|
|
36
|
+
- 목표 (Goal)
|
|
37
|
+
- 파일 경로 (Files to Create/Modify)
|
|
38
|
+
- 코드 템플릿 (Code Template)
|
|
39
|
+
- 구현 순서 (Implementation Steps)
|
|
40
|
+
- 검증 방법 (Verification)
|
|
41
|
+
- 다음 Task
|
|
42
|
+
|
|
43
|
+
### 3️⃣ 코드 구현
|
|
44
|
+
- 구현 가이드에 따라 실제 파일 생성/수정
|
|
45
|
+
- 담당 Agent의 스킬 적용:
|
|
46
|
+
- Backend Python Expert: `~/.vibe/agents/backend-python-expert.md`
|
|
47
|
+
- Frontend Flutter Expert: `~/.vibe/agents/frontend-flutter-expert.md`
|
|
48
|
+
- TRUST 5 원칙 준수:
|
|
49
|
+
- **Test-first (BDD/Contract Testing 우선)**
|
|
50
|
+
- Contract 파일 먼저 작성 (Provider/Consumer)
|
|
51
|
+
- BDD Step Definitions 작성
|
|
52
|
+
- Unit Tests 작성
|
|
53
|
+
- Readable (명확한 코드)
|
|
54
|
+
- Unified (일관된 스타일)
|
|
55
|
+
- Secured (보안 고려)
|
|
56
|
+
- Trackable (로깅, 모니터링)
|
|
57
|
+
|
|
58
|
+
### 4️⃣ Acceptance Criteria 검증
|
|
59
|
+
- TASKS 문서의 체크리스트 확인
|
|
60
|
+
- 검증 명령어 실행 (pytest, flutter test 등)
|
|
61
|
+
- 모든 기준 통과 확인
|
|
62
|
+
|
|
63
|
+
### 5️⃣ Task 상태 업데이트
|
|
64
|
+
- TASKS 문서에서 Task 상태를 ✅ 완료로 변경
|
|
65
|
+
- 완료 일시 기록
|
|
66
|
+
- 진행률 업데이트
|
|
67
|
+
|
|
68
|
+
## Agent Selection
|
|
69
|
+
|
|
70
|
+
| Task | Agent |
|
|
71
|
+
|------|-------|
|
|
72
|
+
| Task 1-1 ~ 1-9 (Backend + Contract Provider) | Backend Python Expert |
|
|
73
|
+
| Task 2-1 ~ 2-9 (Frontend + Contract Consumer) | Frontend Flutter Expert |
|
|
74
|
+
| Task 3-1 ~ 3-2 (FCM Backend) | Backend Python Expert |
|
|
75
|
+
| Task 3-3 (BDD Step Definitions) | QA / Backend/Frontend Expert |
|
|
76
|
+
| Task 3-4 (Contract Verification) | QA |
|
|
77
|
+
| Task 3-5 (E2E Test) | QA / Frontend Flutter Expert |
|
|
78
|
+
|
|
79
|
+
## Input
|
|
80
|
+
|
|
81
|
+
- `.vibe/tasks/{기능명}.md` (TASKS 문서)
|
|
82
|
+
- `.vibe/plans/{기능명}.md` (PLAN 참고)
|
|
83
|
+
- `.vibe/specs/{기능명}.md` (SPEC 참고)
|
|
84
|
+
- `.vibe/features/{기능명}.feature` (BDD Feature 파일 - Contract Test 매핑용)
|
|
85
|
+
|
|
86
|
+
## Output
|
|
87
|
+
|
|
88
|
+
- `.vibe/guides/task-{N}-{M}.md` - 구현 가이드
|
|
89
|
+
- 실제 코드 파일 (생성/수정)
|
|
90
|
+
- TASKS 문서 업데이트 (상태: ✅ 완료)
|
|
91
|
+
|
|
92
|
+
## Example
|
|
93
|
+
|
|
94
|
+
### 개별 Task 실행
|
|
95
|
+
|
|
96
|
+
```
|
|
97
|
+
/vibe.run "Task 1-1"
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
**동작:**
|
|
101
|
+
1. TASKS 문서 읽기
|
|
102
|
+
2. Task 1-1 정보 파싱:
|
|
103
|
+
- 담당: Backend Python Expert
|
|
104
|
+
- 내용: DB 마이그레이션 파일 작성
|
|
105
|
+
- 예상 시간: 30분
|
|
106
|
+
3. 구현 가이드 생성: `.vibe/guides/task-1-1.md`
|
|
107
|
+
4. 코드 작성: `backend/alembic/versions/xxxx_add_notification_settings.py`
|
|
108
|
+
5. 검증: `alembic upgrade head` 실행
|
|
109
|
+
6. Task 상태 업데이트: ⬜ → ✅
|
|
110
|
+
|
|
111
|
+
### Phase 실행
|
|
112
|
+
|
|
113
|
+
```
|
|
114
|
+
/vibe.run --phase 1
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
**동작:**
|
|
118
|
+
- Phase 1의 9개 Task 순차 실행
|
|
119
|
+
- Task 1-1 → 1-2 → ... → 1-9 (Contract Provider 포함)
|
|
120
|
+
- 각 Task마다 의존성 확인 후 실행
|
|
121
|
+
|
|
122
|
+
### 전체 실행
|
|
123
|
+
|
|
124
|
+
```
|
|
125
|
+
/vibe.run --all
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
**동작:**
|
|
129
|
+
- 의존성 그래프에 따라 23개 Task 순차 실행
|
|
130
|
+
- Phase 1 (9개) → Phase 2 (9개) → Phase 3 (5개)
|
|
131
|
+
- BDD/Contract Testing 포함
|
|
132
|
+
- 예상 시간: 28시간
|
|
133
|
+
|
|
134
|
+
## Verification
|
|
135
|
+
|
|
136
|
+
각 Task 완료 후:
|
|
137
|
+
- [ ] Acceptance Criteria 모두 통과
|
|
138
|
+
- [ ] 검증 명령어 실행 성공
|
|
139
|
+
- [ ] 코드 품질 기준 충족 (TRUST 5)
|
|
140
|
+
- [ ] TASKS 문서 상태 업데이트
|
|
141
|
+
|
|
142
|
+
## Error Handling
|
|
143
|
+
|
|
144
|
+
Task 실행 실패 시:
|
|
145
|
+
1. 에러 메시지 확인
|
|
146
|
+
2. 구현 가이드 재검토
|
|
147
|
+
3. 코드 수정 후 재시도
|
|
148
|
+
4. 여전히 실패 시 사용자에게 보고
|
|
149
|
+
|
|
150
|
+
## Next Step
|
|
151
|
+
|
|
152
|
+
Task 완료 후:
|
|
153
|
+
- 의존성 그래프 확인
|
|
154
|
+
- 다음 Task 실행 또는 Phase 완료 확인
|
|
155
|
+
- 모든 Task 완료 시:
|
|
156
|
+
```
|
|
157
|
+
/vibe.verify "푸시 알림 설정 기능"
|
|
158
|
+
```
|