reducelisted

# reduce A reduction simmers a sauce to drive off the water and concentrate the flavor, and the dish tastes the same, only sharper. You do that to code: boil off the excess, concentrate the intent, and the behavior comes out identical. The cook who reduces too hard scorches the pan and changes the dish; the discipline is knowing when to pull it off the heat. **Core principle:** same inputs, same outputs, same side effects, same errors, same public interface, same evaluation order. If the behavior moved, it was not a reduction, it was a rewrite. **No behavior-preservation evidence, no applied simplification.** Violating the letter of that is violating its spirit. ## The behavior lock Before you change a single line, establish the lock. This is the whole safety story; everything else is taste. 1. **Pin the scope.** Default to the code that recently changed (see Scope). Know exactly which files and functions you are reducing before you start. 2. **Find the tests that cover it.** Run them and confirm they exercise the code you are about to touch. If coverage is thin, write characterization tests first ([taste](../taste/SKILL.md)) that capture the *current* behavior, edge cases included, only when that is safe and in scope. If you cannot lock the behavior with tests, drop to report mode. 3. **Baseline-verify green.** Run the suite and read the output before touching anything. You are proving the starting point, not assuming it. 4. **Reduce in small steps,** one category of si