mirror of
https://github.com/pacnpal/thrillwiki_django_no_react.git
synced 2025-12-20 06:31:09 -05:00
e62646bcf9
- Centralize API endpoints in dedicated api app with v1 versioning - Remove individual API modules from parks and rides apps - Add event tracking system with analytics functionality - Integrate Vue.js frontend with Tailwind CSS v4 and TypeScript - Add comprehensive database migrations for event tracking - Implement user authentication and social provider setup - Add API schema documentation and serializers - Configure development environment with shared scripts - Update project structure for monorepo with frontend/backend separation
79 lines
4.3 KiB
Plaintext
79 lines
4.3 KiB
Plaintext
# 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. |