The catalogue builds its own runtime, and postgres serves its tools

Both modules keep their tools in an entrypoint of their own, so an image that
named only the consumer would serve none of them.

modules/mesh-catalog/Dockerfile

@@ -0,0 +1,28 @@
+# mesh-catalog's runtime: the tool runtime, carrying the catalogue's compiled graph, its consumer
+# of what the builder announces, and its tools.
+#
+# **Built from this module's own directory and nothing else.** The sdk is in the base image, so
+# nothing is copied out of a neighbouring checkout — which is what lets the mesh build this from a
+# repository and a path (novox/hq ADR 0069) rather than only on a workstation with the siblings.
+#
+# The base is named by ARG so it can be pinned to a digest the mesh's registry assigned. A tag would
+# make this runtime's contents depend on what somebody last pushed under that name.
+ARG RUNTIME_BASE=127.0.0.1:5000/mesh-tool-runtime@sha256:d4d793c828a5f563fdd8f49e5c6026d17b308a3f7a13c589849188362e4c7415
+
+FROM ${RUNTIME_BASE} AS build
+# Compiled under /app/modules so `@novox/mesh-sdk` resolves upward into the base's own
+# node_modules — the module is compiled against exactly the sdk it will run against.
+WORKDIR /app/modules/mesh-catalog
+COPY . .
+# The compiler is invoked by its real path rather than through node_modules/.bin, whose entries are
+# symlinks to a launcher that requires its library relatively — resolved away when the base image
+# was assembled.
+RUN node /app/node_modules/typescript/bin/tsc pg.d.ts store.ts index.ts tools/index.ts \
+      --module NodeNext --moduleResolution NodeNext --target ES2022 --outDir dist
+
+FROM ${RUNTIME_BASE}
+COPY --from=build /app/modules/mesh-catalog/dist /app/modules/mesh-catalog/dist
+# What a tool host should load: the catalogue's tools. Its consumer of `module.builder.built` is the
+# other entrypoint, and is what this module's own container runs — named in the declaration's `args`
+# rather than here, because which one runs is the declaration's business.
+ENV MESH_TOOL_MODULES=/app/modules/mesh-catalog/dist/tools/index.js

modules/mesh-catalog/module.json

@@ -60,7 +60,6 @@
       "id": "runtime",
       "type": "container",
       "name": "mesh-catalog",
-      "image": "mesh-runtime-mesh-catalog@sha256:0000000000000000000000000000000000000000000000000000000000000000",
       "network": "host",
       "volumes": [
         "/var/lib/mesh/mesh-catalog/broker:/run/secrets/broker:ro",
@@ -71,7 +70,21 @@
       },
       "env-file": [
         "/var/lib/mesh-catalog/db.env"
+      ],
+      "artifact": "runtime",
+      "args": [
+        "run",
+        "/app/modules/mesh-catalog/dist/index.js"
       ]
     }
-  ]
+  ],
+  "build": {
+    "artifacts": [
+      {
+        "name": "runtime",
+        "kind": "image",
+        "from": "Dockerfile"
+      }
+    ]
+  }
 }

modules/postgres/Dockerfile

@@ -23,6 +23,8 @@ RUN node /app/node_modules/typescript/bin/tsc client.ts index.ts provisioner/ind
 
 FROM ${RUNTIME_BASE}
 COPY --from=build /app/modules/postgres/dist /app/modules/postgres/dist
-# Which of the three the container runs is the declaration's business, said in its `args` — one
-# image, because they are one module and share a client.
-ENV MESH_TOOL_MODULES=/app/modules/postgres/dist/index.js
+# What a tool host should load from this module: its event consumer and its tools, which are
+# separate entrypoints because they are loaded by different things. The provisioner is the third,
+# and is not listed here — the declaration names it in the container's `args`, because it is what
+# this module's own container runs. One image, because they are one module and share a client.
+ENV MESH_TOOL_MODULES=/app/modules/postgres/dist/index.js,/app/modules/postgres/dist/tools/index.js