thrillwiki_laravel/memory-bank/features/RideCrudSystemPrompt.md

Ride CRUD System Implementation Prompt

Date: June 22, 2025
Priority: HIGH - Next Major Implementation
Status: 🔄 READY FOR IMPLEMENTATION

🎠 RIDE CRUD SYSTEM DEVELOPMENT PROMPT

Objective

Implement a complete Ride CRUD system leveraging the proven patterns established from the successful Park CRUD system implementation. Apply 99% time reduction using ThrillWiki custom generators.

Implementation Strategy

Leverage Established Patterns: Use the successful Park system patterns for rapid development

• Pattern Reuse: Copy proven Park component architecture
• ThrillWiki Generators: Utilize custom artisan commands for acceleration
• Django Parity: Maintain 100% feature equivalence with Django ride system
• Mobile-First: Apply same responsive design standards

Primary Generator Command

php artisan make:thrillwiki-crud Ride --api --with-tests

Core Requirements

1. Ride Entity Features (Based on Django Parity)

• Basic Information: Name, description, ride type, status
• Technical Specifications: Height requirements, duration, capacity
• Relationships: Park (belongsTo), manufacturer, designer, area
• Statistics: Rider count, popularity metrics, safety records
• Operational Data: Opening/closing dates, seasonal availability

2. Advanced Features (Beyond Basic CRUD)

• Ride Type Filtering: Roller coaster, flat ride, water ride, dark ride categories
• Technical Specifications: Speed, height, inversions, length
• Safety Information: Height restrictions, health warnings, accessibility
• Real-time Status: Operating, closed, maintenance, weather-dependent
• Capacity Management: Throughput, queue times, ride capacity

3. Livewire Components to Generate

RideListComponent (Following Park Pattern):

• Advanced Search: Name, ride type, park, manufacturer search
• Multi-criteria Filtering: Status, type, park, height requirements
• Comprehensive Sorting: Name, opening date, popularity, thrill level
• View Modes: Grid view (ride cards) and list view (compact table)
• Performance: Pagination, eager loading, mobile optimization

RideFormComponent (Following Park Pattern):

• Create/Edit Modes: New ride creation and existing ride modification
• Relationship Management: Park selection, manufacturer/designer dropdowns
• Technical Fields: Height requirements, duration, capacity inputs
• Validation: Comprehensive validation rules with real-time feedback
• File Uploads: Support for ride photos and technical documents

4. Ride-Specific Extensions

Additional Features Beyond Park Pattern:

• Coaster Statistics: Track inversions, speed, height for roller coasters
• Safety Validation: Ensure height requirements are within reasonable ranges
• Manufacturer Integration: Enhanced manufacturer relationship with ride types
• Park Area Integration: Optional park area assignment for location within park
• Queue Time Integration: Foundation for future wait time features

Technical Implementation Details

Smart Trait Integration (Automatic)

• HasSlugHistory: Ride slug management and history tracking
• HasStatistics: Rider counts and popularity metrics
• SoftDeletes: Safe deletion with recovery capability
• HasCaching: Performance optimization for frequently accessed rides

Relationship Configuration (Pre-configured)

• park: belongsTo(Park) - Required parent relationship
• area: belongsTo(ParkArea) - Optional location within park
• manufacturer: belongsTo(Operator, 'manufacturer_id') - Ride manufacturer
• designer: belongsTo(Operator, 'designer_id') - Ride designer
• photos: morphMany(Photo) - Ride image gallery
• reviews: morphMany(Review) - User reviews and ratings

Database Schema Requirements

-- Key fields to be generated:
name (string, required, unique within park)
slug (string, indexed)
description (text, nullable)
ride_type (enum: coaster, flat, water, dark, transport)
status (enum: operating, closed, maintenance, seasonal)
park_id (foreign key, required)
area_id (foreign key, nullable)
manufacturer_id (foreign key, nullable)
designer_id (foreign key, nullable)
opening_date (date, nullable)
closing_date (date, nullable)
height_requirement_min (integer, nullable, cm)
height_requirement_max (integer, nullable, cm)
duration_minutes (decimal, nullable)
capacity_per_hour (integer, nullable)
max_speed_kmh (decimal, nullable)
max_height_meters (decimal, nullable)
inversions_count (integer, nullable, default 0)
length_meters (decimal, nullable)
ride_count (bigint, default 0)
popularity_score (decimal, default 0.0)

Mobile-First Requirements

Performance Targets

• 3G Network Support: <3 second load times on mobile networks
• Touch Targets: Minimum 44px for all interactive elements
• Responsive Design: Mobile-first with breakpoints (320px, 768px, 1024px, 1280px)
• Progressive Enhancement: Works without JavaScript, enhanced with Livewire

User Experience Standards

• Search Optimization: Debounced search (300ms) with loading indicators
• Filter Persistence: Query string persistence for bookmarkable filter states
• Touch Gestures: Swipe navigation between ride details
• Loading States: Skeleton screens during data fetching

Django Parity Requirements

Feature Equivalence

• Search Functionality: Text search across name, description, park
• Filtering Options: Status, type, park, height requirements
• Sorting Capabilities: Name, date, popularity, technical specifications
• CRUD Operations: Create, read, update, delete with proper validation
• Relationship Management: Seamless park and manufacturer integration

Data Validation (Django-equivalent)

• Name Uniqueness: Unique within park scope
• Height Requirements: Logical validation (min < max, reasonable ranges)
• Technical Specifications: Non-negative values for speed, height, capacity
• Date Validation: Opening date before closing date, reasonable date ranges
• Relationship Integrity: Valid park, manufacturer, designer references

Testing Requirements

Automated Test Coverage

• Component Tests: RideListComponent and RideFormComponent functionality
• Feature Tests: CRUD operations, search, filtering, sorting
• Validation Tests: Form validation rules and error handling
• Relationship Tests: Park, manufacturer, designer associations
• Performance Tests: Query optimization and mobile performance

Test Scenarios

• Create Ride: New ride creation with full validation
• Edit Ride: Modification of existing rides with relationship updates
• Search Functionality: Text search across multiple fields
• Filter Combinations: Multiple filter criteria simultaneously
• Sort Operations: All sort fields with ascending/descending
• Mobile Interaction: Touch targets and responsive behavior

Success Criteria

Completion Metrics

• ✅ RideListComponent: Advanced search, filtering, sorting, pagination
• ✅ RideFormComponent: Create/edit forms with comprehensive validation
• ✅ Component Views: Mobile-first responsive templates
• ✅ Component Tests: Full test coverage for both components
• ✅ Django Parity: 100% feature equivalence achieved
• ✅ Mobile Optimization: Touch-friendly, 3G network optimized
• ✅ Documentation: Complete Memory Bank documentation

Performance Benchmarks

• Generation Speed: <5 seconds total generation time (99% faster than manual)
• Load Performance: <3 seconds on 3G networks
• Query Efficiency: <50ms database queries with eager loading
• Mobile Usability: 44px touch targets, thumb-friendly navigation

Implementation Process

Step 1: Generate Foundation

php artisan make:thrillwiki-crud Ride --api --with-tests

Step 2: Verify Generation

• Confirm all files are created successfully
• Check component classes exist and are properly structured
• Verify view templates are generated with ThrillWiki patterns
• Ensure test files are created with comprehensive coverage

Step 3: Customize Ride-Specific Features

• Add ride type filtering logic
• Implement technical specification fields
• Enhance manufacturer/designer relationships
• Add coaster-specific statistics tracking

Step 4: Test Implementation

• Run automated test suite
• Verify mobile responsiveness
• Test search and filtering functionality
• Validate Django parity compliance

Step 5: Document Results

• Update Memory Bank with implementation details
• Document any customizations or deviations
• Record performance metrics and benchmarks
• Prepare for next entity implementation

Expected Deliverables

Generated Files

• RideListComponent (~130-150 lines)
• RideFormComponent (~100-120 lines)
• Component Views (~300-350 total lines)
• Component Tests (~70-90 total lines)
• Ride Controller (Full CRUD with API endpoints)
• Ride Views (index, show, create, edit)
• RideRequest (Form validation)
• Database Migration (If needed)

Documentation Updates

• Memory Bank Documentation: Complete implementation record
• Pattern Documentation: Ride-specific patterns and extensions
• Test Coverage Report: Comprehensive test verification
• Performance Metrics: Mobile optimization and load time results

Risk Mitigation

Potential Challenges

• Complex Relationships: Ride-park-manufacturer relationships
• Technical Field Validation: Speed, height, capacity validation rules
• Mobile Performance: Large dataset pagination and filtering
• Django Parity: Matching exact Django ride functionality

Mitigation Strategies

• Leverage Park Patterns: Use proven relationship management approaches
• Incremental Testing: Test each component as it's generated
• Performance Monitoring: Real-time performance validation
• Reference Documentation: Use Memory Bank Park patterns as reference

Next Steps After Completion

Immediate Follow-up

1. Test Suite Execution: Verify all tests pass
2. Performance Validation: Confirm mobile optimization targets
3. Django Parity Check: Validate feature equivalence
4. Documentation Update: Complete Memory Bank updates

Future Implementation Pipeline

1. 🏢 Operator CRUD System: Theme park operator management
2. 🔍 Global Search Components: Cross-entity search with autocomplete
3. 📱 PWA Features: Service worker and offline capabilities
4. 🌐 API Endpoints: RESTful API for mobile app integration

Status: READY FOR IMMEDIATE IMPLEMENTATION ✅