julian/lunchpick
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(config): 프로젝트 설정 및 문서 개선

Browse Source 
## CLAUDE.md 전면 개편
- 글로벌 규칙(~/.claude/CLAUDE.md)과 중복되는 일반 개발 가이드라인 제거
- 프로젝트 특화 정보만 유지 (331줄 → 100줄, 약 70% 감소)
- 추가된 내용:
  - 앱 이름, 패키지명, SDK 버전 명시
  - 핵심 기술 스택 테이블 (Riverpod, Hive, go_router, Dio 등)
  - 실제 프로젝트 디렉토리 구조 문서화
  - 주요 도메인 엔티티 설명 (Restaurant, VisitRecord 등)
  - 프로젝트 전용 빌드 명령어
- AGENTS.md 참조 링크 추가

## Android 릴리즈 서명 설정
- build.gradle.kts에 릴리즈 signingConfig 추가
- 키스토어: doc/key/lunchpick-release.keystore
- release 빌드 타입에 릴리즈 서명 적용
- 불필요한 TODO 주석 제거

## 개인정보 처리방침 문구 수정
- "네이버 지도 연동" → "네이버 검색 연동" (실제 동작 반영)
- "네이버 지도에서 가져온" → "네이버 URL에서 가져온" (정확한 표현)
- 미사용 Open API 관련 문구 제거
This commit is contained in:
JiWoong Sul
2025-12-08 18:15:22 +09:00
parent cf7e187985
commit 42c609c57a
3 changed files with 90 additions and 318 deletions
Download Patch File Download Diff File Expand all files Collapse all files

387
CLAUDE.md
View File

@@ -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.
- `api_keys.dart`는 커밋 금지 (로컬 생성)
- Android/iOS 빌드 설정 변경 시 승인 필요
- Hive 스키마 변경 시 마이그레이션 고려
- 네이버 API 호출 시 캐시 정책 준수

16
android/app/build.gradle.kts
View File

@@ -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")
}
}
}

5
doc/store_desc/privacy_policy.md
View File

@@ -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**
- 전송되는 정보(예시): 사용자가 입력한 식당 주소(도로명·지번 등)