.cursorrules

# FastLED Project Rules for Cursor

## 🚨 CRITICAL: PYTHON EXECUTION REQUIREMENTS - NO EXCEPTIONS! 🚨

### MANDATORY COMMAND EXECUTION RULES - ALL AGENTS MUST FOLLOW

**🚨 ABSOLUTELY FORBIDDEN: Direct python/python3 execution**
- ❌ **NEVER use:** `python3 <command>`
- ❌ **NEVER use:** `python <command>`  
- ❌ **NEVER use:** `./python`
- ❌ **NEVER use:** Direct Python interpreter calls

**✅ MANDATORY: Always use uv run**
- ✅ **ALWAYS use:** `uv run python <command>`
- ✅ **ALWAYS use:** `uv run python -c "..."`
- ✅ **ALWAYS use:** `uv run python script.py`

**NO EXCEPTIONS - ALL PYTHON CODE MUST RUN THROUGH UV:**

```bash
# ✅ CORRECT - Use uv run python
uv run python test.py
uv run python ci/ci-compile.py uno --examples Blink
uv run python -c "from ci.ci.module import func; func()"
uv run python ci/ci/build_info_analyzer.py --board uno --show-defines

# ❌ FORBIDDEN - Direct python execution
python3 test.py                    # NO!
python ci/ci-compile.py            # NO!
python3 -c "import something"      # NO!
python3 script.py                  # NO!
```

**THIS RULE APPLIES TO:**
- 🚨 **All test execution**
- 🚨 **All script execution** 
- 🚨 **All build commands**
- 🚨 **All analysis tools**
- 🚨 **All development commands**
- 🚨 **ALL Python code execution without exception**

**WHY:** The project uses UV for dependency management and execution environment. Direct python3 calls bypass the controlled environment and may use wrong Python versions or missing dependencies.

**ENFORCEMENT:** Any agent using direct python3/python commands is in violation of project requirements.

### 🚨 UV RUN MANDATE - FINAL WARNING 🚨

**IF YOU SEE ANY COMMANDS IN THIS PROJECT DOCUMENTATION THAT USE `python3` OR `python` DIRECTLY:**

1. **🚫 DO NOT COPY THEM** - They are legacy commands that must be updated
2. **✅ ALWAYS REPLACE** `python3` with `uv run python` 
3. **✅ ALWAYS REPLACE** `python` with `uv run python`
4. **📝 UPDATE DOCUMENTATION** when you find python3 commands 

**EXAMPLES OF MANDATORY REPLACEMENTS:**
```bash
# ❌ If you see this in docs (WRONG):
python3 script.py

# ✅ Always use this instead (CORRECT):
uv run python script.py

# ❌ If you see this in docs (WRONG):  
python -c "import something"

# ✅ Always use this instead (CORRECT):
uv run python -c "import something"
```

**UV RUN IS NOT OPTIONAL - IT IS MANDATORY FOR ALL PYTHON EXECUTION.**

## 🚨 CRITICAL: NO DEFAULT VALUES POLICY 🚨

### MANDATORY: Explicit Parameter Policy - NO DEFAULTS ALLOWED

**🚨 ABSOLUTELY FORBIDDEN: Default values in dataclasses and function parameters**

**❌ NEVER USE DEFAULT VALUES:**
- Function parameters with defaults
- Dataclass fields with default values
- Method parameters with defaults
- Optional parameters with fallback values

**✅ ALWAYS REQUIRE EXPLICIT VALUES:**
- All function parameters must be explicitly provided by caller
- All dataclass fields must be explicitly specified
- Use Optional types for truly optional parameters, but no defaults
- Force callers to handle every parameter consciously

**WHY NO DEFAULTS:**
- **Signature changes break compilation** - Adding/removing parameters forces all callers to update
- **Prevents silent bugs** - Missing parameter updates become compile-time errors
- **Explicit intent** - Every call site shows exactly what values are being passed
- **Refactoring safety** - Internal changes are caught immediately by type checker
- **Code clarity** - No hidden behavior from default values

**EXAMPLES:**

```python
# ❌ FORBIDDEN - Default values hide signature changes
@dataclass
class Config:
    name: str = "default"
    enabled: bool = True
    timeout: int = 30

def process_data(data: bytes, validate: bool = True, timeout: int = 30):
    pass

# ✅ CORRECT - Explicit values required
@dataclass  
class Config:
    name: str
    enabled: bool
    timeout: int

def process_data(data: bytes, validate: bool, timeout: int):
    pass

# Usage requires all parameters
config = Config(name="test", enabled=True, timeout=60)
process_data(data=my_data, validate=False, timeout=30)
```

**BENEFITS:**
- **Immediate feedback** when function signatures change
- **No silent failures** from missed parameter updates
- **Self-documenting code** - all parameters visible at call sites
- **Safer refactoring** - type checker catches all usage sites
- **Consistent behavior** - no surprising default value interactions

**EXCEPTIONS (Use Sparingly):**
- Constructor overloads where defaults truly make sense for usability
- Public API methods where backwards compatibility is critical
- BUT: Internal/private functions should NEVER have defaults

**ENFORCEMENT:**
This policy should be enforced by linters and code review. Adding defaults to existing code without explicit justification is not allowed.

## 🚨 CRITICAL: STRICT ENVIRONMENT HANDLING - NO SILENT FAILURES 🚨

### MANDATORY: Fail Fast on Missing Environment Dependencies - NO EXCEPTIONS

**🚨 ABSOLUTELY FORBIDDEN: Silent fallbacks for missing critical resources**

**❌ NEVER DO SILENT FALLBACKS:**
- Missing configuration files → throw error, don't use defaults
- Missing environment variables → throw error, don't substitute defaults  
- Missing build flags → throw error, don't continue with partial config
- Missing required paths → throw error, don't create alternatives
- Missing dependencies → throw error, don't skip functionality

**✅ ALWAYS FAIL FAST AND EXPLICIT:**
- Throw descriptive RuntimeError/ValueError for missing resources
- Include the expected path/location in error message
- Explain why the resource is required
- Provide clear instructions for fixing the issue
- Use explicit checks before proceeding with operations

**WHY NO SILENT FALLBACKS:**
- **Hidden failures** - Silent fallbacks mask configuration problems
- **Inconsistent behavior** - Code works differently in different environments  
- **Hard to debug** - Missing configs cause subtle bugs hours later
- **Security risks** - Default values may be insecure or inappropriate
- **Configuration drift** - Systems diverge silently when configs are missing

**EXAMPLES:**

```python
# ❌ FORBIDDEN - Silent fallback hides missing config
def load_config(config_path: str) -> Dict[str, Any]:
    try:
        with open(config_path) as f:
            return json.load(f)
    except FileNotFoundError:
        print(f"Warning: {config_path} not found, using defaults")
        return {"timeout": 30, "retries": 3}  # BAD: Silent defaults

# ✅ CORRECT - Fail fast with clear error
def load_config(config_path: str) -> Dict[str, Any]:
    try:
        with open(config_path) as f:
            return json.load(f)
    except FileNotFoundError:
        raise RuntimeError(
            f"CRITICAL: Configuration file not found at {config_path}. "
            f"This file is required for proper operation. "
            f"Please ensure the file exists and is readable."
        )

# ❌ FORBIDDEN - Silent environment variable fallback  
def get_build_dir() -> str:
    return os.environ.get("BUILD_DIR", "/tmp/default")  # BAD: Hidden default

# ✅ CORRECT - Explicit environment requirement
def get_build_dir() -> str:
    build_dir = os.environ.get("BUILD_DIR")
    if not build_dir:
        raise RuntimeError(
            "CRITICAL: BUILD_DIR environment variable is required but not set. "
            "Please set BUILD_DIR to the target build directory."
        )
    return build_dir
```

**STRICT ENFORCEMENT AREAS:**
- **Build configuration files** (build_flags.toml, CMakeLists.txt, etc.)
- **Environment variables** required for compilation/testing
- **Tool dependencies** (compilers, archivers, etc.)
- **Input file paths** passed as parameters
- **Required directories** for output/temporary files

**RARE EXCEPTIONS (Require Explicit Justification):**
- User-facing CLI tools where missing optional config is acceptable
- Graceful degradation for non-critical features only
- BUT: Core build/compilation functionality must NEVER have silent fallbacks

**ERROR MESSAGE REQUIREMENTS:**
- Start with "CRITICAL:" prefix for build/config errors
- Include the exact path/variable name that was expected
- Explain what the missing resource is used for
- Provide actionable steps to fix the issue

**ENFORCEMENT:**
Any function that silently handles missing critical resources without throwing an explicit error is in violation of project requirements. Code review must catch and reject such patterns.

## Cursor Configuration

### Post-Change Hooks
Run linting after every code change:
```yaml
post_change_hooks:
  - command: "bash lint"
    description: "Run code formatting and linting"
    working_directory: "."
```

## MCP Server Configuration
This project includes a custom MCP server (`mcp_server.py`) that provides tools for:
- Running tests with various options
- Compiling examples for different platforms  
- Code fingerprinting and change detection
- Linting and formatting
- Project information and status
- **Build info analysis for platform-specific defines, compiler flags, and toolchain information**
- **Symbol analysis for binary optimization (all platforms)**
- Stack trace setup for enhanced debugging
- **🌐 FastLED Web Compiler with Playwright (FOREGROUND AGENTS ONLY)**
- **🚨 CRITICAL: `validate_completion` tool for background agents**

To use the MCP server, run: `uv run mcp_server.py`

**BACKGROUND AGENTS:** The MCP server includes a mandatory `validate_completion` tool that MUST be used before indicating task completion. This tool runs `bash test` and ensures all tests pass.

### FastLED Web Compiler (FOREGROUND AGENTS ONLY)

**🌐 FOR INTERACTIVE DEVELOPMENT:** The MCP server includes a `run_fastled_web_compiler` tool that:

**Note:** For direct command-line WASM compilation, see the **WASM Sketch Compilation** section below.

- **Compiles Arduino sketches to WASM** for browser execution
- **Captures console.log output** with playwright automation  
- **Takes screenshots** of running visualizations
- **Monitors FastLED_onFrame calls** to verify proper initialization
- **Provides detailed analysis** of errors and performance

**PREREQUISITES:**
- `pip install fastled` - FastLED web compiler
- `pip install playwright` - Browser automation (included in pyproject.toml)
- Docker (optional, for faster compilation)

**USAGE EXAMPLES:**
```python
# Via MCP Server - Basic usage
use run_fastled_web_compiler tool with:
- example_path: "examples/Audio"
- capture_duration: 30
- headless: false
- save_screenshot: true

# Via MCP Server - Different examples
use run_fastled_web_compiler tool with:
- example_path: "examples/Blink"
- capture_duration: 15
- headless: true

# Via MCP Server - Quick test
use run_fastled_web_compiler tool with:
- example_path: "examples/wasm"
- capture_duration: 10
```

**KEY FEATURES:**
- **Automatic browser installation:** Installs Chromium via playwright
- **Console.log capture:** Records all browser console output with timestamps
- **Error detection:** Identifies compilation failures and runtime errors
- **FastLED monitoring:** Tracks `FastLED_onFrame` calls to verify functionality
- **Screenshot capture:** Saves visualization images with timestamps
- **Docker detection:** Checks for Docker availability for faster builds
- **Background agent protection:** Automatically disabled for CI/background environments

**🚫 BACKGROUND AGENT RESTRICTION:**
This tool is **COMPLETELY DISABLED** for background agents and CI environments. Background agents attempting to use this tool will receive an error message. This is intentional to prevent:
- Hanging processes in automated environments
- Resource conflicts in CI/CD pipelines  
- Interactive browser windows in headless environments

**CONSOLE.LOG CAPTURE PATTERN:**
The tool follows the pattern established in `ci/wasm_test.py` and `ci/ci/scrapers/`:
```javascript
// Example captured console.log patterns:
[14:25:30] log: FastLED_onFrame called: {"frame":1,"leds":100}
[14:25:30] log: Audio worklet initialized
[14:25:31] error: Missing audio_worklet_processor.js
[14:25:31] warning: WebGL context lost
```

**INTEGRATION WITH EXISTING CI:**
- Complements existing `ci/wasm_test.py` functionality
- Uses same playwright patterns as `ci/ci/scrapers/`
- Leverages existing pyproject.toml dependencies
- Compatible with existing Docker-based compilation workflow

## Project Structure
- `src/` - Main FastLED library source code
- `examples/` - Arduino examples demonstrating FastLED usage
- `tests/` - Test files and infrastructure
- `ci/` - Continuous integration scripts
- `docs/` - Documentation

## Key Commands
- `uv run test.py` - Run all tests
- `uv run test.py --cpp` - Run C++ tests only
- `uv run test.py TestName` - Run specific C++ test
  - For example: running test_xypath.cpp would be uv run test.py xypath
- `./lint` - Run code formatting/linting
- `uv run ci/ci-compile.py uno --examples Blink` - Compile examples for specific platform
  - For example (uno): `uv run ci/ci-compile.py uno --examples Blink`
  - For example (esp32dev): `uv run ci/ci-compile.py esp32dev --examples Blink`
  - For example (esp8266): `uv run ci/ci-compile.py esp8266 --examples Blink`
  - For example (teensy31): `uv run ci/ci-compile.py teensy31 --examples Blink`
- **WASM Compilation** - Compile Arduino sketches to run in web browsers:
  - `uv run ci/wasm_compile.py examples/Blink -b --open` - Compile Blink to WASM and open browser
  - `uv run ci/wasm_compile.py path/to/your/sketch -b --open` - Compile any sketch to WASM
- **Symbol Analysis** - Analyze binary size and optimization opportunities:
  - `uv run ci/ci/symbol_analysis.py --board uno` - Analyze UNO platform
  - `uv run ci/ci/symbol_analysis.py --board esp32dev` - Analyze ESP32 platform
  - `uv run ci/demo_symbol_analysis.py` - Analyze all available platforms

## 🤖 AI AGENT LINTING GUIDELINES

### FOREGROUND AGENTS (Interactive Development)
**🚨 ALWAYS USE `bash lint` - DO NOT RUN INDIVIDUAL LINTING SCRIPTS**

- **✅ CORRECT:** `bash lint`
- **❌ FORBIDDEN:** `./lint-js`, `./check-js`, `uv run python scripts/enhance-js-typing.py`
- **❌ FORBIDDEN:** `uv run ruff check`, `uv run black`, individual tools

**WHY:** `bash lint` provides:
- **Comprehensive coverage** - Python, C++, JavaScript, and enhancement analysis
- **Consistent workflow** - Single command for all linting needs  
- **Proper sequencing** - Runs tools in the correct order with dependencies
- **Clear output** - Organized sections showing what's being checked
- **Agent guidance** - Shows proper usage for AI agents

### BACKGROUND AGENTS (Automated/CI Environments)
**CAN USE FINE-GRAINED LINTING FOR SPECIFIC NEEDS**

Background agents may use individual linting scripts when needed:
- `./lint-js` - JavaScript-only linting
- `./check-js` - JavaScript type checking
- `uv run python scripts/enhance-js-typing.py` - JavaScript enhancement analysis
- `uv run ruff check` - Python linting only
- MCP server `lint_code` tool - Programmatic access

**BUT STILL PREFER `bash lint` FOR COMPREHENSIVE CHECKING**

### Linting Script Integration

The `bash lint` command now includes:
1. **📝 Python Linting** - ruff, black, isort, pyright
2. **🔧 C++ Linting** - clang-format (when enabled)
3. **🌐 JavaScript Linting** - Deno lint, format check, type checking
4. **🔍 JavaScript Enhancement** - Analysis and recommendations
5. **💡 AI Agent Guidance** - Clear instructions for proper usage

### When to Use Individual Scripts

**FOREGROUND AGENTS:** Never. Always use `bash lint`.

**BACKGROUND AGENTS:** Only when:
- **Debugging specific issues** with one language/tool
- **Testing incremental changes** to linting configuration
- **Running targeted analysis** for specific files
- **Integrating with automated workflows** via MCP server

## Development Guidelines
- Follow existing code style and patterns
- Run tests before committing changes
- Use the MCP server tools for common tasks
- Check examples when making API changes

## 🚨 CRITICAL: .INO FILE CREATION RULES 🚨

### ⚠️ THINK BEFORE CREATING .INO FILES ⚠️

**.ino files should be created SPARINGLY and ONLY when truly justified.**

### 🚫 WHEN NOT TO CREATE .INO FILES:
- **Testing minor code changes** - Use existing test files or unit tests
- **Quick API validation** - Use unit tests or modify existing examples
- **Debugging specific functions** - Use test files, not new sketches
- **One-off experiments** - Create temporary test files instead
- **Small feature tests** - Extend existing relevant examples

### ✅ WHEN TO CREATE .INO FILES:

#### 1. **Temporary Testing (.ino)**
**Use Pattern:** `temp_<feature>.ino` or `test_<api>.ino`
```cpp
// temp_json_api.ino - Testing new JSON fetch functionality
// test_networking.ino - Validating network stack changes
```
- ✅ **FOR:** Testing new APIs during development
- ✅ **FOR:** Quick prototyping and validation
- ✅ **DELETE AFTER USE** - These are temporary by design

#### 2. **Significant New Feature Examples**
**Use Pattern:** `examples/<FeatureName>/<FeatureName>.ino`
```cpp
// examples/JsonFetchApi/JsonFetchApi.ino - Comprehensive JSON API example
// examples/NetworkStack/NetworkStack.ino - Major networking features
```
- ✅ **FOR:** Large, comprehensive new features
- ✅ **FOR:** APIs that warrant dedicated examples
- ✅ **FOR:** Features that users will commonly implement
- ✅ **PERMANENT** - These become part of the example library

### 📋 CREATION CHECKLIST:

**Before creating ANY .ino file, ask:**

1. **🤔 Is this testing a new API?**
   - YES → Create `temp_<name>.ino`, delete after testing
   - NO → Consider alternatives

2. **🤔 Is this a significant new feature that users will commonly use?**
   - YES → Create `examples/<FeatureName>/<FeatureName>.ino`
   - NO → Use existing examples or test files

3. **🤔 Can I modify an existing example instead?**
   - YES → Extend existing example rather than creating new
   - NO → Proceed with creation

4. **🤔 Is this just for debugging/validation?**
   - YES → Use unit tests or temporary test files
   - NO → Consider if it meets the "significant feature" criteria

### 🔍 REVIEW CRITERIA:

**For Feature Examples (.ino files that stay):**
- ✅ **Demonstrates complete, real-world usage patterns**
- ✅ **Covers multiple aspects of the feature comprehensively**  
- ✅ **Provides educational value for users**
- ✅ **Shows best practices and common use cases**
- ✅ **Is likely to be referenced by multiple users**

**For Temporary Testing (.ino files that get deleted):**
- ✅ **Clearly named as temporary (temp_*, test_*)**
- ✅ **Focused on specific API validation**
- ✅ **Will be deleted after development cycle**
- ✅ **Too complex for unit test framework**

### ❌ EXAMPLES OF WHAT NOT TO CREATE:
- `test_basic_led.ino` - Use existing Blink example
- `debug_colors.ino` - Use existing ColorPalette example  
- `quick_brightness.ino` - Use unit tests or modify existing example
- `validate_pins.ino` - Use PinTest example or unit tests

### ✅ EXAMPLES OF JUSTIFIED CREATIONS:
- `temp_new_wifi_api.ino` - Testing major new WiFi functionality (temporary)
- `examples/MachineLearning/MachineLearning.ino` - New ML integration feature (permanent)
- `temp_performance_test.ino` - Validating optimization changes (temporary)

### 🧹 CLEANUP RESPONSIBILITY:
- **Temporary files:** Creator must delete when testing is complete
- **Feature examples:** Must be maintained and updated as API evolves
- **Abandoned files:** Regular cleanup reviews to remove unused examples

**Remember: The examples directory is user-facing documentation. Every .ino file should provide clear value to FastLED users.**

### Memory Management with Smart Pointers and Moveable Objects
**🚨 CRITICAL: Always use proper RAII patterns - smart pointers, moveable objects, or wrapper classes instead of raw pointers for resource management.**

**Resource Management Options:**
- ✅ **PREFERRED**: `fl::shared_ptr<T>` for shared ownership (multiple references to same object)
- ✅ **PREFERRED**: `fl::unique_ptr<T>` for exclusive ownership (single owner, automatic cleanup)
- ✅ **PREFERRED**: Moveable wrapper objects (like `fl::promise<T>`) for safe copying and transferring of unique resources
- ✅ **ACCEPTABLE**: `fl::vector<T>` storing objects by value when objects support move/copy semantics
- ❌ **AVOID**: `fl::vector<T*>` storing raw pointers - use `fl::vector<fl::shared_ptr<T>>` or `fl::vector<fl::unique_ptr<T>>`
- ❌ **AVOID**: Manual `new`/`delete` - use `fl::make_shared<T>()` or `fl::make_unique<T>()`

**Moveable Wrapper Pattern:**
When you have a unique resource (like a future, file handle, or network connection) that needs to be passed around easily, create a moveable wrapper class that:
- Internally manages the unique resource (often with `fl::unique_ptr<T>` or similar)
- Provides copy semantics through shared implementation details
- Maintains clear ownership semantics
- Allows safe transfer between contexts

**Examples:**
```cpp
// ✅ GOOD - Using smart pointers
fl::vector<fl::shared_ptr<HttpClient>> mActiveClients;
auto client = fl::make_shared<HttpClient>();
mActiveClients.push_back(client);

// ✅ GOOD - Using unique_ptr for exclusive ownership
fl::unique_ptr<HttpClient> client = fl::make_unique<HttpClient>();

// ✅ GOOD - Moveable wrapper objects (fl::promise example)
fl::vector<fl::promise<Response>> mActivePromises;  // Copyable wrapper around unique future
fl::promise<Response> promise = fetch.get(url).execute();
mActivePromises.push_back(promise);  // Safe copy, shared internal state

// ✅ GOOD - Objects stored by value (if copyable/moveable)
fl::vector<Request> mRequests;  // When Request supports copy/move

// ❌ BAD - Raw pointers require manual memory management
fl::vector<Promise*> mActivePromises;  // Memory leaks possible
Promise* promise = new Promise();      // Who calls delete?
```

**fl::promise<T> as Moveable Wrapper Example:**
```cpp
// fl::promise<T> wraps a unique fl::future<T> but provides copyable semantics
class promise<T> {
    fl::shared_ptr<future<T>> mImpl;  // Shared wrapper around unique resource
public:
    promise(const promise& other) : mImpl(other.mImpl) {}  // Safe copying
    promise(promise&& other) : mImpl(fl::move(other.mImpl)) {}  // Move support
    // ... wrapper delegates to internal future
};

// Usage - can be copied and passed around safely
fl::promise<Response> promise = http_get_promise("https://api.example.com");
someContainer.push_back(promise);  // Copy is safe
processAsync(promise);  // Can pass to multiple places
```

**Why This Pattern:**
- **Automatic cleanup** - No memory leaks from forgotten `delete` calls
- **Exception safety** - Resources automatically freed even if exceptions occur
- **Clear ownership** - Code clearly shows who owns what objects
- **Thread safety** - Smart pointers provide atomic reference counting
- **Easy sharing** - Moveable wrappers allow safe copying of unique resources
- **API flexibility** - Can pass resources between different contexts safely

## 🚨 CRITICAL REQUIREMENTS FOR ALL AGENTS (FOREGROUND & BACKGROUND) 🚨

## 🚨 MANDATORY COMMAND EXECUTION RULES 🚨

### FOREGROUND AGENTS (Interactive Development)

**FOREGROUND AGENTS MUST FOLLOW THESE COMMAND EXECUTION PATTERNS:**

#### Python Code Execution:
- ❌ **NEVER run Python code directly**
- ❌ **NEVER cd to subdirectories like ci/ - ALWAYS stay in project root**
- ✅ **ALWAYS create/modify tmp.py** with your code
- ✅ **ALWAYS run: `uv run python tmp.py`** (use full `uv run python`, not just `python`)
- ✅ **ALWAYS use correct import paths: `from ci.ci.module` for ci.ci modules, `from ci.module` for top-level ci modules**

#### Shell Command Execution:
- ❌ **NEVER run shell commands directly**  
- ❌ **NEVER cd to subdirectories** - commands should work from project root
- ✅ **ALWAYS create/modify tmp.sh** with your commands
- ✅ **ALWAYS run: `bash tmp.sh`**

#### Command Execution Examples:

**Python Code Pattern:**
```python
# tmp.py (created in project root, NOT in subdirectories)
from ci.ci.clang_compiler import Compiler  # CORRECT import path for ci.ci modules
import subprocess
result = subprocess.run(['git', 'status'], capture_output=True, text=True)
print(result.stdout)
```
Then run: `uv run python tmp.py` (from project root)

**Shell Commands Pattern:**
```bash
# tmp.sh (created in project root)
#!/bin/bash
git status
ls -la
uv run ci/ci-compile.py uno --examples Blink  # Use full paths from root
```
Then run: `bash tmp.sh` (from project root)

### BACKGROUND AGENTS (Automated/CI Environments)

**BACKGROUND AGENTS MUST FOLLOW THESE RESTRICTED COMMAND EXECUTION PATTERNS:**

#### Python Code Execution:
- ❌ **NEVER run Python code directly**
- ❌ **NEVER create/use tmp.py files** (forbidden for background agents)
- ❌ **NEVER cd to subdirectories like ci/ - ALWAYS stay in project root**
- ✅ **ALWAYS use `uv run python` with existing scripts** (e.g., `uv run python test.py`, `uv run python ci/ci-compile.py`)
- ✅ **ALWAYS use correct import paths: `from ci.ci.module` for ci.ci modules, `from ci.module` for top-level ci modules** when testing
- ✅ **ALWAYS use MCP server tools** for programmatic operations when available

#### Shell Command Execution:
- ❌ **NEVER run shell commands directly**
- ❌ **NEVER create/use tmp.sh files** (forbidden for background agents)
- ❌ **NEVER cd to subdirectories** - commands should work from project root
- ✅ **ALWAYS use existing bash scripts** (e.g., `bash test`, `bash lint`)
- ✅ **ALWAYS use `uv run python` for Python scripts** with proper arguments from project root
- ✅ **ALWAYS use MCP server tools** for complex operations when available

#### Background Agent Command Examples:

**✅ ALLOWED - Using existing scripts from project root:**
```bash
bash test
bash lint
uv run python test.py audio_json_parsing
uv run python ci/ci-compile.py uno --examples Blink
```

**❌ FORBIDDEN - Creating temporary files:**
```bash
# DON'T DO THIS - tmp.sh is forbidden for background agents
echo "git status" > tmp.sh
bash tmp.sh
```

**✅ PREFERRED - Using MCP server tools:**
```bash
uv run python mcp_server.py
# Then use appropriate MCP tools like: validate_completion, symbol_analysis, etc.
```

### 🚨 CRITICAL CORRECTIONS FROM USER FEEDBACK 🚨

**These corrections were identified through direct user feedback and MUST be followed:**

#### 1. **Always Use `uv run python` - NEVER just `python` or `uv run`**
- ❌ **WRONG**: `python -c "..."`
- ❌ **WRONG**: `uv run -c "..."`  
- ✅ **CORRECT**: `uv run python -c "..."`

#### 2. **Correct Import Paths - Use Appropriate Module Structure**
- ✅ **CORRECT**: `from ci.ci.clang_compiler import ...` (for ci.ci modules)
- ✅ **CORRECT**: `from ci.clang_compiler import ...` (for top-level ci modules, if they exist)

#### 3. **Never Change Directory - Always Work from Project Root**
- ❌ **WRONG**: `cd ci && python ...`
- ❌ **WRONG**: `cd ci/ci && python ...`
- ✅ **CORRECT**: Stay in project root, use full paths: `uv run python ci/script.py`

#### 4. **Testing Commands Must Use Correct Format**
- ❌ **WRONG**: `python -c "from ci.ci.module import func; func()"` (missing uv run python)
- ✅ **CORRECT**: `uv run python -c "from ci.ci.module import func; func()"` (for ci.ci modules)

**Example of CORRECT Command Pattern:**
```bash
# From project root directory
uv run python -c "from ci.ci.clang_compiler import detect_linker; print('Linker:', detect_linker())"
```

**These patterns were corrected through direct user feedback and must be followed exactly.**

### DELETE Operations - DANGER ZONE (ALL AGENTS):
- 🚨 **STOP and ask for permission** before ANY delete operations
- ✅ **EXCEPTION:** Single files that you just created are OK to delete
- ❌ **NEVER delete multiple files** without explicit permission
- ❌ **NEVER delete directories** without explicit permission
- ❌ **NEVER delete system files or project files** without permission

### Git-Bash Terminal Truncation Issue
**🚨 IMPORTANT: Git-Bash terminal may truncate the first character of commands**

**Problem:** The git-bash terminal on Windows sometimes truncates the first character of commands, causing them to fail or execute incorrectly.

**Solution:** Pre-pend commands with an additional space when using git-bash:
- ✅ **CORRECT**: ` bash test` (note the leading space)
- ❌ **INCORRECT**: `bash test` (may get truncated to `ash test`)

**Examples:**
```bash
# Good - with leading space for git-bash compatibility
 bash test
 uv run python test.py
 bash lint

# Bad - may get truncated in git-bash
bash test
uv run python test.py
bash lint
```

**Why:** This ensures commands work reliably across all terminal environments, especially git-bash on Windows systems.

### Why These Rules Exist:
- **Ensures all operations are reviewable and traceable**
- **Prevents accidental destructive operations in automated environments**
- **Allows for better debugging and error handling**
- **Maintains consistency across different agent types**
- **Provides audit trail for all system modifications**
- **Prevents background agents from creating unnecessary temporary files**

### 📋 QUICK REFERENCE: CORRECTED COMMAND PATTERNS

**User-Corrected Patterns (MANDATORY):**

✅ **Python Testing**: `uv run python -c "from ci.module import func; func()"`
✅ **Script Execution**: `uv run python ci/script.py` (from project root)
✅ **Import Paths**: `from ci.clang_compiler import ...` (NOT `ci.ci.clang_compiler`)
✅ **Working Directory**: Always stay in project root - never cd to subdirectories
✅ **Git-Bash**: Use leading space: ` uv run python test.py`

❌ **Never Do**: cd to ci/, python directly, wrong import paths, uv run without python

**These command execution rules apply to ALL operations including but not limited to:**
- File system operations (creating, modifying, deleting files)
- Git operations (commits, pushes, branch changes)
- Package installations and updates
- Build and compilation commands
- Test execution and validation
- System configuration changes


### MANDATORY MEMORY REFRESH BEFORE COMPLETION
**🚨 ALL AGENTS MUST REFRESH THEIR MEMORY BEFORE CONCLUDING WORK:**

- **The AI shall read the cursor rules again to find out what to do before task is considered complete**
  - This is MANDATORY for both foreground and background agents
  - Reading the cursor rules refreshes your memory about the latest project rules, coding standards, and requirements
  - This ensures you have current information about testing procedures, validation tools, and completion requirements
  - Do NOT indicate your work is "done" until you have refreshed your memory by reading the cursor rules

## 🚨 CRITICAL REQUIREMENTS FOR BACKGROUND AGENTS 🚨

### MANDATORY PRE-COMPLETION VALIDATION
**ALL BACKGROUND AGENTS MUST FOLLOW THESE REQUIREMENTS BEFORE INDICATING COMPLETION:**

1. **🚨 ALWAYS RUN `bash test` BEFORE INDICATING COMPLETION**
   - This is MANDATORY and NON-NEGOTIABLE for all background agents
   - The command `bash test` runs the full test suite including unit tests and compilation checks
   - Background agents MUST NOT indicate they are "done" until ALL tests pass

2. **🚨 USE MCP SERVER VALIDATION TOOL**
   - Use the `validate_completion` tool from the MCP server: `uv run mcp_server.py`
   - This tool runs `bash test` and validates that all tests pass
   - Only indicate completion if this validation tool returns success

3. **🚨 ZERO TOLERANCE FOR TEST FAILURES**
   - If ANY test fails, the background agent MUST fix the issues before completion
   - Do NOT indicate completion with failing tests
   - Do NOT ignore test errors or warnings

### Background Agent Completion Checklist:
- [ ] All code changes have been made
- [ ] `bash test` has been run and ALL tests pass
- [ ] No compilation errors or warnings
- [ ] MCP server `validate_completion` tool shows success
- [ ] Only then indicate task completion

**FAILURE TO FOLLOW THESE REQUIREMENTS WILL RESULT IN BROKEN CODE SUBMISSIONS.**

### C++ Design Patterns
**Shared Implementation Pattern:** When writing a lot of code that applies the same operation on a bunch of C++ objects, try and determine if those objects share a common base class or internal object. If so consider whether it's appropriate to move the implementation into a shared space.

## Code Standards

### Python List Comprehensions

**🚨 AVOID: List comprehensions in favor of explicit loops**

**❌ WRONG - Using list comprehensions:**
```python
# Hard to read and debug
files = [f for f in os.listdir() if f.endswith('.py')]
results = [process(x) for x in data if is_valid(x)]
nested = [(x, y) for x in range(5) for y in range(3)]
```

**✅ CORRECT - Using explicit loops:**
```python
# Clear and debuggable
files = []
for f in os.listdir():
    if f.endswith('.py'):
        files.append(f)

results = []
for x in data:
    if is_valid(x):
        results.append(process(x))

nested = []
for x in range(5):
    for y in range(3):
        nested.append((x, y))
```

**Why avoid list comprehensions:**
- ✅ **Readability** - Explicit loops are easier to read and understand
- ✅ **Debuggability** - Can set breakpoints and inspect variables in loops
- ✅ **Maintainability** - Easier to modify and extend loop logic
- ✅ **Error handling** - Can add try/except blocks in loops
- ✅ **Step-by-step clarity** - Operations are clearly separated and ordered

**When list comprehensions ARE acceptable:**
- ✅ **Simple transformations**: `squares = [x * x for x in numbers]`
- ✅ **Basic filtering**: `evens = [x for x in numbers if x % 2 == 0]`
- ✅ **Single-purpose operations**: `names = [user.name for user in users]`

**Key principle:** If the operation involves multiple conditions, transformations, or would benefit from step-by-step debugging, use an explicit loop instead.

### Python Function Parameter and Return Types

**🚨 MANDATORY: ALL function parameters MUST have explicit type annotations - NO EXCEPTIONS!**
**🚨 MANDATORY: ALL function return types MUST have explicit type annotations - NO EXCEPTIONS!**
**🚨 MANDATORY: NO DEFAULT VALUES in function parameters - NO EXCEPTIONS!**

This rule applies to:
- ✅ Regular function parameters (no defaults) AND return types
- ✅ Method parameters (including self/cls, no defaults) AND return types
- ✅ Lambda parameters (no defaults) AND return types
- ✅ Callback function parameters (no defaults) AND return types
- ✅ Generator function parameters (no defaults) AND return types
- ✅ Async function parameters (no defaults) AND return types
- ✅ Protocol method parameters (no defaults) AND return types

**Examples:**

```python
# ❌ WRONG - Missing parameter types
def process_data(data):
    return data

# ❌ WRONG - Missing return type annotation
def run_tests():
    pass

# ❌ WRONG - Partial typing and defaults
def validate_user(name: str, age, enabled: bool = True):
    return True

# ❌ WRONG - Has default values (even with types)
def process_data(data: bytes, validate: bool = True) -> bytes:
    return data

# ✅ CORRECT - All parameters typed, no defaults, explicit return type
def process_data(data: bytes, validate: bool) -> bytes:
    return data

# ✅ CORRECT - Explicit return type for functions returning None
def run_tests() -> None:
    pass

# ✅ CORRECT - Method parameters typed including self
class DataProcessor:
    def process(self, data: bytes) -> bytes:
        return data

# ✅ CORRECT - Lambda parameters typed
callback: Callable[[int], None] = lambda x: None

# ✅ CORRECT - Async function parameters typed
async def fetch_data(url: str) -> bytes:
    return await download(url)
```

**Return Type Requirements:**
- ✅ Functions that return nothing: `-> None`
- ✅ Functions that return a value: `-> ReturnType`
- ✅ Functions that return optional values: `-> Optional[ReturnType]` or `-> ReturnType | None`
- ✅ Functions that return multiple types: `-> Union[Type1, Type2]` or `-> Type1 | Type2`
- ✅ Generator functions: `-> Generator[YieldType, SendType, ReturnType]`
- ✅ Async functions: `-> Awaitable[ReturnType]` or `async def func() -> ReturnType`

**ABSOLUTELY FORBIDDEN:**
- ❌ Functions without return type annotations: `def function():`
- ❌ Methods without return type annotations: `def method(self):`

**Protocol Method Parameters:**
```python
# ❌ WRONG - Protocol methods missing parameter types
class DataHandler(Protocol):
    def handle(self, data): ...
    def process(self, input, count): ...

# ✅ CORRECT - All Protocol method parameters typed
class DataHandler(Protocol):
    def handle(self, data: bytes) -> None: ...
    def process(self, input: str, count: int) -> bool: ...
```

**Why This Rule Exists:**
- Enables complete static type checking
- Prevents type-related bugs
- Improves code clarity and maintainability
- Makes refactoring safer
- Provides better IDE support
- Ensures Protocol interfaces are fully typed

### Python Variable Types and Type Safety

**🚨 FORBIDDEN: Partially unknown types - All variables must have explicit type annotations**

**❌ WRONG - Implicit typing creates partially unknown types:**
```python
all_files = []                    # Type: list[Unknown]
config = {}                       # Type: dict[Unknown, Unknown]  
result = None                     # Type: None (loses type info)
data = get_some_data()            # Type: Unknown
```

**✅ CORRECT - Explicit type annotations prevent unknown types:**
```python
all_files: list[str] = []         # Type: list[str]
config: dict[str, Any] = {}       # Type: dict[str, Any]
result: Optional[str] = None      # Type: str | None
data: ResponseData = get_some_data()  # Type: ResponseData
```

**🚨 CRITICAL: Lists MUST be properly and fully typed**

**❌ WRONG - Implicit list typing:**
```python
mylist = []                       # Type: list[Unknown] - BAD!
items = []                        # Type: list[Unknown] - BAD!
results = []                      # Type: list[Unknown] - BAD!
```

**✅ CORRECT - Explicit list typing:**
```python
mylist: list[str] = []            # Type: list[str] - GOOD!
items: list[int] = []             # Type: list[int] - GOOD!
results: list[dict[str, Any]] = [] # Type: list[dict[str, Any]] - GOOD!
```

**Why explicit types are mandatory:**
- ✅ **IDE support** - Better autocomplete and error detection
- ✅ **Type safety** - Catches type errors at development time
- ✅ **Documentation** - Code is self-documenting with clear types
- ✅ **Refactoring safety** - Type changes are caught throughout codebase
- ✅ **Runtime validation** - Works with `@typechecked` decorator

**Function signatures must also have explicit types:**
```python
# ❌ WRONG - Missing type annotations
def process_files(files, config):
    return []

# ✅ CORRECT - Complete type annotations
def process_files(files: list[str], config: dict[str, Any]) -> list[str]:
    return []

# ✅ CORRECT - With Optional and complex types
from typing import Optional, Union
def parse_data(data: str, timeout: Optional[int] = None) -> Union[dict[str, Any], None]:
    return {}
```

**🚨 CRITICAL: TUPLES FOR MULTIPLE RETURN VALUES ARE FORBIDDEN**

**NEVER use tuples for multiple return values - use dataclass structs instead:**

**❌ WRONG - Tuples have no named fields:**
```python
def compile_examples() -> tuple[int, int, float]:
    return successful_count, failed_count, compile_time

def link_programs() -> tuple[int, int]:
    return linked_count, failed_count

# Usage becomes unclear and error-prone
success, failed, time = compile_examples()  # Which is which?
a, b = link_programs()  # What do a and b represent?
```

**✅ CORRECT - Dataclass structs with named fields:**
```python
@dataclass
class CompilationResult:
    successful_count: int
    failed_count: int
    compile_time: float

@dataclass  
class LinkingResult:
    linked_count: int
    failed_count: int

def compile_examples() -> CompilationResult:
    return CompilationResult(
        successful_count=success,
        failed_count=failed,
        compile_time=time
    )

def link_programs() -> LinkingResult:
    return LinkingResult(linked_count=linked, failed_count=failed)

# Usage is clear and self-documenting
result = compile_examples()
print(f"Success: {result.successful_count}, Failed: {result.failed_count}")
```

**When tuples ARE acceptable:**
- ✅ **Coordinates/positions**: `point: tuple[float, float]` (x, y coordinates)
- ✅ **Immutable pairs**: `key_value: tuple[str, Any]` (dict items)
- ✅ **Type annotations**: `Union[tuple[str, int], tuple[str, str]]` (variant types)
- ✅ **Single conceptual unit**: `rgb: tuple[int, int, int]` (color components)

**Key principle:** If the tuple elements have different semantic meanings, use a dataclass instead.

**🚨 CRITICAL: Python functions SHOULD NOT return dict UNLESS ABSOLUTELY NECESSARY.**

**Use dataclass structs for type-checked arguments and return values instead of raw dictionaries:**

**❌ WRONG - Returning raw dict:**
```python
def parse_args(...) -> argparse.Namespace:
    # Returns argparse namespace
    
def get_config(...) -> dict:
    return {"name": "test", "enabled": True}
```

**✅ CORRECT - Using @typechecked dataclass structs:**
```python
from dataclasses import dataclass
from typeguard import typechecked

@typechecked
@dataclass
class Args:
    val: int
    name: str
    enabled: bool
    
    def __post_init__(self):
        # Only business logic validation - types are auto-validated by @typechecked!
        if self.val < 0:
            raise ValueError("val must be non-negative")

def parse_args(...) -> Args:
    # Use argparse here, then convert to Args dataclass
    parsed = parser.parse_args()
    return Args(
        val=parsed.val,
        name=parsed.name,
        enabled=parsed.enabled
    )

@typechecked
@dataclass 
class Config:
    name: str
    enabled: bool
    timeout: int = 30  # Default value
    
    def __post_init__(self):
        # Only business logic validation - types are auto-validated by @typechecked!
        if not self.name:
            raise ValueError("name cannot be empty")
        if self.timeout <= 0:
            raise ValueError("timeout must be positive")

def get_config(...) -> Config:
    return Config(name="test", enabled=True)
```

**Benefits of @typechecked dataclass approach:**
- ✅ **Automatic type safety** - `@typechecked` validates all types at runtime automatically
- ✅ **Minimal boilerplate** - No manual `isinstance()` checks needed
- ✅ **Clear separation** - `__post_init__` only for business logic, not type validation
- ✅ **IDE support** - Better autocomplete and type hints
- ✅ **Documentation** - Self-documenting parameter structure
- ✅ **Refactoring safety** - Changes to structure are caught at compile time
- ✅ **Testing** - Easier to create test data with known structure

**When dict IS acceptable:**
- ✅ **Temporary internal data** that won't cross function boundaries
- ✅ **JSON parsing results** that are immediately converted to dataclasses
- ✅ **Configuration dictionaries** from external sources (but convert to dataclass ASAP)
- ✅ **Dynamic data** where the keys are not known at design time

### @typechecked Decorator Usage

**🚨 MANDATORY: Use @typechecked decorator for all dataclasses with type annotations**

```python
from dataclasses import dataclass
from typeguard import typechecked

@typechecked
@dataclass
class CompilerSettings:
    compiler_path: str
    optimization_level: int
    debug_symbols: bool
    include_paths: list[str]
    
    def __post_init__(self):
        # Only business logic validation - NO manual type checking needed!
        if not self.compiler_path:
            raise ValueError("compiler_path cannot be empty")
        if self.optimization_level not in [0, 1, 2, 3]:
            raise ValueError(f"optimization_level must be 0-3, got {self.optimization_level}")
        if not all(isinstance(path, str) for path in self.include_paths):
            raise TypeError("include_paths must contain only strings")
```

**Key Benefits:**
- ✅ **Zero boilerplate** - No manual `isinstance()` checks
- ✅ **Automatic validation** - All type annotations enforced at runtime
- ✅ **Better error messages** - Clear type mismatch errors from typeguard
- ✅ **Focus on business logic** - `__post_init__` only for domain validation

**Example Type Validation:**
```python
# ✅ This works
settings = CompilerSettings(
    compiler_path="/usr/bin/gcc",
    optimization_level=2,
    debug_symbols=True,
    include_paths=["/usr/include", "/opt/local/include"]
)

# ❌ This raises TypeError automatically
settings = CompilerSettings(
    compiler_path="/usr/bin/gcc",
    optimization_level="O2",  # TypeError: should be int
    debug_symbols=True,
    include_paths=["/usr/include"]
)
```

**Migration strategy for existing code:**
1. **Identify functions returning dict** - prioritize public APIs first
2. **Create equivalent @typechecked dataclass** with same fields
3. **Add @typechecked decorator** and remove manual type validation
4. **Update function signature** to return dataclass
5. **Add conversion logic** from internal dict to dataclass
6. **Update callers** to use dataclass fields instead of dict keys
7. **Simplify __post_init__** to only business logic validation

### parse_args Function Signature Requirements
**🚨 CRITICAL: All `parse_args` functions MUST accept an optional `list[str]` parameter for custom argument parsing.**

**Function signature pattern:**
```python
def parse_args(args: Optional[list[str]] = None) -> YourDataClass:
    """Parse command line arguments
    
    Args:
        args: Optional list of arguments to parse. If None, uses sys.argv
        
    Returns:
        Parsed arguments as a dataclass
    """
    parser = argparse.ArgumentParser(description="Your description")
    # ... configure parser ...
    
    # Parse from custom args or sys.argv
    parsed = parser.parse_args(args)
    
    # Convert to dataclass
    return YourDataClass(
        field1=parsed.field1,
        field2=parsed.field2,
        # ... other fields
    )
```

**Benefits of optional args parameter:**
- ✅ **Testing flexibility** - Easy to test with custom argument lists
- ✅ **Library usage** - Functions can be called programmatically with specific args
- ✅ **Scripting integration** - Can be used in automation without modifying sys.argv
- ✅ **Backward compatibility** - Default behavior (None) maintains existing functionality

**Examples:**
```python
# Normal usage (uses sys.argv)
args = parse_args()

# Testing usage with custom arguments
args = parse_args(["--verbose", "--output", "test.txt"])

# Programmatic usage
args = parse_args(["--config", config_file, "--debug"])
```

**Why:** This pattern enables flexible argument parsing for testing, scripting, and programmatic usage while maintaining backward compatibility with existing code that relies on sys.argv parsing.

### Python Command Construction

**🚨 MANDATORY: Use subprocess.list2cmdline() for all command construction - NO EXCEPTIONS!**

**❌ WRONG - Using " ".join() for command construction:**
```python
# DANGEROUS - Breaks with spaces and special characters
cmd_str = " ".join(cmd_list)
command = " ".join(["python", "-m", "ziglang", "ar", "--option", "value with spaces"])
# Result: python -m ziglang ar --option value with spaces  (BROKEN!)
```

**✅ CORRECT - Using subprocess.list2cmdline():**
```python
import subprocess

# SAFE - Properly escapes spaces and special characters
cmd_str = subprocess.list2cmdline(cmd_list)
command = subprocess.list2cmdline(["python", "-m", "ziglang", "ar", "--option", "value with spaces"])
# Result: python -m ziglang ar --option "value with spaces"  (CORRECT!)
```

**Why subprocess.list2cmdline() is mandatory:**
- ✅ **Proper Escaping** - Handles spaces and special characters correctly
- ✅ **Cross-Platform** - Works correctly on Windows, macOS, and Linux
- ✅ **Security** - Prevents command injection vulnerabilities
- ✅ **Reliability** - Avoids broken commands from malformed argument joining

**When this rule applies:**
- ✅ **Command line construction** for subprocess calls
- ✅ **Debug output** showing commands that will be executed
- ✅ **Error messages** displaying failed commands
- ✅ **Logging** command execution for troubleshooting
- ✅ **Any scenario** where command arguments are joined into a string

**Key principle:** Never use `" ".join()` for command construction. Always use `subprocess.list2cmdline()` to ensure proper escaping and cross-platform compatibility.

### Python Import Organization

**🚨 MANDATORY: All system imports must be at the top of the file - NO EXCEPTIONS!**

**❌ WRONG - Imports inside functions:**
```python
def test_archive(self):
    import sys  # BAD - Import inside function
    import os   # BAD - Import inside function
    sys.argv.append("--test")
    os.path.exists("/tmp")
```

**✅ CORRECT - Imports at module level:**
```python
import sys
import os

def test_archive(self) -> None:
    sys.argv.append("--test")
    os.path.exists("/tmp")
```

**Import organization rules:**
- ✅ **Standard library imports** - Always at the top (sys, os, subprocess, etc.)
- ✅ **Third-party imports** - After standard library imports
- ✅ **Local imports** - After third-party imports  
- ✅ **Alphabetical ordering** - Within each group, sort alphabetically
- ✅ **Blank lines** - Separate each group with a blank line

**Correct import structure:**
```python
# Standard library imports
import os
import subprocess
import sys
from pathlib import Path

# Third-party imports
import pytest
from typeguard import typechecked

# Local imports
from ci.compiler.clang_compiler import BuildFlags
from ci.util.paths import PROJECT_ROOT
```

**Rare exceptions (use sparingly):**
- ✅ **Conditional imports** - When import depends on runtime conditions
- ✅ **Circular import avoidance** - When needed to break circular dependencies
- ✅ **Optional dependencies** - When gracefully handling missing packages

**Key principle:** Module-level imports improve readability, enable static analysis, and make dependencies explicit. Function-level imports should be avoided except in exceptional circumstances.

### Python Exception Handling Rules

**🚨 MANDATORY: All Python try-catch blocks must follow these requirements:**

1. **NO BARE EXCEPTIONS** - Always specify the exception type
2. **KEYBOARD INTERRUPT HANDLER** - Must handle `KeyboardInterrupt` with proper cleanup
3. **PROPER EXCEPTION ORDER** - `KeyboardInterrupt` first, then specific exceptions

**✅ CORRECT Exception Handling Pattern:**
```python
import _thread

def risky_operation():
    try:
        # Your code that might raise exceptions
        result = some_operation()
        return result
    except KeyboardInterrupt:
        # MANDATORY: Handle Ctrl+C gracefully
        print("Operation interrupted by user")
        _thread.interrupt_main()  # Propagate interrupt to main thread
        raise  # Re-raise to ensure proper cleanup
    except FileNotFoundError as e:
        # Specific exception handling
        print(f"File not found: {e}")
        return None
    except ValueError as e:
        # Another specific exception
        print(f"Invalid value: {e}")
        return None
    except Exception as e:
        # Generic handler (only if absolutely necessary)
        print(f"Unexpected error: {e}")
        raise  # Re-raise unknown exceptions
```

**❌ FORBIDDEN Exception Patterns:**
```python
try:
    some_operation()
except:  # ❌ NO BARE EXCEPTIONS
    pass

try:
    some_operation()
except Exception:  # ❌ MISSING KeyboardInterrupt HANDLER
    pass

try:
    some_operation()
except Exception as e:  # ❌ WRONG ORDER - KeyboardInterrupt should come first
    handle_error(e)
except KeyboardInterrupt:
    cleanup()
```

**Key Requirements:**
- ✅ **Import `_thread`** when using `KeyboardInterrupt` handler
- ✅ **Call `_thread.interrupt_main()`** in `KeyboardInterrupt` handler
- ✅ **Handle `KeyboardInterrupt` FIRST** before other exceptions
- ✅ **Specify exact exception types** instead of bare `except:`
- ✅ **Re-raise `KeyboardInterrupt`** after cleanup to maintain interrupt behavior

**MANDATORY when catching general Exception:** Whenever you catch a general `Exception`, you MUST also include an explicit `KeyboardInterrupt` handler, and it MUST appear before the general `Exception` clause.

Wrong:
```python
try:
    my_function()
except Exception:
    continue
```

Right:
```python
import _thread  # module-level import required by our import rules

try:
    my_function()
except KeyboardInterrupt:
    _thread.interrupt_main()
    print("Keyboard interrupt!")
    raise
except Exception as e:
    # Handle or re-raise as appropriate for your context
    raise
```

**Complex Exception Handling Example:**
```python
import _thread
import sys

def complex_operation():
    try:
        with open("config.json") as f:
            data = json.load(f)
        
        for item in data:
            process_item(item)
            
    except KeyboardInterrupt:
        print("⚠️  Operation interrupted by user - cleaning up...")
        cleanup_resources()
        _thread.interrupt_main()
        raise
    except FileNotFoundError:
        print("❌ Configuration file not found")
        sys.exit(1)
    except json.JSONDecodeError as e:
        print(f"❌ Invalid JSON in config file: {e}")
        sys.exit(1)
    except ValueError as e:
        print(f"❌ Invalid configuration value: {e}")
        sys.exit(1)
    except Exception as e:
        print(f"❌ Unexpected error during operation: {e}")
        cleanup_resources()
        raise
```

**Why These Rules:**
- **Keyboard interrupt handling** ensures graceful shutdown when user presses Ctrl+C
- **No bare exceptions** prevents masking unexpected errors and makes debugging easier
- **Proper exception order** ensures interrupt signals are handled before other error conditions
- **`_thread.interrupt_main()`** ensures the main thread receives the interrupt signal for proper cleanup

### Python Thread Keyboard Interrupt Handling

**🚨 MANDATORY: All Python threads MUST handle KeyboardInterrupt with thread identification and stack trace:**

**✅ REQUIRED Thread Interrupt Pattern:**
```python
import _thread
import threading
import traceback

def thread_worker():
    """All thread functions must follow this pattern"""
    thread_id = threading.current_thread().ident
    thread_name = threading.current_thread().name
    
    try:
        # Your thread work here
        while True:
            do_work()
            
    except KeyboardInterrupt:
        # MANDATORY: Print thread identification and stack trace
        print(f"🛑 Thread {thread_id} ({thread_name}) caught KeyboardInterrupt")
        print(f"📍 Stack trace for thread {thread_id}:")
        traceback.print_exc()
        
        # MANDATORY: Propagate interrupt to main thread
        _thread.interrupt_main()
        
        # Optional: Thread-specific cleanup
        cleanup_thread_resources()
        
        # MANDATORY: Re-raise to ensure proper shutdown
        raise
    except Exception as e:
        # Handle other exceptions after KeyboardInterrupt
        print(f"❌ Thread {thread_id} ({thread_name}) error: {e}")
        traceback.print_exc()
        raise

# Example thread creation
worker_thread = threading.Thread(target=thread_worker, name="WorkerThread", daemon=True)
worker_thread.start()
```

**Key Thread Interrupt Requirements:**
- ✅ **Thread identification** - Always print thread ID and name on interrupt
- ✅ **Stack trace** - Always print full stack trace with `traceback.print_exc()`
- ✅ **Main thread notification** - Always call `_thread.interrupt_main()`
- ✅ **Proper cleanup** - Perform thread-specific cleanup before re-raising
- ✅ **Re-raise interrupt** - Always re-raise KeyboardInterrupt for proper shutdown
- ✅ **Daemon threads** - Use `daemon=True` for background threads

**Thread Interrupt Example with Cleanup:**
```python
import _thread
import threading
import traceback
import time

def background_processor():
    """Example background thread with proper interrupt handling"""
    thread_id = threading.current_thread().ident
    thread_name = threading.current_thread().name
    
    try:
        print(f"🔄 Thread {thread_id} ({thread_name}) started")
        
        while True:
            # Simulate work
            process_data()
            time.sleep(1)
            
    except KeyboardInterrupt:
        print(f"🛑 Thread {thread_id} ({thread_name}) caught KeyboardInterrupt")
        print(f"📍 Stack trace for thread {thread_id}:")
        traceback.print_exc()
        
        # Thread-specific cleanup
        print(f"🧹 Thread {thread_id} cleaning up resources...")
        close_connections()
        save_state()
        
        # Propagate to main thread
        _thread.interrupt_main()
        raise
    except Exception as e:
        print(f"❌ Thread {thread_id} ({thread_name}) unexpected error: {e}")
        traceback.print_exc()
        _thread.interrupt_main()
        raise

# Start background thread
processor = threading.Thread(
    target=background_processor, 
    name="BackgroundProcessor", 
    daemon=True
)
processor.start()
```

**Why Thread Interrupt Handling is Critical:**
- **Debugging** - Thread ID and stack traces help identify where interrupts occur
- **Clean shutdown** - Proper cleanup prevents resource leaks and corruption
- **Signal propagation** - `_thread.interrupt_main()` ensures main thread gets interrupt
- **Process coordination** - All threads must cooperate for graceful shutdown
- **Error visibility** - Stack traces show exact execution context during interrupt

### Avoid std:: Prefixed Functions
**DO NOT use `std::` prefixed functions or headers in the codebase.** This project provides its own STL-equivalent implementations under the `fl::` namespace.

**Examples of what to avoid and use instead:**

**Headers:**

**Core Language Support:**
- ❌ `#include <type_traits>` → ✅ `#include "fl/type_traits.h"`
- ❌ `#include <algorithm>` → ✅ `#include "fl/algorithm.h"`
- ❌ `#include <functional>` → ✅ `#include "fl/functional.h"`
- ❌ `#include <initializer_list>` → ✅ `#include "fl/initializer_list.h"`

**Containers:**
- ❌ `#include <vector>` → ✅ `#include "fl/vector.h"`
- ❌ `#include <map>` → ✅ `#include "fl/map.h"`
- ❌ `#include <unordered_map>` → ✅ `#include "fl/hash_map.h"`
- ❌ `#include <unordered_set>` → ✅ `#include "fl/hash_set.h"`
- ❌ `#include <set>` → ✅ `#include "fl/set.h"`
- ❌ `#include <span>` → ✅ `#include "fl/slice.h"`

**Utilities & Smart Types:**
- ❌ `#include <optional>` → ✅ `#include "fl/optional.h"`
- ❌ `#include <variant>` → ✅ `#include "fl/variant.h"`
- ❌ `#include <utility>` → ✅ `#include "fl/pair.h"` (for std::pair)
- ❌ `#include <string>` → ✅ `#include "fl/string.h"`
- ❌ `#include <memory>` → ✅ `#include "fl/scoped_ptr.h"` or `#include "fl/stl/shared_ptr.h"`

**Stream/IO:**
- ❌ `#include <sstream>` → ✅ `#include "fl/sstream.h"`

**Threading:**
- ❌ `#include <thread>` → ✅ `#include "fl/thread.h"`

**Math & System:**
- ❌ `#include <cmath>` → ✅ `#include "fl/math.h"`
- ❌ `#include <cstdint>` → ✅ `#include "fl/stdint.h"`

**Functions and classes:**
- ❌ `std::move()` → ✅ `fl::move()`
- ❌ `std::forward()` → ✅ `fl::forward()`
- ❌ `std::vector` → ✅ `fl::vector`
- ❌ `std::enable_if` → ✅ `fl::enable_if`

**Why:** The project maintains its own implementations to ensure compatibility across all supported platforms and to avoid bloating the library with unnecessary STL dependencies.

**Before using any standard library functionality, check if there's a `fl::` equivalent in the `src/fl/` directory first.**

### Compiler Warning Suppression
**ALWAYS use the FastLED compiler control macros from `fl/compiler_control.h` for warning suppression.** This ensures consistent cross-compiler support and proper handling of platform differences.

**Correct Warning Suppression Pattern:**
```cpp
#include "fl/compiler_control.h"

// Suppress specific warning around problematic code
FL_DISABLE_WARNING_PUSH
FL_DISABLE_FORMAT_TRUNCATION  // Use specific warning macros
// ... code that triggers warnings ...
FL_DISABLE_WARNING_POP
```

**Available Warning Suppression Macros:**
- ✅ `FL_DISABLE_WARNING_PUSH` / `FL_DISABLE_WARNING_POP` - Standard push/pop pattern
- ✅ `FL_DISABLE_WARNING(warning_name)` - Generic warning suppression (use sparingly)
- ✅ `FL_DISABLE_WARNING_GLOBAL_CONSTRUCTORS` - Clang global constructor warnings
- ✅ `FL_DISABLE_WARNING_SELF_ASSIGN_OVERLOADED` - Clang self-assignment warnings  
- ✅ `FL_DISABLE_FORMAT_TRUNCATION` - GCC format truncation warnings

**What NOT to do:**
- ❌ **NEVER use raw `#pragma` directives** - they don't handle compiler differences
- ❌ **NEVER write manual `#ifdef __clang__` / `#ifdef __GNUC__` blocks** - use the macros
- ❌ **NEVER ignore warnings without suppression** - fix the issue or suppress appropriately

**Examples:**
```cpp
// ✅ CORRECT - Using FastLED macros
#include "fl/compiler_control.h"

FL_DISABLE_WARNING_PUSH
FL_DISABLE_FORMAT_TRUNCATION
// Code that triggers format truncation warnings
sprintf(small_buffer, "Very long format string %d", value);
FL_DISABLE_WARNING_POP

// ❌ INCORRECT - Raw pragma directives
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wformat-truncation"
sprintf(small_buffer, "Very long format string %d", value);
#pragma GCC diagnostic pop
```

**Why:** The FastLED compiler control system automatically handles:
- **Compiler detection** (GCC vs Clang vs MSVC)  
- **Version compatibility** (warnings that don't exist on older compilers)
- **Platform specifics** (AVR, ESP32, ARM, etc.)
- **Consistent naming** across different compiler warning systems

### Debug Printing
**Use `FL_WARN` for debug printing throughout the codebase.** This ensures consistent debug output that works in both unit tests and live application testing.

**Usage:**
- ✅ `FL_WARN("Debug message: " << message);`
- ❌ `FL_WARN("Value: %d", value);`

**Why:** `FL_WARN` provides a unified logging interface that works across all platforms and testing environments, including unit tests and Arduino sketches.

### Emoticon and Emoji Usage Policy
**NO emoticons or emoji characters are allowed in C++ source files.** This ensures professional, maintainable code that works correctly across all platforms and development environments.

**Prohibited in C++ Files:**
- ❌ **C++ source files** (*.cpp, *.c)
- ❌ **C++ header files** (*.h, *.hpp)
- ❌ **Comments in C++ files** - use clear text instead
- ❌ **String literals in C++ code** - use descriptive text
- ❌ **Log messages in C++ code** - use text prefixes like "SUCCESS:", "ERROR:", "WARNING:"

**Examples of what NOT to do in C++ files:**
```cpp
// ❌ BAD - Emoticons in comments
// 🎯 This function handles user input

// ❌ BAD - Emoticons in log messages  
FL_WARN("✅ Operation successful!");
FL_WARN("❌ Error occurred: " << error_msg);

// ❌ BAD - Emoticons in string literals
const char* status = "🔄 Processing...";
```

**Examples of correct alternatives in C++ files:**
```cpp
// ✅ GOOD - Clear text in comments
// TUTORIAL: This function handles user input

// ✅ GOOD - Text prefixes in log messages
FL_WARN("SUCCESS: Operation completed successfully!");
FL_WARN("ERROR: Failed to process request: " << error_msg);

// ✅ GOOD - Descriptive text in string literals  
const char* status = "PROCESSING: Request in progress...";
```

**Allowed in Python Files:**
- ✅ **Python source files** (*.py) - emoticons are acceptable for build scripts, tools, and utilities
- ✅ **Python comments and docstrings** - can use emoticons for clarity in development tools
- ✅ **Python log messages** - emoticons OK in build/test output for visual distinction

**Why:** 
- **Cross-platform compatibility** - Some compilers/platforms have issues with Unicode characters
- **Professional codebase** - Maintains serious, enterprise-grade appearance
- **Accessibility** - Screen readers and text-based tools work better with plain text
- **Consistency** - Ensures uniform code style across all C++ files
- **Debugging** - Text-based prefixes are easier to search and filter in logs

**Before adding any visual indicators to C++ code, use text-based alternatives like "TODO:", "NOTE:", "WARNING:", "SUCCESS:", "ERROR:" prefixes.**

### Naming Conventions
**Follow these naming conventions for consistency across the codebase:**

**Simple Objects:**
- ✅ Use lowercase class names for simple objects (e.g., `fl::vec2f`, `fl::point`, `fl::rect`)
- ❌ Avoid: `fl::Vec2f`, `fl::Point`, `fl::Rect`

**Complex Objects:**
- ✅ Use CamelCase with uppercase first character for complex objects (e.g., `Raster`, `Controller`, `Canvas`)
- ❌ Avoid: `raster`, `controller`, `canvas`

**Pixel Types:**
- ✅ Use ALL CAPS for pixel types (e.g., `CRGB`, `CHSV`, `HSV16`, `RGB24`)
- ❌ Avoid: `crgb`, `Crgb`, `chsv`, `Chsv`

**Member Variables and Functions:**

**Complex Classes/Objects:**
- ✅ **Member variables:** Use `mVariableName` format (e.g., `mPixelCount`, `mBufferSize`, `mCurrentIndex`)
- ✅ **Member functions:** Use camelCase (e.g., `getValue()`, `setPixelColor()`, `updateBuffer()`)
- ❌ Avoid: `m_variable_name`, `variableName`, `GetValue()`, `set_pixel_color()`

**Simple Classes/Structs:**
- ✅ **Member variables:** Use lowercase snake_case (e.g., `x`, `y`, `width`, `height`, `pixel_count`)
- ✅ **Member functions:** Use camelCase (e.g., `getValue()`, `setPosition()`, `normalize()`)
- ❌ Avoid: `mX`, `mY`, `get_value()`, `set_position()`

**Examples:**

```cpp
// Complex class - use mVariableName for members
class Controller {
private:
    int mPixelCount;           // ✅ Complex class member variable
    uint8_t* mBuffer;          // ✅ Complex class member variable
    bool mIsInitialized;       // ✅ Complex class member variable
    
public:
    void setPixelCount(int count);  // ✅ Complex class member function
    int getPixelCount() const;      // ✅ Complex class member function
    void updateBuffer();            // ✅ Complex class member function
};

// Simple struct - use snake_case for members
struct vec2 {
    int x;                     // ✅ Simple struct member variable
    int y;                     // ✅ Simple struct member variable
    
    float magnitude() const;   // ✅ Simple struct member function
    void normalize();          // ✅ Simple struct member function
};

struct point {
    float x;                   // ✅ Simple struct member variable
    float y;                   // ✅ Simple struct member variable
    float z;                   // ✅ Simple struct member variable
    
    void setPosition(float x, float y, float z);  // ✅ Simple struct member function
    float distanceTo(const point& other) const;   // ✅ Simple struct member function
};
```

**Why:** These conventions help distinguish between different categories of objects and maintain consistency with existing FastLED patterns. Complex classes use Hungarian notation for member variables to clearly distinguish them from local variables, while simple structs use concise snake_case for lightweight data containers.

### Container Parameter Types
**Prefer `fl::span<T>` over `fl::vector<T>` or arrays for function parameters.** `fl::span<T>` provides a non-owning view that automatically converts from various container types, making APIs more flexible and efficient.

**Examples:**
- ✅ `void processData(fl::span<const uint8_t> data)` - accepts arrays, vectors, and other containers
- ❌ `void processData(fl::vector<uint8_t>& data)` - only accepts fl::Vector
- ❌ `void processData(uint8_t* data, size_t length)` - requires manual length tracking

**Benefits:**
- **Automatic conversion:** `fl::span<T>` can automatically convert from `fl::vector<T>`, C-style arrays, and other container types
- **Type safety:** Maintains compile-time type checking while being more flexible than raw pointers
- **Performance:** Zero-cost abstraction that avoids unnecessary copying or allocation
- **Consistency:** Provides a uniform interface for working with contiguous data

**When to use `fl::vector<T>` instead:**
- When you need ownership and dynamic resizing capabilities
- When storing data as a class member that needs to persist

**Why:** Using `fl::span<T>` for parameters makes functions more reusable and avoids forcing callers to convert their data to specific container types.

### Exception Handling
**DO NOT use try-catch blocks or C++ exception handling in the codebase.** FastLED is designed to work on embedded systems like Arduino where exception handling may not be available or desired due to memory and performance constraints.

**Examples of what to avoid and use instead:**

**Avoid Exception Handling:**
- ❌ `try { ... } catch (const std::exception& e) { ... }` - Exception handling not available on many embedded platforms
- ❌ `throw std::runtime_error("error message")` - Throwing exceptions not supported
- ❌ `#include <exception>` or `#include <stdexcept>` - Exception headers not needed

**Use Error Handling Alternatives:**
- ✅ **Return error codes:** `bool function() { return false; }` or custom error enums
- ✅ **Optional types:** `fl::optional<T>` for functions that may not return a value
- ✅ **Assertions:** `FL_ASSERT(condition)` for debug-time validation
- ✅ **Early returns:** `if (!valid) return false;` for error conditions
- ✅ **Status objects:** Custom result types that combine success/failure with data

**Examples of proper error handling:**
```cpp
// Good: Using return codes
bool initializeHardware() {
    if (!setupPins()) {
        FL_WARN("Failed to setup pins");
        return false;
    }
    return true;
}

// Good: Using fl::optional
fl::optional<float> calculateValue(int input) {
    if (input < 0) {
        return fl::nullopt;  // No value, indicates error
    }
    return fl::make_optional(sqrt(input));
}

// Good: Using early returns
void processData(const uint8_t* data, size_t len) {
    if (!data || len == 0) {
        FL_WARN("Invalid input data");
        return;  // Early return on error
    }
    // Process data...
}
```

**Why:** Many embedded platforms (especially Arduino-compatible boards) don't support C++ exceptions or have them disabled to save memory and improve performance. FastLED must work reliably across all supported platforms.

### JSON Usage - Ideal API Patterns
**🎯 PREFERRED: Use the modern `fl::Json` class for all JSON operations.** FastLED provides an ideal JSON API that prioritizes type safety, ergonomics, and crash-proof operation.

**✅ IDIOMATIC JSON USAGE:**
```cpp
// NEW: Clean, safe, idiomatic API
fl::Json json = fl::Json::parse(jsonStr);
int brightness = json["config"]["brightness"] | 128;  // Gets value or 128 default
string name = json["device"]["name"] | string("default");  // Type-safe with default
bool enabled = json["features"]["networking"] | false;  // Never crashes

// Array operations
if (json["effects"].contains("rainbow")) {
    // Safe array checking
}
```

**❌ DISCOURAGED: Verbose legacy API:**
```cpp
// OLD: Verbose, error-prone API (still works, but not recommended)
fl::JsonDocument doc;
fl::string error;
fl::parseJson(jsonStr, &doc, &error);
int brightness = doc["config"]["brightness"].as<int>();  // Can crash if missing
```

**Key Benefits of Ideal API:**
- **🛡️ Type Safety** - No crashes on missing fields or type mismatches
- **🎯 Default Values** - Clean `json["key"] | default` syntax
- **📖 Readable Code** - 50% less boilerplate for common operations
- **🚀 Testing** - Easy test data construction with `JsonBuilder`

**📚 Reference Example:** See `examples/Json/Json.ino` for comprehensive usage patterns and API comparison.

**Testing with JsonBuilder:**
```cpp
// Easy test data construction
auto json = JsonBuilder()
    .set("brightness", 128)
    .set("enabled", true)
    .set("name", "test_device")
    .build();

// Type-safe testing
CHECK_EQ(json["brightness"] | 0, 128);
CHECK(json["enabled"] | false);
```

**🎯 GUIDELINE:** Always prefer the ideal `fl::Json` API for new code. The legacy `fl::parseJson` API remains available for backward compatibility but should be avoided in new implementations.

## ⚠️ CRITICAL WARNING: C++ ↔ JavaScript Bindings

**🚨 EXTREMELY IMPORTANT: DO NOT MODIFY FUNCTION SIGNATURES IN WEBASSEMBLY BINDINGS WITHOUT EXTREME CAUTION! 🚨**

The FastLED project includes WebAssembly (WASM) bindings that bridge C++ and JavaScript code. **Changing function signatures in these bindings is a major source of runtime errors and build failures.**

### Key Binding Files (⚠️ HIGH RISK ZONE ⚠️):
- `src/platforms/wasm/js_bindings.cpp` - Main JavaScript interface via EM_ASM
- `src/platforms/wasm/ui.cpp` - UI update bindings with extern "C" wrappers  
- `src/platforms/wasm/active_strip_data.cpp` - Strip data bindings via EMSCRIPTEN_BINDINGS
- `src/platforms/wasm/fs_wasm.cpp` - File system bindings via EMSCRIPTEN_BINDINGS

### Before Making ANY Changes to These Files:

1. **🛑 STOP and consider if the change is absolutely necessary**
2. **📖 Read the warning comments at the top of each binding file**  
3. **🧪 Test extensively on WASM target after any changes**
4. **🔗 Verify both C++ and JavaScript sides remain synchronized**
5. **📝 Update corresponding JavaScript code if function signatures change**

### Common Binding Errors:
- **Parameter type mismatches** (e.g., `const char*` vs `std::string`)
- **Return type changes** that break JavaScript expectations
- **Function name changes** without updating JavaScript calls
- **Missing `extern "C"` wrappers** for EMSCRIPTEN_KEEPALIVE functions
- **EMSCRIPTEN_BINDINGS macro changes** without updating JS Module calls

### If You Must Modify Bindings:
1. **Update BOTH sides simultaneously** (C++ and JavaScript)
2. **Maintain backward compatibility** when possible
3. **Add detailed comments** explaining the interface contract
4. **Test thoroughly** with real WASM builds, not just compilation
5. **Update documentation** and interface specs

**Remember: The bindings are a CONTRACT between C++ and JavaScript. Breaking this contract causes silent failures and mysterious bugs that are extremely difficult to debug.**

## 🚨 WASM PLATFORM SPECIFIC RULES 🚨

### WASM Build Awareness

**Root Cause**: Multiple .cpp files are compiled together, causing:
- Duplicate function definitions
- Type signature conflicts
- Symbol redefinition errors

**MANDATORY RULES:**
- **NEVER create duplicate function definitions** across WASM .cpp files
- **USE `EMSCRIPTEN_KEEPALIVE` functions as canonical implementations**
- **MATCH Emscripten header signatures exactly** for external C functions
- **REMOVE conflicting implementations** and add explanatory comments

**Fix Pattern Example:**
```cpp
// In timer.cpp (CANONICAL)
extern "C" {
EMSCRIPTEN_KEEPALIVE uint32_t millis() {
    // Implementation
}
}

// In js.cpp (FIXED)
extern "C" {
// NOTE: millis() and micros() functions are defined in timer.cpp with EMSCRIPTEN_KEEPALIVE  
// to avoid duplicate definitions in unified builds
}
```

### WASM Async Platform Pump Pattern

**🚨 CRITICAL: Avoid long blocking sleeps that prevent responsive async processing**

**MANDATORY RULES:**
- **AVOID long blocking sleeps** (e.g., `emscripten_sleep(100)`) in main loops
- **USE short sleep intervals** (1ms) for responsive yielding in main loops
- **ALLOW JavaScript to control timing** via extern functions rather than blocking C++ loops

**Correct Implementation:**
```cpp
// ✅ GOOD - responsive yielding without blocking
while (true) {
    // Keep pthread alive for extern function calls
    // Use short sleep for responsiveness
    emscripten_sleep(1);    // 1ms yield for responsiveness
}
```

**Why This Matters:**
- Long blocking sleeps prevent responsive browser interaction
- JavaScript should control FastLED timing via requestAnimationFrame
- Short sleep intervals maintain responsiveness while allowing other threads to work

### WASM Function Signature Matching

**🚨 CRITICAL: External C function declarations must match Emscripten headers exactly**

**Common Error Pattern:**
```cpp
// ❌ WRONG - causes compilation error
extern "C" void emscripten_sleep(int ms);

// ✅ CORRECT - matches official Emscripten header  
extern "C" void emscripten_sleep(unsigned int ms);
```

**MANDATORY RULES:**
- **ALWAYS verify against official Emscripten header signatures**
- **NEVER assume parameter types** - check the actual headers
- **UPDATE signatures immediately** when compilation errors occur

### WASM Sketch Compilation

**🎯 HOW TO COMPILE ANY ARDUINO SKETCH TO WASM:**

**Basic Compilation Commands:**
```bash
# Compile any sketch directory to WASM
uv run ci/wasm_compile.py path/to/your/sketch

# Quick compile test (compile only, no browser)
uv run ci/wasm_compile.py path/to/your/sketch --just-compile

# Compile examples/Blink to WASM
uv run ci/wasm_compile.py examples/Blink --just-compile

# Compile examples/NetTest to WASM (test fetch API)
uv run ci/wasm_compile.py examples/NetTest --just-compile

# Compile examples/DemoReel100 to WASM  
uv run ci/wasm_compile.py examples/DemoReel100 --just-compile
```

**Output:** Creates `fastled_js/` folder with:
- `fastled.js` - JavaScript loader
- `fastled.wasm` - WebAssembly binary
- `index.html` - HTML page to run the sketch

**Run in Browser:**
```bash
# Simple HTTP server to test
cd fastled_js
python -m http.server 8000
# Open http://localhost:8000
```

**🚨 REQUIREMENTS:**
- **Docker must be installed and running**
- **Internet connection** (for Docker image download on first run)
- **~1GB RAM** for Docker container during compilation

### WASM Testing Requirements

**🚨 MANDATORY: Always test WASM compilation after platform file changes**

**Platform Testing Commands:**
```bash
# Test WASM platform changes (for platform developers)
uv run ci/wasm_compile.py examples/wasm --just-compile

# Quick compile test for any sketch (compile only, no browser)
uv run ci/wasm_compile.py examples/Blink --just-compile

# Quick compile test for NetTest example  
uv run ci/wasm_compile.py examples/NetTest --just-compile

# Quick test without full build
uv run ci/wasm_compile.py examples/wasm --quick
```

**Watch For These Error Patterns:**
- `error: conflicting types for 'function_name'`
- `error: redefinition of 'function_name'`  
- `warning: attribute declaration must precede definition`
- `RuntimeError: unreachable` (often async-related)

**MANDATORY RULES:**
- **ALWAYS test WASM compilation** after modifying any WASM platform files
- **USE `uv run ci/wasm_compile.py` for validation**
- **WATCH for unified build conflicts** in compilation output
- **VERIFY async operations work properly** in browser environment

### WASM Platform File Organization

**Best Practices for WASM platform files:**
- ✅ **Use `timer.cpp` for canonical timing functions** with `EMSCRIPTEN_KEEPALIVE`
- ✅ **Use `entry_point.cpp` for main() and setup/loop coordination** with async pumping
- ✅ **Use `js.cpp` for JavaScript utility functions** without duplicating timer functions
- ✅ **Include proper async infrastructure** (`fl/async.h`) in entry points
- ✅ **Comment when removing duplicate implementations** to explain unified build conflicts

## Testing
The project uses a comprehensive test suite including:
- C++ unit tests
- Platform compilation tests  
- Code quality checks (ruff, clang-format)
- Example compilation verification

### Test Assertion Macros
**🚨 CRITICAL: Always use the proper assertion macros for better error messages and debugging:**

**Equality Assertions:**
- ✅ **CORRECT**: `CHECK_EQ(A, B)` - for equality comparisons
- ❌ **INCORRECT**: `CHECK(A == B)` - provides poor error messages

**Inequality Assertions:**
- ✅ **CORRECT**: `CHECK_LT(A, B)` - for less than comparisons
- ✅ **CORRECT**: `CHECK_LE(A, B)` - for less than or equal comparisons
- ✅ **CORRECT**: `CHECK_GT(A, B)` - for greater than comparisons
- ✅ **CORRECT**: `CHECK_GE(A, B)` - for greater than or equal comparisons
- ❌ **INCORRECT**: `CHECK(A < B)`, `CHECK(A <= B)`, `CHECK(A > B)`, `CHECK(A >= B)`

**Boolean Assertions:**
- ✅ **CORRECT**: `CHECK_TRUE(condition)` - for true conditions
- ✅ **CORRECT**: `CHECK_FALSE(condition)` - for false conditions
- ❌ **INCORRECT**: `CHECK(condition)` - for boolean checks

**String Assertions:**
- ✅ **CORRECT**: `CHECK_STREQ(str1, str2)` - for string equality
- ✅ **CORRECT**: `CHECK_STRNE(str1, str2)` - for string inequality
- ❌ **INCORRECT**: `CHECK(str1 == str2)` - for string comparisons

**Floating Point Assertions:**
- ✅ **CORRECT**: `CHECK_DOUBLE_EQ(a, b)` - for floating point equality
- ✅ **CORRECT**: `CHECK_DOUBLE_NE(a, b)` - for floating point inequality
- ❌ **INCORRECT**: `CHECK(a == b)` - for floating point comparisons

**Examples:**
```cpp
// Good assertion usage
CHECK_EQ(expected_value, actual_value);
CHECK_LT(current_index, max_index);
CHECK_GT(temperature, 0.0);
CHECK_TRUE(is_initialized);
CHECK_FALSE(has_error);
CHECK_STREQ("expected", actual_string);
CHECK_DOUBLE_EQ(3.14159, pi_value, 0.001);

// Bad assertion usage
CHECK(expected_value == actual_value);  // Poor error messages
CHECK(current_index < max_index);       // Poor error messages
CHECK(is_initialized);                  // Unclear intent
CHECK("expected" == actual_string);     // Wrong comparison type
```

**Why:** Using the proper assertion macros provides:
- **Better error messages** with actual vs expected values
- **Clearer intent** about what is being tested
- **Consistent debugging** across all test failures
- **Type safety** for different comparison types

### Blank Test Template
**✅ CORRECT blank test file structure:**

```cpp
// Unit tests for general allocator functionality and integration tests

#include "test.h"
#include "FastLED.h"

using namespace fl;


TEST_CASE("New test - fill in") {

} 
```

**❌ WRONG patterns to avoid:**
- Missing descriptive file header comment
- Missing proper includes (`test.h`, `FastLED.h`)
- Missing `using namespace fl;` declaration
- Empty or non-descriptive test case names
- Inconsistent formatting and spacing

### Test File Creation Guidelines
**🚨 CRITICAL: Minimize test file proliferation - Consolidate tests whenever possible**

**PREFERRED APPROACH:**
- ✅ **CONSOLIDATE:** Add new test cases to existing related test files
- ✅ **EXTEND:** Expand existing `TEST_CASE()` blocks with additional scenarios
- ✅ **REUSE:** Leverage existing test infrastructure and helper functions
- ✅ **COMPREHENSIVE:** Create single comprehensive test files that cover entire feature areas

**CREATE NEW TEST FILES ONLY WHEN:**
- ✅ **Testing completely new subsystems** with no existing related tests
- ✅ **Isolated feature areas** that don't fit logically into existing test structure
- ✅ **Complex integration tests** that require dedicated setup/teardown

**AVOID:**
- ❌ **Creating new test files for minor bug fixes** - add to existing tests
- ❌ **One test case per file** - consolidate related functionality
- ❌ **Duplicate test patterns** across multiple files
- ❌ **Scattered feature testing** - keep related tests together

**EXAMPLES:**

**✅ GOOD - Consolidation:**
```cpp
// Add to existing tests/test_json_comprehensive.cpp
TEST_CASE("JSON - New Feature Addition") {
    // Add new functionality tests to existing comprehensive file
}
```

**❌ BAD - Proliferation:**
```cpp
// Don't create tests/test_json_new_feature.cpp for minor additions
// Instead add to existing comprehensive test file
```

**DEVELOPMENT WORKFLOW:**
1. **During Development/Bug Fixing:** Temporary test files are acceptable for rapid iteration
2. **Near Completion:** **MANDATORY** - Consolidate temporary tests into existing files
3. **Final Review:** Remove temporary test files and ensure comprehensive coverage in main test files

**CONSOLIDATION CHECKLIST:**
- [ ] Can this test be added to an existing `TEST_CASE` in the same file?
- [ ] Does an existing test file cover the same functional area?
- [ ] Would this test fit better as a sub-section of a comprehensive test?
- [ ] Are there duplicate test patterns that can be eliminated?

**Why:** Maintaining a clean, consolidated test suite:
- **Easier maintenance** - fewer files to manage and update
- **Better organization** - related functionality tested together
- **Faster builds** - fewer compilation units
- **Cleaner repository** - less file clutter
- **Improved discoverability** - easier to find existing test coverage

### Test Execution Format
**🚨 CRITICAL: Always use the correct test execution format:**
- ✅ **CORRECT**: `bash test <test_name>` (e.g., `bash test audio_json_parsing`)
- ❌ **INCORRECT**: `./.build/bin/test_<test_name>.exe`
- ❌ **INCORRECT**: Running executables directly

**Examples:**
- `bash test` - Run all tests (includes debug symbols)
- `bash test audio_json_parsing` - Run specific test
- `bash test xypath` - Run test_xypath.cpp
- `bash compile uno --examples Blink` - Compile examples

**Quick Build Options:**
- `bash test --quick --cpp` - Quick C++ tests only (when no *.py changes)
- `bash test --quick` - Quick tests including Python (when *.py changes)

**Why:** The `bash test` wrapper handles platform differences, environment setup, and proper test execution across all supported systems.

Use `bash test` as specified in user rules for running unit tests. For compilation tests, use `bash compile <platform> --examples <example>` (e.g., `bash compile uno --examples Blink`).

**🚨 FOR BACKGROUND AGENTS:** Running `bash test` is MANDATORY before indicating completion. Use the MCP server `validate_completion` tool to ensure all tests pass before completing any task.

## Debugging and Stack Traces

### Stack Trace Setup
The FastLED project supports enhanced debugging through stack trace functionality for crash analysis and debugging.

**For Background Agents**: Use the MCP server tool `setup_stack_traces` to automatically install and configure stack trace support:

```bash
# Via MCP server (recommended for background agents)
uv run mcp_server.py
# Then use setup_stack_traces tool with method: "auto"
```

**Manual Installation**:

**Ubuntu/Debian**:
```bash
sudo apt-get update
sudo apt-get install -y libunwind-dev build-essential
```

**CentOS/RHEL/Fedora**:
```bash
sudo yum install -y libunwind-devel gcc-c++  # CentOS/RHEL
sudo dnf install -y libunwind-devel gcc-c++  # Fedora
```

**macOS**:
```bash
brew install libunwind
```

### Available Stack Trace Methods
1. **LibUnwind** (Recommended) - Enhanced stack traces with symbol resolution
2. **Execinfo** (Fallback) - Basic stack traces using standard glibc
3. **Windows** (On Windows) - Windows-specific debugging APIs
4. **No-op** (Last resort) - Minimal crash handling

The build system automatically detects and configures the best available option.

### Testing Stack Traces
```bash
# Run the test suite which includes stack trace tests
uv run test.py --cpp

# Test executables are in .build/meson-quick/tests/
```

### Using in Code
```cpp
#include "tests/crash_handler.h"

int main() {
    setup_crash_handler();  // Enable crash handling
    // Your code here...
    return 0;
}
```

**For Background Agents**: Always run the `setup_stack_traces` MCP tool when setting up a new environment to ensure proper debugging capabilities are available.

## Platform Build Information Analysis

The FastLED project includes comprehensive tools for analyzing platform-specific build information, including preprocessor defines, compiler flags, and toolchain paths from `build_info.json` files generated during compilation.

### Overview

Platform build information is stored in `.build/{platform}/build_info.json` files that are automatically generated when compiling for any platform. These files contain:

- **Platform Defines** - Preprocessor definitions (`#define` values) specific to each platform
- **Compiler Information** - Paths, flags, and types for C/C++ compilers
- **Toolchain Aliases** - Tool paths for gcc, g++, ar, objcopy, nm, etc.
- **Build Configuration** - Framework, build type, and other settings

### Quick Start

#### 1. Generate Build Information

Before analyzing, ensure you have compiled the platform:

```bash
# Compile a platform to generate build_info.json
uv run ci/ci-compile.py uno --examples Blink
uv run ci/ci-compile.py esp32dev --examples Blink
```

This creates `.build/{platform}/build_info.json` with all platform information.

#### 2. Analyze Platform Defines

**Get platform-specific preprocessor defines:**
```bash
# Command line tool
uv run python ci/ci/build_info_analyzer.py --board uno --show-defines

# Via MCP server
uv run mcp_server.py
# Use build_info_analysis tool with: board="uno", show_defines=true
```

**Example output for UNO:**
```
📋 Platform Defines for UNO:
  PLATFORMIO=60118
  ARDUINO_AVR_UNO
  F_CPU=16000000L
  ARDUINO_ARCH_AVR
  ARDUINO=10808
  __AVR_ATmega328P__
```

**Example output for ESP32:**
```
📋 Platform Defines for ESP32DEV:
  ESP32=ESP32
  ESP_PLATFORM
  F_CPU=240000000L
  ARDUINO_ARCH_ESP32
  IDF_VER="v5.3.2-174-g083aad99cf-dirty"
  ARDUINO_ESP32_DEV
  # ... and 23 more defines
```

#### 3. Compare Platforms

**Compare defines between platforms:**
```bash
# Command line
uv run python ci/ci/build_info_analyzer.py --compare uno esp32dev

# Via MCP 
# Use build_info_analysis tool with: board="uno", compare_with="esp32dev"
```

Shows differences and commonalities between platform defines.

### Available Tools

#### Command Line Tool

**Basic Usage:**
```bash
# List available platforms
uv run python ci/ci/build_info_analyzer.py --list-boards

# Show platform defines
uv run python ci/ci/build_info_analyzer.py --board uno --show-defines

# Show compiler information
uv run python ci/ci/build_info_analyzer.py --board esp32dev --show-compiler

# Show toolchain aliases
uv run python ci/ci/build_info_analyzer.py --board teensy31 --show-toolchain

# Show everything
uv run python ci/ci/build_info_analyzer.py --board digix --show-all

# Compare platforms
uv run python ci/ci/build_info_analyzer.py --compare uno esp32dev

# JSON output for automation
uv run python ci/ci/build_info_analyzer.py --board uno --show-defines --json
```

#### MCP Server Tool

**For Background Agents**, use the MCP server `build_info_analysis` tool:

```bash
# Start MCP server
uv run mcp_server.py

# Use build_info_analysis tool with parameters:
# - board: "uno", "esp32dev", "teensy31", etc. or "list" to see available
# - show_defines: true/false (default: true)
# - show_compiler: true/false  
# - show_toolchain: true/false
# - show_all: true/false
# - compare_with: "other_board_name" for comparison
# - output_json: true/false for programmatic use
```

### Supported Platforms

The build info analysis works with **ANY platform** that generates a `build_info.json` file:

**Embedded Platforms:**
- ✅ **UNO (AVR)** - 8-bit microcontroller (6 defines)
- ✅ **ESP32DEV** - WiFi-enabled 32-bit platform (29 defines)
- ✅ **ESP32S3, ESP32C3, ESP32C6** - All ESP32 variants
- ✅ **TEENSY31, TEENSYLC** - ARM Cortex-M platforms
- ✅ **DIGIX, BLUEPILL** - ARM Cortex-M3 platforms
- ✅ **STM32, NRF52** - Various ARM platforms
- ✅ **RPIPICO, RPIPICO2** - Raspberry Pi Pico platforms
- ✅ **ATTINY85, ATTINY1616** - Small AVR microcontrollers

### Use Cases

#### For Code Development

**Understanding Platform Differences:**
```bash
# See what defines are available for conditional compilation
uv run python ci/ci/build_info_analyzer.py --board esp32dev --show-defines

# Compare two platforms to understand differences
uv run python ci/ci/build_info_analyzer.py --compare uno esp32dev
```

**Compiler and Toolchain Information:**
```bash
# Get compiler paths and flags for debugging builds
uv run python ci/ci/build_info_analyzer.py --board teensy31 --show-compiler

# Get toolchain paths for symbol analysis
uv run python ci/ci/build_info_analyzer.py --board digix --show-toolchain
```

#### For Automation

**JSON output for scripts:**
```bash
# Get defines as JSON for processing
uv run python ci/ci/build_info_analyzer.py --board uno --show-defines --json

# Get all build info as JSON
uv run python ci/ci/build_info_analyzer.py --board esp32dev --show-all --json
```

### Integration with Other Tools

Build info analysis integrates with other FastLED tools:

1. **Symbol Analysis** - Uses build_info.json to find toolchain paths
2. **Compilation** - Generated automatically during example compilation  
3. **Testing** - Provides platform context for test results

### Troubleshooting

**Common Issues:**

1. **"No boards with build_info.json found"**
   - **Solution:** Compile a platform first: `uv run ci/ci-compile.py {board} --examples Blink`

2. **"Board key not found in build_info.json"**
   - **Solution:** Check available boards: `uv run python ci/ci/build_info_analyzer.py --list-boards`

3. **"Build info not found for platform"**
   - **Solution:** Ensure the platform compiled successfully and check `.build/{board}/build_info.json` exists

### Best Practices

1. **Always compile first** before analyzing build information
2. **Use comparison feature** to understand platform differences
3. **Check defines** when adding platform-specific code
4. **Use JSON output** for automated processing and CI/CD
5. **Combine with symbol analysis** for complete platform understanding

**For Background Agents:** Use the MCP server `build_info_analysis` tool for consistent access to platform build information and proper error handling.

## Symbol Analysis for Binary Optimization

The FastLED project includes comprehensive symbol analysis tools to identify optimization opportunities and understand binary size allocation across all supported platforms.

### Overview

Symbol analysis examines compiled ELF files to:
- **Identify large symbols** that may be optimization targets
- **Understand memory allocation** across different code sections
- **Find unused features** that can be eliminated to reduce binary size
- **Compare symbol sizes** between different builds or platforms
- **Provide optimization recommendations** based on actual usage patterns

### Supported Platforms

The symbol analysis tools work with **ANY platform** that generates a `build_info.json` file, including:

**Embedded Platforms:**
- ✅ **UNO (AVR)** - Small 8-bit microcontroller (typically ~3-4KB symbols)
- ✅ **ESP32DEV (Xtensa)** - WiFi-enabled 32-bit platform (typically ~200-300KB symbols)
- ✅ **ESP32S3, ESP32C3, ESP32C6, etc.** - All ESP32 variants supported

**ARM Platforms:**
- ✅ **TEENSY31 (ARM Cortex-M4)** - High-performance 32-bit (typically ~10-15KB symbols)
- ✅ **TEENSYLC (ARM Cortex-M0+)** - Low-power ARM platform (typically ~8-10KB symbols)
- ✅ **DIGIX (ARM Cortex-M3)** - Arduino Due compatible (typically ~15-20KB symbols)
- ✅ **STM32 (ARM Cortex-M3)** - STMicroelectronics platform (typically ~12-18KB symbols)

**And many more!** Any platform with toolchain support and `build_info.json` generation.

### Quick Start

#### 1. Prerequisites

Before running symbol analysis, ensure you have compiled the platform:

```bash
# Compile platform first (required step)
uv run ci/ci-compile.py uno --examples Blink
uv run ci/ci-compile.py esp32dev --examples Blink
uv run ci/ci-compile.py teensy31 --examples Blink
```

This generates the required `.build/{platform}/build_info.json` file and ELF binary.

#### 2. Run Symbol Analysis

**Analyze specific platform:**
```bash
uv run ci/ci/symbol_analysis.py --board uno
uv run ci/ci/symbol_analysis.py --board esp32dev
uv run ci/ci/symbol_analysis.py --board teensy31
```

**Analyze all available platforms at once:**
```bash
uv run ci/demo_symbol_analysis.py
```

**Using MCP Server (Recommended for Background Agents):**
```bash
# Use MCP server tools
uv run mcp_server.py
# Then use symbol_analysis tool with board: "uno" or "auto"
# Or use symbol_analysis tool with run_all_platforms: true
```

### Analysis Output

Symbol analysis provides detailed reports including:

**Summary Information:**
- **Total symbols count** and **total size**
- **Symbol type breakdown** (text, data, bss, etc.)
- **Platform-specific details** (toolchain, ELF file location)

**Largest Symbols List:**
- **Top symbols by size** for optimization targeting
- **Demangled C++ names** for easy identification
- **Size in bytes** and **percentage of total**

**Optimization Recommendations:**
- **Feature analysis** - unused features that can be disabled
- **Size impact estimates** - potential savings from removing features
- **Platform-specific suggestions** based on symbol patterns

### Example Analysis Results

**UNO Platform (Small embedded):**
```
================================================================================
UNO SYMBOL ANALYSIS REPORT
================================================================================

SUMMARY:
  Total symbols: 51
  Total symbol size: 3767 bytes (3.7 KB)

LARGEST SYMBOLS (sorted by size):
   1.  1204 bytes - ClocklessController<...>::showPixels(...)
   2.   572 bytes - CFastLED::show(unsigned char)
   3.   460 bytes - main
   4.   204 bytes - CPixelLEDController<...>::show(...)
```

**ESP32 Platform (Feature-rich):**
```
================================================================================
ESP32DEV SYMBOL ANALYSIS REPORT  
================================================================================

SUMMARY:
  Total symbols: 2503
  Total symbol size: 237092 bytes (231.5 KB)

LARGEST SYMBOLS (sorted by size):
   1. 12009 bytes - _vfprintf_r
   2. 11813 bytes - _svfprintf_r
   3.  8010 bytes - _vfiprintf_r
   4.  4192 bytes - port_IntStack
```

### Advanced Features

#### JSON Output
Save detailed analysis results for programmatic processing:
```bash
uv run symbol_analysis.py --board esp32dev --output-json
# Results saved to: .build/esp32dev_symbol_analysis.json
```

#### Batch Analysis
Analyze multiple platforms in sequence:
```bash
for board in uno esp32dev teensy31; do
    uv run symbol_analysis.py --board $board
done
```

#### Integration with Build Systems
The symbol analysis can be integrated into automated build processes:
```python
# In your Python build script
import subprocess
result = subprocess.run(['uv', 'run', 'symbol_analysis.py', '--board', 'uno'], 
                       capture_output=True, text=True)
```

### MCP Server Tools

**For Background Agents**, use the MCP server tools for symbol analysis:

1. **Generic Symbol Analysis** (`symbol_analysis` tool):
   - Works with **any platform** (UNO, ESP32, Teensy, STM32, etc.)
   - Auto-detects available platforms from `.build/` directory
   - Can analyze single platform or all platforms simultaneously
   - Provides comprehensive usage instructions

2. **ESP32-Specific Analysis** (`esp32_symbol_analysis` tool):
   - **ESP32 platforms only** with FastLED-focused filtering
   - Includes feature analysis and optimization recommendations
   - FastLED-specific symbol identification and grouping

**Usage via MCP:**
```bash
# Start MCP server
uv run mcp_server.py

# Use symbol_analysis tool with parameters:
# - board: "uno", "esp32dev", or "auto"
# - run_all_platforms: true/false
# - output_json: true/false
```

### Troubleshooting

**Common Issues:**

1. **"build_info.json not found"**
   - **Solution:** Compile the platform first: `uv run ci/ci-compile.py {board} --examples Blink`

2. **"ELF file not found"**
   - **Solution:** Ensure compilation completed successfully and check `.build/{board}/` directory

3. **"Tool not found"** (nm, c++filt, etc.)
   - **Solution:** The platform toolchain isn't installed or configured properly
   - **Check:** Verify PlatformIO platform installation: `uv run pio platform list`

4. **"No symbols found"**
   - **Solution:** The ELF file may be stripped or compilation failed
   - **Check:** Verify ELF file exists and has debug symbols

**Debug Mode:**
```bash
# Run with verbose Python output for debugging
uv run python -v ci/ci/symbol_analysis.py --board uno
```

### Best Practices

1. **Always compile first** before running symbol analysis
2. **Use consistent examples** (like Blink) for size comparisons
3. **Run analysis on clean builds** to avoid cached/incremental build artifacts
4. **Compare results across platforms** to understand feature scaling
5. **Focus on the largest symbols first** for maximum optimization impact
6. **Use JSON output for automated processing** and trend analysis

**For Background Agents:** Always use the MCP server `symbol_analysis` tool for consistent results and proper error handling.