-
Notifications
You must be signed in to change notification settings - Fork 16
Expand file tree
/
Copy path.windsurfrules
More file actions
33 lines (32 loc) · 3.25 KB
/
.windsurfrules
File metadata and controls
33 lines (32 loc) · 3.25 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
- After making changes, ALWAYS make sure to start up a new server so I can test it. Using available opentr.sh file in the repo, using appropriate options for the change required (restart, reset, etc)
- Always look for existing code to iterate on instead of creating new code.
- Do not drastically change the patterns before trying to iterate on existing patterns.
- Always kill all existing related servers that may have been created in previous testing before trying to start a new server.
- Always prefer simple solutions
- Avoid duplication of code whenever possible, which means checking for other areas of the codebase that might already have similar code and functionality
- Write code that takes into account the different environments: dev, test, and prod
- You are careful to only make changes that are requested or you are confident are well understood and related to the change being requested
- When fixing an issue or bug, do not introduce a new pattern or technology without first exhausting all options for the existing implementation. And if you finally do this, make sure to remove the old implementation afterwards so we don't have duplicate logic.
- Keep the codebase very clean and organized
- Avoid writing scripts in files if possible, especially if the script is likely only to be run once
- Avoid having files over 200-300 lines of code. Refactor at that point.
- Mocking data is only needed for tests, never mock data for dev or prod
- Never add stubbing or fake data patterns to code that affects the dev or prod environments
- Never overwrite my .env file without first asking and confirming
- Focus on the areas of code relevant to the task
- Do not touch code that is unrelated to the task
- Write thorough tests for all major functionality
- Avoid making major changes to the patterns and architecture of how a feature works, after it has shown to work well, unless explicitly instructed
- Always think about what other methods and areas of code might be affected by code changes
- Always use 'docker compose' command instead of docker-compose
- Always setup the docker files to ensure that the layers are cached and the most changed files are last in the docker file
- Always check for typing erros. Typescript is NOT required.
- document python code properly with Google style Docstring formating
- Setup all imports at the top of the python files
- when running docker containrs, always open each contianer logs to ensure they are working properly. If errors in the containers then reveiw and correct them and restart as required.
- review the code base to ensure it is clean and organized, removing empty files, folders, and files that are no longer used.
- Ensure documentation is up to date and accurate
- Continually update the Readme with any new changes or updates, ensuring easy understanding of the codebase, setup and deployment.
- When looking through database structures, orms, and pydantic models. look in the coed base first, then fix the database. Always look in code base for errors first.
- Database schema changes MUST use Alembic migrations in backend/alembic/versions/. Update the migration, SQLAlchemy ORM models, and Pydantic schemas together. The Alembic migration chain is the sole schema authority.
- any frontend modifications must be light and dark mode compliant.