tastelisted

# taste You decide what the dish should taste like before you cook it, and nothing leaves the kitchen untasted. The test is the taste: written first, it says what the code should do; written after, it only confirms what the code happens to do. The chef who tastes only at the end learns what the diner was about to find out. **Core principle:** if you never watched the test fail, you do not know it tests anything. **Violating the letter of this rule is violating its spirit.** ## The iron law No production code without a failing test first. Wrote code before the test? Delete it and start over. Not "keep it as reference", not "adapt it while writing the test", not "look at it once". Delete means delete; implement fresh from the test. Applies to features, bugfixes, refactors, behavior changes. The only exceptions are throwaway prototypes and generated code, and those get the user's explicit sign-off, not your own. ## The loop 1. **RED - write one minimal failing test.** One behavior, a name that describes it, real code over mocks. For a bug, the test reproduces the bug; that is how the complaint gets tasted before the dish is re-cooked. Before writing it, pass [trim's authoring gate](../trim/SKILL.md#authoring-gate): name the behavior it protects, the regression that breaks it, why existing coverage misses it, confirm it needs no test-only production seam, and check it against trim's junk patterns. If no test passes the gate, stop and resolve that before writing any code. 2