# CommandKit feature request: host-safe consumer launchers

Status: proposed; not an accepted contract or implementation assignment.

## Consumer need

CommandKit selects ReleaseKit v0.8.0 as a Go tool and uses a small launcher to
publish its core and two optional integration modules. Maintainers can inherit
`GOOS` and `GOARCH` from application cross-build work. The release tool must run
on the maintainer's host even when those variables name another target.

CommandKit currently handles this by querying `go env GOHOSTOS` and
`go env GOHOSTARCH`, then using those values when building its native ReleaseKit
executable. Its `TestReleaseLauncherDelegatesPublication` test supplies foreign
target variables and checks native bootstrap behavior together with argument
and exit-status forwarding. Consumer evidence is in CommandKit's
`scripts/release` and `scripts/release_test.go` at local commit
`a74fcb20041cbccde93f9b9a1e3b24cb8dd131e7`.

Please incorporate this behavior and regression coverage into ReleaseKit's
maintained consumer launcher example so downstream projects can reuse the
recipe and rely on upstream tests for its generic bootstrap mechanics.

## Observed failure

Reviewed ReleaseKit v0.8.0, commit
`23203f235cc414c4ffe0fd3941030eb0c9f9943f`. The
[multi-module launcher](../../examples/multi-module/release.sh) invokes
`go tool` without normalizing the inherited target environment.

On Linux/amd64 with Go 1.26.8, from a prepared consumer module registering
`go.maximumdirect.net/releasekit/cmd/releasekit` at v0.8.0:

```sh
GOWORK=off GOTOOLCHAIN=local GOFLAGS=-mod=readonly \
  GOPROXY=off GONOPROXY=none GOSUMDB=off \
  GOOS=windows GOARCH=arm64 go tool releasekit version
```

The command built a Windows executable and failed to launch it with an
`exec format error`. Repeating the command with `GOOS=linux GOARCH=amd64`
succeeded and printed `releasekit v0.8.0`. These observations establish the
tool-execution failure; the complete upstream launcher was inspected rather
than executed in this reproduction. No publication was attempted.

## Requested change

Update the maintained launcher to select the native host target when preparing
and executing ReleaseKit, regardless of inherited application target variables.
Resolve the host through the selected Go toolchain rather than hard-coding a
platform. Scope this change to running the maintainer tool; preserve the
application targets selected through existing release profiles.

Retain the launcher's existing module/version selection, profile routing,
source-file preservation, workspace/toolchain settings, and child exit-status
behavior. Document the host-target handling in the
[consumer adoption guidance](../consumers/adoption.md) where appropriate.

Prefer a small change to the supported example and its tests. This request does
not require a new validation option, public bootstrap API, or test-helper
package. CommandKit's choice to select one tool version from its root module
remains consumer-owned; this request does not change ReleaseKit's example policy
of selecting the tool from the chosen module.

## Acceptance evidence

Extend the existing
[multi-module launcher tests](../../cmd/releasekit/multi_module_example_test.go)
with a controlled foreign-target environment. Demonstrate that:

1. The selected tool executes on the host despite foreign `GOOS` and `GOARCH`.
2. The selected module's tool version and publication arguments still reach the
   child, and child statuses 0, 1, 2, and 3 are preserved.
3. Source module files remain unchanged and existing bootstrap cleanup behavior
   is preserved.

Reuse existing coverage for unaffected behavior rather than adding a parallel
suite. A host-run test can use a synthetic local tool and needs no real release
or external service. Synthetic module downloads must use test-owned caches as
described in [the developer guide](../development.md#testing-synthetic-modules).

## Ownership and downstream follow-up

CommandKit's review found no locally maintained candidate validator that needs
to become a new ReleaseKit feature. Existing formatting, Markdown, and module
distribution options already cover their respective reusable checks; selecting
them as CommandKit release gates is a separate consumer decision.

ReleaseKit already owns publication-engine tests for annotated tags, exact
remote objects, nested tag prefixes, and endpoint preflight. CommandKit can
narrow its local publication exercise to its launcher and profile wiring
without upstreaming a duplicate engine test suite. Its selectors, product names,
publication endpoint, and release order remain local responsibilities.