@su-record/vibe 2.3.0 → 2.3.2
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/settings.json +35 -35
- package/.claude/settings.local.json +24 -25
- package/.claude/vibe/constitution.md +184 -184
- package/.claude/vibe/rules/core/communication-guide.md +104 -104
- package/.claude/vibe/rules/core/development-philosophy.md +52 -52
- package/.claude/vibe/rules/core/quick-start.md +120 -120
- package/.claude/vibe/rules/languages/dart-flutter.md +509 -509
- package/.claude/vibe/rules/languages/go.md +396 -396
- package/.claude/vibe/rules/languages/java-spring.md +586 -586
- package/.claude/vibe/rules/languages/kotlin-android.md +491 -491
- package/.claude/vibe/rules/languages/python-django.md +371 -371
- package/.claude/vibe/rules/languages/python-fastapi.md +386 -386
- package/.claude/vibe/rules/languages/rust.md +425 -425
- package/.claude/vibe/rules/languages/swift-ios.md +516 -516
- package/.claude/vibe/rules/languages/typescript-nextjs.md +441 -441
- package/.claude/vibe/rules/languages/typescript-node.md +375 -375
- package/.claude/vibe/rules/languages/typescript-nuxt.md +521 -521
- package/.claude/vibe/rules/languages/typescript-react-native.md +446 -446
- package/.claude/vibe/rules/languages/typescript-react.md +525 -525
- package/.claude/vibe/rules/languages/typescript-vue.md +353 -353
- package/.claude/vibe/rules/quality/bdd-contract-testing.md +388 -388
- package/.claude/vibe/rules/quality/checklist.md +276 -276
- package/.claude/vibe/rules/quality/testing-strategy.md +437 -437
- package/.claude/vibe/rules/standards/anti-patterns.md +369 -369
- package/.claude/vibe/rules/standards/code-structure.md +291 -291
- package/.claude/vibe/rules/standards/complexity-metrics.md +312 -312
- package/.claude/vibe/rules/standards/naming-conventions.md +198 -198
- package/.claude/vibe/setup.sh +31 -31
- package/.claude/vibe/templates/constitution-template.md +184 -184
- package/.claude/vibe/templates/contract-backend-template.md +517 -517
- package/.claude/vibe/templates/contract-frontend-template.md +594 -594
- package/.claude/vibe/templates/feature-template.md +96 -96
- package/.claude/vibe/templates/spec-template.md +199 -199
- package/CLAUDE.md +345 -323
- package/LICENSE +21 -21
- package/README.md +744 -724
- package/agents/compounder.md +261 -261
- package/agents/diagrammer.md +178 -178
- package/agents/e2e-tester.md +266 -266
- package/agents/explorer.md +48 -48
- package/agents/implementer.md +53 -53
- package/agents/research/best-practices-agent.md +139 -139
- package/agents/research/codebase-patterns-agent.md +147 -147
- package/agents/research/framework-docs-agent.md +181 -181
- package/agents/research/security-advisory-agent.md +167 -167
- package/agents/review/architecture-reviewer.md +107 -107
- package/agents/review/complexity-reviewer.md +116 -116
- package/agents/review/data-integrity-reviewer.md +88 -88
- package/agents/review/git-history-reviewer.md +103 -103
- package/agents/review/performance-reviewer.md +86 -86
- package/agents/review/python-reviewer.md +152 -152
- package/agents/review/rails-reviewer.md +139 -139
- package/agents/review/react-reviewer.md +144 -144
- package/agents/review/security-reviewer.md +80 -80
- package/agents/review/simplicity-reviewer.md +140 -140
- package/agents/review/test-coverage-reviewer.md +116 -116
- package/agents/review/typescript-reviewer.md +127 -127
- package/agents/searcher.md +54 -54
- package/agents/simplifier.md +119 -119
- package/agents/tester.md +49 -49
- package/agents/ui-previewer.md +137 -137
- package/commands/vibe.analyze.md +245 -180
- package/commands/vibe.reason.md +223 -183
- package/commands/vibe.review.md +200 -136
- package/commands/vibe.run.md +838 -836
- package/commands/vibe.spec.md +419 -383
- package/commands/vibe.utils.md +101 -101
- package/commands/vibe.verify.md +282 -241
- package/dist/cli/index.js +385 -385
- package/dist/lib/MemoryManager.d.ts.map +1 -1
- package/dist/lib/MemoryManager.js +119 -114
- package/dist/lib/MemoryManager.js.map +1 -1
- package/dist/lib/PythonParser.js +108 -108
- package/dist/lib/gemini-mcp.js +15 -15
- package/dist/lib/gemini-oauth.js +35 -35
- package/dist/lib/gpt-mcp.js +17 -17
- package/dist/lib/gpt-oauth.js +44 -44
- package/dist/tools/analytics/getUsageAnalytics.js +12 -12
- package/dist/tools/index.d.ts +50 -0
- package/dist/tools/index.d.ts.map +1 -0
- package/dist/tools/index.js +61 -0
- package/dist/tools/index.js.map +1 -0
- package/dist/tools/memory/createMemoryTimeline.js +10 -10
- package/dist/tools/memory/getMemoryGraph.js +12 -12
- package/dist/tools/memory/getSessionContext.js +9 -9
- package/dist/tools/memory/linkMemories.js +14 -14
- package/dist/tools/memory/listMemories.js +4 -4
- package/dist/tools/memory/recallMemory.js +4 -4
- package/dist/tools/memory/saveMemory.js +4 -4
- package/dist/tools/memory/searchMemoriesAdvanced.js +22 -22
- package/dist/tools/planning/generatePrd.js +46 -46
- package/dist/tools/prompt/enhancePromptGemini.js +160 -160
- package/dist/tools/reasoning/applyReasoningFramework.js +56 -56
- package/dist/tools/semantic/analyzeDependencyGraph.js +12 -12
- package/hooks/hooks.json +121 -103
- package/package.json +73 -69
- package/skills/git-worktree.md +178 -178
- package/skills/priority-todos.md +236 -236
|
@@ -1,104 +1,104 @@
|
|
|
1
|
-
# 💬 커뮤니케이션 가이드
|
|
2
|
-
|
|
3
|
-
## ⚠️ 최우선 규칙: 한국어로 응답
|
|
4
|
-
|
|
5
|
-
**모든 대화, 설명, 주석은 한국어로 작성합니다.**
|
|
6
|
-
|
|
7
|
-
- ✅ AI 응답: 한국어
|
|
8
|
-
- ✅ 코드 주석: 한국어
|
|
9
|
-
- ✅ 문서: 한국어
|
|
10
|
-
- ✅ 에러 메시지: 한국어
|
|
11
|
-
- ⚠️ 예외: 코드 자체 (함수명, 변수명 등)는 영어
|
|
12
|
-
|
|
13
|
-
## 3.1 코드 제공 형식
|
|
14
|
-
|
|
15
|
-
```markdown
|
|
16
|
-
### 작업 범위
|
|
17
|
-
|
|
18
|
-
"요청하신 대로 UserProfile 컴포넌트의 상태 관리 로직만 수정했습니다."
|
|
19
|
-
|
|
20
|
-
### 변경 사항 요약
|
|
21
|
-
|
|
22
|
-
주문 상태 업데이트 로직 개선 - Optimistic updates 적용
|
|
23
|
-
|
|
24
|
-
### 코드
|
|
25
|
-
|
|
26
|
-
[완전한 코드 블록]
|
|
27
|
-
|
|
28
|
-
### 참고사항
|
|
29
|
-
|
|
30
|
-
- 에러 발생 시 자동 롤백
|
|
31
|
-
- 네트워크 재시도 3회
|
|
32
|
-
```
|
|
33
|
-
|
|
34
|
-
## 3.2 리뷰 응답 형식
|
|
35
|
-
|
|
36
|
-
```markdown
|
|
37
|
-
### 개선점
|
|
38
|
-
|
|
39
|
-
1. memoization 누락 (성능)
|
|
40
|
-
2. error boundary 미적용 (안정성)
|
|
41
|
-
|
|
42
|
-
### 권장사항
|
|
43
|
-
|
|
44
|
-
useMemo 적용 및 ErrorBoundary로 감싸기
|
|
45
|
-
```
|
|
46
|
-
|
|
47
|
-
## 3.3 에러 보고 형식
|
|
48
|
-
|
|
49
|
-
```markdown
|
|
50
|
-
### 문제
|
|
51
|
-
|
|
52
|
-
[발생한 문제 명확히 설명]
|
|
53
|
-
|
|
54
|
-
### 원인
|
|
55
|
-
|
|
56
|
-
[분석된 원인]
|
|
57
|
-
|
|
58
|
-
### 해결 방법
|
|
59
|
-
|
|
60
|
-
[구체적인 해결 단계]
|
|
61
|
-
|
|
62
|
-
### 예방책
|
|
63
|
-
|
|
64
|
-
[향후 방지 방법]
|
|
65
|
-
```
|
|
66
|
-
|
|
67
|
-
## 3.4 변경사항 설명 원칙
|
|
68
|
-
|
|
69
|
-
- **명확성**: 무엇을 왜 변경했는지 명확히
|
|
70
|
-
- **간결성**: 핵심만 전달
|
|
71
|
-
- **완전성**: 부작용과 주의사항 포함
|
|
72
|
-
- **추적성**: 관련 이슈/요청 참조
|
|
73
|
-
|
|
74
|
-
## 3.5 특수 명령어 실행
|
|
75
|
-
|
|
76
|
-
- **"optimize"**: 성능 개선 (memoization, 번들 크기 등)
|
|
77
|
-
- **"enhance accessibility"**: ARIA, 키보드 지원 등 추가
|
|
78
|
-
- **"strengthen types"**: any 제거, 타입 안전성 향상
|
|
79
|
-
- **"cleanup"**: 불필요한 코드 제거 (요청 시에만)
|
|
80
|
-
- **"split"**: 컴포넌트/함수 분리 (요청 시에만)
|
|
81
|
-
|
|
82
|
-
## 3.6 질문 형식
|
|
83
|
-
|
|
84
|
-
### 명확성이 필요할 때
|
|
85
|
-
|
|
86
|
-
```markdown
|
|
87
|
-
다음 사항을 확인해주세요:
|
|
88
|
-
|
|
89
|
-
1. [구체적인 질문 1]
|
|
90
|
-
2. [구체적인 질문 2]
|
|
91
|
-
|
|
92
|
-
이 정보가 있으면 더 정확한 구현이 가능합니다.
|
|
93
|
-
```
|
|
94
|
-
|
|
95
|
-
### 대안 제시
|
|
96
|
-
|
|
97
|
-
```markdown
|
|
98
|
-
요청하신 방법 외에 다음 대안도 가능합니다:
|
|
99
|
-
|
|
100
|
-
**방법 A**: [설명] - 장점: [장점], 단점: [단점]
|
|
101
|
-
**방법 B**: [설명] - 장점: [장점], 단점: [단점]
|
|
102
|
-
|
|
103
|
-
어떤 방식을 선호하시나요?
|
|
104
|
-
```
|
|
1
|
+
# 💬 커뮤니케이션 가이드
|
|
2
|
+
|
|
3
|
+
## ⚠️ 최우선 규칙: 한국어로 응답
|
|
4
|
+
|
|
5
|
+
**모든 대화, 설명, 주석은 한국어로 작성합니다.**
|
|
6
|
+
|
|
7
|
+
- ✅ AI 응답: 한국어
|
|
8
|
+
- ✅ 코드 주석: 한국어
|
|
9
|
+
- ✅ 문서: 한국어
|
|
10
|
+
- ✅ 에러 메시지: 한국어
|
|
11
|
+
- ⚠️ 예외: 코드 자체 (함수명, 변수명 등)는 영어
|
|
12
|
+
|
|
13
|
+
## 3.1 코드 제공 형식
|
|
14
|
+
|
|
15
|
+
```markdown
|
|
16
|
+
### 작업 범위
|
|
17
|
+
|
|
18
|
+
"요청하신 대로 UserProfile 컴포넌트의 상태 관리 로직만 수정했습니다."
|
|
19
|
+
|
|
20
|
+
### 변경 사항 요약
|
|
21
|
+
|
|
22
|
+
주문 상태 업데이트 로직 개선 - Optimistic updates 적용
|
|
23
|
+
|
|
24
|
+
### 코드
|
|
25
|
+
|
|
26
|
+
[완전한 코드 블록]
|
|
27
|
+
|
|
28
|
+
### 참고사항
|
|
29
|
+
|
|
30
|
+
- 에러 발생 시 자동 롤백
|
|
31
|
+
- 네트워크 재시도 3회
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## 3.2 리뷰 응답 형식
|
|
35
|
+
|
|
36
|
+
```markdown
|
|
37
|
+
### 개선점
|
|
38
|
+
|
|
39
|
+
1. memoization 누락 (성능)
|
|
40
|
+
2. error boundary 미적용 (안정성)
|
|
41
|
+
|
|
42
|
+
### 권장사항
|
|
43
|
+
|
|
44
|
+
useMemo 적용 및 ErrorBoundary로 감싸기
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
## 3.3 에러 보고 형식
|
|
48
|
+
|
|
49
|
+
```markdown
|
|
50
|
+
### 문제
|
|
51
|
+
|
|
52
|
+
[발생한 문제 명확히 설명]
|
|
53
|
+
|
|
54
|
+
### 원인
|
|
55
|
+
|
|
56
|
+
[분석된 원인]
|
|
57
|
+
|
|
58
|
+
### 해결 방법
|
|
59
|
+
|
|
60
|
+
[구체적인 해결 단계]
|
|
61
|
+
|
|
62
|
+
### 예방책
|
|
63
|
+
|
|
64
|
+
[향후 방지 방법]
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
## 3.4 변경사항 설명 원칙
|
|
68
|
+
|
|
69
|
+
- **명확성**: 무엇을 왜 변경했는지 명확히
|
|
70
|
+
- **간결성**: 핵심만 전달
|
|
71
|
+
- **완전성**: 부작용과 주의사항 포함
|
|
72
|
+
- **추적성**: 관련 이슈/요청 참조
|
|
73
|
+
|
|
74
|
+
## 3.5 특수 명령어 실행
|
|
75
|
+
|
|
76
|
+
- **"optimize"**: 성능 개선 (memoization, 번들 크기 등)
|
|
77
|
+
- **"enhance accessibility"**: ARIA, 키보드 지원 등 추가
|
|
78
|
+
- **"strengthen types"**: any 제거, 타입 안전성 향상
|
|
79
|
+
- **"cleanup"**: 불필요한 코드 제거 (요청 시에만)
|
|
80
|
+
- **"split"**: 컴포넌트/함수 분리 (요청 시에만)
|
|
81
|
+
|
|
82
|
+
## 3.6 질문 형식
|
|
83
|
+
|
|
84
|
+
### 명확성이 필요할 때
|
|
85
|
+
|
|
86
|
+
```markdown
|
|
87
|
+
다음 사항을 확인해주세요:
|
|
88
|
+
|
|
89
|
+
1. [구체적인 질문 1]
|
|
90
|
+
2. [구체적인 질문 2]
|
|
91
|
+
|
|
92
|
+
이 정보가 있으면 더 정확한 구현이 가능합니다.
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
### 대안 제시
|
|
96
|
+
|
|
97
|
+
```markdown
|
|
98
|
+
요청하신 방법 외에 다음 대안도 가능합니다:
|
|
99
|
+
|
|
100
|
+
**방법 A**: [설명] - 장점: [장점], 단점: [단점]
|
|
101
|
+
**방법 B**: [설명] - 장점: [장점], 단점: [단점]
|
|
102
|
+
|
|
103
|
+
어떤 방식을 선호하시나요?
|
|
104
|
+
```
|
|
@@ -1,53 +1,53 @@
|
|
|
1
|
-
# 🏛️ 개발 철학과 원칙 - "왜"에 대한 답
|
|
2
|
-
|
|
3
|
-
## 1.1 🥇 최우선 순위: 수술적 정밀도
|
|
4
|
-
|
|
5
|
-
> **⚠️ 이것은 모든 작업에 앞서는 TORY의 첫 번째 원칙입니다.**
|
|
6
|
-
>
|
|
7
|
-
> **요청받지 않은 코드는 절대 수정/삭제하지 않습니다.**
|
|
8
|
-
|
|
9
|
-
### 원칙
|
|
10
|
-
|
|
11
|
-
- **엄격한 범위 준수**: 사용자가 명시적으로 요청한 파일과 코드 블록만 수정
|
|
12
|
-
- **기존 코드 보존**: 작동하는 코드를 임의로 리팩토링하거나 제거하지 않음
|
|
13
|
-
- **스타일 존중**: 기존 네이밍, 포맷팅, 주석 스타일 유지
|
|
14
|
-
|
|
15
|
-
## 1.2 핵심 철학
|
|
16
|
-
|
|
17
|
-
### 🎯 개발의 황금률
|
|
18
|
-
|
|
19
|
-
- **한국어 우선**: 모든 커뮤니케이션은 명확한 한국어로
|
|
20
|
-
- **단순함의 미학**: 코드가 적을수록 좋은 코드
|
|
21
|
-
- **DRY 원칙**: 반복하지 말고 재사용
|
|
22
|
-
- **단일 책임**: 하나의 함수는 하나의 목적만
|
|
23
|
-
- **실용주의**: 완벽보다 실용, YAGNI 정신
|
|
24
|
-
|
|
25
|
-
### 🎨 코드 품질 기준
|
|
26
|
-
|
|
27
|
-
- **가독성**: 코드는 사람을 위한 것
|
|
28
|
-
- **예측 가능성**: 코드에서 놀라움은 금물
|
|
29
|
-
- **유지보수성**: 미래의 나를 배려
|
|
30
|
-
- **테스트 가능성**: 검증 가능한 구조
|
|
31
|
-
|
|
32
|
-
## 1.3 아키텍처 원칙
|
|
33
|
-
|
|
34
|
-
### 🏗️ 설계의 지혜
|
|
35
|
-
|
|
36
|
-
- **패턴의 적절한 적용**: Composite, Observer, Factory 등 필요에 따라 적용
|
|
37
|
-
- **과도한 추상화 지양**: 3단계 이상의 wrapper 금지
|
|
38
|
-
- **순환 의존성 방지**: File A → File B → File A ❌
|
|
39
|
-
|
|
40
|
-
### ♿ 접근성은 선택이 아닌 필수
|
|
41
|
-
|
|
42
|
-
- Semantic HTML을 기본으로
|
|
43
|
-
- 키보드 내비게이션 지원
|
|
44
|
-
- 스크린 리더 최적화
|
|
45
|
-
- ARIA 속성 적극 활용
|
|
46
|
-
|
|
47
|
-
## 핵심 가치
|
|
48
|
-
|
|
49
|
-
1. **명확성**: 코드는 자기 설명적이어야 함
|
|
50
|
-
2. **간결성**: 불필요한 복잡도 제거
|
|
51
|
-
3. **일관성**: 일관된 패턴과 스타일 유지
|
|
52
|
-
4. **확장성**: 미래의 변화를 고려한 설계
|
|
1
|
+
# 🏛️ 개발 철학과 원칙 - "왜"에 대한 답
|
|
2
|
+
|
|
3
|
+
## 1.1 🥇 최우선 순위: 수술적 정밀도
|
|
4
|
+
|
|
5
|
+
> **⚠️ 이것은 모든 작업에 앞서는 TORY의 첫 번째 원칙입니다.**
|
|
6
|
+
>
|
|
7
|
+
> **요청받지 않은 코드는 절대 수정/삭제하지 않습니다.**
|
|
8
|
+
|
|
9
|
+
### 원칙
|
|
10
|
+
|
|
11
|
+
- **엄격한 범위 준수**: 사용자가 명시적으로 요청한 파일과 코드 블록만 수정
|
|
12
|
+
- **기존 코드 보존**: 작동하는 코드를 임의로 리팩토링하거나 제거하지 않음
|
|
13
|
+
- **스타일 존중**: 기존 네이밍, 포맷팅, 주석 스타일 유지
|
|
14
|
+
|
|
15
|
+
## 1.2 핵심 철학
|
|
16
|
+
|
|
17
|
+
### 🎯 개발의 황금률
|
|
18
|
+
|
|
19
|
+
- **한국어 우선**: 모든 커뮤니케이션은 명확한 한국어로
|
|
20
|
+
- **단순함의 미학**: 코드가 적을수록 좋은 코드
|
|
21
|
+
- **DRY 원칙**: 반복하지 말고 재사용
|
|
22
|
+
- **단일 책임**: 하나의 함수는 하나의 목적만
|
|
23
|
+
- **실용주의**: 완벽보다 실용, YAGNI 정신
|
|
24
|
+
|
|
25
|
+
### 🎨 코드 품질 기준
|
|
26
|
+
|
|
27
|
+
- **가독성**: 코드는 사람을 위한 것
|
|
28
|
+
- **예측 가능성**: 코드에서 놀라움은 금물
|
|
29
|
+
- **유지보수성**: 미래의 나를 배려
|
|
30
|
+
- **테스트 가능성**: 검증 가능한 구조
|
|
31
|
+
|
|
32
|
+
## 1.3 아키텍처 원칙
|
|
33
|
+
|
|
34
|
+
### 🏗️ 설계의 지혜
|
|
35
|
+
|
|
36
|
+
- **패턴의 적절한 적용**: Composite, Observer, Factory 등 필요에 따라 적용
|
|
37
|
+
- **과도한 추상화 지양**: 3단계 이상의 wrapper 금지
|
|
38
|
+
- **순환 의존성 방지**: File A → File B → File A ❌
|
|
39
|
+
|
|
40
|
+
### ♿ 접근성은 선택이 아닌 필수
|
|
41
|
+
|
|
42
|
+
- Semantic HTML을 기본으로
|
|
43
|
+
- 키보드 내비게이션 지원
|
|
44
|
+
- 스크린 리더 최적화
|
|
45
|
+
- ARIA 속성 적극 활용
|
|
46
|
+
|
|
47
|
+
## 핵심 가치
|
|
48
|
+
|
|
49
|
+
1. **명확성**: 코드는 자기 설명적이어야 함
|
|
50
|
+
2. **간결성**: 불필요한 복잡도 제거
|
|
51
|
+
3. **일관성**: 일관된 패턴과 스타일 유지
|
|
52
|
+
4. **확장성**: 미래의 변화를 고려한 설계
|
|
53
53
|
5. **안전성**: 오류 처리와 엣지 케이스 고려
|
|
@@ -1,121 +1,121 @@
|
|
|
1
|
-
# ⚡ Quick Start - 즉시 적용 가능한 원칙
|
|
2
|
-
|
|
3
|
-
## 🎯 5가지 핵심 원칙
|
|
4
|
-
|
|
5
|
-
```
|
|
6
|
-
✅ 🇰🇷 한국어로 응답 (최우선)
|
|
7
|
-
✅ 📉 코드가 적을수록 부채도 적다
|
|
8
|
-
✅ 🚫 DRY - Don't Repeat Yourself
|
|
9
|
-
✅ 🎯 단일 책임 원칙 (SRP)
|
|
10
|
-
✅ 🙏 YAGNI - You Aren't Gonna Need It
|
|
11
|
-
```
|
|
12
|
-
|
|
13
|
-
## ⚠️ 언어 규칙 (절대 준수)
|
|
14
|
-
|
|
15
|
-
**모든 답변은 한국어로 작성합니다.**
|
|
16
|
-
|
|
17
|
-
### 한국어 사용 원칙
|
|
18
|
-
|
|
19
|
-
1. **설명, 주석, 대화**: 100% 한국어
|
|
20
|
-
2. **코드**: 영어 (프로그래밍 언어 표준)
|
|
21
|
-
3. **기술 용어**: 한국어 우선, 필요시 영어 병기
|
|
22
|
-
- ✅ "의존성 주입 (Dependency Injection)"
|
|
23
|
-
- ✅ "상태 관리 (State Management)"
|
|
24
|
-
- ❌ "Dependency Injection"
|
|
25
|
-
4. **에러 메시지**: 한국어로 설명
|
|
26
|
-
5. **문서 제목/헤더**: 한국어
|
|
27
|
-
|
|
28
|
-
### 예시
|
|
29
|
-
|
|
30
|
-
```python
|
|
31
|
-
# ✅ 좋은 예
|
|
32
|
-
# 사용자 인증 미들웨어
|
|
33
|
-
async def authenticate_user(token: str) -> User:
|
|
34
|
-
"""
|
|
35
|
-
JWT 토큰을 검증하고 사용자를 반환합니다.
|
|
36
|
-
|
|
37
|
-
Args:
|
|
38
|
-
token: JWT 인증 토큰
|
|
39
|
-
|
|
40
|
-
Returns:
|
|
41
|
-
인증된 사용자 객체
|
|
42
|
-
|
|
43
|
-
Raises:
|
|
44
|
-
HTTPException: 토큰이 유효하지 않은 경우
|
|
45
|
-
"""
|
|
46
|
-
# 토큰 검증
|
|
47
|
-
payload = decode_jwt(token)
|
|
48
|
-
|
|
49
|
-
# 사용자 조회
|
|
50
|
-
user = await get_user(payload["sub"])
|
|
51
|
-
if not user:
|
|
52
|
-
raise HTTPException(401, detail="인증 실패")
|
|
53
|
-
|
|
54
|
-
return user
|
|
55
|
-
|
|
56
|
-
# ❌ 나쁜 예
|
|
57
|
-
# User authentication middleware
|
|
58
|
-
async def authenticate_user(token: str) -> User:
|
|
59
|
-
"""
|
|
60
|
-
Verify JWT token and return user.
|
|
61
|
-
"""
|
|
62
|
-
# Verify token
|
|
63
|
-
payload = decode_jwt(token)
|
|
64
|
-
|
|
65
|
-
# Get user
|
|
66
|
-
user = await get_user(payload["sub"])
|
|
67
|
-
if not user:
|
|
68
|
-
raise HTTPException(401, detail="Authentication failed")
|
|
69
|
-
|
|
70
|
-
return user
|
|
71
|
-
```
|
|
72
|
-
|
|
73
|
-
### AI 응답 예시
|
|
74
|
-
|
|
75
|
-
```markdown
|
|
76
|
-
# ❌ 영어 응답
|
|
77
|
-
I'll help you create a new API endpoint. First, let's define the schema...
|
|
78
|
-
|
|
79
|
-
# ✅ 한국어 응답
|
|
80
|
-
새로운 API 엔드포인트를 만들어드리겠습니다. 먼저 스키마를 정의하겠습니다...
|
|
81
|
-
```
|
|
82
|
-
|
|
83
|
-
## 📦 체크포인트
|
|
84
|
-
|
|
85
|
-
### 새 패키지 추가 전
|
|
86
|
-
|
|
87
|
-
- [ ] 기존 패키지로 해결 가능한가?
|
|
88
|
-
- [ ] 정말 필요한가?
|
|
89
|
-
- [ ] 번들 크기 영향은?
|
|
90
|
-
|
|
91
|
-
### 파일 생성 시
|
|
92
|
-
|
|
93
|
-
- [ ] 사용 위치 확인
|
|
94
|
-
- [ ] import 즉시 추가
|
|
95
|
-
- [ ] 순환 의존성 체크
|
|
96
|
-
|
|
97
|
-
## 🥇 최우선 원칙: 수술적 정밀도
|
|
98
|
-
|
|
99
|
-
> **⚠️ 이것은 모든 작업에 앞서는 TORY의 첫 번째 원칙입니다.**
|
|
100
|
-
>
|
|
101
|
-
> **요청받지 않은 코드는 절대 수정/삭제하지 않습니다.**
|
|
102
|
-
|
|
103
|
-
- **엄격한 범위 준수**: 사용자가 명시적으로 요청한 파일과 코드 블록만 수정
|
|
104
|
-
- **기존 코드 보존**: 작동하는 코드를 임의로 리팩토링하거나 제거하지 않음
|
|
105
|
-
- **스타일 존중**: 기존 네이밍, 포맷팅, 주석 스타일 유지
|
|
106
|
-
|
|
107
|
-
## 🚀 작업 전 필수 체크리스트
|
|
108
|
-
|
|
109
|
-
```
|
|
110
|
-
[x] 최우선 원칙 준수: 요청 범위 외 절대 수정 금지
|
|
111
|
-
[ ] 기존 코드 존중: 기존 스타일과 구조 유지
|
|
112
|
-
[ ] 문서 규칙 준수: 네이밍, 구조 등 모든 가이드라인 준수
|
|
113
|
-
```
|
|
114
|
-
|
|
115
|
-
## 🎯 황금률
|
|
116
|
-
|
|
117
|
-
- **한국어 우선**: 모든 커뮤니케이션은 명확한 한국어로
|
|
118
|
-
- **단순함의 미학**: 코드가 적을수록 좋은 코드
|
|
119
|
-
- **DRY 원칙**: 반복하지 말고 재사용
|
|
120
|
-
- **단일 책임**: 하나의 함수는 하나의 목적만
|
|
1
|
+
# ⚡ Quick Start - 즉시 적용 가능한 원칙
|
|
2
|
+
|
|
3
|
+
## 🎯 5가지 핵심 원칙
|
|
4
|
+
|
|
5
|
+
```
|
|
6
|
+
✅ 🇰🇷 한국어로 응답 (최우선)
|
|
7
|
+
✅ 📉 코드가 적을수록 부채도 적다
|
|
8
|
+
✅ 🚫 DRY - Don't Repeat Yourself
|
|
9
|
+
✅ 🎯 단일 책임 원칙 (SRP)
|
|
10
|
+
✅ 🙏 YAGNI - You Aren't Gonna Need It
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
## ⚠️ 언어 규칙 (절대 준수)
|
|
14
|
+
|
|
15
|
+
**모든 답변은 한국어로 작성합니다.**
|
|
16
|
+
|
|
17
|
+
### 한국어 사용 원칙
|
|
18
|
+
|
|
19
|
+
1. **설명, 주석, 대화**: 100% 한국어
|
|
20
|
+
2. **코드**: 영어 (프로그래밍 언어 표준)
|
|
21
|
+
3. **기술 용어**: 한국어 우선, 필요시 영어 병기
|
|
22
|
+
- ✅ "의존성 주입 (Dependency Injection)"
|
|
23
|
+
- ✅ "상태 관리 (State Management)"
|
|
24
|
+
- ❌ "Dependency Injection"
|
|
25
|
+
4. **에러 메시지**: 한국어로 설명
|
|
26
|
+
5. **문서 제목/헤더**: 한국어
|
|
27
|
+
|
|
28
|
+
### 예시
|
|
29
|
+
|
|
30
|
+
```python
|
|
31
|
+
# ✅ 좋은 예
|
|
32
|
+
# 사용자 인증 미들웨어
|
|
33
|
+
async def authenticate_user(token: str) -> User:
|
|
34
|
+
"""
|
|
35
|
+
JWT 토큰을 검증하고 사용자를 반환합니다.
|
|
36
|
+
|
|
37
|
+
Args:
|
|
38
|
+
token: JWT 인증 토큰
|
|
39
|
+
|
|
40
|
+
Returns:
|
|
41
|
+
인증된 사용자 객체
|
|
42
|
+
|
|
43
|
+
Raises:
|
|
44
|
+
HTTPException: 토큰이 유효하지 않은 경우
|
|
45
|
+
"""
|
|
46
|
+
# 토큰 검증
|
|
47
|
+
payload = decode_jwt(token)
|
|
48
|
+
|
|
49
|
+
# 사용자 조회
|
|
50
|
+
user = await get_user(payload["sub"])
|
|
51
|
+
if not user:
|
|
52
|
+
raise HTTPException(401, detail="인증 실패")
|
|
53
|
+
|
|
54
|
+
return user
|
|
55
|
+
|
|
56
|
+
# ❌ 나쁜 예
|
|
57
|
+
# User authentication middleware
|
|
58
|
+
async def authenticate_user(token: str) -> User:
|
|
59
|
+
"""
|
|
60
|
+
Verify JWT token and return user.
|
|
61
|
+
"""
|
|
62
|
+
# Verify token
|
|
63
|
+
payload = decode_jwt(token)
|
|
64
|
+
|
|
65
|
+
# Get user
|
|
66
|
+
user = await get_user(payload["sub"])
|
|
67
|
+
if not user:
|
|
68
|
+
raise HTTPException(401, detail="Authentication failed")
|
|
69
|
+
|
|
70
|
+
return user
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
### AI 응답 예시
|
|
74
|
+
|
|
75
|
+
```markdown
|
|
76
|
+
# ❌ 영어 응답
|
|
77
|
+
I'll help you create a new API endpoint. First, let's define the schema...
|
|
78
|
+
|
|
79
|
+
# ✅ 한국어 응답
|
|
80
|
+
새로운 API 엔드포인트를 만들어드리겠습니다. 먼저 스키마를 정의하겠습니다...
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
## 📦 체크포인트
|
|
84
|
+
|
|
85
|
+
### 새 패키지 추가 전
|
|
86
|
+
|
|
87
|
+
- [ ] 기존 패키지로 해결 가능한가?
|
|
88
|
+
- [ ] 정말 필요한가?
|
|
89
|
+
- [ ] 번들 크기 영향은?
|
|
90
|
+
|
|
91
|
+
### 파일 생성 시
|
|
92
|
+
|
|
93
|
+
- [ ] 사용 위치 확인
|
|
94
|
+
- [ ] import 즉시 추가
|
|
95
|
+
- [ ] 순환 의존성 체크
|
|
96
|
+
|
|
97
|
+
## 🥇 최우선 원칙: 수술적 정밀도
|
|
98
|
+
|
|
99
|
+
> **⚠️ 이것은 모든 작업에 앞서는 TORY의 첫 번째 원칙입니다.**
|
|
100
|
+
>
|
|
101
|
+
> **요청받지 않은 코드는 절대 수정/삭제하지 않습니다.**
|
|
102
|
+
|
|
103
|
+
- **엄격한 범위 준수**: 사용자가 명시적으로 요청한 파일과 코드 블록만 수정
|
|
104
|
+
- **기존 코드 보존**: 작동하는 코드를 임의로 리팩토링하거나 제거하지 않음
|
|
105
|
+
- **스타일 존중**: 기존 네이밍, 포맷팅, 주석 스타일 유지
|
|
106
|
+
|
|
107
|
+
## 🚀 작업 전 필수 체크리스트
|
|
108
|
+
|
|
109
|
+
```
|
|
110
|
+
[x] 최우선 원칙 준수: 요청 범위 외 절대 수정 금지
|
|
111
|
+
[ ] 기존 코드 존중: 기존 스타일과 구조 유지
|
|
112
|
+
[ ] 문서 규칙 준수: 네이밍, 구조 등 모든 가이드라인 준수
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
## 🎯 황금률
|
|
116
|
+
|
|
117
|
+
- **한국어 우선**: 모든 커뮤니케이션은 명확한 한국어로
|
|
118
|
+
- **단순함의 미학**: 코드가 적을수록 좋은 코드
|
|
119
|
+
- **DRY 원칙**: 반복하지 말고 재사용
|
|
120
|
+
- **단일 책임**: 하나의 함수는 하나의 목적만
|
|
121
121
|
- **실용주의**: 완벽보다 실용, YAGNI 정신
|