Align release preparation and tooling with the current Go version

docs/policy/release.md

@@ -2,7 +2,7 @@
 
 **Base Policy Version:** 1.4
 
-**Last Updated**: 2026-09-27
+**Last Updated**: 2026-10-08
 
 **Upstream Source:** [release.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/release.md)
 
@@ -210,6 +210,13 @@ annotated stable SemVer tags. It has no binaries, hosted download pages, or
 asynchronous deliverables. The source commit is pushed through main before the
 tag. The [release procedure](../release.md) owns commands and recovery.
 
+Release preparation advances Promptkit's `go.mod` Go requirement to the latest
+Go version available in the development environment. Use that same toolchain
+for candidate validation and to build any maintainer release executable.
+Commit the module update before validating the final candidate, and describe
+the resulting minimum Go requirement and compatibility impact in the release
+note under the versioning policy above.
+
 The existing publication script requires Summary, Compatibility, Upgrade, and
 Changes headings beneath a title of `# Promptkit vMAJOR.MINOR.PATCH`. State
 “No action required” or “None” where appropriate. This retained local structure

docs/release.md

@@ -9,6 +9,25 @@ for CI to finish or succeed.
 Required tools are Git, Go with race-detector support, POSIX shell, and Python
 3. Publication requires push access to origin. Work from the repository root.
 
+Use the latest Go toolchain available in the development environment for
+release preparation and validation. Make that installation the active `go`
+command, then advance PromptKit's Go requirement before committing the
+candidate:
+
+```sh
+export GOTOOLCHAIN=local
+go version
+release_go_version=$(go env GOVERSION)
+go get "go@${release_go_version#go}"
+```
+
+Include the module change in the candidate commit. Describe a raised minimum
+Go requirement in the release note and select the release version under the
+[compatibility policy](policy/release.md#versioning-and-compatibility).
+Keep this toolchain active through validation and publication. Toolchain
+selection and the module update are preparation, not mutations of an already
+validated candidate.
+
 Select an unused version and create `docs/releases/<version>.md` using the
 [required structure](policy/release.md#release-documentation). Describe
 compatibility impact and consumer actions and update affected canonical docs.

docs/roadmap/releasekit.md

@@ -71,9 +71,20 @@ push result. Tool bootstrap and dependency preparation precede offline
 candidate validation. The wrapper's responsibility is tool invocation;
 ReleaseKit owns candidate guards, validation coordination, tags, and recovery.
 
+Release preparation advances PromptKit's `go.mod` Go requirement to the latest
+Go version available in the development environment. The
+[runbook preparation step](../release.md#prepare-the-candidate) makes that
+toolchain active before committing the candidate. Use the same Go version
+to build ReleaseKit and run PromptKit's release validation, including the
+consumer examples. Local tooling uses that selected installation rather than
+an executable previously built with a different Go version or an automatically
+downloaded toolchain. This also aligns ReleaseKit's built-in formatter with
+the Go toolchain selected for the release.
+
 Tool output stays outside committed source, and preparation preserves the
-candidate's module files. The library's supported runtime API and execution
+committed candidate's module files after the preparation-time Go update.
-logic need no changes. Tool declarations affect the module graph without
+The library's supported runtime API and execution logic need no changes.
+Tool declarations affect the module graph without
 adding a ReleaseKit runtime import or a PromptKit release-orchestration package.
 
 ### Shared Validation Selection
@@ -153,6 +164,12 @@ Add the tool declaration and selected dependency to `go.mod`, with applicable
 checksum updates, and introduce the small release profile. Replace local
 publication mechanics in `scripts/release.sh` with native tool invocation.
 
+Carry the runbook's preparation-time Go update into the adopted workflow.
+Build the selected ReleaseKit module with that same local toolchain before
+validating the committed candidate. Record the resulting minimum Go version
+and relevant compatibility impact when preparing the PromptKit release note.
+Tool bootstrap preserves the module files already committed for that release.
+
 Extract the three example assertions into the focused additional check.
 Retire the generic `scripts/release-check.sh` implementation rather than
 maintaining parallel shared validators solely for development.
@@ -180,9 +197,9 @@ Update the affected canonical owners when the implementation lands:
 
 | File | Required alignment |
 | --- | --- |
-| `docs/policy/release.md` | Describe the shared validation selections, simpler note convention, adopted publication/recovery model, retired gates, and selected deliverables. Preserve existing compatibility and catalog-profile policy. |
+| `docs/policy/release.md` | Describe the shared validation selections, simpler note convention, adopted publication/recovery model, retired gates, and selected deliverables. Preserve the Go-update/same-toolchain requirement, existing compatibility policy, and catalog-profile policy. |
 | `docs/policy/testing.md` | Route release validation through ReleaseKit while retaining race, full vet, and the three consumer workflows. Distinguish ordinary development checks from committed-candidate validation. |
-| `docs/release.md` | Provide the short executable runbook for tool/dependency preparation, candidate preparation, one publication command, and upstream recovery. |
+| `docs/release.md` | Preserve the preparation-time update to the latest development-environment Go version; document building ReleaseKit with that same toolchain, dependency preparation, one publication command, and upstream recovery. |
 | `docs/development.md` | Replace the old checker inventory and prerequisites with current tool ownership and focused development commands. |
 | `docs/oss/attribution.md` and related notices, if applicable | Apply the OSS policy to the selected tooling and any copied or adapted material according to actual use and distribution. Tool use alone is not a blanket attribution requirement. |
 
@@ -203,6 +220,9 @@ select the released tool and expected checks, that the maintained examples
 still verify meaningful consumer behavior, and that the resulting procedure
 can validate and publish to a temporary Git remote.
 
+Verification of tool bootstrap should also establish that the release tool
+uses the same Go version selected for PromptKit's candidate validation.
+
 Use a small representative integration fixture for local wiring and failure
 propagation. ReleaseKit owns the shared validators' and publication machinery's
 detailed behavioral tests. Avoid duplicating its matrix or recursively running