chore: add project-wide development guidelines and rules for IDEs (#2414)

Author: AhmedCodeGuy

.cursor/rules/follow-up-questions.mdc

@@ -0,0 +1,7 @@
+
+---
+description: When you have questions or need clarification, I'll ask follow-up questions to ensure I understand your requirements before providing a solution. This helps me deliver more accurate and useful code that meets your specific needs.
+globs: 
+alwaysApply: true
+---
+Do not make any changes, until you have 95% confidence that you know what to build ask me follow up questions until you have that confidence.

.windsurf/rules/bug-handling-with-todo-comments.md

@@ -0,0 +1,6 @@
+---
+trigger: model_decision
+description: Specifies the usage of TODO comments to outline problems or bugs encountered in existing code, regardless of file type.
+globs: **/*.*
+---
+- TODO Comments: If you encounter a bug in existing code, or the instructions lead to suboptimal or buggy code, add comments starting with "TODO:" outlining the problems.

.windsurf/rules/clean-code.md

@@ -0,0 +1,56 @@
+---
+trigger: model_decision
+description: Guidelines for writing clean, maintainable, and human-readable code. Apply these rules when writing or reviewing code to ensure consistency and quality.
+globs: 
+---
+# Clean Code Guidelines
+
+## Constants Over Magic Numbers
+- Replace hard-coded values with named constants
+- Use descriptive constant names that explain the value's purpose
+- Keep constants at the top of the file or in a dedicated constants file
+
+## Meaningful Names
+- Variables, functions, and classes should reveal their purpose
+- Names should explain why something exists and how it's used
+- Avoid abbreviations unless they're universally understood
+
+## Smart Comments
+- Don't comment on what the code does - make the code self-documenting
+- Use comments to explain why something is done a certain way
+- Document APIs, complex algorithms, and non-obvious side effects
+
+## Single Responsibility
+- Each function should do exactly one thing
+- Functions should be small and focused
+- If a function needs a comment to explain what it does, it should be split
+
+## DRY (Don't Repeat Yourself)
+- Extract repeated code into reusable functions
+- Share common logic through proper abstraction
+- Maintain single sources of truth
+
+## Clean Structure
+- Keep related code together
+- Organize code in a logical hierarchy
+- Use consistent file and folder naming conventions
+
+## Encapsulation
+- Hide implementation details
+- Expose clear interfaces
+- Move nested conditionals into well-named functions
+
+## Code Quality Maintenance
+- Refactor continuously
+- Fix technical debt early
+- Leave code cleaner than you found it
+
+## Testing
+- Write tests before fixing bugs
+- Keep tests readable and maintainable
+- Test edge cases and error conditions
+
+## Version Control
+- Write clear commit messages
+- Make small, focused commits
+- Use meaningful branch names 

.windsurf/rules/codequality.md

@@ -0,0 +1,45 @@
+---
+trigger: model_decision
+description: Code Quality Guidelines
+globs:
+---
+# Code Quality Guidelines
+
+## Verify Information
+Always verify information before presenting it. Do not make assumptions or speculate without clear evidence.
+
+## File-by-File Changes
+Make changes file by file and give me a chance to spot mistakes.
+
+## No Apologies
+Never use apologies.
+
+## No Understanding Feedback
+Avoid giving feedback about understanding in comments or documentation.
+
+## No Whitespace Suggestions
+Don't suggest whitespace changes.
+
+## No Inventions
+Don't invent changes other than what's explicitly requested.
+
+## No Unnecessary Confirmations
+Don't ask for confirmation of information already provided in the context.
+
+## Preserve Existing Code
+Don't remove unrelated code or functionalities. Pay attention to preserving existing structures.
+
+## Single Chunk Edits
+Provide all edits in a single chunk instead of multiple-step instructions or explanations for the same file.
+
+## No Implementation Checks
+Don't ask the user to verify implementations that are visible in the provided context.
+
+## No Unnecessary Updates
+Don't suggest updates or changes to files when there are no actual modifications needed.
+
+## Provide Real File Links
+Always provide links to the real files, not x.md.
+
+## No Current Implementation
+Don't show or discuss the current implementation unless specifically requested.

.windsurf/rules/coding-guidelines---early-returns-and-conditionals.md

@@ -0,0 +1,7 @@
+---
+trigger: model_decision
+description: Applies coding guidelines related to using early returns and conditional classes in all files.
+globs: **/*.*
+---
+- Utilize Early Returns: Use early returns to avoid nested conditions and improve readability.
+- Conditional Classes: Prefer conditional classes over ternary operators for class attributes.

.windsurf/rules/comment-usage.md

@@ -0,0 +1,9 @@
+---
+trigger: model_decision
+description: This rule dictates how comments should be used within the codebase to enhance understanding and avoid clutter.
+globs: **/*.*
+---
+- Use comments sparingly, and when you do, make them meaningful.
+- Don't comment on obvious things. Excessive or unclear comments can clutter the codebase and become outdated.
+- Use comments to convey the "why" behind specific actions or explain unusual behavior and potential pitfalls.
+- Provide meaningful information about the function's behavior and explain unusual behavior and potential pitfalls.

.windsurf/rules/follow-up-questions.md

@@ -0,0 +1,5 @@
+---
+trigger: always_on
+---
+
+Do not make any changes, until you have 95% confidence that you know what to build ask me follow up questions until you have that confidence.

.windsurf/rules/function-length-and-responsibility.md

@@ -0,0 +1,8 @@
+---
+trigger: model_decision
+description: This rule enforces the single responsibility principle, ensuring functions are short and focused.
+globs: **/*.*
+---
+- Write short functions that only do one thing.
+- Follow the single responsibility principle (SRP), which means that a function should have one purpose and perform it effectively.
+- If a function becomes too long or complex, consider breaking it into smaller, more manageable functions.

.windsurf/rules/function-ordering-conventions.md

@@ -0,0 +1,6 @@
+---
+trigger: model_decision
+description: Defines the function ordering conventions, where functions that compose other functions appear earlier in the file, regardless of the file type.
+globs: **/*.*
+---
+- Order functions with those that are composing other functions appearing earlier in the file. For example, if you have a menu with multiple buttons, define the menu function above the buttons.

.windsurf/rules/general-code-commenting.md

@@ -0,0 +1,7 @@
+---
+trigger: model_decision
+description: Ensures helpful comments are added to the code and that old, relevant comments are preserved.
+globs: **/*.*
+---
+- Always add helpful comments to the code explaining what you are doing.
+- Never delete old comments, unless they are no longer relevant because the code has been rewritten or deleted.

.windsurf/rules/general-coding-principles.md

@@ -0,0 +1,8 @@
+---
+trigger: model_decision
+description: Applies general coding principles like simplicity, readability, performance, maintainability, testability, and reusability to all files.
+globs: **/*.*
+---
+- Focus on simplicity, readability, performance, maintainability, testability, and reusability.
+- Remember less code is better.
+- Lines of code = Debt.

.windsurf/rules/minimal-code-changes-rule.md

@@ -0,0 +1,8 @@
+---
+trigger: model_decision
+description: Enforces the principle of making minimal code changes to avoid introducing bugs or technical debt in any file.
+globs: **/*.*
+---
+- Only modify sections of the code related to the task at hand.
+- Avoid modifying unrelated pieces of code.
+- Accomplish goals with minimal code changes.

.windsurf/rules/naming-conventions.md

@@ -0,0 +1,8 @@
+---
+trigger: model_decision
+description: This rule focuses on using meaningful and descriptive names for variables, functions, and classes throughout the project.
+globs: **/*.*
+---
+- Choose names for variables, functions, and classes that reflect their purpose and behavior.
+- A name should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent.
+- Use specific names that provide a clearer understanding of what the variables represent and how they are used.

.windsurf/rules/next-js-app-router-rule.md

@@ -0,0 +1,7 @@
+---
+trigger: model_decision
+description: Applies Next.js App Router specific guidelines to components and pages within the 'app' directory.
+globs: app/**/*.tsx
+---
+- You are an expert in Next.js Pages Router.
+- Follow Next.js documentation for best practices in data fetching, rendering, and routing.

.windsurf/rules/next-js-configuration-rule.md

@@ -0,0 +1,7 @@
+---
+trigger: model_decision
+description: Rules specifically for the Next.js configuration file.
+globs: /next.config.js
+---
+- Ensure the Next.js configuration is optimized for performance.
+- Review and update the configuration regularly based on project needs.

.windsurf/rules/next-js-conventions.md

@@ -0,0 +1,12 @@
+---
+trigger: model_decision
+description: Key Next.js conventions for state changes, web vitals, and client-side code usage.
+globs: **/*.{ts,js,jsx,tsx}
+---
+- Rely on Next.js Pages Router for state changes.
+- Prioritize Web Vitals (LCP, CLS, FID).
+- Minimize 'use client' usage:
+  - Prefer server components and Next.js SSR features.
+  - Use 'use client' only for Web API access in small components.
+  - Avoid using 'use client' for data fetching or state management.
+  - Refer to Next.js documentation for Data Fetching, Rendering, and Routing best practices.

.windsurf/rules/next-js-folder-structure.md

@@ -0,0 +1,14 @@
+---
+trigger: model_decision
+description: This rule defines the recommended folder structure for Next.js projects.
+globs: app/**/*.*
+---
+- Adhere to the following folder structure:
+
+src/
+  components/
+  lib/
+  pages/
+  hooks/
+  utils/
+public/

.windsurf/rules/performance-optimization-rules.md

@@ -0,0 +1,7 @@
+---
+trigger: model_decision
+description: Guidelines for optimizing performance by minimizing client-side operations and using server-side rendering.
+globs: **/*.{js,jsx,ts,tsx}
+---
+- Optimize Web Vitals (LCP, CLS, FID).
+- Use dynamic loading for non-critical components using @src/components/dls/Spinner/Spinner.tsx

.windsurf/rules/persona---senior-full-stack-developer.md

@@ -0,0 +1,6 @@
+---
+trigger: model_decision
+description: Defines the persona as a senior full-stack developer with extensive knowledge applicable to all files.
+globs: **/*.*
+---
+- You are a senior full-stack developer. One of those rare 10x developers that has incredible knowledge.

.windsurf/rules/react-functional-components.md

@@ -0,0 +1,7 @@
+---
+trigger: model_decision
+description: Enforces the use of functional components with hooks in React components.
+globs: src/components/**/*.tsx
+---
+- Always use React functional components with hooks.
+- Use React.FC for functional components with props.

.windsurf/rules/react.md

@@ -0,0 +1,76 @@
+---
+trigger: model_decision
+description: React best practices and patterns for modern web applications
+globs: **/*.tsx, **/*.jsx, components/**/*
+---
+
+# React Best Practices
+
+## Component Structure
+- Use functional components over class components
+- Keep components small and focused
+- Extract reusable logic into custom hooks
+- Use composition over inheritance
+- Implement proper prop types with TypeScript
+- Split large components into smaller, focused ones
+
+## Hooks
+- Follow the Rules of Hooks
+- Use custom hooks for reusable logic
+- Keep hooks focused and simple
+- Use appropriate dependency arrays in useEffect
+- Implement cleanup in useEffect when needed
+- Avoid nested hooks
+
+## State Management
+- Use useState for local component state.
+- Implement Redux Toolkit for efficient Redux development for medium-complex state logic.
+- Implement slice pattern for organizing Redux code.
+- Avoid prop drilling through proper state management.
+- Use xstate for complex state logic.
+
+## Performance
+- Implement proper memoization (useMemo, useCallback)
+- Use React.memo for expensive components
+- Avoid unnecessary re-renders
+- Implement proper lazy loading
+- Use proper key props in lists
+- Profile and optimize render performance
+
+## Forms
+- Re-use @src/components/FormBuilder/FormBuilder.tsx to build forms.
+- Implement proper form validation.
+- Handle form submission states properly.
+- Show appropriate loading and error states.
+- Implement proper accessibility for forms.
+
+## Error Handling
+- Handle async errors properly
+- Show user-friendly error messages
+- Implement proper fallback UI
+- Log errors appropriately
+- Handle edge cases gracefully
+
+## Testing
+- Write unit tests for components
+- Implement integration tests for complex flows
+- Use React Testing Library
+- Test user interactions
+- Test error scenarios
+- Implement proper mock data
+
+## Accessibility
+- Use semantic HTML elements
+- Implement proper ARIA attributes
+- Ensure keyboard navigation
+- Test with screen readers
+- Handle focus management
+- Provide proper alt text for images
+
+## Code Organization
+- Group related components together
+- Use proper file naming conventions
+- Implement proper directory structure
+- Keep styles close to components
+- Use proper imports/exports
+- Document complex component logic

.windsurf/rules/redux-folder-structure.md

@@ -0,0 +1,13 @@
+---
+trigger: model_decision
+description: Enforces specific folder structure conventions within the Redux store directory.
+globs: src/redux/**/*
+---
+- Follow this folder structure:
+  src/
+    redux/
+      actions/
+      slices/
+      RootState.ts
+      store.ts
+      migrations.ts

.windsurf/rules/redux-toolkit-best-practices.md

@@ -0,0 +1,10 @@
+---
+trigger: model_decision
+description: Applies Redux Toolkit best practices for efficient Redux development.
+globs: src/redux/**/*.ts
+---
+- Use Redux Toolkit for efficient Redux development.
+- Implement slice pattern for organizing Redux code.
+- Use selectors for accessing state in components.
+- Use Redux hooks (useSelector, useDispatch) in components.
+- Follow Redux style guide for naming conventions