Separate the Go minimum from the release toolchain

docs/policy/release.md

@@ -210,12 +210,17 @@ 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
+Release preparation advances Promptkit's `go.mod` Go requirement to the initial
-Go version available in the development environment. Use that same toolchain
+stable release of the latest Go series available in the development environment
-for candidate validation and to build any maintainer release executable.
+(for example, `go 1.26.0`). Use a higher patch minimum when required by a
-Commit the module update before validating the final candidate, and describe
+dependency or a specific correctness fix, rather than recording the maintainer's
-the resulting minimum Go requirement and compatibility impact in the release
+current patch solely because it was used to build the release.
-note under the versioning policy above.
+
+Use the latest locally available patch in that series for candidate validation
+and to build any maintainer release executable. Keep that same local toolchain
+active throughout those operations. Commit the module update before validating
+the final candidate, and describe a raised minimum Go requirement and its
+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

docs/release.md

@@ -11,16 +11,22 @@ Required tools are Git, Go with race-detector support, POSIX shell, and Python
 
 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
+command, then advance PromptKit's minimum Go requirement to that series' first
-candidate:
+stable release before committing the candidate:
 
 ```sh
 export GOTOOLCHAIN=local
 go version
 release_go_version=$(go env GOVERSION)
-go get "go@${release_go_version#go}"
+release_go_series=${release_go_version#go}
+release_go_series=${release_go_series%.*}
+go mod edit "-go=${release_go_series}.0"
 ```
 
+For example, building with Go 1.26.8 normally records `go 1.26.0`, not
+`go 1.26.8`. If a dependency or a specific correctness fix requires a higher
+patch minimum, use that minimum instead of reducing it to `.0`.
+
 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).

docs/roadmap/implementation.md

@@ -4,6 +4,10 @@ Implement the agreed [adoption roadmap](releasekit.md) in the stages below,
 in order. Each stage is scoped for one Luna coding-agent prompt. This document
 owns the implementation steps; the roadmap owns purpose and selected policy.
 
+Status: Stage 1's tool selection and dependency preparation are complete in
+`3ca01ae`. The agreed series-based Go minimum supersedes the original patch-based
+requirement. Resume adoption at Stage 2 after this revision.
+
 ## Baseline And Working Rules
 
 - Planning baseline: PromptKit commit
@@ -47,7 +51,8 @@ owns the implementation steps; the roadmap owns purpose and selected policy.
 ## Stage 1 — Declare The Released Tool And Advance The Go Requirement
 
 **Outcome:** Module metadata selects ReleaseKit as a maintainer tool and records
-the development environment's current Go requirement.
+the initial stable version of the development environment's current Go series
+as the consumer minimum, subject to required higher patch minima.
 
 **Read:** `go.mod`, `go.sum`, the runbook's
 [preparation step](../release.md#prepare-the-candidate), and the OSS policy.
@@ -56,10 +61,12 @@ the development environment's current Go requirement.
 
 1. From the repository root, use the active latest local Go installation:
    `export GOTOOLCHAIN=local`; capture `go env GOVERSION`.
-2. Advance the requirement with
+2. Follow the runbook's series-based requirement update: strip the `go` prefix
-   `go get "go@${release_go_version#go}"`, where `release_go_version` contains
+   and final patch component from the captured version, then use
-   that captured value. This is preparation before the resulting candidate
+   `go mod edit "-go=${release_go_series}.0"`. For example, local Go 1.26.8
-   commit, not an operation performed inside publication.
+   normally records `go 1.26.0`. Retain a higher patch minimum if required by a
+   dependency or a specific correctness fix. This is preparation before the
+   resulting candidate commit, not an operation performed inside publication.
 3. Add the tool with
    `go get -tool gitea.maximumdirect.net/eric/ReleaseKit/cmd/releasekit@v0.2.0`.
    Use a Go `tool` declaration, not an artificial runtime import or a
@@ -295,8 +302,9 @@ and recovery guidance, and the affected canonical documentation.
    wiring check as focused development validation, not a recurring release
    requirement or part of default Go tests.
 7. Rewrite the relevant `docs/release.md` sections around:
-   activate the latest available local Go; update its requirement before the
+   activate the latest available local Go; record its series-based minimum
-   candidate commit; prepare module caches; author the note/footer; retire
+   (or a required higher patch minimum) before the candidate commit;
+   prepare module caches; author the note/footer; retire
    completed roadmaps; ordinary review/commit; push `main`; run the single
    publication command. Preparation commands may update module metadata before
    commit; bootstrap/validation preserve the final candidate.
@@ -362,8 +370,9 @@ completion criteria.
 
 - The final source-only publication command delegates to released ReleaseKit;
   the committed profile is the single local declaration of selected checks.
-- Go metadata records the preparation-time requirement; tool build, native
+- Go metadata records the series-based minimum or a required higher patch
-  validation and examples use the same selected local Go installation.
+  minimum; tool build, native validation and examples use the same selected
+  latest-local-patch Go installation, independently of that consumer minimum.
 - Profile-selected shared validation and the real consumer examples pass on the
   complete source snapshot, while fixture failures prevent publication.
 - No runtime ReleaseKit import, local module replacement, extra release gate,

docs/roadmap/releasekit.md

@@ -1,6 +1,6 @@
 # ReleaseKit Adoption Roadmap
 
-Status: Adoption scope agreed; implementation has not started.
+Status: Tool dependency selected; remaining adoption work is pending.
 The [implementation plan](implementation.md) owns the ordered migration steps.
 
 ## Purpose
@@ -71,10 +71,13 @@ 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
+Release preparation records the initial stable release of the latest locally
-Go version available in the development environment. The
+available Go series as PromptKit's minimum requirement, retaining a higher patch
+minimum where needed by a dependency or a specific correctness fix. The
 [runbook preparation step](../release.md#prepare-the-candidate) makes that
-toolchain active before committing the candidate. Use the same Go version
+series' latest locally available patch active before committing the candidate.
+The module minimum and build toolchain are separate: for example, `go 1.26.0`
+can be built and validated with Go 1.26.8. Use the same local 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
@@ -203,7 +206,7 @@ Update the affected canonical owners when the implementation lands:
 | --- | --- |
 | `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` | 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/release.md` | Preserve the preparation-time series-based Go minimum and latest-local-patch selection; 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. |
 

go.mod

@@ -1,6 +1,6 @@
 module gitea.maximumdirect.net/eric/promptkit
 
-go 1.26.8
+go 1.26.0
 
 require (
 	gitea.maximumdirect.net/eric/ConfigKit v0.5.0