Uncomplect

Treat the current system as a functional prototype. It proves which behavior matters; it does not prove its structure was right. Keep the behavior and the evidence, and let the accidental structure go.

The goal is fewer braided concerns, not fewer lines. A replacement that adds a type and deletes three special cases is simpler. A replacement that adds a layer and deletes nothing is not.

Read first

Recommendations built on guesses about the code tend to fix a system that does not exist, so ground every one in what you read. Start with the nearest project instructions, decisions, source, tests, runtime receipts, and current incidents.

For state-machine code, read the machine, the persisted state, the restoration path, invoked actors, guards, and transition tests. For effect-system code, read the project's pinned version and its existing service, error, retry, and transaction boundaries, and check APIs against that version's source.

You are done when every recommendation names the fact it rests on, the behavior it preserves, and the complexity it deletes.

Hickey: separate what was braided

Complection is two independent concerns woven together so that neither can change alone. Build a table of them: