Issue 210: the record of the runtime's process carries no digest; the credential and the unit text are ruled out

04-ISSUES/210-the-host-re-creates-the-nodes-runtime-on-every-reconcile/00-report.md

@@ -36,13 +36,16 @@ when the machine is as declared; a `process` here never does.
 
 Owner mesh-host, `internal/apply/process.go`. The decision is: the digest of the fetched bundle
 plus the unit text is `want`; when the host's record of what it last wrote equals `want` and no
-`restart-on` resource changed, the process is left alone. The unit text is rendered with sorted
-keys, so `want` is stable. The log says `created` — the word the code uses only when the previous
-record is empty (with a record it would say `updated`) — so what fails is the record: for this
-resource the host does not find what it wrote last cycle. Two candidates, to be settled in the
-host's tests: the applied-store does not persist or does not key a `process` outcome the way it is
-read back, or the outcome's `wrote` is dropped before it is saved. **Fix direction:** a test that
-applies the same `process` declaration twice against a recorded store and asserts the second
-outcome is `unchanged` with no restart. Observed only on the laptop's journal; the other three
-machines' host logs are not readable by the operator account over SSH, and the behaviour is the
-host's, not the machine's.
+`restart-on` resource changed, the process is left alone. Two things were ruled out on the laptop:
+the credential the runtime restarts on, which has not been written since the evening before (the
+host would also say `updated`, not `created`, for a restart it owed to another resource); and the
+unit text, rendered with sorted keys and so stable. What fails is the record. The host's state file
+holds an entry for `node-tools.runtime` — applied at the last cycle, with **no `wrote` digest at
+all** — while the sibling entry for the runtime's credential carries its digest. The apply sets the
+digest on its outcome on every path that installs the daemon, and the loop that records outcomes
+copies it into the record for every kind; between the two, a `process` outcome arrives with its
+digest empty. **Fix direction:** find where a `process` outcome loses its digest on the way to the
+record, and a test that applies the same `process` declaration twice against a recorded store and
+asserts the second outcome is `unchanged` with no restart — the test the shape never had. Observed
+on the laptop's journal and state; the other three machines' host logs are not readable by the
+operator account over SSH, and the behaviour is the host's, not the machine's.