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