Resolve ReleaseKit adoption decisions

docs/roadmap/releasekit.md

@@ -47,6 +47,15 @@ best effort. ReleaseKit's other optional checks, including formatting,
 Markdown, module-distribution, and file-size checks, remain unselected unless
 a separate decision establishes a distinct need for them.
 
+Declare `gitea.maximumdirect.net/eric/ReleaseKit/cmd/releasekit` with a
+`go.mod` `tool` directive and pin its module at v0.2.0, with resolved checksums
+in `go.sum`. The release-tool build uses that module selection; there is no
+separate executable-version pin. This adds release-tool dependencies to
+ConfigKit's module graph without importing ReleaseKit into library code or
+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
@@ -62,6 +71,14 @@ 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).
 
+Use ReleaseKit's note-heading and exact effective-push-URL guards without
+recreating ConfigKit's current exact-first-line-title or fetch-URL checks.
+Continue writing release notes with the required `# ConfigKit <version>`
+first line, while aligning release policy with the guards that actually run.
+Per-test skip listings are optional diagnostic output, not a release gate;
+ReleaseKit's one nonverbose standard suite still blocks publication on test
+failure.
+
 ReleaseKit owns generic candidate guards, test and compile coordination, tag
 creation, publication, and push recovery. ConfigKit owns version selection,
 compatibility review, note content, its selected validation and support
@@ -70,7 +87,9 @@ release process adds no ConfigKit public API or runtime use of ReleaseKit.
 
 ## Changes from the baseline
 
-- Add the minimal profile and a documented, versioned tool-preparation method.
+- 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
@@ -79,7 +98,8 @@ release process adds no ConfigKit public API or runtime use of ReleaseKit.
   [maintainer procedure](../release.md) for candidate publication to `main`
   before ReleaseKit's command, its effective-push-URL check, recurring Go
   version selection and compatibility review, one selected validation pass,
-  tag-only publication, and ReleaseKit's failure states. Preserve ConfigKit's
+  tag-only publication, ReleaseKit's standard note and URL guards, optional
+  skip listings, and ReleaseKit's failure states. Preserve ConfigKit's
   source-only deliverables, supported targets, and no-CI completion rule.
 - Update the [development guide](../development.md) so its release guidance and
   task-to-test map describe the adopted process. Keep ordinary development
@@ -99,47 +119,3 @@ release process adds no ConfigKit public API or runtime use of ReleaseKit.
 
 Historical tags and release notes remain unchanged. This adoption work does
 not itself authorize publication of a ConfigKit version.
-
-## Open Decisions
-
-### How should ConfigKit pin and acquire ReleaseKit?
-
-**Recommendation:** Use a separately installed ReleaseKit executable pinned to
-v0.2.0 for the first migration, built with the Go version selected during
-release preparation. Document acquisition before offline validation. ConfigKit
-has no hosted-delivery workflow to coordinate with a CI tool pin, so this
-keeps ReleaseKit and its tool dependencies out of ConfigKit's library module
-graph. The [OSS policy](../policy/oss.md) does not require an attribution entry
-merely for using a development tool.
-
-**Viable alternative:** Declare ReleaseKit in ConfigKit's `go.mod` and use its
-module-selected tooling convention. This gives local publication and any future
-tag-triggered delivery one version declaration, but adds tool dependencies to
-the library's module graph and requires dependency and attribution review.
-
-### Should ConfigKit keep its stricter local publication guards?
-
-**Recommendation:** Adopt ReleaseKit's note-heading rule and exact
-`expected_push_url` check, while continuing to write notes as
-`# ConfigKit <version>`. Update policy wording to match the actual automated
-guards. ReleaseKit checks the effective publication endpoint and queries that
-endpoint for remote state; retaining a second ConfigKit-specific fetch-URL and
-exact-heading checker would preserve local release machinery for little added
-value.
-
-**Viable alternative:** Retain small product checks for ConfigKit's exact
-first-line title and both configured fetch and push URLs. This preserves the
-current local policy literally, but makes ConfigKit continue owning and testing
-release-specific checks alongside ReleaseKit's standard guards.
-
-### Must the release command list skipped filesystem tests?
-
-**Recommendation:** Treat per-test skip output as optional diagnostic detail
-and revise the runbook's statement that the release checker reports it.
-ReleaseKit's single standard suite is not verbose, while failed tests still
-block publication. This avoids an extra test run solely for output.
-
-**Viable alternative:** Ask ReleaseKit for a supported verbosity selection
-within its one base test invocation. This preserves the current skip display
-without duplicating the suite, but expands the shared API and may add output
-that other consumers do not need.