From 5c5821b21056886a70c9fe399bc1eab6de9097ef Mon Sep 17 00:00:00 2001 From: jochen Date: Tue, 22 Sep 2026 22:00:38 +0200 Subject: [PATCH] Issue 085 resolved: the packages port is a node setting; two of its open questions stay open --- .../00-report.md | 28 +++++++++++++++++-- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/04-ISSUES/085-the-packages-port-given-at-genesis-is-not-a-setting/00-report.md b/04-ISSUES/085-the-packages-port-given-at-genesis-is-not-a-setting/00-report.md index 58af427..c2a9c01 100644 --- a/04-ISSUES/085-the-packages-port-given-at-genesis-is-not-a-setting/00-report.md +++ b/04-ISSUES/085-the-packages-port-given-at-genesis-is-not-a-setting/00-report.md @@ -1,8 +1,8 @@ --- -status: open +status: resolved opened: 2026-09-22 -located-in: [] -fixed-by: +located-in: [mesh-host internal/bootstrap, mesh-catalog modules/builder] +fixed-by: mesh-host#21, mesh-controller#45, mesh-catalog#39 amended-design: --- @@ -47,3 +47,25 @@ registers or takes over that module again, and nothing checks that it stays give from the provider? - What should check that every foundation port given at genesis is still the port in use after the foundation is adopted as modules? + +## Resolution + +*2026-09-22.* The port given at genesis is a per-node setting now, in two places: the forge's own +`ports`, and the `serves.port` of the binding the builder carries. Both come from the one input at +genesis. The installer no longer rewrites the builder's manifest, so re-registering the builder +keeps the port, and the forge's module comes up on it. + +The forge's module is registered at genesis without being assigned, so the setting has something +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. + +**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 +checks that a port given at genesis is still the port in use once the foundation is adopted as +modules. + +Three neighbouring gaps found on the way are their own reports: +[088](../088-the-forges-own-address-names-a-port-it-may-not-have/00-report.md), +[089](../089-a-contributed-route-names-a-port-the-node-may-have-moved/00-report.md), +[090](../090-the-forge-module-does-not-take-over-the-forge-genesis-raised/00-report.md). -- 2.54.0