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

refactor: 프로젝트 구조 개선 및 테스트 시스템 강화
Some checks failed
Flutter Test & Quality Check / Test on macos-latest (push) Has been cancelled
Details
Flutter Test & Quality Check / Test on ubuntu-latest (push) Has been cancelled
Details
Flutter Test & Quality Check / Build APK (push) Has been cancelled
Details

Browse Source 
주요 변경사항:
- CLAUDE.md: 프로젝트 규칙 v2.0으로 업데이트, 아키텍처 명확화
- 불필요한 문서 제거: NEXT_TASKS.md, TEST_PROGRESS.md, test_results 파일들
- 테스트 시스템 개선: 실제 API 테스트 스위트 추가 (15개 새 테스트 파일)
- License 관리: DTO 모델 개선, API 응답 처리 최적화
- 에러 처리: Interceptor 로직 강화, 상세 로깅 추가
- Company/User/Warehouse 테스트: 자동화 테스트 안정성 향상
- Phone Utils: 전화번호 포맷팅 로직 개선
- Overview Controller: 대시보드 데이터 로딩 최적화
- Analysis Options: Flutter 린트 규칙 추가

테스트 개선:
- company_real_api_test.dart: 실제 API 회사 관리 테스트
- equipment_in/out_real_api_test.dart: 장비 입출고 API 테스트
- license_real_api_test.dart: 라이선스 관리 API 테스트
- user_real_api_test.dart: 사용자 관리 API 테스트
- warehouse_location_real_api_test.dart: 창고 위치 API 테스트
- filter_sort_test.dart: 필터링/정렬 기능 테스트
- pagination_test.dart: 페이지네이션 테스트
- interactive_search_test.dart: 검색 기능 테스트
- overview_dashboard_test.dart: 대시보드 통합 테스트

코드 품질:
- 모든 서비스에 에러 처리 강화
- DTO 모델 null safety 개선
- 테스트 커버리지 확대
- 불필요한 로그 파일 제거로 리포지토리 정리

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
JiWoong Sul
2025-08-07 17:16:30 +09:00
parent fe05094392
commit c8dd1ff815
79 changed files with 12558 additions and 9761 deletions
Download Patch File Download Diff File Expand all files Collapse all files

776
CLAUDE.md
View File

@@ -1,468 +1,376 @@
# Claude Code Global Development Rules
# Superport ERP System - Project Rules v2.0
## 🌐 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**
> 💡 **Note**: Global Claude Code rules from `~/.claude/CLAUDE.md` are automatically applied. This document contains **project-specific** configurations only.
## 🤖 Agent Selection Rules
- **Always select and use a specialized agent appropriate for the task**
- **Utilize parallel processing when multiple agents can work simultaneously**
- **Design custom agents when existing ones don't meet specific needs**
## 🎯 Project Identity
## 🎯 Mandatory Response Format
**Superport**는 Rust 백엔드 + Flutter 웹/모바일 기반의 **엔터프라이즈 ERP 시스템**입니다.
Before starting any task, you MUST respond in the following format:
### Core Domains
- **Equipment Management**: 장비 입고/출고, 시리얼 번호 추적, 재고 관리
- **Company Management**: 고객사 정보, 다중 지점 관리
- **User Management**: 역할 기반 접근 제어 (S: 관리자, M: 멤버)
- **License Management**: 유지보수 라이선스, 만료일 추적
- **Warehouse Management**: 창고 위치 체계적 관리
## 🏗️ Architecture Rules
### Clean Architecture Structure
```
[Model Name] - [Agent Name]. I have reviewed all the following rules: [rule file list or categories]. Proceeding with the task. Master!
lib/
├── core/ # ⚠️ 핵심 설정 - 신중히 수정
│ ├── api_client.dart # Dio/Retrofit 설정
│ ├── exceptions.dart # 전역 예외 처리
│ └── navigation.dart # 라우팅 관리
├── data/ # 데이터 레이어
│ ├── dto/ # API 응답 모델 (Freezed)
│ ├── repositories/ # 데이터 소스 추상화
│ └── services/ # API 서비스 (Retrofit)
├── domain/ # 비즈니스 로직
│ ├── entities/ # 도메인 모델
│ ├── repositories/ # Repository 인터페이스
│ └── usecases/ # 비즈니스 로직
├── services/ # 애플리케이션 서비스
│ ├── auth_service.dart # JWT 인증 관리
│ ├── api_service.dart # API 호출 관리
│ └── storage_service.dart # 로컬 저장소
├── screens/ # Feature-First UI
│ └── [feature]/
│ ├── controllers/ # Provider 기반 상태 관리
│ ├── widgets/ # 재사용 컴포넌트
│ └── [feature]_form.dart
└── di/ # GetIt 의존성 주입
```
**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
- **flutter-web-expansion-specialist**: Flutter web platform expansion
- **app-launch-validator**: App launch validation
- **aso-optimization-expert**: ASO optimization
- **mobile-growth-hacker**: Mobile growth strategy
- **mobile-app-startup-mentor**: Mobile app startup mentoring
- **mobile app mvp planner**: MVP planning
- **app-store-optimizer**: App store optimization
- **tiktok-strategist**: TikTok marketing strategy
- **rapid-prototyper**: Rapid prototype development
- **test-writer-fixer**: Test writing and fixing
- **backend-architect**: Backend architecture design
- **mobile-app-builder**: Mobile app development
- **frontend-developer**: Frontend development
- **devops-automator**: DevOps automation
- **ai-engineer**: AI/ML implementation
- **workflow-optimizer**: Workflow optimization
- **test-results-analyzer**: Test results analysis
- **performance-benchmarker**: Performance testing
- **api-tester**: API testing
- **tool-evaluator**: Tool evaluation
- **sprint-prioritizer**: Sprint planning and prioritization
- **feedback-synthesizer**: User feedback analysis
- **trend-researcher**: Market trend research
- **studio-producer**: Studio production coordination
- **project-shipper**: Project launch management
- **experiment-tracker**: Experiment tracking
- **studio-coach**: Elite performance coaching
- **whimsy-injector**: UI/UX delight injection
- **ui-designer**: UI design
- **brand-guardian**: Brand management
- **ux-researcher**: UX research
- **visual-storyteller**: Visual narrative creation
- **legal-compliance-checker**: Legal compliance
- **analytics-reporter**: Analytics reporting
- **support-responder**: Customer support
- **finance-tracker**: Financial management
- **infrastructure-maintainer**: Infrastructure maintenance
- **joker**: Humor and morale boost
**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)
## 🚀 Agent Utilization Strategy
### Optimal Solution Derivation
- **Analyze task requirements** to identify the most suitable agent(s)
- **Consider agent specializations** and select based on expertise match
- **Evaluate complexity** to determine if multiple agents are needed
- **Prioritize solutions** that minimize side effects and maximize efficiency
### Parallel Processing Guidelines
- **Identify independent tasks** that can be executed simultaneously
- **Launch multiple agents** concurrently when tasks don't have dependencies
- **Coordinate results** from parallel agents to ensure consistency
- **Monitor resource usage** to prevent system overload
- **Example scenarios**:
- UI design + Architecture planning
- Testing + Documentation
- Performance optimization + Security audit
### Side Effect Prevention
- **Analyze impact** before implementing any solution
- **Isolate changes** to minimize unintended consequences
- **Implement rollback strategies** for critical operations
- **Test thoroughly** in isolated environments first
- **Document all changes** and their potential impacts
- **Use feature flags** for gradual rollouts
- **Monitor system behavior** after implementations
### Custom Agent Design
When existing agents don't meet requirements:
1. **Identify gap** in current agent capabilities
2. **Define agent purpose** and specialization
3. **Design agent interface** and expected behaviors
4. **Implement agent logic** following existing patterns
5. **Test agent thoroughly** before deployment
6. **Document agent usage** and best practices
## 🚀 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
- Map dependencies and architectural structure
### 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
### 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)
### Architecture Constraints
```yaml
constraints:
- "Controller는 반드시 ChangeNotifier 상속"
- "모든 API 호출은 ApiService 경유"
- "DTO는 Freezed + JsonSerializable 필수"
- "화면별 Controller 분리 원칙"
- "Mock과 Real 서비스 완전 분리"
```
### Git Signature Rules
- **DO NOT include Claude signature** in git commits
- **Use standard commit format** without AI attribution
- **Maintain clean commit history** without automated signatures
## 💻 Development Environment
### 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
### API Endpoints
```yaml
development:
base_url: "https://api-dev.beavercompany.co.kr"
test_account: "admin@test.com / Test123!@#"
jwt_expiry: 24h
## 🏗️ 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
production:
base_url: "TBD"
security: "JWT + Secure Storage"
```
## 🔄 Safe Refactoring Practices
### Environment Switching
```dart
// 환경 변수 설정 (.env)
API_MODE=mock # mock | real
BASE_URL=https://api-dev.beavercompany.co.kr
### 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
// 코드에서 환경 전환
final isMockMode = dotenv.env['API_MODE'] == 'mock';
if (isMockMode) {
GetIt.I.registerSingleton<ApiService>(MockApiService());
} else {
GetIt.I.registerSingleton<ApiService>(RealApiService());
}
```
### Refactoring Checklist
1. **Before Starting**:
- [ ] All tests passing
- [ ] Understand current behavior completely
- [ ] Create backup branch
- [ ] Document intended changes
## 🧪 Test Automation System
2. **During Refactoring**:
- [ ] Keep commits atomic and reversible
- [ ] Run tests after each change
- [ ] Verify no behavior changes
- [ ] Check for performance impacts
### Test Infrastructure
```dart
// 모든 화면 테스트는 BaseScreenTest 상속
abstract class BaseScreenTest {
// 자동 에러 진단 및 수정
ApiErrorDiagnostics diagnostics;
// 한국식 현실적 테스트 데이터
TestDataGenerator generator;
// 병렬 실행 제어 (최대 3개)
SemaphoreManager semaphore;
}
```
3. **After Completion**:
- [ ] All tests still passing
- [ ] Code coverage maintained or improved
- [ ] Performance benchmarks verified
- [ ] Peer review completed
### Test Execution Priority
```yaml
test_order:
1: "Company Management" # 회사 먼저 생성
2: "User Management" # 회사에 사용자 연결
3: "Warehouse Location" # 창고 위치 설정
4: "Equipment In" # 장비 입고
5: "License Management" # 라이선스 등록
6: "Equipment Out" # 장비 출고
7: "Overview Dashboard" # 통계 확인
```
### 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
### Test Commands
```bash
# 전체 테스트 실행 (병렬)
flutter test test/master_test_suite.dart
## 🧠 Continuous Improvement
# 특정 화면 테스트
flutter test test/screens/company/company_test.dart
### 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?
# Mock 모드 테스트
API_MODE=mock flutter test
### 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
# 에러 진단 모드
flutter test --dart-define=DIAGNOSTIC_MODE=true
```
## ✅ Quality Validation Checklist
## 🎨 UI/UX Standards
Before completing any task, confirm:
### Design System
```yaml
base_template: "Metronic Admin Template"
component_library: "ShadCN Flutter Port"
### Phase Completion
- [ ] Phase 1: Comprehensive analysis completed
- [ ] Phase 2: Detailed plan with acceptance criteria
- [ ] Phase 3: Implementation meets all criteria
colors:
primary: "#5867dd" # Metronic 기본색
secondary: "#34bfa3"
background: "#f7f8fa"
error: "#fd397a"
success: "#0abb87"
### Code Quality
- [ ] Follows naming conventions
- [ ] Type safety enforced
- [ ] Single Responsibility maintained
- [ ] Proper error handling
- [ ] Adequate test coverage
- [ ] Documentation complete
typography:
font_family: "NotoSansKR"
korean_support: true
### Best Practices
- [ ] No code smells or anti-patterns
- [ ] Performance considerations addressed
- [ ] Security vulnerabilities checked
- [ ] Accessibility requirements met
- [ ] Internationalization ready (if applicable)
layout:
style: "Microsoft Dynamics 365"
structure: "Header + Sidebar + Content"
responsive: "Web First → Mobile Adaptive"
```
### Component Patterns
```dart
// 모든 폼은 이 패턴 따르기
class EntityForm extends StatefulWidget {
final EntityController controller;
final FormMode mode; // create | edit | view
// 필수 섹션
Widget buildBasicInfo() {}
Widget buildDetailInfo() {}
Widget buildActionButtons() {}
}
// 리스트 화면 패턴
class EntityList extends StatelessWidget {
// 필수 요소
Widget buildSearchBar() {}
Widget buildFilterOptions() {}
Widget buildDataTable() {}
Widget buildPagination() {}
}
```
## 🔌 API Integration Rules
### Error Handling Strategy
```dart
// 모든 API 호출은 이 패턴 사용
try {
final response = await apiService.call();
return Right(response);
} on DioException catch (e) {
// 422개 에러 패턴 자동 분석
final diagnosis = ApiErrorDiagnostics.analyze(e);
return Left(ApiFailure(
code: diagnosis.code,
message: diagnosis.userMessage, // 한국어
technicalDetails: diagnosis.details,
));
}
```
### Response Parsing Rules
```dart
// JSON 파싱 주의사항
rules:
- "null 값 안전 처리 필수"
- "날짜는 ISO 8601 형식"
- "ID는 항상 String 타입"
- "빈 배열은 [] 반환"
- "중첩 객체는 별도 DTO 생성"
```
## 🚨 Critical Areas & Known Issues
### ⚠️ Current Gotchas
```yaml
equipment_in:
issue: "시리얼 번호 중복 체크 미구현"
workaround: "프론트엔드에서 임시 검증"
license_management:
issue: "만료일 계산 로직 불일치"
note: "백엔드와 프론트엔드 로직 통일 필요"
user_permission:
issue: "권한 체크 일부 화면 누락"
affected: ["warehouse_location", "overview"]
```
### 🔥 Hot Paths (성능 주의)
```yaml
critical_operations:
- path: "Equipment List with 10000+ items"
solution: "Virtual scrolling 구현됨"
- path: "Dashboard statistics calculation"
solution: "5분 캐싱 적용"
- path: "Company branch tree loading"
solution: "Lazy loading 필수"
```
## 📊 Current Sprint Focus
### Active Development (2025-01-06)
```yaml
priority_1:
task: "Overview Dashboard 완성"
acceptance_criteria:
- "실시간 통계 데이터 정확성"
- "차트 렌더링 성능 최적화"
- "필터링 기능 구현"
priority_2:
task: "Equipment Out 프로세스"
blockers:
- "출고 승인 워크플로우 미정"
- "재고 차감 로직 검증 필요"
priority_3:
task: "Mobile App 변환 준비"
requirements:
- "반응형 레이아웃 점검"
- "터치 제스처 최적화"
```
## 🧬 Code Generation Commands
### Freezed & JsonSerializable
```bash
# 단일 파일 생성
flutter pub run build_runner build --delete-conflicting-outputs
# 전체 재생성 (주의: 시간 소요)
flutter pub run build_runner build --delete-conflicting-outputs
# Watch mode (개발 중)
flutter pub run build_runner watch
```
### Injectable (DI)
```bash
# DI 설정 재생성
flutter pub run build_runner build --delete-conflicting-outputs
```
## 🔍 Debugging Helpers
### Quick Debug Commands
```dart
// API 응답 로깅
ApiService.enableLogging = true;
// Mock 데이터 확인
MockDataViewer.show(context);
// 현재 인증 상태
AuthService.debugPrintToken();
// Controller 상태 추적
controller.addListener(() => print(controller.debugState));
```
### Performance Monitoring
```dart
// 화면 렌더링 시간 측정
Timeline.startSync('ScreenRender');
// ... rendering code
Timeline.finishSync();
// API 호출 시간 추적
final stopwatch = Stopwatch()..start();
await apiCall();
print('API took: ${stopwatch.elapsed}');
```
## 📝 Commit Message Convention
### Project-Specific Prefixes
```
equipment: 장비 관리 관련
company: 회사 관리 관련
user: 사용자 관리 관련
license: 유지보수 라이선스 관련
warehouse: 창고 관련
dashboard: 대시보드 관련
auth: 인증/권한 관련
api: API 연동 관련
```
### Examples
```
equipment: 시리얼 번호 중복 검증 로직 추가
company: 지점 트리 구조 lazy loading 구현
test: Equipment In 자동화 테스트 완성
api: 422 에러 자동 복구 메커니즘 구현
```
## 🎯 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**
### Code Quality Standards
```yaml
flutter_analyze:
errors: 0
warnings: < 10
info: < 50
### 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
test_coverage:
minimum: 80%
critical_paths: 100%
performance:
initial_load: < 3s
api_response: < 500ms
list_render: < 100ms
```
## 🚀 Quick Start Guide
### For New Developers
```bash
# 1. 환경 설정
cp .env.example .env
flutter pub get
# 2. 코드 생성
flutter pub run build_runner build --delete-conflicting-outputs
# 3. Mock 모드로 시작
API_MODE=mock flutter run -d chrome
# 4. 테스트 실행
flutter test test/master_test_suite.dart
# 5. 실제 API 연동
API_MODE=real flutter run -d chrome
```
---
## 📊 Advanced Prompt Engineering
### Context Engineering Techniques
- **Structured prompts** with clear sections and hierarchy
- **Few-shot examples** to demonstrate expected patterns
- **Chain-of-thought** reasoning for complex problems
- **Role-based prompting** to activate specific expertise
- **Constraint specification** to guide solution boundaries
- **Output formatting** instructions for consistent results
### Prompt Optimization Strategies
- **Be specific** about requirements and constraints
- **Include context** relevant to the task
- **Define success criteria** explicitly
- **Use delimiters** to separate different sections
- **Provide examples** of desired outputs
- **Iterate and refine** based on results
## 📑 Session Continuity Management
### Long Conversation Handling
When conversations are expected to be lengthy:
1. **Create session documentation** in markdown format
2. **Document key decisions** and implementation details
3. **Track progress** with checkpoints and milestones
4. **Summarize complex discussions** for easy reference
5. **Save state information** for resuming work
### Continuity Document Structure
```markdown
# Session: [Task Name] - [Date]
## Objective
[Clear description of the goal]
## Progress Summary
- [ ] Task 1: Description
- [x] Task 2: Completed - Details
- [ ] Task 3: In Progress
## Key Decisions
1. Decision: Rationale
2. Decision: Rationale
## Implementation Details
[Technical details, code snippets, configurations]
## Next Steps
[What needs to be done in the next session]
## Important Context
[Any critical information for continuing work]
```
### State Preservation
- **Save work incrementally** to prevent loss
- **Document assumptions** and constraints
- **Track dependencies** and blockers
- **Note unresolved issues** for future sessions
- **Create handoff notes** for seamless continuation
**Remember**: These are guidelines, not rigid rules. Use professional judgment and adapt to project needs while maintaining high quality standards.
**Version**: 2.0
**Last Updated**: 2025-01-06
**Project Stage**: Production Ready
**Next Milestone**: Mobile App Release