|
1 | | -# Agent Guidelines for the Exceptionless Repository |
| 1 | +# Exceptionless |
2 | 2 |
|
3 | | -You are an expert engineer working on Exceptionless, a production-grade real-time error monitoring platform handling billions of requests. Your changes must maintain backward compatibility, performance, and reliability. Approach each task methodically: research existing patterns, make surgical changes, and validate thoroughly. |
4 | | - |
5 | | -**Craftsmanship Mindset**: Every line of code should be intentional, readable, and maintainable. Write code you'd be proud to have reviewed by senior engineers. Prefer simplicity over cleverness. When in doubt, favor explicitness and clarity. |
| 3 | +Real-time error monitoring platform handling billions of requests (ASP.NET Core 10 + Svelte 5). Act as a distinguished engineer focusing on readability, performance while maintaining backwards compatibility. |
6 | 4 |
|
7 | 5 | ## Quick Start |
8 | 6 |
|
9 | | -Run `Exceptionless.AppHost` from your IDE. Aspire automatically starts all required services (Elasticsearch, Redis) with proper ordering. The Aspire dashboard opens at the assigned localhost port, resources and logs can be accessed via the Aspire MCP. |
10 | | - |
11 | | -## Skills Reference |
12 | | - |
13 | | -Load skills on-demand for detailed patterns and guidelines. When working in a domain, read the corresponding SKILL.md file from `.github/skills/<skill-name>/`. |
14 | | - |
15 | | -### Backend Skills |
16 | | - |
17 | | -- **dotnet-conventions** — C# naming, formatting, async patterns, nullable |
18 | | -- **backend-architecture** — Project layering, repositories, controllers, Aspire |
19 | | -- **dotnet-cli** — Build, test, and format commands |
20 | | -- **backend-testing** — xUnit patterns, AppWebHostFactory, integration tests |
21 | | -- **foundatio** — Caching, queues, message bus, jobs, resilience |
22 | | - |
23 | | -### Frontend Skills |
24 | | - |
25 | | -- **svelte-components** — Svelte 5, runes, $state, $derived, $effect, snippets |
26 | | -- **tanstack-form** — TanStack Form, Zod validation, error handling |
27 | | -- **tanstack-query** — Data fetching, caching, mutations, WebSocket invalidation |
28 | | -- **shadcn-svelte** — UI components, trigger patterns, dialogs |
29 | | -- **typescript-conventions** — Naming, imports, type safety |
30 | | -- **frontend-architecture** — Route groups, feature slices, lib structure |
31 | | -- **storybook** — Component stories, defineMeta, visual testing |
32 | | - |
33 | | -### Testing Skills |
34 | | - |
35 | | -- **frontend-testing** — Vitest, Testing Library, component tests |
36 | | -- **e2e-testing** — Playwright, Page Object Model, accessibility audits |
37 | | - |
38 | | -### Cross-Cutting Skills |
39 | | - |
40 | | -- **security-principles** — Secrets, encryption, secure defaults, OWASP |
41 | | -- **accessibility** — WCAG 2.2 AA, ARIA, keyboard navigation |
42 | | - |
43 | | -## Build System |
44 | | - |
45 | | -### Prerequisites |
46 | | - |
47 | | -- **.NET SDK 10.0** |
48 | | -- **Node 24+** |
49 | | -- **npm** — use the committed `package-lock.json` |
50 | | - |
51 | | -### Backend Build |
52 | | - |
53 | | -```bash |
54 | | -dotnet restore |
55 | | -dotnet build |
56 | | -``` |
57 | | - |
58 | | -### Frontend Build |
59 | | - |
60 | | -```bash |
61 | | -cd src/Exceptionless.Web/ClientApp |
62 | | -npm ci |
63 | | -npm run build |
64 | | -``` |
| 7 | +Run `Exceptionless.AppHost` from your IDE. Aspire starts all services (Elasticsearch, Redis) automatically. |
65 | 8 |
|
66 | | -## Testing |
| 9 | +## Build & Test |
67 | 10 |
|
68 | | -- **Backend:** `dotnet test` |
69 | | -- **Frontend Unit:** `npm run test:unit` |
70 | | -- **Frontend E2E:** `npm run test:e2e` |
| 11 | +| Task | Command | |
| 12 | +| -------------- | --------------------------------------------------------------- | |
| 13 | +| Backend build | `dotnet build` | |
| 14 | +| Backend test | `dotnet test` | |
| 15 | +| Frontend build | `cd src/Exceptionless.Web/ClientApp && npm ci && npm run build` | |
| 16 | +| Frontend test | `npm run test:unit` | |
| 17 | +| E2E test | `npm run test:e2e` | |
71 | 18 |
|
72 | 19 | ## Project Structure |
73 | 20 |
|
74 | 21 | ```text |
75 | | -src |
76 | | -├── Exceptionless.AppHost # Aspire orchestrator (start here for full stack) |
77 | | -├── Exceptionless.Core # Domain logic and services |
78 | | -├── Exceptionless.Insulation # Concrete implementations (Elasticsearch, Redis, etc.) |
79 | | -├── Exceptionless.Web # ASP.NET Core API + SPA host |
80 | | -│ └── ClientApp # Svelte 5 SPA (primary client) |
81 | | -│ └── ClientApp.angular # Angular SPA (legacy client) |
| 22 | +src/ |
| 23 | +├── Exceptionless.AppHost # Aspire orchestrator (start here) |
| 24 | +├── Exceptionless.Core # Domain logic |
| 25 | +├── Exceptionless.Insulation # Infrastructure (Elasticsearch, Redis, Azure) |
| 26 | +├── Exceptionless.Web # API + Svelte SPA (ClientApp/) |
82 | 27 | └── Exceptionless.Job # Background workers |
83 | | -tests # C# integration/unit tests + HTTP samples |
84 | | -docker # Compose files for local services |
85 | | -build # Scripts and templates |
| 28 | +tests/ # C# tests + HTTP samples |
86 | 29 | ``` |
87 | 30 |
|
88 | | -## Making Changes |
89 | | - |
90 | | -### Before Starting |
91 | | - |
92 | | -1. **Gather context**: Read related files, search for similar implementations |
93 | | -2. **Research patterns**: Find existing usages using grep/semantic search |
94 | | -3. **Understand completely**: Know the problem, side effects, and edge cases |
95 | | -4. **Plan the approach**: Choose the simplest solution that satisfies requirements |
96 | | -5. **Check dependencies**: Verify how changes affect dependent code |
97 | | - |
98 | | -### Pre-Implementation Analysis |
99 | | - |
100 | | -Before writing code, think critically: |
101 | | - |
102 | | -1. **What could go wrong?** Race conditions, null references, edge cases |
103 | | -2. **What are the failure modes?** Network failures, timeouts, concurrent access |
104 | | -3. **What assumptions am I making?** Validate against the codebase |
105 | | -4. **Is this the root cause?** Don't fix symptoms—trace to the core problem |
106 | | -5. **Is there existing code that does this?** Search before creating new utilities |
107 | | - |
108 | | -### Single Responsibility Principle |
109 | | - |
110 | | -- Each class/component has **one reason to change** |
111 | | -- Methods do one thing well; extract when doing multiple things |
112 | | -- Keep files focused: one primary type per file |
113 | | -- Separate concerns: don't mix I/O, business logic, and presentation |
114 | | -- If a method needs a comment explaining what it does, it should probably be extracted |
115 | | - |
116 | | -### Test-First Development |
117 | | - |
118 | | -**Always write or extend tests before implementing changes:** |
119 | | - |
120 | | -1. **Find existing tests first**: Search for tests covering the code you're modifying |
121 | | -2. **Extend existing tests**: Add test cases to existing test classes when possible |
122 | | -3. **Write failing tests**: Demonstrate the bug or missing feature |
123 | | -4. **Implement the fix**: Write minimal code to make tests pass |
124 | | -5. **Refactor**: Clean up while keeping tests green |
125 | | - |
126 | | -### Validation |
127 | | - |
128 | | -Before marking work complete: |
129 | | - |
130 | | -1. **Builds successfully**: Both backend and frontend compile without errors |
131 | | -2. **All tests pass**: No test failures in affected areas |
132 | | -3. **No new warnings**: Check build output for compiler/linter warnings |
133 | | -4. **API compatibility**: Breaking changes are intentional and flagged |
134 | | - |
135 | | -## Testing Philosophy |
136 | | - |
137 | | -Tests are **executable documentation** and **design tools**: |
138 | | - |
139 | | -- **Fast & Isolated**: No external dependencies or execution order |
140 | | -- **Repeatable & Self-checking**: Consistent results, validate outcomes |
141 | | -- **Timely**: Write tests alongside code |
142 | | - |
143 | | -### Test Layers |
144 | | - |
145 | | -1. **Unit tests**: Fast, isolated, test single units of logic |
146 | | -2. **Integration tests**: Component interactions with real dependencies |
147 | | -3. **E2E tests**: Complete user workflows through the UI |
| 31 | +## Skills |
148 | 32 |
|
149 | | -## Dependencies |
| 33 | +Load from `.github/skills/<name>/SKILL.md` when working in that domain: |
150 | 34 |
|
151 | | -- **NuGet:** Feeds in `NuGet.Config`; do not add sources unless requested |
152 | | -- **SDK:** Shared settings in `src/Directory.Build.props` |
153 | | -- **npm:** Keep `package-lock.json` in sync; use `npm ci` |
154 | | -- **Secrets:** Never commit secrets; use environment variables |
| 35 | +| Domain | Skills | |
| 36 | +| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | |
| 37 | +| Backend | dotnet-conventions, backend-architecture, dotnet-cli, backend-testing, foundatio | |
| 38 | +| Frontend | svelte-components, tanstack-form, tanstack-query, shadcn-svelte, typescript-conventions, frontend-architecture, storybook, accessibility | |
| 39 | +| Testing | frontend-testing, e2e-testing | |
| 40 | +| Cross-cutting | security-principles | |
155 | 41 |
|
156 | | -## Resources |
| 42 | +## Constraints |
157 | 43 |
|
158 | | -- Use context7 MCP for library API docs and code generation |
159 | | -- Load skills for detailed patterns (see Skills Reference above) |
160 | | -- Check existing patterns in the codebase before introducing new ones |
| 44 | +- Use `npm ci` (not `npm install`) |
| 45 | +- Never commit secrets — use environment variables |
| 46 | +- NuGet feeds are in `NuGet.Config` — don't add sources |
0 commit comments