feat: Update ThrillWiki development rules and context documentation for enhanced clarity and consistency

.clinerules/cline_rules.md

@@ -1,42 +1,98 @@
+---
+description: Core ThrillWiki development rules covering API organization, data models, development commands, code quality standards, and critical business rules
+author: ThrillWiki Development Team
+version: 1.0
+globs: ["**/*.py", "apps/**/*", "thrillwiki/**/*", "**/*.md"]
+tags: ["django", "api-design", "code-quality", "development-commands", "business-rules"]
+---
+
+# ThrillWiki Core Development Rules
+
+## Objective
+This rule defines the fundamental development standards, API organization patterns, code quality requirements, and critical business rules that MUST be followed for all ThrillWiki development work. It ensures consistency, maintainability, and adherence to project-specific constraints.
+
 ## API Organization and Data Models
+
+### Mandatory API Structure
 - **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
 - **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
+- **Validation Required**: Validate all endpoint URLs against the mandatory trailing slash rule
-- **RIDE TYPES vs RIDE MODELS**: These are separate concepts for ALL ride categories:
+
+### Ride System Architecture
+**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)
+- **Implementation**: 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
+- **Coverage**: Ride types MUST be available for ALL ride categories, not just roller coasters
 
 ## 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`
+### Required Commands
-- **Package Management**: Always use `uv add <package>` instead of `pip install <package>`
+- **Django Server**: ALWAYS use `uv run manage.py runserver_plus` instead of `python manage.py runserver`
-- **Django Management**: Always use `uv run manage.py <command>` instead of `python manage.py <command>`
+- **Django Migrations**: ALWAYS use `uv run manage.py makemigrations` and `uv run manage.py migrate` instead of `python manage.py`
-- Break down methods with high cognitive complexity (>15) into smaller, focused helper methods
+- **Package Management**: ALWAYS use `uv add <package>` instead of `pip install <package>`
-- Extract logical operations into separate methods with descriptive names
+- **Django Management**: ALWAYS use `uv run manage.py <command>` instead of `python manage.py <command>`
-- Use single responsibility principle - each method should have one clear purpose
+
-- Prefer composition over deeply nested conditional logic
+### Code Quality Standards
-- Always handle None values explicitly to avoid type errors
+- **Cognitive Complexity**: Break down methods with high cognitive complexity (>15) into smaller, focused helper methods
-- Use proper type annotations, including union types (e.g., `Polygon | None`)
+- **Method Extraction**: Extract logical operations into separate methods with descriptive names
-- Structure API views with clear separation between parameter handling, business logic, and response building
+- **Single Responsibility**: Each method SHOULD have one clear purpose
-- When addressing SonarQube or linting warnings, focus on structural improvements rather than quick fixes
+- **Logic Structure**: Prefer composition over deeply nested conditional logic
+- **Null Handling**: ALWAYS handle None values explicitly to avoid type errors
+- **Type Annotations**: Use proper type annotations, including union types (e.g., `Polygon | None`)
+- **API Structure**: Structure API views with clear separation between parameter handling, business logic, and response building
+- **Quality Improvements**: When addressing SonarQube or linting warnings, focus on structural improvements rather than quick fixes
 
 ## ThrillWiki Project Rules
+
+### Domain Architecture
 - **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
+- **Change Tracking**: All models use pghistory for change tracking and TrackedModel base class
-- **Slugs**: Unique within scope (park slugs global, ride slugs within park, ride model slugs within manufacturer)
+- **Slug Management**: Unique within scope (park slugs global, ride slugs within park, ride model slugs within manufacturer)
+
+### Status and Role Management
 - **Status Management**: Rides have operational status (OPERATING, CLOSED_TEMP, SBNO, etc.) with date tracking
 - **Company Roles**: Companies can be MANUFACTURER, OPERATOR, DESIGNER, PROPERTY_OWNER with array field
 - **Location Data**: Use PostGIS for geographic data, separate location models for parks and rides
+
+### Technical Patterns
 - **API Patterns**: Use DRF with drf-spectacular, comprehensive serializers, nested endpoints, caching
 - **Photo Management**: Banner/card image references, photo types, attribution fields, primary photo logic
 - **Search Integration**: Text search, filtering, autocomplete endpoints, pagination
 - **Statistics**: Cached stats endpoints with automatic invalidation via Django signals
 
 ## CRITICAL RULES
-- **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.
+
-- **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.
+### Data Integrity (ABSOLUTE)
-- **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.
+🚨 **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.
+
+### Domain Separation (CRITICAL BUSINESS RULE)
+🚨 **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.
+
+**Correct URL Patterns:**
+- **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}/`
+
+⚠️ **WARNING**: NEVER mix these domains - this is a fundamental and DANGEROUS business rule violation.
+
+### Photo Management Standards
+🚨 **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
+
+## Verification Checklist
+
+Before implementing any changes, verify:
+- [ ] All API endpoints have trailing slashes
+- [ ] Domain separation is maintained (parks vs rides companies)
+- [ ] No mock data is used outside of schema documentation
+- [ ] Proper uv commands are used for all Django operations
+- [ ] Type annotations are complete and accurate
+- [ ] Methods follow single responsibility principle
+- [ ] CloudflareImagesField is used for all photo uploads

.clinerules/rich-choice-objects.md

@@ -1,17 +1,100 @@
-## Brief overview
+---
+description: Mandatory Rich Choice Objects system enforcement for ThrillWiki project replacing Django tuple-based choices with rich metadata-driven choice fields
+author: ThrillWiki Development Team
+version: 1.0
+globs: ["apps/**/choices.py", "apps/**/models.py", "apps/**/serializers.py", "apps/**/__init__.py"]
+tags: ["django", "choices", "rich-choice-objects", "data-modeling", "mandatory"]
+---
+
+# Rich Choice Objects System (MANDATORY)
+
+## Objective
+This rule enforces the mandatory use of the Rich Choice Objects system instead of Django's traditional tuple-based choices for ALL choice fields in the ThrillWiki project. It ensures consistent, metadata-rich choice handling with enhanced UI capabilities and maintainable code patterns.
+
+## Brief Overview
 Mandatory use of Rich Choice Objects system instead of Django tuple-based choices for all choice fields in ThrillWiki project.
 
-## Rich Choice Objects enforcement
+## Rich Choice Objects Enforcement
-- NEVER use Django tuple-based choices (e.g., `choices=[('VALUE', 'Label')]`) - ALWAYS use RichChoiceField
+
-- All choice fields MUST use `RichChoiceField(choice_group="group_name", domain="domain_name")` pattern
+### Absolute Requirements
-- Choice definitions MUST be created in domain-specific `choices.py` files using RichChoice dataclass
+🚨 **NEVER use Django tuple-based choices** (e.g., `choices=[('VALUE', 'Label')]`) - ALWAYS use RichChoiceField
-- All choices MUST include rich metadata (color, icon, description, css_class at minimum)
+
-- Choice groups MUST be registered with global registry using `register_choices()` function
+### Implementation Standards
-- Import choices in domain `__init__.py` to trigger auto-registration on Django startup
+- **Field Usage**: All choice fields MUST use `RichChoiceField(choice_group="group_name", domain="domain_name")` pattern
-- Use ChoiceCategory enum for proper categorization (STATUS, CLASSIFICATION, TECHNICAL, SECURITY)
+- **Choice Definitions**: MUST be created in domain-specific `choices.py` files using RichChoice dataclass
-- Leverage rich metadata for UI styling, permissions, and business logic instead of hardcoded values
+- **Rich Metadata**: All choices MUST include rich metadata (color, icon, description, css_class at minimum)
-- DO NOT maintain backwards compatibility with tuple-based choices - migrate fully to Rich Choice Objects
+- **Registration**: Choice groups MUST be registered with global registry using `register_choices()` function
-- Ensure all existing models using tuple-based choices are refactored to use RichChoiceField
+- **Auto-Registration**: Import choices in domain `__init__.py` to trigger auto-registration on Django startup
-- Validate choice groups are correctly loaded in registry during application startup
+
-- Update serializers to use RichChoiceSerializer for choice fields
+### Required Patterns
-- Follow established patterns from rides, parks, and accounts domains for consistency
+- **Categorization**: Use ChoiceCategory enum for proper categorization (STATUS, CLASSIFICATION, TECHNICAL, SECURITY)
+- **Business Logic**: Leverage rich metadata for UI styling, permissions, and business logic instead of hardcoded values
+- **Serialization**: Update serializers to use RichChoiceSerializer for choice fields
+
+### Migration Requirements
+- **NO Backwards Compatibility**: DO NOT maintain backwards compatibility with tuple-based choices - migrate fully to Rich Choice Objects
+- **Model Refactoring**: Ensure all existing models using tuple-based choices are refactored to use RichChoiceField
+- **Validation**: Validate choice groups are correctly loaded in registry during application startup
+
+### Domain Consistency
+- **Follow Established Patterns**: Follow established patterns from rides, parks, and accounts domains for consistency
+- **Domain-Specific Organization**: Maintain domain-specific choice organization in separate `choices.py` files
+
+## Implementation Checklist
+
+Before implementing choice fields, verify:
+- [ ] RichChoiceField is used instead of Django tuple choices
+- [ ] Choice group and domain are properly specified
+- [ ] Rich metadata includes color, icon, description, css_class
+- [ ] Choices are defined in domain-specific `choices.py` file
+- [ ] Choice group is registered with `register_choices()` function
+- [ ] Domain `__init__.py` imports choices for auto-registration
+- [ ] Appropriate ChoiceCategory enum is used
+- [ ] Serializers use RichChoiceSerializer for choice fields
+- [ ] No tuple-based choices remain in the codebase
+
+## Examples
+
+### ✅ CORRECT Implementation
+```python
+# In apps/rides/choices.py
+from core.choices import RichChoice, ChoiceCategory, register_choices
+
+RIDE_STATUS_CHOICES = [
+    RichChoice(
+        value="operating",
+        label="Operating",
+        color="#10b981",
+        icon="check-circle",
+        description="Ride is currently operating normally",
+        css_class="status-operating",
+        category=ChoiceCategory.STATUS
+    ),
+    # ... more choices
+]
+
+register_choices("ride_status", RIDE_STATUS_CHOICES, domain="rides")
+
+# In models.py
+status = RichChoiceField(choice_group="ride_status", domain="rides")
+```
+
+### ❌ FORBIDDEN Implementation
+```python
+# NEVER DO THIS - Tuple-based choices are forbidden
+STATUS_CHOICES = [
+    ('operating', 'Operating'),
+    ('closed', 'Closed'),
+]
+
+status = models.CharField(max_length=20, choices=STATUS_CHOICES)
+```
+
+## Verification Steps
+
+To ensure compliance:
+1. Search codebase for any remaining tuple-based choice patterns
+2. Verify all choice fields use RichChoiceField
+3. Confirm all choices have complete rich metadata
+4. Test choice group registration during application startup
+5. Validate serializers use RichChoiceSerializer where appropriate

.clinerules/thrillwiki-context.md

@@ -1,50 +1,161 @@
-## ThrillWiki Django App Context
+---
+description: Comprehensive ThrillWiki Django project context including architecture, development patterns, business rules, and mandatory Context7 MCP integration workflow
+author: ThrillWiki Development Team
+version: 2.0
+globs: ["**/*.py", "**/*.html", "**/*.js", "**/*.css", "**/*.md"]
+tags: ["django", "architecture", "api-design", "business-rules", "context7-integration", "thrillwiki"]
+---
 
-### Project Overview
+# ThrillWiki Django Project Context
+
+## Objective
+This rule provides comprehensive context for the ThrillWiki project, defining core architecture patterns, business rules, development workflows, and mandatory integration requirements. It serves as the primary reference for maintaining consistency across all ThrillWiki development activities.
+
+## Project Overview
 ThrillWiki is a comprehensive theme park database platform with user-generated content, expert moderation, and rich media support. Built with Django REST Framework, it serves 120+ API endpoints for parks, rides, companies, and user management.
 
-### Core Architecture
+## Core Architecture
+
+### Technology Stack
 - **Backend**: Django 5.0+ with DRF, PostgreSQL + PostGIS, Redis caching, Celery tasks
-- **Frontend**: HTMX + AlpineJS + Tailwind CSS + Django-Cotton (NO React/Vue/Angular allowed)
+- **Frontend**: HTMX + AlpineJS + Tailwind CSS + Django-Cotton 
+  - 🚨 **CRITICAL**: NO React/Vue/Angular allowed
 - **Media**: Cloudflare Images using Direct Upload with variants and transformations
 - **Tracking**: pghistory for all model changes, TrackedModel base class
 - **Choices**: Rich Choice Objects system (NEVER use Django tuple choices)
 
-### Domain Structure
+### Domain Architecture
-- **Parks Domain**: parks/, companies (OPERATOR/PROPERTY_OWNER roles only)
+- **Parks Domain**: `parks/`, companies (OPERATOR/PROPERTY_OWNER roles only)
-- **Rides Domain**: rides/, companies (MANUFACTURER/DESIGNER roles only)
+- **Rides Domain**: `rides/`, companies (MANUFACTURER/DESIGNER roles only)
-- **Core Apps**: accounts/, media/, moderation/, core/
+- **Core Apps**: `accounts/`, `media/`, `moderation/`, `core/`
-- **CRITICAL**: Never mix park/ride company roles - fundamental business rule
+- 🚨 **CRITICAL BUSINESS RULE**: Never mix park/ride company roles - fundamental business rule violation
 
-### Key Patterns
+## Development Patterns
-- **Models**: All inherit TrackedModel, use SluggedModel for slugs with history
-- **API**: Nested URLs (/parks/{slug}/rides/{slug}/), mandatory trailing slashes
-- **Choices**: RichChoiceField with metadata (color, icon, description, css_class)
-- **Photos**: CloudflareImagesField with photo types and attribution
-- **Location**: PostGIS for geographic data, separate location models
 
-### Development Commands
+### Model Patterns
-- **Server**: `uv run manage.py runserver_plus` (NOT python manage.py)
+- **Base Classes**: All models MUST inherit from TrackedModel
-- **Migrations**: `uv run manage.py makemigrations/migrate`
+- **Slug Handling**: Use SluggedModel for slugs with history tracking
-- **Packages**: `uv add <package>` (NOT pip install)
+- **Location Data**: Use PostGIS for geographic data, separate location models
-- **Management**: Always use `uv run manage.py <command>`
+- **Media Fields**: Use CloudflareImagesField for all image handling
 
-### API Rules
+### API Design Patterns
+- **URL Structure**: Nested URLs (`/parks/{slug}/rides/{slug}/`)
+- **Trailing Slashes**: MANDATORY trailing slashes on all endpoints
 - **Authentication**: Token-based with role hierarchy (USER/MODERATOR/ADMIN/SUPERUSER)
-- **Filtering**: Comprehensive filtering on rides (25+ parameters), parks (15+ parameters)
+- **Filtering**: Comprehensive filtering - rides (25+ parameters), parks (15+ parameters)
 - **Responses**: Standard DRF pagination, rich error responses with details
 - **Caching**: Multi-level (Redis, CDN, browser) with signal-based invalidation
-- **NEVER MOCK DATA**: All responses must use real database queries
 
-### Rich Choice Objects (MANDATORY)
+### Choice System (MANDATORY)
-- Use `RichChoiceField(choice_group="group_name", domain="domain_name")`
+- **Implementation**: `RichChoiceField(choice_group="group_name", domain="domain_name")`
-- Define choices in domain-specific `choices.py` using RichChoice dataclass
+- **Definition**: Domain-specific `choices.py` using RichChoice dataclass
-- Register with `register_choices()` function in domain `__init__.py`
+- **Registration**: `register_choices()` function in domain `__init__.py`
-- Include rich metadata: color, icon, description, css_class minimum
+- **Required Metadata**: color, icon, description, css_class (minimum)
-- NO tuple-based choices allowed anywhere in codebase
+- 🚨 **FORBIDDEN**: NO tuple-based choices allowed anywhere in codebase
 
-### Frontend Constraints
+## Development Commands
-- HTMX for dynamic updates, AlpineJS for client state, Tailwind for styling
+
-- Progressive enhancement approach required
+### Package Management
-- Must support latest 2 versions of major browsers
+- **Python Packages**: `uv add <package>` (NOT `pip install`)
-- Performance targets: FCP < 1.5s, TTI < 2s, Core Web Vitals compliance
+- **Server**: `uv run manage.py runserver_plus` (NOT `python manage.py`)
+- **Migrations**: `uv run manage.py makemigrations/migrate`
+- **Management**: ALWAYS use `uv run manage.py <command>`
+
+## Business Rules
+
+### Company Role Separation
+- **Parks Domain**: Only OPERATOR and PROPERTY_OWNER roles
+- **Rides Domain**: Only MANUFACTURER and DESIGNER roles
+- 🚨 **CRITICAL**: Never allow cross-domain company roles
+
+### Data Integrity
+- **Model Changes**: All must be tracked via pghistory
+- **API Responses**: MUST use real database data (NEVER MOCK DATA)
+- **Geographic Data**: MUST use PostGIS for accuracy
+
+## Frontend Constraints
+
+### Architecture Requirements
+- **HTMX**: Dynamic updates and AJAX interactions
+- **AlpineJS**: Client-side state management
+- **Tailwind CSS**: Styling framework
+- **Progressive Enhancement**: Required approach
+
+### Performance Targets
+- **First Contentful Paint**: < 1.5s
+- **Time to Interactive**: < 2s
+- **Compliance**: Core Web Vitals compliance
+- **Browser Support**: Latest 2 versions of major browsers
+
+## Context7 MCP Integration (MANDATORY)
+
+### Requirement
+🚨 **CRITICAL**: ALWAYS use Context7 MCP for documentation lookups before making changes
+
+### Libraries Requiring Context7
+- **tailwindcss**: CSS utility classes, responsive design, component styling
+- **django**: Models, views, forms, URL patterns, Django-specific patterns
+- **django-cotton**: Component creation, template organization, Cotton-specific syntax
+- **htmx**: Dynamic updates, form handling, AJAX interactions
+- **alpinejs**: Client-side state management, reactive data, JavaScript interactions
+- **django-rest-framework**: API design, serializers, viewsets, DRF patterns
+- **postgresql**: Database queries, PostGIS functions, advanced SQL features
+- **postgis**: Geographic data handling and spatial queries
+- **redis**: Caching strategies, session management, performance optimization
+
+### Mandatory Workflow Steps
+1. **Before editing/creating code**: Query Context7 for relevant library documentation
+2. **During debugging**: Use Context7 to verify syntax, patterns, and best practices
+3. **When implementing new features**: Reference Context7 for current API and method signatures
+4. **For performance issues**: Consult Context7 for optimization techniques and patterns
+5. **For geographic data handling**: Use Context7 for PostGIS functions and best practices
+6. **For caching strategies**: Refer to Context7 for Redis patterns and best practices
+7. **For database queries**: Utilize Context7 for PostgreSQL best practices and advanced SQL features
+
+### Mandatory Scenarios
+- Creating new Django models or API endpoints
+- Implementing HTMX dynamic functionality
+- Writing AlpineJS reactive components
+- Designing responsive layouts with Tailwind CSS
+- Creating Django-Cotton components
+- Debugging CSS, JavaScript, or Django issues
+- Implementing caching or database optimizations
+- Handling geographic data with PostGIS
+- Utilizing Redis for session management
+- Implementing real-time features with WebSockets
+
+### Context7 Commands
+1. **Resolve Library**: Always call `Context7:resolve-library-id` first to get correct library ID
+2. **Get Documentation**: Then use `Context7:get-library-docs` with appropriate topic parameter
+
+### Example Topics by Library
+- **tailwindcss**: responsive design, flexbox, grid, animations
+- **django**: models, views, forms, admin, signals
+- **django-cotton**: components, templates, slots, props
+- **htmx**: hx-get, hx-post, hx-swap, hx-trigger, hx-target
+- **alpinejs**: x-data, x-show, x-if, x-for, x-model
+- **django-rest-framework**: serializers, viewsets, routers, permissions
+- **postgresql**: joins, indexes, transactions, window functions
+- **postgis**: geospatial queries, distance calculations, spatial indexes
+- **redis**: caching strategies, pub/sub, data structures
+
+## Code Quality Standards
+
+### Model Requirements
+- All models MUST inherit from TrackedModel
+- Use SluggedModel for entities with slugs and history tracking
+- Always use RichChoiceField instead of Django choices
+- Use CloudflareImagesField for all image handling
+- Use PostGIS fields and separate location models for geographic data
+
+### API Requirements
+- MUST include trailing slashes and follow nested pattern
+- All responses MUST use real database queries
+- Implement comprehensive filtering and pagination
+- Use signal-based cache invalidation
+
+### Development Workflow
+- Use uv for all Python package operations
+- Use runserver_plus for enhanced development server
+- Always use `uv run` for Django management commands
+- All functionality MUST work with progressive enhancement

.clinerules/thrillwiki-context.xml

@@ -1,265 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<thrillwiki_context version="1.0">
-  <!-- Core Project Information -->
-  <project_overview>
-    <name>ThrillWiki</name>
-    <description>Comprehensive theme park database platform with user-generated content, expert moderation, and rich media support</description>
-    <framework>Django REST Framework</framework>
-    <api_endpoints>120+</api_endpoints>
-    <primary_entities>
-      <entity>Parks</entity>
-      <entity>Rides</entity>
-      <entity>Companies</entity>
-      <entity>Users</entity>
-    </primary_entities>
-  </project_overview>
-
-  <!-- Technology Stack -->
-  <tech_stack>
-    <backend>
-      <framework>Django 5.0+</framework>
-      <api>Django REST Framework</api>
-      <database>PostgreSQL with PostGIS</database>
-      <caching>Redis</caching>
-      <task_queue>Celery</task_queue>
-    </backend>
-    <frontend>
-      <constraint>NO React/Vue/Angular allowed</constraint>
-      <technologies>
-        <tech name="HTMX" purpose="Dynamic updates"/>
-        <tech name="AlpineJS" purpose="Client-side state management"/>
-        <tech name="Tailwind CSS" purpose="Styling"/>
-        <tech name="Django-Cotton" purpose="Component system"/>
-      </technologies>
-    </frontend>
-    <media>
-      <service>Cloudflare Images</service>
-      <method>Direct Upload with variants and transformations</method>
-    </media>
-    <tracking>
-      <system>pghistory for all model changes</system>
-      <base_class>TrackedModel</base_class>
-    </tracking>
-  </tech_stack>
-
-  <!-- Domain Architecture -->
-  <domain_structure>
-    <domain name="parks">
-      <path>parks/</path>
-      <companies>
-        <allowed_roles>
-          <role>OPERATOR</role>
-          <role>PROPERTY_OWNER</role>
-        </allowed_roles>
-      </companies>
-    </domain>
-    <domain name="rides">
-      <path>rides/</path>
-      <companies>
-        <allowed_roles>
-          <role>MANUFACTURER</role>
-          <role>DESIGNER</role>
-        </allowed_roles>
-      </companies>
-    </domain>
-    <core_apps>
-      <app>accounts/</app>
-      <app>media/</app>
-      <app>moderation/</app>
-      <app>core/</app>
-    </core_apps>
-    <critical_rules>
-      <rule>NEVER mix park/ride company roles - fundamental business rule</rule>
-    </critical_rules>
-  </domain_structure>
-
-  <!-- Development Patterns -->
-  <development_patterns>
-    <models>
-      <base_class>TrackedModel (all models inherit)</base_class>
-      <slug_handling>SluggedModel for slugs with history</slug_handling>
-    </models>
-    <api_design>
-      <url_structure>Nested URLs (/parks/{slug}/rides/{slug}/)</url_structure>
-      <trailing_slash>Mandatory trailing slashes</trailing_slash>
-    </api_design>
-    <choices>
-      <system>RichChoiceField with metadata</system>
-      <metadata>color, icon, description, css_class</metadata>
-      <forbidden>NEVER use Django tuple choices</forbidden>
-    </choices>
-    <media_handling>
-      <field_type>CloudflareImagesField</field_type>
-      <features>photo types and attribution</features>
-    </media_handling>
-    <location>
-      <system>PostGIS for geographic data</system>
-      <structure>separate location models</structure>
-    </location>
-  </development_patterns>
-
-  <!-- Development Commands -->
-  <commands>
-    <server>
-      <command>uv run manage.py runserver_plus</command>
-      <forbidden>python manage.py</forbidden>
-    </server>
-    <migrations>
-      <make>uv run manage.py makemigrations</make>
-      <apply>uv run manage.py migrate</apply>
-    </migrations>
-    <packages>
-      <install>uv add &lt;package&gt;</install>
-      <forbidden>pip install</forbidden>
-    </packages>
-    <management>
-      <pattern>Always use `uv run manage.py &lt;command&gt;`</pattern>
-    </management>
-  </commands>
-
-  <!-- API Rules and Standards -->
-  <api_standards>
-    <authentication>
-      <type>Token-based</type>
-      <role_hierarchy>
-        <role level="1">USER</role>
-        <role level="2">MODERATOR</role>
-        <role level="3">ADMIN</role>
-        <role level="4">SUPERUSER</role>
-      </role_hierarchy>
-    </authentication>
-    <filtering>
-      <rides>25+ parameters</rides>
-      <parks>15+ parameters</parks>
-    </filtering>
-    <responses>
-      <pagination>Standard DRF pagination</pagination>
-      <errors>Rich error responses with details</errors>
-    </responses>
-    <caching>
-      <levels>Multi-level (Redis, CDN, browser)</levels>
-      <invalidation>Signal-based invalidation</invalidation>
-    </caching>
-    <data_policy>
-      <rule>NEVER MOCK DATA - All responses must use real database queries</rule>
-    </data_policy>
-  </api_standards>
-
-  <!-- Rich Choice Objects System (MANDATORY) -->
-  <rich_choices>
-    <implementation>
-      <field_usage>RichChoiceField(choice_group="group_name", domain="domain_name")</field_usage>
-      <definition_location>domain-specific choices.py using RichChoice dataclass</definition_location>
-      <registration>register_choices() function in domain __init__.py</registration>
-    </implementation>
-    <required_metadata>
-      <metadata>color</metadata>
-      <metadata>icon</metadata>
-      <metadata>description</metadata>
-      <metadata>css_class</metadata>
-    </required_metadata>
-    <forbidden>
-      <rule>NO tuple-based choices allowed anywhere in codebase</rule>
-    </forbidden>
-  </rich_choices>
-
-  <!-- Frontend Constraints -->
-  <frontend_constraints>
-    <architecture>
-      <htmx>Dynamic updates</htmx>
-      <alpinejs>Client state management</alpinejs>
-      <tailwind>Styling framework</tailwind>
-    </architecture>
-    <approach>Progressive enhancement required</approach>
-    <browser_support>Latest 2 versions of major browsers</browser_support>
-    <performance_targets>
-      <fcp>First Contentful Paint &lt; 1.5s</fcp>
-      <tti>Time to Interactive &lt; 2s</tti>
-      <compliance>Core Web Vitals compliance</compliance>
-    </performance_targets>
-  </frontend_constraints>
-
-  <!-- Code Quality Standards -->
-  <code_standards>
-    <model_inheritance>All models must inherit from TrackedModel</model_inheritance>
-    <slug_management>Use SluggedModel for entities with slugs and history tracking</slug_management>
-    <choice_fields>Always use RichChoiceField instead of Django choices</choice_fields>
-    <api_urls>Must include trailing slashes and follow nested pattern</api_urls>
-    <media_fields>Use CloudflareImagesField for all image handling</media_fields>
-    <geographic_data>Use PostGIS fields and separate location models</geographic_data>
-  </code_standards>
-
-  <!-- Business Rules -->
-  <business_rules>
-    <company_roles>
-      <rule>Parks domain: Only OPERATOR and PROPERTY_OWNER roles</rule>
-      <rule>Rides domain: Only MANUFACTURER and DESIGNER roles</rule>
-      <rule>CRITICAL: Never allow cross-domain company roles</rule>
-    </company_roles>
-    <data_integrity>
-      <rule>All model changes must be tracked via pghistory</rule>
-      <rule>All API responses must use real database data</rule>
-      <rule>Geographic data must use PostGIS for accuracy</rule>
-    </data_integrity>
-  </business_rules>
-
-  <!-- Development Workflow -->
-  <workflow>
-    <package_management>Use uv for all Python package operations</package_management>
-    <server_management>Use runserver_plus for enhanced development server</server_management>
-    <database_management>Always use uv run for Django management commands</database_management>
-    <testing>All functionality must work with progressive enhancement</testing>
-  </workflow>
-
-  <!-- Context7 MCP Integration (MANDATORY) -->
-  <context7_usage>
-    <requirement>ALWAYS use Context7 MCP for documentation lookups before making changes</requirement>
-    <libraries_requiring_context7>
-      <library name="tailwindcss">Use for CSS utility classes, responsive design, and component styling</library>
-      <library name="django">Use for models, views, forms, URL patterns, and Django-specific patterns</library>
-      <library name="django-cotton">Use for component creation, template organization, and Cotton-specific syntax</library>
-      <library name="htmx">Use for dynamic updates, form handling, and AJAX interactions</library>
-      <library name="alpinejs">Use for client-side state management, reactive data, and JavaScript interactions</library>
-      <library name="django-rest-framework">Use for API design, serializers, viewsets, and DRF patterns</library>
-      <library name="postgresql">Use for database queries, PostGIS functions, and advanced SQL features</library>
-      <library name="postgis">Use for geographic data handling and spatial queries</library>
-      <library name="redis">Use for caching strategies, session management, and performance optimization</library>
-    </libraries_requiring_context7>
-    <workflow_steps>
-      <step order="1">Before editing/creating code: Query Context7 for relevant library documentation</step>
-      <step order="2">During debugging: Use Context7 to verify syntax, patterns, and best practices</step>
-      <step order="3">When implementing new features: Reference Context7 for current API and method signatures</step>
-      <step order="4">For performance issues: Consult Context7 for optimization techniques and patterns</step>
-      <step order="5">For geographic data handling: Use Context7 for PostGIS functions and best practices</step>
-      <step order="6">For caching strategies: Refer to Context7 for Redis patterns and best practices</step>
-      <step order="7">For database queries: Utilize Context7 for PostgreSQL best practices and advanced SQL features</step>
-    </workflow_steps>
-    <mandatory_scenarios>
-      <scenario>Creating new Django models or API endpoints</scenario>
-      <scenario>Implementing HTMX dynamic functionality</scenario>
-      <scenario>Writing AlpineJS reactive components</scenario>
-      <scenario>Designing responsive layouts with Tailwind CSS</scenario>
-      <scenario>Creating Django-Cotton components</scenario>
-      <scenario>Debugging CSS, JavaScript, or Django issues</scenario>
-      <scenario>Implementing caching or database optimizations</scenario>
-      <scenario>Handling geographic data with PostGIS</scenario>
-      <scenario>Utilizing Redis for session management</scenario>
-      <scenario>Implementing real-time features with WebSockets</scenario>
-    </mandatory_scenarios>
-    <context7_commands>
-      <resolve_library>Always call Context7:resolve-library-id first to get correct library ID</resolve_library>
-      <get_docs>Then use Context7:get-library-docs with appropriate topic parameter</get_docs>
-      <example_topics>
-        <topic library="tailwindcss">responsive design, flexbox, grid, animations</topic>
-        <topic library="django">models, views, forms, admin, signals</topic>
-        <topic library="django-cotton">components, templates, slots, props</topic>
-        <topic library="htmx">hx-get, hx-post, hx-swap, hx-trigger, hx-target</topic>
-        <topic library="alpinejs">x-data, x-show, x-if, x-for, x-model</topic>
-        <topic library="django-rest-framework">serializers, viewsets, routers, permissions</topic>
-        <topic library="postgresql">joins, indexes, transactions, window functions</topic>
-        <topic library="postgis">geospatial queries, distance calculations, spatial indexes</topic>
-        <topic library="redis">caching strategies, pub/sub, data structures</topic>
-      </example_topics>
-    </context7_commands>
-  </context7_usage>
-</thrillwiki_context>