Add Woodpecker tagged-release workflows

docs/consumers/delivery.md

@@ -79,3 +79,44 @@ fmt.Println(result.State, result.ReleaseURL)
 See the [CLI contract](../cli.md), [configuration reference](../config.md),
 and [Gitea integration guide](../integrations/gitea.md) for exact settings,
 exit codes, and transport behavior.
+
+## Woodpecker tag workflows
+
+Maintained workflow examples are available for source-only and binary delivery:
+
+- [Source-only tag workflow](../../examples/woodpecker/tag-delivery-source-only.yml)
+- [Binary tag workflow](../../examples/woodpecker/tag-delivery-binary.yml)
+
+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 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,
+Go caches, build outputs, and build receipt remain available to later steps.
+The workflow keeps its `.releasekit/` directory out of Git status using the
+checkout's local exclude file.
+
+Preparation can access the Go module proxy to install the pinned ReleaseKit
+executable. The binary workflow also runs `go mod download` before the build.
+The later `releasekit build` command runs with `GOPROXY=off` and
+`GOTOOLCHAIN=local`; its declared binary targets and receipt are placed in
+`.releasekit/assets`. Delivery then passes that directory with `--assets`.
+The source-only workflow skips this build step and sends the committed note
+page directly. Neither template runs `check` or `publish`.
+
+Woodpecker runs delivery after the tag event, independently from the source
+publication result. Read its workflow status as delivery status: a delivery
+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
+[workflow syntax](https://woodpecker-ci.org/docs/usage/workflow-syntax) for tag
+events, sequential steps, and the shared workspace.

docs/roadmap/implementation.md

@@ -1,6 +1,6 @@
 # ReleaseKit staged implementation plan
 
-Status: In progress. Stages 1–15 are complete; later stages remain pending.
+Status: In progress. Stages 1–16 are complete; later stages remain pending.
 
 Date: 2026-10-05
 
@@ -835,7 +835,7 @@ no live Gitea service or credentials were used.
 
 ## Stage 16: Provide the common Woodpecker integration
 
-Status: Pending. Depends on Stage 15.
+Status: Complete. Depends on Stage 15.
 
 1. Add maintained source-only and binary-producing tag-pipeline templates.
    Parameterize the Go image and immutable ReleaseKit source pin for eventual
@@ -863,6 +863,23 @@ CI success is not a source release gate. The
 [Woodpecker environment reference](https://woodpecker-ci.org/docs/usage/environment)
 owns the runner-provided tag and commit variables.
 
+Evidence: maintained source-only and binary tag workflows are in
+`examples/woodpecker/`. Both parameterize the Go image and immutable ReleaseKit
+commit through their matrix entries, verify the fetched tag against the runner
+commit, and keep shared output under the locally ignored `.releasekit/`
+directory. Only the delivery step maps the configured Woodpecker secret to the
+CLI token variable. The source-only workflow delivers the note page; the binary
+workflow prepares module caches, builds declared targets offline, and passes
+the build receipt and assets into delivery. The delivery guide covers template
+inputs, source publication versus delivery status, and retries against the same
+tag. A test builds the CLI from this checkout and exercises both workflows'
+delivery command sequences against fixture repositories and a local HTTP
+server; it substitutes the built executable for the installation command. Both
+YAML files parse with locally available PyYAML 6.0.3, and static checks confirm
+their tag filters, step layout, and delivery-only secret mapping. `go test ./...`,
+`go run ./internal/apicheck`, and the Markdown whitespace check pass. No live
+Woodpecker runner, image pull, secret, or hosted delivery service was used.
+
 ## Stage 17: Prepare ReleaseKit's own hosted-page delivery
 
 Status: Pending. Depends on Stage 16.