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.

docs/internal/overview.md

@@ -74,7 +74,7 @@ not a separate release matrix:
 | Page-only and managed or prebuilt binary delivery | `releasekit.Deliver`, `internal/delivery`, `internal/gitea`, CLI | `TestDeliverPageOnlySkipsBuildAndHostedAssets`, `TestDeliverManagedBuildUploadsArtifactsAndCleansTemporaryOutput`, `TestDeliverPrebuiltArtifactsRemainCallerOwned`, `TestDeliverManagedBuildFailureCleansTemporaryOutputBeforeHostedWrites`, `TestDeliverManagedBuildCancellationCleansTemporaryOutput`, `TestDeliverBuildsTaggedArtifactsAndReusesAssets`, `TestDeliverRejectsTamperedAssetsAndStaleReceiptBeforeRemoteWrites` |
 | Tagged checkout and build dependency preparation | `releasekit.PrepareTaggedCheckout`, `releasekit.PrepareBuildDependencies`, `internal/preparation`, `internal/git`, `internal/gotool` | `TestPrepareTaggedCheckoutFetchesExpectedCommitAndDetaches`, `TestPrepareTaggedCheckoutRejectsWrongCommitBeforeCheckout`, `TestPrepareTaggedCheckoutReportsLocalCheckoutConflict`, `TestPrepareTaggedCheckoutReportsConflictingLocalTag`, `TestPrepareBuildDependenciesPreservesPreparationEnvironment`, `TestPrepareBuildDependenciesPropagatesCommandFailure`, `TestPrepareBuildDependenciesPropagatesCancellation` |
 | Page, manifest, asset comparison, and additive retry outcomes | `internal/gitea` | `TestEnsureReleaseCreatesMissingPageFromCommittedNote`, `TestInspectAssetsDetectsSameNameAndSizeWithDifferentBytes`, `TestUploadMissingPartialFailureThenRerunOnlyMissingAssets` |
-| CLI profiles and prepared Woodpecker sequences | `cmd/releasekit`, `cmd/releasekit/internal/cli`, `examples/woodpecker/` | `TestLoadSettingsRejectsInvalidProfiles`, `TestWoodpeckerDeliveryCommandSequences`, `TestReleaseKitSourceDeliveryWorkflowFromTaggedCheckout` |
+| CLI profiles and prepared Woodpecker sequences | `cmd/releasekit`, `cmd/releasekit/internal/cli`, `examples/woodpecker/` | `TestLoadSettingsRejectsInvalidProfiles`, `TestWoodpeckerTagDeliveryTemplate`, `TestReleaseKitSourceDeliveryWorkflowFromTaggedCheckout` |
 
 Run the complete suite with `go test ./...`. The public API and import boundary
 check is `go run ./internal/apicheck`. Local HTTP and Git fixtures exercise

docs/release.md

@@ -111,8 +111,8 @@ If validation or a guard fails before this invocation pushes, correct and
 commit the candidate, publish `main`, and run the command again. A retained
 local tag still requires the authoritative-state check above before removal;
 a concurrent publisher may already have published the version. The prepared
-Woodpecker workflow builds the CLI from the tagged
-checkout and runs page-only delivery. To activate it after configuring the
+Woodpecker workflow builds the CLI from the tagged checkout, then uses
+`ci-deliver` for page-only delivery. To activate it after configuring the
 destination and secret, copy it to `.woodpecker/releasekit-source-delivery.yml`
 and add the Woodpecker repository secret `releasekit_gitea_token`. If page
 delivery fails or is uncertain, inspect the hosted release and retry the same

docs/roadmap/audit.md

@@ -227,11 +227,12 @@ when needed.
 
 ### F6 — Adoption priority: shared deployment still depends on copied mechanics
 
-**Evidence.** The [source-only](../../examples/woodpecker/tag-delivery-source-only.yml)
-and [binary](../../examples/woodpecker/tag-delivery-binary.yml) templates repeat
-fetch/checkout guards, local exclusions, cache setup, and tool installation.
-The binary template adds an explicit build/receipt/deliver sequence even though
-the CLI already supports combined delivery. ReleaseKit's
+**Evidence.** The original source-only and binary templates repeated
+fetch/checkout guards, local exclusions, cache setup, and tool installation;
+they are now consolidated in the maintained
+[tag-delivery template](../../examples/woodpecker/tag-delivery.yml). The binary
+template added an explicit build/receipt/deliver sequence even though the CLI
+already supports combined delivery. ReleaseKit's
 [own workflow](../../examples/woodpecker/releasekit-source-delivery.yml) has a
 separate first-release bootstrap. Consumer pins remain placeholders as documented.
 
@@ -249,14 +250,14 @@ Keep dependency preparation separate from offline validation/builds. A split
 build/delivery flow remains useful for an actual credential boundary or artifact
 handoff. See Design Choice 4 for packaging alternatives.
 
-`TestWoodpeckerDeliveryCommandSequences` in
-[the CLI workflow tests](../../cmd/releasekit/woodpecker_test.go) executes
-equivalent commands;
-[the ReleaseKit workflow test](../../cmd/releasekit/releasekit_delivery_workflow_test.go)
-similarly reconstructs the sequence. Execution of the maintained YAML and
-installation step remains unverified. A YAML drift can leave these tests green.
-Validate the selected integration during adoption and keep a small check tied to
-the maintained artifact. Use that evidence to maintain the shared integration.
+The original `TestWoodpeckerDeliveryCommandSequences` and the ReleaseKit
+workflow test reconstructed workflow commands, so YAML drift could leave the
+tests green. The maintained tag template and ReleaseKit's bootstrap workflow
+are now exercised from their command blocks by local Git/HTTP fixtures. The Go
+bootstrap shim verifies template arguments while mapping the pinned module
+invocation to the test executable; it does not verify published-module
+availability. Real installation and live Woodpecker execution remain
+deployment work.
 
 ### F7 — Medium: delivery asset classifications overlap inconsistently
 

docs/roadmap/implementation.md

@@ -1,6 +1,6 @@
 # ReleaseKit audit implementation plan
 
-Status: Stages 1–9 complete; Stage 10 next.
+Status: Stages 1–10 complete; Stage 11 next.
 Baseline: `e4be7fa` (2026-10-06). The [audit](audit.md) records the evidence,
 product goals, and selected direction. This document owns implementation order
 and completion criteria for that work.
@@ -510,6 +510,20 @@ matching remote content. The bootstrap shim proves template wiring, not
 published-module availability. Record that distinction and retain real
 installation/live Woodpecker verification as deployment work.
 
+**Completed:** Source-only and binary consumer delivery now share one
+profile-driven `tag-delivery.yml` using versioned `go run ... ci-deliver`; the
+duplicated templates were removed. ReleaseKit's separate first-source workflow
+still builds its CLI from tagged source and then uses `ci-deliver`. CLI workflow
+tests extract and execute the maintained command blocks with matrix
+substitution, Woodpecker dollar escaping, local Git/HTTP fixtures, and a Go
+bootstrap shim. Both profiles deliver successfully twice, preserving matching
+pages and binary assets. The shim validates command wiring but does not prove
+published-module availability. Consumer and maintainer guidance now covers
+bootstrap requirements, credentials, Go compatibility, caches, dependency
+preparation, and pin upgrades. Real pins and live integration remain deployment
+work. The full offline suite, API boundary check, and documentation whitespace
+checks pass.
+
 ## Stage 11 — Validate representative adoption and close the sprint
 
 **Covers:** audit-wide acceptance and adoption evidence. **Primary owners:**

docs/roadmap/releasekit.md

@@ -211,9 +211,9 @@ infrastructure and one coherent release model.
 - Choose the broader consumer integration test plan and migration sequence.
   Evaluate API clarity, product-specific checks, and the infrastructure removed
   from each consuming repository.
-- Select immutable ReleaseKit deployment pins and Go image digests for consumer
-  workflows. Provision delivery credentials and activate the prepared Woodpecker
-  workflows as part of deployment.
+- Replace the maintained example's ReleaseKit version placeholder with a real
+  immutable revision or published version. Provision delivery credentials and
+  activate consumer Woodpecker workflows as part of deployment.
 - Verify live Gitea delivery and Woodpecker execution. Existing verification uses
   local Git and HTTP fixtures; no live deployment has been verified.
 - Keep ReleaseKit executable binary distribution deferred until deliverables