mi-crow 0.1.2__tar.gz → 1.0.0__tar.gz

{mi_crow-0.1.2 → mi_crow-1.0.0}/.gitignore

@@ -36,12 +36,16 @@ venv.bak/
 *.iws
 *.iml
 *.ipr
+.run/
 out/
 
 # VS Code
 .vscode/
 *.code-workspace
 
+# Cursor IDE
+.cursor/
+
 # macOS
 .DS_Store
 .AppleDouble
@@ -67,6 +71,9 @@ Temporary Items
 coverage.xml
 htmlcov/
 
+# MkDocs generated site
+site/
+
 
 # Jupyter
 .ipynb_checkpoints

{mi_crow-0.1.2 → mi_crow-1.0.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mi-crow
-Version: 0.1.2
+Version: 1.0.0
 Summary: Engineer Thesis: Explaining and modifying LLM responses using SAE and concepts.
 Author-email: Hubert Kowalski <your.email@example.com>, Adam Kaniasty <adam.kaniasty@gmail.com>
 Requires-Python: >=3.10

{mi_crow-0.1.2 → mi_crow-1.0.0}/docs/guide/best-practices.md

@@ -386,5 +386,5 @@ assert len(top_texts) > 0  # Found some concepts
 
 - **[Troubleshooting](troubleshooting.md)** - Common issues and solutions
 - **[Examples](examples.md)** - Example code patterns
-- **[Hooks: Advanced](../hooks/advanced.md)** - Advanced patterns
+- **[Hooks: Advanced](hooks/advanced.md)** - Advanced patterns
 

{mi_crow-0.1.2 → mi_crow-1.0.0}/docs/guide/examples.md

@@ -77,7 +77,7 @@ The examples directory contains Jupyter notebooks demonstrating mi-crow function
 
 **Related guides**:
 - [Concept Discovery](workflows/concept-discovery.md)
-- [Hooks: Detectors](../hooks/detectors.md)
+- [Hooks: Detectors](hooks/detectors.md)
 
 ---
 
@@ -112,7 +112,7 @@ The examples directory contains Jupyter notebooks demonstrating mi-crow function
 **Related guides**:
 - [Concept Manipulation](workflows/concept-manipulation.md)
 - [Activation Control](workflows/activation-control.md)
-- [Hooks: Controllers](../hooks/controllers.md)
+- [Hooks: Controllers](hooks/controllers.md)
 
 ---
 
@@ -133,7 +133,7 @@ The examples directory contains Jupyter notebooks demonstrating mi-crow function
 
 **Related guides**:
 - [Saving Activations](workflows/saving-activations.md)
-- [Hooks: Detectors](../hooks/detectors.md)
+- [Hooks: Detectors](hooks/detectors.md)
 
 ---
 
@@ -215,8 +215,8 @@ The examples directory contains Jupyter notebooks demonstrating mi-crow function
 
 **Related guides**:
 - [Activation Control](workflows/activation-control.md)
-- [Hooks: Fundamentals](../hooks/fundamentals.md)
-- [Hooks: Controllers](../hooks/controllers.md)
+- [Hooks: Fundamentals](hooks/fundamentals.md)
+- [Hooks: Controllers](hooks/controllers.md)
 
 ---
 
@@ -319,6 +319,6 @@ If you encounter issues:
 After working through examples:
 
 - **[Workflows](workflows/index.md)** - Detailed workflow guides
-- **[Hooks System](../hooks/index.md)** - Deep dive into hooks
+- **[Hooks System](hooks/index.md)** - Deep dive into hooks
 - **[Experiments](../experiments/index.md)** - Real-world experiments
 

{mi_crow-0.1.2 → mi_crow-1.0.0}/mkdocs.yml

@@ -76,6 +76,7 @@ nav:
     - experiments/verify-sae-training.md
     - experiments/slurm-pipeline.md
   - API Reference:
+    - api.md
     - api/index.md
     - Language Model: api/language_model.md
     - SAE: api/sae.md

{mi_crow-0.1.2 → mi_crow-1.0.0}/src/mi_crow.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mi-crow
-Version: 0.1.2
+Version: 1.0.0
 Summary: Engineer Thesis: Explaining and modifying LLM responses using SAE and concepts.
 Author-email: Hubert Kowalski <your.email@example.com>, Adam Kaniasty <adam.kaniasty@gmail.com>
 Requires-Python: >=3.10

{mi_crow-0.1.2 → mi_crow-1.0.0}/src/mi_crow.egg-info/SOURCES.txt

@@ -7,16 +7,9 @@ mkdocs.yml
 pyproject.toml
 raport_implementacji.md
 uv.lock
-.cursor/commands/fix-and-add-unit-tests.md
-.cursor/commands/refactor-given-code.md
-.cursor/plans/dokumentacja-implementacji-modu-w-i-automatyzacji-83a10087.plan.md
-.cursor/plans/server-sae-full-metadata_b869cacf.plan.md
-.cursor/rules/coding-rules.mdc
-.cursor/rules/comments.mdc
 .github/workflows/docs.yml
 .github/workflows/publish.yml
 .github/workflows/tests.yml
-.run/Unit tests.run.xml
 docs/api.md
 docs/index.md
 docs/api/datasets.md

mi_crow-0.1.2/.cursor/commands/fix-and-add-unit-tests.md

@@ -1,55 +0,0 @@
-# fix-and-add-unit-tests
-
-Your role:
-You are a Senior Python Engineer responsible for designing and maintaining high-quality unit tests for a production system.
-All tests must meet or exceed 90% coverage and follow industry-grade best practices.
-
-When I send you any Python module, class, function, or code fragment:
-1. Analyze the Code
-Identify responsibilities, edge-cases, invariants, and failure modes
-Detect missing validations, ambiguous cases, undefined behaviors
-Identify all branches, paths, and interactions
-Determine which parts are not testable or require refactoring
-2. Produce Senior-Level Unit Tests
-All test code MUST:
-Use pytest style
-Be fully isolated
-Avoid side effects
-Use parametrization extensively
-Use fixtures where appropriate
-Cover success, failure, and boundary conditions
-Include negative tests (exceptions, invalid inputs)
-Mock external systems only when needed
-Be deterministic (no randomness unless seeded)
-Ensure ≥ 90% coverage, including branches and error handling
-Follow clean naming:
-test_<function>_<scenario>_<expected>()
-3. Fix & Improve Existing Tests (if provided)
-Rewrite poor tests
-Remove duplication
-Replace broad mocks with specific ones
-Improve assertions
-Add missing cases
-Ensure readability, clarity, and intent disclosure
-Apply red-green-refactor test discipline
-4. Suggest Improvements to Production Code
-If required to achieve proper testability, propose:
-Dependency injection
-Splitting functions
-Returning richer objects
-Making side effects explicit
-Better error handling
-Removing hidden globals
-Eliminating nondeterministic behaviors
-Never modify production code unless explicitly asked — but always propose improvements.
-5. Output Format
-Always reply with:
-A) Summary of issues found
-Missing coverage areas
-Undetected edge-cases
-Logical gaps
-Suggested refactors
-Anything blocking full testability
-
-Ensure tests run with:
-uv run pytest -q --unit -n auto

mi_crow-0.1.2/.cursor/commands/refactor-given-code.md

@@ -1,18 +0,0 @@
-# refactor-given-code
-
-You are a Senior Python Engineer specializing in refactoring and code quality.
-When I send you any code file, module, or class, your task is to refactor it for clarity, maintainability, testability, and correctness, while preserving functionality.
-Your responsibilities:
-Apply single responsibility principle and extract private helper functions when needed
-Break large modules/classes into smaller files with clear boundaries
-Improve naming, API clarity, and separation of concerns
-Remove duplication and inline complex logic into clean reusable functions
-Replace implicit behaviors with explicit ones
-Improve error handling and edge-case coverage
-Keep refactoring safe, deterministic, and production-friendly
-Ensure final structure is testable and follows clean code principles
-Output format:
-Short explanation of key improvements
-Optional suggestions for further enhancements
-When ready, say:
-“Send me the code you want to refactor.”

mi_crow-0.1.2/.cursor/plans/dokumentacja-implementacji-modu-w-i-automatyzacji-83a10087.plan.md

@@ -1,119 +0,0 @@
----
-name: Plan raportu implementacji modułów i automatyzacji
-overview: ""
-todos:
-  - id: 41a71e17-1a66-482a-927c-8b8739cedd36
-    content: Utworzenie pliku docs/automation.md z opisem wszystkich procedur automatyzacji (UV, pre-commit, ruff, pytest, GitHub Actions, MkD
-    status: pending
-  - id: ab21d40e-3967-484a-8a10-8dd60a424cb5
-    content: Utworzenie pliku docs/modules.md z dokumentacją wszystkich modułów, ich parametrów i konfiguracjiAktualizacja mkdocs.yml - dodanie nowych sekcji do nawigacjiAktualizacja docs/index.md - dodanie linków do nowych sekcji dokumentacjiUtworzenie pliku docs/automation.md z opisem wszystkich procedur automatyzacji (UV, pre-commit, ruff, pytest, GitHub Actions, MkDocs)Utworzenie pliku docs/modules.md z dokumentacją wszystkich modułów, ich parametrów i konfiguracjiAktualizacja mkdocs.yml - dodanie nowych sekcji do nawigacjiAktualizacja docs/index.md - dodanie linków do nowych sekcji dokumentacUtworzenie pliku docs/automation.md z opisem wszystkich procedur automatyzacji (UV, pre-commit, ruff, pytest, GitHub Actions, MkDocs)Utworzenie pliku docs/modules.md z dokumentacją wszystkich modułów, ich parametrów i konfiguracjiAktualizacja mkdocs.yml - dodanie nowych sekcji do nawigacjiAktualizacja docs/index.md - dodanie linków do nowych sekcji dokumentacji
-    status: pending
----
-
-# Plan raportu implementacji modułów i automatyzacji
-
-## Cel
-
-Utworzenie jednego pliku Markdown z raportem na zajęcia opisującym:
-
-1. Procedury automatyzacji (GitHub Actions, UV, pre-commit, ruff, pytest, środowisko testowe)
-2. Implementację modułów (stan implementacji, parametry, opisy modeli ML)
-
-## Struktura raportu
-
-Jeden plik Markdown (np. `raport.md` lub `raport_implementacji.md`) w katalogu głównym projektu z następującymi sekcjami:
-
-## 1. Procedury automatyzacji
-
-### 1.1 Zarządzanie zależnościami (UV)
-
-- Opis użycia UV jako menedżera pakietów
-- Konfiguracja w `pyproject.toml`
-- Komendy: `uv sync`, `uv add`, `uv lock`
-- Grupy zależności: `dev`, `docs`
-- Plik `uv.lock` i synchronizacja wersji
-
-### 1.2 Pre-commit hooks
-
-- Konfiguracja w `.pre-commit-config.yaml`
-- Hooks: `ruff` (linter) i `ruff-format` (formatter)
-- Automatyczne uruchamianie przed commitami
-- Instalacja: `pre-commit install`
-
-### 1.3 Ruff - linting i formatowanie
-
-- Konfiguracja w `pyproject.toml` sekcja `[tool.ruff]`
-- Ustawienia: line-length=120, target-version, select rules
-- Uruchamianie: `uv run ruff check`, `uv run ruff format`
-
-### 1.4 Testy i coverage (pytest)
-
-- Konfiguracja w `pyproject.toml` sekcja `[tool.pytest.ini_options]`
-- Wymagane pokrycie: 90% (fail-under=90)
-- Markery testów: `--unit`, `--e2e`
-- Raporty: terminal, XML, HTML
-- Środowisko testowe: fixtures w `conftest.py`, testy jednostkowe i e2e
-
-### 1.5 GitHub Actions
-
-- Opis workflow CI/CD (jeśli dostępne)
-- Badge CI widoczny w README.md
-- Automatyczne testy i deployment (jeśli skonfigurowane)
-
-### 1.6 Dokumentacja (MkDocs)
-
-- Konfiguracja w `mkdocs.yml`
-- Theme: Material
-- Plugins: mkdocstrings, search, section-index
-- Deploy: GitHub Pages (https://adamkaniasty.github.io/Inzynierka/)
-
-## 2. Implementacja modułów
-
-### 2.1 Moduł `mi_crow.datasets`
-
-- **BaseDataset**: Klasa abstrakcyjna z LoadingStrategy (MEMORY, DYNAMIC_LOAD, ITERABLE_ONLY)
-- **TextDataset**: Dataset tekstowy z parametrem `text_field`
-- **ClassificationDataset**: Dataset z kategoriami, parametry `text_field`, `category_field` (single/multiple)
-- **LoadingStrategy**: Enum z trzema strategiami ładowania
-
-### 2.2 Moduł `mi_crow.hooks`
-
-- **Hook**: Klasa abstrakcyjna, parametry: `layer_signature`, `hook_type` (FORWARD/PRE_FORWARD), `hook_id`
-- **Detector**: Hook do wykrywania/zapisywania aktywacji
-- **Controller**: Hook do modyfikacji aktywacji
-- **LayerActivationDetector**: Implementacja zapisywania aktywacji warstw
-- **FunctionController**: Implementacja kontrolera funkcji
-
-### 2.3 Moduł `mi_crow.language_model`
-
-- **LanguageModel**: Główna klasa wrappera modelu
-- Parametry inicjalizacji: `model`, `tokenizer`, `store`, `model_id`
-- Metody: `tokenize()`, `forwards()`, `generate()`, `save_model()`
-- Factory methods: `from_huggingface()`, `from_local_torch()`, `from_local()`
-- **LanguageModelLayers**: Zarządzanie warstwami i hookami
-- **LanguageModelActivations**: Zarządzanie aktywacjami
-- **LanguageModelTokenizer**: Wrapper tokenizera
-- **InferenceEngine**: Silnik inferencji z parametrami `autocast`, `autocast_dtype`, `with_controllers`
-
-### 2.4 Moduł `mi_crow.mechanistic.sae` (moduły uczenia maszynowego)
-
-- **Sae**: Klasa abstrakcyjna SAE
-- Parametry: `n_latents`, `n_inputs`, `hook_id`, `device`, `store`
-- Metody abstrakcyjne: `encode()`, `decode()`, `forward()`, `modify_activations()`, `save()`
-- **TopKSae**: Implementacja TopK SAE
-- Dodatkowy parametr: `k` (liczba aktywnych neuronów)
-- Metody: `train()`, `save()`, `load()`
-- **SaeTrainer**: Klasa trenująca SAE
-- **SaeTrainingConfig**: Konfiguracja treningu
-- Parametry treningu: `epochs`, `batch_size`, `lr`, `l1_lambda`, `device`, `dtype`
-- Parametry zaawansowane: `use_amp`, `amp_dtype`, `grad_accum_steps`, `clip_grad`, `monitoring`
-- Parametry wandb: `use_wandb`, `wandb_project`, `wandb_entity`, `wandb_name`, `wandb_tags`, `wandb_mode`
-- **AutoencoderContext**: Kontekst SAE z parametrami: `n_latents`, `n_inputs`, `device`, `text_tracking_enabled`, `text_tracking_k`
-- **AutoencoderConcepts**: Zarządzanie konceptami (multiplication, bias)
-
-### 2.5 Moduł `mi_crow.store`
-
-- **Store**: Klasa abstrakcyjna do przechowywania tensorów
-- Parametry: `base_path`, `runs_prefix`, `dataset_prefix`, `model_prefix`
-- Organizacja: runs -> batches -> layers -> keys
-- **LocalStore**: Implementacja lokalnego przechowywania (safetensors)

mi_crow-0.1.2/.cursor/plans/server-sae-full-metadata_b869cacf.plan.md

@@ -1,55 +0,0 @@
----
-name: server-sae-full-metadata
-overview: "Wire server to mi_crow SAE without touching core library: LocalStore-based activations, real SAE training/inference, concept application, and enriched responses."
-todos: []
----
-
-# Server SAE Integration (No Core Library Changes)
-
-## Scope
-
-b
-
-- Only modify server code; reuse mi_crow APIs as-is.
-- Use LocalStore for activations, real SaeTrainer for training, and Sae hook for inference/top-texts.
-- Concept handling via existing mi_crow concept classes; no edits to mi_crow package.
-
-## Plan
-
-1) **Activation Pipeline → LocalStore**
-
-- Update `/sae/activations/save` to write activations into `mi_crow.store.LocalStore` under `artifact_base_path` using `run_id`/batch/layer keys.
-- Keep manifest with run_id, layers, dataset info, token counts, batch indices.
-- Add layer-existence check (already present) and bounds on batch/sample size.
-
-2) **SAE Training (real)**
-
-- In `/sae/train`, load LocalStore with run_id/layer from manifest; build `SaeTrainingConfig` from payload; call `SaeTrainer.train` on the selected SAE class (chosen by payload or default) without modifying mi_crow code.
-- Save SAE checkpoint via its `save` method alongside training metadata (history, config, metrics) in `artifact_base_path/sae/<model>/<run>/`.
-- Return sae_id/sae_path/metadata_path from the job result.
-
-3) **SAE Inference & Top Texts**
-
-- In `/sae/infer`, load SAE via `Sae.load`, register the SAE hook on target layer, run the LM forward; capture neuron activations from the SAE detector metadata.
-- Compute top-N neurons per prompt and write top-texts JSON (neuron_id, activation stats, example texts) to `top_texts_dir`.
-- Response: generated text/tokens, optional logits/probs, top-neuron summary + path to top-texts file, sae_id reference.
-
-4) **Concepts Integration**
-
-- `/sae/concepts/load`: parse user file into mi_crow concepts/dictionary; validate against SAE dims; persist normalized concept file under concepts dir.
-- `/sae/concepts/manipulate`: accept weights/edits; build a concept-config mapping to neuron weights; persist config.
-- `/sae/infer` accepts concept_config to adjust activations/decoder via SAE hook before generation (no mi_crow code changes—use available hook points).
-
-5) **Jobs & Observability**
-
-- Keep in-memory JobManager; ensure train job result carries sae_id/paths/metadata. Add minimal logging around train start/end and inference timings.
-
-6) **Testing & Docs**
-
-- Extend server tests with small dummy SAE class implementing `save/load/encode/decode` to cover training/inference flows without touching mi_crow; mock LocalStore I/O.
-- Update README with new expectations: activations in LocalStore, real training path, concept flow, top-text outputs, and job responses.
-
-## Notes
-
-- No changes to mi_crow core; all integrations via its public classes (LocalStore, SaeTrainer, Sae, concepts).
-- Keep payload schemas mostly stable; only enrich responses with sae/metadata paths and top-text summaries.

mi_crow-0.1.2/.cursor/rules/coding-rules.mdc

@@ -1,195 +0,0 @@
----
-globs: *.py
-alwaysApply: false
----
-# Python Programming Rules
-
-This file defines coding standards and best practices for Python files in this codebase.
-
-## 1. Comments in Docstrings Only
-
-- **All comments must be in docstrings** using Google-style format
-- **No inline comments** (`#`) except for type ignore comments (e.g., `# type: ignore`)
-- Docstrings should explain **"why"** not just **"what"**
-- Use docstrings for:
-  - Module-level documentation
-  - Class documentation
-  - Function/method documentation
-  - Complex logic explanations
-
-### Example
-
-```python
-def process_activations(activations: Tensor) -> Tensor:
-    """
-    Normalize and scale activations for downstream processing.
-    
-    This normalization is required because raw activations can have
-    extreme values that cause numerical instability in the SAE.
-    We use layer normalization to ensure consistent scale across batches.
-    
-    Args:
-        activations: Raw activation tensor of shape (batch, seq_len, hidden_dim)
-        
-    Returns:
-        Normalized activation tensor with same shape
-        
-    Raises:
-        ValueError: If activations contain NaN or Inf values
-    """
-    if torch.isnan(activations).any() or torch.isinf(activations).any():
-        raise ValueError("Activations contain invalid values")
-    return self._normalize(activations)
-```
-
-## 2. Modular Code with Private Methods
-
-- **Prefer small, focused private methods** (prefixed with `_`) over large monolithic functions
-- Break down complex logic into smaller, testable units
-- Public methods should be **thin orchestration layers** that delegate to private methods
-- Methods should have **single responsibility**
-- If a method exceeds ~50 lines, consider breaking it into smaller methods
-- Private methods should be well-named and self-documenting
-
-### Example
-
-```python
-class ActivationProcessor:
-    def process(self, activations: Tensor) -> Tensor:
-        """Process activations through normalization and scaling pipeline."""
-        normalized = self._normalize(activations)
-        scaled = self._apply_scaling(normalized)
-        return self._validate_output(scaled)
-    
-    def _normalize(self, activations: Tensor) -> Tensor:
-        """Apply layer normalization to activations."""
-        # Implementation here
-        pass
-    
-    def _apply_scaling(self, activations: Tensor) -> Tensor:
-        """Scale activations by learned factor."""
-        # Implementation here
-        pass
-    
-    def _validate_output(self, activations: Tensor) -> Tensor:
-        """Validate processed activations meet quality criteria."""
-        # Implementation here
-        pass
-```
-
-## 3. Test Refactoring Requirements
-
-- **When refactoring code, always refactor corresponding tests**
-- Tests should reflect the new structure and implementation
-- Update test names and assertions to match refactored code
-- Remove tests for implementation details that no longer exist
-- Add tests for new private methods if they expose new behavior
-- Ensure test coverage remains at or above 85%
-
-### Example
-
-If you refactor a method `process_data()` into `_validate()`, `_transform()`, and `_save()`:
-- Update the test to verify the public interface still works
-- Add tests for the new private methods if they have complex logic
-- Remove tests that were checking internal implementation details
-
-## 4. Meaningful Tests Only
-
-- Write tests that **verify behavior, not implementation details**
-- Avoid trivial tests that don't add value (e.g., testing simple getters/setters)
-- Focus on:
-  - Edge cases and boundary conditions
-  - Error conditions and exception handling
-  - Integration points between components
-  - Complex business logic
-- Tests should be **readable and self-documenting**
-- Use descriptive test names that explain what is being tested
-
-### Example
-
-```python
-# Good: Tests meaningful behavior
-def test_process_activations_raises_on_invalid_input():
-    """Test that invalid activations raise appropriate errors."""
-    processor = ActivationProcessor()
-    invalid_activations = torch.tensor([float('nan')])
-    with pytest.raises(ValueError, match="invalid values"):
-        processor.process(invalid_activations)
-
-# Bad: Trivial test that doesn't add value
-def test_get_enabled_returns_boolean():
-    """Test that get_enabled returns a boolean."""
-    hook = Hook()
-    assert isinstance(hook.enabled, bool)  # Too trivial
-```
-
-## 5. No Backward Compatibility
-
-- **Do not maintain backward compatibility** when refactoring
-- Remove deprecated code paths immediately
-- Update all call sites when changing APIs
-- Breaking changes are acceptable for code quality improvements
-- If an API change is needed, update all usages throughout the codebase
-- Do not add deprecation warnings or compatibility shims
-
-### Example
-
-If you need to change a method signature:
-```python
-# Old API
-def process(data: Tensor, batch_size: int = 32) -> Tensor:
-    pass
-
-# New API - just change it, don't keep the old one
-def process(data: Tensor, config: ProcessingConfig) -> Tensor:
-    pass
-```
-
-Then update all call sites immediately - do not provide both versions.
-
-## Additional Best Practices
-
-### Type Hints
-
-- **Type hints required** for all function signatures
-- Use `from __future__ import annotations` for forward references
-- Prefer `|` union syntax over `Union` (Python 3.10+)
-- Use `TypeAlias` for complex type definitions
-
-### Code Style
-
-- Follow existing code style (ruff configuration, 120 char line length)
-- Use double quotes for strings (per ruff configuration)
-- Follow PEP 8 naming conventions:
-  - Classes: `PascalCase`
-  - Functions/methods: `snake_case`
-  - Constants: `UPPER_SNAKE_CASE`
-  - Private: `_leading_underscore`
-
-### Design Principles
-
-- **Prefer composition over inheritance**
-- Use abstract base classes (`abc.ABC`) for interfaces
-- Handle errors explicitly with custom exceptions when appropriate
-- Use dependency injection for testability
-- Keep functions pure when possible (no side effects)
-
-### Error Handling
-
-- Create custom exception classes for domain-specific errors
-- Use exception chaining (`raise ... from e`) when appropriate
-- Provide clear error messages that help with debugging
-
-### Performance
-
-- Profile before optimizing
-- Use appropriate data structures (e.g., `dict` for O(1) lookups)
-- Consider memory usage for large tensors
-- Use generators for large datasets
-
-### Documentation
-
-- All public APIs must have docstrings
-- Include Args, Returns, and Raises sections in docstrings
-- Use type hints in docstrings only if they add clarity beyond type hints
-- Keep docstrings up-to-date with code changes

mi_crow-0.1.2/.run/Unit tests.run.xml

@@ -1,17 +0,0 @@
-<component name="ProjectRunConfigurationManager">
-  <configuration default="false" name="Unit tests" type="ShConfigurationType">
-    <option name="SCRIPT_TEXT" value="uv run pytest -q --unit -n auto" />
-    <option name="INDEPENDENT_SCRIPT_PATH" value="true" />
-    <option name="SCRIPT_PATH" value="" />
-    <option name="SCRIPT_OPTIONS" value="" />
-    <option name="INDEPENDENT_SCRIPT_WORKING_DIRECTORY" value="true" />
-    <option name="SCRIPT_WORKING_DIRECTORY" value="$PROJECT_DIR$" />
-    <option name="INDEPENDENT_INTERPRETER_PATH" value="true" />
-    <option name="INTERPRETER_PATH" value="/bin/zsh" />
-    <option name="INTERPRETER_OPTIONS" value="" />
-    <option name="EXECUTE_IN_TERMINAL" value="true" />
-    <option name="EXECUTE_SCRIPT_FILE" value="false" />
-    <envs />
-    <method v="2" />
-  </configuration>
-</component>