# 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](commandkit-feature-request.md) 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](../../examples/multi-module/release.sh)
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](../consumers/adoption.md) included a minimal `go tool`
launcher. The [single-module CI template](../../examples/woodpecker/tag-delivery.yml)
and [multi-module CI template](../../examples/multi-module/woodpecker.yml) also
invoked the selected tool without explicit host-target normalization.

The [maintainer launcher](../../scripts/release),
[source delivery template](../../examples/woodpecker/releasekit-source-delivery.yml),
and [manual delivery retry](../release.md) built and executed the tool with the
same inherited-target assumption. The CLI's [generated recovery command](../../cmd/releasekit/main.go)
inherited the target from the shell where it ran, and [recovery dependency
preparation](../../internal/gotool/recovery.go) also inherited the target.

Existing [launcher tests](../../cmd/releasekit/multi_module_example_test.go)
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](implementation.md) 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.