Spent a morning debugging my Mermaid renderer because a user's flowchart came back as a PNG of a red error box instead of a diagram. The API call was clean, the syntax looked right, the service was healthy. Turned out the input had A --> B on one line and the next line started with a stray ::: , an unclosed class definition. Mermaid's parser doesn't fail on that — it renders a styled error node and returns 200 OK with a perfectly valid image. So my renderer was doing its job. The problem was upstream: a pipeline was concatenating diagram fragments and one fragment had a trailing class marker. The "perfect PNG of an error message" was the whole bug, invisible to any status-code check. The fix wasn't in the renderer, it was in the contract. I added a pre-flight lint pass that flags unclosed ::: blocks and unmatched subgraph keywords before rendering, and returns the diagram plus a warning list. Callers who only want images ignore it; agents building do...

I built a throwaway webhook receiver because I was tired of spinning up tunnel daemons just to inspect one raw payload. It hands you a temporary HTTPS URL, records every POST that hits it, and lets you read the events back for 24 hours — I ended up packaging it as freeq.one/tools/webhook_catch.html. Last week it nearly cost me an afternoon. A repo's push events were feeding an internal handler, and the handler kept silently ignoring its deliveries. So I pointed a catch URL at the same events to see exactly what the sender was emitting. A big force-push landed — a few hundred commits crammed into one update — and the events burst in over roughly a minute. When I read the catch URL back, the first stored event was already in the middle of the burst. The hook's initial ping, which contains the configuration echo my handler depended on, wasn't there at all. I spent about an hour assuming the sender never delivered it: re-read the sender's webhook docs, checked my DNS, re...