feat: add basic chat interface with MudBlazor and propose responses API integration

Install MudBlazor 9.2.0, replace Bootstrap layout with MudLayout/MudAppBar,
create Chat.razor with message list, text input, auto-scroll, and hardcoded
responses. Add ChatMessage shared model. Remove template pages (Counter,
Weather), move health check to /health. Include OpenSpec change artifacts
for the upcoming wire-responses-api work.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

openspec/changes/archive/2026-04-04-basic-chat-interface/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-03

openspec/changes/archive/2026-04-04-basic-chat-interface/design.md

@@ -0,0 +1,48 @@
+## Context
+
+The project has a working Blazor WASM client and ASP.NET Core API with health check connectivity proven. The client currently uses Bootstrap for layout and has template pages (Counter, Weather). No UI component library is installed. This change introduces MudBlazor and builds the first real feature — a chat interface with hardcoded responses.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Install and configure MudBlazor as the UI component library
+- Build a ChatGPT/Gemini-inspired chat interface
+- Establish the message model and UI patterns that future phases will build on
+- Keep hardcoded responses so the UI is testable without API wiring
+
+**Non-Goals:**
+- OpenAI API integration (future phase)
+- Markdown rendering of messages (future phase — Markdig)
+- Conversation persistence or history (future phase)
+- Multiple conversations / sidebar navigation (future phase)
+- Responsive mobile layout optimization
+
+## Decisions
+
+### Decision 1: MudBlazor component choices
+
+**Chat message list**: Use `MudPaper` cards inside a scrollable `div` (or `MudStack`). Each message gets a `MudPaper` with `Elevation="0"` and a background color to distinguish user vs assistant.
+
+**Input area**: `MudTextField` with `Variant="Outlined"` and an `Adornment` send button (icon). This gives a single-line input with integrated send — similar to ChatGPT.
+
+**Layout**: `MudLayout` + `MudAppBar` + `MudMainContent`. No drawer/sidebar yet — that comes when we add conversation management.
+
+**Alternative considered**: Building with raw HTML/CSS. Rejected because MudBlazor is in the tech stack spec and provides the component patterns needed for later phases (dialogs, drawers, lists).
+
+### Decision 2: ChatMessage model location
+
+Place `ChatMessage.cs` in `ChatAgent.Shared` so it's available to both Client and API when API integration comes. Fields: `Role` (string: "user" or "assistant"), `Content` (string), `Timestamp` (DateTime).
+
+### Decision 3: Chat page structure
+
+The Chat.razor component owns the message list (`List<ChatMessage>`) and handles input. No separate service layer yet — the hardcoded response is inline in the component. When AI integration comes, a service will be extracted.
+
+### Decision 4: Template page cleanup
+
+Remove Counter.razor and Weather.razor. Move Home.razor from `/` to `/health` so the health check is still accessible but the chat page takes the root route.
+
+## Risks / Trade-offs
+
+- [MudBlazor WASM bundle size] → Acceptable for a personal tool; AOT is deferred per stack spec
+- [No service abstraction for responses] → Intentional; extracting too early adds complexity before the pattern is clear. Will refactor when adding API integration.
+- [Removing template pages] → Low risk; they were scaffolding. Health check preserved at `/health`.

openspec/changes/archive/2026-04-04-basic-chat-interface/proposal.md

@@ -0,0 +1,35 @@
+## Why
+
+The project exists to be a working AI chat interface, but there is no chat UI yet — only a health check page. This change builds the foundational chat experience using MudBlazor components, with hardcoded responses so the UI can be developed and tested independently of the OpenAI API integration.
+
+## What Changes
+
+- Install and configure MudBlazor in the Client project (NuGet, CSS/JS, providers, imports)
+- Replace the Bootstrap navbar/layout with a MudBlazor layout (MudLayout, MudAppBar, MudMainContent)
+- Create a Chat page with a message list and text input, styled after ChatGPT/Gemini
+- Add a shared `ChatMessage` model (role + content + timestamp)
+- Wire the input to append user messages and reply with a hardcoded bot response
+- Remove template pages (Counter, Weather) that are no longer needed
+
+## Capabilities
+
+### New Capabilities
+- `chat-ui`: The chat interface — message display, input handling, auto-scroll, and layout
+- `mudblazor-setup`: MudBlazor installation, theming, and provider configuration
+
+### Modified Capabilities
+<!-- None -->
+
+## Impact
+
+- `src/ChatAgent.Client/ChatAgent.Client.csproj`: Add MudBlazor package
+- `src/ChatAgent.Client/wwwroot/index.html`: Add MudBlazor CSS/JS/font links
+- `src/ChatAgent.Client/_Imports.razor`: Add MudBlazor using
+- `src/ChatAgent.Client/Program.cs`: Add MudBlazor services
+- `src/ChatAgent.Client/Layout/MainLayout.razor`: Replace with MudBlazor layout
+- `src/ChatAgent.Client/Layout/NavMenu.razor`: Replace or remove Bootstrap nav
+- `src/ChatAgent.Client/Pages/Chat.razor`: New chat page (becomes default route)
+- `src/ChatAgent.Client/Pages/Home.razor`: Demote from `/` route or keep as `/health`
+- `src/ChatAgent.Shared/Models/ChatMessage.cs`: New shared message model
+- `src/ChatAgent.Client/Pages/Counter.razor`: Remove
+- `src/ChatAgent.Client/Pages/Weather.razor`: Remove

openspec/changes/archive/2026-04-04-basic-chat-interface/specs/chat-ui/spec.md

@@ -0,0 +1,66 @@
+## ADDED Requirements
+
+### Requirement: Message display
+
+The chat page SHALL display messages in a vertically scrolling list, with each message showing the sender role (user or assistant), the message content, and a visual distinction between user and assistant messages (e.g., alignment, color, or avatar).
+
+#### Scenario: User message displayed
+
+- **WHEN** the user sends a message
+- **THEN** the message appears in the message list aligned or styled to indicate it is from the user
+
+#### Scenario: Assistant message displayed
+
+- **WHEN** the assistant responds
+- **THEN** the response appears in the message list with distinct styling from user messages (different alignment, color, or avatar)
+
+#### Scenario: Message ordering
+
+- **WHEN** multiple messages exist in the conversation
+- **THEN** messages are displayed in chronological order, oldest at top
+
+### Requirement: Message input
+
+The chat page SHALL provide a text input area at the bottom of the page where the user can type and submit messages.
+
+#### Scenario: Submit via button
+
+- **WHEN** the user types text and clicks the send button
+- **THEN** the message is added to the conversation and the input is cleared
+
+#### Scenario: Submit via Enter key
+
+- **WHEN** the user types text and presses Enter
+- **THEN** the message is submitted (same as clicking send)
+
+#### Scenario: Empty input blocked
+
+- **WHEN** the user attempts to send an empty or whitespace-only message
+- **THEN** nothing is sent and no message is added
+
+### Requirement: Hardcoded response
+
+In this phase, the assistant SHALL reply with a hardcoded message to every user input. This stubs the AI integration point for future phases.
+
+#### Scenario: Bot replies to any input
+
+- **WHEN** the user sends any message
+- **THEN** the assistant replies with a hardcoded response (e.g., "This is a placeholder response. AI integration coming soon!")
+
+### Requirement: Auto-scroll
+
+The message list SHALL automatically scroll to the newest message when a new message is added.
+
+#### Scenario: New message scrolls into view
+
+- **WHEN** a new message (user or assistant) is added to the conversation
+- **THEN** the message list scrolls to the bottom so the new message is visible
+
+### Requirement: Chat page is default route
+
+The chat page SHALL be the default route (`/`) of the application.
+
+#### Scenario: App opens to chat
+
+- **WHEN** the user navigates to the root URL
+- **THEN** the chat page is displayed

openspec/changes/archive/2026-04-04-basic-chat-interface/specs/mudblazor-setup/spec.md

@@ -0,0 +1,46 @@
+## ADDED Requirements
+
+### Requirement: MudBlazor package installed
+
+The Client project SHALL have MudBlazor 9.2.0 installed as a NuGet dependency.
+
+#### Scenario: Package reference present
+
+- **WHEN** the Client project is built
+- **THEN** MudBlazor 9.2.0 is resolved as a dependency
+
+### Requirement: MudBlazor services registered
+
+MudBlazor services SHALL be registered in the Client's DI container via `AddMudServices()`.
+
+#### Scenario: Services available
+
+- **WHEN** the application starts
+- **THEN** MudBlazor services (snackbar, dialog, etc.) are available for injection
+
+### Requirement: MudBlazor assets loaded
+
+The Client's `index.html` SHALL include MudBlazor CSS, JS, and font references.
+
+#### Scenario: Styles and scripts present
+
+- **WHEN** the application loads in the browser
+- **THEN** MudBlazor CSS (`_content/MudBlazor/MudBlazor.min.css`), JS (`_content/MudBlazor/MudBlazor.min.js`), and Material Design Icons font are loaded
+
+### Requirement: MudBlazor layout providers
+
+The app root SHALL include `MudThemeProvider`, `MudPopoverProvider`, and `MudDialogProvider` so MudBlazor components function correctly.
+
+#### Scenario: Providers present
+
+- **WHEN** any MudBlazor component is rendered
+- **THEN** it functions correctly because the required providers are in the component tree
+
+### Requirement: MudBlazor layout replaces Bootstrap
+
+The application layout SHALL use MudBlazor layout components (`MudLayout`, `MudAppBar`, `MudMainContent`) instead of the current Bootstrap navbar.
+
+#### Scenario: Layout renders with MudBlazor
+
+- **WHEN** any page is displayed
+- **THEN** the page is wrapped in a MudBlazor layout with an app bar showing the application name

openspec/changes/archive/2026-04-04-basic-chat-interface/tasks.md

@@ -0,0 +1,38 @@
+## 1. MudBlazor Setup
+
+- [x] 1.1 Install MudBlazor 9.2.0 NuGet package in ChatAgent.Client
+- [x] 1.2 Add MudBlazor CSS, JS, and Material Design Icons font to index.html (remove Bootstrap CSS)
+- [x] 1.3 Add `@using MudBlazor` to _Imports.razor
+- [x] 1.4 Register MudBlazor services (`AddMudServices()`) in Program.cs
+- [x] 1.5 Add MudThemeProvider, MudPopoverProvider, MudDialogProvider to MainLayout.razor
+
+## 2. Layout Migration
+
+- [x] 2.1 Replace MainLayout.razor with MudBlazor layout (MudLayout, MudAppBar, MudMainContent)
+- [x] 2.2 Remove NavMenu.razor (Bootstrap navbar no longer needed)
+- [x] 2.3 Remove MainLayout.razor.css (MudBlazor handles styling)
+
+## 3. Shared Model
+
+- [x] 3.1 Create ChatMessage.cs in ChatAgent.Shared/Models with Role, Content, Timestamp
+
+## 4. Chat Page
+
+- [x] 4.1 Create Chat.razor at route `/` with message list and input area
+- [x] 4.2 Implement message display with MudPaper cards (distinct styling for user vs assistant)
+- [x] 4.3 Implement text input with MudTextField and send button adornment
+- [x] 4.4 Wire Enter key and send button to submit handler
+- [x] 4.5 Block empty/whitespace-only submissions
+- [x] 4.6 Add hardcoded assistant response after each user message
+- [x] 4.7 Implement auto-scroll to bottom on new messages
+
+## 5. Cleanup
+
+- [x] 5.1 Move Home.razor route from `/` to `/health`
+- [x] 5.2 Remove Counter.razor and Weather.razor
+- [x] 5.3 Update app.css — remove Bootstrap-specific styles, keep custom styles that still apply
+
+## 6. Verify
+
+- [x] 6.1 Run `dotnet build` on the solution to confirm no errors
+- [ ] 6.2 Manually verify: chat page loads at `/`, messages display correctly, hardcoded response works

openspec/changes/wire-responses-api/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-04

openspec/changes/wire-responses-api/design.md

@@ -0,0 +1,66 @@
+## Context
+
+The chat UI has a hardcoded response stub. A local OpenAI-compatible proxy at `localhost:8317` serves the Responses API (`POST /v1/responses`) with Claude models. The existing architecture has a WASM client calling the API backend — we add a new endpoint that proxies to the Responses API and streams tokens back.
+
+The Responses API streaming format uses SSE with events like `response.output_text.delta` carrying a `delta` field with text fragments.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Wire real AI responses through the existing client → backend → proxy chain
+- Stream tokens to the UI for responsive feel
+- Keep the proxy URL and model configurable (server-side only)
+- Show a thinking indicator while waiting for first token
+
+**Non-Goals:**
+- Conversation history / multi-turn context (future phase)
+- Model selection UI (future phase)
+- Retry logic or rate limiting
+- Markdown rendering of responses (future phase — Markdig)
+
+## Decisions
+
+### Decision 1: Backend proxies the Responses API
+
+The WASM client cannot call `localhost:8317` directly (different origin, and we keep external service URLs server-side). The API backend gets a new `ChatController` that:
+1. Receives messages from the client
+2. Forwards them to `POST /v1/responses` with `"stream": true`
+3. Reads the SSE stream, extracts `response.output_text.delta` events
+4. Re-emits the text deltas as simple SSE events to the client
+
+**Format for client SSE**: `data: {"text": "<delta>"}\n\n` for each token, and `data: [DONE]\n\n` at the end. This is simpler than forwarding the full Responses API event structure.
+
+**Alternative considered**: Having the client call `localhost:8317` directly via CORS. Rejected — breaks the architecture constraint of keeping external URLs server-side.
+
+### Decision 2: Client-side streaming with SetBrowserResponseStreamingEnabled
+
+Per the stack spec, the client uses:
+- `SetBrowserResponseStreamingEnabled(true)` on the `HttpRequestMessage`
+- `HttpCompletionOption.ResponseHeadersRead` to start reading before the full response arrives
+- Line-by-line iteration of the response stream
+
+This avoids any JavaScript interop for streaming.
+
+### Decision 3: Simple DTOs in Shared project
+
+Add `ChatRequest` (list of messages) and keep the existing `ChatMessage` model. The SSE parsing happens in `ChatApiClient` — no DTO needed for individual stream events since they're parsed inline.
+
+### Decision 4: Configuration via appsettings.json
+
+The API's `appsettings.json` gets:
+```json
+{
+  "ResponsesApi": {
+    "BaseUrl": "http://localhost:8317",
+    "Model": "claude-sonnet-4-6"
+  }
+}
+```
+
+This is the API project's appsettings (server-side, not exposed to the browser).
+
+## Risks / Trade-offs
+
+- [Proxy adds latency] → Minimal for localhost; acceptable tradeoff for keeping URLs server-side
+- [No conversation history] → Intentional; each request is single-turn for now. Multi-turn comes in a future phase.
+- [No retry on stream failure] → If the stream breaks mid-response, the partial text stays visible and an error is shown. Good enough for phase 1.

openspec/changes/wire-responses-api/proposal.md

@@ -0,0 +1,30 @@
+## Why
+
+The chat UI currently returns hardcoded responses. A local OpenAI-compatible proxy is running at `localhost:8317` that exposes the Responses API (`POST /v1/responses`) backed by Anthropic Claude models. This change wires the chat to produce real AI responses via streaming, replacing the hardcoded stub.
+
+## What Changes
+
+- Add a chat endpoint to the API backend that proxies requests to the local Responses API
+- Stream tokens from the Responses API back to the WASM client as SSE
+- Update ChatApiClient with a streaming chat method
+- Replace the hardcoded response in Chat.razor with live streaming from the API
+- Add a "thinking" indicator while the assistant is responding
+- Disable input during streaming to prevent overlapping requests
+
+## Capabilities
+
+### New Capabilities
+- `chat-streaming`: Streaming AI responses from the Responses API proxy through the backend to the WASM client
+
+### Modified Capabilities
+- `chat-ui`: Replace hardcoded response with streaming AI response, add typing indicator, disable input during streaming
+
+## Impact
+
+- `src/ChatAgent.Api/ChatAgent.Api.csproj`: Add no new packages (uses built-in HttpClient)
+- `src/ChatAgent.Api/Controllers/ChatController.cs`: New controller proxying to Responses API
+- `src/ChatAgent.Api/Program.cs`: Register HttpClient for the proxy, add configuration
+- `src/ChatAgent.Api/appsettings.json`: New — configure Responses API base URL and model
+- `src/ChatAgent.Client/Services/ChatApiClient.cs`: Add streaming chat method
+- `src/ChatAgent.Client/Pages/Chat.razor`: Replace hardcoded response with streaming call
+- `src/ChatAgent.Shared/Models/`: New request/response DTOs for the chat endpoint

openspec/changes/wire-responses-api/specs/chat-streaming/spec.md

@@ -0,0 +1,51 @@
+## ADDED Requirements
+
+### Requirement: Chat endpoint proxies to Responses API
+
+The API backend SHALL expose `POST /api/chat` that accepts a list of messages and proxies the request to the local Responses API at a configurable base URL using the `POST /v1/responses` endpoint.
+
+#### Scenario: Successful proxy request
+
+- **WHEN** the client sends a POST to `/api/chat` with a message list
+- **THEN** the API forwards the messages to the Responses API with the configured model and returns the response
+
+### Requirement: Streaming response delivery
+
+The API backend SHALL stream the Responses API's SSE events back to the WASM client as `text/event-stream`, forwarding `response.output_text.delta` events so the client can render tokens incrementally.
+
+#### Scenario: Tokens stream to client
+
+- **WHEN** the Responses API emits `response.output_text.delta` events
+- **THEN** the backend forwards each delta as an SSE event to the client containing the text fragment
+
+#### Scenario: Stream completes
+
+- **WHEN** the Responses API emits `response.completed`
+- **THEN** the backend signals stream completion to the client
+
+### Requirement: Configurable proxy target
+
+The Responses API base URL and model name SHALL be configurable via `appsettings.json` in the API project, not hardcoded.
+
+#### Scenario: Configuration read at startup
+
+- **WHEN** the API starts
+- **THEN** it reads `ResponsesApi:BaseUrl` and `ResponsesApi:Model` from configuration
+
+### Requirement: Client streams from backend
+
+The WASM client SHALL call `POST /api/chat` with `SetBrowserResponseStreamingEnabled(true)` and `HttpCompletionOption.ResponseHeadersRead`, then iterate the SSE stream to update the UI token by token.
+
+#### Scenario: Client reads streaming response
+
+- **WHEN** the client sends a chat request
+- **THEN** it reads the response stream incrementally and appends each text delta to the assistant message in real time
+
+### Requirement: Error propagation
+
+If the Responses API returns an error or is unreachable, the API backend SHALL return an appropriate HTTP error status and the client SHALL display the error to the user.
+
+#### Scenario: Proxy unreachable
+
+- **WHEN** the Responses API is not running
+- **THEN** the client displays an error message instead of an assistant response

openspec/changes/wire-responses-api/specs/chat-ui/spec.md

@@ -0,0 +1,50 @@
+## MODIFIED Requirements
+
+### Requirement: Hardcoded response
+
+The assistant SHALL reply with a real AI response streamed from the backend API, replacing the previous hardcoded stub. Tokens appear incrementally as they arrive.
+
+#### Scenario: Bot replies with streamed AI response
+
+- **WHEN** the user sends any message
+- **THEN** the assistant message appears and grows token by token as the stream delivers text
+
+### Requirement: Message input
+
+The chat page SHALL provide a text input area at the bottom of the page where the user can type and submit messages.
+
+#### Scenario: Submit via button
+
+- **WHEN** the user types text and clicks the send button
+- **THEN** the message is added to the conversation and the input is cleared
+
+#### Scenario: Submit via Enter key
+
+- **WHEN** the user types text and presses Enter
+- **THEN** the message is submitted (same as clicking send)
+
+#### Scenario: Empty input blocked
+
+- **WHEN** the user attempts to send an empty or whitespace-only message
+- **THEN** nothing is sent and no message is added
+
+#### Scenario: Input disabled during streaming
+
+- **WHEN** the assistant is currently streaming a response
+- **THEN** the input field and send button are disabled until streaming completes
+
+## ADDED Requirements
+
+### Requirement: Thinking indicator
+
+The chat page SHALL show a visual indicator while waiting for the first token from the assistant.
+
+#### Scenario: Indicator shown during wait
+
+- **WHEN** the user sends a message and the assistant has not yet started streaming
+- **THEN** a thinking indicator (e.g., animated dots) is shown in the assistant message area
+
+#### Scenario: Indicator replaced by content
+
+- **WHEN** the first token arrives from the stream
+- **THEN** the thinking indicator is replaced by the streamed text

openspec/changes/wire-responses-api/tasks.md

@@ -0,0 +1,29 @@
+## 1. Shared Models
+
+- [ ] 1.1 Create ChatRequest.cs in ChatAgent.Shared/Models with a Messages list property
+
+## 2. API Backend
+
+- [ ] 2.1 Add appsettings.json to ChatAgent.Api with ResponsesApi:BaseUrl and ResponsesApi:Model
+- [ ] 2.2 Register an HttpClient for the Responses API proxy in Api Program.cs
+- [ ] 2.3 Create ChatController with POST /api/chat that proxies to the Responses API with streaming
+- [ ] 2.4 Parse Responses API SSE stream, extract response.output_text.delta events, re-emit as simplified SSE to client
+
+## 3. Client Streaming
+
+- [ ] 3.1 Add a streaming SendChatAsync method to ChatApiClient that uses SetBrowserResponseStreamingEnabled and HttpCompletionOption.ResponseHeadersRead
+- [ ] 3.2 Parse the simplified SSE stream line-by-line, yielding text deltas
+
+## 4. Chat Page Updates
+
+- [ ] 4.1 Replace hardcoded response in Chat.razor with a call to ChatApiClient.SendChatAsync
+- [ ] 4.2 Append tokens to the assistant message incrementally with StateHasChanged after each delta
+- [ ] 4.3 Add a thinking indicator shown until the first token arrives
+- [ ] 4.4 Disable input field and send button while streaming is in progress
+- [ ] 4.5 Handle errors — display error message if API call fails
+- [ ] 4.6 Auto-scroll during streaming (not just at the end)
+
+## 5. Verify
+
+- [ ] 5.1 Run dotnet build to confirm no errors
+- [ ] 5.2 Manually verify: send a message, see streaming response from Claude