@@ -0,0 +1,24 @@
+name: checks
+
+on:
+  pull_request:
+  push:
+    branches: [main]
+
+permissions:
+  contents: read
+
+jobs:
+  checks:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out repo
+        uses: actions/checkout@v5
+
+      - name: Forbidden syntax
+        run: bash scripts/forbidden-syntax.sh
+
+      - name: Shell syntax check
+        run: |
+          find examples/lgtm-datamesh/scripts examples/lgtm-datamesh/demos scripts \
+            -name '*.sh' -type f -print0 | xargs -0 -n1 bash -n
@@ -27,6 +27,9 @@ jobs:
       - name: Check out repo
         uses: actions/checkout@v5
 
+      - name: Forbidden syntax
+        run: bash scripts/forbidden-syntax.sh
+
       - name: Set up Ruby
         uses: ruby/setup-ruby@v1
         with:
 
@@ -10,3 +10,7 @@ Gemfile.lock
 # Node.js
 node_modules/
 package-lock.json
+
+# Python bytecode
+__pycache__/
+*.pyc
@@ -13,5 +13,5 @@ group :jekyll_plugins do
   gem "jekyll-seo-tag"  # provides {% seo %} — used in _layouts/default.html
 end
 
-# Windows and macOS sometimes need this explicitly
+# Local `jekyll serve` on Ruby 3+ needs webrick explicitly
 gem "webrick", "~> 1.8"
@@ -113,14 +113,14 @@ forks.
 - A reader who runs the example tree gets a working data mesh on their
   laptop: five services, contracts, catalog, canary, autoscaling,
   observability, all green within ~30 minutes of bootstrap on the
-  verified configuration.
+  target configuration.
 - A reader can demonstrate the cross-product behaviours that make a
   collection of services a *mesh*: a single GraphQL query producing a
   trace tree across three products, a contract canary shifting live
   traffic by weight without application code changes, a Kafka-lag
   scaler waking and quiescing an event consumer.
-- The runnable examples build and run end to end on a Fedora-on-rootless-podman
-  minikube setup with one bootstrap command. CAP-047 of the historical
+- The runnable examples build and run end to end on a Fedora 44 + Docker Engine + minikube
+  (docker driver, containerd) setup with one bootstrap command. CAP-047 of the historical
   decision log documents the one deferred component (the KEDA HTTP
   add-on's interceptor on the gateway scale-from-zero path) and the
   worked-around demo path that keeps the walkthrough 5-of-5 green.
@@ -147,11 +147,11 @@ forks.
   Snowflake vs. BigQuery vs. Databricks, dbt vs. SQLMesh, or warehouse
   shape. Those choices are downstream of the mesh; this reference stops
   at the boundary.
-- **Coverage of every Kubernetes runtime.** The verified configuration
+- **Coverage of every Kubernetes runtime.** The target configuration
   is minikube on Fedora 44. The reference is portable in principle to
   OpenShift (where the implementation deck pairs it explicitly), EKS,
   GKE, AKS, and vanilla K8s, but the bootstrap and chart values are
-  written for the verified runtime. Adapting to other runtimes is left
+  written for the target runtime. Adapting to other runtimes is left
   to readers as a known and welcome contribution path.
 - **Building a generic "data mesh framework."** This is a reference
   implementation, not a framework. There's no abstraction layer
@@ -263,7 +263,7 @@ diagrams that have changed.
 ### Verification metrics (project-controlled)
 
 - The presenter walkthrough runs 5-of-5 green on the verified runtime
-  (Fedora 44 + rootless podman + minikube), as documented in the
+  (Fedora 44 + Docker Engine + minikube (docker driver, containerd)), as documented in the
   reconciliation file at `_plans/reconciliation.md`.
 - All internal links resolve (`scripts/check-cross-references.sh` exits 0).
 - All `{{ }}` Liquid expressions in `_plans/*.md` are properly fenced
@@ -293,7 +293,7 @@ day-to-day decisions, but are useful as a long-range health check:
 - **Kubernetes is the substrate model.** Anything that contradicts
   upstream Kubernetes idioms (operators, CRDs, RBAC, service mesh) is
   out of scope.
-- **The verified runtime is minikube on Fedora 44 with rootless podman.**
+- **The verified runtime is Fedora 44 + Docker Engine + minikube (docker driver, containerd)** (2026-10-09, engine provided by Docker Desktop; see `_plans/reconciliation.md`).
   Other runtimes are documented as portable in principle; verifying
   them is a contribution path.
 - **Vendor-neutral language.** Where multiple tools could fit a slot
 
@@ -81,8 +81,8 @@ end to end, verified order-independent (see
 |---|---|---|
 | Services | Python 3.12, FastAPI, SQLAlchemy + Alembic, Poetry | Five domain services + GraphQL gateway; migrations via init-containers |
 | Protocols | REST (OpenAPI), gRPC (Protobuf/buf), GraphQL (SDL), Kafka (Avro) | The deliberate protocol mix: cross-product APIs, hot paths, read surface, async spine |
-| Packaging | Helm (umbrella chart + per-service subcharts), podman | One chart tree for the whole system; images built on the host, pushed to the in-cluster registry |
-| Substrate | Kubernetes v1.32 on minikube (rootless podman driver, containerd) | The whole system on one 24 GB profile |
+| Packaging | Helm (umbrella chart + per-service subcharts), Docker Engine | One chart tree for the whole system; images built on the host and loaded into the minikube node |
+| Substrate | Kubernetes v1.32 on minikube (Docker driver, containerd + runc) | The whole system on one 24 GB profile |
 | Database | CloudNativePG operator, PostgreSQL | One shared cluster, schema-per-service ownership |
 | Events | Strimzi operator, Apache Kafka | The asynchronous spine (`order-placed` topic) |
 | Contracts | Apicurio Registry | OpenAPI + Protobuf + GraphQL SDL (discovery) and Avro (runtime, Confluent-compatible API) |
@@ -130,9 +130,11 @@ cd examples/lgtm-datamesh
 ./demos/walkthrough.sh            # the five-act presenter walkthrough
 ```
 
-The verified configuration is Fedora with rootless podman, 64 GB RAM
+The verified configuration is Fedora 44 with Docker Engine, 64 GB RAM
 (24 GB for the minikube profile), and minikube ≥ 1.36.
 
+An optional OpenShift Local (CRC) appendix uses podman. <!-- forbidden-ok -->
+
 ## Origin
 
 This repo is a fork of the §17 capstone from
 
@@ -100,7 +100,17 @@ a laptop but also concentrates failure modes that a real multi-node cluster woul
 spread out. Where those single-node realities bite — resource ceilings, node-level
 decay, the operational care a long-lived single-node cluster needs — they're collected
 as operational gotchas rather than mixed into the conceptual material here, because
-they're particular to this deployment choice rather than to data mesh as a pattern.
+they're particular to this deployment choice rather than to data mesh as a pattern. The
+profile is a Docker container (the docker driver) running containerd with the runc
+runtime, sized by `MINIKUBE_MEMORY`, `MINIKUBE_CPUS` and `MINIKUBE_DISK`.
+
+Host access follows the same single-node logic. The capstone's UIs and service
+endpoints are NodePorts published on `127.0.0.1` when the minikube profile is created
+(`--ports=127.0.0.1:<hostPort>:<nodePort>`), never SSH tunnels or port-forwarding. <!-- forbidden-ok -->
+The ports are fixed at creation, so changing the set means recreating the profile with
+`./scripts/setup-capstone-profile.sh --replace`. `--replace` deletes and recreates the cluster, so run `./scripts/bootstrap-capstone.sh` again afterwards. Run the workshop in isolation: shut down
+CRC, other minikube profiles, and other workloads first, so the host ports are free.
+`./scripts/show-endpoints.sh` prints what is published and reachable.
 
 Next, the services themselves: what a data product looks like in this build, the
 order-service template the others follow, and how each one is packaged and shipped.
@@ -83,37 +83,29 @@ start rather than retrofitting it.
 ## The one part that fights back: getting images to the kubelet
 
 This is worth its own section because it's the single part of the capstone that
-reliably trips people up, and it's a direct consequence of a deliberate choice made
-back in §3: the capstone uses the **rootless-podman driver with the containerd
-runtime**, because that's the most realistic local mirror of how Kubernetes runs in
-production. The cost of that realism is that getting a locally-built image to the
-kubelet is not as simple as you'd expect.
-
-The intuitive approaches are unreliable on this driver. `minikube image build` can
-exit successfully without the image actually landing in the profile's containerd
-store, so the pod then fails to pull. `minikube image load` can report "image not
-found" for an image that's plainly present, because the lookup goes through the
-rootless podman socket in a way that doesn't resolve.
-
-The reliable answer the capstone standardizes on is **minikube's built-in registry
-addon**: build on the host with podman, push to the registry, and let deployments pull
-from it like any ordinary image. The one detail that catches everyone is that the
-registry has *two addresses*. With the podman driver the host-side port is not 5000 —
-minikube assigns one (something like `127.0.0.1:41685`) and tells you when you enable
-the addon — while *inside* the cluster the kubelet reaches the same registry at
-`localhost:5000`. So you **push** from the host to `127.0.0.1:<assigned-port>` and the
-cluster **pulls** from `localhost:5000`. The build script discovers the host port
-automatically; the charts pull from the in-cluster address.
-
-One environment variable makes or breaks all of this: `MINIKUBE_ROOTLESS=true`. If
-it's not set in your shell, minikube routes host operations through `sudo podman`,
-which can't see your rootless container — producing a spread of failures that look
-like a broken cluster but aren't. The capstone scripts both persist it and export it
-at the top of every script; if you run minikube commands by hand, export it first.
-
-None of this is unique to the capstone — it's inherent to the rootless driver — but
+reliably trips people up. The profile is a Docker container (the docker driver) running
+containerd, and that container has its own image store, separate from the Docker Engine
+on your host. An image you build locally is invisible to the kubelet until you put it
+there, and a pod that can't find its image fails in ways that look like a broken
+cluster.
+
+The capstone's answer is deliberately simple: **build with Docker Engine, then load the
+image into the profile with `minikube image load`**. There is no registry to run and no
+addresses to reconcile, and it works the same on a native engine and on a VM-based one
+(Docker Desktop, for example). That portability is the reason for the choice:
+pushing to a registry on the host's loopback only works when the engine's daemon shares
+the host's network, which a VM-based engine's does not.
+
+Images are tagged `capstone/<svc>:v1` and the charts set `imagePullPolicy: Never`. The
+policy matters in both directions. If an image was never loaded, the pod fails at once
+with `ErrImageNeverPull` instead of quietly trying Docker Hub for a name that exists
+nowhere. And because `:v1` is a mutable tag, a rebuild does not change what running pods
+use, so `scripts/build-image.sh` restarts the Deployments that use the image it just
+loaded.
+
+None of this is unique to the capstone — any local cluster has some version of the gap between the host's images and the node's — but
 the capstone is where it bites, because it's the first place you build and deploy your
-*own* images at scale. Get the registry workflow right once here, and every service
+*own* images at scale. Get the image workflow right once here, and every service
 afterward is the same three commands. (The deeper operational sharp edges of running
 all this on a single node are collected as gotchas, separate from this build-level
 friction.)
 
@@ -37,8 +37,8 @@ A couple of honest simplifications worth naming. v1 and v2 here run the *same im
 with an environment toggle and a different `version` label, rather than two images from
 two commits — that keeps the demo focused on the traffic-management mechanism rather
 than an image pipeline, and the Istio mechanics are identical either way. And traffic
-enters through the ingress gateway (reached over an SSH tunnel to its NodePort, under
-the rootless-podman setup from §11) rather than from a meshed client, so no client needs
+enters through the ingress gateway (reached on its NodePort, published to
+127.0.0.1:8088 when the profile is created, DRA-017) rather than from a meshed client, so no client needs
 to join the mesh for the canary to work.
 
 This was verified end to end: with the split set to 90/10, a run of 100 requests landed
 
@@ -7,7 +7,7 @@ duration: 40 min
 
 [Chapter 3]({{ '/docs/02-kubernetes-substrate/' | relative_url }}) built the case for
 Kubernetes as the mesh's substrate and brought the capstone up on minikube via Helm —
-NodePorts, a stable SSH tunnel, a local image registry. That's a real deployment, and
+NodePorts published to loopback, a local image registry. That's a real deployment, and
 everything in the reading set up to the [summary]({{ '/docs/10-summary/' | relative_url }})
 assumes it. But "deploy it to Kubernetes" and "deploy it to OpenShift" are not the same
 sentence. OpenShift adds opinions on top of plain Kubernetes — Security Context
@@ -45,6 +45,8 @@ documenting the OpenShift-native counterpart.
 You don't need a paid subscription or a cloud account. **OpenShift Local** (CRC —
 "CodeReady Containers") runs a real, single-node OpenShift cluster in a local VM.
 
+This appendix uses podman (and `oc`) on the host to build and push to the integrated registry; the minikube path uses Docker Engine. Podman is needed only here. <!-- forbidden-ok -->
+
 1. **Create a free Red Hat Developer account.** Go to
    [developers.redhat.com](https://developers.redhat.com), register or log in. It's free
    and gives you access to OpenShift Local and the pull secret.
@@ -168,12 +170,13 @@ datamesh-infra`, which is worth knowing when debugging a pod stuck in
 `CreateContainerConfigError` with an SCC-related event — it's the same RoleBinding under
 the hood.
 
-### 2. Routes, not port-forward/NodePort
+### 2. Routes, not published NodePorts
 
 The minikube path this capstone uses elsewhere in the reading set exposes services via
-NodePort, reached over a stable SSH tunnel because minikube has no cluster-native router.
-OpenShift has one built in: a `Route` object hands a Service a real external hostname,
-served by the cluster's router, with no tunnel to keep alive. The chart defines two —
+NodePorts published to `127.0.0.1` when the profile is created, because minikube has no
+cluster-native router. OpenShift has one built in: a `Route` object hands a Service a
+real external hostname, served by the cluster's router, with nothing to publish on the
+host. The chart defines two —
 `templates/route.yaml` ranges over the same `services:` map and emits a Route for any
 service with `route: true` set (currently just `graphql-gateway`), and `apicurio.yaml`
 wires its own Route directly since Apicurio isn't part of that map: