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