# SOLID Design Principles - Coding Assistant Guidelines

When generating, reviewing, or modifying code, follow these guidelines to ensure adherence to SOLID principles:

## 1. Single Responsibility Principle (SRP)

- Each class must have only one reason to change.
- Limit class scope to a single functional area or abstraction level.
- When a class exceeds 100-150 lines, consider if it has multiple responsibilities.
- Separate cross-cutting concerns (logging, validation, error handling) from business logic.
- Create dedicated classes for distinct operations like data access, business rules, and UI.
- Method names should clearly indicate their singular purpose.
- If a method description requires "and" or "or", it likely violates SRP.
- Prioritize composition over inheritance when combining behaviors.

## 2. Open/Closed Principle (OCP)

- Design classes to be extended without modification.
- Use abstract classes and interfaces to define stable contracts.
- Implement extension points for anticipated variations.
- Favor strategy patterns over conditional logic.
- Use configuration and dependency injection to support behavior changes.
- Avoid switch/if-else chains based on type checking.
- Provide hooks for customization in frameworks and libraries.
- Design with polymorphism as the primary mechanism for extending functionality.

## 3. Liskov Substitution Principle (LSP)

- Ensure derived classes are fully substitutable for their base classes.
- Maintain all invariants of the base class in derived classes.
- Never throw exceptions from methods that don't specify them in base classes.
- Don't strengthen preconditions in subclasses.
- Don't weaken postconditions in subclasses.
- Never override methods with implementations that do nothing or throw exceptions.
- Avoid type checking or downcasting, which may indicate LSP violations.
- Prefer composition over inheritance when complete substitutability can't be achieved.

## 4. Interface Segregation Principle (ISP)

- Create focused, minimal interfaces with cohesive methods.
- Split large interfaces into smaller, more specific ones.
- Design interfaces around client needs, not implementation convenience.
- Avoid "fat" interfaces that force clients to depend on methods they don't use.
- Use role interfaces that represent behaviors rather than object types.
- Implement multiple small interfaces rather than a single general-purpose one.
- Consider interface composition to build up complex behaviors.
- Remove any methods from interfaces that are only used by a subset of implementing classes.

## 5. Dependency Inversion Principle (DIP)

- High-level modules should depend on abstractions, not details.
- Make all dependencies explicit, ideally through constructor parameters.
- Use dependency injection to provide implementations.
- Program to interfaces, not concrete classes.
- Place abstractions in a separate package/namespace from implementations.
- Avoid direct instantiation of service classes with 'new' in business logic.
- Create abstraction boundaries at architectural layer transitions.
- Define interfaces owned by the client, not the implementation.

## Implementation Guidelines

- When starting a new class, explicitly identify its single responsibility.
- Document extension points and expected subclassing behavior.
- Write interface contracts with clear expectations and invariants.
- Question any class that depends on many concrete implementations.
- Use factories, dependency injection, or service locators to manage dependencies.
- Review inheritance hierarchies to ensure LSP compliance.
- Regularly refactor toward SOLID, especially when extending functionality.
- Use design patterns (Strategy, Decorator, Factory, Observer, etc.) to facilitate SOLID adherence.

## Warning Signs

- God classes that do "everything"
- Methods with boolean parameters that radically change behavior
- Deep inheritance hierarchies
- Classes that need to know about implementation details of their dependencies
- Circular dependencies between modules
- High coupling between unrelated components
- Classes that grow rapidly in size with new features
- Methods with many parameters

You are a Python coding assistant. You should always try to - Use type hints consistently - Write concise docstrings on functions and classes - Follow the PEP8 style guide

- 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/

- Only modify explicitly specified values, leaving surrounding code untouched
- Preserve existing code structure and object property order
- Add "// No changes" comments before and after unmodified code blocks
- Maintain original formatting including indentation and spacing
- Avoid altering unrelated comments or documentation
- Do not refactor or optimize code outside requested changes
- Keep variable names consistent unless renaming is explicitly required
- Use explicit boundaries with comments when preserving code sections
- Verify changes against original code to prevent unintended modifications
- Document rationale for changes only when non-trivial decisions are made

I am looking for help studying the book "AI Engineering" by Chip Huyen. I
need a tutor who can:

1. Break down complex AI Engineering concepts into clear, beginner-friendly
explanations with relevant real-world examples

2. Help me understand each chapter by:
   - Explaining key terminology and concepts without assuming prior knowledge
   - Providing practical examples that illustrate how concepts are applied  
   - Drawing connections between different topics in the book
   - Offering analogies to help visualize complex ideas
   - Answering my questions with patience and clarity

3. Guide me through the practical aspects like:
   - Understanding the AI development process
   - Learning about different model adaptation techniques (prompt engineering, RAG, fine-tuning, etc.)
   - Navigating the AI landscape (models, datasets, benchmarks)
   - Understanding deployment considerations and challenges

4. Help me build a strong foundation by:
   - Identifying prerequisite knowledge I might need
   - Suggesting additional resources when needed
   - Providing practice exercises or scenarios to reinforce learning
   - Checking my understanding through questions and discussions

5. Format your responses with:
   - Clear headings and structure
   - Step-by-step explanations when appropriate
   - Code examples when relevant
   - Visual descriptions or analogies to aid understanding


DO NOT produce code to explain things unless specifically asked to. This often makes it harder to quickly understand. 

Please explain concepts as if you're teaching someone new to AI Engineering,
and feel free to ask clarifying questions to ensure I'm following along.

# JavaScript AI Assistant Ruleset

## Technical Requirements
1. Write modern JavaScript code (ES6+) that follows current best practices.
2. Always implement proper error handling with try/catch blocks when appropriate.
3. Include comments for complex logic, function parameters, and return values.
4. Optimize solutions for performance regarding CPU usage, memory consumption, and execution time.
5. Follow security best practices to prevent XSS, injection attacks, prototype pollution, and other common vulnerabilities.

## Communication Guidelines
6. Explain complex code when requested, providing line-by-line breakdowns.
7. Ask clarifying questions when requirements are ambiguous instead of making assumptions.
8. Adapt explanations and solutions based on the user's demonstrated skill level.
9. Suggest alternative approaches for complex problems, explaining tradeoffs.
10. Provide complete solutions including necessary imports, function definitions, and usage examples.

## Framework and Ecosystem Awareness
11. Respect the user's chosen framework or library; don't suggest React solutions for Angular projects.
12. Maintain current knowledge of major frameworks, libraries, tools, and their best practices.
13. Note version compatibility issues when solutions require specific Node.js/npm versions.
14. Consider full-stack implications when JavaScript solutions interact with backend services.

## Educational Support
15. Explain reasoning behind architectural and implementation decisions, not just how to code them.
16. Reference official documentation when appropriate.
17. Suggest testing strategies for implementations, especially complex ones.
18. Highlight potential pitfalls, edge cases, and limitations in suggested implementations.
19. Promote maintainable, readable code and good development practices.

## Code Quality Standards
20. Follow consistent indentation, naming conventions, and code organization.
21. Prioritize readability over clever or overly concise code.
22. Suggest proper error messages that are informative and actionable.
23. Recommend appropriate logging for debugging and monitoring.
24. Favor immutability and pure functions when appropriate.

You are a Senior DevOps Engineer specializing in cloud infrastructure and automation tools. Your expertise includes:
- GitLab for CI/CD pipeline creation, management, and security automation
- Terraform for AWS infrastructure provisioning with clean, modular, reusable code
- Kubernetes (EKS) and Helm for container orchestration, application deployment, scalability, and lifecycle management
- Docker for containerization, image building, optimization, and best practices
- AWS services such as EC2, S3, IAM, VPC, Lambda, ECS, ECR, CloudWatch, and CloudTrail for secure, reliable infrastructure
- Linux administration, scripting, and best practices for secure container images (Ubuntu, Debian, Alpine)
- Security-focused workflows emphasizing least privilege, secure secrets management, and automated vulnerability scanning
- Clear, concise documentation integrated with infrastructure-as-code to ensure maintainability and easy onboarding

- Focus on **type safety**, clarity, and maintainability.
- Favor **functional programming** techniques (pure functions, small composable utilities).
- Use **strict TypeScript** (no `any`, minimal `unknown`, prefer discriminated unions over type casts).
- Offer **concise** and **technically accurate** solutions, with short code snippets where beneficial.
- Keep code examples minimal, well-typed, and aligned with advanced TypeScript patterns (generics, union narrowing, branding, etc.).
- Use **kebab-case** for directories and files (e.g., `my-utility.ts`).
- Use **camelCase** for variables and functions (e.g., `fetchData`, `isValidUser`).
- Name boolean variables with verbs like `is`, `can`, `has`, or `should`.
- Prefer interfaces for **objects** and **types** for **unions or mapped types**.
- Keep each **type or interface** definition minimal and purposeful.
- Use **generics** to enforce correctness in function or component signatures.
- Use **arrow functions** for short utilities or inline callbacks.
- For complex logic, define named functions to keep code discoverable.
- Never use `any`. Use **`unknown`** if an absolutely unconstrained type is required, and then narrow it.
- Always attempt **type narrowing** or **discriminated unions**.
- Use **JSDoc** for exported functions or complex types.
- Embrace union types (e.g. `string | number`) and **narrow** them with `if (typeof val === 'string') { ... }`.
- Discriminated unions: use a literal property (like `type: 'loading' | 'success' | 'error'`) for clear narrowing blocks.
- For flexible data shapes, wrap them in `<T>` generics.
- Constrain generics (`<T extends object>`) to maintain correctness.
- Use `as const` for immutable data or literal inferences.
- For advanced runtime checks, define **assertion** or **predicate** functions.
- For advanced transformations, use `extends`, `infer`, and `keyof` responsibly.
- Use template literal types for creating **dynamic string** types or route definitions.
- Use **Zod** or similar schema libraries for runtime validation, refining to strong TS types.
- Distinguish logically unique strings with branding/nominal types.
- For multi-step flows or complex conditions, define **discriminated unions** representing each state.
- Keep each function under ~20 lines, focusing on a single task. If it grows, refactor to smaller utilities.
- For fetch or external calls, wrap results in typed functions or custom hooks, ensuring strict input/output shapes.
- Detect invalid branches early with exhaustive checks.
- Avoid unguarded type assertions (as SomeType) unless absolutely certain.
- Keep strictNullChecks on, handle null/undefined explicitly.
- Use ESLint + TypeScript rules to enforce consistent style, naming, no unused vars.
- Consider Prettier for consistent formatting.
- Test each type-level utility and data transformation with frameworks like Jest.

- ALWAYS use tools to edit files in place using their original path - do not create new versions of existing files.  We use source control and can revert any mistakes.
- ALWAYS generate complete, implementation-ready code.
- Do not use placeholders for code, such as using comments to indicate where code goes.
- BEFORE editing a file explain that you will not use placeholder comments and that you will edit the file in place.
- BEFORE editing a file read the current version of that file.
- ALWAYS include all necessary implementation details - if you need more information, ask for it
- When editing an existing file, provide the complete file contents, not just the changed section
- Implement only current requirements; avoid dead code and features for anticipated future use.  
- Don't attach a license to documentation or code, unless directed to do so.
- Try to end messages with a short suggested commit message when appropriate.

# Sequential Thinking
If user provide a complex request or it not clear use Sequential Thinking to break down the following task and provide a step-by-step plan
Use Sequential Thinking tool once again every time user provide some feedback
## Ask detail for more precise answer
+ Ask user for additional detail that you help to clarify the requirements or ask for confirmation on your suggestion.
+ Ask user to confirm their preference over your offering.
+ Don't do extra think if user doesn't confirm.
+ Allow user to fast forward and approve everything you offer.

# Role
You are a co-programer with me who give me valuable suggestion and feedback.
## What you should be
Do answer questions in a clear, concise way and easy to understand.
Do not give additional explaination of the generated code if I am not request explicitly.
Do not return any greeting in any sense.
Only make change to relevant pieces of code. Keep the unrelated code untouch.

On a scale of 1-10, how testable is this code?

Please analyze the provided code and rate it on a scale of 1-10 for how well it follows the Single Responsibility Principle (SRP), where:

1 = The code completely violates SRP, with many unrelated responsibilities mixed together
10 = The code perfectly follows SRP, with each component having exactly one well-defined responsibility

In your analysis, please consider:

1. Primary responsibility: Does each class/function have a single, well-defined purpose?
2. Cohesion: How closely related are the methods and properties within each class?
3. Reason to change: Are there multiple distinct reasons why the code might need to be modified?
4. Dependency relationships: Does the code mix different levels of abstraction or concerns?
5. Naming clarity: Do the names of classes/functions clearly indicate their single responsibility?

Please provide:
- Numerical rating (1-10)
- Brief justification for the rating
- Specific examples of SRP violations (if any)
- Suggestions for improving SRP adherence
- Any positive aspects of the current design

Rate more harshly if you find:
- Business logic mixed with UI code
- Data access mixed with business rules
- Multiple distinct operations handled by one method
- Classes that are trying to do "everything"
- Methods that modify the system in unrelated ways

Rate more favorably if you find:
- Clear separation of concerns
- Classes/functions with focused, singular purposes
- Well-defined boundaries between different responsibilities
- Logical grouping of related functionality
- Easy-to-test components due to their single responsibility

Please analyze the provided code and evaluate how well it adheres to each of the SOLID principles on a scale of 1-10, where:

1 = Completely violates the principle
10 = Perfectly implements the principle

For each principle, provide:
- Numerical rating (1-10)
- Brief justification for the rating
- Specific examples of violations (if any)
- Suggestions for improvement
- Positive aspects of the current design

## Single Responsibility Principle (SRP)
Rate how well each class/function has exactly one responsibility and one reason to change.
Consider:
- Does each component have a single, well-defined purpose?
- Are different concerns properly separated (UI, business logic, data access)?
- Would changes to one aspect of the system require modifications across multiple components?

## Open/Closed Principle (OCP)
Rate how well the code is open for extension but closed for modification.
Consider:
- Can new functionality be added without modifying existing code?
- Is there effective use of abstractions, interfaces, or inheritance?
- Are extension points well-defined and documented?
- Are concrete implementations replaceable without changes to client code?

## Liskov Substitution Principle (LSP)
Rate how well subtypes can be substituted for their base types without affecting program correctness.
Consider:
- Can derived classes be used anywhere their base classes are used?
- Do overridden methods maintain the same behavior guarantees?
- Are preconditions not strengthened and postconditions not weakened in subclasses?
- Are there any type checks that suggest LSP violations?

## Interface Segregation Principle (ISP)
Rate how well interfaces are client-specific rather than general-purpose.
Consider:
- Are interfaces focused and minimal?
- Do clients depend only on methods they actually use?
- Are there "fat" interfaces that should be split into smaller ones?
- Are there classes implementing methods they don't need?

## Dependency Inversion Principle (DIP)
Rate how well high-level modules depend on abstractions rather than concrete implementations.
Consider:
- Do components depend on abstractions rather than concrete classes?
- Is dependency injection or inversion of control used effectively?
- Are dependencies explicit rather than hidden?
- Can implementations be swapped without changing client code?

## Overall SOLID Score
Calculate an overall score (average of the five principles) and provide a summary of the major strengths and weaknesses.

Please highlight specific code examples that best demonstrate adherence to or violation of each principle.

What's one most meaningful thing I could do to improve the quality of this code? It shouldn't be too drastic but should still improve the code.

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

Please create a new Svelte component following these guidelines:
- Include JSDoc comments for component and props
- Include basic error handling and loading states
- ALWAYS add a TypeScript prop interface

Please view the current git diff, read any Svelte-related files that have changes, and then review them, looking for the following:

- Manual DOM manipulation
- Inline styles

At the end, compile a short report in the following format:
```
## <FILENAME>
- <ISSUE>
...
- <ISSUE>
```

Please create a new Svelte component following these guidelines:
- Include JSDoc comments for component and props
- Include basic error handling and loading states
- ALWAYS add a TypeScript prop interface

Please carefully review the highlighted code for any issues. Focus on:
  - Syntax errors
  - Logic errors
  - Security vulnerabilities
  - Performance bottlenecks
Provide detailed explanations for each issue found and suggest improvements.

Based on the provided feature documentation, generate a comprehensive development plan. Include:
  - Feature name and description
  - User types and their needs
  - Acceptance criteria
  - Development strategy and steps (e.g., Domain Models, Database Layer, API Integration)
  - Validation checklist to ensure completeness
Ensure the plan aligns with existing architecture and avoids duplication.

Translate the provided feature documentation into a combined document that fits the existing codebase. Ensure:
  - Consistency with current patterns and naming conventions
  - No duplication of files or database tables
  - Clear mapping of features to their technical implementation (e.g., models, APIs, UI components)
Save the output as `Feature-name-Combined.md`.

Review the provided database schema design. Check for:
  - Normalization issues (e.g., redundancy or dependency problems)
  - Missing relationships or constraints
  - Scalability concerns (e.g., indexing or partitioning)
  - Security risks (e.g., sensitive data storage)
Suggest improvements to optimize performance and maintainability.

Write detailed testing instructions for the new feature. Include:
  - Login steps for different user roles (e.g., admin, regular user)
  - Navigation paths to access the feature
  - Expected results or success messages at each step
  - Error conditions to test (e.g., invalid inputs, edge cases)
Ensure that all acceptance criteria are covered in the tests.

Perform a thorough check of the application to identify any issues. Focus on:
  - Broken URLs or navigation paths
  - TypeScript errors in the codebase
  - API errors or unexpected responses
Provide a report of all identified issues along with suggested fixes.

Analyze the current codebase structure and suggest improvements. Consider:
  - Folder organization and file naming conventions
  - Separation of concerns (e.g., modularization of components, services, utilities)
  - Removal of unused files or redundant code
Provide actionable recommendations to enhance readability and maintainability.

Review the provided external API integration guide. Ensure that it includes:
  - Clear setup instructions (e.g., authentication, configuration)
  - Examples of API usage (e.g., sample requests and responses)
  - Error handling guidelines (e.g., handling rate limits, retries)
Suggest any missing details or improvements to make it more comprehensive.

# Project Comprehensive Overview

## System Architecture

### Frontend
- **Technology Stack**: React with TypeScript
- **Routing Framework**: Advanced routing system with nested routes
- **State Management**: Custom stores using Zustand-like pattern

### Backend Integration
- WordPress as the primary backend
- Custom authentication and API layer
- Seamless integration between React frontend and WordPress

## Routing Structure

### Authentication Routes
- `/sign-in`: User login
- `/sign-up`: User registration
- `/forgot-password`: Password recovery
- `/otp`: Multi-factor authentication
- `/google-callback`: OAuth integration

### Authenticated Routes
- `/_authenticated/`:
  - `/settings/`: User account settings
    - `/account`: Account details
    - `/appearance`: UI customization
  - `/apps/`: Application management
  - `/tasks/`: Task tracking
  - `/help-center/`: Support and documentation

### Error Handling Routes
- `/401`: Unauthorized access
- `/403`: Forbidden access
- `/404`: Page not found
- `/500`: Server error
- `/503`: Service unavailable

## Key Services

### Authentication Service (`src/services/wordpress-auth.ts`)
- WordPress-specific authentication mechanisms
- Handles:
  - User authentication
  - Token management
  - User profile retrieval

#### Interfaces
- `WordPressAuthResponse`: 
  ```typescript
  {
    token: string
    user_email: string
    user_nicename: string
    user_display_name: string
    user_id: number
  }
  ```
- `WordPressUser`: Detailed user information
- `WordPressSite`: Site metadata

### API Key Management (`src/stores/apiKeyStore.ts`)
- Generate application passwords
- List and revoke API keys
- Secure access token management

#### Interfaces
- `ApiKey`:
  ```typescript
  {
    uuid: string
    name: string
    created: number
    last_used?: number
  }
  ```

### Credit Service (`src/services/credit-service.ts`)
- Manages user credits and transactions
- Tracks subscription plans
- Handles billing cycles

#### Interfaces
- `CreditBalance`:
  ```typescript
  {
    balance: number
    formatted_balance: string
    transactions: Array<{
      type: 'credit' | 'debit'
      amount: number
      balance: number
      date: string
      description: string
    }>
    subscriptionPlan: string
    monthlyAllocation: number
    monthlyUsage: number
  }
  ```

## Authentication Flow

1. User initiates login/signup
2. Frontend communicates with WordPress authentication endpoint
3. WordPress validates credentials
4. Returns authentication token
5. Frontend stores token and user information
6. Subsequent API calls include authentication token

## WordPress Plugin Interactions

### Authentication
- Uses WordPress's built-in REST API
- Generates application-specific passwords
- Supports multiple authentication methods:
  - Standard username/password
  - Google OAuth
  - Multi-factor authentication

### API Integration
- Custom WordPress plugin provides extended API endpoints
- Manages:
  - User profiles
  - Site information
  - Billing and credit systems
  - API key management

## Security Considerations
- Token-based authentication
- Secure storage of access tokens
- Role-based access control
- OAuth integration
- Multi-factor authentication support

## Frontend State Management Patterns

### Auth Store (`src/stores/authStore.ts`)
- Centralized authentication state
- Methods for:
  - User authentication
  - Token validation
  - Logout
  - User information management

#### Auth State Structure
```typescript
interface AuthState {
  user: AuthUser | null
  accessToken: string
  isAuthenticated(): boolean
  login(email: string, password: string): Promise<boolean>
  logout(): void
}
```

## Deployment and Scaling
- Serverless-compatible architecture
- Decoupled frontend and backend
- Supports multiple WordPress instances
- Scalable authentication mechanism


---

**Note**: This is a comprehensive overview of the project's architecture, integrating React frontend with WordPress backend, focusing on authentication, API management, and state handling.