diff --git a/.woodpecker.yaml b/.woodpecker.yaml
index b1b3630..ccc6cca 100644
--- a/.woodpecker.yaml
+++ b/.woodpecker.yaml
@@ -58,9 +58,13 @@ steps:
   # from the Mac that can sign them.
   - name: release
     image: alpine
-    # No secret: the step authenticates with the forge credential Woodpecker already
-    # hands every step, which belongs to the repository's owner. To publish as someone
-    # else instead, add a `gitea_token` repository secret and map it here as GITEA_TOKEN.
+    environment:
+      # Needed. Woodpecker does hand steps a forge credential — a manual build printed
+      # one — but a build started by the tag webhook does not get it: the first tag build
+      # died here with no credential at all. So the token is a repository secret, and the
+      # script still falls back to the forge credential when it is there.
+      GITEA_TOKEN:
+        from_secret: gitea_token
     commands:
       - apk add --no-cache curl jq
       # No globs on the command line: the package names have spaces in them.
diff --git a/README.md b/README.md
index dc3f97a..08c25e2 100644
--- a/README.md
+++ b/README.md
@@ -204,11 +204,20 @@ So the whole of a release is:
 
 The window test is local as well: it needs a display and a store on the machine.
 
-The `release` step needs **no secret**. It authenticates with the forge credential
-Woodpecker hands every step for cloning, which is an access token of the repository's
-owner; Gitea takes it as `token …` or `Bearer …` depending on how Woodpecker was set up,
-so `scripts/ci-upload.sh` probes which of the two works instead of assuming. To publish
-as somebody else, add a `gitea_token` repository secret and map it into the step.
+The `release` step needs a **`gitea_token`** repository secret — a Gitea token with
+write access to this repository:
+
+```sh
+woodpecker-cli repo secret add --repository stores/warp-engine-client \
+  --name gitea_token --value <token> --event tag
+```
+
+Woodpecker does hand steps a forge credential of its own, and the script uses it when the
+secret is absent, but that is not something to rely on: a **manual** build has it and a
+build started by the **tag webhook** does not, which is how the first tag build failed —
+after building all four packages. Gitea takes either credential as `token …` or
+`Bearer …` depending on how it was issued, so the script probes which of the two `/user`
+accepts instead of assuming, and logs which one it used.
 
 There are two publishers on purpose: `scripts/release.sh` drives `tea`, which is logged
 in on a workstation, and `scripts/ci-upload.sh` speaks the API with whatever credential
diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES.md
index 63e5b26..09d5139 100644
--- a/RELEASE_NOTES.md
+++ b/RELEASE_NOTES.md
@@ -62,8 +62,7 @@ A `vX.Y.Z` tag now starts the pipeline, which builds the AppImage, the deb, the
 installer and the portable exe — Windows through Wine — **creates this release** and
 attaches all four. macOS stays a local build, because Apple's toolchain and its signing
 exist only on a Mac, so `make release` from a Mac pushes that package onto the same
-release afterwards. No secret is involved: the pipeline publishes with the forge
-credential Woodpecker already gives every step.
+release afterwards. Publishing uses a `gitea_token` repository secret in Woodpecker.
 
 The Windows installer is not signed: Windows will warn about an unknown publisher until
 there is a certificate.