argus-standards 0.1.0__tar.gz

argus_standards-0.1.0/.argus.yml

@@ -0,0 +1,18 @@
+packs:
+- atomic-commit
+- tdd
+- solid
+- code-quality
+- pre-commit
+- type-safety
+- error-handling
+- documentation-standards
+- dependency-injection
+- design-patterns
+- refactoring
+- testing-strategy
+platforms:
+- claude
+- opencode
+- copilot
+- cursor

argus_standards-0.1.0/.claude/rules/atomic-commit.md

@@ -0,0 +1,38 @@
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+# Atomic Commit Workflow
+
+## Core Rule
+Every logical change is one commit. A commit represents a single, discrete, complete unit of work.
+
+## Diagnostic Rule
+If your commit message requires the word "also", that is a second commit.
+
+## Commit Cycle (within TDD)
+STOP → RED → GREEN → COMMIT → REFACTOR → COMMIT
+
+Each phase produces exactly one commit. Never batch phases.
+
+## Commit Message Format (Conventional Commits — conventionalcommits.org)
+`type(scope): description`
+
+**Types:**
+- `feat` — new functionality
+- `fix` — bug fix
+- `test` — adding or correcting tests
+- `refactor` — code change that neither fixes a bug nor adds a feature
+- `docs` — documentation only changes
+- `chore` — build process, tooling, dependencies
+
+**Examples:**
+```
+test: add failing test for discount calculation
+feat: implement discount calculation
+refactor: extract discount rate to named constant
+```
+
+## Red Flags — Do Not Commit If:
+- The word "also" appears in your commit message
+- The commit contains changes to more than one logical concern
+- The commit mixes test and implementation changes (except the GREEN phase commit)
+- Tests are failing

argus_standards-0.1.0/.claude/rules/code-quality.md

@@ -0,0 +1,36 @@
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+# Code Quality Metrics
+
+All thresholds below are grounded in industry standards, not opinion.
+
+## Cyclomatic Complexity
+- **Maximum: 10 per method** (NIST standard; NASA mandates < 10 for mission-critical software)
+- Cyclomatic complexity = number of linearly independent paths through a method
+- Count: +1 for each `if`, `elif`, `for`, `while`, `case`, `catch`, `and`, `or`
+- Methods exceeding 10 are the highest reliability risk (NASA Software Assurance Technology Center)
+
+## Method Size
+- **Maximum: 20 lines** (excluding blank lines and comments)
+- Size is the single most predictive code quality metric (industry consensus)
+- If a method exceeds 20 lines, extract a private method with a descriptive name
+
+## Class Size
+- **Maximum: 300 lines** (class body only — imports, package declarations, comments excluded)
+- A class exceeding 300 lines almost always violates SRP
+- Extract responsibilities into focused collaborator classes
+
+## Parameters
+- **Maximum: 5 parameters per method**
+- If a method needs more than 5 parameters, introduce a parameter object (data class / struct)
+
+## Duplication
+- **Zero tolerance for duplicated logic**
+- If the same logic appears in two places, extract it once and reference it
+- "Rule of Three": duplicated once is tolerable; duplicated twice, extract it
+
+## Red Flags
+- Method with cyclomatic complexity > 10: refactor before committing
+- Method > 20 lines: extract before committing
+- Class > 300 lines: split before committing
+- Method with > 5 parameters: introduce parameter object before committing

argus_standards-0.1.0/.claude/rules/dependency-injection.md

@@ -0,0 +1,28 @@
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+# Dependency Injection
+
+## Core Rule
+Depend on abstractions, not concretions. Inject all dependencies via constructor — never
+instantiate collaborators inside a class body.
+
+## Constructor Injection
+- Accept dependencies as constructor parameters typed to abstract interfaces (Protocol / ABC)
+- Never call `ConcreteClass()` inside a class body; receive it as a parameter instead
+- Store injected dependencies as instance attributes; do not pass them through method chains
+
+## Abstract Boundaries
+- Define a Protocol or ABC for every dependency that has more than one conceivable implementation
+- Application-layer classes depend only on those abstractions, never on concrete imports from
+  infrastructure layers (databases, HTTP clients, file system adapters)
+
+## Composition Root
+- Wire concrete implementations to abstractions in exactly one place: the entry point (CLI, app
+  factory, `main()`)
+- Test code is the only other place that substitutes implementations
+
+## Red Flags — Stop and Correct
+- `ConcreteClass()` instantiated inside a class body
+- `import` of a concrete infrastructure class inside a domain or application module
+- Method that accepts a flag/enum to select which implementation to use (use polymorphism instead)
+- Test that patches internals of the class under test rather than injecting a substitute

argus_standards-0.1.0/.claude/rules/design-patterns.md

@@ -0,0 +1,30 @@
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+# Design Patterns
+
+## Core Rule
+Apply structural patterns to eliminate `isinstance` checks, `if/elif` type-dispatch chains, and
+duplicated logic. A pattern is the fix, not the decoration.
+
+## Pattern Quick Reference
+
+| Smell | Pattern | Fix |
+|---|---|---|
+| `if type == "A": ... elif type == "B":` | Strategy | One class per behaviour; caller holds the variant |
+| Object creation buried in application logic | Factory / Factory Method | Centralise creation, return abstract type |
+| Many callers updated when state changes | Observer | Callers subscribe; emitter calls `notify()` |
+| Incompatible interfaces must work together | Adapter | Wrap the foreign interface; expose the local protocol |
+| Step sequence fixed, some steps vary | Template Method | Base class owns the skeleton; subclasses override steps |
+| Repeated `if feature_flag:` throughout code | Decorator | Compose behaviours at the composition root |
+
+## Usage Rules
+- Apply a pattern only when the smell exists — not speculatively
+- Name the participant classes after the pattern role: `*Strategy`, `*Factory`, `*Observer`, `*Adapter`
+- Keep pattern participants in separate modules; avoid god-module pattern files
+- Prefer composition over inheritance for Strategy and Decorator
+
+## Red Flags — Stop and Correct
+- `match`/`switch` dispatching on an object's type or an enum variant
+- `isinstance` check before calling a method (fix the type hierarchy instead)
+- New variant requires editing an existing class body (violates Open/Closed)
+- Pattern introduced with only one concrete implementation (premature — wait for the second)

argus_standards-0.1.0/.claude/rules/documentation-standards.md

@@ -0,0 +1,27 @@
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+# Documentation Standards
+
+## Docstring Requirements
+- All public classes must have a one-line docstring describing their purpose
+- All public methods and functions must have a one-line docstring
+- All Click CLI commands must have a one-line docstring (used by `--help`)
+- `__init__` methods are exempt — document the class instead
+- Private methods (prefixed `_`) are exempt
+
+## Docstring Style
+- One sentence, imperative mood: "Load packs from the search path." not "Loads packs..."
+- No restating the function name: `def load():` → not "Load the load."
+- Fits on one line — if you need more, the function probably does too much
+
+## Comment Discipline
+- Write comments only when the WHY is non-obvious: a hidden constraint, a workaround,
+  a subtle invariant, or behaviour that would surprise a reader
+- Never explain WHAT the code does — well-named identifiers already do that
+- Never reference the current task, ticket, or caller in a comment
+
+## Red Flags — Stop and Correct
+- Public class, method, or CLI command with no docstring
+- Docstring that restates the function name or explains what the code does
+- Comment that says what the code does rather than why
+- Multi-line docstring on a function under 10 lines

argus_standards-0.1.0/.claude/rules/error-handling.md

@@ -0,0 +1,27 @@
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+# Error Handling
+
+## Exception Design
+- All custom exceptions inherit from a project-level base exception (e.g. `ArgusError`)
+- Exception names end in `Error`
+- Define the project base exception in the project's root package (e.g. `argus/__init__.py`); define subclass exceptions in the module that raises them, importing the base
+- Exceptions carry a human-readable message sufficient to understand the failure
+
+## Raise vs Return
+- Raise for conditions the caller cannot reasonably anticipate or recover from inline
+- Return for expected outcomes the caller must handle (results, None, empty collections)
+- Never use exceptions for control flow
+
+## Catching Rules
+- Catch only at system boundaries (CLI entry points, public API surfaces); test fixtures and context managers are exempt
+- Catch only the specific exception types you can handle — never bare `except:` or `except Exception:`
+- Never swallow exceptions silently (`except ...: pass` is always wrong)
+- When catching to re-raise with context, use `raise NewError(...) from original`
+
+## Red Flags — Stop and Correct
+- Custom exception inherits directly from `Exception` without a project base class
+- `except:` or `except Exception:` anywhere except a top-level CLI handler
+- `except ...: pass` (silent swallow)
+- try/except inside a function that is not a system boundary
+- Exception name does not end in `Error`

argus_standards-0.1.0/.claude/rules/pre-commit.md

@@ -0,0 +1,27 @@
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+# Pre-Commit Gate
+
+Before every `git commit`, all of the following must be true. No exceptions.
+
+## Non-Negotiable Gates (🔴 RED LIGHT — do not commit if any fail)
+
+1. **All unit tests pass** — run your project's test suite to completion
+2. **Build succeeds** — the project compiles / type-checks without errors
+3. **No lint errors** — linter exits with code 0
+4. **TDD cycle followed** — test existed and was RED before implementation was written
+5. **No SOLID violations** — check the SOLID checklist before committing
+6. **No code quality violations** — no method > 20 lines, no class > 300 lines, complexity ≤ 10
+7. **Commit is atomic** — one logical change, message has no "also", follows conventional format
+
+## OK to Commit (🟢 GREEN LIGHT)
+
+- All unit tests pass
+- Build succeeds
+- Lint clean
+- TDD cycle was followed for this change
+- Commit message is `type(scope): description` format
+- This commit could be reverted cleanly without affecting other concerns
+
+## When In Doubt
+If you are unsure whether a commit is ready: it is not ready. Fix the uncertainty first.

argus_standards-0.1.0/.claude/rules/refactoring.md

@@ -0,0 +1,62 @@
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+# Refactoring
+
+## Core Rule
+Refactoring means changing code structure without changing external behavior. Never add new
+functionality in the same commit as a refactor — that is always a separate change.
+
+## When to Refactor
+
+**Rule of Three:** The first time you write something, just do it. The second time you do
+something similar, note the duplication. The third time, refactor.
+
+**Preparatory refactoring:** Before adding a feature, refactor the code to make the feature
+easy to add. "Make the change easy, then make the easy change." — Kent Beck. The refactor
+is one commit; the feature is the next.
+
+**TDD Refactor phase:** The REFACTOR step only happens after GREEN (tests passing). Never
+refactor during RED — finish making the test pass first.
+
+**Never refactor when:**
+- Tests are failing
+- You are in the RED phase of TDD
+- You are mid-feature (finish the feature first, then clean up)
+
+## Code Smells — What Signals Refactoring
+
+### Bloaters (things that grew too large)
+- **Long Method** — any method over 20 lines → Extract Method
+- **Large Class** — class over 300 lines → Extract Class
+- **Long Parameter List** — more than 5 parameters → Introduce Parameter Object
+- **Data Clumps** — same group of variables together in multiple places → Extract Class
+- **Primitive Obsession** — using a `str` or `int` where a small class would be clearer → Replace Primitive with Object
+
+### Dispensables (things that add no value)
+- **Duplicate Code** — same logic in two or more places → Extract Function
+- **Dead Code** — unreachable or unused code → Delete it
+- **Speculative Generality** — abstractions nobody uses yet → Delete it
+- **Excessive Comments** — a comment explaining what the code does signals unclear code → Rename or extract until the comment is unnecessary
+
+### Object-Orientation Abusers
+- **Switch/Match on type** — dispatching behavior based on an object's type → Strategy pattern (see design-patterns pack)
+- **Refused Bequest** — subclass ignores most of what the parent provides → Rework the hierarchy
+
+### Couplers (inappropriate dependencies)
+- **Feature Envy** — a method uses another class's data more than its own → Move Method
+- **Message Chains** — `a.b().c().d()` → Extract Method or Hide Delegate
+- **Inappropriate Intimacy** — two classes know too much about each other's internals → Extract Class or Move Method
+
+## How to Refactor Safely
+
+1. **Confirm tests pass** before starting — if they don't, fix that first
+2. **Make one change** — extract one method, rename one variable, move one class
+3. **Run tests** after each change — if they fail, undo and reconsider
+4. **Commit** when tests pass and the change is complete: `refactor: <what you improved>`
+5. **Never** mix refactoring and new behavior in the same commit
+
+## Red Flags — Stop and Correct
+- Refactoring with failing tests
+- Adding a new feature during a refactoring commit
+- Making multiple structural changes before running tests
+- Commit message contains both `feat:` and `refactor:` concerns

argus_standards-0.1.0/.claude/rules/solid.md

@@ -0,0 +1,30 @@
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+# SOLID Principles
+
+## Violation Quick Reference
+
+The following patterns are mechanically detectable. Stop and correct before committing.
+
+| Violation | Principle | Fix |
+|---|---|---|
+| God class (300+ lines, 10+ methods) | SRP | Extract focused classes |
+| `switch`/`match` on type | OCP | Strategy pattern or polymorphism |
+| Subclass throws `UnsupportedOperationException` or `NotImplementedError` | LSP | Rework the abstraction hierarchy |
+| Interface with stub methods (`pass`, `TODO`) | ISP | Split into focused interfaces |
+| `new ConcreteClass()` constructed inside a class | DIP | Constructor injection with interface |
+| Method name contains "And" | SRP | Split into two methods |
+| Class imports 10+ packages | SRP | Extract responsibilities |
+| `isinstance`/`is` type checks before method calls | LSP | Fix the type hierarchy |
+
+## Principle Summaries
+
+**S — Single Responsibility:** A class has one reason to change. If you can describe what it does and the description requires "and", it has two responsibilities.
+
+**O — Open/Closed:** Open for extension, closed for modification. Add behaviour by adding code, not by editing existing code. `switch` on type is the canonical violation.
+
+**L — Liskov Substitution:** Subtypes must be substitutable for their base type. If a subclass throws for a method the base defines, the hierarchy is wrong.
+
+**I — Interface Segregation:** No class should implement methods it doesn't use. If a class has `pass` or `raise NotImplementedError` for interface methods, split the interface.
+
+**D — Dependency Inversion:** Depend on abstractions, not concretions. High-level modules should not import concrete low-level classes directly.

argus_standards-0.1.0/.claude/rules/tdd.md

@@ -0,0 +1,40 @@
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+# Test-Driven Development (TDD)
+
+## Core Rule
+Never write or modify production code before there exists at least one failing test for the targeted behaviour. (TDD Guard contract — see: news.lavx.hu/article/tdd-guard)
+
+## The Cycle
+STOP → RED → GREEN → COMMIT → REFACTOR → COMMIT
+
+1. **STOP** — Understand the requirement. Write nothing yet.
+2. **RED** — Write the smallest failing test that captures the requirement. Run it. Confirm it fails with the right error.
+3. **GREEN** — Write the minimum production code to make the test pass. No extra logic.
+4. **COMMIT** — `git commit -m "feat: implement <behaviour>"`
+5. **REFACTOR** — Improve code quality without changing behaviour. Run tests after each change.
+6. **COMMIT** — `git commit -m "refactor: <what you improved>"`
+
+## Coverage Threshold
+- Minimum 80% unit test coverage for all changed code (NIST-aligned standard)
+- 100% coverage required for critical paths (payment processing, authentication, data integrity)
+- Integration tests and E2E tests do NOT count toward the 80% unit coverage threshold
+
+## Test Structure (Given-When-Then)
+```
+def test_<behaviour>_when_<condition>():
+    # Given
+    <setup state>
+    # When
+    <perform action>
+    # Then
+    assert <expected outcome>
+```
+
+## Red Flags — Stop and Correct
+- Implementation file modified before any test file exists for that behaviour
+- Tests written after implementation to confirm existing code (not to specify behaviour)
+- "I'll add tests later"
+- Test file created after the implementation already passes
+- Batching multiple RED phases before going GREEN
+- Tests that don't assert anything meaningful (trivial pass-through tests)

argus_standards-0.1.0/.claude/rules/testing-strategy.md

@@ -0,0 +1,82 @@
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+# Testing Strategy
+
+## Core Rule
+Test at the lowest layer that gives you confidence. More unit tests than integration tests;
+more integration tests than E2E tests. Inverting this pyramid produces a slow, fragile suite.
+
+## The Test Pyramid
+
+        /\
+       /E2E\       ← few, slow, fragile — critical journeys only
+      /------\
+     /Integr. \    ← moderate — only at system boundaries
+    /----------\
+   / Unit Tests \  ← many, fast, isolated — all business logic
+  /--------------\
+
+The pyramid shape is intentional: unit tests are cheap to write and run in milliseconds;
+E2E tests are expensive, slow, and occasionally flaky. Inverting it is a common mistake
+that teams pay for with hours of CI time and fragile suites.
+
+## Unit Tests
+
+**Use for:** Business logic, algorithms, transformations, domain rules — anything that can
+be tested without external dependencies.
+**Characteristics:** No I/O, no network, no database. Milliseconds per test. Deterministic.
+**Coverage:** 80% minimum for changed code (see `tdd` pack).
+**Rule:** If it can be tested without any external dependency, test it here.
+
+## Integration Tests
+
+**Use for:** Code that crosses a system boundary — database queries, external API calls,
+file I/O, message queues, adapter implementations.
+**Characteristics:** Slower than unit tests. Uses real infrastructure or a realistic substitute
+(e.g., an in-memory database, a local test container, a fake HTTP server).
+**Scope is narrow:** Test the integration point itself, not every code path that reaches it.
+One integration test per repository method or adapter — not one per caller.
+**Rule:** If the behavior depends on a real external system, test it here, not in unit tests.
+
+## End-to-End Tests
+
+**Use for:** The 2–3 critical user journeys that must never break regardless of internal changes.
+**Characteristics:** Slow (seconds to minutes), occasionally flaky due to timing and environment,
+expensive to maintain. Tests the whole deployed system.
+**Rule:** If a unit or integration test can answer the question, use that instead. E2E tests
+are a last resort, not a default.
+**Anti-pattern:** Testing every feature E2E. This produces a suite that takes 20+ minutes to
+run and breaks on every UI or API change.
+
+## Test Doubles
+
+Use the simplest double that makes the test work:
+
+| Double | What it is | When to use |
+|---|---|---|
+| **Fake** | A working simplified implementation | Integration tests — in-memory DB, fake HTTP server |
+| **Stub** | Returns canned values, no behavior | Unit tests — when you need a value from a collaborator |
+| **Mock** | Verifies that specific calls were made | Unit tests — when the interaction itself is the assertion |
+
+**Prefer fakes and stubs over mocks.** Mocks assert on HOW code works internally — they
+break when you refactor, even when behavior is correct. Fakes and stubs assert on WHAT
+the code produces — they survive refactoring. See the `dependency-injection` pack for how
+constructor injection makes substitution easy without patching internals.
+
+**Never patch internals to test.** If you need to monkey-patch a private method or module
+internals to write a test, that is a signal to inject the dependency instead.
+
+## Test Execution Tiers
+
+| When | What runs | Why |
+|---|---|---|
+| Before every commit | Unit tests only | Fast, isolated — no reason to skip |
+| Before push | Unit tests + integration tests | Catch boundary failures before teammates see them |
+| CI pipeline | Unit + integration + E2E | Hard gate — failures block merge |
+
+## Red Flags — Stop and Correct
+- E2E test written for a feature that could be covered by a unit test
+- Mock asserting on an internal private method call
+- Integration test covering business logic (that belongs in unit tests)
+- Unit test hitting a real database or network
+- Test suite takes more than 5 minutes to run locally (pyramid is inverted)

argus_standards-0.1.0/.claude/rules/type-safety.md

@@ -0,0 +1,25 @@
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+# Type Safety
+
+## Core Rule
+Every function and method must have fully annotated parameters and return type.
+Run `mypy argus/` before committing — it must exit 0.
+
+## Annotation Requirements
+- All parameters annotated — no bare untyped arguments
+- All return types explicit — including `-> None`
+- Use `X | None` syntax (not `Optional[X]`)
+- Use built-in generics: `list[str]`, `dict[str, int]` (not `List`, `Dict` from `typing`)
+
+## `Any` Policy
+`Any` is permitted **only at external data boundaries** (YAML, JSON, CLI input).
+Assign the unstructured value to a typed local variable as soon as its shape is known.
+`Any` in function signatures is never permitted.
+
+## Red Flags — Stop and Correct
+- Unannotated function parameter or return type
+- `Any` in a function signature
+- `Optional[X]` instead of `X | None`
+- `List`, `Dict`, `Tuple` imported from `typing` (use built-ins)
+- mypy exits non-zero

argus_standards-0.1.0/.claude/skills/atomic-commit/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: atomic-commit
+description: Atomic commit discipline and conventional commits format
+---
+
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+
+
+## Atomic Commit Checklist
+
+- [ ] This commit addresses exactly one logical change
+- [ ] The commit message does NOT contain the word "also"
+- [ ] Commit message follows format: `type(scope): description`
+- [ ] Type is one of: feat, fix, test, refactor, docs, chore
+- [ ] All tests pass
+- [ ] This commit could be reverted without affecting any other concern
+
+
+## Atomic Commit Examples
+
+### Correct — one feature, three commits (TDD cycle)
+
+```bash
+git commit -m "test: add failing test for user email validation"
+git commit -m "feat: implement user email validation"
+git commit -m "refactor: extract email regex to named constant"
+```
+
+### Incorrect — never do this
+
+```bash
+# Bad: the word "and" signals multiple concerns
+git commit -m "add user validation and fix login bug and update docs"
+
+# Bad: mixed concerns
+git commit -m "feat: add discount plus fix rounding error"
+```

argus_standards-0.1.0/.claude/skills/code-quality/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: code-quality
+description: NIST-backed code metrics — cyclomatic complexity, method size, class size
+---
+
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+
+
+## Code Quality Checklist
+
+- [ ] No method has cyclomatic complexity > 10 (NIST standard)
+- [ ] No method exceeds 20 lines (excluding blank lines and comments)
+- [ ] No class body exceeds 300 lines
+- [ ] No method has more than 5 parameters
+- [ ] No duplicated logic exists in two or more places
+- [ ] Every extracted method has a name that describes what it does (not how)

argus_standards-0.1.0/.claude/skills/dependency-injection/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: dependency-injection
+description: Inject dependencies via constructor; depend on abstractions, not concretions
+---
+
+<!-- Generated by argus. Run `argus generate` to update. Do not edit manually. -->
+
+
+
+## Dependency Injection Checklist
+
+- [ ] All dependencies received via constructor parameters, not instantiated internally
+- [ ] Constructor parameter types are abstractions (Protocol / ABC), not concrete classes
+- [ ] No `ConcreteClass()` call inside a class body
+- [ ] No concrete infrastructure imports in domain or application modules
+- [ ] Composition root (entry point) is the only place that wires concrete implementations
+- [ ] Tests inject substitutes via constructor — no patching of internals
+
+
+## Dependency Injection Examples
+
+### Correct
+
+```python
+from typing import Protocol
+
+class PackRepository(Protocol):
+    def find(self, name: str) -> Pack: ...
+
+class PackLoader:
+    """Load packs using an injected repository."""
+
+    def __init__(self, repository: PackRepository) -> None:
+        self._repository = repository
+
+    def load(self, name: str) -> Pack:
+        """Return a pack by name from the repository."""
+        return self._repository.find(name)
+```
+
+```python
+# Composition root — only place that wires concrete types
+def main() -> None:
+    repo = FileSystemPackRepository(root=Path("packs"))
+    loader = PackLoader(repository=repo)
+    cli(loader=loader)
+```
+
+### Incorrect
+
+```python
+class PackLoader:
+    def __init__(self) -> None:
+        self._repository = FileSystemPackRepository()  # concrete, internal
+
+    def load(self, name: str) -> Pack:
+        return self._repository.find(name)
+```
+
+```python
+# Infrastructure import in domain module
+from argus.infrastructure.fs_repo import FileSystemPackRepository  # wrong layer
+```
+
+### Testable with injection
+
+```python
+class FakeRepository:
+    def find(self, name: str) -> Pack:
+        return Pack(name=name, content="# stub")
+
+def test_loader_returns_pack_by_name():
+    # Given
+    loader = PackLoader(repository=FakeRepository())
+    # When
+    result = loader.load("tdd")
+    # Then
+    assert result.name == "tdd"
+```