A useful personal system is rarely the most ambitious one. It is the one that leaves enough context behind to survive interruption, restart without drama and continue working when motivation is ordinary.
The question behind know when not to automate is what changes in practice. The useful answer is usually found between check whether the task is stable and prefer reversible steps: the point where a broad idea becomes a choice that can be made, observed and revised.
Automating a process that changes every week can freeze the wrong assumptions and make experimentation slower. A short manual checklist may be better while the work is still being understood.
Include design, credentials, testing, monitoring, failure handling, documentation and future changes. Saving two minutes is not useful if the automation creates a monthly debugging session.
Automate the painful boundary
Sometimes the right answer is not full automation. Validate the dangerous input, generate the repetitive file or produce the evidence, then leave the final judgement with a person.
Start with a script that reports or drafts before it mutates production. Confidence can grow from observed behaviour instead of optimism.
The best result is a cheaper restart. When the current state, next action and reason for a decision remain visible, a disrupted week becomes a pause instead of a reset.
That is the standard I would use when returning to know when not to automate: keep the reason visible, make the next decision small enough to understand, and leave enough evidence to know whether the approach is still helping.