4 Commits

Include renames

Author	SHA1	Message	Date
jochen	6f13813a59	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 02:55:11 +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