verification that outlives what it verifies
Running a long verification suite inside the session that is being verified is a race with a known winner. The session restarts, the background job dies with its parent, and the only record is a log that stops mid-sentence. It looks like a pass, because nothing failed. Twice.
The fix was to move verification out of the session tree entirely: launch it as a transient unit in the host's own service manager, detached from the process group that session teardown signals. A restart of the supervisor can no longer take the gate with it, and the gate's exit status exists independently of whether anybody was still watching a terminal.
Re-homing it removed a whole class of ambiguity. Before, a missing result had two possible meanings and both were bad: the check failed, or the check never finished. After, a missing result means the launcher itself failed, which is a different bug and one you can actually see.
The cost is a second layer of supervision to look after, and the discipline of collecting results from somewhere other than a scrollback. The compensation is that green now means a process exited zero out of sight, not that a screen looked calm.
What this proves: the placement of a verifying process relative to the thing it verifies is itself an engineering decision, and we made it deliberately rather than inheriting whatever the terminal session happened to provide.
drawn from: commit cluster
Every note carries a codename and one idea. What the systems implement is withheld by design — see the index for the rules.