Records say what the build does: 0101 names only measured daemons; 0102 adds to lists and keeps what it writes over; 0103 names every held kind, the found-service rule, conflicting found rules, guards, and what of 0100 it replaces; designs 05, 09 and 17 in step; issue 084's diagnosis in its own file

03-DESIGN/01-to-be/05-the-node-host.md

@@ -158,8 +158,11 @@ keeps its mode and owner, a unit present with no record keeps its state and boot
 container that would mount found data is not created, and an action run in a held container
 waits for the cutover. **A file the machine shares is written into, never over**
 ([ADR 0102](../../02-DECISIONS/0102-the-mesh-writes-into-a-shared-file-never-over-it.md)): the host sets the mesh's keys in the object already there,
-keeps every other key, records what each of its keys held before and gives them back when the
-file is undeclared. Such a file replaces nothing, so it is never held. A service that re-reads
+keeps every other key, adds its members to a list already there rather than replacing it,
+records what each of its keys held and which members it added, and gives them back when the
+file is undeclared. Such a file replaces nothing, so it is never held. And on any node, before
+the host writes over a file it has no record of making, it keeps the original once and names
+where; if it cannot keep it, it does not write. A service that re-reads
 its configuration is **reloaded** for what it names in `reload-on`, never restarted. *How it is
 checked:* unit tests hold the host to each of these, and the adoption bed asserts the runtime's
 own settings survive adoption and a container without a restart policy keeps running.