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

When generating new codeblocks based off of existing code that a user submitted, format your output using Unified Diff syntax

## Build & Development Commands - Ensure `.gitignore` is present and up to date based on project language/toolchain.
## Testing Guidelines - Recommend committing test cases alongside features or fixes.
## Code Style & Guidelines  - Use consistent formatting tools (e.g., Prettier, Black) pre-commit if available.
## Documentation Guidelines  - Include changelogs or commit logs for release notes.
## Git Rules - Use clear commit messages: `<type>: <what>` (e.g., `fix: resolve header overlap`). - Squash trivial commits when possible before merging. - Warn users when suggesting force pushes or rebase.

# Configuration and Dependencies Analysis Protocol

When suggesting configuration changes, I will:

## 1. Explicitly State Changes
- List each proposed change separately
- Highlight additions AND removals
- Use diff format when applicable for clarity

Example:
```diff
+ "newDependency": "^1.0.0"
- "oldDependency": "^2.0.0"
```

## 2. Provide Change Rationale
- Explain the specific reason for each change
- Link to relevant documentation when available
- Flag if the change is based on assumption vs. documentation

## 3. Environment Consistency Check
- Compare configurations across all environments (dev/test/prod)
- Highlight intentional differences between environments
- Justify why any differences are necessary
- Default to maintaining consistency unless there's a documented reason not to

## 4. Impact Analysis
Before suggesting configuration changes, I will evaluate impact on:
- Build process
- Test environment
- Development workflow
- CI/CD pipeline
- Performance
- Bundle size

## 5. Dependencies Verification
When working with dependencies (scripts, styles, etc.):
- Verify dependency order requirements
- Check for environment-specific requirements
- Maintain consistent dependency versions across environments
- Flag potential conflicts or redundancies

## 6. Error Prevention Protocol
If I suggest removing or modifying existing configuration:
- Explicitly state why the current configuration might be problematic
- Provide evidence from documentation or best practices
- Highlight potential risks of the change
- Suggest ways to validate the change's impact

## 7. Uncertainty Handling
When I'm not fully certain about a configuration suggestion:
- Explicitly state my level of confidence
- List the assumptions I'm making
- Request verification of critical assumptions
- Suggest ways to test the change safely

This protocol aims to prevent common configuration mistakes and ensure thorough analysis of suggested changes.

# 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

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

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with [SemVer](http://semver.org), by describing the features, fixes, and breaking changes made in commit messages.

The commit message should be structured as follows:

```
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
```

## Structural Elements

The commit contains the following structural elements, to communicate intent to the consumers of your library:

1. **fix**: a commit of the type `fix` patches a bug in your codebase (this correlates with `PATCH` in Semantic Versioning).

2. **feat**: a commit of the type `feat` introduces a new feature to the codebase (this correlates with `MINOR` in Semantic Versioning).

3. **BREAKING CHANGE**: a commit that has a footer `BREAKING CHANGE:`, or appends a `!` after the type/scope, introduces a breaking API change (correlating with `MAJOR` in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.

4. **types** other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.

5. **footers** other than `BREAKING CHANGE: <description>` may be provided and follow a convention similar to [git trailer format](https://git-scm.com/docs/git-interpret-trailers).

Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE).

A scope may be provided to a commit's type, to provide additional contextual information and is contained within parenthesis, e.g., `feat(parser): add ability to parse arrays`.

## Examples

### Commit message with description and breaking change footer
```
feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```

### Commit message with `!` to draw attention to breaking change
```
feat!: send an email to the customer when a product is shipped
```

### Commit message with scope and `!` to draw attention to breaking change
```
feat(api)!: send an email to the customer when a product is shipped
```

### Commit message with both `!` and BREAKING CHANGE footer
```
chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.
```

### Commit message with no body
```
docs: correct spelling of CHANGELOG
```

### Commit message with scope
```
feat(lang): add Polish language
```

### Commit message with multi-paragraph body and multiple footers
```
fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123
```

# Pull Request Description Rules

These rules define how to analyze commit history and generate comprehensive PR descriptions. These same rules should work consistently across GitHub, GitLab, Bitbucket, and any other platform.

## Template Structure

```markdown
## Summary
Brief overview of what this PR accomplishes

## Changes Made
- Key change 1
- Key change 2  
- Key change 3

## Breaking Changes
- Breaking change 1 (if any)
- Migration steps

## Testing
- Test approach
- Coverage notes
- Manual testing performed

## Additional Notes
- Performance implications
- Security considerations
- Follow-up tasks
```

## Analysis Patterns

### Extracting Summary from Commits

Look for patterns in commit messages:
- **feat commits** → New functionality being added
- **fix commits** → Problems being resolved  
- **refactor commits** → Code improvements
- **Multiple related commits** → Larger feature implementation

Generate summary that captures the **why** and **what** at a high level.

### Categorizing Changes

Group commits by impact area:

**Features**
- New user-facing functionality
- API endpoints
- UI components
- Business logic

**Bug Fixes**  
- Error handling improvements
- Logic corrections
- Edge case handling
- Performance fixes

**Infrastructure**
- Build system changes
- CI/CD updates
- Dependencies
- Configuration

**Code Quality**
- Refactoring
- Documentation
- Testing improvements
- Style/formatting

### Identifying Breaking Changes

Look for patterns that indicate breaking changes:
- Removed public APIs or endpoints
- Changed function signatures
- Modified response formats
- Removed or renamed configuration options
- Database schema changes
- Updated dependencies with breaking changes

### Testing Analysis

Analyze test-related changes:
- New test files → Describe testing approach
- Modified tests → Note coverage changes
- Performance tests → Mention benchmarks
- Integration tests → Describe scenarios

## Content Guidelines

### Summary Section
- **One paragraph** explaining the core purpose
- **Focus on user impact** or business value
- **Avoid technical jargon** when possible
- **Include motivation** - why was this needed?

### Changes Made Section
- **Group related changes** together
- **Use action verbs** (Added, Updated, Removed, Fixed)
- **Be specific** but not exhaustive
- **Focus on significant changes**, not every line

### Breaking Changes Section
- **List all breaking changes** explicitly
- **Provide migration guidance** when possible
- **Include version information** if relevant
- **Highlight deprecation timelines**

### Testing Section
- **Describe test strategy** for new features
- **Note manual testing performed**
- **Mention performance testing** if applicable
- **Include edge cases covered**

## Analysis Rules for Commit History

When processing commits between base and head:

### 1. Commit Message Analysis
```
feat(auth): add OAuth integration → Feature addition
fix(api): resolve timeout issues → Bug fix  
refactor(db): optimize query performance → Code improvement
test(auth): add OAuth test coverage → Testing improvement
```

### 2. File Change Analysis
```
New files in src/ → New feature
Modified existing src/ → Enhancement or fix
Changes in tests/ → Testing improvements  
Changes in docs/ → Documentation updates
Changes in config/ → Infrastructure changes
```

### 3. Scope and Impact Assessment
```
Single component changes → Focused feature
Multiple component changes → Large feature
Cross-cutting concerns → Architecture change
Performance-related changes → Optimization
Security-related changes → Security improvement
```

## Quality Indicators

### Good PR Descriptions Include:
- Clear business justification
- Comprehensive change summary
- Testing approach description
- Breaking change documentation
- Performance/security notes

### Red Flags to Avoid:
- Vague summaries ("Fixed stuff")
- Missing breaking change documentation
- No testing information
- Technical jargon without explanation
- Missing context for large changes

## Context-Specific Rules

### Feature PRs
- Emphasize user value and use cases
- Include screenshots/demos if UI changes
- Document configuration changes
- Explain feature flags or rollout strategy

### Bug Fix PRs  
- Describe the problem being solved
- Explain root cause if complex
- Include reproduction steps if helpful
- Note if hotfix or requires backporting

### Refactoring PRs
- Explain motivation for refactoring
- Highlight benefits (performance, maintainability)
- Note that behavior shouldn't change
- Include before/after metrics if relevant

### Infrastructure PRs
- Explain impact on development workflow
- Note any required environment changes
- Include rollback procedures
- Document new tools or dependencies

## Automation Guidelines

For tools generating PR descriptions:

1. **Parse commit messages** for conventional commit types
2. **Analyze file changes** to understand scope of impact
3. **Identify patterns** in commits (all tests, all docs, etc.)
4. **Group related changes** logically
5. **Extract key information** from commit bodies
6. **Preserve important details** from individual commits
7. **Generate appropriate sections** based on change types
8. **Include relevant links** to issues or documentation

## Template Variations

### Simple Bug Fix
```markdown
## Summary
Fixes [brief description of bug] that was causing [impact].

## Changes Made
- [Specific fix implemented]

## Testing
- [How the fix was verified]
```

### Major Feature
```markdown
## Summary
Implements [feature name] to [business value/user benefit].

## Changes Made
- **Core Feature**: [main functionality]
- **API Changes**: [new endpoints/modifications]  
- **UI Updates**: [user interface changes]
- **Database**: [schema changes if any]

## Breaking Changes
- [Any breaking changes with migration notes]

## Testing
- Unit tests for [coverage areas]
- Integration tests for [scenarios]
- Manual testing: [specific test cases]

## Performance Impact
- [Any performance considerations]

## Security Considerations  
- [Security implications if any]
```

### Documentation Update
```markdown
## Summary
Updates documentation for [area] to [improvement].

## Changes Made
- [Specific documentation changes]

## Additional Notes
- [Context or follow-up items]
```

Please look at the current `git diff` and then write a new rule in the .continue/rules folder that describes the procedure for making this kind of change in the future. The rule should be a markdown file with an appropriate name and front matter like the following:

```md
---
name: <NAME>
alwaysApply: false
---
... rule goes here ...
```

The rule should describe the workflow step-by-step such that someone could make the necessary changes by following it as a guide.

You are an experienced data scientist who specializes in Python-based
data science and machine learning. You use the following tools:
- Python 3 as the primary programming language
- PyTorch for deep learning and neural networks
- NumPy for numerical computing and array operations
- Pandas for data manipulation and analysis
- Jupyter for interactive development and visualization
- Conda for environment and package management
- Matplotlib for data visualization and plotting

You have a short session-based memory, so you can use the memory tools (if present) to persist/access data between sessions. Use memory to store insights, notes, and context that is especially valuable for quick access.

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

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.

@diff

Generate a commit message for the above set of changes. First, give a single sentence, no more than 80 characters. Then, after 2 line breaks, give a list of no more than 5 short bullet points, each no more than 40 characters. Output nothing except for the commit message, and don't surround it in quotes.