Replaces copilot instructions with granular files

Breaks down the monolithic copilot instructions file into smaller, more focused instruction sets based on file types.

This change improves maintainability and allows for more targeted guidance to the copilot during development.

Author: niemyjski

.github/copilot-instructions.md

@@ -1,204 +1,24 @@
 # Copilot Instructions
 
 This project features an **ASP.NET Core** backend (REST API) and a **Svelte 5 TypeScript** frontend (SPA).
-All contributions must respect existing formatting and conventions specified in the `.editorconfig` file.
-You are a distinguished engineer and are expected to deliver high-quality code that adheres to the guidelines below.
 
----
+## Instructions Organization
 
-## 1. General Coding Guidelines
+This project uses modular instruction files for better organization and targeted guidance. The instructions are organized as follows:
 
-- **Code Style & Minimal Diffs:**
-  - Match the file's existing style; use `.editorconfig` when unsure.
-  - Preserve extra spaces, comments, and minimize diffs.
-  - Always ask before creating new files, directories, or changing existing structures.
-  - Always look at existing usages before refactoring or changing code to prevent new code from breaking existing code.
-  - Assume any existing uncommitted code is correct and ask before changing it.
-  - Don't add code comments unless necessary. Code should be self-explanatory.
-  - Don't use deprecated or insecure libraries, algorithms or features.
+- **[General Guidelines](instructions/general.instructions.md)** - Core coding practices applied to all files
+- **[Frontend Guidelines](instructions/frontend.instructions.md)** - Svelte 5 TypeScript SPA specific guidelines
+- **[Backend Guidelines](instructions/backend.instructions.md)** - ASP.NET Core C# specific guidelines
+- **[Frontend Svelte](instructions/frontend-svelte.instructions.md)** - Svelte-specific component guidelines
+- **[Frontend TypeScript](instructions/frontend-typescript.instructions.md)** - TypeScript/JavaScript language-specific guidelines
+- **[Backend Testing](instructions/backend-testing.instructions.md)** - C# testing practices for backend tests
+- **[Frontend Testing](instructions/frontend-testing.instructions.md)** - TypeScript/JavaScript testing guidelines
+- **[Frontend Svelte Testing](instructions/frontend-svelte-testing.instructions.md)** - Svelte component testing guidelines
+- **[E2E Testing](instructions/e2e-testing.instructions.md)** - Playwright end-to-end testing guidelines
+- **[Project Structure](instructions/project-structure.instructions.md)** - Understanding the codebase organization
 
-- **Modern Code Practices:**
-  - Write complete, runnable code—no placeholders or TODOs.
-  - Use modern language features, clear naming conventions, and defensive coding when necessary.
-  - Follow SOLID, DRY, and clean code principles. Remove unused code.
+## Key Principles
 
-- **Behavior Management:**
-  - Flag any user-visible changes for review.
-  - Deliver exactly what’s requested—avoid adding unnecessary features unless explicitly instructed.
-
----
-
-## 2. Frontend Guidelines (Svelte 5 / TypeScript SPA)
-
-Located in the `src/Exceptionless.Web/ClientApp` directory.
-
-- **Framework & Best Practices:**
-  - Use Svelte 5 in SPA mode with TypeScript and Tailwind CSS.
-  - Follow modern ES6 best practices and the ESLint recommended configuration ([standardjs](https://standardjs.com)).
-  - Code can be formatted and linted with `npm run format` and checked for errors with `npm run check` tasks.
-  - Don't use namespace imports unless importing svelte-shadcn component or from a barrel export index file.
-  - Limit use of $effect as there is usually a better way to solve the problem like using $derived.
-  - All single-line control statements in JavaScript must be enclosed in curly braces to ensure unambiguous control flow, enhance readability, and prevent potential errors arising from unintended statement grouping.
-
-- **Architecture & Components:**
-  - Follow the Composite Component Pattern.
-  - Organize code into vertical slices (e.g., features aligned with API controllers) and maintain shared components in a central folder.
-  - Use **kebab-case** for filenames and directories (e.g., `components/event-overview.svelte`).
-  - Reexport generated code `src/Exceptionless.Web/ClientApp/src/lib/generated` from the respective feature models folder.
-    - Always look for models in generated code before creating new models.
-  - If a function returns a promise always await it.
-  - **Do NOT** use any server-side Svelte features.
-
-- **UI, Accessibility & Testing:**
-  - Ensure excellent keyboard navigation for all interactions.
-  - Build forms with shadcn-svelte forms & superforms, and validate with class-validator.
-    - Good examples are the manage account and login pages.
-  - Use formatters `src/Exceptionless.Web/ClientApp/src/lib/features/shared/components/formatters` for displaying built-in types (date, number, boolean, etc.).
-  - All dialogs should use shadcn-svelte dialog components.
-    - Good examples are the mark fixed and delete stack dialogs.
-  - Ensure semantic HTML, mobile-first design, and WCAG 2.2 Level AA compliance.
-  - Use shadcn-svelte components (based on [bits-ui](https://bits-ui.com/docs/llms.txt)).
-    - Look for new components in the shadcn-svelte documentation
-
-- **API Calls:**
-  - Use TanStack Query for all API calls centralized in an `api.svelte.ts` file.
-  - Leverage `@exceptionless/fetchclient` for network operations.
-
-- **Testing Tools:**
-  - Unit Testing: Vitest
-  - Component Testing: Testing Library
-  - E2E Testing: Playwright
-
-- **Reference documentation:**
-  - Always use Svelte 5 features: [https://svelte.dev/llms-full.txt](https://svelte.dev/llms-full.txt)
-    - on:click -> onclick
-    - import { page } from '$app/stores'; -> import { page } from '$app/state';
-
----
-
-## 3. Backend Guidelines (ASP.NET Core / C#)
-
-- **Framework & Best Practices:**
-  - Use the latest ASP.NET Core with C# and enable Nullable Reference Types.
-  - Code can be formatted with `dotnet format` and checked for errors with `dotnet build`.
-
-- **Conventions & Best Practices:**
-- Adhere to the `.editorconfig` file and Microsoft's [coding conventions](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions).
-- Follow Microsoft's [unit testing best practices](https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-best-practices).
-
-- **Architectural Considerations:**
-  - Design services with awareness of distributed computing challenges.
-
----
-
-## 4. Security Guidelines
-
-- **Best Practices:**
-  - Sanitize all user inputs and rigorously validate data.
-  - Follow OWASP guidelines and implement a robust Content Security Policy.
-  - Adopt Shift-Left security practices to identify vulnerabilities early.
-
----
-
-## 5. Developer Planning & Reflection
-
-- **Pre-Coding Reflection:**
-  1. Identify the problem or feature you’re solving.
-  2. Consider three possible approaches.
-  3. Choose the simplest approach that satisfies all requirements.
-  4. Clarify:
-     - Can the solution be modularized into smaller functions?
-     - Are there unnecessary abstractions?
-     - Will the implementation be clear to a junior developer?
-
-- **Post-Coding Reflection:**
-  1. Review for refactor opportunities—can clarity or maintainability be improved?
-  2. Identify potential edge cases or areas prone to bugs.
-  3. Verify robust error handling and validation mechanisms.
-
----
-
-## 6. Code Reviews
-
-- **Focus Areas:**
-  - Ensure adherence to complexity, consistency, and clean code standards.
-  - Validate robust error handling and defensive coding practices.
-  - Check for duplication and maintainable solutions.
-
----
-
-## 7. Debugging Guidelines
-
-1. **Reproduce** the issue with minimal steps and code.
-2. **Understand** the underlying problem thoroughly.
-3. **Form Hypotheses** about the cause.
-4. **Test & Verify** potential solutions.
-5. **Document** fixes and adjustments clearly for future reference.
-
----
-
-## 8. Project Structure
-
-```plaintext
-project-root/
-├── build                                           # Build files
-├── docker                                          # Docker files
-├── k8s                                             # Kubernetes files
-├── samples
-├── src
-│   ├── Exceptionless.AppHost                       # Aspire
-│   ├── Exceptionless.Core                          # Domain
-│   ├── Exceptionless.EmailTemplates                # Email Templates
-│   ├── Exceptionless.Insulation                    # Concrete Implementations
-│   ├── Exceptionless.Job                           # ASP.NET Core Jobs
-│   ├── Exceptionless.Web                           # ASP.NET Core Web Application
-│   │   ├── ClientApp                               # Frontend SvelteKit Spa Application
-│   │   │   ├── api-templates                       # API templates for generated code using OpenApi
-│   │   │   ├── e2e
-│   │   │   ├── src                                 # JavaScript SvelteKit application
-│   │   │   │   ├── lib
-│   │   │   │   │   ├── assets                      # Static assets
-│   │   │   │   │   ├── features                    # Vertical Sliced Features, each folder corresponds to an api controller
-│   │   │   │   │   │   ├── events                  # Event features (related to Events Controller)
-│   │   │   │   │   │   │   ├── components
-│   │   │   │   │   │   │   └── models
-│   │   │   │   │   │   ├── organizations
-│   │   │   │   │   │   ├── projects
-│   │   │   │   │   │   │   └── components
-│   │   │   │   │   │   ├── shared                  # Shared components used by all other features
-│   │   │   │   │   │   │   ├── api
-│   │   │   │   │   │   │   ├── components
-│   │   │   │   │   │   │   └── models
-│   │   │   │   │   │   ├── stacks
-│   │   │   │   │   │   │   └── components
-│   │   │   │   │   ├── generated                   # Generated code
-│   │   │   │   │   ├── hooks                       # Client hooks
-│   │   │   │   │   └── utils                       # Utility functions
-│   │   │   │   └── routes                          # Application routes
-│   │   │   │       ├── (app)
-│   │   │   │       │   ├── account
-│   │   │   │       │   └── stream
-│   │   │   │       ├── (auth)
-│   │   │   │       │   ├── login
-│   │   │   │       │   └── logout
-│   │   │   │       └── status
-│   │   │   └── static                              # Static assets
-│   │   ├── ClientApp.angular                       # Legacy Angular Client Application (Ignore)
-│   │   ├── Controllers                             # ASP.NET Core Web API Controllers
-│   └── tests                                       # ASP.NET Core Unit and Integration Tests
-```
-
----
-
-### Additional Considerations
-
-- **Expanding the Guidelines:**
-  As the project evolves, consider including sample code snippets, decision flowcharts, or ASCII diagrams to clarify more complex guidelines.
-
-- **Continuous Improvement:**
-  Regularly review and update these guidelines to stay aligned with evolving best practices and emerging technologies.
-
-- **Thoughtful Contribution:**
-  Always strive to deliver code that not only functions well but also advances the overall maintainability and quality of the project.
+All contributions must respect existing formatting and conventions specified in the `.editorconfig` file. You are a distinguished engineer and are expected to deliver high-quality code that adheres to the guidelines in the instruction files.
 
 Let's keep pushing for clarity, usability, and excellence—both in code and user experience.

.github/instructions/backend-testing.instructions.md

@@ -0,0 +1,38 @@
+---
+description: "C# backend testing guidelines"
+applyTo: "tests/**/*.cs"
+---
+
+# Backend Testing Guidelines (C#)
+
+## Framework & Best Practices
+
+- Follow Microsoft's [unit testing best practices](https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-best-practices).
+- Use xUnit as the primary testing framework.
+
+## Test Principles
+
+- **Fast & Isolated**: Tests should execute quickly and not depend on external factors or the order of execution.
+- **Repeatable & Self-Checking**: Tests must be consistent and validate their own outcomes without manual checks.
+- **Timely**: Write tests alongside your code to ensure relevance and improve design.
+
+## Test Structure & Naming
+
+- Write complete, runnable tests—no placeholders or TODOs.
+- Use clear, descriptive naming conventions for test methods:
+  - `MethodName_StateUnderTest_ExpectedBehavior`
+  - `Should_ExpectedBehavior_When_StateUnderTest`
+- Follow AAA pattern (Arrange, Act, Assert).
+
+## Test Organization
+
+- Use `[Theory]` and `[InlineData]` for parameterized tests.
+- Implement proper setup and teardown using constructors and `IDisposable`.
+
+## Integration Testing
+
+- Use the custom `AppWebHostFactory`, which inherits from `WebApplicationFactory<Startup>`, for integration tests. This factory manages the Aspire distributed application lifecycle.
+- Inject `ITestOutputHelper` and `AppWebHostFactory` into the test class constructor to get access to the test output and the application factory.
+- Isolate dependencies using test containers, in-memory providers, or stubs to ensure reliable test execution.
+- Test the full request/response cycle, including model validation and HTTP status codes.
+- Verify data persistence and side effects by inspecting the state of the database or other services after the test runs.

.github/instructions/backend.instructions.md

@@ -0,0 +1,20 @@
+---
+description: "ASP.NET Core backend guidelines"
+applyTo: "**/*.cs"
+---
+
+# Backend Guidelines (ASP.NET Core / C#)
+
+## Framework & Best Practices
+
+- Use the latest ASP.NET Core with C# and enable Nullable Reference Types.
+- Code can be formatted with `dotnet format` and checked for errors with `dotnet build`.
+
+## Conventions & Best Practices
+
+- Adhere to the `.editorconfig` file and Microsoft's [coding conventions](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions).
+- Follow Microsoft's [unit testing best practices](https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-best-practices).
+
+## Architectural Considerations
+
+- Design services with awareness of distributed computing challenges.

.github/instructions/e2e-testing.instructions.md

@@ -0,0 +1,41 @@
+---
+description: "E2E testing guidelines for Playwright tests"
+applyTo: "src/Exceptionless.Web/ClientApp/e2e/**/*.{test,spec}.{ts,js}"
+---
+
+# E2E Testing Guidelines (Playwright)
+
+## Test Structure & Organization
+
+- Use Page Object Model pattern for reusable page interactions.
+- Group tests by feature or user workflow in separate files.
+- Use descriptive test names that explain the user scenario.
+- Keep tests focused on end-to-end user journeys.
+
+## Playwright Best Practices
+
+- Use `page.locator()` with semantic selectors (roles, labels, text).
+- Prefer `data-testid` attributes over CSS selectors when semantic options aren't available.
+- Use `page.waitForLoadState()` and `expect().toBeVisible()` for reliable timing.
+- Implement proper error handling and meaningful assertions.
+
+## Test Data Management
+
+- Use test fixtures for consistent test data setup.
+- Clean up test data after each test run.
+- Use unique identifiers to avoid test interference.
+- Consider using database snapshots for complex scenarios.
+
+## Cross-Browser & Responsive Testing
+
+- Configure tests to run across Chrome, Firefox, and Safari.
+- Test responsive breakpoints and mobile interactions.
+- Verify touch gestures and mobile-specific behaviors.
+- Include accessibility testing with axe-playwright.
+
+## Visual & Performance Testing
+
+- Use `page.screenshot()` for visual regression testing.
+- Implement performance assertions for critical user paths.
+- Monitor Core Web Vitals metrics during testing.
+- Test offline scenarios and network conditions where applicable.

.github/instructions/frontend-svelte-testing.instructions.md

@@ -0,0 +1,33 @@
+---
+description: "Frontend: Svelte component testing specific guidelines"
+applyTo: "src/Exceptionless.Web/ClientApp/**/*.{test,spec}.{ts,js}"
+---
+
+# Svelte Component Testing Guidelines
+
+## Testing Library Integration
+
+- Use `@testing-library/svelte` for component testing.
+- Import `render`, `screen`, and `fireEvent` from the testing library.
+- Use `cleanup` to ensure components are properly unmounted between tests.
+
+## Svelte-Specific Testing Patterns
+
+- Test component props and their effects on rendering.
+- Test event dispatching using `createEventDispatcher`.\
+- Test component slots and their content projection.
+- Validate two-way binding behavior with form inputs.
+
+## State Management Testing
+
+- Test component state changes through user interactions.
+- Verify `$state` and `$derived` reactive variables update correctly.
+- Test component lifecycle hooks if they affect behavior.
+- Mock store values and test component reactions to store changes.
+
+## Accessibility Testing
+
+- Ensure proper ARIA attributes are present and correct.
+- Test keyboard navigation and focus management.
+- Verify screen reader compatibility with semantic HTML.
+- Test color contrast and visual accessibility requirements.

.github/instructions/frontend-svelte.instructions.md

@@ -0,0 +1,40 @@
+---
+description: "Frontend: Svelte specific guidelines"
+applyTo: "src/Exceptionless.Web/ClientApp/**/*.svelte"
+---
+
+# Svelte Component Guidelines
+
+## Component Structure
+
+- Use Svelte 5 syntax and features consistently
+- Prefer `$state` and `$derived` over `$effect` when possible
+- Always use `onclick` instead of `on:click`
+- Use `import { page } from '$app/state'` instead of `'$app/stores'`
+- Use snippets `{#snippet ...}` and `{@render ...}` instead of `<slot>` for content projection.
+
+## Event Handling
+
+- All single-line control statements must be enclosed in curly braces
+- Use proper event handling patterns with Svelte 5 syntax
+
+## Component Organization
+
+- Follow kebab-case naming for component files
+- Use the Composite Component Pattern
+- Organize components within vertical slices aligned with API controllers
+
+## Accessibility
+
+- Ensure excellent keyboard navigation for all interactions
+- Use semantic HTML elements
+- Maintain WCAG 2.2 Level AA compliance
+- Implement mobile-first design principles
+
+## Reference Documentation
+
+- Always use Svelte 5 features: [https://svelte.dev/llms-full.txt](https://svelte.dev/llms-full.txt)
+  - on:click -> onclick
+  - import { page } from '$app/stores'; -> import { page } from '$app/state'
+  - <slot> -> {#snippet ...}
+  - beforeUpdate/afterUpdate -> $effect.pre