README.md

@@ -99,8 +99,10 @@ Then open `http://<host>:5000` and register — **the first account becomes the
   unset, a signing key is generated and persisted in the database (sessions survive restarts).
 - Uploaded images live under the `thoughtsync-data` volume at `/var/thoughtsync`.
 - The app waits for the database and runs migrations (`alembic upgrade head`) automatically on start.
-- **Image tags:** `:latest` (stable, built from `main`) · `:dev` (latest `dev` build) ·
-  `:<git-sha>` (immutable, for pinning / rollback).
+- **Image tags:** `:latest` (stable, built from `main`) · `:dev` (latest `dev`
+  build) · `:<git-sha>` on `main` only (immutable, the rollback unit). There are
+  no version-shaped tags: nothing pins one, and the build reports its own version
+  at `/api/config` and `/health`.
 - **Putting it on the public internet:** there are four things to do first — close
   registration, terminate TLS and forward `X-Forwarded-Proto`, stop publishing the app
   port, and back up the attachment volume as well as the database. See

docs/android-distribution.md

@@ -15,13 +15,19 @@ cannot talk to.
 
 **Normally: nowhere. It is already in the image.**
 
-CI fetches the newest published Android build into every server image it builds,
-so `:dev`, `:latest` and `:<version>` all ship a client. `docker compose pull &&
-docker compose up -d` delivers a new server and a new client together, and there
-is nothing to copy.
+CI fetches the published Android build into every server image it builds, so
+`:dev` and `:latest` both ship a client. `docker compose pull && docker compose
+up -d` delivers a new server and a new client together, and there is nothing to
+copy.
 
-A versioned image therefore carries the *newest* client rather than one pinned to
-that version. That is deliberate: the two negotiate a sync protocol version
+**The channel is a property of the image you run.** A `:dev` image bakes in the
+dev-channel APK, `:latest` the stable one — so pointing a phone at a stable
+server gets it a stable client, with no second place holding that decision. (Until
+M314 step 3 the fetch was hard-wired to the dev release on every branch, so a
+stable server served a dev client.)
+
+An image therefore carries the *newest* client on its channel rather than one
+pinned to a version. That is deliberate: the two negotiate a sync protocol version
 before they link, so a mismatch is caught by the handshake rather than by
 pinning.