An agent asked to rename one field is editing its fortieth file — what should have told you sooner?

## The count is the weakest signal you have A rename is a change with a naturally wide reach. The field is named by its callers, by whatever serialises it, by the tests that exercise it, and by the fixtures those tests load. Touching forty files for a one-field rename can be correct work — the number describes how connected your codebase is, not how the run is behaving. A rule of the form *stop it at fifteen files* stops good runs and lets bad ones through, because a run that is going wrong is usually going wrong well before it gets there. What you want is a signal that fires on the **kind** of file entering the change. ## Legitimate reach against new territory The useful line is between an edit that follows from what you asked and an edit that opens an area you did not ask about. Following is fine; opening is the event. | edit | reading | |---|---| | a caller updated to the new name | follows from the rename | | a test's references updated to the new name | follows from the rename | | a test's expected values edited so it passes | the run is fitting the specification to the code | | stored data or its shape changed | a new area, and a far harder one to reverse | | an externally visible response shape changed | a new area, and other people's systems are in it | | a new module or abstraction added | not a rename at all | The bottom three rows open areas you did not approve when you approved a rename. The row above them is a different signal with the same value: no new area is involved, but the run has moved the standard the change is judged against. ## The signals that arrive before the count does - **The first file outside the named area.** Not the tenth. The run has just made a judgment you did not delegate, and the moment it does so is the cheapest moment to look. - **An edited expectation.** A test that changes because an identifier changed is a consequence. A test whose asserted values change is the run deciding that the code is right and the test is wrong. Those look similar in a file list and are not similar at all. - **A reason that lives inside the session.** *To keep this consistent, I also need to…* is the run explaining a decision rather than asking about it. The explanation is usually sound; the point is that it is a decision you did not make. - **Repair turns.** A turn whose purpose is to fix what the previous turn broke is ordinary once; a run of them is a run that has stopped advancing and started coping. ## Why the cheap moment is early Two costs grow with every further turn. The first is unwinding: later turns are built on the widened change, so returning to the point before the expansion throws away more work each time. The second is review: a change spanning two areas with different blast radii is hard to review honestly as one thing, and a reviewer who reads it as one thing tends to read the small half carefully and wave the large half through. There is also a human cost worth naming, because it is the one that decides the outcome. The longer the run goes, the more invested you are, and the nearer the change is to working. Almost nobody stops a run that is nearly done. That is exactly why the condition that will stop you is worth fixing before the run starts rather than in the moment. ## What to do when you see it 1. **Stop the run at that file** rather than at the end of the turn's plan. 2. **Ask what that file has to do with the request.** The answer is either a consequence you had not thought about — which is useful and often means your request was incomplete — or a decision the run made, which is yours to take back. 3. **Choose a landing.** Narrow the instruction and continue, when the widening is one identifiable area and the work so far is sound; or return to the last point you verified, when the widening shows the run was working from something you did not intend; or take the rest back by hand, when what is left needs a judgment you would have to make anyway. 4. **Write the boundary into the next instruction** in the terms the failure gave you: which areas this change may touch, and what it must stop and ask about. ## What this is not This is not an argument that a run which widens is misbehaving. A run told to rename a field and leave the tests passing may do whatever makes the tests pass, and an edited expectation is a reasonable reading of that instruction. The widening is as often a property of the request as of the run. It is also not the question of how small to cut the work in the first place, which is a separate subject. Prevention and recovery are different skills, and a run that widens despite a well-cut request is common enough that noticing it in flight is worth practising on its own.