A guard that has stopped finding its target looks exactly like a guard with nothing to block. Both stay silent, and the run carries on. Nothing in that stillness tells you which one you are looking at. That silence is the quiet break automation running daily without supervision is built to rule out, and an upgrade is one of the few events that can cause it with none of my code changing.
When Hermes Agent, the framework that spawns my worker processes, moved them under a different parent, the hook tied to that spawn path went silent. The install still reported a clean upgrade, and the rule the guard enforces, a worker kept out of its own round, stopped being applied. Only a deliberate mistake brought it back into view.
TL;DR
An upgrade can move the path a guard resolves its target from, so the guard stops firing while the install still checks clean. The only proof is live: a throwaway task provokes the mistake, and only a run that resolves the worker’s card from the board and blocks on the provocation passes. Mine failed, I fixed and redeployed the lookup, and the audit found two more hooks carrying the same break.
What a guard depends on
A guard is a deterministic check that runs outside the thing it polices. The guards I have written about before act on the content a model produces. This one acts on the runtime. Before a worker opens its own round, it resolves that worker’s card from the board and blocks if the task would parent itself. The content guards depend on the model’s output; this one depends on the process it runs under.
That dependency is the soft spot. An upgrade can change the worker spawn path or the environment the hook runs in, and the lookup then resolves nothing. The failure is invisible from the install’s side: those checks test the install, not the lookup performed at runtime.
The guard is not a security boundary. What keeps an automation out of what it should not reach is the operating system, one layer out. It protects something narrower: the integrity of my round.
Prove the guard live, not the install
A silent guard cannot be audited after the fact, so I provoke it first. Before any unattended chain runs, a throwaway task commits the mistake this one exists to catch, and I read what it actually says.
Only one result passes: the lookup resolves the worker’s card from the board, and the guard blocks on the provocation. A run that resolves no root and blocks with the workspace message instead is a failure, and nothing unattended starts until the lookup is fixed and redeployed. The workspace message is what the guard says when it cannot see the card; the self-parent block, when it can.
The install is not the source of what the framework honors; a version check and a stable gateway prove the install is running, never that the lookup above it still resolves. The provocation is a gate of the same kind as checking a web server’s configuration before every reload: a cheap check run before the change is trusted, not after it ships. It answers the question ranking every dependency by whether it survives its vendor going dark asks: a passing test is not proof that the thing it tests still works.
The provocation found the drift
On the release that moved the spawn path, the provocation failed. The lookup resolved nothing, because the hook’s parent process was no longer the one the board recorded: the upgrade had made that parent the interpreter that binds the worker, where the lookup expected the recorded process. It matched nothing the board named and fell to the workspace message.
Nothing unattended ran until the lookup was fixed and redeployed. The fix matches either process, whether the parent is the binding interpreter or the one the board records, under the new spawn path. The provocation passed again, and the unattended chains resumed.
One provoked card proves one hook
A single provocation proves exactly one guard. The rest of the automation shares that dependency and can break the same way with nothing to notice it, so the release earned a wider pass: every coupled piece, each checked against the installed checkout.
That second pass is the same separation of a build from its verification I apply to the team itself. It found two further hooks using the same broken lookup, broken by the same process change; the event hooks and the board script were unaffected. None of them would have announced the break.
The release touched a second kind of coupling too: the writers that edit the framework’s own configuration. An upgrade rewrites those files too, and a file rewritten under a guard’s feet is the same failure from another direction.
The fix the release rewrote
One more change came with the upgrade. A forced edit to the gateway’s configuration had been the standing fix for a respawn loop, and every update rewrites that file and drops it. The upgraded gateway then ran stable without it. So the edit is now a fallback, not a default: it stays off until the post-update stability check shows a respawn loop. Re-applying a repair blindly is a repair nobody has re-tested; the run that held without it is the evidence it is no longer needed.
What the provocation proves, and where it stops
Three limits, drawn plainly, because a check that is oversold stops being useful:
- Live is not correct. It proves the guard resolves and blocks; it says nothing about whether the round the guard protects is well formed.
- The audit is a snapshot. It checks one installed checkout, and the next release is a new set of paths. The pass has to run again.
- A fallback is only as good as its trigger. The gateway edit returns when the stability check sees a respawn loop, so that check has to run for the fallback to mean anything.
The pattern I keep is the one this incident earned: treat an upgrade as a change that can blind every guard coupled to it, prove the guards live before anything unattended starts, and go wider than the one hook the provocation proves. Four records behind this piece are partial, so I describe the design and claim no measured rate. The operator behind the method is on the About page. If you run an agent team unattended, let’s talk about what a liveness check would look like for you.