diff --git a/Dockerfile b/Dockerfile
index 1146815..38fdf47 100755
--- a/Dockerfile
+++ b/Dockerfile
@@ -10,18 +10,19 @@ WORKDIR /app/backend
 COPY backend/package.json ./
 RUN npm install
 COPY backend/ ./
-# Only this stage ever sees .git, and the final image below copies just `dist`,
-# so no repository history reaches the deployed container. The build reads the
-# commit out of it directly rather than shelling out to git, because this base
-# image has no git binary and adding an apt layer so the image can print seven
-# characters is a poor trade. See #233.
+# There is deliberately no `COPY .git` here. It was tried in #233 and broke
+# every Portainer deploy with `"/.git": not found` — Portainer's build context
+# does not contain the repository history, whatever a local `docker build`
+# suggests. That was the version stamp becoming the thing that stopped a
+# deploy, which is the one outcome it must never be (#235).
 #
-# There is no .dockerignore, so .git is in the build context here and in
-# Portainer, which clones the repository before building.
-COPY .git ./.git
-# writeBuildInfo runs against the compiled output, so it has to follow tsc. It
-# warns rather than fails when .git is unreadable: a deploy must never be
-# stopped by the thing whose only job is to say which deploy it is.
+# The consequence is that `commit` reads "unknown" in any environment Portainer
+# builds. `builtAt` is still real, and is the half that matters most here:
+# Portainer already reports which commit it cloned, but it cannot tell you
+# whether the running container is actually that build. A build time can.
+#
+# writeBuildInfo runs against the compiled output, so it has to follow tsc, and
+# it warns rather than fails when it finds no .git.
 RUN npm run build && node dist/writeBuildInfo.js
 
 FROM node:20-bookworm-slim