hq/04-ISSUES/077-a-fact-fetched-at-first-start-is-fetched-once/01-diagnosis.md

# 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.

**What closed it, and what did not.** The report named two ways the fact changes: the provider
moved, or its state wiped. The move is closed: it rewrites the consumer's binding, the step names
that binding, and the host's unit test runs the step again on exactly that rewrite — the bed that
would re-key a live authority was not written, because a move *is* a rewritten file and the unit
test covers the file. A state wiped behind the mesh's back on the same node is not closed and is
not claimed (ADR 0099, consequences): nothing the mesh knows changes, so nothing it declares can
follow it. On the mesh's own path it does not arise — the authority's state directory survives
unassign and reassign, and a re-issue does not touch it.