reworklisted

# rework The question that ends most loops: > **I have changed this file three times without running it. What would running it tell me right now?** Rework is not caused by bad edits. It is caused by *unverified* edits — each one built on the assumption that the last one was right. When the first assumption turns out wrong, everything stacked on top of it gets redone. --- ## The three loops ### 1. The blind stack Edit, edit, edit, edit, then run. If the run fails, you do not know which of the four was wrong — so you re-reason about all of them. **Batching a few related edits is good practice.** One run per typo would be absurd. The cost appears at depth, and it is not linear: a stack of three is cheap to unwind, a stack of fifteen is a rewrite. **The rule:** batch edits that are *the same change* — a rename across four files, one fix in three places. Run before edits that depend on the previous one being right. The moment to stop and run is when you notice you are about to write *"and also"*. ### 2. The retry loop A command fails. You adjust a flag and run it again. It fails. You adjust a path. It fails. By the third attempt you are no longer testing a hypothesis, you are guessing at a shape. The fix is never a fourth guess: - **Read the error properly.** Not the last line — the first one. The first error causes the rest. - **Shrink the command.** Drop the pipeline, the redirect, the quoting, the flags. Get the smallest thing that runs, then add back one piec