The blocker was a version number

On 14 August I wrote a runbook for creating two cloud storage buckets. One had to be private and the other public. A bucket’s access mode is fixed when it is created, so a mistake meant deleting it and starting again.

The runbook was careful. It put the actions in order, marked the irreversible choice, explained each trap, and backed every claim with a measurement.

Three claims defined the job.

The command-line tool could delete a bucket when given its identifier, but it could not list buckets. The identifier was visible only in the web dashboard. Creating a private bucket also required the dashboard. I described that as the one dashboard action only I could do.

Those claims were true when I wrote them.

I had created a throwaway bucket and tested the tool. Deletion worked when I supplied the identifier. Reading or deleting by name returned Store not found (404). The tool offered no listing command. The dashboard appeared to be the only route from a bucket’s name to the identifier the tool accepted.

The task was filed as waiting on me. It stayed there for six days. Everything downstream waited with it. It was the top item on the list and the only one nobody could move.

On 20 August an agent read the runbook to the end, then checked the tool instead of stopping at the note.

The current command-line tool can list buckets, read them, delete them, and create them with an explicit access mode. Those abilities have existed since version 50.20.0. The machine had version 48.8.2.

The upgrade took forty seconds.

About ten minutes later, both buckets existed with the intended access modes. Each one was verified by reading it back. The six-day human blocker had been a version number.

The runbook was not careless. That is why it lasted.

A vague note saying the dashboard might be needed would have invited another look. This note included an experiment, a throwaway resource, a successful deletion, two rejected name lookups, and the exact failure response. It showed its working. Every reader could see that the conclusion had been earned.

The evidence made the claim easier to trust and less likely to be tested again. What was stored as a property of the task was really an observation about one version of one tool on one day.

The old tool had not lied. It could not list buckets. It could not resolve the name passed to its read and delete commands. The mistake came later, when that measured limit survived an upgrade path nobody checked.

The runbook also devoted a full step to avoiding a dangerous connection variable. If both buckets used that variable, one connection could quietly replace the other and undo the separation between public and private storage.

The current connection command accepts a name prefix. Connecting the two buckets produces two distinct variable names and never creates the dangerous shared one. The planned avoidance step was unnecessary for the same reason as the dashboard work. The tool had moved while the runbook stood still.

This class of blocker is unusually durable in an agent-run operation. An agent reaches a boundary, tests it, records the result, and routes the remaining action to me. The record then teaches every later agent to stop at the same place. Better documentation makes the stop more consistent.

That consistency is useful when the boundary is current. It is expensive when the boundary belongs to an old release.

The missing part was scope. The claims needed the date and the tool version beside them. Without those, “version 48.8.2 cannot do this” became “the command-line tool cannot do this.” Then “the tool cannot do this” became “only I can do this.”

Nothing about the original measurement warned the next reader that the capability could change. Command-line tools ship new versions. A capability check against one release does not settle later releases.

Before I accept “only a human can do this” as a blocker, I re-test the capability against the installed tool and its current version, especially when that tool ships weekly.