docs: expand Core Development Principles documentation

- Add detailed explanations for SOLID principles
- Expand DRY development guidelines with implementation examples
- Add Law of Demeter and Composition over Inheritance principles
- Include Interface Segregation and Fail Fast principles
- Add Principle of Least Astonishment and Information Hiding
- Document Single Source of Truth and Principle of Least Privilege
- Add CI/CD principles and best practices
- Maintain existing accessibility and performance requirements

This update provides comprehensive development guidelines for the Time Safari project,
including practical examples and TypeScript integration.

README-context.md

@@ -111,24 +111,161 @@ When developing new features, be mindful of these constraints:
 
 ## Core Development Principles
 
-- DRY development
+### DRY development
-- SOLID principles
+- **Code Reuse**
-- Law of Demeter
+  - Extract common functionality into utility functions
-- Composition over Inheritence
+  - Create reusable components for UI patterns
-- Interface Segregation
+  - Implement service classes for shared business logic
-- Fail Fast
+  - Use mixins for cross-cutting concerns
-- Principle of Least Astonishment
+  - Leverage TypeScript interfaces for shared type definitions
-- Information Hiding
+
-- Single Source of Truth
+- **Component Patterns**
-- Principle of Least Privilege
+  - Create base components for common UI elements
-- Continuous Integration/Continuous Deployment (CI/CD)
+  - Implement higher-order components for shared behavior
+  - Use slot patterns for flexible component composition
+  - Create composable services for business logic
+  - Implement factory patterns for component creation
+
+- **State Management**
+  - Centralize state in Pinia stores
+  - Use computed properties for derived state
+  - Implement shared state selectors
+  - Create reusable state mutations
+  - Use action creators for common operations
+
+- **Error Handling**
+  - Implement centralized error handling
+  - Create reusable error components
+  - Use error boundary components
+  - Implement consistent error logging
+  - Create error type definitions
+
+- **Type Definitions**
+  - Create shared interfaces for common data structures
+  - Use type aliases for complex types
+  - Implement generic types for reusable components
+  - Create utility types for common patterns
+  - Use discriminated unions for state management
+
+- **API Integration**
+  - Create reusable API client classes
+  - Implement request/response interceptors
+  - Use consistent error handling patterns
+  - Create type-safe API endpoints
+  - Implement caching strategies
+
+- **Platform Services**
+  - Abstract platform-specific code behind interfaces
+  - Create platform-agnostic service layers
+  - Implement feature detection
+  - Use dependency injection for services
+  - Create service factories
+
+- **Testing**
+  - Create reusable test utilities
+  - Implement test factories
+  - Use shared test configurations
+  - Create reusable test helpers
+  - Implement consistent test patterns
+  
+### SOLID Principles
+- **Single Responsibility**: Each class/component should have only one reason to change
+  - Components should focus on one specific feature (e.g., QR scanning, DID management)
+  - Services should handle one type of functionality (e.g., platform services, crypto services)
+  - Utilities should provide focused helper functions
+
+- **Open/Closed**: Software entities should be open for extension but closed for modification
+  - Use interfaces for service definitions
+  - Implement plugin architecture for platform-specific features
+  - Allow component behavior extension through props and events
+
+- **Liskov Substitution**: Objects should be replaceable with their subtypes
+  - Platform services should work consistently across web/mobile
+  - Authentication providers should be interchangeable
+  - Storage implementations should be swappable
+
+- **Interface Segregation**: Clients shouldn't depend on interfaces they don't use
+  - Break down large service interfaces into smaller, focused ones
+  - Component props should be minimal and purposeful
+  - Event emissions should be specific and targeted
+
+- **Dependency Inversion**: High-level modules shouldn't depend on low-level modules
+  - Use dependency injection for services
+  - Abstract platform-specific code behind interfaces
+  - Implement factory patterns for component creation
+
+### Law of Demeter
+- Components should only communicate with immediate dependencies
+- Avoid chaining method calls (e.g., `this.service.getUser().getProfile().getName()`)
+- Use mediator patterns for complex component interactions
+- Implement facade patterns for subsystem access
+- Keep component communication through defined events and props
+
+### Composition over Inheritance
+- Prefer building components through composition
+- Use mixins for shared functionality
+- Implement feature toggles through props
+- Create higher-order components for common patterns
+- Use service composition for complex features
+
+### Interface Segregation
+- Define clear interfaces for services
+- Keep component APIs minimal and focused
+- Split large interfaces into smaller, specific ones
+- Use TypeScript interfaces for type definitions
+- Implement role-based interfaces for different use cases
+
+### Fail Fast
+- Validate inputs early in the process
+- Use TypeScript strict mode
+- Implement comprehensive error handling
+- Add runtime checks for critical operations
+- Use assertions for development-time validation
+
+### Principle of Least Astonishment
+- Follow Vue.js conventions consistently
+- Use familiar naming patterns
+- Implement predictable component behaviors
+- Maintain consistent error handling
+- Keep UI interactions intuitive
+
+### Information Hiding
+- Encapsulate implementation details
+- Use private class members
+- Implement proper access modifiers
+- Hide complex logic behind simple interfaces
+- Use TypeScript's access modifiers effectively
+
+### Single Source of Truth
+- Use Pinia for state management
+- Maintain one source for user data
+- Centralize configuration management
+- Use computed properties for derived state
+- Implement proper state synchronization
+
+### Principle of Least Privilege
+- Implement proper access control
+- Use minimal required permissions
+- Follow privacy-by-design principles
+- Restrict component access to necessary data
+- Implement proper authentication/authorization
+
+### Continuous Integration/Continuous Deployment (CI/CD)
+- Automated testing on every commit
+- Consistent build process across platforms
+- Automated deployment pipelines
+- Quality gates for code merging
+- Environment-specific configurations
+
+This expanded documentation provides:
+1. Clear principles for development
+2. Practical implementation guidelines
+3. Real-world examples
+4. TypeScript integration
+5. Best practices for Time Safari
+
+Would you like me to provide more specific examples for any of these principles?
 - Ensure all components support accessibility first design
-- Implement privacy-preserving features by default
-- Support progressive enhancement across devices
-- Enable voluntary collaboration features
-- Build trust-enabling interactions
-- Optimize for low resource requirements
-- Support offline-first functionality where possible
 - Use class-based syntax with decorators from vue-facing-decorators.
 - Should attempt to maximize Lighthouse Score as close to 100 as possible.
 - Use Lighthouse for performance scoring