unslop

# Unslop Treat this as a job-site walkthrough before demolition. Find the places where the code makes ordinary work harder, separate proven friction from a hunch, and make one sound cleanup choice at a time. Do not assume code is bad because AI wrote it; judge the shape and the evidence. ## Establish the ground truth Read `CONTEXT.md` and relevant `docs/adr/` records before drawing conclusions. Use the terms from `/codebase-design`: **module**, **interface**, **implementation**, **depth**, **seam**, **adapter**, **leverage**, and **locality**. Use the project's glossary for domain terms. - Respect a recorded decision unless current, observable friction justifies reopening it. Mark that conflict plainly. - Keep an observation separate from its proposed cleanup. Cite the files, call paths, tests, or repeated patterns that support each observation. - Do not start refactoring while the review is still choosing a target. ## Walk the codebase Start at entry points and follow a few representative user flows through their tests and dependencies. Read enough surrounding code to understand the responsibility before flagging it. Look for work that is unnecessarily spread out: - A shallow module whose interface asks callers to understand nearly everything its implementation does. - Pass-through modules, one-use helpers, or abstraction stacks that merely move a decision to another file. - Repeated types, validation, branching, or error handling that has drifted between callers. - Infrastructure details leaking over a seam into domain logic or callers. - Tests coupled to private choreography instead of observable behaviour. - Ambiguous names, generic indirection, dead paths, or speculative knobs that obscure the domain model. - Changes to one behaviour that require edits across many modules, showing poor locality. For every suspected shallow module, run the deletion test: mentally remove it. If callers would each have to reconstruct its work, it is buying leverage. If little changes beyond file locations, it is probably slop. ## Present the cleanup brief Give the user a compact Markdown brief in the conversation. Do not create a temporary HTML dashboard: the audit needs an actionable comparison, not a second artifact to maintain. Include three to seven candidates, ranked by the value and confidence of the evidence. For every candidate, include: - **Name and files** — name the responsibility and list the concrete paths. - **Evidence** — what the walkthrough showed, with relevant symbols or lines. - **Friction** — explain the problem in terms of depth, seam, locality, or leverage. - **Cleanup direction** — describe the safe consolidation or separation, but do not settle a new interface yet. - **Proof and risk** — tests to add, preserve, or replace; migration hazards; and any ADR conflict. - **Strength** — `Strong`, `Worth exploring`, or `Speculative`. End with one top recommendation and the reason it wins now. Ask the user to choose a candidate. A simple before/after sketch is useful when call flow or module ownership would otherwise be hard to see; omit decorative diagrams. ## Take the selected candidate to completion For a cleanup with a real design choice, use `/grill` to settle the module's responsibility, seam, and constraints before changing code. For a small, well-bounded cleanup, state the intended observable behaviour and proof first, then use `/implement`. - Put new tests at the deepened module's interface. Once that proof exists, remove tests whose only purpose was pinning a discarded shallow wrapper. - Introduce an adapter or seam only when at least two real implementations need it. See `/codebase-design` for dependency categories and alternative interfaces. - Keep the cleanup focused. A candidate that exposes a larger design question becomes a separate follow-up rather than expanding the current change. - Finish with `/code-review`: inspect the full change, confirm the old drift is gone rather than relocated, and run the relevant checks.