Merge pull request #1245 from Stijnus/FEAT_BoltDYI_NEW_SETTINGS_UI_V3

feat: bolt dyi new settings UI V3

Author: coleam00

.cursorrules

@@ -0,0 +1,157 @@
+# Project Overview
+
+bolt.diy (previously oTToDev) is an open-source AI-powered full-stack web development platform that allows users to choose different LLM providers for coding assistance. The project supports multiple AI providers including OpenAI, Anthropic, Ollama, OpenRouter, Gemini, LMStudio, Mistral, xAI, HuggingFace, DeepSeek, and Groq.
+
+# Personality
+
+- Professional and technically precise
+- Focus on best practices and clean code
+- Provide clear explanations for code changes
+- Maintain consistent code style with the existing codebase
+
+# Techstack
+
+- Framework: Remix
+- Runtime: Node.js (>=18.18.0)
+- Package Manager: pnpm
+- UI: React with TypeScript
+- Styling: UnoCSS
+- Development Environment: Vite
+- Testing: Vitest
+- Deployment: Cloudflare Pages
+- Containerization: Docker
+- Code Quality: ESLint, Prettier, TypeScript
+
+# our .env file
+
+- Follow .env.example for required environment variables
+- Keep API keys and sensitive data in .env.local
+- Never commit .env files (they are gitignored)
+
+# Error Fixing Process
+
+1. Identify the root cause through error messages and logs
+2. Check relevant components and dependencies
+3. Verify type safety and TypeScript compliance
+4. Test changes locally before committing
+5. Follow existing error handling patterns
+
+# Our Codebase
+
+- Main application code in /app directory
+- Components follow a modular structure
+- Server-side code in app/lib/.server
+- Client-side utilities in app/lib/
+- Type definitions in types/ directory
+- Documentation in docs/ directory
+
+# Current File Structure
+
+- /app - Main application code
+- /docs - Documentation
+- /functions - Serverless functions
+- /public - Static assets
+- /scripts - Build and utility scripts
+- /types - TypeScript definitions
+- /icons - SVG icons and assets
+
+# github upload process
+
+1. Follow conventional commit messages
+2. Run linting and tests before committing
+3. Create feature branches for new work
+4. Submit PRs with clear descriptions
+5. Ensure CI/CD checks pass
+
+# Important
+
+- Keep dependencies updated
+- Follow TypeScript strict mode
+- Maintain backward compatibility
+- Document API changes
+- Test cross-browser compatibility
+
+# comments
+
+- Use JSDoc for function documentation
+- Keep comments clear and concise
+- Document complex logic and business rules
+- Update comments when changing code
+- Remove redundant comments
+- Always write comments that are relevant to the code they describe
+- Ensure comments explain the "why" not just the "what"
+
+# code review
+
+- Check for type safety
+- Verify error handling
+- Ensure code follows project patterns
+- Look for performance implications
+- Validate accessibility standards
+
+# code writing
+
+- Follow TypeScript best practices
+- Use functional components for React
+- Implement proper error boundaries
+- Write testable code
+- Follow the DRY principle
+
+# code refactoring
+
+- Maintain backward compatibility
+- Update tests alongside changes
+- Document breaking changes
+- Follow the project's type system
+- Keep components modular and reusable
+
+# Development Process
+
+- Write 3 reasoning paragraphs before implementing solutions
+- Analyze the problem space thoroughly before jumping to conclusions
+- Consider all edge cases and potential impacts
+- Process tasks with a Senior Developer mindset
+- Continue working until the solution is complete and verified
+- Remember and consider the full commit/change history when working
+
+# Code Quality Guidelines
+
+- Fewer lines of code is better, but not at the expense of readability
+- Preserve existing comments and documentation
+- Add meaningful comments explaining complex logic or business rules
+- Follow the principle of "Clean Code, Clear Intent"
+- Balance between conciseness and maintainability
+- Think twice, code once - avoid premature optimization
+- Never add comments just for the sake of commenting - ensure they add value
+
+# Problem Solving Approach
+
+1. Understand the context fully before making changes
+2. Document your reasoning and assumptions
+3. Consider alternative approaches and their trade-offs
+4. Validate your solution against existing patterns
+5. Test thoroughly before considering work complete
+6. Review impact on related components
+
+# UI GUIDELINES
+
+- Use consistent colors and typography
+- Ensure UI is responsive and accessible
+- Provide clear feedback for user actions
+- Use meaningful icons and labels
+- Keep UI clean and organized
+- Use consistent spacing and alignment
+- Use consistent naming conventions for components and variables
+- Use consistent file and folder structure
+- Use consistent naming conventions for components and variables
+- Use consistent file and folder structure
+
+# Style Guide
+
+- Use consistent naming conventions for components and variables
+- Use consistent file and folder structure
+- Respect the Light/Dark mode
+- Don't use white background for dark mode
+- Don't use white text on white background for dark mode
+- Match the style of the existing codebase
+- Use consistent naming conventions for components and variables

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -1,4 +1,4 @@
-name: "Bug report"
+name: 'Bug report'
 description: Create a report to help us improve
 body:
   - type: markdown

.github/ISSUE_TEMPLATE/epic.md

@@ -19,5 +19,5 @@ Usual values: Software Developers using the IDE | Contributors -->
 
 # Capabilities
 
-<!-- which existing capabilities or future features can be imagined that belong to this epic? This list serves as illustration to sketch the boundaries of this epic. 
+<!-- which existing capabilities or future features can be imagined that belong to this epic? This list serves as illustration to sketch the boundaries of this epic.
 Once features are actually being planned / described in detail, they can be linked here. -->

.github/ISSUE_TEMPLATE/feature.md

@@ -13,13 +13,13 @@ assignees: ''
 
 # Scope
 
-<!-- This is kind-of the definition-of-done for a feature. 
+<!-- This is kind-of the definition-of-done for a feature.
 Try to keep the scope as small as possible and prefer creating multiple, small features which each solve a single problem / make something better
 -->
 
 # Options
- 
-<!-- If you already have an idea how this can be implemented, please describe it here. 
+
+<!-- If you already have an idea how this can be implemented, please describe it here.
 This allows potential other contributors to join forces and provide meaningful feedback prio to even starting work on it.
 -->
 

.github/workflows/docker.yaml

@@ -8,7 +8,7 @@ on:
       - main
     tags:
       - v*
-      - "*"
+      - '*'
 
 permissions:
   packages: write
@@ -57,7 +57,7 @@ jobs:
         with:
           registry: ${{ env.REGISTRY }}
           username: ${{ github.actor }} # ${{ secrets.DOCKER_USERNAME }}
-          password: ${{ secrets.GITHUB_TOKEN }} # ${{ secrets.DOCKER_PASSWORD }} 
+          password: ${{ secrets.GITHUB_TOKEN }} # ${{ secrets.DOCKER_PASSWORD }}
 
       - name: Build and push
         uses: docker/build-push-action@v6

.github/workflows/docs.yaml

@@ -5,7 +5,7 @@ on:
     branches:
       - main
     paths:
-      - 'docs/**'  # This will only trigger the workflow when files in docs directory change
+      - 'docs/**' # This will only trigger the workflow when files in docs directory change
 permissions:
   contents: write
 jobs:
@@ -23,7 +23,7 @@ jobs:
       - uses: actions/setup-python@v5
         with:
           python-version: 3.x
-      - run: echo "cache_id=$(date --utc '+%V')" >> $GITHUB_ENV 
+      - run: echo "cache_id=$(date --utc '+%V')" >> $GITHUB_ENV
       - uses: actions/cache@v4
         with:
           key: mkdocs-material-${{ env.cache_id }}
@@ -32,4 +32,4 @@ jobs:
             mkdocs-material-
 
       - run: pip install mkdocs-material
-      - run: mkdocs gh-deploy --force 
+      - run: mkdocs gh-deploy --force

.github/workflows/pr-release-validation.yaml

@@ -9,10 +9,10 @@ on:
 jobs:
   validate:
     runs-on: ubuntu-latest
-    
+
     steps:
       - uses: actions/checkout@v4
-      
+
       - name: Validate PR Labels
         run: |
           if [[ "${{ contains(github.event.pull_request.labels.*.name, 'stable-release') }}" == "true" ]]; then
@@ -28,4 +28,4 @@ jobs:
             fi
           else
             echo "This PR doesn't have the stable-release label. No release will be created." 
-          fi
+          fi

.github/workflows/semantic-pr.yaml

@@ -29,4 +29,4 @@ jobs:
             docs
             refactor
             revert
-            test
+            test

.github/workflows/stale.yml

@@ -2,8 +2,8 @@ name: Mark Stale Issues and Pull Requests
 
 on:
   schedule:
-    - cron: '0 2 * * *'  # Runs daily at 2:00 AM UTC
-  workflow_dispatch:  # Allows manual triggering of the workflow
+    - cron: '0 2 * * *' # Runs daily at 2:00 AM UTC
+  workflow_dispatch: # Allows manual triggering of the workflow
 
 jobs:
   stale:
@@ -14,12 +14,12 @@ jobs:
         uses: actions/stale@v8
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
-          stale-issue-message: "This issue has been marked as stale due to inactivity. If no further activity occurs, it will be closed in 7 days."
-          stale-pr-message: "This pull request has been marked as stale due to inactivity. If no further activity occurs, it will be closed in 7 days."
-          days-before-stale: 10            # Number of days before marking an issue or PR as stale
-          days-before-close: 4             # Number of days after being marked stale before closing
-          stale-issue-label: "stale"       # Label to apply to stale issues
-          stale-pr-label: "stale"          # Label to apply to stale pull requests
-          exempt-issue-labels: "pinned,important" # Issues with these labels won't be marked stale
-          exempt-pr-labels: "pinned,important"    # PRs with these labels won't be marked stale
-          operations-per-run: 75           # Limits the number of actions per run to avoid API rate limits
+          stale-issue-message: 'This issue has been marked as stale due to inactivity. If no further activity occurs, it will be closed in 7 days.'
+          stale-pr-message: 'This pull request has been marked as stale due to inactivity. If no further activity occurs, it will be closed in 7 days.'
+          days-before-stale: 10 # Number of days before marking an issue or PR as stale
+          days-before-close: 4 # Number of days after being marked stale before closing
+          stale-issue-label: 'stale' # Label to apply to stale issues
+          stale-pr-label: 'stale' # Label to apply to stale pull requests
+          exempt-issue-labels: 'pinned,important' # Issues with these labels won't be marked stale
+          exempt-pr-labels: 'pinned,important' # PRs with these labels won't be marked stale
+          operations-per-run: 75 # Limits the number of actions per run to avoid API rate limits

.github/workflows/update-stable.yml

@@ -7,12 +7,12 @@ on:
 
 permissions:
   contents: write
-  
+
 jobs:
   prepare-release:
     if: contains(github.event.head_commit.message, '#release')
     runs-on: ubuntu-latest
-    
+
     steps:
       - uses: actions/checkout@v4
         with:
@@ -80,7 +80,6 @@ jobs:
           NEW_VERSION=${{ steps.bump_version.outputs.new_version }}
           pnpm version $NEW_VERSION --no-git-tag-version --allow-same-version
 
-      
       - name: Prepare changelog script
         run: chmod +x .github/scripts/generate-changelog.sh
 
@@ -89,14 +88,14 @@ jobs:
         env:
           NEW_VERSION: ${{ steps.bump_version.outputs.new_version }}
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          
+
         run: .github/scripts/generate-changelog.sh
 
       - name: Get the latest commit hash and version tag
         run: |
           echo "COMMIT_HASH=$(git rev-parse HEAD)" >> $GITHUB_ENV
           echo "NEW_VERSION=${{ steps.bump_version.outputs.new_version }}" >> $GITHUB_ENV
-          
+
       - name: Commit and Tag Release
         run: |
           git pull
@@ -123,4 +122,4 @@ jobs:
           gh release create "$VERSION" \
             --title "Release $VERSION" \
             --notes "${{ steps.changelog.outputs.content }}" \
-            --target stable
+            --target stable