Research 013: the forge and the registries — a seat answers the wrong question; issues 090 and 085 corrected from the code

2026-09-23 00:38:34 +02:00
parent 6c81ea2204
commit 43b55d6664
4 changed files with 194 additions and 1 deletions
@@ -59,6 +59,11 @@ The forge's module is registered at genesis without being assigned, so the setti
 to hang on — which also has the controller reserve that machine port, something it could not do
 before because it did not know the bootstrap forge existed.

+**On a default-port genesis none of that happens.** The recording is skipped when the port is the
+catalogue's own, so the ordinary mesh raises a forge the controller has never heard of, holding a
+port the controller has not reserved. Noticed while surveying this ground on 2026-09-23
+([research 013](../../01-RESEARCH/013-the-forge-and-the-registries/00-overview.md)).
+
 **Open question 2 of this report is not answered**: a binding still names a port rather than
 resolving it from the provider. Answering it needs a requirement that may go unanswered during
 genesis, and the mesh has no such thing. **Open question 3 is not answered either**: nothing
@@ -25,7 +25,11 @@ four ways at once:
 - **the network** — genesis runs it on the machine's own network, the module's runs bridged;
 - **where its data lives** — genesis gives it no data volume of its own; the module mounts one;
 - **the address it is told to call itself** — genesis sets it from the port given; the module
-  sets none.
+  sets none;
+- **the image itself.** Checked in the code on 2026-09-23: the two are pinned to **different
+  digests**, while the comment above the installer's constant says they are *pinned identically so
+  the module adopts the running server rather than replacing it*. A comment asserting a fact about
+  the system, and the fact is not true.

 Assigning the module therefore does not adopt what is running. It raises a second forge, with a
 different name, on a different network, with a different data directory, beside the first.