docs: point app authors at the release template that signs outside the build

CONTRIBUTING.md

@@ -46,9 +46,9 @@ You can upload any subset — Colony only advertises the platforms whose asset i
 
 ### Step 3 — Wire up a release workflow (Rust apps)
 
-The ready-to-use GitHub Actions template lives in Project-Colony-Resources at [`templates/release.yml`](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/release.yml), next to the shared signing script it calls. Copy it to your own repo as `.github/workflows/release.yml` and replace `{{APP_NAME}}` with your binary/repo name (lowercase).
+The ready-to-use GitHub Actions template lives in Project-Colony-Resources at [`templates/sign-and-publish-caller.yml`](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/sign-and-publish-caller.yml). Copy it to your own repo as `.github/workflows/release.yml` and replace `{{APP_NAME}}` with your binary/repo name (lowercase). Its build jobs never see a signing key: signing and publishing happen in the organisation's [shared signing workflow](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/design/releases.md#shared-signing-workflow), which the template calls.
 
-It uses [`release-please`](https://github.com/googleapis/release-please) so every merged PR tagged with a conventional-commit prefix (`feat:`, `fix:`, etc.) opens a release PR; merging that PR tags the version, builds the matrix of 4 platforms, and uploads the assets under the convention above. Zero manual release work afterwards.
+It uses [`release-please`](https://github.com/googleapis/release-please) so every merged PR tagged with a conventional-commit prefix (`feat:`, `fix:`, etc.) opens a release PR; merging that PR tags the version, builds the matrix of 4 platforms, then signs and publishes the assets under the convention above. Zero manual release work afterwards.
 
 Non-Rust apps: replicate the same asset naming convention with whatever tooling you prefer (electron-builder, pyinstaller, go build, etc.).
 

README.md

@@ -111,7 +111,7 @@ Then publish a GitHub Release with assets named `yourapp-linux`, `yourapp-window
 
 **Full walkthrough**: see [CONTRIBUTING.md § Adding your app to Colony](CONTRIBUTING.md#adding-your-app-to-colony).
 
-The canonical [release workflow template](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/release.yml) lives in Project-Colony-Resources, alongside the shared signing script and the manifest schema.
+The canonical [release workflow template](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/sign-and-publish-caller.yml) lives in Project-Colony-Resources, alongside the shared signing workflow it calls and the manifest schema.
 
 ## Platforms
 

docs/colony-spec.md

@@ -224,17 +224,12 @@ signing is adopted per-app, no flag day - **unless** the manifest declares:
 With `"signed": true`, a missing signature ABORTS the install. Declare it once
 every release of the app ships `.sig` assets. Not every Project-Colony app
 signs its releases yet, so check an app's release assets rather than assuming.
-Sign with:
-
-```sh
-COLONY_SIGNING_KEY=/path/to/colony-release.pem \
-COLONY_RELEASE_VERSION=<tag> ./scripts/sign-release.sh <asset>
-```
-
-`COLONY_RELEASE_VERSION` is required because the script also emits a signed
-`<asset>.meta` sidecar binding the bytes to a version and a filename. The
-launcher's self-update requires it, and app installs check it whenever it is
-published (see below).
+An app signs nothing itself: its release workflow, copied from the
+[release workflow template](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/sign-and-publish-caller.yml),
+hands the built binaries to the organisation's shared signing workflow. That
+workflow writes `<asset>.sig` and a signed `<asset>.meta` sidecar binding the
+bytes to a version and a filename. The launcher's self-update requires the
+sidecar, and app installs check it whenever it is published (see below).
 
 Note the trust boundary. Signatures protect against tampered release assets
 (e.g. an asset swapped after publication), because forging one requires the
@@ -274,5 +269,6 @@ colony validate-manifest colony.json $(tr '\n' ' ' < names.txt)
 ```
 
 It exits non-zero on any problem, so it works as a CI gate. The shipped
-[release workflow template](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/release.yml)
-already runs it against each release before signing.
+[release workflow template](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/sign-and-publish-caller.yml)
+already runs it on every release, in its Linux build job, before anything is
+signed.

docs/docs.md

@@ -16,4 +16,4 @@ This folder contains the technical and end-user documentation for Colony.
 
 - [Project-Colony GitHub organization](https://github.com/Project-Colony)
 - [Contributing guide](../CONTRIBUTING.md) — adding your app + contributing to Colony itself
-- [Release workflow template](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/release.yml) and the shared signing script, in Project-Colony-Resources
+- [Release workflow template](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/sign-and-publish-caller.yml) and the shared signing workflow it calls, in Project-Colony-Resources