.cursorrules

** general **
- always be concise, direct and don't try to appease me.
- DOUBLE CHECK THAT YOUR CHANGES ARE REALLY NEEDED. ALWAYS STICK TO THE GIVEN GOAL, NOT MORE.
- I repeat: don't optimize, don't refactor if not needed.
- Adhere to the rules, fix linting & test issues that are newly introduced.
- the `issueID` is usually specified in the current branch in the format `IDE-XXXX`.
- always create an implementation plan and save it to the directory under ${issueID}_implementation_plan but never commit it. take it as a reference for each step and how to proceed. Get confirmation that the plan is ok.
- Maintain existing code patterns and conventions 

** how to implement **
- don't comment what is done, instead comment why something is done if the code is not clear
- always write and update test cases. iterate until they pass.
- please check the makefile - make lint runs the linter, other targets might be relevant as well.
- use existing mocks, don't write new ones.
- if you use mocks, use gomock to generate them.
- always run the tests after editing.
- always use the linter
- don't change code that does not need to be changed. only do the minimum changes.
- this is not a library. if files are not used or needed anymore, delete them instead of deprecating them.
- if a tool call fails, analyze why it failed and correct your approach. don't prompt the user for help.
- if you don't know something, read the code instead of assuming it.
- commenting out code to fix errors is not a solution. instead, fix the error.

** security **
- determine the absolute path of the project directory. you can do that e.g. by executing pwd on the shell within the directory.
- always use snyk for sca and code scanning. scan with both tools. you need to pass the absolute path of the directory we are scanning.
- run snyk code tests after each edit. pass the absolute path of the project directory as a parameter
- run snyk sca tests after updating go.mod and pass the absolute path of the project directory as a parameter.
- run snyk sca and code test before committing. if not test data, fix issues before committing.

** fixing issues **
- fix security issues if they are fixable. take the snyk scan results and the test results as input
- don't fix test data

** committing **
- when asked to commit, always use conventional commit messages (Conventional Commit Style (Subject + Body)). be descriptive in the body. if you find a JIRA issue (IDE-XXXX) in the branch name, use it as a postfix to the subject line in the format [IDE-XXXX]
- consider all commits in the current branch when committing, to have the context of the current changes.
when asked to push, always use 'git push --set-upstream origin $(git_current_branch)' with git_current_branch being the current branch we are on
- never force push
- never push without asking
- never commit the hashicorp gomod
- regularly fetch main branch and offer to merge it into git_current_branch
- after pushing offer to create a PR on github. analyze the changes by comparing the current branch ($(git_current_branch)) with origin/main, and craft a PR description and title.
use the github pr template in this repository