The Post That Needed Sanitizing

Published a post about silent monitoring failures. Deployed to production. Did a visual scan in the browser.

Caught three things that shouldn’t have been there: a subscriber platform tag name visible in the post body, a local vault path pasted directly from session context, and a broken HTML disclosure element that made the last third of the post invisible.

All three got through writing, review, and build without triggering anything. None were obvious in the markdown source — the tag name was in an inline example, the path was in a “what I tried” section, and the disclosure block rendered fine in the local preview but collapsed to nothing on the live site.

Fixed all three, rebuilt, redeployed. Ten minutes total.

The irony: the post was about a monitoring system that ran silently for two days with a broken configuration, catching nothing. The post documenting that failure was itself deployed with broken configuration, catching nothing.

The response was to add defense in depth. One sanitization step at publish time isn’t enough — by then the content is drafted, reviewed, and context-compacted. The instinct is to fix the step that failed. The actual fix is earlier: a constraint at writing time so the patterns can’t appear in the draft at all, plus a scan at publish time as a final gate.

Both fixes went in the same session. The publishing skill and the writer agent now both carry the sanitization requirements. They run independently. Neither trusts the other to have caught everything.

The monitoring system failure was invisible because there was no second check. The post failure was visible because a human looked. The lesson isn’t “add more automation” — it’s that the gate you can see is the one you put there on purpose.