releasekit/docs/roadmap/host-native-launchers.md

Roadmap: host-native consumer launchers

Status: implemented.

Purpose

Make ReleaseKit's maintained launchers and generated recovery commands prepare and execute the release tool for the maintainer's host when inherited GOOS and GOARCH select a different application target. Centralize the recipe and regression coverage so consumers can retain small launchers and product-specific wiring tests.

This is a launcher correctness improvement. It requires no public bootstrap API, validation option, or test-helper package. This roadmap selects no release version.

Baseline before implementation

The CommandKit feature request describes a prepared v0.8.0 tool invocation on Linux/amd64 with GOOS=windows GOARCH=arm64 that built a Windows executable and failed with an exec format error. CommandKit's local launcher already selects the Go host target before building the release executable. The report's reproduction exercised tool execution without attempting publication.

The maintained multi-module launcher already selected a module and profile, copied module metadata into temporary storage, prepared the selected ReleaseKit dependency, and invoked go tool releasekit. It set GOWORK=off and GOTOOLCHAIN=local while passing inherited GOOS and GOARCH to dependency inspection and tool execution.

The adoption guide included a minimal go tool launcher. The single-module CI template and multi-module CI template also invoked the selected tool without explicit host-target normalization.

The maintainer launcher, source delivery template, and manual delivery retry built and executed the tool with the same inherited-target assumption. The CLI's generated recovery command inherited the target from the shell where it ran, and recovery dependency preparation also inherited the target.

Existing launcher tests exercised synthetic module selection, publication arguments, child statuses 0 through 3, and preservation of source module metadata. Those fixtures provided the starting point for foreign-target regression coverage.

Targeted end state

Maintained launchers and module-based recovery use GOHOSTOS and GOHOSTARCH from the selected Go toolchain as GOOS and GOARCH while preparing and running ReleaseKit. The tool executes on that host even when the caller was working with a foreign application target. Normalize before target-dependent dependency inspection as well as tool execution. Generated recovery commands select the host when run, using the Go toolchain that will execute the command.

Application targets continue to come from existing release profiles. The launcher's host selection preserves module-selected tool versions, profile and argument routing, source-file preservation, temporary-file cleanup, existing workspace/toolchain settings, and child exit statuses. Consumers retain their own selectors, products, endpoints, and release order.

The scope is inherited GOOS and GOARCH handling for the maintainer tool. It does not establish a hermetic environment, broaden hardware or platform support, or add release gates. Existing Go/toolchain failures remain ordinary bootstrap failures. No new fallback toolchain or download policy is introduced.

The implementation plan defines the work to reach this state.

Completion evidence

Completion requires host selection before dependency inspection and successful host execution under a foreign target, including for generated recovery commands. Preserve selected tool identity and arguments, child-status forwarding, unchanged source metadata, and existing cleanup behavior. The maintained local and CI recipes and adoption guidance must use the same host-selection approach. Application build targets must retain their existing profile-driven behavior.