Two defects the worldtree-pinned case exposed in the guard written an hour
ago.
1. The guard compared the container's .Config.Image STRING against the tag
being pinned. That string is only the tag the container was CREATED from,
which can differ from what it actually runs: worldtree-pinned was created
from `:latest` back when that tag pointed at 446e5807, and `:latest` has
since moved to b19afd71d7cc. So the guard refused an instance whose
pinning was correct and necessary. Now it resolves the target tag to an
image ID and compares that against the running image ID -- asserting the
thing actually cared about, that this tag names the bytes now running.
It also fails closed when no such local tag exists.
2. The sed step reported CHANGED unconditionally, so a re-run on an
already-pinned instance claimed work it had not done. Gated behind a
`when:` that skips when the line is already correct; a second run on demo
now reports "2 ok, 0 changed, 2 skipped / overall: OK".
Applied to worldtree-pinned under worldtree-dev authorization. That instance
needed a `docker tag` first -- its image was DANGLING (no repo tags, kept
alive only by the running container), so the fleet's frozen reference was one
`docker rm` from garbage collection. Tagged as :446e5807bf43, then pinned.
All three instances now render a SHA with no floating tag anywhere:
worldtree -> :ae88a057c0ed
worldtree-personal -> :f63529168c13
worldtree-pinned -> :446e5807bf43
Nothing restarted -- pinned still Up 3 months, its start time unchanged.
Both corviduo-dev Worldtree instances carried
`WORLDTREE_IMAGE=.../worldtree:latest` in their .env while running
SHA-tagged images built the same day. The local :latest tag pointed at
b19afd71d7cc, built 2026-06-14 -- 69 days stale. Any `docker compose up`
on either instance, by anyone, silently downgraded that service by 69
days: the same footgun behind the 2026-06-15 outage.
Applied under worldtree-dev authorization (Worldtree #410):
demo -> gitea.phasefinal.com/vh/worldtree:ae88a057c0ed
personal -> gitea.phasefinal.com/vh/worldtree:f63529168c13
Both runs verified compose config resolves every service to the pinned
SHA with no :latest remaining, and that no container restarted. The edit
is inert by design -- it changes what the NEXT recreate pulls.
The playbook guards against pinning a SHA that is not the one actually
running, which would re-arm the same hazard with a different image.
Also records the worldtree-pinned case, deliberately NOT changed here:
that instance runs a DANGLING image (sha256:446e5807, no repo tags),
kept alive only by the running container. It has no tag to pin to, so it
needs `docker tag` first -- and an untagged image referenced only by a
container is one `docker rm` from garbage collection, which for the
fleet's frozen reference instance is worth fixing on its own merits.
Out of the authorized scope (demo + personal); raised with worldtree-dev.
Stopgap: the durable fix is the deploy workflow stamping the deployed SHA
into .env at each deploy, queued repo-side with worldtree-dev.
vh