# 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.