[Serraniel]

Follow-up to your review point on #331 — which you merged before this landed, hence a separate PR.

You said hardcoded versions go stale every release. They do. In docs/deployment.md they were also the wrong value by construction, which is the more interesting half.

The actual bug

The three commands under Checking what you pulled verify the image you deployed. With a literal tag printed on the page, somebody running 0.4.1 who copies:

cosign verify ghcr.io/serraniel/sendan:0.3.3 ...

…verifies 0.3.3 — and it passes, because 0.3.3 is a genuinely signed image. They get a green check for an image they are not running.

A verification step that answers a different question than the one asked, affirmatively, is worse than one that is merely out of date. The version there was never going to be right, at any point in time, for anyone who hadn't just deployed that exact release.

The fix: read the tag off the deployment

# started with compose.yaml, where the container is sendan-sendan-1
IMAGE=$(docker inspect --format '{{ .Config.Image }}' "$(docker compose ps -q sendan)")

# started with a bare `docker run --name sendan`
IMAGE=$(docker inspect --format '{{ .Config.Image }}' sendan)

Two forms because compose.yaml sets name: sendan and the service is also sendan, so the container is sendan-sendan-1 — the single-argument form fails on the primary documented deployment path. I caught that by running it rather than by reading the file, and both forms are verified against a real container:

$ docker compose ps -a --format '{{.Name}}'
sendan-sendan-1
$ docker inspect --format '{{ .Config.Image }}' "$(docker compose ps -q sendan)"
ghcr.io/serraniel/sendan:0.3.3

Everywhere else, sorted by what the reference is for

Reference	Treatment	Why
README docker run	:latest	it is explicitly a local trial, and the next sentence already says to pin a tested release for a deployment. The snippet and the advice no longer contradict each other
SECURITY.md reproduce procedures ×2	placeholder	which release to reproduce was never ours to choose
compose.yaml comment, README pinning note	keeps a version	it is an example of the form — :0.3.3, never :v0.3.3. The number is incidental and the warning holds whatever it is
sendan verify sample output	left alone	see below

The one place I deliberately did nothing

Sample output. README's block is presented as a transcript against the live demo and the text invites you to run it, so real values belong there. SECURITY.md's equivalent stays illustrative with the fake commit (1a2b3c4) it already carried.

Staleness there is cosmetic: a reader seeing 35 of 35 where the page shows 33 of 33 learns nothing wrong, because the ✓ line is the verdict and the version is labelled as the instance's claim. Not worth a mechanism.

If you do want the remaining numbers kept current automatically, release-please supports extra-files — but the annotation it needs (<!-- x-release-please-version -->) renders literally inside a fenced code block, so it would pollute every snippet it touched. A small scripts/check-doc-versions.sh in the house style of check-toolchains.sh would fit much better. Say the word and I'll write it; I did not want to add a gate you had not asked for.

🤖 Generated with Claude Code