releasekit/docs/roadmap/commandkit-feature-request.md

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 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:

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

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.