Run consumer release commands through Go tools

docs/consumers/adoption.md

@@ -34,8 +34,21 @@ Go minimum. See the
 [Go tool dependency reference](https://go.dev/ref/mod#go-mod-file-tool).
 
 Run `go tool releasekit` from within the consumer module to use its selected
-version. Follow the [CLI contract](../cli.md) for commands and exit statuses,
-and the [configuration reference](../config.md) for the release profile.
+version. Go builds and caches the executable and preserves its exit status.
+A launcher invoked from that module can forward commands directly:
+
+```sh
+#!/bin/sh
+exec go tool releasekit "$@"
+```
+
+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.
+
+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
+vendor selection.
 
 ## Go API consumers
 
@@ -89,9 +102,10 @@ Go module identity. The Go consumer minimum remains 1.26.0.
 ## CI adoption
 
 The maintained [consumer tag-delivery workflow](delivery.md#woodpecker-tag-workflows)
-supports both tool and ordinary package dependencies. It builds ReleaseKit from
-the tagged consumer's module selection, so the committed module files also
-govern CI delivery and retries. Registering the CLI as a tool is sufficient for
+supports both tool and ordinary package dependencies. It runs `go tool releasekit`
+with temporary module metadata derived from the tagged consumer's module
+selection, so the committed module files also govern CI delivery and retries.
+Registering the CLI as a tool is sufficient for
 consumers that use ReleaseKit only for maintainer commands.
 
 Upgrade the module-selected tool and workflow together. For a tag created before

docs/consumers/delivery.md

@@ -293,11 +293,13 @@ identify an annotated tag object or a commit. The template requires the resolved
 commits to match, checks out that commit detached, and confirms the source tree
 is clean. It then copies the tagged `go.mod` and any `go.sum` to a temporary
 directory outside the checkout. `go list -m` confirms that the module selects
-ReleaseKit; Go uses
-an alternate `-modfile` to prepare dependencies and build the selected
-`cmd/releasekit` package without changing the tagged module files. The template
-invokes that executable with `CI_WORKSPACE`, the resolved event commit, and
-`CI_COMMIT_TAG`. A cleanup trap removes the temporary metadata and executable.
+ReleaseKit. The template adds its CLI tool declaration to that temporary copy
+and prepares tool dependencies with `go list -deps`. It then uses
+`go tool -modfile=... releasekit` to build, cache, and run the selected tool with
+`CI_WORKSPACE`, the resolved event commit, and `CI_COMMIT_TAG`. The tagged module
+files stay unchanged, including for consumers with an ordinary package
+dependency. A cleanup trap removes the temporary metadata; Go manages the
+cached executable. The command preserves the tool's exit status.
 
 Tool bootstrap and application artifact preparation are separate. The bootstrap
 resolves and builds ReleaseKit from the tagged consumer's module configuration.