feat: migrate CLAUDE.md content to OpenSpec specs and initialize workflow

Move project description and tech stack research from CLAUDE.md into
openspec/specs/project/ and openspec/specs/stack/. Slim CLAUDE.md to a
pointer file. Populate config.yaml with project context. Add OpenSpec
CLI skills and commands.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
local
2026-04-04 01:23:13 +01:00
parent 7dd4243f01
commit a462b7dbc7
26 changed files with 3132 additions and 162 deletions

View File

@@ -0,0 +1,70 @@
## Purpose
Define the chat interface — message display, input handling, auto-scroll, and routing.
## 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

View File

@@ -0,0 +1,50 @@
## Purpose
Define MudBlazor installation, theming, and provider configuration for the Client project.
## 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

View File

@@ -0,0 +1,27 @@
## Purpose
Define the project identity, core value, and non-negotiable constraints for Chat Agent WebApp.
## Requirements
### Requirement: Project identity
The project spec SHALL contain the project name, a description paragraph, and a core value statement that communicates the project's dual purpose: working AI chat interface and Blazor learning journey.
#### Scenario: Project description present
- **WHEN** an AI agent or developer reads the project spec
- **THEN** they find the project name ("Chat Agent WebApp"), a description of what the app does, and the core value statement
### Requirement: Project constraints
The project spec SHALL enumerate all non-negotiable constraints that govern technical decisions across the project.
#### Scenario: Constraints enumerated
- **WHEN** a decision is made about technology, architecture, or approach
- **THEN** the project spec provides the authoritative list of constraints to check against:
- Tech stack: .NET / C# / Blazor WebAssembly
- LLM provider: OpenAI GPT API
- Storage: JSON files on local disk
- Architecture: WASM client + backend API (API key stays server-side)
- Code style: Every Blazor concept introduced MUST have inline comments explaining what it does and why

View File

@@ -0,0 +1,54 @@
## Purpose
Document the technology stack decisions for Chat Agent WebApp.
## Requirements
### Requirement: Core technology stack
The stack spec SHALL document the recommended core technologies with version, purpose, and rationale for each.
#### Scenario: Core stack documented
- **WHEN** a developer needs to add or update a dependency
- **THEN** the stack spec provides the authoritative record of: .NET 9 SDK, Blazor WebAssembly Standalone, ASP.NET Core Web API, C# 13, OpenAI SDK 2.9.1, Markdig 1.1.1, MudBlazor 9.2.0, and System.Text.Json
### Requirement: Supporting libraries and tools
The stack spec SHALL document supporting libraries, development tools, and installation notes.
#### Scenario: Supporting libraries referenced
- **WHEN** a developer evaluates adding a new dependency
- **THEN** the stack spec lists supporting libraries with guidance on when to use them (e.g., Microsoft.Extensions.AI — skip for v1)
### Requirement: Alternatives and exclusions
The stack spec SHALL document considered alternatives and explicitly excluded technologies with rationale.
#### Scenario: Alternative considered
- **WHEN** a developer proposes an alternative package or approach
- **THEN** the stack spec provides a record of alternatives already evaluated and why the current choice was made
#### Scenario: Excluded technology referenced
- **WHEN** a developer considers using a technology on the exclusion list
- **THEN** the stack spec explains why it was excluded and what to use instead
### Requirement: Stack patterns
The stack spec SHALL document implementation patterns that govern how stack technologies are used together (streaming, storage, markdown rendering).
#### Scenario: Pattern referenced during implementation
- **WHEN** a developer implements streaming, storage, or markdown rendering
- **THEN** the stack spec provides the canonical pattern to follow
### Requirement: Version compatibility matrix
The stack spec SHALL maintain a compatibility matrix and list of authoritative sources for version decisions.
#### Scenario: Compatibility check
- **WHEN** a package version is being upgraded
- **THEN** the stack spec provides the compatibility matrix to verify cross-package compatibility