Claude Code stopped most when work looked done, not when it broke

The month's setup was deliberately ordinary: Claude Code was given article drafting and scheduled publishing, daily page-view collection into a database and dashboard, static-site edits and deploys to Cloudflare Pages, and morning tasks triggered by scheduled tasks and a Worker cron. The failures clustered in the seams between doing an action and confirming what it produced. The clearest case was an image-set task where the insertion happened but the final save did not, so the API returned an empty image field.

A second pattern was counting wrong. Four times, code read only the first page of a paginated API. Because the JSON looked valid and many APIs sort by page views descending, the dropped items were always low-traffic ones; in one instance the total page views read 183 against an actual 189, too small a gap to notice. The operator's chosen guard was to cross-check counts against a second source, comparing a statistics API's 22 records with 22 published articles from an unauthenticated API, rather than rewriting the loop.

A third theme is verification against the wrong signal. After one update, an article's length fell from 21,101 to 20,095 characters, prompting a recovery effort, but nothing had been lost: the service reassigns block names and ids on every save, and a later save restored 21,101. The stakes here look less about model capability than about the operator's own discipline — whether these outside checks, records, and instructions keep working as the range of delegated tasks widens, and whether the still-unresolved scheduled-execution stoppage is ever traced to its cause.