What changed: dockerfiles/dockerfile-samgis-base — builder_global stage repinned from dhi.io/python:3.13-dev to the exact same digest as the runtime stage (dhi.io/python:3.13@sha256:a87c4bc7bbf75da7d5bb1816f2bdf7640c17eeb42d3ba84c5201827977da8de4); its 3 shell-form RUN instructions converted to exec-form JSON arrays (using paths relative to WORKDIR rather than ${WORKDIR_ROOT} substitution); final stage's COPY --from=builder_global model-weights source path updated from /root/.samgis/... to /home/nonroot/.samgis/....
Follow-up action: when adding or modifying a multi-stage Dockerfile that builds artifacts (venvs, compiled binaries, anything with baked-in absolute paths) in one DHI (Docker Hardened Images) variant and copies them into another, first verify the two variants share the same Python/interpreter install location: docker run --rm --network none <image> python3 -c "import sys; print(sys.executable, sys.prefix)" for both. Only rely on cross-stage COPY of such artifacts if the paths match exactly.
Do NOT: assume dhi.io/<lang>:<version>-dev and dhi.io/<lang>:<version> (hardened, non-dev) are portability-compatible just because they're the same version or even the same release epoch (same docker scout provenance commit). Confirmed on 2026-07-25: python:3.13-dev installs Python at /usr (/usr/bin/python3), the hardened python:3.13 installs it at /opt/python (/opt/python/bin/python3) — these are structurally different images, not just build-tools-vs-not.
Trigger: any time a build using a DHI -dev builder stage + hardened runtime stage starts failing with ModuleNotFoundError (or similar "the code that should be there isn't") in a runtime-stage smoke test, immediately after a base-image or Dockerfile change — check for this class of bug before assuming a dependency-resolution problem. Symptom signature: the missing package genuinely was installed successfully in the builder stage logs, but the runtime stage can't see it.
Why: a copied venv's bin/python3 is a symlink baked with the builder's absolute interpreter path at creation time. If that path doesn't exist in the runtime image, PATH resolution silently falls through to the runtime's own separate interpreter — a real, working Python that has simply never heard of anything in the venv. No error is raised for the broken symlink itself; the failure surfaces several steps later as a missing-module error on whatever import happens to run first. Additionally, the hardened runtime variant defaults to a nonroot user (uid 65532, HOME=/home/nonroot) rather than root, which independently breaks any ~-relative path assumptions carried over from a builder stage that ran as root.
Verify: docker buildx build . -f dockerfiles/dockerfile-samgis-base ... completes through the runtime 7/7 smoke-test RUN step (import rasterio; import onnxruntime; import fastapi; import uvicorn) without error, and the final stage's model-weights COPY --from=builder_global step finds its source path.
Rollback: revert builder_global's FROM line back to dhi.io/python:3.13-dev and its RUN/COPY instructions to their prior shell-form/paths — but this reintroduces the original bug; only do this if the pinned digest approach itself needs to be superseded by a different fix.