Consolidate Woodpecker delivery templates

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