Your implementer looks for what you already have before it writes something new. Hand it a task whose best answer is a helper sitting elsewhere in your repository and it now finds that helper and uses it, instead of writing a second copy of the same logic a module away. When it finds something that only partly fits, its report names that helper too, so a near-miss is visible to you rather than silently passed over.
A plan that asks for more structure than the job needs no longer gets built as written. Where a lighter route satisfies the task's own "done" check, the implementer takes it and records the swap for you to see, rather than faithfully building a configuration class and a new module to do the work of one function. Structure you genuinely need survives: when several callers really do need different settings, it still builds the shared piece.
The loop is now asked to weigh each addition it declines against a stated rule. Its "tempted to add, chose against" note asks for the "Cut before adding" step behind each line, so the reasoning sits against a written rule rather than a one-off justification, and where no step covers the call — an accepted requirement or a safety control forbids it — it is asked to say that instead of fitting a rule to it after the fact. This one is guidance the note requests rather than a check that enforces it, so read the notes rather than relying on them.