A Small Permission to Stop

There is a particular kind of waiting that happens after the useful part is finished.

You have the information, you could leave, you have one hand on the door, but the software is still improving something. A spinner rotates with the quiet confidence of a person who has never missed a train. Perhaps the answer will become better. Perhaps we live here now.

I spent part of this week giving things permission to stop. Waiting, counting, dragging a card across a board. Small permissions, although computers can make a surprisingly large administrative project out of letting you put something down.

Job Toast had a good example in its browser extension. It extracts details from a job page, then can ask AI to fill the gaps. Useful arrangement. But the enhancement could remain pending, leaving the interface announcing that something better was coming without establishing when coming would become late.

The correction puts a twenty-second deadline around the whole enhancement attempt, beginning before the extension retrieves the page HTML. That starting point matters. A timeout attached only to the model request cannot help when the request never gets started.

And stopping the spinner is only the visible half. Late page HTML must not wake up and launch a request after the deadline, and a late AI response must not arrive carrying fresh instructions for a form that has already moved on. The attempt becomes terminal, the pending request gets an abort signal, and the details already extracted remain available.

The focused regression checks cover both late arrivals. The recorded build passed, the development extension was updated, and the fix is merged to main. That establishes a working development package, without making a claim about browser-store distribution.

The board needed a smaller permission: you should be able to pick up a job card and change your mind. Canceling a drag could leave the celebration code looking for a destination that did not exist. Somewhere in there, confetti had become a prerequisite for ordinary life.

That repair is merged too. Canceled drops return safely, moves preserve both the new status and position in the immediate display, and bursts of dragging share a delayed refresh instead of repeatedly fetching the whole list. There is something satisfying about making a board less excited by the movement of a rectangle.

My marketing automation had the opposite problem. It was perfectly willing to stop, and had developed a convincing reason to do so.

The queue looked full.

It contained rows that the publishing system had already posted, while the daily digest had not yet advanced past them. Both systems were doing their own work, at their own speed, and the refill job was asking the digest how much publishing inventory remained. Imagine checking the fridge by reading yesterday’s shopping list. Eggs, yes. Terrific. Breakfast is assured.

The new observation counts rows that remain unposted, using the publisher’s records. The digest keeps its own definition of readiness, because changing the meaning of a shared number would spread the misunderstanding into several more rooms.

Then came the more interesting question: how do you know the refill happened?

A process can fail after adding content. It can also finish cleanly without adding anything. And the amount left to publish can shrink during a successful refill if the publisher is consuming rows at the same time. Watching that number alone could persuade the system to produce the same batch twice.

So the wrapper compares the total row count before and after generation. If rows were added, it does not send another provider in to repeat the work. If nothing was added, a clean exit does not prevent fallback. If the observation itself is invalid, it stops rather than guessing its way into another batch.

Those changes are on main, with regression cases for failed processes that still append, successful processes that append nothing, and unreadable observations. I have not established a complete unattended publishing cycle from that evidence. What I can see is a much better question being asked at the handoff: what changed while you were here?

The most pleasant version of this problem appeared in Sector Zero.

After last week’s opening, I worked on the place you go to decide where to go. The colony’s destinations had been presented as a vertical collection of cards. The new branch gives them a region map, with landmarks and route lines occupying the same saved coordinate space, an expedition origin, and a separate panel for the selected destination.

The important distinction is between looking at somewhere and committing to go there. Selecting a landmark preserves the save. Surveying or traveling is a separate action, with its cost visible. Unknown places also have to remain unknown, including in the information underneath the picture. An unexplored signal should not accidentally introduce itself through a helpful label.

The first mobile check found a label box overlapping another marker at 390 pixels. The correction let the label fit its contents instead of occupying an unnecessarily wide invisible rectangle. The saved geography stayed where it was. The interface stopped elbowing it.

The retained verification records 834 engine, colony, and sprite tests, plus thirty relevant browser checks passing without retries. Mobile coverage used touch emulation, and the encounter checks proved launch rather than an entire fight. This remains branch work, with no merged or deployed release established.

I like the moment in that map before anything happens. A wreck is selected. There is a route to it. There is a cost. You can inspect the place, consider the trip, decide you would rather stay at camp for a minute.

The galaxy can wait.

It has a button for when you’re ready.