We taught our loop to ask before it publishes. It still can't say yes to itself.

This week we extended our internal autonomy loop to reach the one action in our own stack that can't be undone: publishing a package to the world. The loop can now turn an explicit approval — a tap from a founder's phone, not a click typed at a keyboard — into the exact label that authorizes that publish. It still cannot merge the pull request, publish anything itself, or grant itself permission to skip asking next time.

What the loop already did before this

Over the past two weeks the loop went from watching our own infrastructure to touching it. It opens pull requests for stale dependencies across our repos, keeps shared package versions in sync when they drift, and — under a strict set of conditions — merges its own low-risk fixes without anyone reviewing them first. Every one of those actions is reversible: a bad dependency bump is a revert, a wrongly merged PR is a rollback. Publishing a package is different. Once a version goes out to npm, it's out, and every one of our other tools that depends on it moves with it.

So publishing stayed manual, on purpose, since we locked that gate on 2026-07-05: our release pipeline only runs the actual publish step when the merged version-bump pull request already carries a specific label, set before merge, by a person.

The one label that fires a publish

What we built this week doesn't remove that gate — it moves who can reach it. When our changesets tooling opens the routine "version packages" pull request and its checks are green, the loop now opens the same phone-tap approval card it already uses for other decisions. Say yes, and the loop sets the label itself, through the one audited credential path every cross-repo action in the system already goes through. Say nothing, say no, or let it expire, and the label never gets set.

The pull request still has to be merged by a person. That's deliberate: the label authorizes a publish, but merging is the action that actually fires it, and we wanted a human hand on the last step of the one thing in this whole system we can't take back.

Why does authorizing one label need four separate checks?

Because it's the highest-consequence action anywhere in the loop, we didn't let it rely on the same defaults as the rest of the system. Four things all have to hold before the label gets set: the lane has to be explicitly switched on, the credential that lets it act across repos has to exist, the approval system it's asking through has to be properly configured, and the approval itself has to come back as an explicit yes. Miss any one of those and nothing happens — no label, no path to a publish.

That last point mattered enough to write down deliberately. Elsewhere in the loop, if the approval system is unreachable or unset, the safe default is to treat the action as harmless and let it through. Here we did the opposite: an unreachable or unconfigured approval system reads as "not approved," full stop. It's the one place in the whole design where we refused to let a missing setting quietly mean yes.

The highest-consequence action in the entire loop is the one place we were least willing to let a missing setting quietly mean yes.

It can ask to stop asking. It can't decide that alone.

We also gave the loop a memory for its own track record. It counts how many times in a row a publish has gone through cleanly under this label-and-approve process, with nothing reverted in between. Once that streak crosses ten, the loop writes up a proposal: retire the manual-approval step for this specific action and let it land on its own from then on.

That proposal goes into the same review queue every other suggestion the loop generates lands in, and it sits there until a person reads it and decides. We also built the category that governs "should this thing require less oversight" to be permanently excluded from the loop's own promotion mechanism — it's the one kind of decision the system is structurally barred from ever making about itself, ten clean runs or not.

Where this actually stands today

The code merged into our main branch today, and it does nothing yet. Every switch it needs to act — the lane's own on-switch, the cross-repo credential, the approval system's connection details — is unset. Until we turn those on by hand, the loop reads the state of our release pipeline, logs what it would have done, and stops there. When we do turn it on, the first thing it changes is where one click happens, not who's allowed to publish.