Request adaptable release validation for ConfigKit

docs/roadmap/feature-request-configkit.md

@@ -0,0 +1,67 @@
+# Feature request from ConfigKit: adaptable release validation
+
+Status: Requested by a prospective downstream consumer; not yet adopted by
+ReleaseKit.
+
+ConfigKit would like to adopt ReleaseKit's common source-release process and
+retire most of its repository-owned release scripts and publication tests. It is
+a source-only Go library. ConfigKit can follow ReleaseKit's existing convention
+of publishing the candidate to `main` before running the tag-publication
+command; it does not need binary artifacts or a different source-publication
+sequence.
+
+## Select one base Go test invocation
+
+ReleaseKit's [candidate check](../consumers/check.md) currently runs its
+standard `go test` suite before any configured additional checks. ConfigKit's
+selected release validation includes a race-enabled run of its full test
+suite, with a separate full vet pass. Expressing the race run as an additional
+check would run the suite twice and retain avoidable consumer-specific release
+wiring.
+
+Please provide a small public API and profile capability for a consumer to
+select its **one base Go test invocation** for candidate validation. The
+selection should replace the default invocation, rather than add a second test
+run. Without a selection, ReleaseKit's current default remains useful. Both
+`Check` and `Publish`, including their CLI forms, should use the selected
+invocation consistently while ReleaseKit continues to own candidate capture,
+validation order, result reporting, and publication. ConfigKit needs to select
+a full-suite race run with test-time vet omitted because it selects a separate
+full vet pass. ReleaseKit can choose the simplest public expression of that
+choice; ConfigKit is not asking for a general-purpose release pipeline or
+consumer-owned orchestration.
+
+## Evaluate shared release checks
+
+ConfigKit also uses a separate full `go vet` pass and compile checks for Linux
+amd64 and arm64. Please assess whether these checks are useful enough across
+ReleaseKit consumers to offer directly through its public API and profile,
+either as defaults or as selected options where product support differs.
+
+In particular, a source-only library needs to verify that its packages compile
+for selected targets without declaring executable artifacts or adding delivery
+work. ReleaseKit could make that distinction available to consumers. The goal
+is to keep these checks, when selected, within the same candidate validation
+and publication flow without repeating work already done by the base test.
+Whether race, vet, or cross-target compilation should be common defaults is a
+ReleaseKit product decision; ConfigKit asks for an assessment, not a universal
+new release gate.
+
+## Optional publication endpoint expectation
+
+ConfigKit currently identifies one expected authoritative Git destination. An
+optional expected-endpoint setting in ReleaseKit's public API and profile could
+let a consumer verify that the selected remote resolves to its declared
+destination before publication. Please consider whether this is broadly useful
+and simpler than retaining a small consumer-owned preflight check. Existing
+ReleaseKit remote selection and endpoint handling should remain the common
+publication model.
+
+## Adoption outcome
+
+A useful outcome would let ConfigKit declare its product identity, selected
+validation, and any expected publication destination, then rely on ReleaseKit's
+standard candidate check and tag-publication command. ConfigKit would retain
+its compatibility decisions and release notes while removing duplicated release
+mechanics. Source publication would still complete at the confirmed tag push;
+CI and hosted delivery would remain separate from that completion point.