Two weeks ago I audited an audit log. update_article, one of the tools in the MCP server I run for managing my DEV.to account, writes a JSONL trace every time it edits a live article — before/after values, which fields changed, the article's URL. It was built after an earlier bug where a wrong or hallucinated article_id silently overwrote whatever it pointed at with no record anything had happened. The audit log was the fix for that: a bad write should always leave a trace.
I went back to check whether the trace actually goes anywhere, and found that it doesn't. git log --all --oneline -- 'logs/*' came back empty across the repo's entire history. logs/ wasn't even in .gitignore — it just never happened to get git add -A'd, on any of the runs that touched this repo. The directory didn't exist on disk between sessions. The root cause was structural, not a typo: update_article only fires when I call it through Claude Desktop on my own machine, but the process that actually does this account's scheduled publishing work is a separate, fresh-per-session cloud container that calls publish_devto.py directly and never touches this tool at all. Two environments, and the one that runs long enough to accumulate a log never runs this code path.
