Hold the forge to being an ordinary provider, in tests (hq issue 085) #45

2026-09-22T19:58:08Z

jschoubben commented

2026-09-22 19:58:08 +00:00

Tests only. Nothing in the controller needed changing for hq issue 085: a provider's port already reaches its consumers through a node's ports setting. Nothing said the forge was ordinary, which is how it came to be special and got a port written into a manifest instead.

Over the real catalogue manifests:

the forge's port given on a node reaches what it serves, and defaults to the catalogue's without a setting;
the builder's carried binding takes its port from the node while keeping its scheme, npm path, provision and the module it is with;
provision, from, at and as are refused as settings;
the builder's carried binding starts where the forge serves, so the two halves cannot drift apart in the catalogue.

Merge after mesh-host and before mesh-catalog.

go build ./... && go vet ./... && go test ./... green against a throwaway Postgres.

Tests only. Nothing in the controller needed changing for hq issue 085: a provider's port already reaches its consumers through a node's `ports` setting. Nothing *said* the forge was ordinary, which is how it came to be special and got a port written into a manifest instead. Over the real catalogue manifests: - the forge's port given on a node reaches what it serves, and defaults to the catalogue's without a setting; - the builder's carried binding takes its port from the node while keeping its scheme, npm path, provision and the module it is with; - `provision`, `from`, `at` and `as` are refused as settings; - the builder's carried binding starts where the forge serves, so the two halves cannot drift apart in the catalogue. Merge after mesh-host and before mesh-catalog. `go build ./... && go vet ./... && go test ./...` green against a throwaway Postgres.

jschoubben added 2 commits 2026-09-22 19:58:08 +00:00

Hold the forge's port to the same rule as every other provider's 0e413e3e7a

The package registry was the one foundation port not resolved from what its
module serves. Nothing in the controller had to change for it — `ports` on the
forge moves its container, what it serves and what consumers are told, and the
builder's carried binding is settable like any other mergeable file — but
nothing said so, which is how it came to be special in the first place.

Two tests over the catalogue's own manifests: the forge's port is given on a
node and reaches what it serves, and the builder's carried binding takes the
port from the node while keeping who the binding is with.

novox/hq 04-ISSUES/085

Tie the builder's carried binding to what the forge serves, and hold at shut 729537e745

The builder carries a binding because at genesis nothing provides
`package-registry` to resolve one from; once the forge is a module the same
consumer is told what the forge serves. Nothing held the two to the same number,
so the catalogue could drift into dialling one port before the forge is assigned
and another after.

And `at` is now protected, for the reason it had to be: a setting that moves it
points the builder, and the registry password it sends, at a host somebody else
chose.

novox/hq 04-ISSUES/085

jschoubben merged commit 45425702d5 into main

2026-09-22 19:59:52 +00:00

jschoubben deleted branch feat/packages-port

2026-09-22 19:59:52 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-controller#45