Record host launcher integration findings

docs/roadmap/remediation.md

@@ -78,3 +78,71 @@ recovery commands. Disposable smoke probes also verified the maintainer
 launcher forwards the child status and the manual retry preserves the calling
 shell's target variables. The review made no changes to production code or
 tests.
+
+## Integration audit
+
+The audit below examines how the new bootstrap paths interact with existing
+invocation recipes, product checks, and publication recovery.
+
+### Use the external Go executable in printed recovery commands
+
+**Evidence:** Before host normalization, the
+[command formatter](../../cmd/releasekit/main.go) emitted
+`env GOWORK=off GOTOOLCHAIN=local go ...`, which resolves Go through `PATH`.
+[Recovery preparation](../../internal/gotool/recovery.go) still executes an
+external Go command. The new printed command uses bare `go` for both host
+queries and the later tool invocation, so a function named `go` in the
+operator's shell can intercept it. In a local rejected-push fixture, the
+actual printed command reconciled the saved record in an ordinary shell.
+With `go() { GOOS=windows GOARCH=arm64 command go "$@"; }` defined, the same
+command failed with an exec format error. The function overrode the final
+assignments even though the host queries reported the correct host. In this
+case both paths exited with status 1, but only one produced a reconciliation
+result.
+
+**Fix:** Restore external command lookup for the host queries and tool
+invocation, for example by using `env go -C ...` throughout the subshell.
+Keep selection through the operator's current `PATH`, including executable
+shims, and keep the exact record and exit status. Exercise a generated
+handoff from a POSIX shell that defines a cross-build Go function; assert
+the reconciliation result as well as the status.
+
+### Explain how host normalization affects configured product checks
+
+**Evidence:** The updated launchers export `GOOS` and `GOARCH` to the
+ReleaseKit process. Existing [configured checks](../config.md) inherit that
+process environment unless their `env` maps override it;
+[`RunChecks`](../../cmd/releasekit/internal/cli/config.go) adds the configured
+and ReleaseKit-owned values to the child. This differs from built-in
+application compilation, which chooses its target from the profile. A
+disposable consumer's check using shell defaults for an application target
+passed with the previous direct `go tool` invocation and no target
+variables, then failed through the updated launcher because it observed
+`linux/amd64`. Adding explicit `GOOS=windows` and `GOARCH=arm64` to that
+check's `env` restored its behavior.
+
+**Fix:** In the launcher adoption guidance, explain that host variables
+reach configured child checks and that checks which need an application
+target should set it explicitly in their existing `env` map or command.
+Link to the configuration contract. Keep the current environment overlay
+semantics and the separate profile selection for built-in builds.
+
+### Align direct source and standalone CI recipes with the launcher guidance
+
+**Evidence:** The [README quick start](../../README.md) and
+[CLI reference](../cli.md) still recommend bare `go run ./cmd/releasekit`
+for source invocation. The [consumer delivery guide](../consumers/delivery.md#woodpecker-tag-workflows)
+also recommends bare `go install ...@PIN` for consumers who install the
+delivery executable separately. These older recipes remain target-sensitive
+alongside the new host-native launchers. On Linux/amd64 with inherited
+`GOOS=windows GOARCH=arm64`, the README's actual `version` command failed
+with an exec format error. A versioned install from a disposable local
+module proxy failed under the same variables with `GOBIN` set; the native
+install succeeded and its binary ran.
+
+**Fix:** Link these recipes to the host-selection instructions and make the
+native target requirement explicit at the source invocation and at the
+standalone installation step. Use the existing recipe where a copyable
+command is useful. Keep the selected version, install location, and
+`go run` exit-status caveat. An already installed native binary does not
+need a new bootstrap step.