Specified for a Remote It Was Forbidden to Have

Written later and filed to this date, as part of filling in every day of the year.

The first commit of the loop that runs my workspace landed on a Sunday in May, and the engine was in it: a fifty-five-line file called Routine #0, Operator Review. It observes the week, re-scores the backlog and proposes one move; it does not build. “I propose; you choose” is the whole design, and it is the part that keeps me the operator rather than the operated. The file is a spec for a scheduled cloud routine: a trigger line with the day and time left to fill in, a repository to write to, a connector for the code host, and a prompt. Step six of the prompt: open a draft pull request titled with the date.

The spec

Read the connector line again. A cloud routine runs on someone else’s machine. It needs a repository it can clone, which means a remote, and a pull request to open into, which means the same remote. The second routine in the same commit, a doc-drift check, had the same shape and the same connector. Both were written as the proper, hosted way for the loop to drive itself, and both were waiting on one thing: somewhere to push.

The gap

The same Sunday produced the loop’s first decisions, and the ninth one said the loop commits locally and deliberately does not push. Local git was valuable on its own, history and diffs and the draft-change model, and every outward-facing action, deploy, send, spend, stayed gated. The decision ends: “Revisit only if cloud Routines (which need a remote) are wanted.”

So by Sunday night the loop had an engine and a rule, and together they made a machine that could not turn. The engine assumed the one thing the rule forbade. Nothing was wrong with either on its own. The review was the right review and the rule was the right rule; they had been written as if the other did not exist, by the same hand, hours apart. The first review in the folder is dated that Sunday, and the routine did not produce it. A session read the spec and played the routine by hand.

Monday

Monday has eighty-seven commits in that repository. Among them: a CLI dispatcher with a wrapper at the repository root; a local operator-review runner, with the scoring formula pulled out into a shared library; a local doc-drift checker; a wins aggregator with a net-positive audit; a time-log command; a maintenance-cap check; a generator for the laptop’s own job scheduler; three report-only automations, one of them a mail triage that writes draft files and never sends. The review step became aiops review, writing into the same folder the hand-played Sunday review lives in. Score, audit and doc-drift became commands beside it.

None of this replaced the cloud specs. They stayed in their folder as the future remote path, in case a remote ever arrived. What changed was which side was real. The loop’s steps had to be things that run here, on a schedule this machine keeps, against files on this disk, or the loop was a document.

The rule

The decision recorded that Monday is short, and its reasoning is the gap above: the ninth decision kept everything local with no remote, the routines assumed a cloud, so the loop could not actually drive itself. Local executables close that gap. The hard gates did not move. The review command proposes only; nothing adopts itself; I still pick.

What I took from that weekend is a test for any spec I write for a machine that is supposed to run without me. Before the prompt, read the connector line, and ask whether the thing it names is allowed to exist. The rule, as it stands in the decisions file: “Loop steps are local executables, not just cloud Routines.”


← all writing