docs: auto rollbacks, bare image as latest and registry request scope (#9)

README.md

@@ -129,9 +129,12 @@ multi-arch image the digest is the index digest, the same one `docker inspect` s
 
 - **What counts as new.** A digest different from the one the service runs becomes the
   service's *available* version (the overview badge, source `poll`). A digest the master
-  already suggested is not suggested again. A service in **auto** mode also gets an update
-  job to `repo:tag` (the agent resolves the digest itself, so agents on protocol version 2 keep
-  working). A failed auto job is not retried every interval.
+  already suggested is not suggested again. A service in **auto** mode also gets one update
+  job to `repo:tag` per digest (the agent resolves the digest itself, so agents on protocol
+  version 2 keep working); the master remembers that digest in `services.last_auto_digest`
+  and does not start another job for it, whether the job failed or the user rolled back
+  afterwards. If the service already had a job when the digest was found, the next cycle
+  tries again.
 - **What is not polled.** Services that follow no tag (`repo@digest`), `build:` services, and
   services without a registry digest (locally built images). The service page says which.
   The updater's own services and plain containers are polled, so their badge works, but
@@ -146,25 +149,35 @@ multi-arch image the digest is the index digest, the same one `docker inspect` s
   in $PATH`, because the container has no credential helper binaries. The master logs
   `registry_credentials` at startup with the directory and whether `config.json` exists,
   never its contents.
+- **Requests go wherever the image name points.** The master sends the lookup to the
+  registry host in the image name, including a `GET /v2/` ping that follows redirects.
+  Anyone who can start containers on a managed host can therefore make the master send
+  blind requests to internal hosts. The registry's answer is not shown: an error keeps only
+  the HTTP status and the registry's error codes.
 
 ### Version history and rollback
 
 The master records every version it sees (webhook, polling, and what agents report as
 running) in `image_versions`. The service page lists the 10 most recently first seen
 versions of the service's image repo, marks the one that is running, and has a *Deploy*
-button on each row. A webhook announces a tag but not its digest, so such a row has no digest until polling or an
-agent reports one; it is hidden once a row with the same tag and a digest exists.
+button on each row. A webhook announces a tag but not its digest, so such a row has no
+digest until polling or an agent reports one; it is hidden when a row with the same tag
+and a digest was first seen at or after it. A bare image (`postgres`) is recorded as tag
+`latest`.
 
 Picking a version starts a manual job to exactly that reference. Picking an older one is a
-rollback, including to a digest-pinned reference. A version without a tag deploys `repo@digest` and the
-service then follows no tag, so it is no longer polled or updatable with the plain *Update* button until
-it is moved to a tagged version again. Picks of digest-pinned or tagless versions need an agent speaking protocol
-version 3 (this release); older agents get a failed job "agent too old for updates".
+rollback, including to a digest-pinned reference. A version without a tag deploys
+`repo@digest` and the service then follows no tag, so it is no longer polled or updatable
+with the plain *Update* button until it is moved to a tagged version again. Picks of
+digest-pinned or tagless versions need an agent speaking protocol version 3 (this
+release); on an older agent the job fails with "agent too old to deploy a pinned version
+(needs protocol 3)".
 
-On a service in **auto** mode a rollback is only a warning in the UI: the service stays auto and
-is moved forward again at the next new version, announced by the webhook or found by polling.
-Rolling back to an older digest of the tag the service follows keeps the newer version marked as
-available.
+A service in **auto** mode stays auto after a rollback. Polling does not undo the rollback:
+it started at most one job per digest, so the service stays on the older version until a
+new digest of the followed tag appears. The newer version it was rolled back from stays
+marked as available. A webhook that names a tag still starts a job for an auto service
+every time, so a CI push moves it forward again.
 
 ## Adding agents