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
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-04-03
|
||||
@@ -0,0 +1,33 @@
|
||||
## Context
|
||||
|
||||
CLAUDE.md is a monolithic file containing project identity, tech stack research, and stale GSD workflow sections. OpenSpec is now initialized and provides a structured home for this content as specs.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
- Move project description and constraints into `openspec/specs/project/spec.md`
|
||||
- Move technology stack research into `openspec/specs/stack/spec.md`
|
||||
- Populate `openspec/config.yaml` context so AI agents get project context when creating artifacts
|
||||
- Reduce CLAUDE.md to a slim file that points to OpenSpec for project knowledge
|
||||
|
||||
**Non-Goals:**
|
||||
- Rewriting or editing the migrated content (faithful move, not a rewrite)
|
||||
- Creating conventions or architecture specs (those are still empty placeholders)
|
||||
- Changing any application code
|
||||
|
||||
## Decisions
|
||||
|
||||
### Decision 1: Spec file format
|
||||
|
||||
The main specs in `openspec/specs/` will use a prose/reference format (not the WHEN/THEN delta format). The delta specs in the change use WHEN/THEN for requirements tracking, but the actual spec content is the migrated prose — tables, lists, and all.
|
||||
|
||||
### Decision 2: CLAUDE.md post-migration content
|
||||
|
||||
CLAUDE.md will retain only:
|
||||
- A one-line project summary
|
||||
- A pointer to `openspec/specs/` for project knowledge
|
||||
- Any workflow instructions specific to Claude Code (not project specs)
|
||||
|
||||
### Decision 3: config.yaml context
|
||||
|
||||
The `context` field in `openspec/config.yaml` will get a brief project summary and tech stack headline, so artifact generation has baseline context without reading full specs.
|
||||
@@ -0,0 +1,27 @@
|
||||
## Why
|
||||
|
||||
CLAUDE.md currently holds all project knowledge — description, constraints, and a large tech stack research block. With OpenSpec initialized, this content belongs in `openspec/specs/` where it can be managed as proper specs, referenced by changes, and won't conflict with CLAUDE.md's role as a slim workflow/instruction file.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Extract project description and constraints into a `project` spec
|
||||
- Extract full technology stack research into a `stack` spec
|
||||
- Populate `openspec/config.yaml` with project context
|
||||
- Slim CLAUDE.md down to workflow instructions with pointers to OpenSpec
|
||||
- Remove stale GSD placeholder sections (conventions, architecture, profile)
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `project`: Project identity, core value statement, and non-negotiable constraints
|
||||
- `stack`: Technology stack decisions — packages, versions, alternatives, patterns, compatibility, and sources
|
||||
|
||||
### Modified Capabilities
|
||||
<!-- None — no existing specs yet -->
|
||||
|
||||
## Impact
|
||||
|
||||
- `CLAUDE.md`: Reduced from ~147 lines to a slim pointer file
|
||||
- `openspec/specs/project/spec.md`: New file with project identity
|
||||
- `openspec/specs/stack/spec.md`: New file with stack research
|
||||
- `openspec/config.yaml`: Updated with project context
|
||||
@@ -0,0 +1,24 @@
|
||||
## ADDED 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
|
||||
@@ -0,0 +1,51 @@
|
||||
## ADDED 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
|
||||
@@ -0,0 +1,16 @@
|
||||
## 1. Create main specs
|
||||
|
||||
- [x] 1.1 Create `openspec/specs/project/spec.md` with project description, core value, and constraints from CLAUDE.md
|
||||
- [x] 1.2 Create `openspec/specs/stack/spec.md` with full technology stack content from CLAUDE.md
|
||||
|
||||
## 2. Update config
|
||||
|
||||
- [x] 2.1 Populate `openspec/config.yaml` context field with project summary and tech stack headline
|
||||
|
||||
## 3. Slim down CLAUDE.md
|
||||
|
||||
- [x] 3.1 Replace CLAUDE.md contents with slim pointer file
|
||||
|
||||
## 4. Verify
|
||||
|
||||
- [x] 4.1 Confirm no content was lost — all substantive information is in specs
|
||||
@@ -1,20 +1,9 @@
|
||||
schema: spec-driven
|
||||
|
||||
# Project context (optional)
|
||||
# This is shown to AI when creating artifacts.
|
||||
# Add your tech stack, conventions, style guides, domain knowledge, etc.
|
||||
# Example:
|
||||
# context: |
|
||||
# Tech stack: TypeScript, React, Node.js
|
||||
# We use conventional commits
|
||||
# Domain: e-commerce platform
|
||||
|
||||
# Per-artifact rules (optional)
|
||||
# Add custom rules for specific artifacts.
|
||||
# Example:
|
||||
# rules:
|
||||
# proposal:
|
||||
# - Keep proposals under 500 words
|
||||
# - Always include a "Non-goals" section
|
||||
# tasks:
|
||||
# - Break tasks into chunks of max 2 hours
|
||||
context: |
|
||||
Chat Agent WebApp — personal AI chat app built with Blazor WebAssembly + OpenAI GPT API.
|
||||
Tech stack: .NET 9, C# 13, Blazor WASM (standalone client), ASP.NET Core Web API (backend proxy).
|
||||
Key libraries: OpenAI SDK 2.9.1, Markdig 1.1.1, MudBlazor 9.2.0, System.Text.Json.
|
||||
Storage: JSON files on local disk. Single-user, no auth.
|
||||
The project is also a Blazor tutorial — every concept must have inline comments explaining what and why.
|
||||
See openspec/specs/project/ and openspec/specs/stack/ for full details.
|
||||
|
||||
70
openspec/specs/chat-ui/spec.md
Normal file
70
openspec/specs/chat-ui/spec.md
Normal 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
|
||||
50
openspec/specs/mudblazor-setup/spec.md
Normal file
50
openspec/specs/mudblazor-setup/spec.md
Normal 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
|
||||
27
openspec/specs/project/spec.md
Normal file
27
openspec/specs/project/spec.md
Normal 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
|
||||
|
||||
54
openspec/specs/stack/spec.md
Normal file
54
openspec/specs/stack/spec.md
Normal 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
|
||||
|
||||
Reference in New Issue
Block a user