Separate Go minimum from release toolchain

docs/roadmap/releasekit.md

@@ -56,18 +56,20 @@ adding a runtime API. Review the resulting module changes and license
 treatment under the [OSS policy](../policy/oss.md); tooling use alone does not
 require an attribution entry.
 
-At each release preparation, select the newest Go version available in the
-development environment and advance ConfigKit's `go.mod` `go` directive to
-that version. This deliberately raises ConfigKit's minimum Go version for
-consumers when the selected version is newer. Use the same selected Go
-executable to build the pinned ReleaseKit tool and to run ReleaseKit's
-validation, with native race prerequisites available. ReleaseKit sets
-`GOTOOLCHAIN=local` for its child commands, so ConfigKit's existing
-`CONFIGKIT_BASELINE_TOOLCHAIN` environment selection cannot select a
+At each release preparation, select the newest stable Go series available in
+the development environment. Record that series' first stable release in
+ConfigKit's `go.mod` `go` directive (for example, `go 1.26.0` when using Go
+1.26.8), retaining a higher patch minimum when a dependency or specific
+correctness fix requires it. This directive is the consumer minimum, not the
+release toolchain version. Use the latest locally available patch in the
+selected series to build the pinned ReleaseKit tool and run its validation,
+provided it meets that minimum and has native race prerequisites available.
+ReleaseKit sets `GOTOOLCHAIN=local` for its child commands, so ConfigKit's
+existing `CONFIGKIT_BASELINE_TOOLCHAIN` environment selection cannot select a
 different validation toolchain. Prepare the tool and dependencies before
-offline candidate validation; the `go.mod` change belongs in the committed
-candidate. Review any minimum-Go increase as a compatibility change and
-explain its consumer impact in the release note. Before v1.0.0, an intentional
+offline candidate validation; any `go.mod` change belongs in the committed
+candidate. Review a minimum-Go increase as a compatibility change and explain
+its consumer impact in the release note. Before v1.0.0, an intentional
 increase requires a minor rather than patch release under ConfigKit's
 [versioning policy](../policy/release.md#versioning-and-compatibility).
 
@@ -90,9 +92,9 @@ release process adds no ConfigKit public API or runtime use of ReleaseKit.
 - Add the minimal profile and declare ReleaseKit v0.2.0 as a tool dependency in
   `go.mod`, updating `go.sum` and reviewing its dependency and license impact.
   Document how to build the module-selected tool before offline validation.
-  The release runbook should select the newest Go available in the development
-  environment, advance `go.mod`, and build ReleaseKit with that same Go
-  executable. Keep the selected release command small and do not re-create
+  The release runbook should record the selected series' minimum in `go.mod`,
+  use its latest locally available patch to build ReleaseKit and validate the
+  candidate, and keep the selected release command small. Do not re-create
   generic Git guards or Go check sequencing in a wrapper.
 - Revise the [release policy](../policy/release.md) and
   [maintainer procedure](../release.md) for candidate publication to `main`
@@ -113,9 +115,10 @@ release process adds no ConfigKit public API or runtime use of ReleaseKit.
 - Verify the migration without publishing a real ConfigKit version: exercise
   the selected profile and release command against an isolated candidate and
   temporary Git remote, including a validation failure and successful tag
-  publication. Confirm that the selected Go executable matches the candidate's
-  `go.mod` directive, builds ReleaseKit, and runs the selected gates once. Do
-  not make a separate successful CI run a release condition.
+  publication. Confirm that the candidate's `go.mod` records the selected
+  series' minimum or a required higher patch, and that the same selected Go
+  executable builds ReleaseKit and runs the selected gates once. Do not make
+  a separate successful CI run a release condition.
 
 Historical tags and release notes remain unchanged. This adoption work does
 not itself authorize publication of a ConfigKit version.