Consolidate Woodpecker delivery templates

docs/consumers/delivery.md

@@ -148,31 +148,41 @@ exit codes, and transport behavior.
 
 ## Woodpecker tag workflows
 
-Maintained workflow examples are available for source-only and binary delivery:
+Use the maintained [tag-delivery workflow](../../examples/woodpecker/tag-delivery.yml)
+in the consumer repository's `.woodpecker/` directory. Set `GO_IMAGE` to an
+image with Go 1.25 or newer, Git, and a Go version compatible with the consumer
+module. Replace `RELEASEKIT_VERSION` with an immutable ReleaseKit revision or
+published version. The example deliberately leaves this deployment pin as a
+placeholder. Configure the Woodpecker repository secret
+`releasekit_gitea_token`; the template maps it to `RELEASEKIT_GITEA_TOKEN` only
+for the delivery step. The repository needs a `delivery` profile. Page-only and
+binary behavior both use this template; the profile's build target list selects
+whether binaries are built and delivered.
 
-- [Source-only tag workflow](../../examples/woodpecker/tag-delivery-source-only.yml)
-- [Binary tag workflow](../../examples/woodpecker/tag-delivery-binary.yml)
+The command runs versioned source directly with `go run`, passing
+`CI_WORKSPACE`, `CI_COMMIT_SHA`, and `CI_COMMIT_TAG` as command arguments.
+`ci-deliver` fetches and verifies the event tag against its commit before
+checking out the commit detached. It then loads the profile from that source,
+validates the destination and token, and downloads application dependencies
+only for profiles with build targets. The facade builds and delivers those
+targets with the note page. Source-only profiles skip dependency downloads and
+binary work. The workflow does not repeat checkout guards or maintain a
+separate build/receipt/delivery sequence.
 
-Copy one into the consumer repository's `.woodpecker/` directory. In its
-matrix entry, set `GO_IMAGE` to a Go image compatible with the consumer module
-and replace `RELEASEKIT_SOURCE` with an immutable ReleaseKit commit. The
-examples deliberately contain no claimed published ReleaseKit pin. Configure
-the Woodpecker repository secret `releasekit_gitea_token`; the workflow maps it
-to `RELEASEKIT_GITEA_TOKEN` only for the delivery step. The repository also
-needs a `delivery` profile using the default `RELEASEKIT_GITEA_TOKEN` variable.
-The binary profile must declare its build targets.
+The normal Go module and build caches are sufficient. Cache mounts may be added
+as deployment configuration when they help the runner; they are not needed by
+the template. A locally retained executable can be installed with
+`go install gitea.maximumdirect.net/eric/ReleaseKit/cmd/releasekit@PIN`, then run
+with the same arguments:
 
-The tag workflow fetches the event tag, verifies that the tag resolves to
-`CI_COMMIT_SHA`, and checks out that commit detached. Woodpecker shares the
-repository workspace between sequential steps, so the installed executable
-and Go caches remain available. The workflow keeps its `.releasekit/` directory
-out of Git status using the checkout's local exclude file.
+```sh
+releasekit ci-deliver --repo "$CI_WORKSPACE" --commit "$CI_COMMIT_SHA" "$CI_COMMIT_TAG"
+```
 
-Preparation can access the Go module proxy to install the pinned ReleaseKit
-executable. The binary workflow also runs `go mod download` before delivery.
-The single `releasekit deliver` invocation builds selected targets through the
-facade and uploads them with the release page. The source-only workflow sends
-the committed note page directly. Neither template runs `check` or `publish`.
+Upgrade by changing the selected immutable
+`RELEASEKIT_VERSION` (or the `@PIN` used by `go install`) and validating the
+workflow against a tag fixture. The command and profile behavior are documented
+in the [CLI contract](../cli.md) and [configuration reference](../config.md).
 
 Woodpecker runs delivery after the tag event, independently from the source
 publication result. Read its workflow status as delivery status: a delivery
@@ -180,6 +190,6 @@ failure does not undo source publication. A failed, partial, or uncertain run
 can be inspected and retried against the same immutable tag and commit; do not
 move the tag to make a retry pass. See
 [Woodpecker's environment reference](https://woodpecker-ci.org/docs/usage/environment)
-for the runner-provided tag and commit variables and
+for runner-provided tag and commit variables and
 [workflow syntax](https://woodpecker-ci.org/docs/usage/workflow-syntax) for tag
 events, sequential steps, and the shared workspace.