Explain target variables in configured checks

docs/consumers/adoption.md

@@ -49,7 +49,12 @@ selected module to verify registration. It preserves the consumer's workspace
 and toolchain settings while selecting the host for the executable.
 For a launcher callable from other directories, first change to its consumer
 module directory. Follow the [CLI contract](../cli.md) for commands and exit
-statuses, and the [configuration reference](../config.md) for the release profile.
+statuses.
+
+Configured product checks inherit the launcher's host `GOOS` and `GOARCH`.
+If a check needs an application target, set it in that check's `env` map or
+command. The [configuration reference](../config.md) describes
+check environments and the separate target selection for built-in builds.
 
 For consumers using vendoring, register the CLI before running `go mod vendor`
 so the vendor tree includes its dependencies. `go tool` follows Go's normal

docs/roadmap/remediation.md

@@ -119,6 +119,8 @@ the reconciliation result as well as the status.
 
 ### Explain how host normalization affects configured product checks
 
+**Completed.** The adoption guide explains inherited host variables and points checks that need an application target to the existing environment overlay.
+
 **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;