Align release policy with ReleaseKit

docs/policy/release.md

@@ -54,10 +54,11 @@ authoritative primary branch, completes the release. The source commit may be
 pushed before the tag or published together with it through an atomic push.
 The procedure must choose and document the supported approach.
 
-ConfigKit uses sequential explicit pushes: first the captured candidate to
-authoritative `main`, then the annotated tag. Its
-[release procedure](../release.md) names `origin` and checks that its fetch and
-push destinations resolve to the authoritative URL.
+ConfigKit uses sequential publication: first push the committed candidate to
+authoritative `main`, then invoke ReleaseKit once to validate that candidate and
+publish its annotated tag. The [release procedure](../release.md) names
+`origin`; ReleaseKit checks its exact effective push URL before validation and
+tag publication.
 
 Release commands must finish at successful publication. They must not wait for
 or poll CI, require successful CI status, inspect downloadable artifacts, or
@@ -76,8 +77,9 @@ the tagged source. The procedure must identify those deliverables and the
 responsibility of their automation. Published deliverables must be traceable
 to that source and identify the same version.
 
-ConfigKit currently declares no additional deliverables. Its source-tag push
-is the completion point.
+ConfigKit currently declares no additional deliverables. Confirmed publication
+of the intended source tag is the completion point. CI, macOS validation,
+hosted delivery, and consumer retrieval are outside the release gates.
 
 ## Versioning And Compatibility
 
@@ -114,7 +116,8 @@ Every new release must include `docs/releases/<version>.md` in the tagged
 source tree. Use the complete version tag as the filename and begin with a
 title containing the product name and that exact version.
 
-ConfigKit requires the first line `# ConfigKit <version>`.
+ConfigKit requires the first line `# ConfigKit <version>`. ReleaseKit v0.2.0's
+publication guard checks the release-note H1 for the product and version.
 
 Include a short summary and any relevant compatibility impact or upgrade
 instructions. Choose sections suited to the release and keep the note
@@ -146,10 +149,9 @@ checks publication state, and publishes the intended refs. A validation-only
 mode or command may be provided for diagnosis, but must not be a required step
 before publication repeats the same checks.
 
-ConfigKit uses `./scripts/release.sh vMAJOR.MINOR.PATCH`. The separate
-`scripts/release-check.sh` remains an optional diagnostic command; the
-publication command invokes it once and does not use a persistent candidate
-record.
+ConfigKit uses the module-selected ReleaseKit CLI's `publish
+vMAJOR.MINOR.PATCH` command. Its `check` command is optional for diagnosis; it
+is not a required preliminary pass to publication.
 
 Run the complete deterministic, offline default test suite once for the final
 candidate, following the [testing policy](testing.md). For repositories that
@@ -157,13 +159,24 @@ publish builds, verify the required build targets. Select those targets for
 the application's actual support commitments; native testing on each platform
 and access to particular hardware are not default release prerequisites.
 
-ConfigKit's one maintained Go 1.25 baseline runs the full suite with the race
-detector and test-time vet disabled. This protects library behavior, ownership,
-and concurrent use; the suite already includes examples, consumer fixtures,
-documentation links, and package boundaries. One full vet pass adds static
-checks beyond the test-time subset. CGO-disabled Linux amd64 and arm64 builds
-cover supported configurations distinct from native race compilation. macOS
-and newer-toolchain checks are optional.
+For release preparation, record the initial stable release of the newest
+locally available Go series in `go.mod`'s `go` directive. Retain a higher patch
+minimum only when required by a dependency or a specific correctness fix. Use
+the latest locally available compatible patch in that series, selected with
+`GOTOOLCHAIN=local`, to build the module-selected ReleaseKit CLI and validate the
+candidate, provided it meets the current `go.mod` minimum. Review any
+minimum-version increase under the existing compatibility rules. Prepare
+dependencies and build the tool before offline validation; the publication
+command is the required validation run, with no separate successful test or CI
+run required before it.
+
+The selected profile runs the complete deterministic, offline default suite
+once with the race detector and test-time vet disabled. The suite already
+includes examples, consumer fixtures, documentation links, and package
+boundaries. One full vet pass adds static checks beyond the test-time subset.
+CGO-disabled Linux amd64 and arm64 package compilation covers supported
+configurations distinct from native race compilation. macOS and newer-toolchain
+checks are optional.
 
 Additional gates must address a concrete risk that the existing checks do not
 adequately cover. Do not automatically require linting, race testing, module
@@ -172,9 +185,10 @@ expanded platform matrices solely because they are possible. Retain such
 checks when their distinct protection justifies their cost. A one-time migration
 check must not silently become a permanent release requirement.
 
-The selected Go commands use readonly module mode with `GOPROXY=off`; acquire
-the baseline toolchain and dependencies before validation. Formatting and
-whitespace remain ordinary development checks in `scripts/check.sh`.
+ReleaseKit runs its selected Go commands with readonly module mode and
+`GOPROXY=off`; acquire dependencies and build the tool before candidate
+validation. Formatting and whitespace remain ordinary development checks in
+`scripts/check.sh`.
 Review module tidiness when dependencies change, not as a release gate.
 
 Release tests must not require real credentials, mutable application services,
@@ -206,16 +220,19 @@ Automate the checks needed to publish the intended source under a fresh version:
   authoritative remote;
 - the worktree and index are clean on the primary release branch;
 - the source being published is the exact candidate that passed validation,
-  including its matching release note;
+  including its matching release note H1;
 - the remote primary branch can be advanced to that candidate without
   discarding remote history, and is published before the tag; and
 - the tag identifies the validated candidate and only the intended refs are
   published.
 
-ConfigKit also checks that `origin` has exactly the authoritative fetch and
-push destination, including configured push URLs. The command checks the
-candidate and unused version again after validation, and checks local state
-before creating the tag. Ignored local files do not block publication.
+ReleaseKit checks that `origin`'s effective push URL exactly matches the
+authoritative URL before candidate validation. This does not assert the
+configured fetch URL or require the release-note H1 to be the first line; the
+required `# ConfigKit <version>` first-line format remains a content rule. The
+command checks the candidate and unused version again after validation, and
+checks local state before creating the tag. Ignored local files do not block
+publication.
 
 Fetch the authoritative branch and tag state as needed for these checks.
 Do not force branch or tag updates to bypass a failed guard. Publish explicit

docs/roadmap/implementation.md

@@ -62,7 +62,7 @@ Completion evidence: the profile is valid JSON, the focused test and ordinary
 Go suite pass, and review shows only the selected gates and no binary or hosted
 delivery configuration.
 
-## Stage 3: Align release policy with the adopted workflow
+## Stage 3: Align release policy with the adopted workflow — Complete
 
 1. Revise [the release policy](../policy/release.md) so candidate preparation
    explicitly publishes the committed candidate to authoritative `main`