feat: Enhance Park Detail Endpoint with Media URL Service Integration

- Updated ParkDetailOutputSerializer to utilize MediaURLService for generating Cloudflare URLs and friendly URLs for park photos.
- Added support for multiple lookup methods (ID and slug) in the park detail endpoint.
- Improved documentation for the park detail endpoint, including request properties and response structure.
- Created MediaURLService for generating SEO-friendly URLs and handling Cloudflare image URLs.
- Comprehensive updates to frontend documentation to reflect new endpoint capabilities and usage examples.
- Added detailed park detail endpoint documentation, including request and response structures, field descriptions, and usage examples.

.clinerules/cline_rules.md

@@ -1,23 +1,77 @@
-## Mandatory Development Rules
+## Brief overview
+Critical thinking rules for frontend design decisions. No excuses for poor design choices that ignore user vision.
 
-### API Organization
+## Rule compliance and design decisions
+- Read ALL .clinerules files before making any code changes
+- Never assume exceptions to rules marked as "MANDATORY"
+- Take full responsibility for rule violations without excuses
+- Ask "What is the most optimal approach?" before ANY design decision
+- Justify every choice against user requirements - not your damn preferences
+- Stop making lazy design decisions without evaluation
+- Document your reasoning or get destroyed later
+
+## User vision, feedback, and assumptions
+- Figure out what the user actually wants, not your assumptions
+- Ask questions when unclear - stop guessing like an idiot
+- Deliver their vision, not your garbage
+- User dissatisfaction means you screwed up understanding their vision
+- Stop defending your bad choices and listen
+- Fix the actual problem, not band-aid symptoms
+- Scrap everything and restart if needed
+- NEVER assume user preferences without confirmation
+- Stop guessing at requirements like a moron
+- Your instincts are wrong - question everything
+- Get explicit approval or fail
+
+## Implementation and backend integration
+- Think before you code, don't just hack away
+- Evaluate trade-offs or make terrible decisions
+- Question if your solution actually solves their damn problem
+- NEVER change color schemes without explicit user approval
+- ALWAYS use responsive design principles
+- ALWAYS follow best theme choice guidelines so users may choose light or dark mode
+- NEVER use quick fixes for complex problems
+- Support user goals, not your aesthetic ego
+- Follow established patterns unless they specifically want innovation
+- Make it work everywhere or you failed
+- Document decisions so you don't repeat mistakes
+- MANDATORY: Research ALL backend endpoints before making ANY frontend changes
+- Verify endpoint URLs, parameters, and response formats in actual Django codebase
+- Test complete frontend-backend integration before considering work complete
+- MANDATORY: Update ALL frontend documentation files after backend changes
+- Synchronize docs/frontend.md, docs/lib-api.ts, and docs/types-api.ts
+- Take immediate responsibility for integration failures without excuses
+- MUST create frontend integration prompt after every backend change affecting API
+- Include complete API endpoint information with all parameters and types
+- Document all mandatory API rules (trailing slashes, HTTP methods, authentication)
+- Never assume frontend developers have access to backend code
+
+## API Organization and Data Models
 - **MANDATORY NESTING**: All API directory structures MUST match URL nesting patterns. No exceptions.
-- **NO TOP-LEVEL ENDPOINTS**: URLs must be nested under top-level domains. Avoid creating separate top-level API endpoints - nest them under existing domains instead.
-
-### Data Model Rules
+- **NO TOP-LEVEL ENDPOINTS**: URLs must be nested under top-level domains
+- **MANDATORY TRAILING SLASHES**: All API endpoints MUST include trailing forward slashes unless ending with query parameters
+- Validate all endpoint URLs against the mandatory trailing slash rule
 - **RIDE TYPES vs RIDE MODELS**: These are separate concepts for ALL ride categories:
   - **Ride Types**: How rides operate (e.g., "inverted", "trackless", "spinning", "log flume", "monorail")
   - **Ride Models**: Specific manufacturer products (e.g., "B&M Dive Coaster", "Vekoma Boomerang")
   - Individual rides reference BOTH the model (what product) and type (how it operates)
   - Ride types must be available for ALL ride categories, not just roller coasters
 
-### Development Commands
+## Development Commands and Code Quality
 - **Django Server**: Always use `uv run manage.py runserver_plus` instead of `python manage.py runserver`
 - **Django Migrations**: Always use `uv run manage.py makemigrations` and `uv run manage.py migrate` instead of `python manage.py`
 - **Package Management**: Always use `uv add <package>` instead of `pip install <package>`
 - **Django Management**: Always use `uv run manage.py <command>` instead of `python manage.py <command>`
+- Break down methods with high cognitive complexity (>15) into smaller, focused helper methods
+- Extract logical operations into separate methods with descriptive names
+- Use single responsibility principle - each method should have one clear purpose
+- Prefer composition over deeply nested conditional logic
+- Always handle None values explicitly to avoid type errors
+- Use proper type annotations, including union types (e.g., `Polygon | None`)
+- Structure API views with clear separation between parameter handling, business logic, and response building
+- When addressing SonarQube or linting warnings, focus on structural improvements rather than quick fixes
 
-### ThrillWiki Project Rules
+## ThrillWiki Project Rules
 - **Domain Structure**: Parks contain rides, rides have models, companies have multiple roles (manufacturer/operator/designer)
 - **Media Integration**: Use CloudflareImagesField for all photo uploads with variants and transformations
 - **Tracking**: All models use pghistory for change tracking and TrackedModel base class
@@ -30,38 +84,8 @@
 - **Search Integration**: Text search, filtering, autocomplete endpoints, pagination
 - **Statistics**: Cached stats endpoints with automatic invalidation via Django signals
 
-### CRITICAL DOCUMENTATION RULE
-- CRITICAL: After every change, it is MANDATORY to update docs/frontend.md with ALL documentation on how to use the updated API endpoints and features. Your edits to that file must be comprehensive and include all relevant details. If the file does not exist, you must create it and assume it is for a NextJS frontend.
-- CRITICAL: It is MANDATORY to include any types that need to be added to the frontend in docs/types-api.ts for NextJS as the file would appear in `src/types/api.ts` in the NextJS project exactly. Again, create it if it does not exist. Make sure it is in sync with docs/api.ts. Full type safety.
-- IT IS MANDATORY that api calls include a trailing forward slash. See example below. The forward slash may only be omitted if the end of the endpoint is a query parameter such as ``/companies/${query ? `?${query}` : ''}` or `/map/locations/${createQuery(params)}`.
-  Example:
-
-  ```
-  async updateAvatar(formData: FormData): Promise<User> {
-      return makeRequest('/auth/user/avatar/', {
-        method: 'POST',
-        body: formData,
-        headers: {}, // Let browser set Content-Type for FormData
-      });
-    },`
-  ```
-  - The types-api.ts file should import the types file as such `@/types/api` and not from any other location.
-- CRITICAL: It is MANDATORY to include any new API endpoints in docs/lib-api.ts for NextJS as the file would appear in `/src/lib/api.ts` in the NextJS project exactly. Again, create it if it does not exist. Make sure it is in sync with docs/types.ts. Full type safety.
-
-### CRITICAL DATA RULE
+## CRITICAL RULES
+- **DOCUMENTATION**: After every change, it is MANDATORY to update docs/frontend.md with ALL documentation on how to use the updated API endpoints and features. It is MANDATORY to include any types in docs/types-api.ts for NextJS as the file would appear in `src/types/api.ts`. It is MANDATORY to include any new API endpoints in docs/lib-api.ts for NextJS as the file would appear in `/src/lib/api.ts`. Maintain accuracy and compliance in all technical documentation. Ensure API documentation matches backend URL routing expectations.
 - **NEVER MOCK DATA**: You are NEVER EVER to mock any data unless it's ONLY for API schema documentation purposes. All data must come from real database queries and actual model instances. Mock data is STRICTLY FORBIDDEN in all API responses, services, and business logic.
-
-### CRITICAL DOMAIN SEPARATION RULE
-- **OPERATORS AND PROPERTY_OWNERS ARE FOR PARKS ONLY**: Company roles OPERATOR and PROPERTY_OWNER are EXCLUSIVELY for parks domain. They should NEVER be used in rides URLs or ride-related contexts. Only MANUFACTURER and DESIGNER roles are for rides domain.
-- **Correct URL patterns**:
-  - Parks: `/parks/{park_slug}/` and `/parks/` showing a global list of parks with all possible fields.
-  - Rides: `/parks/{park_slug}/rides/{ride_slug}/` and `/rides/` showing a global list of rides with all possible fields.
-  - Parks Companies: `/parks/operators/{operator_slug}/` and `/parks/owners/{owner_slug}/` and `/parks/operators/` and `/parks/owners/` showing a global list of park operators or owners respectively with filter options based on all fields.
-  - Rides Companies: `/rides/manufacturers/{manufacturer_slug}/` and `/rides/designers/{designer_slug}/` and `/rides/manufacturers/` and `/rides/designers/` showing a global list of ride manufacturers or designers respectively with filter options based on all fields.
-- **NEVER mix these domains** - this is a fundamental and DANGEROUS business rule violation.
-
-### CRITICAL PHOTO MANAGEMENT RULE
-- **Use CloudflareImagesField**: All photo uploads must use CloudflareImagesField with variants and transformations.
-- **Photo Types**: Clearly define and use photo types (e.g., banner, card) for all images.
-- **Attribution Fields**: Include attribution fields for all photos, specifying the source and copyright information.
-- **Primary Photo Logic**: Implement logic to determine the primary photo for each model, ensuring consistency across the application.
+- **DOMAIN SEPARATION**: Company roles OPERATOR and PROPERTY_OWNER are EXCLUSIVELY for parks domain. They should NEVER be used in rides URLs or ride-related contexts. Only MANUFACTURER and DESIGNER roles are for rides domain. Parks: `/parks/{park_slug}/` and `/parks/`. Rides: `/parks/{park_slug}/rides/{ride_slug}/` and `/rides/`. Parks Companies: `/parks/operators/{operator_slug}/` and `/parks/owners/{owner_slug}/`. Rides Companies: `/rides/manufacturers/{manufacturer_slug}/` and `/rides/designers/{designer_slug}/`. NEVER mix these domains - this is a fundamental and DANGEROUS business rule violation.
+- **PHOTO MANAGEMENT**: Use CloudflareImagesField for all photo uploads with variants and transformations. Clearly define and use photo types (e.g., banner, card) for all images. Include attribution fields for all photos. Implement logic to determine the primary photo for each model.

.clinerules/code-complexity-management.md

@@ -1,37 +0,0 @@
-## Brief overview
-Guidelines for managing code complexity and maintaining clean, maintainable code in Django projects. These rules focus on reducing cognitive complexity, improving code organization, and following best practices for refactoring complex methods.
-
-## Cognitive complexity management
-- Always break down methods with high cognitive complexity (>15) into smaller, focused helper methods
-- Extract logical operations into separate methods with descriptive names
-- Use single responsibility principle - each method should have one clear purpose
-- Prefer composition over deeply nested conditional logic
-- When refactoring complex methods, maintain original functionality while improving structure
-
-## Method extraction patterns
-- Create helper methods for parameter parsing and validation
-- Separate data retrieval logic from serialization logic
-- Extract cache operations into dedicated methods
-- Use descriptive method names that clearly indicate their purpose (e.g., `_serialize_park_data`, `_get_parks_data`)
-- Keep helper methods focused and avoid creating new complexity within them
-
-## Error handling and type safety
-- Always handle None values explicitly to avoid type errors
-- Use proper type annotations, including union types (e.g., `Polygon | None`)
-- Implement fallback mechanisms for operations that may not be available in all environments
-- Validate input parameters before processing to prevent runtime errors
-- Use `getattr()` with defaults when accessing potentially missing attributes
-
-## Django API view organization
-- Structure API views with clear separation between parameter handling, business logic, and response building
-- Use helper methods to reduce the main method complexity while preserving readability
-- Maintain consistent error response formats across all endpoints
-- Implement proper caching strategies with appropriate fallbacks
-- Follow DRF patterns for serialization and response construction
-
-## Refactoring approach
-- When addressing SonarQube or linting warnings, focus on structural improvements rather than quick fixes
-- Preserve all original functionality during refactoring
-- Test edge cases and error conditions after complexity reduction
-- Maintain API contracts and response formats
-- Document complex business logic within helper methods when necessary

.clinerules/frontend-integration-prompts.md

@@ -1,40 +0,0 @@
-## Brief overview
-Guidelines for creating comprehensive frontend integration prompts after any backend changes that affect the frontend API. These rules ensure frontend developers have all necessary information to implement changes without requiring code samples or extensive back-and-forth communication.
-
-## Mandatory prompt creation
-- MUST create a frontend integration prompt after every backend change that affects API endpoints, parameters, or data structures
-- Prompt files should be saved in the docs/ directory with descriptive names ending in "-llm-prompt.md"
-- Never assume frontend developers have access to backend code or can infer implementation details
-
-## Prompt content requirements
-- Include complete API endpoint information with all parameters and their types
-- Document all mandatory API rules (trailing slashes, HTTP methods, authentication requirements)
-- Provide comprehensive parameter lists organized by logical categories
-- Explain data relationships and hierarchies that affect frontend implementation
-- Include error handling requirements and expected response formats
-
-## Information organization
-- Start with project context and high-level objectives
-- Group related parameters and concepts into logical sections
-- Use clear headings and bullet points for easy scanning
-- Avoid code samples but include detailed technical specifications
-- Document both required and optional parameters with clear descriptions
-
-## Frontend-specific considerations
-- Include TypeScript integration requirements and type safety guidelines
-- Document state management patterns and URL synchronization needs
-- Provide user experience recommendations for complex filtering interfaces
-- Explain performance optimization strategies relevant to the changes
-- Include testing considerations and validation requirements
-
-## Backend compatibility notes
-- Always confirm which features are fully supported vs planned
-- Document any database schema changes that affect API behavior
-- Explain data source patterns (real database queries vs static lists)
-- Include information about caching, pagination, and response metadata
-
-## Documentation maintenance
-- Update existing frontend documentation files when creating new prompts
-- Ensure consistency between lib-api.ts, types-api.ts, and frontend.md files
-- Reference related documentation files and their current status
-- Include version information or timestamps when relevant for tracking changes

.clinerules/mandatory-compliance-enforcement.md

@@ -1,32 +0,0 @@
-## Brief overview
-This rule file establishes strict compliance enforcement protocols for mandatory development standards. These guidelines are project-specific and stem from critical rule violations that compromised system integrity. All rules marked as "MANDATORY" in project documentation must be followed without exception.
-
-## Rule compliance verification
-- Always read and review ALL .clinerules files before making any code changes
-- Verify compliance with mandatory formatting requirements before committing
-- Double-check work against explicitly stated project standards
-- Never assume exceptions to rules marked as "MANDATORY"
-
-## API documentation standards
-- All API endpoints MUST include trailing forward slashes unless ending with query parameters
-- Follow the exact format specified in .clinerules for API endpoint documentation
-- Validate all endpoint URLs against the mandatory trailing slash rule
-- Ensure consistency across all API documentation files
-
-## Quality assurance protocols
-- Perform systematic review of all changes against project rules
-- Validate that modifications comply with architectural standards
-- Check for systematic patterns that might indicate rule violations
-- Implement self-review processes before submitting any work
-
-## Accountability measures
-- Take full responsibility for rule violations without excuses
-- Acknowledge when mandatory standards have been compromised
-- Accept consequences for systematic non-compliance
-- Demonstrate commitment to following established project standards
-
-## Documentation integrity
-- Maintain accuracy and compliance in all technical documentation
-- Ensure API documentation matches backend URL routing expectations
-- Preserve system architecture integrity through compliant documentation
-- Follow project-specific formatting requirements exactly as specified