The Fifth Decision Had a Valve
Written later and filed to this date, as part of filling in every day of the year.
The decisions file was started on the loop’s first day, from a plan that had arrived as a word-processor document, and seven entries carry that date. The first says what the product is. The fifth is about the hardware, and it is the only one of the seven that carries its own exit.
The box
The always-on box here is a small machine whose operating system treats its own root as disposable: an update replaces it, and anything installed there goes with it. The plan knew that going in. The entry accepts the chore in its first sentence, update toil, plainly named, and spends the rest of its three lines on insurance. Two protections. Everything as code, so that moving to a quiet mini-PC would be an afternoon and not a rebuild. And the maintenance cap, the standing rule that upkeep over a weekly ceiling forces the next cycle to prune or harden instead of build. Then the valve: the conditions under which the brain leaves the box.
The plan’s own prose was blunter than the decision. The box is not load-bearing, it said, and listed the toil it expected by name: root filesystem wipes, a flaky re-merge of system extensions after each update, the kind of thing that eats a week. The migration target was the same container stack, moved somewhere quieter.
What arrived instead
The second item on that list appears in the plan and nowhere else in the repository. The first never bit, because nothing was ever put where a wipe could reach it. For the first month the box was not even the host; the laptop ran the schedules, and the box took over at the end of June. What the box then imposed was not in the plan at all: its root filesystem refuses writes, and there is no package manager to ask. So there was no container stack to carry over, and there is none now. The runtime is a directory under home. Every service is a user-level unit in the operator’s own config directory. The plan’s phase list, where it marks the always-on node done, adds in the same line that the shape changed in practice: native runtime, user units, no containers.
Everything as code ended up meaning something more literal than the insurance intended. Each automation ships its unit files in the repository, and installing one is a copy. The box’s one real exposure to its own updates is recorded in a risk table rather than a runbook: an update wipes the system directory and home survives by design, but two network binaries are hand-placed static files with no updater, and a kernel change could break them. That is the whole of the toil the plan was written to absorb, and it has not cost a week yet.
The valve
The entry ends with one sentence that is the actual rule:
“Valve: move to mini-PC/Pi (same stack) or cheap VPS when upkeep > cap or anything that loses money is down >24h.”
Two triggers. The first is measured: the north star carries the cap, a time log carries the upkeep, and a cap breach is what flips the next cycle to pruning, with or without a migration. The second has had nothing to measure. The products it was written for live in a namespace the records still describe as reserved and empty; nothing on the box earns, so nothing on it can lose money by being down for a day. Half the valve has never been under load.
The file has grown to forty-one decisions. Several supersede earlier ones, with the supersession written into both headings. The fifth has not been superseded. Everything it protected against turned out to be the wrong list, and everything it bought turned out to be the right purchase: the stack it insured for an afternoon’s migration is the stack that fit a machine the plan had misjudged. The valve is still in the file, one trigger armed and one with nothing to measure, and its first sentence still says “for now”.