Cline rules for Django

# Cline and Roo rules

Project rules for Cline and Roo Code in this Django repository.
Use the project's commands. Do not invent a package manager, and do not run destructive shell commands.

## Tool use

- Read the files you will change before editing them.
- Prefer a focused patch over rewriting a whole file.
- Run the test command from this file after a behavior change, or say why you could not.
- Do not delete generated folders, lockfiles, or migrations unless the task says so.

## Stack

This repository is a Django project. Models, views, and templates follow the apps that already exist. Schema changes go through migrations, and you do not skip migrations.

## Layout

- Each app owns its models, views, urls, and templates.
- Project settings stay in the settings package. Do not hard-code secrets in an app module.
- Business rules that are not HTTP belong on the model or a service function, not in the template.

## Commands

- Dev server: `python manage.py runserver`
- Migrations: `python manage.py makemigrations && python manage.py migrate`
- Tests: `python manage.py test`
- Check: `python manage.py check`

Use the script the repo already defines when it differs from the command above.

## Conventions

- Use the ORM. Raw SQL needs a reason the ORM cannot express.
- A model change ships with its migration. Do not skip migrations or edit an applied migration to dodge a mistake.
- Query in the view or a model method, not in the template.
- Use `select_related` and `prefetch_related` when a template or serializer walks relations.
- CSRF protection stays on for browser forms. Do not disable it globally.
- Settings read from the environment the way the project already does.

## Testing

Add or update tests when behavior changes.

Use Django's test client or pytest-django, matching the repo. Cover the view status and one model constraint.

## Style

- Optimize for the next reader over the shortest diff.
- Comment only when the why is non-obvious.
- Name things the way neighboring files already do.
- Do not reformat code you did not change.

## Errors

- Fail at the boundary. Do not swallow errors.
- Use Django's validation and a 4xx response for bad input. Let unexpected exceptions hit the configured logging.

## Scope

- Do the requested task. Do not refactor unrelated code.
- Match the rigor already in the repo. Fix what you touch.
- Ask one clarifying question only when the task cannot be finished without it. Otherwise state the assumption and continue.

## Avoid

- Do not import models at module scope in `AppConfig.ready` carelessly, and do not create import cycles between apps.
- Do not call `objects.get` without handling `DoesNotExist` when the row might be missing.
- Do not store money or other exact values in a binary float.
- Do not run new queries in a loop when one prefetch will do.

## Done when

- The requested behavior works.
- `python manage.py check` is clean and the migration list matches the model change you made.
- The diff stays inside the task.
- You list anything you could not run.