@umituz/react-native-settings 4.20.61 → 4.21.1

package/AI_AGENT_GUIDELINES.md

@@ -1,367 +0,0 @@
-# AI Agent Development Guidelines
-
-Comprehensive guidelines for AI agents when developing with `@umituz/react-native-settings`.
-
-## Core Principles
-
-### 1. No Code Examples in Documentation
-- ❌ **FORBIDDEN**: Including code examples in README files
-- ✅ **REQUIRED**: Reference file paths only
-- ✅ **REQUIRED**: Describe patterns and strategies
-- **REASON**: Code changes frequently, documentation stays valid
-
-### 2. File Path References
-When describing functionality:
-- Always provide exact file path
-- Use relative paths from package root
-- Include `.tsx` or `.ts` extensions
-- Format: `src/path/to/File.tsx`
-
-### 3. Strategy-Based Documentation
-Each component/module MUST include:
-- **Strategy**: How to use it effectively
-- **Restrictions**: What NOT to do
-- **Rules**: What MUST be followed
-- **AI Guidelines**: Specific AI agent instructions
-
-## Component Development Rules
-
-### When Creating Settings UI
-
-#### ✅ ALWAYS
-1. **Use Existing Components**
-   - Check if component exists in `src/presentation/components/`
-   - Import from `@umituz/react-native-settings`
-   - Reference implementation file
-
-2. **Follow Domain Structure**
-   - Place feature in appropriate domain
-   - Use domain's existing patterns
-   - Reference similar features
-
-3. **Type Safety**
-   - Use TypeScript for all files
-   - Define proper interfaces
-   - Export types
-
-#### ❌ NEVER
-1. **Create Duplicate Components**
-   - Don't recreate existing components
-   - Check component library first
-   - Extend if needed, don't duplicate
-
-2. **Bypass Layers**
-   - Don't skip repository layer
-   - Don't access storage directly
-   - Follow DDD layering
-
-3. **Hardcode Values**
-   - Use design system tokens
-   - Use constants file
-   - Don't hardcode colors, sizes
-
-## File Organization
-
-### Domain Structure
-
-Each domain follows this pattern:
-```
-src/domains/{domain-name}/
-├── domain/              # Business entities
-├── application/         # Domain-specific application logic
-├── infrastructure/      # Data persistence
-├── presentation/        # UI components
-│   ├── screens/
-│   ├── components/
-│   └── hooks/
-├── types/              # Domain types
-└── utils/              # Domain utilities
-```
-
-### Rules
-- Place files in correct layer
-- Follow existing patterns
-- Use proper imports between layers
-- Don't create circular dependencies
-
-## Component Creation Checklist
-
-Before creating a new component:
-
-1. ✅ **Check Existing Components**
-   - Search `src/presentation/components/`
-   - Search domain's `presentation/components/`
-   - Check if similar component exists
-
-2. ✅ **Follow Structure**
-   - Create in appropriate location
-   - Use proper naming conventions
-   - Add TypeScript types
-
-3. ✅ **Documentation**
-   - Create README.md in component directory
-   - Follow documentation template
-   - Include Strategy/Restrictions/Rules
-   - NO CODE EXAMPLES
-
-4. ✅ **Testing**
-   - Add test file alongside component
-   - Test file: `ComponentName.test.tsx`
-   - Follow testing patterns
-
-## Import Rules
-
-### From Package
-```typescript
-import { ComponentName } from '@umituz/react-native-settings';
-```
-
-### Relative Imports
-```typescript
-// Within same domain
-import { ComponentName } from '../components/ComponentName';
-
-// Across domains
-import { ComponentName } from '../../domains/{domain}/presentation/components/ComponentName';
-```
-
-### Restrictions
-- ❌ Don't use deep relative imports (`../../../`)
-- ❌ Don't import from implementation files directly
-- ✅ Use barrel exports (`index.ts`)
-
-## Naming Conventions
-
-### Components
-- PascalCase: `SettingsItemCard.tsx`
-- Descriptive names
-- Prefix with feature name if domain-specific
-
-### Hooks
-- camelCase with `use` prefix: `useSettings.ts`
-- Domain hooks: `use{Feature}{Action}.ts`
-
-### Utilities
-- camelCase: `formatDate.ts`
-- Descriptive action names: `normalizeConfig.ts`
-
-### Types
-- PascalCase for interfaces: `UserSettings.ts`
-- Type suffix: `SettingsConfig.types.ts`
-
-## Design System Usage
-
-### ✅ ALWAYS Use Design System
-```typescript
-// Instead of:
-color: '#2196F3'
-fontSize: 16
-
-// Use:
-color: tokens.colors.primary
-fontSize: tokens.typography.fontSize.base
-```
-
-### Tokens Reference
-See: `src/presentation/design-system/tokens.ts`
-- Colors: `tokens.colors.*`
-- Spacing: `tokens.spacing.*`
-- Typography: `tokens.typography.*`
-- Border Radius: `tokens.borderRadius.*`
-
-## TypeScript Rules
-
-### ✅ MUST
-- Type all props
-- Type all function parameters
-- Type all return values
-- Export reusable types
-- Use strict mode
-
-### Type Definition Location
-- Component types: Same file as component
-- Shared types: `types/` directory
-- Domain types: `src/domains/{domain}/types/`
-
-## Error Handling
-
-### ✅ ALWAYS
-1. Use try-catch for async operations
-2. Provide meaningful error messages
-3. Log errors appropriately
-4. Handle user-friendly errors
-
-### Pattern
-```typescript
-// Check implementation files for patterns
-// Repository: src/infrastructure/repositories/SettingsRepository.ts
-// Service: src/infrastructure/services/SettingsService.ts
-```
-
-## Performance Rules
-
-### ✅ ALWAYS
-1. Use React.memo for expensive components
-2. Use useCallback for handlers
-3. Use useMemo for computed values
-4. Avoid unnecessary re-renders
-
-### ❌ NEVER
-1. Define functions in render
-2. Create objects in render
-3. Skip optimization without reason
-4. Ignore performance warnings
-
-## Accessibility
-
-### ✅ MUST
-1. Add accessibilityLabel to interactive elements
-2. Provide accessibilityHint for complex interactions
-3. Support screen readers
-4. Maintain proper touch target sizes (44x44 min)
-
-## Testing Guidelines
-
-### Test File Location
-- Next to component: `ComponentName.test.tsx`
-- In `__tests__` directory: `__tests__/ComponentName.test.tsx`
-
-### What to Test
-- Component rendering
-- User interactions
-- Props changes
-- Error states
-- Accessibility
-
-### Pattern Reference
-Check existing test files:
-- `src/presentation/components/__tests__/SettingsItemCard.test.tsx`
-- `src/domains/about/presentation/components/__tests__/AboutContent.test.tsx`
-
-## Common Patterns
-
-### Adding a New Settings Item
-
-1. **Check Existing**: Look at `SettingsItemCard` usage
-2. **Follow Pattern**: Use `SettingsItemCard` component
-3. **Reference File**: `src/presentation/components/SettingsItemCard/SettingsItemCard.tsx`
-4. **No Custom Code**: Don't create custom item cards
-
-### Adding a New Domain
-
-1. **Follow Structure**: Copy existing domain structure
-2. **Reference**: Similar domain for patterns
-3. **Layers**: domain/, application/, infrastructure/, presentation/
-4. **Documentation**: Create domain README with strategy/restrictions/rules
-
-### Adding Navigation
-
-1. **Reference**: `src/presentation/navigation/`
-2. **Use Wrappers**: Existing screen wrappers
-3. **Follow Patterns**: See navigation utilities
-4. **No Inline**: Don't inline navigation logic
-
-## File Reference Patterns
-
-When agent needs to implement something:
-
-1. **Find Similar Implementation**
-   ```
-   Search: Use Task tool with Explore agent
-   Pattern: Look for similar feature in existing code
-   Reference: Check READMEs for file paths
-   ```
-
-2. **Follow Existing Patterns**
-   ```
-   Don't: Create from scratch
-   Do: Reference and adapt existing code
-   Verify: Check implementation file directly
-   ```
-
-3. **Check Documentation First**
-   ```
-   1. Read component README
-   2. Check Strategy section
-   3. Follow Rules section
-   4. Reference file path
-   ```
-
-## Verification Steps
-
-### Before Completing Task
-
-1. ✅ **Checked Documentation**
-   - Read relevant README files
-   - Understood strategy and restrictions
-   - Know the file paths
-
-2. ✅ **Referenced Implementation**
-   - Looked at similar components
-   - Followed existing patterns
-   - Used same imports
-
-3. ✅ **Followed Rules**
-   - No code examples in docs
-   - All files properly typed
-   - Design system tokens used
-   - Error handling included
-
-4. ✅ **Testing**
-   - Added tests if new component
-   - Verified existing tests pass
-   - Tested on both platforms if needed
-
-## Quick Reference
-
-### Common File Paths
-
-```
-Components:
-  src/presentation/components/SettingsItemCard/
-  src/presentation/screens/components/SettingsContent/
-
-Domains:
-  src/domains/about/
-  src/domains/appearance/
-  src/domains/legal/
-  (etc.)
-
-Configuration:
-  src/presentation/screens/types/SettingsConfig.ts
-  src/presentation/screens/utils/normalizeConfig.ts
-
-Navigation:
-  src/presentation/navigation/components/
-  src/presentation/navigation/hooks/
-  src/presentation/navigation/utils/
-```
-
-### Key Import Patterns
-
-```typescript
-// From package
-import { X } from '@umituz/react-native-settings';
-
-// Domain components
-import { X } from '../../domains/{domain}/presentation/components/X';
-
-// Utilities
-import { util } from '../../path/to/util';
-```
-
-## Summary
-
-### Agent Approach
-1. **Read Documentation First** - Check READMEs
-2. **Reference Implementation** - Look at file paths
-3. **Follow Patterns** - Don't create from scratch
-4. **No Code Examples** - Keep docs code-free
-5. **Strategy Over Syntax** - Focus on approach
-
-### Success Criteria
-- ✅ Uses existing components
-- ✅ Follows domain structure
-- ✅ Includes proper documentation
-- ✅ No code examples in docs
-- ✅ File paths referenced correctly

package/ARCHITECTURE.md

@@ -1,246 +0,0 @@
-# Architecture Overview
-
-Comprehensive architecture documentation for the `@umituz/react-native-settings` package following Domain-Driven Design (DDD) principles.
-
-## Purpose
-
-This document defines the architectural principles, structural organization, and design patterns governing the `@umituz/react-native-settings` package. It serves as the authoritative reference for understanding the system's layered architecture, domain organization, and interaction patterns between components.
-
-## File Paths
-
-**Base Directory**: `/Users/umituz/Desktop/github/umituz/apps/artificial_intelligence/npm-packages/react-native-settings/`
-
-**Key Structure**:
-- `/src/domains/` - Domain-specific modules
-- `/src/application/` - Application layer interfaces
-- `/src/infrastructure/` - Infrastructure implementations
-- `/src/presentation/` - UI components and screens
-
-## Architecture Layers
-
-```
-┌─────────────────────────────────────────┐
-│      Presentation Layer                 │
-│  (UI Components, Screens, Hooks)        │
-└─────────────────────────────────────────┘
-                  ↓
-┌─────────────────────────────────────────┐
-│       Application Layer                 │
-│   (Business Logic, Interfaces)          │
-└─────────────────────────────────────────┘
-                  ↓
-┌─────────────────────────────────────────┐
-│      Infrastructure Layer               │
-│  (Data Persistence, Services)           │
-└─────────────────────────────────────────┘
-                  ↓
-┌─────────────────────────────────────────┐
-│         Domain Layer                    │
-│   (Business Entities, Rules)            │
-└─────────────────────────────────────────┘
-```
-
-### Layer Responsibilities
-
-**Presentation Layer**: UI rendering and user interaction handling
-**Application Layer**: Business logic orchestration and interface definitions
-**Infrastructure Layer**: Data persistence and external service implementations
-**Domain Layer**: Business entities, rules, and domain-specific logic
-
-## Directory Structure
-
-```
-src/
-├── domains/                    # Business domains
-│   ├── about/
-│   ├── appearance/
-│   ├── legal/
-│   ├── disclaimer/
-│   ├── feedback/
-│   ├── faqs/
-│   ├── rating/
-│   ├── video-tutorials/
-│   ├── cloud-sync/
-│   └── dev/
-├── application/                # Application layer
-│   └── ports/                  # Layer interfaces
-├── infrastructure/             # Infrastructure layer
-│   ├── repositories/           # Data repositories
-│   └── services/               # Business services
-└── presentation/              # Presentation layer
-    ├── components/             # Shared components
-    ├── screens/                # Screens
-    ├── hooks/                  # Presentation hooks
-    └── navigation/             # Navigation
-```
-
-## Domain Organization
-
-Each domain follows a consistent self-contained structure:
-
-```
-domain/
-├── domain/            # Business entities
-├── application/       # Domain-specific application logic
-├── infrastructure/    # Domain-specific infrastructure
-├── presentation/      # Domain-specific UI
-├── types/            # Domain types
-└── utils/            # Domain utilities
-```
-
-### Domain Examples
-
-**About Domain**: Application information, version details, developer contact
-**Appearance Domain**: Theme settings, language preferences, display options
-**Legal Domain**: Terms of service, privacy policy, legal notices
-**Disclaimer Domain**: Usage disclaimers, liability statements
-**Feedback Domain**: User feedback collection, issue reporting
-**FAQs Domain**: Frequently asked questions and answers
-**Rating Domain**: App store ratings, review prompts
-**Video Tutorials Domain**: Tutorial videos, help content
-**Cloud Sync Domain**: Data synchronization, backup/restore
-**Dev Domain**: Development tools, debugging features
-
-## Data Flow Patterns
-
-### Reading Settings
-
-```
-User → UI Component → Hook → Query → Service → Repository → Storage
-```
-
-### Updating Settings
-
-```
-User → UI → Mutation Hook → Service → Repository → Storage
-```
-
-## Design Patterns
-
-### Repository Pattern
-Separates data access logic from business logic through interface-based abstractions
-
-### Dependency Injection
-Inject dependencies through constructors for testability and flexibility
-
-### Factory Pattern
-Create objects with factory functions for consistent object creation
-
-### Observer Pattern
-React hooks and TanStack Query use observer pattern for reactive state management
-
-## Strategy
-
-1. **Domain-Driven Organization**: Structure the codebase around business domains rather than technical layers, ensuring each domain is self-contained with its own entities, logic, and presentation
-
-2. **Layered Architecture**: Maintain clear separation between presentation, application, infrastructure, and domain layers with unidirectional dependencies flowing from outer to inner layers
-
-3. **Interface-Based Design**: Define clear interfaces between layers and components to enable loose coupling, testability, and independent evolution of components
-
-4. **Dependency Inversion**: Depend on abstractions rather than concrete implementations, allowing for easy substitution of implementations (e.g., different storage backends)
-
-5. **Single Responsibility Principle**: Each component, service, and module should have one reason to change, ensuring focused, maintainable code
-
-## Restrictions
-
-### ❌ DO NOT
-
-- Skip architectural layers when communicating between components (e.g., Presentation must not directly access Storage)
-- Create circular dependencies between layers or domains
-- Mix concerns within a single layer (e.g., business logic in presentation components)
-- Access external services directly from domain or presentation layers
-- Duplicate business logic across multiple domains or components
-
-### ❌ NEVER
-
-- Allow presentation components to directly access infrastructure implementations
-- Create dependencies from inner layers (domain/infrastructure) to outer layers (presentation)
-- Implement business rules in UI components or hooks
-- Share mutable state between different domains without proper encapsulation
-- Bypass repository interfaces when accessing data
-
-### ❌ AVOID
-
-- Creating tightly coupled dependencies between different domains
-- Implementing complex business logic in presentation layer hooks
-- Using global state or singletons for sharing data between layers
-- Making infrastructure details (e.g., storage implementation) visible to other layers
-- Creating overly complex abstractions that don't serve a clear purpose
-
-## Rules
-
-### ✅ ALWAYS
-
-- Use interfaces to define contracts between layers and components
-- Follow dependency injection patterns for passing dependencies
-- Implement proper error handling at each layer with consistent error types
-- Maintain type safety with TypeScript throughout the architecture
-- Write tests that verify behavior at each architectural layer
-
-### ✅ MUST
-
-- Ensure all data access goes through repository interfaces
-- Keep domain entities and business rules independent of infrastructure
-- Implement proper separation of concerns in all components
-- Use async/await for all asynchronous operations
-- Handle edge cases and errors gracefully at each layer
-
-### ✅ SHOULD
-
-- Prefer composition over inheritance when sharing behavior
-- Keep interfaces focused and cohesive (small, related sets of methods)
-- Use factory functions for creating complex objects with dependencies
-- Implement proper logging at each layer for debugging and monitoring
-- Maintain consistency in naming conventions across all layers
-
-## AI Agent Guidelines
-
-### Architecture Modifications
-
-When modifying the architecture:
-
-1. **Layer Adherence**: Always respect the layered architecture and maintain unidirectional dependencies from outer to inner layers
-2. **Domain Boundaries**: Keep domains self-contained and minimize inter-domain dependencies
-3. **Interface Stability**: When changing interfaces, maintain backward compatibility or provide migration paths
-4. **Incremental Changes**: Make architectural changes incrementally, ensuring tests pass at each step
-
-### Adding New Features
-
-When adding new features:
-
-1. **Domain Identification**: Determine which domain the feature belongs to, or create a new domain if appropriate
-2. **Layer Placement**: Place each piece of functionality in the appropriate layer following the architecture patterns
-3. **Interface Design**: Design clear interfaces before implementing functionality
-4. **Dependency Management**: Use dependency injection to pass dependencies and enable testing
-
-### Refactoring Guidelines
-
-When refactoring existing code:
-
-1. **Maintain Contracts**: Keep existing interfaces stable; internal refactoring should not break external contracts
-2. **Test Coverage**: Ensure comprehensive test coverage before and after refactoring
-3. **Gradual Migration**: Refactor incrementally, maintaining functionality at each step
-4. **Documentation Updates**: Update architecture documentation to reflect significant structural changes
-
-### Code Review Checklist
-
-Review should verify:
-
-- Layer separation is maintained
-- Dependencies flow in correct direction (outer → inner)
-- Interfaces are well-defined and cohesive
-- Domain logic is properly encapsulated
-- Error handling is consistent across layers
-- Tests cover all architectural layers
-- No circular dependencies exist
-- Type safety is maintained throughout
-
-## Related Documentation
-
-- **TESTING.md**: Comprehensive testing strategies for each architectural layer
-- **Domain READMEs**: Individual domain-specific documentation
-- **Component Documentation**: UI component usage and patterns
-
-## License
-
-MIT

package/CHANGELOG.md

@@ -1,67 +0,0 @@
-# Changelog
-
-All notable changes to this project will be documented in this file.
-
-The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
-and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
-
-## [4.20.58] - 2025-01-08
-
-### Added
-- Complete documentation migration to new format
-- AI Agent Guidelines for all components
-- Strategy-based documentation without code examples
-- File path references in all documentation
-- CONTRIBUTING.md guide
-- LICENSE file
-
-### Changed
-- All README files now use Purpose/Strategy/Restrictions/Rules format
-- ARCHITECTURE.md updated to new documentation style
-- TESTING.md updated to new documentation style
-- Removed all code examples from documentation
-- Added AI-friendly guidelines throughout
-
-### Fixed
-- Documentation consistency across all files
-- Missing file path references
-- Incomplete AI guidelines
-
-## [4.20.57] - Previous Releases
-
-### Features
-- Settings screen with modular sections
-- Theme management (light, dark, auto)
-- Language selection
-- Notification preferences
-- About screen with app info
-- Legal documents (privacy, terms)
-- Disclaimer system
-- Feedback collection
-- FAQ management
-- Rating prompts
-- Video tutorials
-- Cloud sync support
-- Development utilities
-
-### Architecture
-- Domain-Driven Design (DDD)
-- Four-layer architecture
-- Repository pattern
-- Service layer
-- TanStack Query integration
-- Type-safe implementation
-
-## Documentation Format
-
-From version 4.20.58 onwards, all documentation follows:
-- No code examples
-- Strategy-based approach
-- File path references
-- Clear restrictions (❌ DO NOT, ❌ NEVER, ❌ AVOID)
-- Mandatory rules (✅ ALWAYS, ✅ MUST, ✅ SHOULD)
-- AI Agent Guidelines
-
-## License
-
-MIT License - see LICENSE file for details