# Project Rules

## Original Project Reference
IMPORTANT: The original Django project is located at:
Path: '/Users/talor/thrillwiki_django_no_react'
This path contains the reference implementation that must be followed.

## Feature Parity Requirements

IMPORTANT: This Laravel/Livewire project must maintain strict feature parity with the original Django project.

### Core Requirements

1. Feature-to-Feature Matching
   - Every Django app must have an equivalent Laravel implementation
   - All functionality must be replicated without loss of capability
   - New features must not break existing feature parity
   - Document any deviations or Laravel-specific enhancements

2. Function-to-Function Equivalence
   - Methods and functions must maintain the same business logic
   - API endpoints must provide identical responses
   - Database operations must maintain data integrity
   - Performance characteristics should be equivalent or better

3. Design Consistency
   - UI/UX must match the original Django implementation
   - Component structure should mirror Django templates
   - Maintain consistent naming conventions
   - Preserve user interaction patterns

4. Project Structure Reference
   - Original Django apps to maintain parity with:
     * accounts
     * analytics
     * autocomplete
     * companies
     * core
     * designers
     * email_service
     * history
     * history_tracking
     * location
     * moderation
     * parks
     * reviews
     * rides
     * search
     * wiki

### Implementation Guidelines

1. Framework Usage
   - Use Laravel and Livewire native implementations whenever possible
   - Avoid custom code unless absolutely necessary
   - Leverage built-in Laravel features and conventions
   - Utilize Livewire's reactive components and lifecycle hooks
   - Only create custom solutions when framework features don't meet requirements

2. Before implementing new features:
   - Review corresponding Django implementation
   - Document feature requirements
   - Plan Laravel/Livewire approach
   - Verify feature parity coverage

2. During development:
   - Test against Django behavior
   - Maintain identical data structures
   - Preserve business logic flow
   - Document any technical differences

3. After implementation:
   - Verify feature completeness
   - Test edge cases match Django
   - Update documentation
   - Mark feature as parity-verified

### Quality Assurance

1. Testing Requirements
   - Test cases must cover Django functionality
   - Behavior must match Django implementation
   - Performance metrics must be comparable
   - Document any differences in approach

2. Documentation Requirements
   - Reference original Django features
   - Explain implementation differences
   - Document Laravel-specific enhancements
   - Maintain feature parity tracking

3. Review Process
   - Compare against Django source
   - Verify feature completeness
   - Test user workflows
   - Document verification results

### Exceptions

1. Allowed Deviations
   - Performance improvements
   - Security enhancements
   - Framework-specific optimizations
   - Modern browser capabilities

2. Required Documentation
   - Justify any deviations
   - Document improvements
   - Explain technical decisions
   - Track affected features