feat: SMS 스캔 전면광고 및 Isolate 버그 수정
## 전면 광고 (AdService) - AdService 클래스 신규 생성 (lunchpick 패턴 참조) - Completer 패턴으로 광고 완료 대기 구현 - 로딩 오버레이로 앱 foreground 상태 유지 - 몰입형 모드 (immersiveSticky) 적용 - iOS 테스트 광고 ID 설정 ## SMS 스캔 버그 수정 - Isolate 내 Flutter 바인딩 접근 오류 해결 - _isoExtractServiceNameFromSender()에서 하드코딩 사용 - 로딩 위젯 화면 정중앙 배치 수정 ## 문서 및 설정 - CLAUDE.md 최적화 (글로벌 규칙 중복 제거) - Claude Code Skills 5개 추가 - flutter-build: 빌드/분석 - hive-model: Hive 모델 관리 - release-deploy: 릴리즈 배포 - sms-scanner: SMS 스캔 디버깅 - admob: 광고 구현 ## 버전 - 1.0.1+2 → 1.0.1+3
This commit is contained in:
JiWoong Sul
377
CLAUDE.md
377
CLAUDE.md
@@ -1,314 +1,111 @@
|
||||
# Claude 프로젝트 컨텍스트
|
||||
# CLAUDE.md
|
||||
|
||||
## 언어 설정
|
||||
- 모든 답변은 한국어로 제공
|
||||
- 기술 용어는 영어와 한국어 병기 가능
|
||||
프로젝트별 가이드. 일반 규칙은 `~/.claude/CLAUDE.md` 참조.
|
||||
|
||||
## 프로젝트 정보
|
||||
- Flutter 기반 구독 관리 앱 (SubManager)
|
||||
## Project Overview
|
||||
|
||||
## 현재 작업
|
||||
- 구독카드가 클릭이 되지 않아서 문제를 찾는 중.
|
||||
**SubManager** - 구독 관리 앱 (Flutter 3.x)
|
||||
|
||||
## 🎯 Mandatory Response Format
|
||||
| 항목 | 기술 |
|
||||
|------|------|
|
||||
| DB | Hive (로컬 전용) |
|
||||
| 상태관리 | Provider + ChangeNotifier |
|
||||
| 디자인 | Material 3 |
|
||||
| 광고 | google_mobile_ads |
|
||||
|
||||
Before starting any task, you MUST respond in the following format:
|
||||
**버전**: 1.0.1+3
|
||||
|
||||
```
|
||||
[Model Name]. I have reviewed all the following rules: [rule file list or categories]. Proceeding with the task. Master!
|
||||
## Quick Commands
|
||||
|
||||
```bash
|
||||
# Hive 모델 생성
|
||||
dart run build_runner build --delete-conflicting-outputs
|
||||
|
||||
# 빌드
|
||||
flutter build apk --release # APK
|
||||
flutter build appbundle --release # AAB (Play Store)
|
||||
|
||||
# 버전업 후 디바이스 설치
|
||||
flutter install --release
|
||||
```
|
||||
|
||||
**Examples:**
|
||||
## Architecture
|
||||
|
||||
- `Claude Sonnet 4. I have reviewed all the following rules: development guidelines, class structure, testing rules. Proceeding with the task. Master!`
|
||||
- For extensive rules: `coding style, class design, exception handling, testing rules` (categorized summary)
|
||||
|
||||
## 🚀 Mandatory 3-Phase Task Process
|
||||
|
||||
### Phase 1: Codebase Exploration & Analysis
|
||||
|
||||
**Required Actions:**
|
||||
|
||||
- Systematically discover ALL relevant files, directories, modules
|
||||
- Search for related keywords, functions, classes, patterns
|
||||
- Thoroughly examine each identified file
|
||||
- Document coding conventions and style guidelines
|
||||
- Identify framework/library usage patterns
|
||||
|
||||
### Phase 2: Implementation Planning
|
||||
|
||||
**Required Actions:**
|
||||
|
||||
- Create detailed implementation roadmap based on Phase 1 findings
|
||||
- Define specific task lists and acceptance criteria per module
|
||||
- Specify performance/quality requirements
|
||||
|
||||
### Phase 3: Implementation Execution
|
||||
|
||||
**Required Actions:**
|
||||
|
||||
- Implement each module following Phase 2 plan
|
||||
- Verify ALL acceptance criteria before proceeding
|
||||
- Ensure adherence to conventions identified in Phase 1
|
||||
|
||||
## ✅ Core Development Principles
|
||||
|
||||
### Language & Type Rules
|
||||
|
||||
- **Write ALL code, variables, and names in English**
|
||||
- **Write ALL comments, documentation, prompts, and responses in Korean**
|
||||
- **Always declare types explicitly** for variables, parameters, and return values
|
||||
- Avoid `any`, `dynamic`, or loosely typed declarations (except when strictly necessary)
|
||||
- Define **custom types** when needed
|
||||
- Extract magic numbers and literals into named constants or enums
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
|Element|Style|Example|
|
||||
|---|---|---|
|
||||
|Classes|`PascalCase`|`UserService`, `DataRepository`|
|
||||
|Variables/Methods|`camelCase`|`userName`, `calculateTotal`|
|
||||
|Files/Folders|`under_score_case`|`user_service.dart`, `data_models/`|
|
||||
|Environment Variables|`UPPERCASE`|`API_URL`, `DATABASE_PASSWORD`|
|
||||
|
||||
**Critical Rules:**
|
||||
|
||||
- **Boolean variables must be verb-based**: `isReady`, `hasError`, `canDelete`
|
||||
- **Function/method names start with verbs**: `executeLogin`, `saveUser`
|
||||
- Use meaningful, descriptive names
|
||||
- Avoid abbreviations unless widely accepted: `i`, `j`, `err`, `ctx`, `API`, `URL`
|
||||
|
||||
## 🔧 Function & Method Design
|
||||
|
||||
### Function Structure Principles
|
||||
|
||||
- **Keep functions short and focused** (≤20 lines recommended)
|
||||
- **Avoid blank lines inside functions**
|
||||
- **Follow Single Responsibility Principle**
|
||||
- **Use verb + object format** for naming:
|
||||
- Boolean return: `isValid`, `canRetry`, `hasPermission`
|
||||
- Void return: `executeLogin`, `saveUser`, `startAnimation`
|
||||
|
||||
### Function Optimization Techniques
|
||||
|
||||
- Use **early returns** to avoid nested logic
|
||||
- Extract logic into helper functions
|
||||
- Prefer **arrow functions** for short expressions (≤3 lines)
|
||||
- Use **named functions** for complex logic
|
||||
- Minimize null checks by using **default values**
|
||||
- Minimize parameters using **RO-RO pattern** (Receive Object – Return Object)
|
||||
|
||||
## 📦 Data & Class Design
|
||||
|
||||
### Class Design Principles
|
||||
|
||||
- **Strictly follow Single Responsibility Principle (SRP)**
|
||||
- **Favor composition over inheritance**
|
||||
- **Define interfaces/abstract classes** to establish contracts
|
||||
- **Prefer immutable data structures** (use `readonly`, `const`)
|
||||
|
||||
### File Size Management
|
||||
|
||||
- **Split by responsibility when exceeding 200 lines** (responsibility-based, not line-based)
|
||||
- ✅ **May remain as-is if**:
|
||||
- Has **single clear responsibility**
|
||||
- Is **easy to maintain**
|
||||
- 🔁 **Must split when**:
|
||||
- Contains **multiple concerns**
|
||||
- Requires **excessive scrolling**
|
||||
- Patterns repeat across files
|
||||
- Difficult for new developer onboarding
|
||||
|
||||
### Class Recommendations
|
||||
|
||||
- ≤ 200 lines (not mandatory)
|
||||
- ≤ 10 public methods
|
||||
- ≤ 10 properties
|
||||
|
||||
### Data Model Design
|
||||
|
||||
- Avoid excessive use of primitives — use **composite types or classes**
|
||||
- Move **validation logic inside data models** (not in business logic)
|
||||
|
||||
## ❗ Exception Handling
|
||||
|
||||
### Exception Usage Principles
|
||||
|
||||
- Use exceptions only for **truly unexpected or critical issues**
|
||||
- **Catch exceptions only to**:
|
||||
- Handle known failure scenarios
|
||||
- Add useful context
|
||||
- Otherwise, let global handlers manage them
|
||||
|
||||
## 🧪 Testing
|
||||
|
||||
### Test Structure
|
||||
|
||||
- Follow **Arrange–Act–Assert** pattern
|
||||
- Clear test variable naming: `inputX`, `mockX`, `actualX`, `expectedX`
|
||||
- **Write unit tests for every public method**
|
||||
|
||||
### Test Doubles Usage
|
||||
|
||||
- Use **test doubles** (mock/fake/stub) for dependencies
|
||||
- Exception: allow real use of **lightweight third-party libraries**
|
||||
|
||||
### Integration Testing
|
||||
|
||||
- Write **integration tests per module**
|
||||
- Follow **Given–When–Then** structure
|
||||
- Ensure **100% test pass rate in CI** and **apply immediate fixes** for failures
|
||||
|
||||
## 📝 Git Commit Guidelines
|
||||
|
||||
### Commit Message Format
|
||||
|
||||
- **Use clear, descriptive commit messages in Korean**
|
||||
- **Follow conventional commit format**: `type: description`
|
||||
- **Keep commit messages concise and focused**
|
||||
- **DO NOT include Claude Code attribution or co-author tags**
|
||||
|
||||
### Commit Message Structure
|
||||
|
||||
```
|
||||
type: brief description in Korean
|
||||
|
||||
Optional detailed explanation if needed
|
||||
```text
|
||||
lib/
|
||||
├── controllers/ # 비즈니스 로직 (3개)
|
||||
│ ├── add_subscription_controller.dart
|
||||
│ ├── detail_screen_controller.dart
|
||||
│ └── sms_scan_controller.dart
|
||||
├── models/ # Hive 모델 (@HiveType)
|
||||
│ ├── subscription_model.dart (typeId: 0)
|
||||
│ ├── category_model.dart (typeId: 1)
|
||||
│ └── payment_card_model.dart (typeId: 2)
|
||||
├── providers/ # ChangeNotifier 상태관리
|
||||
├── screens/ # 화면 위젯
|
||||
├── services/ # 외부 서비스 연동
|
||||
├── widgets/ # 재사용 컴포넌트
|
||||
├── utils/ # 유틸리티 헬퍼
|
||||
├── routes/ # 라우팅 정의
|
||||
├── theme/ # 테마/색상
|
||||
└── l10n/ # 다국어 (ko/en/ja/zh)
|
||||
```
|
||||
|
||||
### Commit Types
|
||||
## Key Services
|
||||
|
||||
- `feat`: 새로운 기능 추가
|
||||
- `fix`: 버그 수정
|
||||
- `refactor`: 코드 리팩토링
|
||||
- `style`: 코드 스타일 변경 (formatting, missing semi-colons, etc)
|
||||
- `docs`: 문서 변경
|
||||
- `test`: 테스트 코드 추가 또는 수정
|
||||
- `chore`: 빌드 프로세스 또는 보조 도구 변경
|
||||
| Service | 역할 |
|
||||
|---------|------|
|
||||
| `AdService` | 전면 광고 (Completer 패턴) |
|
||||
| `SmsScanner` | SMS 파싱 → 구독 자동 감지 (Isolate 사용) |
|
||||
| `NotificationService` | 로컬 알림 |
|
||||
| `ExchangeRateService` | 환율 조회 |
|
||||
| `url_matcher/` | 서비스명 → URL 매칭 |
|
||||
|
||||
### Examples
|
||||
## Routes
|
||||
|
||||
✅ **Good Examples:**
|
||||
- `feat: 월별 차트 다국어 지원 추가`
|
||||
- `fix: 분석화면 총지출 금액 불일치 문제 해결`
|
||||
- `refactor: 통화 변환 로직 모듈화`
|
||||
| Path | Screen |
|
||||
|------|--------|
|
||||
| `/` | MainScreen |
|
||||
| `/add-subscription` | AddSubscriptionScreen |
|
||||
| `/subscription-detail` | DetailScreen (requires SubscriptionModel) |
|
||||
| `/sms-scanner` | SmsScanScreen |
|
||||
| `/analysis` | AnalysisScreen |
|
||||
| `/settings` | SettingsScreen |
|
||||
| `/payment-card-management` | PaymentCardManagementScreen |
|
||||
|
||||
❌ **Avoid These:**
|
||||
- Including "🤖 Generated with [Claude Code](https://claude.ai/code)"
|
||||
- Including "Co-Authored-By: Claude <noreply@anthropic.com>"
|
||||
- Vague messages like "update code" or "fix stuff"
|
||||
- English commit messages (use Korean)
|
||||
## Project Rules
|
||||
|
||||
### Critical Rules
|
||||
1. **로컬 전용**: 서버/Firebase/외부 DB 금지
|
||||
2. **권한 거부 시**: 수동 입력 폴백 (SMS), 기능 비활성화 (알림)
|
||||
3. **외부 API**: Clearbit Logo API만 허용
|
||||
4. **Isolate 주의**: `compute()` 내부에서 Flutter 바인딩/Context 접근 불가
|
||||
|
||||
- **NEVER include AI tool attribution in commit messages**
|
||||
- **Focus on what was changed and why**
|
||||
- **Use present tense and imperative mood**
|
||||
- **Keep the first line under 50 characters when possible**
|
||||
## Known Patterns
|
||||
|
||||
## 🧠 Error Analysis & Rule Documentation
|
||||
### 전면 광고 (AdService)
|
||||
|
||||
### Mandatory Process When Errors Occur
|
||||
|
||||
1. **Analyze root cause in detail**
|
||||
2. **Document preventive rule in `.cursor/rules/error_analysis.mdc`**
|
||||
3. **Write in English including**:
|
||||
- Error description and context
|
||||
- Cause and reproducibility steps
|
||||
- Resolution approach
|
||||
- Rule for preventing future recurrences
|
||||
- Sample code and references to related rules
|
||||
|
||||
### Rule Writing Standards
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: Clear, one-line description of what the rule enforces
|
||||
globs: path/to/files/*.ext, other/path/**/*
|
||||
alwaysApply: boolean
|
||||
---
|
||||
|
||||
**Main Points in Bold**
|
||||
- Sub-points with details
|
||||
- Examples and explanations
|
||||
```dart
|
||||
// Completer 패턴으로 광고 완료 대기
|
||||
final completer = Completer<bool>();
|
||||
ad.fullScreenContentCallback = FullScreenContentCallback(
|
||||
onAdDismissedFullScreenContent: (ad) {
|
||||
completer.complete(true);
|
||||
},
|
||||
);
|
||||
ad.show();
|
||||
return completer.future;
|
||||
```
|
||||
|
||||
## 🏗️ Architectural Guidelines
|
||||
### SMS 스캔 (Isolate)
|
||||
|
||||
### Clean Architecture Compliance
|
||||
```dart
|
||||
// Isolate 내부에서는 하드코딩 사용
|
||||
// Flutter 바인딩, Context, Provider 접근 불가
|
||||
return 'Unknown service'; // AppLocalizations 사용 불가
|
||||
```
|
||||
|
||||
- **Layered structure**: `modules`, `controllers`, `services`, `repositories`, `entities`
|
||||
- Apply **Repository Pattern** for data abstraction
|
||||
- Use **Dependency Injection** (`getIt`, `inject`, etc.)
|
||||
- Controllers handle business logic (not view processing)
|
||||
## Response Format
|
||||
|
||||
### Code Structuring
|
||||
|
||||
- **One export or public declaration per file**
|
||||
- Centralize constants, error messages, and configuration
|
||||
- Make **all shared logic reusable** and place in dedicated helper modules
|
||||
|
||||
## 🌲 UI Structure & Component Design
|
||||
|
||||
### UI Optimization Principles
|
||||
|
||||
- **Avoid deeply nested widget/component trees**:
|
||||
- Flatten hierarchy for **better performance and readability**
|
||||
- Easier **state management and testability**
|
||||
- **Split large components into small, focused widgets/components**
|
||||
- Use `const` constructors (or equivalents) for performance optimization
|
||||
- Apply clear **naming and separation** between view, logic, and data layers
|
||||
|
||||
## 📈 Continuous Rule Improvement
|
||||
|
||||
### Rule Improvement Triggers
|
||||
|
||||
- New code patterns not covered by existing rules
|
||||
- Repeated similar implementations across files
|
||||
- Common error patterns that could be prevented
|
||||
- New libraries or tools being used consistently
|
||||
- Emerging best practices in the codebase
|
||||
|
||||
### Rule Update Criteria
|
||||
|
||||
**Add New Rules When:**
|
||||
|
||||
- A new technology/pattern is used in 3+ files
|
||||
- Common bugs could be prevented by a rule
|
||||
- Code reviews repeatedly mention the same feedback
|
||||
|
||||
**Modify Existing Rules When:**
|
||||
|
||||
- Better examples exist in the codebase
|
||||
- Additional edge cases are discovered
|
||||
- Related rules have been updated
|
||||
|
||||
## ✅ Quality Validation Checklist
|
||||
|
||||
Before completing any task, confirm:
|
||||
|
||||
- ✅ All three phases completed sequentially
|
||||
- ✅ Each phase output meets specified format requirements
|
||||
- ✅ Implementation satisfies all acceptance criteria
|
||||
- ✅ Code quality meets professional standards
|
||||
- ✅ Started with mandatory response format
|
||||
- ✅ All naming conventions followed
|
||||
- ✅ Type safety ensured
|
||||
- ✅ Single Responsibility Principle adhered to
|
||||
|
||||
## 🎯 Success Validation Framework
|
||||
|
||||
### Expert-Level Standards Verification
|
||||
|
||||
- **Minimalistic Approach**: High-quality, clean solutions without unnecessary complexity
|
||||
- **Professional Standards**: Every output meets industry-standard software engineering practices
|
||||
- **Concrete Results**: Specific, actionable details at each step
|
||||
|
||||
### Final Quality Gates
|
||||
|
||||
- [ ] All acceptance criteria validated
|
||||
- [ ] Code follows established conventions
|
||||
- [ ] Minimalistic approach maintained
|
||||
- [ ] Expert-level implementation standards met
|
||||
- [ ] Korean comments and documentation provided
|
||||
- [ ] English code and variable names used consistently
|
||||
```text
|
||||
[모델명]. I have reviewed all the following rules: [규칙]. Proceeding with the task. Master!
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user