Refactor

Refactoring changes structure, never behavior. If behavior must change, that's a feature — use /tdd instead.

Before touching anything

Tests must exist for the code being changed. If they don't, write characterization tests first — capture what the code does today, not what it should do.
Establish a green baseline:
```
composer test
```
Never refactor on red.

Name the smell before choosing a technique.

Smell	Move
Long method	Extract method
Large class (> 200 lines)	Extract collaborator
Long parameter list (> 3)	Introduce a `Transfer` object
Duplicated logic	Extract to a shared method or Domain value object
Feature envy	Move the method to the data's owner
Primitive obsession (`string $txid` everywhere)	Value object in `Domain/Data/`
Growing `switch` on a type	Interface + implementations, bound in the provider
`new` inside business logic	Inject the interface, bind in the ServiceProvider
Query in an Action	Move it into the repository
Comment explaining what	Rename until the comment is redundant

One refactoring at a time. Run the narrow test after each:
```
vendor/bin/phpunit tests/Unit/<Module>/
```
Watch the layer boundaries while moving code — extracting a class is the moment things drift. Interfaces land in Domain/, policy in Application/, adapters in Infrastructure/. Anything extracted from Domain must stay Laravel-free.
Update the binding if an extraction introduced a new interface.
Full gate + style:
```
composer fix
composer test
```
Commit with ref: — small and atomic, one refactoring per commit.

Public behavior stays identical — tests must pass unchanged. Editing a test to make a refactor pass means the behavior changed.
Do not mix a refactor with a feature or a fix in the same commit.
Extracting a class for its own sake is not an improvement — name the smell it removes.