4 Commits

Include renames

Author	SHA1	Message	Date
mesh-tools	52600ec7bd	Take the node-engine's parser from mesh-sdk: remaining imports (issue 1392)	2026-10-20 11:17:14 +00:00
jschoubben	5dd439df50	inspect by kind, not the ambiguous bare form — a same-named network stops a container from ever being found ... docker inspect <name> resolves across every object kind, not just containers. A module regularly names a network the same as the container that joins it (keycloak does this today, ordinarily) — so when the container does not exist yet but the same-named network already does, the bare form answers with the network's JSON instead of reporting the container absent, and the template these callers use (.State.Running) fails to execute against it entirely. Live on novox tonight: minio's LB container, named the same as its network ("minio"), could never be created — every apply crashed on "the container runtime could not say whether minio is here", stuck since first push, because the check itself never got a clean answer. Fixed at every call site asking a container's state by name (containerState, inspectFound, NamesFree, raiseGiteaServer, containerRunning) by scoping to `docker container inspect`, matching the type-scoped form this codebase already uses correctly for networks, volumes and images elsewhere. Also scoped the one image inspect that was still bare (publish.go), for the same reason. mesh-host runs as a host-level service (nox-mesh-host.service), not a Docker module — merging this does not redeploy it. The live novox failure persists until the service itself is rebuilt and updated.	2026-09-24 19:50:16 +02:00
jschoubben	121367319d	Rename mesh-control -> mesh-controller, substrate -> foundation ... One name per thing, per the HQ glossary: the module/container/image/binary/repo becomes mesh-controller, the seat the-controller, and the store+broker pair the foundation (embedded base bundles, default template and example lock renamed with their go:embed directives). No behaviour change — a pure vocabulary rename. Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx	2026-09-16 18:40:40 +02:00
jschoubben	b82ab95f74	mesh-bootstrap: the first-node procedure, as a program rather than a test ... The only complete written-down copy of how a mesh is stood up was an integration test in the lab. That is why every bootstrap gap kept being found late: an install procedure that lives as a test fixture is exercised by whoever writes tests, never by whoever installs. This is that procedure. A separate binary, not a mesh-host subcommand. mesh-host says of itself that it connects to nothing and listens on nothing and that what it applies comes from a file, and that sentence is what makes an always-running root daemon auditable. An installer loads images and interrogates a control plane. Same tier, different program. The control plane's image is carried, not built and not fetched. The forge that holds its source runs on the mesh, so a bootstrap that had to fetch it would need a mesh in order to raise one. Embedding breaks that cycle the way the carried bundle breaks "copy it onto a machine and run it". The image id is read out of the saved tar before the runtime is asked anything, which is what makes the load idempotent: the installer can ask whether the machine already holds exactly this. Five steps, each idempotent and each saying whether it found or changed something, because this is run over and over by somebody getting a machine working. It stops at a running substrate with a control plane that replies — enrolment, the module catalogue and assignment are the next stage and are deliberately absent. Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF	2026-09-10 23:17:30 +02:00