thrillwiki_django_no_react/.clinerules

# Project Startup Rules

## Development Server
IMPORTANT: Always follow these instructions exactly when starting the development server:

FIRST, assume the server is running. Always. Assume the changes have taken effect.

IF THERE IS AN ISSUE WITH THE SERVER, run the following command exactly:
```bash
lsof -ti :8000 | xargs kill -9; find . -type d -name "__pycache__" -exec rm -r {} +; cd backend && uv run manage.py runserver_plus && cd ../frontend && pnpm run dev

Note: These steps must be executed in this exact order to ensure consistent behavior. If server does not start correctly, fix the error in accordance with the error details as best you can.

## Package Management
IMPORTANT: When a Python package is needed, only use UV to add it:
```bash
uv add <package>
```
Do not attempt to install packages using any other method.

## Django Management Commands
IMPORTANT: When running any Django manage.py commands (migrations, shell, etc.), always use UV:
```bash
uv run manage.py <command>
```
This applies to all management commands including but not limited to:
- Making migrations: `uv run manage.py makemigrations`
- Applying migrations: `uv run manage.py migrate`
- Creating superuser: `uv run manage.py createsuperuser` and possible echo commands before for the necessary data input.
- Starting shell: `uv run manage.py shell` and possible echo commands before for the necessary data input.

NEVER use `python manage.py` or `uv run python manage.py`. Always use `uv run manage.py` directly.

## Entity Relationship Rules
IMPORTANT: Follow these entity relationship patterns consistently:

# Park Relationships
- Parks MUST have an Operator (required relationship)
- Parks MAY have a PropertyOwner (optional, usually same as Operator)
- Parks CANNOT directly reference Company entities

# Ride Relationships
- Rides MUST belong to a Park (required relationship)
- Rides MAY have a Manufacturer (optional relationship)
- Rides MAY have a Designer (optional relationship)
- Rides CANNOT directly reference Company entities

# Entity Definitions
- Operators: Companies that operate theme parks (replaces Company.owner)
- PropertyOwners: Companies that own park property (new concept, optional)
- Manufacturers: Companies that manufacture rides (replaces Company for rides)
- Designers: Companies/individuals that design rides (existing concept)
- IMPORTANT: All entities can have locations. 

# Relationship Constraints
- Operator and PropertyOwner are usually the same entity but CAN be different
- Manufacturers and Designers are distinct concepts and should not be conflated
- All entity relationships should use proper foreign keys with appropriate null/blank settings

- You are to NEVER assume that blank output means your fixes were correct. That assumption can lead to further issues down the line.
- ALWAYS verify your changes by testing the affected functionality thoroughly.
- ALWAYS use context7 to check documentation when troubleshooting. It contains VITAL documentation for any and all frameworks, modules, and packages.
- ALWAYS document your code changes with conport and the reasoning behind them.
- ALWAYS include relevant context and information when making changes to the codebase.
- ALWAYS ensure that your code changes are properly tested and validated before deployment.
- ALWAYS communicate clearly and effectively with your team about any changes you make.
- ALWAYS be open to feedback and willing to make adjustments as necessary.
- ALWAYS strive for continuous improvement in your work and processes.
- ALWAYS prioritize code readability and maintainability.
- ALWAYS keep security best practices in mind when developing and reviewing code.
- ALWAYS consider performance implications when making changes to the codebase.
- ALWAYS be mindful of the impact of your changes on the overall system architecture.
- ALWAYS keep scalability in mind when designing new features or modifying existing ones.
- ALWAYS consider the potential for code reuse and modularity in your designs.
- ALWAYS document your code with clear and concise comments.
- ALWAYS keep your code DRY (Don't Repeat Yourself) by abstracting common functionality into reusable components.
- ALWAYS use meaningful variable and function names to improve code readability.
- ALWAYS handle errors and exceptions gracefully to improve the user experience.
- ALWAYS log important events and errors for troubleshooting purposes.
- ALWAYS consider if there may be an existing module or package that can be leveraged before creating new functionality from scratch.
- ALWAYS keep documentation up to date with any code changes.
- ALWAYS consider if there are any potential security vulnerabilities in your code.
- ALWAYS consider if there are any potential performance bottlenecks in your code.