Plan host native release launchers

docs/roadmap/commandkit-feature-request.md

@@ -0,0 +1,93 @@
+# 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.