docs: spell out the upgrade risk and the bare-image rule (#7)

README.md

@@ -18,7 +18,9 @@ Clicking *Update* on a service re-pulls the service's **current tag** (`repo:tag
 agent asks its Docker daemon for the tag's digest and deploys `repo:tag@digest`, so what
 runs is exactly what was pulled. The log streams to the browser while it runs; job
 history is kept in Postgres. A service without a tag (`repo@digest`), a plain container,
-and the updater's own services cannot be updated, and the UI says why. One update at a
+and the updater's own services cannot be updated, and the UI says why. A bare image
+(`image: postgres`, no tag and no digest) counts as `postgres:latest`; only a reference
+with a digest and no tag (`repo@sha256:...`) "follows no tag". One update at a
 time per service, and one job at a time per agent.
 
 ## Deploying the master
@@ -103,7 +105,13 @@ on a manager, or point `DOCKER_HOST` at one).
 
 This release removes `cmd/server` and changes the image's default entrypoint to
 `updater-agent`. A running old-style updater (default entrypoint, `UPDATER_API_KEY`) will
-crash-loop the next time its image is pulled. Pin it to the last pre-phase-2 tag first.
+crash-loop the next time its image is pulled. Anything that pulls `:latest` for the old
+instance triggers this: its own `/update` webhook, Watchtower or Shepherd.
+
+Pinning means two things: pin the old instance to the last pre-phase-2 tag **and** remove
+its `se.shcizo.auto-update` label, so nothing updates it to the new image. Or do not tag a
+release until phase 3 moves `POST /update` to the master.
+
 Master and agents must be on this release together: a phase-1 agent connects but every
 job sent to it fails "agent too old for updates".