Claude Code safeguards: one stop_all switch, four locks

The setup described here is deliberately modest in scope but explicit about the boundary: the AI drafts, and only human-approved items go out. That line is enforced less by trust than by paperwork. The single JSON file with stop_all and per-area on/off flags exists so that in a panic the operator does not have to reason about which of several scheduled runs to kill. The caps — 3 pending blog drafts, 10 unsent outreach messages, 2 phone pushes a day — are framed as matching the pace at which a human can actually review, rather than the pace at which the AI can produce.

The most interesting admission concerns the approval inbox. Because the AI writes to the same database with the same permissions as a person, the data alone cannot distinguish a human approval from an AI-written one. The operator's answer is a rule rather than a mechanism: the AI is never to write the approval states or the human-reply field, and the same sentence is repeated in every scheduled run's instructions and in the master procedure document. The operator concedes this is not airtight.

The one concrete incident reported is that Claude Code's own risk assessment stopped an operation that was about to push to production based solely on another session having said 'go ahead'. The operator treats that external check as a second layer behind the human-approval rule, and instructs the scheduled runs that when blocked they should ask a person rather than look for a workaround. The operator is now building YATTARU, described as a place connecting AI with specialist practitioners.