Prepare ReleaseKit hosted-page delivery

docs/policy/release.md

@@ -41,12 +41,16 @@ A failed or ambiguous push requires resolving the authoritative remote state
 before declaring success or retrying; successful pushes do not require a
 separate remote read-back gate.
 
-ReleaseKit's initial deliverable is source only. Distributing executable builds
-requires a deliberate update identifying the deliverables, selected targets,
-and automation responsibilities. Supporting cross-builds for consumers does not
-declare ReleaseKit binaries. Additional declared deliverables may be published
-asynchronously from the tagged source, must be traceable to that source, and
-must identify the same version.
+ReleaseKit's deliverables are its immutable source tag and a hosted Gitea
+release page whose body is the complete checked-in release note. A prepared
+Woodpecker workflow builds the local release tool from that tagged source and
+delivers the note page. This adds no executable download or binary manifest.
+Any later distribution of executable builds requires a deliberate update
+identifying the deliverables, selected targets, and automation responsibilities.
+Supporting cross-builds for consumers does not declare ReleaseKit binaries.
+Additional declared deliverables may be published asynchronously from the
+tagged source, must be traceable to that source, and must identify the same
+version.
 
 Track source-release completion and artifact delivery separately. Report delivery
 failures and optional investigations under artifact-delivery status.

docs/release.md

@@ -1,11 +1,14 @@
 # ReleaseKit release procedure
 
-ReleaseKit's initial deliverable is source only. The authoritative repository
-is `origin` at `https://gitea.maximumdirect.net/eric/ReleaseKit.git`, and the
-release branch is `main`. A release completes when the intended annotated tag
-is successfully pushed, or when one exact-object recovery query confirms that
-the push succeeded. CI, hosted artifacts, and consumer installation are not
-completion checks.
+ReleaseKit's deliverables are its source tag and a hosted Gitea page containing
+the complete checked-in release note. The page is delivered asynchronously by
+the prepared [Woodpecker workflow](../examples/woodpecker/releasekit-source-delivery.yml);
+it is not a source-release completion check and carries no binary assets. The
+authoritative repository is `origin` at
+`https://gitea.maximumdirect.net/eric/ReleaseKit.git`, and the release branch
+is `main`. A release completes when the intended annotated tag is successfully
+pushed, or when one exact-object recovery query confirms that the push
+succeeded. CI and consumer installation are not completion checks.
 
 ## Prepare a candidate
 
@@ -88,6 +91,24 @@ uses the version, choose a new version after resolving the conflict.
 
 If validation or a guard fails before the push, the local tag has not been
 published. Correct and commit the candidate, publish `main`, and run the
-command again. ReleaseKit does not publish executable artifacts or wait for
-asynchronous delivery; any future deliverables require a separate policy and
-procedure update.
+command again. The prepared Woodpecker workflow builds the CLI from the tagged
+checkout and runs 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
+immutable version from its tag:
+
+```sh
+git fetch origin "refs/tags/vX.Y.Z:refs/tags/vX.Y.Z"
+git checkout --detach "vX.Y.Z"
+mkdir -p .releasekit/bin
+GOTOOLCHAIN=local GOPROXY=off GOSUMDB=off go build -o .releasekit/bin/releasekit ./cmd/releasekit
+RELEASEKIT_GITEA_TOKEN="$GITEA_TOKEN" .releasekit/bin/releasekit deliver "vX.Y.Z"
+```
+
+The root ignore file excludes `.releasekit/`. Delivery uses the committed note
+and does not build consumer binaries, create a checksum manifest, or require a
+previously released ReleaseKit executable. Keep source publication and hosted
+page delivery status separate; retry only after resolving an uncertain remote
+write. The workflow secret is named `releasekit_gitea_token` and is mapped to
+`RELEASEKIT_GITEA_TOKEN` only in the delivery step.

docs/roadmap/implementation.md

@@ -1,6 +1,6 @@
 # ReleaseKit staged implementation plan
 
-Status: In progress. Stages 1–16 are complete; later stages remain pending.
+Status: In progress. Stages 1–17 are complete; later stages remain pending.
 
 Date: 2026-10-05
 
@@ -882,7 +882,7 @@ 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.
+Status: Complete. Depends on Stage 16.
 
 1. Extend ReleaseKit's source-only profile with its Gitea destination and token
    environment name. Keep the build target set empty and retain its selected
@@ -905,6 +905,19 @@ requiring a receipt, or consulting a previously released tool. Delivery failure
 leaves source status unchanged. Workflow preparation requires no real tag,
 credentials, remote push, CI activation, or maintainer checkpoint.
 
+Evidence: ReleaseKit's root profile identifies its Gitea destination and
+`RELEASEKIT_GITEA_TOKEN`, preserves the offline default test suite, and declares
+no build targets. The repository-specific Woodpecker example remains under
+`examples/` and builds the CLI from the fetched, commit-checked tag before
+page-only delivery; the release procedure documents later activation and secret
+configuration, source-tag completion, and same-tag retry. A local integration
+test clones and tags a temporary copy of the repository, builds the CLI from
+that tag, and exercises delivery against a local HTTP server. It verifies a
+hosted-tag failure leaves the source tag intact, then checks page creation and
+an identical rerun without assets; the complete note body, including its three
+license links, is preserved. No real tag, push, credential, or hosted service
+was used.
+
 ## Stage 18: Complete the initial implementation and handoff documentation
 
 Status: Pending. Depends on Stage 17.