- You are a Svelte developer
- Use SvelteKit for the framework
- Use TailwindCSS for styling
- Use TypeScript
- Use the canonical SvelteKit file structure:
  ```
  src/
    actions/
    components/
    data/
    routes/
    runes/
    styles/
    utils/

## Build & Development Commands
- yarn create tauri-app my-tauri-app --template svelte to create app
- yarn tauri dev to build in dev

## Testing Guidelines
- Test, test, test as we add new features
- Test both frontend and backend

## Code Style & Guidelines 
- Follow SOLID principles
- separate concerns
- keep it DRY
- document code using docstrings

## Documentation Guidelines 
- Yarn 2 API is different from Yarn 1. Check the docs

# Solid principles

You *MUST* abide by SOLID principles:

- Single Responsibility Principle (SRP): A class or module should have only one reason to change, meaning it should have a single, focused purpose. 
- Open/Closed Principle (OCP): Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
- Liskov Substitution Principle (LSP): Subtypes should be substitutable for their base types without altering the correctness of the program. 
- Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they don't use. 
- Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions. 

# Keep it dry

You should keep it D.R.Y — do not repeat your code

# Keep it simple

Keep it simple, stupid — favour simplicity 

# Separate concerns

Divide the code into distinct modules or components, each responsible for a specific task or area of functionality. 

# Abstraction


Hide complex implementation details and expose only the necessary interface, making code more manageable and reusable

# Clean Code

Prioritize code readability, maintainability, and clarity. Follow coding style guidelines and use meaningful names

# Documentation

Provide clear and concise comments to explain complex logic and design decisions. Specifically use doctrings to make code readable by computers and people 

# Testing

Write unit tests and integration tests to verify code correctness and prevent regressions

# Robustness

- Design code to handle unexpected inputs or errors gracefully, preventing crashes or unexpected behavior
- Avoid Premature Optimization:
- Focus on writing clear and correct code first, then optimize only where necessary

# Law of Demeter


Each unit should only interact with its immediate neighbors, minimizing dependencies between unrelated parts of the code.

Project uses Rust, Tauri and Swelte

Ensure you use Tauri 2 API docs -- ih context -- as the package differs from Tauri 1 in considerable respects, and there are breaking changes

Use Cargo to write a comprehensive suite of unit tests for this function