
REMOVED DUPLICATES: - web/dashboard.py (533KB, 10474 lines) - Legacy massive file - web/dashboard_backup.py (504KB, 10022 lines) - Backup copy - web/temp_dashboard.py (132KB, 2577 lines) - Temporary file - web/scalping_dashboard.py (146KB, 2812 lines) - Duplicate functionality - web/enhanced_scalping_dashboard.py (65KB, 1407 lines) - Duplicate functionality REMOVED RUN SCRIPTS: - run_dashboard.py - Pointed to deleted legacy dashboard - run_enhanced_scalping_dashboard.py - For deleted dashboard - run_cob_dashboard.py - Simple duplicate - run_fixed_dashboard.py - Temporary fix - run_main_dashboard.py - Duplicate functionality - run_enhanced_system.py - Commented out file - simple_cob_dashboard.py - Integrated into main dashboards - simple_dashboard_fix.py - Temporary fix - start_enhanced_dashboard.py - Empty file UPDATED REFERENCES: - Fixed imports in test files to use clean_dashboard - Updated .cursorrules to reference clean_dashboard - Updated launch.json with templated dashboard config - Fixed broken import references RESULTS: - Removed ~1.4GB of duplicate dashboard code - Removed 8 duplicate run scripts - Kept essential: clean_dashboard.py, templated_dashboard.py, run_clean_dashboard.py - All launch configurations still work - Project is now slim and maintainable
66 lines
2.9 KiB
Plaintext
66 lines
2.9 KiB
Plaintext
# Cursor AI Coding Rules for gogo2 Trading Dashboard Project
|
|
|
|
## Environment
|
|
- we are on windows 11 machine
|
|
|
|
## Unicode and Encoding Rules
|
|
- **NEVER use Unicode characters that may not be supported by Windows console (cp1252)**
|
|
|
|
|
|
## Code Structure and Versioning Rules
|
|
- **NEVER create multiple versions of the same functionality** (e.g., _fixed, _enhanced, _v2)
|
|
- **ALWAYS work with existing code structure** and modify in place
|
|
- **ASK FOR EXPLICIT APPROVAL** before creating new implementations of existing features
|
|
- When fixing issues, modify the original file rather than creating copies
|
|
- Use descriptive commit messages but avoid creating parallel implementations
|
|
- If major refactoring is needed, discuss the approach first
|
|
|
|
## Dashboard Development Rules
|
|
- Focus on the main clean dashboard (`web/clean_dashboard.py`)
|
|
- Do not create alternative dashboard implementations unless explicitly requested
|
|
- Fix issues in the existing codebase rather than creating workarounds
|
|
- Ensure all callback registrations are properly handled
|
|
- Test callback functionality thoroughly before deployment
|
|
|
|
## Logging Best Practices
|
|
- Use structured logging with clear, ASCII-only messages
|
|
- Include relevant context in log messages without Unicode characters
|
|
- Use logger.info(), logger.error(), etc. with plain text
|
|
- Example: `logger.info("TRADING: Starting Live Scalping Dashboard at http://127.0.0.1:8051")`
|
|
|
|
## Error Handling
|
|
- Always include proper exception handling
|
|
- Log errors with ASCII-only characters
|
|
- Provide meaningful error messages without emojis
|
|
- Include stack traces for debugging when appropriate
|
|
|
|
## File Naming Conventions
|
|
- Use descriptive names without version suffixes
|
|
- Avoid creating multiple files for the same purpose
|
|
- Use clear, concise names that indicate the file's purpose
|
|
|
|
## Testing Guidelines
|
|
- Create focused test files for specific functionality
|
|
- Use temporary test files that can be easily cleaned up
|
|
- Name test files clearly (e.g., `test_callback_registration.py`)
|
|
- Remove or archive test files after issues are resolved
|
|
|
|
## Windows Compatibility
|
|
- Ensure all code works properly on Windows systems
|
|
- Handle Windows-specific path separators correctly
|
|
- Use appropriate encoding for file operations
|
|
- Test console output compatibility with Windows Command Prompt and PowerShell
|
|
|
|
## Dashboard Callback Rules
|
|
- Ensure all Dash callbacks are properly registered
|
|
- Use consistent callback patterns across the application
|
|
- Handle callback errors gracefully with fallback values
|
|
- Test callback functionality with direct HTTP requests when debugging
|
|
|
|
## Code Review Checklist
|
|
Before submitting code changes, verify:
|
|
- [ ] No Unicode/emoji characters in logging or console output
|
|
- [ ] No duplicate implementations of existing functionality
|
|
- [ ] Proper error handling with ASCII-only messages
|
|
- [ ] Windows compatibility maintained
|
|
- [ ] Existing code structure preserved and enhanced rather than replaced |