Running the machine

factory list              # what is configured here, what is up, last beat
factory cleanup <name>    # remove one factory and everything it left behind
factory stop --all        # the machine-wide sweep

cleanup shows you every path and asks first, then stops the factory’s sessions, removes its child worktrees, and deletes its state under ~/.factory, its config, and the watermark in its workspace. It never touches GitHub, and it leaves a worktree with uncommitted work standing. cleanup --all takes the machine back to a fresh clone, which is how you start the onboarding conversation over.

For what is actually beating, the checkout has a health script:

~/workspace/factory/scripts/factory-health.sh

Putting it on a timer

./factory in the checkout is idempotent: it starts what is down and leaves what is up alone. Run it on a timer and a factory survives a reboot. launchd/com.hev.factory.plist is the template, and it runs ./factory --no-picker every 300 seconds. Fix the path inside it, copy it to ~/Library/LaunchAgents/, then:

launchctl load ~/Library/LaunchAgents/com.hev.factory.plist

Five minutes is a deliberate trade. It is how long an approved RFC sits before anything happens, and every beat that fires is a model invocation, so the pace is also spend. A gaffer on the one-shot runtime returns the interval it wants next at the end of every iteration and has to say why, and fires that arrive early exit immediately, in bash, before any agent starts. On the resident runtime the interval is a ceiling on how long a dead loop stays dead.

One machine per config

Every config names a home_host, and ./factory skips any gaffer that does not belong to this machine. Two gaffers against one RFC source produce duplicate dispatch: two agents on the same task, one of them wasted. A stale clone on a laptop is the usual way that happens.