## Project

**Chat Agent WebApp**

A personal AI chat web application built with Blazor WebAssembly and MudBlazor. Users send messages through a ChatGPT-style interface and receive responses from a backend service. The project is an incremental learning journey — each phase introduces one concept at a time, making it suitable for a C# developer experienced in backend work but new to web application frameworks.

**Core Value:** A working chat interface where every line of code is intentional and explained, so the builder learns Blazor patterns while shipping a real product.

**Current Phase:** Echo — the backend returns "success msg!" for every user message. No external API integration yet.

### Constraints

- **Tech stack**: C# / Blazor WebAssembly — non-negotiable
- **Hosting model**: Blazor WASM (standalone) with separate ASP.NET Core Web API backend
- **UI library**: MudBlazor
- **Code style**: Simple, well-documented. Every Blazor concept introduced must have inline comments explaining what it does, why it's done that way, and what idiomatic alternatives exist

## Technology Stack

| Technology | Version | Purpose |
|------------|---------|---------|
| .NET SDK | 9.0.x | Runtime and tooling |
| Blazor WebAssembly Standalone | .NET 9 | Client SPA running in-browser |
| ASP.NET Core Web API | .NET 9 | Backend proxy (for future external API calls) |
| MudBlazor | latest | Material Design component library |
| System.Text.Json | built-in | JSON serialization |

## Architecture

See [ARCHITECTURE.md](ARCHITECTURE.md) for detailed hosting model discussion, API design decisions, and project structure rationale.

**Summary:**
- Three-project solution: Client (WASM), Api (backend proxy), Shared (models)
- Components update locally — no API needed for UI rendering
- The Api project exists for future use when external services require server-side secrets
- For the current echo phase, only the Client project is actively used

## Conventions

- Inline comments on every new Blazor concept: what it does, why, and idiomatic alternatives
- Emphasize framework idiom and explain choices — written for a C# developer new to web/Blazor
- Keep code simple; avoid abstractions until they are clearly needed
- One concept per phase — do not introduce multiple new patterns at once