Separate Go minimum from release toolchain

docs/roadmap/implementation.md

@@ -9,17 +9,18 @@ current release procedure authoritative until the replacement is working.
 Follow the task-specific reading guide in [development.md](../development.md)
 and avoid adding gates, compatibility promises, or restrictions beyond the
 roadmap and adopted policies. Stages 3–5 are one documentation-and-machinery
-cutover; their intermediate state is not a release candidate.
+cutover; do not commit or hand off their intermediate state as a release-ready
+candidate.
 
 ## Stage 1: Select Go and declare the release tool
 
-1. Identify the newest Go executable available in the development environment
-   when implementing this stage. Make it the `go` on `PATH`, verify it with
-   `GOTOOLCHAIN=local go version`, and advance ConfigKit's `go.mod` `go`
-   directive to its full version. Do not substitute a newer downloaded
-   toolchain during later validation. Record the resulting minimum-Go increase
-   for the next release's compatibility review; before v1.0.0, an intentional
-   increase requires a minor release, not a patch release.
+1. Identify the latest locally available patch in the newest stable Go series
+   available in the development environment. Make it the `go` on `PATH` and
+   verify it with `GOTOOLCHAIN=local go version`. Keep ConfigKit's current
+   `go.mod` `go` minimum until the release-workflow cutover in Stage 4: the
+   existing release checker still selects Go 1.25 and cannot validate a module
+   requiring Go 1.26. Do not substitute an automatically downloaded toolchain
+   during later validation.
 2. Using that same Go executable, add
    `gitea.maximumdirect.net/eric/ReleaseKit/cmd/releasekit@v0.2.0` as a
    `go.mod` tool dependency (the Go `tool` directive and its module
@@ -34,10 +35,13 @@ cutover; their intermediate state is not a release candidate.
    [OSS policy](../policy/oss.md); a tool used only for development and release
    work does not by itself require an attribution entry.
 
-Completion evidence: `go.mod` selects the chosen Go version and the pinned
-ReleaseKit tool, `go.sum` is consistent, `go mod tidy` leaves no unintended
-changes, the module-selected executable builds with the selected Go, and the
-ordinary offline Go suite still passes after dependencies are prepared.
+Completion evidence: `go.mod` retains its current Go minimum and selects the
+pinned ReleaseKit tool, `go.sum` is consistent, `go mod tidy` leaves no
+unintended changes, the module-selected executable builds with the selected
+local Go, and the ordinary offline Go suite still passes after dependencies
+are prepared. If the new tool dependency itself requires a higher minimum,
+handle that compatibility change together with the cutover rather than
+leaving the current release checker unusable.
 
 ## Stage 2: Add ConfigKit's ReleaseKit profile
 
@@ -70,8 +74,11 @@ delivery configuration.
    baseline with the selected local Go executable, the current `go.mod`
    minimum, the module-selected ReleaseKit CLI, its one race suite with
    test-time vet disabled, full vet, and Linux amd64/arm64 package compilation.
-   State that preparation advances `go.mod` to the newest Go available in the
-   development environment and reviews any minimum-version increase under
+   State that preparation records the initial stable release of the newest
+   locally available Go series in `go.mod`, retaining a higher patch minimum
+   only when required by a dependency or specific correctness fix. Use the
+   latest locally available compatible patch in that series for ReleaseKit's
+   build and validation, and review any minimum-version increase under
    existing compatibility rules. Keep dependency acquisition and tool build
    before offline candidate validation; do not add a separate successful test
    or CI run as a publication prerequisite.
@@ -89,16 +96,21 @@ stronger automated guards as current behavior.
 ## Stage 4: Replace the maintainer release runbook
 
 1. Revise [the runbook](../release.md) into copyable steps for the adopted
-   process. During preparation, select the newest Go executable available in
-   the development environment, keep it first on `PATH`, verify its version
-   with `GOTOOLCHAIN=local`, and update `go.mod` to that full version if needed.
+   process. During this cutover, move `go.mod` from its current minimum to the
+   first stable release of the newest Go series available in the development
+   environment (for example, `go 1.26.0` when using Go 1.26.8), unless a
+   dependency or specific correctness fix needs a higher patch minimum. Have
+   the runbook derive the series from `GOTOOLCHAIN=local go env GOVERSION` and
+   use `go mod edit` to record its `.0` release, without lowering an existing
+   required higher patch minimum. Keep that series' latest locally available
+   compatible patch first on `PATH` for both the tool build and validation.
    Explain the minimum-Go compatibility impact and version choice, including
-   the pre-v1.0.0 minor-release rule. Prepare dependencies, then build the
-   module-selected `cmd/releasekit` with that executable into temporary storage
-   outside the repository. Use the native executable for publication so its
-   exit status and diagnostic state are preserved. Its child Go commands must
-   find the same selected `go` on `PATH`; the old
-   `CONFIGKIT_BASELINE_TOOLCHAIN` selector cannot choose them.
+   the pre-v1.0.0 minor-release rule. Prepare
+   dependencies, then build the module-selected `cmd/releasekit` with that
+   executable into temporary storage outside the repository. Use the native
+   executable for publication so its exit status and diagnostic state are
+   preserved. Its child Go commands must find the same selected `go` on `PATH`;
+   the old `CONFIGKIT_BASELINE_TOOLCHAIN` selector cannot choose them.
 2. Keep ordinary candidate preparation: check access to the authoritative
    remote, choose an unused stable version, review compatibility and content,
    write `docs/releases/<version>.md` with the exact ConfigKit first line and
@@ -151,8 +163,10 @@ profile wiring without duplicating ReleaseKit's generic behavior.
 
 ## Stage 6: Exercise the migration without publishing ConfigKit
 
-1. Build ReleaseKit from the candidate's `go.mod` selection with the same Go
-   executable declared by that candidate. In disposable Git fixtures, use
+1. Build ReleaseKit from the candidate's `go.mod` selection with the latest
+   selected local Go patch for that minimum's series. Use that same executable
+   for ReleaseKit's validation, without requiring its patch number to equal
+   the `go.mod` minimum. In disposable Git fixtures, use
    ConfigKit's selected profile with only `expected_push_url` changed to a
    temporary bare remote, and provide a matching committed fixture release
    note. Never push a ConfigKit tag or source commit to its real remote.