mirror of
https://github.com/pacnpal/thrillwiki_laravel.git
synced 2025-12-20 06:51:10 -05:00
110 lines
3.2 KiB
Plaintext
110 lines
3.2 KiB
Plaintext
# 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 |