mirror of
https://github.com/pacnpal/thrillwiki_laravel.git
synced 2025-12-20 09:51:10 -05:00
Refactor Location model to integrate PostGIS for spatial data, add legacy coordinate fields for compatibility, and enhance documentation for geocoding service implementation.
This commit is contained in:
105
.clinerules
Normal file
105
.clinerules
Normal file
@@ -0,0 +1,105 @@
|
||||
# Project Rules
|
||||
|
||||
## Feature Parity Requirements
|
||||
|
||||
IMPORTANT: This Laravel/Livewire project must maintain strict feature parity with the original Django project at '/Users/talor/thrillwiki_django_no_react'.
|
||||
|
||||
### 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
|
||||
Reference in New Issue
Block a user