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).