diff --git a/RELEASING.md b/RELEASING.md
index 4b4587d..be3fbef 100644
--- a/RELEASING.md
+++ b/RELEASING.md
@@ -71,12 +71,30 @@ git push
 git push origin v1.1
 ```
 
-**The tag must keep the `v` prefix.** F-Droid's `checkupdates` takes the tag name
-verbatim as the commit to build, so `v1.1` here means `commit: v1.1` in their
-metadata. A tag named `1.1` would break the automation.
+Keep tags in the `v1.1` shape for consistency, but nothing depends on it:
+`UpdateCheckMode: Tags` with no pattern matches every tag whatever it's called,
+and F-Droid's bot resolves whichever tag it finds to a commit hash before it
+writes the build entry.
 
 Never move or delete a tag that has been pushed — F-Droid may already have built
-it. If a release is wrong, bump the version and release again.
+it. If a release is wrong, bump the version and release again. (The recipe pins
+a hash, so a moved tag can't retroactively change a version they already built;
+it would just leave your repo disagreeing with what's on people's phones.)
+
+**If you ever write a build entry by hand**, its `commit:` must be a full 40-char
+commit hash — never a tag, never a branch. Tags are mutable, so a tag there means
+the thing F-Droid builds and signs can change under them, and they reject it on
+sight. This came up on the very first submission and is easy to get wrong,
+because `fdroid lint` doesn't check it under `UpdateCheckMode: Tags` — the
+pipeline goes green and a human catches it days later. Get the hash with:
+
+```bash
+git rev-parse v1.1^{commit}      # ^{commit}, or an annotated tag gives you the
+                                 # tag object's hash instead of the commit's
+```
+
+This doesn't come up in a normal release: the bot writes the entry, and the bot
+writes hashes.
 
 ## 6. Wait