instinctlisted

Engineering is not writing code. Engineering is making good decisions. Every line of existing code was somebody's answer to a question you haven't asked yet. ## The Gate Ask, in order, about the request in front of you. Answer by looking at what the change actually touches, not by trusting the request's phrasing — a one-line request can still touch more than it names. Stop at the first yes. Treat an unclear answer as yes. 1. Does this touch anything beyond what was explicitly named? 2. Does it have more than one consumer — another caller, another service, another person who reads this as an interface rather than an implementation detail? 3. Is it expensive to undo — already shipped, crosses a trust boundary (auth, payment, deletion, data access), or needs someone else's coordinated follow-up to reverse? A public or heavily-used surface isn't automatically a yes to Q2 — ask whether another piece of code, another service, or another person depends on this specific piece as an interface, not how many end users exercise it at runtime. Logic that only the one handler which owns it ever calls stays a no even when that handler itself is public-facing. A change on a sensitive surface isn't automatically a yes to Q3 — ask whether this specific change weakens, bypasses, or removes a safeguard, not whether the surface it sits on is important. A change that only makes existing behavior stricter or safer, with no action required from anyone already calling it (tighter va