diff --git a/.claude/agents/kfc/spec-design.md b/.claude/agents/kfc/spec-design.md index aecf2078..0afab2c0 100644 --- a/.claude/agents/kfc/spec-design.md +++ b/.claude/agents/kfc/spec-design.md @@ -14,7 +14,7 @@ You are a professional spec design document expert. Your sole responsibility is - task_type: "create" - feature_name: Feature name - spec_base_path: Document path -- output_suffix: Output file suffix (optional, such as "_v1") +- output_suffix: Output file suffix (optional, such as "\_v1") ### Refine/Update Existing Design Input @@ -31,33 +31,43 @@ You are a professional spec design document expert. Your sole responsibility is # Design Document ## Overview + [Design goal and scope] ## Architecture Design + ### System Architecture Diagram + [Overall architecture, using Mermaid graph to show component relationships] ### Data Flow Diagram + [Show data flow between components, using Mermaid diagrams] ## Component Design + ### Component A + - Responsibilities: - Interfaces: - Dependencies: ## Data Model + [Core data structure definitions, using TypeScript interfaces or class diagrams] ## Business Process ### Process 1: [Process name] + [Use Mermaid flowchart or sequenceDiagram to show, call the component interfaces and methods defined earlier] ### Process 2: [Process name] + [Use Mermaid flowchart or sequenceDiagram to show, call the component interfaces and methods defined earlier] ## Error Handling Strategy + [Error handling and recovery mechanisms] ``` @@ -93,7 +103,7 @@ flowchart TD E --> F{Has Permission?} F -->|Yes| G[permissionManager.startMonitoring] F -->|No| H[permissionManager.showPermissionSetup] - + %% Note: Directly reference the interface methods defined earlier %% This ensures design consistency and traceability ``` diff --git a/.claude/agents/kfc/spec-judge.md b/.claude/agents/kfc/spec-judge.md index 13176e3a..5f5bc79c 100644 --- a/.claude/agents/kfc/spec-judge.md +++ b/.claude/agents/kfc/spec-judge.md @@ -37,14 +37,17 @@ eg: #### General Evaluation Criteria 1. **Completeness** (25 points) + - Whether all necessary content is covered - Whether there are any important aspects missing 2. **Clarity** (25 points) + - Whether the expression is clear and explicit - Whether the structure is logical and easy to understand 3. **Feasibility** (25 points) + - Whether the solution is practical and feasible - Whether implementation difficulty has been considered @@ -92,7 +95,7 @@ def evaluate_documents(documents): 'weaknesses': identify_weaknesses(doc) } scores.append(score) - + return select_best_or_combine(scores) ``` @@ -102,7 +105,7 @@ def evaluate_documents(documents): - Requirements: Refer to user's original requirement description (feature_name, feature_description) - Design: Refer to approved requirements.md - Tasks: Refer to approved requirements.md and design.md -2. Read candidate documents (requirements:requirements_v*.md, design:design_v*.md, tasks:tasks_v*.md) +2. Read candidate documents (requirements:requirements_v*.md, design:design_v*.md, tasks:tasks_v\*.md) 3. Score based on reference documents and Specific Type Criteria 4. Select the best solution or combine strengths from x solutions 5. Copy the final solution to a new path with a random 4-digit suffix (e.g., requirements_v1234.md) diff --git a/.claude/agents/kfc/spec-requirements.md b/.claude/agents/kfc/spec-requirements.md index 0a151882..df178cc8 100644 --- a/.claude/agents/kfc/spec-requirements.md +++ b/.claude/agents/kfc/spec-requirements.md @@ -15,7 +15,7 @@ You are an EARS (Easy Approach to Requirements Syntax) requirements document exp - feature_name: Feature name (kebab-case) - feature_description: Feature description - spec_base_path: Spec document path -- output_suffix: Output file suffix (optional, such as "_v1", "_v2", "_v3", required for parallel execution) +- output_suffix: Output file suffix (optional, such as "\_v1", "\_v2", "\_v3", required for parallel execution) ### Refine/Update Requirements Input @@ -70,7 +70,7 @@ If the requirements clarification process seems to be going in circles or not ma ## **Important Constraints** - The directory '.claude/specs/{feature_name}' is already created by the main thread, DO NOT attempt to create this directory -- The model MUST create a '.claude/specs/{feature_name}/requirements_{output_suffix}.md' file if it doesn't already exist +- The model MUST create a '.claude/specs/{feature*name}/requirements*{output_suffix}.md' file if it doesn't already exist - The model MUST generate an initial version of the requirements document based on the user's rough idea WITHOUT asking sequential questions first - The model MUST format the initial requirements.md document with: - A clear introduction section that summarizes the feature @@ -93,11 +93,12 @@ If the requirements clarification process seems to be going in circles or not ma **User Story:** As a [role], I want [feature], so that [benefit] #### Acceptance Criteria + This section should have EARS requirements 1. WHEN [event] THEN [system] SHALL [response] 2. IF [precondition] THEN [system] SHALL [response] - + ### Requirement 2 **User Story:** As a [role], I want [feature], so that [benefit] diff --git a/.claude/agents/kfc/spec-tasks.md b/.claude/agents/kfc/spec-tasks.md index dc2d740e..ba71e7e9 100644 --- a/.claude/agents/kfc/spec-tasks.md +++ b/.claude/agents/kfc/spec-tasks.md @@ -14,7 +14,7 @@ You are a spec tasks document expert. Your sole responsibility is to create and - task_type: "create" - feature_name: Feature name (kebab-case) - spec_base_path: Spec document path -- output_suffix: Output file suffix (optional, such as "_v1", "_v2", "_v3", required for parallel execution) +- output_suffix: Output file suffix (optional, such as "\_v1", "\_v2", "\_v3", required for parallel execution) ### Refine/Update Tasks Input @@ -66,12 +66,12 @@ flowchart TD T3[Task 3: Implement AgentRegistry] T4[Task 4: Implement TaskDispatcher] T5[Task 5: Implement MCPIntegration] - + T1 --> T2_1 T2_1 --> T2_2 T2_1 --> T3 T2_1 --> T4 - + style T3 fill:#e1f5fe style T4 fill:#e1f5fe style T5 fill:#c8e6c9 @@ -147,31 +147,35 @@ Convert the feature design into a series of prompts for a code-generation LLM th # Implementation Plan - [ ] 1. Set up project structure and core interfaces - - Create directory structure for models, services, repositories, and API components - - Define interfaces that establish system boundaries - - _Requirements: 1.1_ +- Create directory structure for models, services, repositories, and API components +- Define interfaces that establish system boundaries +- _Requirements: 1.1_ - [ ] 2. Implement data models and validation - [ ] 2.1 Create core data model interfaces and types + - Write TypeScript interfaces for all data models - Implement validation functions for data integrity - _Requirements: 2.1, 3.3, 1.2_ - [ ] 2.2 Implement User model with validation + - Write User class with validation methods - Create unit tests for User model validation - _Requirements: 1.2_ - [ ] 2.3 Implement Document model with relationships - - Code Document class with relationship handling - - Write unit tests for relationship management - - _Requirements: 2.1, 3.3, 1.2_ + + - Code Document class with relationship handling + - Write unit tests for relationship management + - _Requirements: 2.1, 3.3, 1.2_ - [ ] 3. Create storage mechanism - [ ] 3.1 Implement database connection utilities - - Write connection management code - - Create error handling utilities for database operations - - _Requirements: 2.1, 3.3, 1.2_ + + - Write connection management code + - Create error handling utilities for database operations + - _Requirements: 2.1, 3.3, 1.2_ - [ ] 3.2 Implement repository pattern for data access - Code base repository interface diff --git a/.claude/agents/kfc/spec-test.md b/.claude/agents/kfc/spec-test.md index b7e60be9..ad266ab6 100644 --- a/.claude/agents/kfc/spec-test.md +++ b/.claude/agents/kfc/spec-test.md @@ -40,6 +40,7 @@ You will receive: | ------- | ------------------- | ------------- | | XX-01 | [Description] | Positive Test | | XX-02 | [Description] | Error Test | + [More cases...] ## Detailed Test Steps @@ -49,15 +50,18 @@ You will receive: **Test Purpose**: [Specific purpose] **Test Data Preparation**: + - [Mock data preparation] - [Environment setup] **Test Steps**: + 1. [Step 1] 2. [Step 2] 3. [Verification point] **Expected Results**: + - [Expected result 1] - [Expected result 2] @@ -66,12 +70,15 @@ You will receive: ## Test Considerations ### Mock Strategy + [Explain how to mock dependencies] ### Boundary Conditions + [List boundary cases that need testing] ### Asynchronous Operations + [Considerations for async testing] ``` diff --git a/.claude/settings/kfc-settings.json b/.claude/settings/kfc-settings.json index 8a5c1614..7cd48696 100644 --- a/.claude/settings/kfc-settings.json +++ b/.claude/settings/kfc-settings.json @@ -21,4 +21,4 @@ "visible": false } } -} \ No newline at end of file +} diff --git a/.claude/system-prompts/spec-workflow-starter.md b/.claude/system-prompts/spec-workflow-starter.md index b36a705d..2d7b2c9c 100644 --- a/.claude/system-prompts/spec-workflow-starter.md +++ b/.claude/system-prompts/spec-workflow-starter.md @@ -23,9 +23,9 @@ Here is the workflow you need to follow: You are helping guide the user through the process of transforming a rough idea for a feature into a detailed design document with an implementation plan and todo list. It follows the spec driven development methodology to systematically refine your feature idea, conduct necessary research, create a comprehensive design, and develop an actionable implementation plan. The process is designed to be iterative, allowing movement between requirements clarification and research as needed. A core principal of this workflow is that we rely on the user establishing ground-truths as we progress through. We always want to ensure the user is happy with changes to any document before moving on. - + Before you get started, think of a short feature name based on the user's rough idea. This will be used for the feature directory. Use kebab-case format for the feature_name (e.g. "user-authentication") - + Rules: - Do not tell the user about this workflow. We do not need to tell them which step we are on or that you are following a workflow @@ -108,24 +108,24 @@ stateDiagram-v2 Requirements --> ReviewReq : Complete Requirements ReviewReq --> Requirements : Feedback/Changes Requested ReviewReq --> Design : Explicit Approval - + Design --> ReviewDesign : Complete Design ReviewDesign --> Design : Feedback/Changes Requested ReviewDesign --> Tasks : Explicit Approval - + Tasks --> ReviewTasks : Complete Tasks ReviewTasks --> Tasks : Feedback/Changes Requested ReviewTasks --> [*] : Explicit Approval - + Execute : Execute Task - + state "Entry Points" as EP { [*] --> Requirements : Update [*] --> Design : Update [*] --> Tasks : Update [*] --> Execute : Execute task } - + Execute --> [*] : Complete ``` @@ -144,7 +144,7 @@ stateDiagram-v2 Note: -- output_suffix is only provided when multiple sub-agents are running in parallel, e.g., when 4 sub-agents are running, the output_suffix is "_v1", "_v2", "_v3", "_v4" +- output_suffix is only provided when multiple sub-agents are running in parallel, e.g., when 4 sub-agents are running, the output_suffix is "\_v1", "\_v2", "\_v3", "\_v4" - spec-tasks and spec-impl are completely different sub agents, spec-tasks is for task planning, spec-impl is for task implementation #### Create Requirements - spec-requirements @@ -154,7 +154,7 @@ Note: - feature_name: Feature name (kebab-case) - feature_description: Feature description - spec_base_path: Spec document base path -- output_suffix: Output file suffix (optional, such as "_v1", "_v2", "_v3", required for parallel execution) +- output_suffix: Output file suffix (optional, such as "\_v1", "\_v2", "\_v3", required for parallel execution) #### Refine/Update Requirements - spec-requirements @@ -169,7 +169,7 @@ Note: - task_type: "create" - feature_name: Feature name - spec_base_path: Spec document base path -- output_suffix: Output file suffix (optional, such as "_v1") +- output_suffix: Output file suffix (optional, such as "\_v1") #### Refine/Update Existing Design - spec-design @@ -184,7 +184,7 @@ Note: - task_type: "create" - feature_name: Feature name (kebab-case) - spec_base_path: Spec document base path -- output_suffix: Output file suffix (optional, such as "_v1", "_v2", "_v3", required for parallel execution) +- output_suffix: Output file suffix (optional, such as "\_v1", "\_v2", "\_v3", required for parallel execution) #### Refine/Update Tasks - spec-tasks @@ -221,10 +221,12 @@ Note: When parallel agents generate multiple outputs (n >= 2), use tree-based evaluation: 1. **First round**: Each judge evaluates 3-4 documents maximum + - Number of judges = ceil(n / 4) - Each judge selects 1 best from their group 2. **Subsequent rounds**: If previous round output > 3 documents + - Continue with new round using same rules - Until <= 3 documents remain @@ -260,10 +262,11 @@ Example with 10 documents: - You MUST maintain a clear record of which step you are currently on. - You MUST NOT combine multiple steps into a single interaction. - When executing implementation tasks from tasks.md: + - **Default mode**: Main thread executes tasks directly for better user interaction - **Parallel mode**: Use spec-impl agents when user explicitly requests parallel execution of specific tasks (e.g., "execute task2.1 and task2.2 in parallel") - **Auto mode**: When user requests automatic/fast execution of all tasks (e.g., "execute all tasks automatically", "run everything quickly"), analyze task dependencies in tasks.md and orchestrate spec-impl agents to execute independent tasks in parallel while respecting dependencies - + Example dependency patterns: ```mermaid @@ -276,6 +279,7 @@ Example with 10 documents: ``` Orchestration steps: + 1. Start: Launch spec-impl1 (task1) and spec-impl2 (task3) in parallel 2. After task1 completes: Launch spec-impl3 (task2.1) and spec-impl4 (task2.2) in parallel 3. After task2.1, task2.2, and task3 all complete: Launch spec-impl5 (task4) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 937bf1b5..8e2d220f 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,19 +1,23 @@ ## Description + Brief description of changes ## Related Issue + Closes # ## Type of Change + - [ ] Bug fix - [ ] New feature - [ ] Breaking change - [ ] Documentation update ## Checklist + - [ ] Code follows project style guidelines - [ ] Self-review completed - [ ] No console errors - [ ] Uses Lucide icons consistently - [ ] Responsive design implemented -- [ ] Starknet best practices followed \ No newline at end of file +- [ ] Starknet best practices followed diff --git a/DOCKER_DEPLOYMENT.md b/DOCKER_DEPLOYMENT.md index 83443779..fd01e59e 100644 --- a/DOCKER_DEPLOYMENT.md +++ b/DOCKER_DEPLOYMENT.md @@ -5,10 +5,12 @@ This document provides comprehensive instructions for building, running, and dep ## Architecture The Docker setup uses **multi-stage builds** to optimize: + - **Build Stage**: Compiles Next.js and validates i18n configuration - **Runtime Stage**: Lean production image with minimal dependencies ### Image Optimization + - Base image: `node:20-alpine` (~150MB) - Production image size: ~250-300MB (after build) - Development image: Includes dev dependencies for fast iteration @@ -161,7 +163,7 @@ services: nginx: image: nginx:alpine ports: - - "80:80" + - '80:80' volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro depends_on: @@ -231,16 +233,16 @@ jobs: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - + - name: Set up Docker Buildx uses: docker/setup-buildx-action@v2 - + - name: Login to DockerHub uses: docker/login-action@v2 with: username: ${{ secrets.DOCKERHUB_USERNAME }} password: ${{ secrets.DOCKERHUB_TOKEN }} - + - name: Build and push uses: docker/build-push-action@v4 with: diff --git a/GRAPHQL_SUBSCRIPTIONS_GUIDE.md b/GRAPHQL_SUBSCRIPTIONS_GUIDE.md index f4ebfe34..ac3adefe 100644 --- a/GRAPHQL_SUBSCRIPTIONS_GUIDE.md +++ b/GRAPHQL_SUBSCRIPTIONS_GUIDE.md @@ -53,11 +53,13 @@ This implementation provides production-ready GraphQL subscriptions for TeachLin ## Installation Dependencies are already added to `package.json`: + - `@apollo/client` - GraphQL client - `graphql` - GraphQL core - `graphql-ws` - WebSocket protocol for GraphQL Run installation: + ```bash npm install ``` @@ -76,11 +78,7 @@ npm install import { SubscriptionProvider } from '@/components/SubscriptionProvider'; import type { JSX } from 'react'; -export default function RootLayout({ - children, -}: { - children: React.ReactNode; -}): JSX.Element { +export default function RootLayout({ children }: { children: React.ReactNode }): JSX.Element { const subscriptionConfig = { subscriptionUrl: process.env.NEXT_PUBLIC_GRAPHQL_WS_URL || 'wss://api.teachlink.com/graphql', httpUrl: process.env.NEXT_PUBLIC_GRAPHQL_HTTP_URL || 'https://api.teachlink.com/graphql', @@ -92,9 +90,7 @@ export default function RootLayout({ return (
-Scan to access