enhancing clarity in research assessment and problem description sections.

some files rename

.cursor/rules/architectural-rules.mdc

@@ -0,0 +1,10 @@
+---
+description: Coding and component architecture rules
+alwaysApply: false
+---
+ - Follow SOLID principles
+ - Follow KISS principle.
+ - Follow principle: Dumb code - smart data.
+ - Follow DRY principles, but do not overcomplicate things, if small or even medium code duplication (sometimes even 2 times) would make solution easier - go for it. 
+  Deduplicate code concepts if it is clear reusing pattern and semantically can be easily distinguish in reusable component
+ - Follow conventions and rules of the project's programming language

.cursor/rules/coding-rules.mdc

@@ -0,0 +1,22 @@
+---
+description: Coding
+alwaysApply: false
+---
+# Coding rules
+
+- Always prefer simple solution
+- Generate concise code
+- Do not put comments in the code
+- Do not put logs unless it is an exception, or was asked specifically
+- Do not put code annotations unless it was asked specifically
+- Your changes should be well correlated with what was requested. In case of any uncertainties ask questions.
+- Mocking data is needed only for tests
+- When you add new libraries or dependencies make sure you are using the same version of it as other parts of the code
+
+- Focus on the areas of code relevant to the task
+- Do not touch code that is unrelated to the task
+- Always think about what other methods and areas of code might be affected by the code changes
+- When you think you are done with changes, run tests and make sure they are not broken
+- Do not rename any databases or tables or table columns without confirmation. Avoid such renaming if possible.
+- Do not create diagrams unless I ask explicitly
+- Do not commit binaries, create and keep .gitignore up to date and delete binaries after you are done with the task

.cursor/rules/sonar-rules.mdc

@@ -0,0 +1,18 @@
+---
+description: Coding
+alwaysApply: false
+---
+- Use collection expressions for collection initialization
+- Non-derived "private" classes and records should be "sealed"
+- In tests Use 'Assert.ThrowsExactly' instead of 'Assert.ThrowsException'
+- Parameter names should match base declaration and other partial definitions
+- Exceptions should be either logged or rethrown but not both
+- Exceptions should not be thrown from property getters
+- A Route attribute should be added to the controller when a route template is specified at the action level
+- "Thread.Sleep" should not be used in tests
+- Maintain consistent whitespace formatting with blank lines between logical code blocks
+- Cognitive Complexity of methods should not be too high
+- Avoid constant arrays as arguments
+- Server-side requests should not be vulnerable to traversing attacks
+- String literals should not be duplicated
+- Value type property used as input in a controller action should be nullable, required or annotated with the JsonRequiredAttribute to avoid under-posting