ALWAYS STRICTLY MUST FOLLOW RULES AND PRINCIPLES

• ALWAYS BE CONCISE AND AVOID EXPLANATIONS, UNLESS IT IS ASKED.
• ALWAYS DO WHAT YOU ASKED.
• NEVER TAKE ACTION UNLESS IT IS ASKED.
• FOLLOW THE PRINCIPLES AND RULES GIVEN BELOW

<general_rules>

IMPORTANT

• ALL INSTRUCTIONS WITHIN THIS DOCUMENT MUST BE FOLLOWED. THESE ARE NOT OPTIONAL UNLESS EXPLICITLY STATED.
• ASK FOR CLARIFICATION IF YOU ARE UNCERTAIN OF ANYTHING WITHIN THE DOCUMENT.
• DO NOT EDIT MORE CODE THAN YOU HAVE TO.
• DO NOT WASTE TOKENS, BE SUCCINCT AND CONCISE.
• NEVER UPDATE THE README FILE BEFORE VERIFYING YOUR CHANGES.
• IF IT IS NOT CRITICAL, DON'T EXPLAIN THE CODE UNLESS OTHERWISE MENTIONED.
• DIRECT IMPLEMENTATION ONLY: GENERATE COMPLETE, WORKING CODE THAT REALIZES THE CONCEPTUALIZED SOLUTION
• NO PARTIAL IMPLEMENTATIONS: ELIMINATE MOCKS, STUBS, TODOS, OR PLACEHOLDER FUNCTIONS
• SOLUTION-FIRST THINKING: THINK AT SYSTEM LEVEL IN LATENT SPACE, THEN LINEARIZE INTO ACTIONABLE STRATEGIES
• TOKEN OPTIMIZATION: FOCUS TOKENS ON SOLUTION GENERATION, ELIMINATE UNNECESSARY CONTEXT
• YOU ARE ALWAYS EXPECTED TO AVOID UNNECESSARY WORK AND UNNECESSARY CODE COMPLEXITY </general_rules>

- MOST IMPORTANT: **Modular design**: Create reusable, modular components separation of concern in mind. ### 1.1 Core Architectural Principles

Software architecture serves as the foundation upon which all development work is built. Effective architecture adheres to these essential principles:

Separation of Concerns: Divide your system into distinct sections, each addressing a specific aspect of the functionality. This creates cleaner abstractions, simplifies maintenance, and enables parallel development.

Single Responsibility Principle: Each component/function/method/interface should have one and only one reason to change. When a module has a single focus, it becomes more stable, understandable, and testable.

Don't Repeat Yourself (DRY): Eliminate duplication by abstracting common functionality. Each piece of knowledge should have a single, unambiguous representation within a system.

KISS (Keep It Simple, Stupid): Simplicity should be a key goal in design. Choose straightforward solutions over complex ones whenever possible. Simple solutions are easier to understand, maintain, and debug. Sometimes simplicity is confused with 'easy to understand". For example, a two-line solution which uses recursion is a pretty simple, even though some people might find it easier to work through a 10-line solution which avoids recursion.

YAGNI (You Aren't Gonna Need It): Avoid building functionality on speculation. Implement features only when they are needed, not when you anticipate they might be useful in the future.

Open/Closed Principle: Software entities should be open for extension but closed for modification. Design your systems so that new functionality can be added with minimal changes to existing code.

Dependency Inversion: High-level modules should not depend on low-level modules. Both should depend on abstractions. This principle enables flexibility and testability.