Cline rules

1---
2description: ColorAgent rules for writing backend code
3author: Sean Bellows
4version: 0.0.1
5globs: *.py
6tags: ["backend", "api", "coding-guidelines"]
7---
8 
9You are an expert in Python and writing scalable API applications using FastAPI, SQLAlchemy, and Pydantic.
10 
11## Key Principles
12 
13  - Write clear, technical responses with precise FastAPI examples.
14  - Use descriptive variable and function names; adhere to naming conventions (e.g., lowercase with underscores for functions and variables).
15 
16# Python
17 
18  - Async-first development
19  - Use Pydantic for Type safety along with its BaseModel with support for Python's dataclasses for simple, shared models between python projects
20  - Dependency injection
21  - Follow SOLID principles
22  - Use middleware judiciously to handle cross-cutting concerns like authentication, logging, and caching.
23 
24## Error Handling and Validation
25 
26  - Prefer try-except blocks for handling exceptions in business logic.
27  - Create custom error responses (e.g., 404, 500) where those errors are in the domain of the application.
28  - Apply Open Telemetry style logging to errors.
29 
30## Dependencies
31 
32  - Python v3.13+
33  - Pydantic
34  - Redis (for caching and task queues)
35  - Celery (for background tasks)
36  - PostgreSQL (preferred databases for production)
37 
38## Performance Optimization
39 
40  - Optimize query performance using related object fetching.
41  - Use Redis or Memcached to reduce database load.
42  - Implement database indexing and query optimization techniques for better performance.
43  - Use asynchronous views and background tasks (via Celery) for I/O-bound or long-running operations.
44 
45## Logging
46 
47  - As a general rule, we should have logs for every expected and unexpected actions of the application, using the appropriate log level.
48  - Python exceptions should almost always be captured automatically without extra instrumentation, but custom ones (such as failed requests to external services, query errors, or Celery task failures) can be tracked using capture_exception().
49 
50## Log Levels
51 
52  - A log level or log severity is a piece of information telling how important a given log message is:
53    - DEBUG: should be used for information that may be needed for diagnosing issues and troubleshooting or when running application in the test environment for the purpose of making sure everything is running correctly
54    - INFO: should be used as standard log level, indicating that something happened
55    - WARN: should be used when something unexpected happened but the code can continue the work
56    - ERROR: should be used when the application hits an issue preventing one or more functionalities from properly functioning
57 
58## Logging Format
59 
60  - Use Structlog as the default logging library. It's a structured logging framework that adds cohesive metadata on each logs that makes it easier to track events or incidents.
61  - Structured logging means that you don’t write hard-to-parse and hard-to-keep-consistent prose in your logs but that you log events that happen in a context instead.
62 
63  (example)
64 
65```python
66  import structlog
67  logger = structlog.get_logger(__name__)
68  logger.debug("event_sent_to_kafka", event_uuid=str(event_uuid), kafka_topic=topic)
69```
70 
71  will produce:
72 
73```sh
74  2021-10-28T13:46:40.099007Z [debug] event_sent_to_kafka [posthog.api.capture] event_uuid=017cc727-1662-0000-630c-d35f6a29bae3 kafka_topic=default
75  As you can see above, the log contains all the information needed to understand the app behaviour.
76```
77 
78## Security
79 
80  - Don’t log sensitive information. Make sure you never log:
81    - authorization tokens
82    - passwords
83    - PII (Personal Identifiable Information)
84 
85## Testing
86 
87  - After adding or updating tests, make sure they pass, by running them with pytest.
88  - When rerunning previously failed tests, specify the specific tests to re-run.
89  - All new packages and most new significant functionality should come with unit tests
90  - Significant features should come with integration and/or end-to-end tests
91  - Analytics-related queries should be covered by snapshot tests for ease of reviewing
92  - Always consider if you can simplify a test by using the `parameterized.expand` decorator
93 
94## Unit Tests
95  - A good unit test should:
96    - focus on a single use-case at a time
97    - have a minimal set of assertions per test
98    - demonstrate every use case. The rule of thumb is: if it can happen, it should be covered
99 
100## Integration Tests
101 
102  - Integration tests should ensure that the feature works end-to-end. They must cover all the important use cases of the feature.
103  
104## Running Commands
105 
106- Use `uv sync` instead of `pip install -r ...`, and `uv add PACKAGE` instead of `pip install PACKAGE`. If there is an import error, first activate the venv at `.venv/`.
107