Batches, and Stopping Without Losing Anything

One executor, one pass, one commit - and the work can be dropped at any boundary. 👋 I'm Anton - a software engineer working mostly in PHP/Symfony and Go, currently carving a live PHP monolith into Go services. Earlier parts of this series were about what an executor must know, how small a unit of work has to get, and how to write a task with nothing left to interpret. This part is about the thing I only learned by having to stop in the middle: the unit at which work becomes droppable . Notes: github.com/brilliant-almazov . Maybe you already do this better, maybe you organise it differently - either way I'd rather hear how than assume mine is the shape. As always: these are my habits on one codebase, not advice for yours. The evening I had to stop mid-stage A stage of 13 iterations . The first wave had closed, the second wave was running, and I had to put the work down right then - not "wind it up", not "finish the current thing", stop. There was exactly one question worth asking, and it wasn't "how far did I get". It was: What is sitting uncommitted, and what would I have to reconstruct from memory? The second half of that question is the trap, because of how the executor works. It carries nothing between tasks. No dialogue history, no memory of the previous iteration, no accumulated sense of "where we were". Every task arrives complete or it doesn't arrive at all. So "I'll pick it up tomorrow and it'll remember roughly where we were" is not available to me at any price. Tomorrow's executor starts from zero, from the text I wrote. Which means the only thing that survives an interruption is what's written down and committed . Everything else is in my head, and my head is the least reliable component in the pipeline. I want to be precise about the framing, because this is the part I got wrong for a while. Being interrupted is not an emergency to be handled. It is the normal case. A day ends, a production incident lands, a call runs long, priorities move. If the way I