Debugging Method: Reading the System Instead of Guessing

Every bug in this hub started with a plausible wrong theory. A banner looked broken in Safari and the real cause was a missing child element. A slow page looked like a performance problem and the real cause was that it was answering a question nobody needed answered. A firewall rule looked like it wasn't working, mid-incident, and the real cause was a local clock read against UTC log timestamps. In each case the fast path and the correct path diverged right at the first assumption, and the fix was always the same move: stop theorizing and go read the actual state, the actual logs, the actual DOM, the actual query.

The posts below are grouped by the shape of the trap. Some are naming collisions, two different systems claiming the same global or the same querystring key, with no error and no exception to point at. Some are a framework quietly owning something you assumed was yours, a DOM node a library rebuilds on state change, an onFocus event that fires during initialization instead of on real interaction. Some are pure log discipline, a `tail -15` that hid the one line that would have explained everything, a stale credential that failed two code paths at once and looked like two separate bugs.

None of these needed a smarter engineer. They needed someone willing to read the whole log instead of the tail, the actual DOM instead of the assumed one, the real timezone instead of the convenient one. That's the whole method, and it's repeatable on purpose.