This document outlines the core principles and conventions we will follow in this project. As my AI partner, your adherence to these rules is critical for building high-quality, maintainable software.
-
Modularity is Key: No single file should exceed 500 lines. If it grows too large, your first step is to propose a refactoring plan to break it into smaller, logical modules.
-
Consistent Organization: We group files by feature. For example, a new
userfeature would have its logic insrc/users/, its API routes insrc/api/routes/users.py, and its tests intests/users/. -
Clean Imports: Use absolute imports for clarity (e.g.,
from src.utils import helpers). Avoid circular dependencies. -
Environment First: All sensitive keys, API endpoints, or configuration variables must be managed through a
.envfile and loaded usingpython-dotenv. Never hardcode them.
-
Test Everything That Matters: Every new function, class, or API endpoint must be accompanied by unit tests in the tests/ directory.
-
The Test Triad: For each feature, provide at least three tests:
-
A "happy path" test for expected behavior.
-
An "edge case" test for unusual but valid inputs.
-
A "failure case" test for expected errors or invalid inputs.
-
-
Docstrings are Non-Negotiable: Every function must have a Google-style docstring explaining its purpose, arguments (
Args:), and return value (Returns:).
-
Follow the Standards: All Python code must be formatted with
blackand adhere toPEP8guidelines. -
Type Safety: Use type hints for all function signatures and variables. We use
mypyto enforce this. -
Data Certainty: Use
pydanticfor all data validation, especially for API request and response models. This is our single source of truth for data shapes.
-
Clarify, Don't Assume: If a requirement is ambiguous or context is missing, your first action is to ask for clarification.
-
No Hallucinations: Do not invent libraries, functions, or file paths. If you need a tool you don't have, state what you need and why.
-
Plan Before You Code: For any non-trivial task, first outline your implementation plan in a list or with pseudocode. We will approve it before you write the final code.
-
Explain the "Why": For complex or non-obvious blocks of code, add a
# WHY:comment explaining the reasoning behind the implementation choice.