docs(ci-testing): hadolint floating-latest policy — fix surfaced findings, never pin

Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>

Author: CybotTM

skills/docker-development/references/ci-testing.md

@@ -178,3 +178,30 @@ When smoke/boot-testing an image by hand (not in the CI matrix):
 - **Foreground apps that log to a file leave `docker logs` empty.** E.g. Tomcat started with `-fg` writes to `logs/catalina.out`, not stdout — an empty `docker logs` does *not* mean "nothing happened". Read the in-container log files (`docker exec <c> sh -c 'tail -n 80 .../catalina.out'`), and check the process and state (`docker inspect -f '{{.State.Status}} {{.State.ExitCode}}' <c>`).
 - **Minimal/distroless images have no shell.** `docker exec … sh`/`tail`/`pgrep` won't exist on `scratch`/distroless runtimes — probe with host-side `curl` against a published port, `docker inspect` for state, or a debug sidecar (`docker run --rm --pid container:<c> busybox …`).
 - **Grep for real failure signals, not benign noise.** After a bundled-dependency swap, scan logs for `NoSuchMethodError|AbstractMethodError|LinkageError|IncompatibleClassChangeError` (binary incompatibility) — not bare `ClassNotFoundException`, which OSGi/plugin frameworks emit normally.
+
+## hadolint in CI: floating `latest` is a feature — fix findings, don't pin
+
+CI lint jobs typically run `hadolint/hadolint:latest-alpine`. A hadolint
+release can turn a previously-quiet rule into a failure overnight, so an
+unrelated MR (a Renovate version bump, a docs change) suddenly goes red.
+
+Diagnose before blaming the diff: if the default branch's last green run
+predates the failure and re-running it fails identically, the linter moved,
+not your change.
+
+Policy: treat the new finding as surfaced debt and fix it in the same MR —
+do not pin the hadolint image and do not add an ignore. Pinning hides every
+future rule improvement; the debt only grows.
+
+Concrete case (2026-08-13, `docker/node-red`): a hadolint update started
+failing `DL3066` (non-numeric user-id) on `USER root` / `USER node-red`.
+Fix: use the numeric ids the image already establishes —
+
+```dockerfile
+USER 0
+RUN apk add --no-cache shadow && usermod -u 10458 node-red && apk del shadow
+USER 10458
+```
+
+No behavior change, and the id survives environments that cannot resolve
+container-internal user names.