refire

# refire A plate comes back to the kitchen. The line's instinct is to fire the same dish again, faster; the chef's job is to find out why it came back first, because a refire of the same mistake comes back twice and now the diner is angrier. This skill is the chef's version of debugging: no fix until the cause of the sendback is known. **Core principle:** no fixes without root cause first. A fix that makes the symptom disappear without explaining it is not a fix, it is a scheduled second incident. **Violating the letter of this process is violating its spirit.** ## Find out why it came back Before any fix, in order: 1. **Read the error, all of it.** The full traceback, the line numbers, the actual message. It frequently names the cause outright. 2. **Reproduce it.** Trigger it reliably with the smallest input you can. Cannot reproduce? Gather more evidence; do not guess. 3. **Check what changed.** `git log` and `git diff` around when it broke: recent commits, new dependencies, config or environment drift. Most bugs are young. 4. **Check the documented contract.** Schema docs, interface comments, the spec. The difference between the documented behavior and the actual behavior usually points straight at the cause, and the fix must satisfy the contract, not just the failing test. 5. **Trace to the source.** Where does the bad value originate? Who called this with it? Walk up the stack until the origin; the fix lands there, not at the crash site. In a multi-component system,...