Separate the Go minimum from the release toolchain

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
-   `go get "go@${release_go_version#go}"`, where `release_go_version` contains
-   that captured value. This is preparation before the resulting candidate
-   commit, not an operation performed inside publication.
+2. Follow the runbook's series-based requirement update: strip the `go` prefix
+   and final patch component from the captured version, then use
+   `go mod edit "-go=${release_go_series}.0"`. For example, local Go 1.26.8
+   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
-   candidate commit; prepare module caches; author the note/footer; retire
+   activate the latest available local Go; record its series-based minimum
+   (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
-  validation and examples use the same selected local Go installation.
+- Go metadata records the series-based minimum or a required higher patch
+  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,