Accept the module-selected tooling ADR

docs/adr/0004-module-selected-tooling.md

@@ -0,0 +1,68 @@
+# ADR 0004: Select release tooling from the released application's module configuration
+
+## Status
+
+Accepted.
+
+## Date
+
+2026-10-07
+
+## Context
+
+Applications can declare ReleaseKit as a Go module dependency and use that
+selection to build their local release tool. A separate CI version pin creates
+a second declaration that maintainers must coordinate during upgrades. The two
+paths can then use different ReleaseKit versions for the same release.
+
+Hosted delivery runs after source publication and may be retried for an older
+release. It needs a stable source for tool-version selection associated with
+that release. [ADR 0002](0002-routine-releases.md) prioritizes reducing repeated
+configuration and routine release decisions.
+
+## Decision
+
+For applications that declare ReleaseKit as a module dependency, the standard
+integration selects the tool through the application's module configuration.
+Local publication uses the candidate's module configuration. CI delivery uses
+the released source's module configuration. Both paths follow the same
+module-based selection approach.
+
+CI verifies the triggering tag and commit and checks out that source before
+resolving and building the release tool. Delivery retries use the same released
+source for tool selection. The application maintains its ReleaseKit dependency
+as the shared version declaration for these operations.
+
+Tool bootstrap and dependency preparation remain separate from offline
+validation and builds. The CI integration supplies the event, environment, and
+credentials; the application profile supplies product and delivery settings.
+Source publication and hosted delivery retain their separate outcomes.
+
+Consumers using a separately installed tool and ReleaseKit's own source
+bootstrap remain supported use cases. Adoption guidance describes the
+appropriate bootstrap for each integration.
+
+## Alternatives considered
+
+- An independent CI version pin makes tool selection explicit in the workflow
+  and requires maintainers to coordinate it with the application's dependency.
+- Selecting from the current default branch follows ongoing dependency
+  updates and allows delivery retries for an older release to select a newer
+  tool.
+
+## Consequences
+
+Applications using the standard module-based integration update one dependency
+declaration for local publication and CI delivery. Tool selection follows the
+released source when delivery is retried, preserving the release's dependency
+choice as the application evolves.
+
+CI must establish the released checkout before tool bootstrap. Its environment
+must provide a compatible Go toolchain and access to the dependencies needed
+to build the selected tool. Retrying delivery for an older release retains
+those preparation requirements.
+
+Maintained templates and adoption guidance must preserve this selection order.
+Verification should exercise a dependency-version change and selection from
+the triggering release's source. Exact commands and bootstrap mechanics belong
+in the maintained integration guidance and examples.