5 Commits

Include renames

Author	SHA1	Message	Date
jochen	5f147fe6b9	Seal the build agent the forge genesis raised, in place of the builder's npm-password (hq issue 121, ADR 0336) ... The build agent declares neither the retired builder's npm-password own-secret nor a serves setting, so the packages step handed its credential to nothing and genesis's sdk step had no way to publish. The packages step now seals the genesis-package-registry own-secret to build-agent: the forge on this node's loopback, the port given for the package registry, its npm path, and the mesh-builder account with its password. setFoundationSettings no longer gives the builder a serves.port.	2026-10-13 03:01:35 +02:00
jochen	d941d798e9	Install the build agent at genesis, the module that builds since ADR 0190 (hq issue 596) ... Genesis's builder step read modules/builder from the catalogue, which retired it on 2026-10-03 for the build agent (node-build-agent on every machine), so no genesis got past step 13. The step now installs build-agent from the catalogue, puts the builder image it carried and published where the manifest names the image it builds, and issues its bus account as any module's.	2026-10-13 02:25:10 +02:00
jschoubben	744beb6c51	A re-run does not replace the registered forge with whatever checkout it was given ... Registering a module is an overwrite. Recording the forge's port ran `module add` every time, so a genesis re-run pointed at an older catalogue would replace the manifest of a forge that is built and assigned — with a push a few lines later. Registering is only here so a settings row has a module row to hang on, and that row is already there on a mesh that knows the forge. So: ask first, and skip. Two comments narrowed to what is true. What follows the node's setting is what the mesh derives from a module's ports — its container mapping, its filter rule, its opening and what it serves. The forge's own address in its runtime's environment (hq 088) and its route contribution's port do not, and are already wrong for any port the mesh assigned. And a settings layer is the module's, not one resource's: a second mergeable file on the builder would be given `serves` too. novox/hq 04-ISSUES/085	2026-09-22 21:56:42 +02:00
jschoubben	c4ce57997e	The packages port given at genesis is a module's setting, like every other ... Every foundation port given at genesis became a per-node setting of the module that binds it, except the package registry's: that one was fixed by rewriting the builder's manifest when the installer registered it. Registering the builder again from the catalogue undid it, and the forge's own module, when it took the bootstrap forge over, came up on the catalogue's port — which on a machine where a predecessor holds 3000 points the builder at the predecessor's forge. So the rewrite is gone, and the port is recorded twice as a setting, both from the one input: - the forge's module is registered at genesis — not assigned, nothing of it runs — so the controller has something to hold `{"ports": {"3000": <given>}}` against. Assigning the forge later raises it on the port this machine was given, and its container, its filter rule, its opening, what it serves and what consumers are told all read it from there. - the builder is given `{"serves": {"port": <given>}}`, which merges into the binding it carries in place of one nothing can resolve yet. A genesis on the catalogue's port records nothing and registers nothing, so it does exactly what it did before. novox/hq 04-ISSUES/085, ADR 0100	2026-09-22 21:40:02 +02:00
jschoubben	48a8f4cf9d	Point the builder's package binding at the port given with --packages-port (hq ADR 0100)	2026-09-22 18:16:00 +02:00