diff --git a/CLAUDE.md b/CLAUDE.md index 314353e..fc79ef5 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1,331 +1,100 @@ -# Claude Code Global Development Rules +# LunchPick - 점심 메뉴 추천 앱 -## 🌐 Language Settings -- **All answers and explanations must be provided in Korean** -- **Variable and function names in code should use English** -- **Error messages should be explained in Korean** +> 글로벌 규칙(~/.claude/CLAUDE.md) 상속. 상세 가이드는 [AGENTS.md](AGENTS.md) 참조. -## 🤖 Agent Selection Rules -- **Always select and use a specialized agent appropriate for the task** +## 프로젝트 개요 -## 🎯 Mandatory Response Format +- **앱 이름**: 오늘 뭐 먹Z? +- **패키지**: `com.naturebridgeai.lunchpick` +- **SDK**: Flutter 3.8.1+ / Dart 3.8.1+ -Before starting any task, you MUST respond in the following format: +## 핵심 기술 스택 -``` -[Model Name] - [Agent Name]. I have reviewed all the following rules: [rule file list or categories]. Proceeding with the task. Master! +| 분류 | 패키지 | +|------|--------| +| 상태관리 | Riverpod + riverpod_generator | +| 로컬저장 | Hive + hive_generator | +| 네비게이션 | go_router | +| 네트워크 | Dio + dio_cache_interceptor | +| 위치/권한 | geolocator, permission_handler | +| 광고 | google_mobile_ads | + +## 프로젝트 구조 + +```text +lib/ +├── core/ +│ ├── constants/ # app_constants, app_colors, api_keys +│ ├── network/ # network_client, interceptors +│ ├── services/ # permission, geocoding, ad, bluetooth, notification +│ ├── errors/ # app_exceptions, network_exceptions +│ └── widgets/ # 공통 위젯 (loading, error, empty_state) +├── data/ +│ ├── api/ # naver_api_client, naver GraphQL/LocalSearch +│ ├── datasources/ # local, remote (naver_html_parser 등) +│ ├── repositories/ # *_repository_impl +│ └── models/ # DTO, Hive adapters +├── domain/ +│ ├── entities/ # Restaurant, VisitRecord, UserSettings, WeatherInfo +│ ├── repositories/ # 인터페이스 정의 +│ └── usecases/ # 비즈니스 로직 +└── presentation/ + ├── providers/ # Riverpod providers + ├── view_models/ # 화면 상태 관리 + └── pages/ # splash, main, random_selection, restaurant_list, + # calendar, settings, share ``` -**Agent Names:** -- **Direct Implementation**: Perform direct implementation tasks -- **Master Manager**: Overall project management and coordination -- **flutter-ui-designer**: Flutter UI/UX design -- **flutter-architecture-designer**: Flutter architecture design -- **flutter-offline-developer**: Flutter offline functionality development -- **flutter-network-engineer**: Flutter network implementation -- **flutter-qa-engineer**: Flutter QA/testing -- **app-launch-validator**: App launch validation -- **aso-optimization-expert**: ASO optimization -- **mobile-growth-hacker**: Mobile growth strategy -- **Idea Analysis**: Idea analysis -- **mobile app mvp planner**: MVP planning +## 주요 도메인 엔티티 -**Examples:** -- `Claude Opus 4 - Direct Implementation. I have reviewed all the following rules: development guidelines, class structure, testing rules. Proceeding with the task. Master!` -- `Claude Opus 4 - flutter-network-engineer. I have reviewed all the following rules: API integration, error handling, network optimization. Proceeding with the task. Master!` -- For extensive rules: `coding style, class design, exception handling, testing rules` (categorized summary) +- `Restaurant`: 음식점 정보 (이름, 카테고리, 위치, 영업시간 등) +- `VisitRecord`: 방문 기록 +- `RecommendationRecord`: 추천 기록 +- `UserSettings`: 사용자 설정 (반경, 카테고리 필터 등) +- `WeatherInfo`: 날씨 정보 (추천 알고리즘 활용) +## 필수 명령어 +```bash +# 의존성 설치 +flutter pub get -## 🚀 Mandatory 3-Phase Task Process +# 코드 생성 (Hive adapters, Riverpod, JSON) +dart run build_runner build --delete-conflicting-outputs -### 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 -- Map dependencies and architectural structure +# 개발 중 자동 생성 +dart run build_runner watch --delete-conflicting-outputs -### 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 -- Plan test strategy and coverage -- Identify potential risks and edge cases +# 분석 & 테스트 +flutter analyze +flutter test +flutter test test_hive # Hive 변경 시 -### 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 -- Write tests alongside implementation -- Document complex logic and design decisions - -## ✅ Core Development Principles - -### Language & Documentation Rules -- **Code, variables, and identifiers**: Always in English -- **Comments and documentation**: Use project's primary spoken language -- **Commit messages**: Use project's primary spoken language -- **Error messages**: Bilingual when appropriate (technical term + native explanation) - -### Type Safety Rules -- **Always declare types explicitly** for variables, parameters, and return values -- Avoid `any`, `dynamic`, or loosely typed declarations (except when strictly necessary) -- Define **custom types/interfaces** for complex data structures -- Use **enums** for fixed sets of values -- Extract magic numbers and literals into named constants - -### Naming Conventions - -|Element|Style|Example| -|---|---|---| -|Classes/Interfaces|`PascalCase`|`UserService`, `DataRepository`| -|Variables/Methods|`camelCase`|`userName`, `calculateTotal`| -|Constants|`UPPERCASE` or `PascalCase`|`MAX_RETRY_COUNT`, `DefaultTimeout`| -|Files (varies by language)|Follow language convention|`user_service.py`, `UserService.java`| -|Boolean variables|Verb-based|`isReady`, `hasError`, `canDelete`| -|Functions/Methods|Start with verbs|`executeLogin`, `saveUser`, `validateInput`| - -**Critical Rules:** -- Use meaningful, descriptive names -- Avoid abbreviations unless widely accepted: `i`, `j`, `err`, `ctx`, `API`, `URL` -- Name length should reflect scope (longer names for wider scope) - -## 🔧 Function & Method Design - -### Function Structure Principles -- **Keep functions short and focused** (≤20 lines recommended) -- **Follow Single Responsibility Principle (SRP)** -- **Minimize parameters** (≤3 ideal, use objects for more) -- **Avoid deeply nested logic** (≤3 levels) -- **Use early returns** to reduce complexity -- **Extract complex conditions** into well-named functions - -### Function Optimization Techniques -- Prefer **pure functions** without side effects -- Use **default parameters** to reduce overloading -- Apply **RO-RO pattern** (Receive Object – Return Object) for complex APIs -- **Cache expensive computations** when appropriate -- **Avoid premature optimization** - profile first - -## 📦 Data & Class Design - -### Class Design Principles -- **Single Responsibility Principle (SRP)**: One class, one purpose -- **Favor composition over inheritance** -- **Program to interfaces**, not implementations -- **Keep classes cohesive** - high internal, low external coupling -- **Prefer immutability** when possible - -### File Size Management -**Guidelines (not hard limits):** -- Classes: ≤200 lines -- Functions: ≤20 lines -- Files: ≤300 lines - -**Split when:** -- Multiple responsibilities exist -- Excessive scrolling required -- Pattern duplication occurs -- Testing becomes complex - -### Data Model Design -- **Encapsulate validation** within data models -- **Use Value Objects** for complex primitives -- **Apply Builder pattern** for complex object construction -- **Implement proper equals/hashCode** for data classes - -## ❗ Exception Handling - -### Exception Usage Principles -- Use exceptions for **exceptional circumstances only** -- **Fail fast** at system boundaries -- **Catch exceptions only when you can handle them** -- **Add context** when re-throwing -- **Use custom exceptions** for domain-specific errors -- **Document thrown exceptions** - -### Error Handling Strategies -- Return **Result/Option types** for expected failures -- Use **error codes** for performance-critical paths -- Implement **circuit breakers** for external dependencies -- **Log errors appropriately** (error level, context, stack trace) - -## 🧪 Testing Strategy - -### Test Structure -- Follow **Arrange-Act-Assert (AAA)** pattern -- Use **descriptive test names** that explain what and why -- **One assertion per test** (when practical) -- **Test behavior, not implementation** - -### Test Coverage Guidelines -- **Unit tests**: All public methods and edge cases -- **Integration tests**: Critical paths and external integrations -- **End-to-end tests**: Key user journeys -- Aim for **80%+ code coverage** (quality over quantity) - -### Test Best Practices -- **Use test doubles** (mocks, stubs, fakes) appropriately -- **Keep tests independent** and idempotent -- **Test data builders** for complex test setups -- **Parameterized tests** for multiple scenarios -- **Performance tests** for critical paths - -## 📝 Version Control Guidelines - -### Commit Best Practices -- **Atomic commits**: One logical change per commit -- **Frequent commits**: Small, incremental changes -- **Clean history**: Use interactive rebase when needed -- **Branch strategy**: Follow project's branching model - -### Commit Message Format -``` -type(scope): brief description - -Detailed explanation if needed -- Bullet points for multiple changes -- Reference issue numbers: #123 - -BREAKING CHANGE: description (if applicable) +# 릴리즈 빌드 +flutter build appbundle --release ``` -### Commit Types -- `feat`: New feature -- `fix`: Bug fix -- `refactor`: Code refactoring -- `perf`: Performance improvement -- `test`: Test changes -- `docs`: Documentation -- `style`: Code formatting -- `chore`: Build/tooling changes +## Agent 응답 형식 -## 🏗️ Architecture Guidelines - -### Clean Architecture Principles -- **Dependency Rule**: Dependencies point inward -- **Layer Independence**: Each layer has single responsibility -- **Testability**: Business logic independent of frameworks -- **Framework Agnostic**: Core logic doesn't depend on external tools - -### Common Architectural Patterns -- **Repository Pattern**: Abstract data access -- **Service Layer**: Business logic coordination -- **Dependency Injection**: Loose coupling -- **Event-Driven**: For asynchronous workflows -- **CQRS**: When read/write separation needed - -### Module Organization -``` -src/ -├── domain/ # Business entities and rules -├── application/ # Use cases and workflows -├── infrastructure/ # External dependencies -├── presentation/ # UI/API layer -└── shared/ # Cross-cutting concerns +```text +[Model Name] - [Agent Name]. I have reviewed all the following rules: [categories]. Proceeding with the task. Master! ``` -## 🔄 Safe Refactoring Practices +### Available Agents -### Preventing Side Effects During Refactoring -- **Run all tests before and after** every refactoring step -- **Make incremental changes**: One small refactoring at a time -- **Use automated refactoring tools** when available (IDE support) -- **Preserve existing behavior**: Refactoring should not change functionality -- **Create characterization tests** for legacy code before refactoring -- **Use feature flags** for large-scale refactorings -- **Monitor production metrics** after deployment +| Agent | 용도 | +|-------|------| +| Direct Implementation | 직접 구현 | +| flutter-ui-designer | UI/UX 디자인 | +| flutter-architecture-designer | 아키텍처 설계 | +| flutter-network-engineer | 네트워크/API | +| flutter-qa-engineer | QA/테스트 | +| app-launch-validator | 출시 검증 | +| aso-optimization-expert | ASO 최적화 | -### Refactoring Checklist -1. **Before Starting**: - - [ ] All tests passing - - [ ] Understand current behavior completely - - [ ] Create backup branch - - [ ] Document intended changes +## 주의사항 -2. **During Refactoring**: - - [ ] Keep commits atomic and reversible - - [ ] Run tests after each change - - [ ] Verify no behavior changes - - [ ] Check for performance impacts - -3. **After Completion**: - - [ ] All tests still passing - - [ ] Code coverage maintained or improved - - [ ] Performance benchmarks verified - - [ ] Peer review completed - -### Common Refactoring Patterns -- **Extract Method**: Break large functions into smaller ones -- **Rename**: Improve clarity with better names -- **Move**: Relocate code to appropriate modules -- **Extract Variable**: Make complex expressions readable -- **Inline**: Remove unnecessary indirection -- **Extract Interface**: Decouple implementations - -## 🧠 Continuous Improvement - -### Code Review Focus Areas -- **Correctness**: Does it work as intended? -- **Clarity**: Is it easy to understand? -- **Consistency**: Does it follow conventions? -- **Completeness**: Are edge cases handled? -- **Performance**: Are there obvious bottlenecks? -- **Security**: Are there vulnerabilities? -- **Side Effects**: Are there unintended consequences? - -### Knowledge Sharing -- **Document decisions** in ADRs (Architecture Decision Records) -- **Create runbooks** for operational procedures -- **Maintain README** files for each module -- **Share learnings** through team discussions -- **Update rules** based on team consensus - -## ✅ Quality Validation Checklist - -Before completing any task, confirm: - -### Phase Completion -- [ ] Phase 1: Comprehensive analysis completed -- [ ] Phase 2: Detailed plan with acceptance criteria -- [ ] Phase 3: Implementation meets all criteria - -### Code Quality -- [ ] Follows naming conventions -- [ ] Type safety enforced -- [ ] Single Responsibility maintained -- [ ] Proper error handling -- [ ] Adequate test coverage -- [ ] Documentation complete - -### Best Practices -- [ ] No code smells or anti-patterns -- [ ] Performance considerations addressed -- [ ] Security vulnerabilities checked -- [ ] Accessibility requirements met -- [ ] Internationalization ready (if applicable) - -## 🎯 Success Metrics - -### Code Quality Indicators -- **Low cyclomatic complexity** (≤10 per function) -- **High cohesion**, low coupling -- **Minimal code duplication** (<5%) -- **Clear separation of concerns** -- **Consistent style throughout** - -### Professional Standards -- **Readable**: New developers understand quickly -- **Maintainable**: Changes are easy to make -- **Testable**: Components tested in isolation -- **Scalable**: Handles growth gracefully -- **Reliable**: Fails gracefully with clear errors - ---- - -**Remember**: These are guidelines, not rigid rules. Use professional judgment and adapt to project needs while maintaining high quality standards. \ No newline at end of file +- `api_keys.dart`는 커밋 금지 (로컬 생성) +- Android/iOS 빌드 설정 변경 시 승인 필요 +- Hive 스키마 변경 시 마이그레이션 고려 +- 네이버 API 호출 시 캐시 정책 준수 diff --git a/android/app/build.gradle.kts b/android/app/build.gradle.kts index 3d67b97..16d3a9f 100644 --- a/android/app/build.gradle.kts +++ b/android/app/build.gradle.kts @@ -20,11 +20,17 @@ android { jvmTarget = JavaVersion.VERSION_11.toString() } + signingConfigs { + create("release") { + storeFile = file("../../doc/key/lunchpick-release.keystore") + storePassword = "lunchpick" + keyAlias = "lunchpick" + keyPassword = "lunchpick" + } + } + defaultConfig { - // TODO: Specify your own unique Application ID (https://developer.android.com/studio/build/application-id.html). applicationId = "com.naturebridgeai.lunchpick" - // You can update the following values to match your application needs. - // For more information, see: https://flutter.dev/to/review-gradle-config. minSdk = flutter.minSdkVersion targetSdk = flutter.targetSdkVersion versionCode = flutter.versionCode @@ -37,9 +43,7 @@ android { buildTypes { release { - // TODO: Add your own signing config for the release build. - // Signing with the debug keys for now, so `flutter run --release` works. - signingConfig = signingConfigs.getByName("debug") + signingConfig = signingConfigs.getByName("release") } } } diff --git a/doc/store_desc/privacy_policy.md b/doc/store_desc/privacy_policy.md index dca46c8..0202ef9 100644 --- a/doc/store_desc/privacy_policy.md +++ b/doc/store_desc/privacy_policy.md @@ -3,7 +3,7 @@ 오늘 뭐 먹Z? (이하 “앱”)는 사용자의 개인정보 보호를 최우선 가치로 삼습니다. 앱은 점심 메뉴 추천 및 맛집 관리 기능 제공을 위해 최소한의 정보만을 사용하며, **개발자가 직접 운영하는 별도 서버를 두지 않습니다.** -다만, 위치 기반 추천, 날씨 정보 제공, 네이버 지도 연동, 광고 노출 및 좌표 확인을 위해 제3자 서비스와 통신할 수 있습니다. +다만, 위치 기반 추천, 날씨 정보 제공, 네이버 검색 연동, 광고 노출 및 좌표 확인을 위해 제3자 서비스와 통신할 수 있습니다. 본 개인정보 처리방침은 앱이 어떤 정보를 어떤 목적과 방식으로 처리하는지 설명합니다. @@ -38,7 +38,7 @@ 2) **맛집 및 방문 기록 정보** - 내용 - - 사용자가 직접 입력하거나 네이버 지도에서 가져온 식당 정보 + - 사용자가 직접 입력하거나 네이버 URL에서 가져온 식당 정보 - 식당 이름, 카테고리, 설명, 전화번호, 도로명/지번 주소 - 위도·경도, 주소, 영업시간 등 - 방문 기록 및 통계 정보 @@ -73,7 +73,6 @@ - **지도·식당 정보 제공을 위한 네이버 지도 웹 서비스** - 전송되는 정보(예시): 사용자가 앱에 붙여넣은 네이버 지도 URL, 해당 URL에 포함된 식당 ID 등 - 사용 목적: 네이버 지도 페이지 및 관련 API(예: GraphQL)를 통해 식당 이름·주소·좌표·전화번호 등을 조회하고, 앱 내 식당 정보로 변환 - - 현재 버전에서는 네이버의 “로컬 검색 Open API(키 기반 검색)”를 사용하지 않으며, 사용자가 제공한 지도 링크를 기반으로 한 페이지 파싱 방식만 사용합니다. - **지오코딩(Geocoding) 서비스: OpenStreetMap Nominatim** - 전송되는 정보(예시): 사용자가 입력한 식당 주소(도로명·지번 등)