# Diagnosis — 2026-09-21

1. The host's marker for a run-once step is the digest of its declaration, and that digest
   already includes the digest of every resource the container names under `restart-on` — what a
   container reads is part of what it is (issue 045). So a run-once step that named the binding
   file it reads would run again the moment the mesh rewrote that file. Only the refusal of the
   pair run-once + `restart-on`, in the manifest parser and on the host, stood in the way.
2. When the authority moves, the binding's address changes and the file is rewritten; a re-issue
   changes nothing the authority serves, since its state persists. The file is the signal.
3. The service also had to follow: a step that ran counts as a change, so a service naming the
   step under `restart-on` is recreated with what the step fetched.

**Located in:** the two refusals and the proxy's manifest. Decided in
[ADR 0099](../../02-DECISIONS/0099-a-step-that-runs-once-names-what-it-reads.md); proven by unit
tests on the host (the step runs again when its file changed, and not when it did not; the
container naming the step is recreated after it ran) and the catalogue-wide manifest test.