chore: update project structure with contracts and services for CaddyManager, including configuration and Docker integration

.cursor/rules/blazor-development.mdc

@@ -0,0 +1,38 @@
+---
+alwaysApply: true
+---
+# Blazor Development Workflow and Environment
+
+## Development Environment
+- All running, debugging, and testing of the Blazor app should happen in Cursor ide
+- Code editing, AI suggestions, and refactoring will be done within Cursor AI
+- Recognize that Cursor ide is installed and should be used for compiling and launching the app
+
+## Blazor Code Style and Structure
+- Write idiomatic and efficient Blazor and C# code
+- Follow .NET and Blazor conventions
+- Use Razor Components appropriately for component-based UI development
+- Prefer inline functions for smaller components but separate complex logic into code-behind or service classes
+- Async/await should be used where applicable to ensure non-blocking UI operations
+
+## Blazor and .NET Specific Guidelines
+- Utilize Blazor's built-in features for component lifecycle (e.g., OnInitializedAsync, OnParametersSetAsync)
+- Use data binding effectively with @bind
+- Leverage Dependency Injection for services in Blazor
+- Structure Blazor components and services following Separation of Concerns
+- Use C# 10+ features like record types, pattern matching, and global usings
+- Logic code of the blazor component must be implemented in a separated .razor.cs code file.
+- Prefer using the Tailwind classes to the Style attribute
+
+## Performance Optimization
+- Use asynchronous methods (async/await) for API calls or UI actions that could block the main thread
+- Optimize Razor components by reducing unnecessary renders and using StateHasChanged() efficiently
+- Minimize the component render tree by avoiding re-renders unless necessary, using ShouldRender() where appropriate
+- Use EventCallbacks for handling user interactions efficiently, passing only minimal data when triggering events
+
+## Testing and Debugging
+- All unit testing and integration testing should be done in Cursor ide
+- Test Blazor components and services using xUnit
+- Use Moq for mocking dependencies during tests
+- Debug Blazor UI issues using browser developer tools and Cursor ide's debugging tools for backend and server-side issues
+- For performance profiling and optimization, rely on Cursor ide's diagnostics tools

.cursor/rules/coding-standards.mdc

@@ -0,0 +1,42 @@
+---
+alwaysApply: true
+---
+
+# Coding Standards and Naming Conventions
+
+## Naming Conventions
+- Follow PascalCase for component names, method names, and public members
+- Use camelCase for private fields and local variables
+- Prefix interface names with "I" (e.g., IUserService) and interfaces will be located at the relevant Contracts project.
+- Interface implementations, if not tighten to UI, will be located at the relevant Services project.
+
+## Error Handling and Validation
+- Implement proper error handling for Blazor pages and API calls
+- Use logging for error tracking in the backend and consider capturing UI-level errors in Blazor with tools like ErrorBoundary
+- Implement validation using FluentValidation or DataAnnotations in forms
+
+## Security and Authentication
+- Implement Authentication and Authorization in the Blazor app where necessary using ASP.NET Identity or JWT tokens for API authentication
+- Use HTTPS for all web communication and ensure proper CORS policies are implemented
+
+## API Design and Integration
+- Use HttpClient or other appropriate services to communicate with external APIs or your own backend
+- Implement error handling for API calls using try-catch and provide proper user feedback in the UI
+
+## API Documentation and Swagger
+- Use Swagger/OpenAPI for API documentation for your backend API services
+- Ensure XML documentation for models and API methods for enhancing Swagger documentation
+
+## Utils
+- For JSON processing and utils, we are using Newtonsoft exclusively
+
+## Using and imports
+- Must keep the using and import statements clean and lean, any unecessary statement must be removed.
+
+## Commit Conventions
+- Always follow git commit conventions
+
+## Implementation details
+- Interfaces and models live in the .Contracts projects
+- Implementations of services live in the .Service projects
+- UI code lives in the main app project

.cursor/rules/development-workflow.mdc

@@ -0,0 +1,22 @@
+---
+alwaysApply: true
+---
+# Development Workflow and Task Management
+
+## Procedure and Approach
+- You should do your tasks effectively and efficiently. Normally, you'd start your task by analyzing and planning and designing, using a md file with the suffix `_plan` created under the `.cursor/docs/` folder to keep track of the progress. You'd keep finishing your task by tracking the progress with that `_plan` file until your task is completely finished.
+- When the task is complex, you should break it into smaller tasks and do the subtasks one by one until all are done. The subtasks' progress can be kept track in the master `_plan` file.
+- Always remember to run tests, and check the coverage and add new tests whenever you add new implementation logic, services or when you modify the existing implementations and services
+- What you do, you'd have to do to the end, when the result matches the expectations. You must not stop in the middle
+
+## Testing Requirements
+- Always run tests after changing code that affects tests and after changing tests themselves
+- Check the launch.json file for secrets before committing. If secrets are found, replace them with 'SECRET', commit the changes, and restore the original secret values afterwards
+- Build warnings should also be taken care of.
+
+## Documentations
+- Knowledge base and documentations are and will be generated under the folder docs/
+- Only generate the documentations under that /docs folder on-demand, when it's requested by me
+- Tests code should have summary to explain the test cases
+- API and method should have relevant summary
+- Complex logic should have comments to explain better# Development Workflow and Task Management

.cursor/rules/git-configuration.mdc

@@ -0,0 +1,10 @@
+---
+alwaysApply: true
+---
+# Git Configuration and Preferences
+
+## Git Configuration
+- The user prefers that the assistant not add launch.json by default; they will add it only when needed
+
+## Commit and Security
+- Check the launch.json file for secrets before committing. If secrets are found, replace them with 'SECRET', commit the changes, and restore the original secret values afterwards

.cursor/rules/state-management.mdc

@@ -0,0 +1,14 @@
+---
+alwaysApply: true
+---
+# State Management and Caching Strategies
+
+## Caching Strategies
+- Implement in-memory caching for frequently used data, especially for Blazor Server apps. Use IMemoryCache for lightweight caching solutions
+- For Blazor, utilize EboloState (create the inheritance states where necessary) to cache application state between user sessions
+- Consider Distributed Cache strategies (like Redis or SQL Server Cache) for larger applications that need shared state across multiple users or clients
+- Cache API calls by storing responses to avoid redundant calls when data is unlikely to change, thus improving the user experience
+
+## State Management Libraries
+- For server-side Blazor, use Scoped Services and the StateContainer pattern to manage state within user sessions while minimizing re-renders
+