# Roadmap: host-native consumer launchers

Status: planned; implementation pending.

## 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
and describes work to be implemented after this documentation pass.

## Current baseline

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)
selects a module and profile, copies module metadata into temporary storage,
prepares the selected ReleaseKit dependency, and invokes `go tool releasekit`.
It sets `GOWORK=off` and `GOTOOLCHAIN=local`, but inherits `GOOS` and `GOARCH`.
Target-dependent dependency inspection therefore also sees the inherited target.

The [adoption guide](../consumers/adoption.md) includes 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
invoke 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) build and execute the tool with the
same inherited-target assumption. The CLI's [generated recovery command](../../cmd/releasekit/main.go)
inherits the target from the shell where it is run, and [recovery dependency
preparation](../../internal/gotool/recovery.go) also inherits the target.

Existing [launcher tests](../../cmd/releasekit/multi_module_example_test.go)
exercise synthetic module selection, publication arguments, child statuses
0 through 3, and preservation of source module metadata. Those fixtures provide
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.