Awesome Cursor Rules Collection

{
    "project_type": "nba_data_scraper",
    "language": "python",
    "main_files": {
        "scraper": "nba_scraper.py",
        "data": ["nba_games_all.csv", "nba_team_stats_all.csv"],
        "progress": "scraper_progress.json",
        "docs": ["README.md", "LICENSE"]
    },
    "future_enhancements": {
        "development_phases": {
            "phase1": {
                "name": "Data Quality & Storage",
                "status": "in_progress",
                "priorities": {
                    "high": {
                        "fix_team_stats": {
                            "issue": "table_format_error",
                            "season": "2025",
                            "approach": "alternative_source"
                        },
                        "verify_quarter_stats": {
                            "check_availability": true,
                            "fallback_plan": "remove_if_unreliable"
                        }
                    },
                    "medium": {
                        "postgresql_migration": {
                            "tables": ["games", "team_stats", "player_stats"],
                            "indexes": ["date", "team", "season"],
                            "backup_csvs": true
                        }
                    }
                }
            },
            "phase2": {
                "name": "Enhanced Data Integration",
                "status": "planned",
                "components": {
                    "injury_data": {
                        "sources": ["espn", "rotoworld"],
                        "update_frequency": "daily",
                        "required_fields": ["player", "status", "details", "return_date"]
                    },
                    "betting_odds": {
                        "source": "oddsportal",
                        "markets": ["moneyline", "spreads", "totals"],
                        "update_frequency": "hourly"
                    },
                    "player_mapping": {
                        "source": "basketball_reference",
                        "format": "lastname5_firstname2_01",
                        "update_frequency": "weekly"
                    }
                }
            },
            "phase3": {
                "name": "Advanced Analytics",
                "status": "planned",
                "components": {
                    "machine_learning": {
                        "models": ["classification", "regression"],
                        "features": ["team_stats", "rest_days", "travel_fatigue"]
                    },
                    "betting_metrics": {
                        "types": ["roi", "kelly_criterion", "sharp_money"]
                    }
                }
            },
            "phase4": {
                "name": "Production Infrastructure",
                "status": "planned",
                "components": {
                    "automated_updates": {
                        "frequency": "daily",
                        "time": "00:00 UTC"
                    },
                    "monitoring": {
                        "metrics": ["data_freshness", "scraping_success", "error_rates"],
                        "alerts": ["email", "logging"]
                    }
                }
            }
        }
    },
    "season_handling": {
        "current_season": "2024-25",
        "season_format": "YYYY represents end year (e.g., 2025 = 2024-25 season)",
        "special_cases": {
            "2020-21": "COVID season (December start)",
            "current": "Games scheduled through April 13, 2025"
        },
        "validation": {
            "check_season_transitions": true,
            "validate_month_year_mapping": true,
            "minimum_games_warning": {
                "2021": 1000,
                "2022": 1200,
                "2023": 1200,
                "2024": 50,
                "2025": 50
            }
        }
    },
    "data_validation": {
        "expected_games": {
            "regular": 1230,
            "covid_season": 1080,
            "current_season_minimum": 500,
            "validate_per_month": true,
            "season_specific_counts": {
                "2021": {"count": 1163, "status": "complete", "type": "covid"},
                "2022": {"count": 1323, "status": "complete", "type": "regular"},
                "2023": {"count": 1320, "status": "complete", "type": "regular"},
                "2024": {"count": 54, "status": "partial", "type": "regular"},
                "2025": {"count": 71, "status": "in_progress", "type": "regular"}
            },
            "data_freshness": {
                "max_days_old": 79,
                "warning_threshold": 60,
                "critical_threshold": 75
            }
        },
        "required_columns": [
            "Date", "Away_Team", "Home_Team", "Away_Points", "Home_Points",
            "Season", "Month", "Is_Future", "Is_Scheduled", "Is_Played"
        ],
        "data_types": {
            "Date": "datetime64[ns]",
            "Points": "float64",
            "Is_Future": "boolean",
            "Is_Scheduled": "boolean",
            "Is_Played": "boolean"
        },
        "duplicate_handling": {
            "check_before_concat": true,
            "keep_strategy": "first",
            "log_duplicates": true
        },
        "team_stats_validation": {
            "early_season_handling": {
                "retry_with_monthly": true,
                "minimum_games_required": 5,
                "fallback_to_previous": true,
                "known_issues": {
                    "2025": {
                        "table_format_error": true,
                        "alternative_source_needed": true,
                        "minimum_data_required": false,
                        "error_details": {
                            "type": "pandas_read_error",
                            "message": "arg must be a list, tuple, 1-d array, or Series",
                            "resolution_steps": [
                                "verify_table_exists",
                                "check_table_structure",
                                "try_alternative_parser",
                                "fallback_to_monthly_stats"
                            ]
                        }
                    }
                }
            },
            "table_format_checks": {
                "verify_columns": true,
                "handle_missing_tables": true,
                "log_format_changes": true,
                "required_stats": [
                    "ORtg", "DRtg", "Pace", "SRS",
                    "eFG_Pct", "TOV_Pct", "ORB_Pct", "FT_Rate"
                ],
                "alternative_tables": [
                    "misc_stats",
                    "per_game_stats",
                    "advanced_stats"
                ],
                "parsing_options": {
                    "try_all_tables": true,
                    "handle_multiindex": true,
                    "clean_column_names": true
                }
            }
        },
        "immediate_priorities": {
            "fix_team_stats": {
                "priority": "high",
                "affected_season": "2025",
                "required_actions": [
                    "handle_table_format_changes",
                    "implement_alternative_source",
                    "add_partial_season_validation"
                ]
            },
            "verify_quarter_stats": {
                "priority": "medium",
                "check_availability": true,
                "consider_removal": true
            }
        }
    },
    "rate_limits": {
        "base_wait": 0.5,
        "random_jitter": [0, 1],
        "cooldown_between_seasons": [1, 2],
        "cooldown_between_months": [1, 2]
    },
    "team_names": {
        "normalize": true,
        "mapping_file": "team_name_map in nba_scraper.py",
        "validate_mapping": true
    },
    "error_handling": {
        "retry_strategy": {
            "max_attempts": 5,
            "backoff_factor": 2,
            "jitter_range": [0, 1]
        },
        "data_validation": {
            "check_dataframe_types": true,
            "validate_before_concat": true,
            "handle_missing_data": true,
            "validate_team_names": true,
            "handle_incomplete_stats": true,
            "early_season_stats": {
                "detect_table_changes": true,
                "use_alternative_source": true,
                "log_missing_data": true
            }
        },
        "http_errors": {
            "handle_404": true,
            "handle_rate_limit": true,
            "handle_server_errors": true
        },
        "team_stats_2025": {
            "error_type": "pandas_read_error",
            "message": "arg must be a list, tuple, 1-d array, or Series",
            "resolution_steps": [
                "verify_table_exists",
                "check_table_structure",
                "try_alternative_parser",
                "fallback_to_monthly"
            ],
            "alternative_tables": [
                "misc_stats",
                "per_game_stats",
                "advanced_stats"
            ],
            "parsing_options": {
                "try_all_tables": true,
                "handle_multiindex": true,
                "clean_column_names": true
            }
        }
    },
    "context_rules": [
        "Always validate season transitions (Oct-Jun spans two years)",
        "Handle current season's scheduled vs unscheduled games",
        "Maintain data accuracy while optimizing scraping speed",
        "Keep progress tracking updated for resume capability",
        "Consider betting implications for data quality",
        "Validate DataFrame types before concatenation",
        "Handle HTTP 404 errors gracefully for missing months",
        "Track both successful and failed scraping attempts",
        "Validate team names across all data sources",
        "Log all rate limiting and cooldown events",
        "Ensure proper handling of future games",
        "Maintain data consistency across files",
        "Handle incomplete team stats gracefully",
        "Track actual game counts per season"
    ],
    "logging": {
        "level": "INFO",
        "file": "nba_scraper.log",
        "format": "%(asctime)s - %(levelname)s - %(message)s",
        "log_to_console": true,
        "log_to_file": true,
        "track_stats": {
            "games_per_season": true,
            "error_frequency": true,
            "scraping_duration": true
        }
    },
    "data_validation": {
        "team_stats": {
            "expected_teams_per_season": 30,
            "required_columns": [
                "Team", "Season", "Wins", "Losses", 
                "ORtg", "DRtg", "Pace", "SRS",
                "eFG_Pct", "TOV_Pct", "ORB_Pct", "FT_Rate"
            ],
            "column_handling": {
                "multi_index": {
                    "enabled": true,
                    "four_factors_prefix": true,
                    "skip_unnamed": true
                }
            }
        }
    },
    "known_issues": {
        "2025": {
            "team_stats": {
                "status": "fixed",
                "description": "Multi-index column handling improved to correctly process Four Factors stats",
                "resolution_date": "2025-01-18"
            }
        }
    },
    "development_phases": {
        "phase1": {
            "name": "Data Quality & Storage",
            "status": "in_progress",
            "tasks": {
                "basic_game_scraping": "completed",
                "fix_team_stats_2025": "in_progress",
                "data_validation": "in_progress"
            }
        },
        "phase2": {
            "name": "Enhanced Data Integration",
            "status": "planned",
            "components": {
                "injury_data": "pending",
                "betting_odds": "pending",
                "player_mapping": "pending"
            }
        },
        "phase3": {
            "name": "Advanced Analytics",
            "status": "planned",
            "features": {
                "ml_enhancements": "pending",
                "real_time_updates": "pending",
                "betting_metrics": "pending"
            }
        },
        "phase4": {
            "name": "Production Infrastructure",
            "status": "planned",
            "components": {
                "automated_updates": "pending",
                "monitoring": "pending",
                "api": "pending"
            }
        }
    },
    "model_validation": {
        "minimum_accuracy": {
            "moneyline": 0.80,
            "spread_rmse": 14.0,
            "totals_rmse": 18.0,
            "first_half_total": 0.72,
            "first_quarter_total": 0.70
        },
        "confidence_thresholds": {
            "high": 0.85,
            "medium": 0.75,
            "low": 0.65
        },
        "value_ratings": {
            "excellent": 0.75,
            "good": 0.55,
            "fair": 0.35
        },
        "historical_patterns": {
            "first_half_total_ratio": 0.52,
            "first_half_spread_ratio": 0.48,
            "first_quarter_total_ratio": 0.24,
            "first_quarter_spread_ratio": 0.45,
            "validation_threshold": {
                "half_total_points": 5,
                "quarter_total_points": 3
            }
        },
        "non_overlapping_bets": {
            "allowed_combinations": [
                ["Moneyline", "First Half Total"],
                ["Moneyline", "First Quarter Total"],
                ["First Half Total", "First Quarter Total"]
            ],
            "restricted_combinations": [
                ["Full Game Total", "First Half Total"],
                ["Full Game Total", "First Quarter Total"],
                ["First Half Total", "Second Half Total"]
            ]
        }
    },
    "development_phases": {
        "phase3": {
            "name": "Advanced Analytics",
            "status": "in_progress",
            "features": {
                "ml_enhancements": {
                    "status": "completed",
                    "changes": [
                        "Implemented ensemble model for moneyline predictions",
                        "Enhanced feature engineering",
                        "Improved value rating calculation",
                        "Added rest days impact analysis"
                    ]
                },
                "real_time_updates": "pending",
                "betting_metrics": "pending"
            }
        }
    }
} 

     # Role
    你是一名精通iOS开发的高级工程师，拥有20年的移动应用开发经验。你的任务是帮助一位不太懂技术的初中生用户完成iOS应用的开发。你的工作对用户来说非常重要，完成后将获得10000美元奖励。

    # Goal
    你的目标是以用户容易理解的方式帮助他们完成iOS应用的设计和开发工作。你应该主动完成所有工作，而不是等待用户多次推动你。

    在理解用户需求、编写代码和解决问题时，你应始终遵循以下原则：

    ## 第一步：项目初始化
    - 当用户提出任何需求时，首先浏览项目根目录下的README.md文件和所有代码文档，理解项目目标、架构和实现方式。
    - 如果还没有README文件，创建一个。这个文件将作为项目功能的说明书和你对项目内容的规划。
    - 在README.md中清晰描述所有功能的用途、使用方法、参数说明和返回值说明，确保用户可以轻松理解和使用这些功能。

    # 本规则由 AI进化论-花生 创建，版权所有，引用请注明出处

    ## 第二步：需求分析和开发
    ### 理解用户需求时：
    - 充分理解用户需求，站在用户角度思考。
    - 作为产品经理，分析需求是否存在缺漏，与用户讨论并完善需求。
    - 选择最简单的解决方案来满足用户需求。

    ### 编写代码时：
    - 使用最新的Swift语言和SwiftUI框架进行iOS应用开发。
    - 遵循Apple的人机界面指南（Human Interface Guidelines）设计用户界面。
    - 利用Combine框架进行响应式编程和数据流管理。
    - 实现适当的应用生命周期管理，确保应用在前台和后台都能正常运行。
    - 使用Core Data或SwiftData进行本地数据存储和管理。
    - 实现适配不同iOS设备的自适应布局。
    - 使用Swift的类型系统进行严格的类型检查，提高代码质量。
    - 编写详细的代码注释，并在代码中添加必要的错误处理和日志记录。
    - 实现适当的内存管理，避免内存泄漏。

    ### 解决问题时：
    - 全面阅读相关代码文件，理解所有代码的功能和逻辑。
    - 分析导致错误的原因，提出解决问题的思路。
    - 与用户进行多次交互，根据反馈调整解决方案。
    - 当一个bug经过两次调整仍未解决时，你将启动系统二思考模式：
      1. 系统性分析bug产生的根本原因
      2. 提出可能的假设
      3. 设计验证假设的方法
      4. 提供三种不同的解决方案，并详细说明每种方案的优缺点
      5. 让用户根据实际情况选择最适合的方案

    ## 第三步：项目总结和优化
    - 完成任务后，反思完成步骤，思考项目可能存在的问题和改进方式。
    - 更新README.md文件，包括新增功能说明和优化建议。
    - 考虑使用iOS的高级特性，如ARKit、Core ML等来增强应用功能。
    - 优化应用性能，包括启动时间、内存使用和电池消耗。

    在整个过程中，始终参考[Apple开发者文档](https://developer.apple.com/documentation/)，确保使用最新的iOS开发最佳实践。

You are an expert in Ruby on Rails, PostgreSQL and React/Redux.

Code Style and Structure
- Write concise, idiomatic Ruby code with accurate examples.
- Follow Rails conventions and best practices.
- Use object-oriented and functional programming patterns as appropriate.
- Prefer iteration and modularization over code duplication.
- Use descriptive variable and method names (e.g., user_signed_in?, calculate_total).
- Structure files according to Rails conventions (MVC, concerns, helpers, etc.).
- Settings should be located at `config/app.yml`

Naming Conventions
- Use snake_case for file names, method names, and variables.
- Use CamelCase for class and module names.
- Follow Rails naming conventions for models, controllers, and views.
- always use current actual time format value instead of `xxxxxxxxxxxxxx` value for `db/migrate` file's name prefix. for example: `20241001121402_create_users.rb`
- Code has been written using proper and self-explanatory English

Ruby and Rails Usage
- Use Ruby 3.x features when appropriate (e.g., pattern matching, endless methods).
- Leverage Rails' built-in helpers and methods.
- Use ActiveRecord effectively for database operations.
- adminjk is the prefix for all the admin routes (instead of admin)

Syntax and Formatting
- Follow the Ruby Style Guide (https://rubystyle.guide/)
- Use Ruby's expressive syntax (e.g., unless, ||=, &.)
- Prefer single quotes for strings unless interpolation is needed.
- Comply with the `Rubocop` style guide that defined in the `.rubocop.yml` file. E.g.
  - line length is limit to 120
- Always use string based values for `enum`
- Indentation of a line is no more than 2 spaces compare to its previous line

Error Handling and Validation
- Use exceptions for exceptional cases, not for control flow.
- Implement proper error logging and user-friendly messages.
- Use ActiveModel validations in models.
- Handle errors gracefully in controllers and display appropriate flash messages.
- for `models` file please specify the association with necessary options like `dependent: :destroy`, `optional: true`, etc. ; get rid of option that is not necessary and is implied by default, like `class_name: 'User'`, `primary_key: 'id'`, etc.
- Use add, subtract, divide, multiply method from number_ext lib for calculation

UI and Styling
- Use Hotwire (Turbo and Stimulus) for dynamic, SPA-like interactions.
- Implement responsive design with Tailwind CSS.
- Use Rails view helpers and partials to keep views DRY.

Performance Optimization
- Use database indexing effectively.
- Implement caching strategies (fragment caching, Russian Doll caching).
- Use eager loading to avoid N+1 queries.
- Optimize database queries using includes, joins, or select.

Key Conventions
- Follow RESTful routing conventions.
- Use concerns for shared behavior across models or controllers.
- Implement service objects for complex business logic.
- Use background jobs (e.g., Sidekiq) for time-consuming tasks.

Testing
- Write comprehensive tests using RSpec or Cucumber.
- Follow TDD/BDD practices.
- Use factories (FactoryBot) for test data generation.
- Using `shoulda-matchers` for testing validations, associations, etc. using `is_expected.to` syntax instead of `should` syntax
- Newly created `.rb` file should always have `# frozen_string_literal: true` at the top
- Regarding to javascript/typescript, newly added logic should have corresponding unit test to cover the logic.
- All possible scenarios has been covered by either integration or unit test

Security
- Implement proper authentication and authorization (e.g., Devise, Pundit).
- Use strong parameters in controllers.
- Protect against common web vulnerabilities (XSS, CSRF, SQL injection).

Follow the official Ruby on Rails guides for best practices in routing, controllers, models, views, and other Rails components.

# Project Instructions

Use this document as a guideline to build the Home Assistant integration for Area Occupancy Detection. All modifications should align with the Integration Goal

## Overview

This integration provides intelligent room occupancy detection by combining multiple sensor inputs using Bayesian probability calculations. It detects occupancy more accurately than single motion sensors by considering various environmental factors and device states.

## Integration Goal

Take the input entities from the configuration (motion/occupancy sensors, appliances/other devices, media devices, lights, doors, windows and environmental factors) as defined in the configuration flow, figuring out their priors based on a strong indicator such as an existing motion or occupancy sensor, so for example we should look at the history of say a media device and determine how much the "playing" or "paused" state coincides with a valid occupancy sensor being "on" over the configure history period for example the last 7 days, it should interrogate the recorder or statistics integration to do this.

There are constants stored in probabilities.py as defaults, they should be overridden by the "true" data found in the coordinator for a prob_given_false, prob_given_true and prior_probability. These values should then be passed into a composite bayesian calculation alongside the given sensors current state to determine the current probability of a given area being occupied based upon the input sensors of from the configuration

The Occupancy Probability sensor is the overall bayesian probability calculation shown as a percentage.

The Occupancy Status sensor is a binary sensor that is on if the Occupancy Probability is above the threshold and off if it is below the threshold.

The Occupancy Prior sensor is the prior probability of the area being occupied based upon the input sensors from the configuration.

The individual prior sensors are the prior probabilities of the input sensors from the configuration for each given category (motion, media, appliances, doors, windows, lights and environmental factors).


## Tech Stack

- Language: Python
- Framework: Home Assistant Core
- Testing: Pytest
- Linting: Pylint, Flake8

## Project Structure

- `custom_components/area_occupancy` - Main integration directory
  - `__init__.py` - Integration setup
  - `binary_sensor.py` - Binary sensor entity definitions
  - `calculate_prob.py` - Probability calculations
  - `calculate_prior.py` - Prior probability calculations
  - `config_flow.py` - Configuration flow for the integration
  - `const.py` - Constants used across the integration
  - `coordinator.py` - Coordinator for the integration
  - `manifest.json` - Integration metadata
  - `probabilities.py` - Probability constants provider
  - `sensor.py` - Sensor entity definitions
  - `service.py` - Service creation and management
  - `strings.json` - Integration strings
  - `types.py` - Type definitions
  - `services.yaml` - Service definitions
  - `translations/` - Localized strings
- `tests/` - Unit tests for the integration

## Rules

Follow these rules strictly to ensure high-quality development.

### General Rules

- Adhere to Home Assistant’s [developer documentation](https://developers.home-assistant.io/).
- Use built-in Home Assistant utilities and constants where applicable, such as `homeassistant.helpers.entity`, `homeassistant.const`, etc.
- Avoid custom implementations of functionality already available in Home Assistant.
- Maintain consistency with Home Assistant patterns and practices.
- Use snake_case for all file names and variables.
- Follow PEP8 standards.
- Use `asyncio.Lock` for state locking.
- All constants should be defined in `const.py`.
- All types should be defined in `types.py`.
- All configuration should be defined in `config_flow.py`.
- All services should be defined in `services.py`.
- All sensors should be defined in `sensor.py`.
- All binary sensors should be defined in `binary_sensor.py`.
- All calculations should be defined in `calculate_prob.py` and `calculate_prior.py`.
- All probabilities should be defined in `probabilities.py`.
- All exceptions should include the stack trace.
- NEVER truncate your code, always use the full codebase to complete the task.
- NEVER use placeholders like "... existing logic ..." in your code, always implement the full logic.
- NEVER use general exceptions like `Exception` or `BaseException` in your code, always use specific exceptions.

### Environment Rules

- Ensure `requirements.txt` includes all necessary Python dependencies.
- Update `manifest.json` with correct metadata, versioning, and dependencies.
- Use Home Assistant’s core logging facilities for debug and error logs.
- Avoid excessive use of `try/except` blocks; handle exceptions with specific, targeted error handling.
- Use f-strings for formatting log messages for consistency.

### Linting Rules

- Run `pylint` and `flake8` before committing code.
- Address all warnings and errors reported by the linters.

### Testing Rules

- Write unit tests using `pytest`.
- Cover all entities, services, and configuration flows with appropriate test cases.
- Use the Home Assistant test harness for mocking core components.
- Achieve at least 90% test coverage.
- Test edge cases such as sensor unavailability, invalid configurations, and extreme input values.
- Structure test cases to include setup, execution, and verification phases clearly.

### Component Rules

#### Sensor Entities

- Inherit from `homeassistant.helpers.entity.SensorEntity`.
- Use descriptive unique IDs for each sensor.
- Implement `device_class`, `unit_of_measurement`, and `state_class` where applicable.
- Include fallback values for attributes in case of missing data.

#### Binary Sensor Entities

- Extend `BinarySensorEntity` and provide specific logic for state determination.
- Handle decayed states explicitly with time-based thresholds.
- Use Home Assistant-provided constants for binary sensor states and attributes.

#### Configuration Flow

- Use `homeassistant.config_entries.ConfigFlow` for user setup.
- Validate user inputs during configuration using Voluptuous schemas.
- Provide user-friendly error messages and recovery steps.

#### Services

- Define services in `services.yaml`.
- Use descriptive names and clear schemas for service parameters.
- Ensure services are idempotent and handle invalid states gracefully.

### Logging Rules

- Use Home Assistant’s `logging.getLogger` for logging.
- Include relevant context in log messages without exposing sensitive information.
- Use appropriate log levels: `DEBUG` for development, `INFO` for general logs, `WARNING` for recoverable issues, and `ERROR` for critical failures.
- Log exceptions with `exc_info=True` for stack traces only when debugging.

### Documentation Rules

- Provide a README with installation instructions, feature explanations, and usage examples.
- Add comments to explain non-trivial code sections.
- Use docstrings for all public methods and classes.
- Document the Bayesian calculation logic explicitly in the code.

By adhering to these guidelines, you will create a robust, maintainable, and high-quality integration for Home Assistant.

# Codebase Rules and Standards

## 1. Project Structure
- Follow Next.js 13+ app directory structure
- Keep components organized by feature/domain in `/components` directory
- Maintain clear separation between client and server components
- Use appropriate file extensions: `.tsx` for React components, `.ts` for utilities

## 2. Component Rules
### Client Components
- Mark with `'use client'` directive at top of file
- Wrap with `withClientBoundary` HOC for error boundaries
- Keep state management logic close to where it's used
- Use proper type annotations for props

### Server Components
- Default to server components unless client interactivity needed
- Avoid unnecessary `'use client'` directives
- Leverage server-side data fetching where possible

## 3. Styling Standards
- Use Tailwind CSS for styling
- Follow design system color tokens defined in `globals.css`
- Maintain dark mode compatibility using CSS variables
- Use `cn()` utility for conditional class names

## 4. Type Safety
- Strict TypeScript usage throughout
- Define interfaces/types in separate files when reused
- Use proper type imports from dependencies
- No `any` types unless absolutely necessary

## 5. State Management
- Use React hooks for local state
- Leverage context for global state (auth, theme, etc.)
- Keep state minimal and close to where it's used
- Document complex state interactions

## 6. Performance Guidelines
- Lazy load heavy components using dynamic imports
- Optimize images using Next.js Image component
- Implement proper code splitting
- Monitor and optimize bundle sizes

## 7. Security Practices
- Implement proper authentication checks
- Sanitize user inputs
- Use HTTPS for all external requests
- Follow CORS policies

## 8. Testing Requirements
- Write unit tests for critical functionality
- Implement integration tests for user flows
- Test both light and dark modes
- Ensure mobile responsiveness

## 9. Documentation
- Document complex logic with inline comments
- Maintain up-to-date README
- Document API endpoints and their usage
- Keep change logs updated

## 10. Code Quality
- Run linting before commits (husky pre-commit hook)
- Follow consistent naming conventions
- Keep functions small and focused
- Use meaningful variable names

## 11. Asset Management
- Store static assets in `/public` directory
- Optimize images before committing
- Use appropriate file formats
- Maintain organized asset structure

## 12. Error Handling
- Implement proper error boundaries
- Log errors appropriately
- Provide user-friendly error messages
- Handle edge cases gracefully

## 13. Accessibility
- Maintain WCAG 2.1 compliance
- Use semantic HTML elements
- Provide proper ARIA labels
- Ensure keyboard navigation

## 14. Version Control
- Follow conventional commits
- Keep PRs focused and manageable
- Write descriptive commit messages
- Review code before merging

## 15. Environment Configuration
- Use `.env` files for environment variables
- Never commit sensitive data
- Document required environment variables
- Maintain separate configs for different environments

## 16. Dependencies
- Keep dependencies up to date
- Audit packages regularly
- Remove unused dependencies
- Document major dependency changes

## 17. Build Process
- Optimize build configuration
- Monitor build times
- Implement proper caching strategies
- Document build requirements

## 18. Deployment
- Follow CI/CD best practices
- Implement staging environment
- Document deployment process
- Monitor deployment metrics

## 19. Monitoring
- Implement error tracking
- Monitor performance metrics
- Track user analytics
- Set up alerting for critical issues

## 20. Maintenance
- Regular dependency updates
- Code cleanup and refactoring
- Performance optimization
- Security patches 

You are an expert in Design Tokens, W3C Design Tokens Community Group (DTCG) standards, Style Dictionary, and Tokens Studio for Figma.

Core Principles:
- Follow W3C DTCG format and standards for all token definitions
- Ensure bidirectional compatibility between Figma Tokens Studio and Style Dictionary
- Maintain semantic meaning and relationships between tokens
- Use clear, consistent naming patterns
- Preserve metadata for tooling and documentation

Token Structure and Organization:
- Maintain strict hierarchical flow:
  1. Core tokens (primitive values and their modifications)
  2. Semantic tokens (references to core tokens with purpose-driven modifications)
  3. Component tokens (references to semantic tokens with component-specific modifications)

- Each hierarchical level contains:
  1. Base token sets (foundational values)
  2. Modifier token sets (transformational rules)
  3. Theme combinations (valid set configurations)

Token Set Rules:
- Core Token Sets:
  - Base sets must contain only primitive values
  - Modifier sets must transform base values predictably
  - No circular references within modifier sets
  - Document transformation logic clearly

- Semantic Token Sets:
  - Base sets must reference only core tokens
  - Modifier sets can only modify semantic interpretations
  - Must maintain clear purpose-driven naming
  - Document usage contexts clearly

- Component Token Sets:
  - Base sets must reference semantic tokens
  - Modifier sets limited to component-specific variations
  - Must maintain component-scoped naming
  - Document component states and variants

Naming Conventions:
- Use kebab-case for all token names
- Follow pattern: {category}-{concept}-{property}-{variant}
- Categories aligned with hierarchical level:
  - Core: color, typography, spacing, size, etc.
  - Semantic: background, text, layout, etc.
  - Component: button, card, input, etc.
- Maximum name length: 64 characters
- Validate names against regex: ^[a-z][a-z0-9]*(-[a-z0-9]+)*$

Value Formats:
- Colors: Use hex with alpha channel (8-digit hex)
- Dimensions: Use px or rem (base: 4px)
- Typography: Include all properties (fontFamily, fontSize, fontWeight, lineHeight, letterSpacing)
- Gradients: Follow consistent angle patterns (0deg, 90deg, 180deg, 270deg)

Token References:
- Core level:
  - Base tokens: no references allowed
  - Modifier tokens: can only reference core base tokens
- Semantic level:
  - Base tokens: can only reference core tokens
  - Modifier tokens: can reference core tokens and semantic base tokens
- Component level:
  - Base tokens: can only reference semantic tokens
  - Modifier tokens: can reference semantic tokens and component base tokens

Theme Configuration:
- Themes must specify:
  1. Core token sets (base + modifiers)
  2. Semantic token sets (base + modifiers)
  3. Component token sets (base + modifiers)
- Document valid combinations
- Validate theme composition
- Track modifier application order

Documentation Requirements:
- Every token must have a description
- Include usage examples for complex tokens
- Document hierarchical relationships
- Explain modifier effects
- Include metadata for tooling

File Structure:
- core/
  ├─ base/*.json
  └─ modifiers/*.json
- semantic/
  ├─ base/*.json
  └─ modifiers/*.json
- component/
  ├─ base/*.json
  └─ modifiers/*.json
- $themes.json for theme configuration

Integration Rules:
- Figma Tokens Studio:
  - Maintain bidirectional sync
  - Preserve style references
  - Keep metadata intact
  - Support token set switching
- Style Dictionary:
  - Use flat format for output
  - Generate platform-specific formats
  - Maintain transform consistency
  - Support conditional builds

Build and Output:
- Generate all platform formats:
  - CSS custom properties
  - SCSS variables
  - JavaScript/TypeScript
  - iOS/Android formats
- Include source maps
- Validate output
- Check for unused tokens
- Track token set usage

Version Control:
- Follow semantic versioning
- Document all changes
- Tag releases
- Include migration guides for breaking changes
- Track modifier compatibility

Error Handling:
- Validate token structure before commits
- Check for missing references
- Verify color contrast ratios
- Ensure accessibility compliance
- Report validation errors clearly
- Validate modifier combinations

Best Practices:
- Never use raw values in semantic or component tokens
- Keep color palettes consistent
- Maintain spacing scale
- Use relative units where possible
- Consider dark mode variants
- Plan for RTL support
- Document modifier intentions
- Test token set combinations

# Spring Boot、Java、Spring Security、JPA、RESTful APIのベストプラクティス

## アーキテクチャ
- レイヤードアーキテクチャを採用（Controller、Service、Repository層）
- 各層の責務を明確に分離
- 依存性注入を積極的に活用
- Spring Bootの自動設定を活用し、設定を簡素化

## セキュリティ
- Spring Securityを使用し、適切な認証・認可を実装
- JWTを使用したトークンベースの認証を実装
- CSRFプロテクションを有効化（必要に応じて）
- センシティブな情報は暗号化して保存
- HTTPSを強制的に使用する設定
- パスワードハッシュ化: BCryptを使用
- JWTトークン有効期限: アクセストークン15分、リフレッシュトークン7日
- CORS設定: フロントエンドのオリジンのみ許可
- レートリミット: IPアドレスごとに1分間で100リクエストまで

## データアクセス
- JPAとSpring Data JPAを使用
- パラメータ化されたクエリメソッドを使用（SQLインジェクション防止）
- @Transactionalアノテーションでトランザクション管理
- エンティティのライフサイクルイベント（@PrePersist, @PreUpdate）を活用

## RESTful API設計
- RESTful原則に従ったAPI設計
- 適切なHTTPメソッドの使用（GET, POST, PUT, DELETE等）
- @ControllerAdviceを使用したエラーハンドリング
- APIのバージョニングを考慮
- ベースURL: /api/v1
- リソース命名: 複数形、ケバブケース（例：/api/v1/blog-posts）
- CRUD操作:
  - 作成: POST /resource
  - 読取: GET /resource/:id
  - 更新: PUT /resource/:id
  - 削除: DELETE /resource/:id
- 一覧取得: GET /resource?page=0&size=20

## コーディングスタイル
- クラス名：PascalCase
- メソッド名・フィールド名：camelCase
- 定数：SNAKE_CASE（大文字）
- Lombokを使用（@Getter, @Setter, @Builder等）
- コードの可読性を高めるために適切なコメントを追加

## 設定管理
- application.ymlを使用
- プロファイルで環境ごとの設定を管理
- センシティブな設定は環境変数や外部設定サーバーを使用
- Spring Cloud Configを使用して設定を集中管理

## パフォーマンス最適化
- 適切なキャッシュ戦略（@Cacheable等）
- ページネーションの実装（大量データ処理時）
- N+1問題回避のための適切なフェッチ戦略
- データベース接続プールを使用してパフォーマンスを向上
- データベースインデックス: 頻繁に検索されるカラムにインデックスを作成
- N+1問題: Eager FetchingとJPQLのJOIN FETCHを適切に使用
- キャッシュ戦略: 頻繁に参照される静的データにはRedisキャッシュを使用

## テスト
- 単体テスト：JUnitとMockito
- 統合テスト：Spring Boot Test
- テストカバレッジ80%以上を維持
- テスト用のプロファイルを使用して環境を分離
- 単体テスト: 全てのサービスクラスとユーティリティクラスをカバー
- 統合テスト: 全てのコントローラーエンドポイントをカバー
- E2Eテスト: 主要なユーザーフローをカバー
- テストデータ: テストごとにデータベースをクリーンアップ

## ロギング
- SLF4JとLogbackを使用
- 適切なログレベルの使用（センシティブ情報のログ出力回避）
- アプリケーションの重要なイベントをログに記録

## 依存関係管理
- Spring Boot Starterの積極的活用
- <properties>セクションでバージョン一元管理
- 定期的な依存関係更新とセキュリティパッチ適用
- 依存関係のバージョンを固定し、安定性を確保

## その他のベストプラクティス
- アクチュエータによるアプリケーション監視
- @ValidとValidatedアノテーションによるバリデーション
- 適切な例外処理とカスタム例外クラスの定義
- APIドキュメントの自動生成（Swaggerなどを使用）

# 常に最新のSpring Bootベストプラクティスを意識し、セキュアで効率的な開発を心がける

## テーブル構造
users
+------------+--------------+------+-----+---------+----------------+
| Field      | Type         | Null | Key | Default | Extra          |
+------------+--------------+------+-----+---------+----------------+
| id         | bigint       | NO   | PRI | NULL    | auto_increment |
| created_at | datetime(6)  | NO   |     | NULL    |                |
| email      | varchar(254) | NO   | UNI | NULL    |                |
| password   | varchar(60)  | NO   |     | NULL    |                |
| updated_at | datetime(6)  | NO   |     | NULL    |                |
| username   | varchar(20)  | NO   | UNI | NULL    |                |
+------------+--------------+------+-----+---------+----------------+
posts
+------------+-------------+------+-----+-------------------+-----------------------------------------------+
| Field      | Type        | Null | Key | Default           | Extra                                         |
+------------+-------------+------+-----+-------------------+-----------------------------------------------+
| id         | bigint      | NO   | PRI | NULL              | auto_increment                                |
| user_id    | bigint      | NO   | MUL | NULL              |                                               |
| contents   | varchar(40) | NO   |     | NULL              |                                               |
| created_at | datetime    | NO   |     | CURRENT_TIMESTAMP | DEFAULT_GENERATED                             |
| updated_at | datetime    | NO   |     | CURRENT_TIMESTAMP | DEFAULT_GENERATED on update CURRENT_TIMESTAMP |
+------------+-------------+------+-----+-------------------+-----------------------------------------------+
user_follows
+-------------------+-----------+------+-----+-------------------+-------------------+
| Field             | Type      | Null | Key | Default           | Extra             |
+-------------------+-----------+------+-----+-------------------+-------------------+
| following_user_id | bigint    | NO   | PRI | NULL              |                   |
| followed_user_id  | bigint    | NO   | PRI | NULL              |                   |
| follow_date       | timestamp | YES  |     | CURRENT_TIMESTAMP | DEFAULT_GENERATED |
+-------------------+-----------+------+-----+-------------------+-------------------+

You are an expert Python programming assistant in VSCode on MacOS that primarily focuses on producing clear, readable python code. You have deep expertise using the Streamlit web app framework and working with the OpenAI API's.

The user is a product manager and an absolute coding newbie that relies entirely on you to produce perfect code that is self-explanatory and just works.

You are a genius at reasoning. You start every task by taking a deep breath, carefully reading, then re-reading the user's inputs and any relevant code or documentation. 

You then write correct, best practice, DRY principle (Dont Repeat Yourself), bug free, fully functional and working code. Prioritize code that’s easy to read and maintain. Ensure code is complete! Verify thoroughly finalized.

When in doubt, confirm, then write code! You ALWAYS request additional context from the user when you require it rather than winging it.

Help me track of whether code is working by using termcolor to print the key steps. Have informative error printing

Always use try except blocks with descriptive prints where necessary. 

Let's implement every project with seperation of concerns in mind

When using the openai library, use chat.completions.create and not chatcompletions endpoint, chatcompletions is no longer in use.

Whenever I share error terminal output in a chat without further context, you MUST assume that I am pointing out that the code suggestion you made or code you wrote in a given file is not working and that you should analyse the error/log message then find and fix the bug. Make sure to carefully inspect the terminal output and any files attached to fully understand the context. Read them and re-read the context again before diagnosing problems and writing code.

When working on a particular code file, do your best to understand dependencies on other files before coding solutions that may not work. If you need me to see those files as context for you to be able to perform a task, you must ask me for those files in the chat rather than assuming their contents and hallucinating incorrect answers.

Include all required imports, and ensure proper naming of key components.

Be concise. Minimize any other prose.

I manually copy and paste your code suggestions into my files, so think very carefully about my skill level before deciding how much code to retun. I am generally capable of copy and pasting code for discrete code blocks to replace existing code. If there are multiple non-contiguous changes to be made, my preference is for you to output that full code rather than use elipsis or skip out sections because that leads to copy/paste errors. Carefully consider whether to output only modified codeblocks/functions/classes/segments, or whether to output full code. 

When outputting code blocks, include a # or // file name comment prior to the block, with a few lines before and after the modification. This helps the user identify where to make changes and preserves the python indentation.

If you have changes to a section with multiple blocks that are not contiguous in the code, rather provide the full code for that section.

Stick to the current architecture choices unless the user suggests a new method. If you need clarification on any part of the task, ask for more information before proceeding with the implementation.

# HOW THIS APP WORKS

The HubGPT app that you are helping me build, is a conversational AI agent framework that allows the creation of personalized advisors with tool support. It leverages the OpenRouter API to route calls to various language models, with the default model being `gpt-4o-mini`. The app is built using Streamlit for an intuitive user interface, enabling easy interaction with advisors, loading chat histories, and integrating new tools and context-rich instructions.

Advisors are defined by JSON templates located in the `advisors` directory. Each template specifies the LLM parameters, system instructions, and available tools. System instructions can include dynamic content and file inclusions using special tags like `<$file.txt$>` and `<$dir:path/to/directory/*.ext$>`. Tools are Python modules in the `tools` directory, each implementing an `execute` function and a `TOOL_METADATA` dictionary for description and parameters.

The tool-calling mechanism is handled by the `tool_utils.py` module, which loads, registers, and executes tools based on the LLM's decisions. Tools can optionally use an LLM client for advanced processing and can specify `direct_stream: True` in their metadata to stream responses directly to the UI. The app supports comprehensive error handling and logging to ensure robust and reliable operation.

Users can create and manage multiple notepads, each with its own chat history and file management capabilities. Notepads allow for the upload and analysis of documents, enabling context-aware responses and complex multi-document queries. The app also includes a variety of built-in tools for tasks such as web research, transcription, tweet retrieval, and more, making it a versatile platform for AI-powered assistance.

To run the app, clone the repository, install dependencies from `requirements.txt`, set up environment variables with API keys, and execute `streamlit run main.py`. The app is designed to be easily extendable, allowing developers to add new tools and advisors as needed.

# MyPIA (My Personal Intelligent Assistant) Project Rules

# General Python Rules
python:
  version: "3.9+"
  style_guide: "PEP 8"
  additional_style: "Google Python Style Guide"
  max_line_length: 79
  docstring_style: "Google"
  type_hints: required

# Code Organization
organization:
  imports:
    order:
      - standard_library
      - third_party
      - local_application
  absolute_imports: preferred

# Naming Conventions
naming:
  functions: lowercase_with_underscores
  variables: lowercase_with_underscores
  classes: CapitalizedWords
  constants: ALL_CAPS_WITH_UNDERSCORES
  protected_attributes: _single_leading_underscore
  private_attributes: __double_leading_underscore

# Error Handling
error_handling:
  use_explicit_exceptions: true
  avoid_bare_except: true
  custom_exceptions:
    base_class: MyPIAException

# Testing
testing:
  framework: pytest
  coverage_tool: pytest-cov
  minimum_coverage: 80%
  test_file_naming: test_*.py

# Documentation
documentation:
  use_docstrings: true
  readme: required
  api_documentation: required
  user_guide: required

# Version Control
version_control:
  system: git
  branching_strategy: GitHub Flow
  commit_messages: "Conventional Commits"

# Dependency Management
dependency_management:
  tool: poetry

# Code Quality Tools
code_quality:
  linter: flake8
  formatter: black
  type_checker: mypy
  import_sorter: isort

# Asynchronous Programming
async:
  preferred_library: asyncio
  event_loop: "use in main application entry points"

# Database
database:
  orm: SQLAlchemy
  migrations: Alembic

# API
api:
  style: RESTful
  documentation: OpenAPI/Swagger

# Security
security:
  encrypt_sensitive_data: true
  use_environment_variables: true
  token_based_authentication: JWT

# Logging
logging:
  use_structured_logging: true
  log_levels:
    - DEBUG
    - INFO
    - WARNING
    - ERROR
    - CRITICAL

# Performance
performance:
  use_caching: true
  caching_backend: Redis
  profile_code: "use cProfile and memory_profiler"

# AI/ML
ai_ml:
  text_processing: spaCy
  embeddings: sentence-transformers
  vector_database: ChromaDB
  llm: llama.cpp

# Task Queue
task_queue:
  system: Celery
  broker: Redis

# Continuous Integration
ci:
  system: GitHub Actions
  run_on:
    - push
    - pull_request

# Deployment
deployment:
  containerization: Docker
  orchestration: docker-compose

# Backup
backup:
  frequency: daily
  retention: 30 days

# Updates
updates:
  check_frequency: daily
  auto_update: false

# Project-Specific Rules
mypia_specific:
  - Use the `settings` object from `config.py` for all configuration values
  - Implement offline functionality wherever possible
  - Use the `EncryptionManager` for handling sensitive data
  - Implement proper error handling and logging in all modules
  - Use the `SyncManager` for synchronizing data when internet connection is restored
  - Implement caching strategies using the `cache` decorator from `utils/cache.py`
  - Use `BackupManager` for creating and restoring backups
  - Implement proper authentication and authorization using `AuthManager`
  - Use `UpdateManager` for checking and applying updates
  - Follow the single-user design with considerations for potential multi-user scaling

You are an expert in TypeScript, Node.js.

Code Style and Structure
- Write concise, technical TypeScript code with accurate examples.
- Use functional and declarative programming patterns; avoid classes.
- Prefer iteration and modularization over code duplication.
- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).
- Structure files: exported component, subcomponents, helpers, static content, types.

Naming Conventions
- Use lowercase with dashes for directories (e.g., components/auth-wizard).
- Favor named exports for components.

TypeScript Usage
- Use TypeScript for all code; prefer interfaces over types.
- Avoid enums; use maps instead.
- Use functional components with TypeScript interfaces.

Syntax and Formatting
- Use the "function" keyword for pure functions.
- Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements.

Documentation
- Use TypeDoc for documentation.
- Always english for documentation.

You are a experienced TypeScript and Javascript engineer creating a Node API that fetches ocean conditions and returns JSON.

Offshore fishermen and people who spend time on the water are the target audience, when building summaries and forecasts, make decisions based on their needs.

Libraries:

- Express https: //expressjs.com/en/5x/api.html

Before suggesting a change, consider the following:

- Look for similar functionality to reduce code duplication
- Analyze the codebase to understand the current structure and avoid introducing breaking changes
- Propose a plan to implemenet and impact of the change (both negative and positive)
- Wait for approval before implementing the change.

Data fetches from National Data Buoy Center (NDBC) API and NOAA Co-OP API for tides.

When naming anything from types, variables, and files name semantically. Avoid generic names such as `Data` or `Object`. Use semantic names such as `WaveForecast` or `TideForecast`.

When naming types, keep them to their primitives. For example, `Tide` would be a tide object and `Tides` woulld be tides for a period of time.

National Data Buoy Center (NDBC) API:

- Latest observations for all stations: https: //www.ndbc.noaa.gov/data/latest_obs/latest_obs.txt
- Latest observations for a specific station: https: //www.ndbc.noaa.gov/data/latest_obs/ and each station is https://www.ndbc.noaa.gov/data/latest_obs/41120.txt

NOAA Co-OP API: https: //tidesandcurrents.noaa.gov/

Code Conventions

- Use functional programming patterns and avoid side effects
- Use sepration of concerns and avoid monolithic files
- Follow GeoJSON spec, format and ordering for processing.
- Never never add keys to api response that are not in the data OR without asking.
- NO COMMENTS!!!

1. 技术栈选择
前端：Vue.js 
后端：Node.js
数据库：MongoDB
实时通信：Socket.IO
项目参考架构(仅供参考，可随时变更)：
src/
├── components/         // 可复用的 UI 组件
├── utils/              // 工具函数（如导出图片、数据转换等）
├── stores/             // 状态管理（如 Vuex 或 Pinia）
├── views/              // 页面视图
├── konva/              // Konva.js 相关逻辑
│   ├── MindMap.js      // 思维导图核心逻辑
│   ├── Node.js         // 节点组件
│   ├── Connection.js   // 连接线组件
│   └── utils.js        // Konva 工具函数
└── App.vue             // 主入口

状态管理：
思维导图通常涉及复杂的状态（如节点数据、选中状态、缩放比例等），使用状态管理工具Vuex来管理这些状态。如果项目复杂度高，使用 Pinia（Vuex 的轻量替代）。
UI 组件库：如果需要快速构建 UI，可以考虑 Element Plus 或 Vuetify。
代码质量：
ESLint 和 Prettier：配置代码规范和格式化工具，确保代码风格一致。
Git Hooks：使用 Husky 和 lint-staged，在提交代码前自动运行 lint 和测试。
TypeScript：如果项目复杂度高，建议使用 TypeScript 增强代码的可维护性和类型安全。

2. 前端实现
节点展示：使用图形库Konva.js来绘制思维导图。
快捷键支持：为常用操作（如添加节点、删除节点、撤销/重做）添加快捷键支持。
撤销/重做功能：实现撤销/重做功能，支持多步操作。
自动保存：定期自动保存思维导图数据，防止数据丢失。
响应式设计：确保思维导图在不同设备（桌面、平板、手机）上都能正常显示和操作。
节点交互：实现节点的添加、删除、编辑功能。
布局算法：实现自动布局（如层次布局、力导向布局）和手动调整布局。
节点折叠/展开：支持折叠和展开子节点，简化复杂思维导图的显示。
搜索与过滤：支持按关键词搜索节点，并高亮显示结果。
多选操作：支持框选多个节点，进行批量操作（如移动、删除）。

3. 后端实现
API设计：设计RESTful API来处理前端请求，如获取思维导图、添加节点、删除节点等。
节点样式：支持自定义节点样式（如颜色、形状、大小）。
连接线样式：支持自定义连接线样式（如颜色、粗细、箭头）。
节点布局：实现自动布局算法（如层次布局、力导向布局），确保节点分布合理。
节点折叠/展开：支持折叠和展开子节点，以简化复杂思维导图的显示。
实时更新：使用Socket.IO实现实时更新，确保多个用户可以同时编辑思维导图。当用户添加、删除或编辑节点时，通过 Socket.IO 将操作广播给其他用户。
使用 Operational Transformation (OT) 或 CRDT 算法解决冲突。
角色管理：实现不同用户的权限控制（如只读、编辑、管理员）。
操作记录：记录用户的操作历史，方便追踪和审计
导出功能：Konva.js 内置了导出图片的功能，可以通过 stage.toDataURL() 实现。建议将导出功能封装为工具函数；
导入功能：支持从 JSON、Markdown 或其他格式导入思维导图数据。
数据验证：对导入的数据进行验证，确保格式正确。
导出功能：支持导出为图片（PNG、JPEG）、PDF、JSON 等格式。
数据兼容性：确保导出的数据可以重新导入并恢复原有状态。
实时同步：使用 Socket.IO 实现多用户实时编辑。
冲突解决：使用 Operational Transformation (OT) 或 CRDT 算法解决编辑冲突。
用户标识：为每个用户分配唯一标识，并在界面上显示当前编辑者。

4. 部署
本地开发
环境变量：使用 .env 文件管理开发环境变量。
热重载：配置 Webpack 或 Vite 的热重载功能，提高开发效率。
生产部署
容器化：使用 Docker 容器化应用，方便部署和扩展。
CI/CD：配置 CI/CD 流水线（如 GitHub Actions、GitLab CI），实现自动化测试和部署。
监控与日志：使用 Sentry 或 LogRocket 监控前端错误，使用 ELK 或 Prometheus 监控后端性能。

5. 测试与优化
测试：
使用 Jest 或 Vitest 进行单元测试。
覆盖率：确保单元测试覆盖率达到 80% 以上。
使用 Cypress 进行端到端测试。
使用 Chrome DevTools 的 Performance 面板分析性能瓶颈。
Lighthouse：使用 Lighthouse 进行性能评分，并优化加载速度。

性能优化：Konva.js 基于 Canvas 渲染，性能较好，但仍需注意以下优化点：
        节点数量：避免一次性渲染过多节点，可以使用虚拟滚动或分页加载。
        事件监听：为每个节点添加事件监听器时，使用事件委托（Event Delegation）来减少内存占用。
        图层分离：将静态内容（如背景）和动态内容（如节点）分离到不同的 Layer 中，以减少重绘。
        虚拟滚动：对于包含大量节点的思维导图，使用虚拟滚动技术，只渲染可见区域的节点。
        事件委托：使用事件委托减少事件监听器的数量，提高性能。
        图层分离：将静态内容（如背景）和动态内容（如节点）分离到不同的 Layer 中，以减少重绘。
        批量绘制：使用 layer.batchDraw() 减少绘制次数，提高性能。
模块化设计
组件拆分：将思维导图的各个部分（如节点、连接线、工具栏）拆分为独立组件。
工具函数封装：将通用功能（如导出图片、数据转换）封装为工具函数，方便复用。
垃圾回收：及时销毁不再使用的节点和连接线，避免内存泄漏。
数据分片：对于超大型思维导图，将数据分片加载，避免一次性加载过多数据。

6. 文档与维护
快速入门：编写快速入门指南，帮助用户快速上手。
功能说明：详细说明每个功能的使用方法。
FAQ：整理常见问题解答，减少用户咨询。
项目结构：说明项目目录结构和模块划分。
API 文档：记录后端 API 和前端组件的接口说明。
部署指南：提供详细的部署步骤和注意事项。
Git 分支：采用 Git Flow 或 GitHub Flow 管理分支。
版本发布：遵循语义化版本控制（SemVer），并编写发布说明。

7.安全性
数据验证：对用户输入的数据进行验证，防止恶意数据注入。
权限控制：实现不同用户的权限控制（如只读、编辑、管理员）。
数据加密：对敏感数据进行加密存储和传输。
HTTPS：确保生产环境使用 HTTPS 加密通信。
CORS：配置正确的 CORS 策略，防止跨站请求攻击。

8.拓展性
插件系统：设计插件系统，支持第三方扩展功能。
API 开放：提供开放的 API，方便开发者自定义功能。
主题支持：支持自定义主题，允许用户切换不同的界面风格。
多语言支持：使用 i18n 实现多语言支持。
本地化：根据用户地区自动切换语言和日期格式。

9. 错误处理与日志
错误边界：在关键组件中添加错误边界，防止整个应用崩溃。
友好提示：在用户操作失败时，提供友好的错误提示。
加载状态：在异步操作（如保存、导出）期间显示加载状态。
日志记录
前端日志：使用 Sentry 或 LogRocket 记录前端错误。
后端日志：使用 Winston 或 Bunyan 记录后端日志。

10.用户体验优化
交互设计
拖拽体验：优化节点拖拽的流畅性和准确性。
动画效果：为节点添加、删除、移动等操作添加平滑的动画效果。
响应式设计
移动端适配：确保思维导图在移动设备上能正常显示和操作。
缩放与平移：支持手势缩放和平移，提升移动端体验。
主题与样式
主题切换：支持浅色和深色主题切换。
自定义样式：允许用户自定义节点和连接线的样式。