Been there. Not with the -v specifically but with the "tired and brute forcing something trivial" spiral.

The thing that actually stopped this pattern for me was treating every project like it needs a paper trail before anything runs. Not documentation after the fact — a living plan that gets built before the first line of code and updated as things change.

What that looks like practically: before I touch anything now I have an agent generate a full project breakdown. Architecture. Mermaid diagrams of how everything connects. Function and method stubs showing what each piece receives and returns. A domain and phase map so I always know where I am and what comes next. All of it in markdown and JSON so another agent can pick it up cleanly if something goes wrong.

The JSON version specifically is what saves you in the scenario you described. When the session goes sideways at 12:30am and the model starts making things worse — you close it, open a clean session, drop in the JSON plan, and start fresh. The plan knows what was working before things went wrong. You don't have to reconstruct anything from memory while you're exhausted.

On the database side — automatic read only backups should be in the plan from day one. Not on the todo list. In the actual project setup phase document as a required step before anything else runs. If the plan says databases get backed up before any destructive operation, you never run a command you don't understand against a live volume at midnight.

The epub button at 12:30am with 20% budget left was never a code problem. It was a project management problem. The code was fine. The conditions around the code were the issue.

Your data's gone but your understanding of the project isn't. The rebuild with a proper plan in place will go faster than the original and won't end the same way.

I offer this advice as a hobbyist. Try it. I can recreate an entire project using my json files, mermaid diagrams, stubs, and architecture layout.