Add agreed ConfigKit features to the v0.2.0 roadmap

docs/roadmap/v0.2.0.md

@@ -62,3 +62,135 @@ installed tool remain supported use cases.
 
 Completion should leave downstream maintainers with one ReleaseKit dependency
 update for this integration and a maintained template they can adopt directly.
+
+## 2. Select one base test invocation, including race testing
+
+### Rationale and current baseline
+
+ReleaseKit always runs its standard offline Go suite before additional product
+checks. ConfigKit selects race-enabled testing for its release validation.
+Expressing that selection as an additional check would execute the suite twice
+and leave the application coordinating shared validation mechanics.
+
+A small declarative selection lets consumers retain their chosen validation
+while ReleaseKit owns the procedure and runs the suite once.
+
+### Target end state
+
+The public Go API and profile support selecting race testing for the single
+base Go test invocation. With no selection, the current default applies.
+`Check` and `Publish`, including their CLI forms, use the same selection.
+
+ReleaseKit constructs the invocation and owns candidate capture, full-suite
+scope, offline execution, ordering, and failure reporting. Additional product
+checks remain available after shared validation. Selecting race testing reports
+unavailable prerequisites clearly and preserves the selected validation.
+
+### Work needed
+
+- Add compact validation options to the facade and profile, and carry them
+  through both candidate-check and publication paths.
+- Extend shared Go invocation handling to apply race selection to the base
+  suite while preserving its offline environment and native test behavior.
+- Update consumer guidance and verify default behavior, one selected suite run,
+  consistent API/CLI behavior, and propagation of validation failures.
+
+Completion should let ConfigKit select its race-enabled suite once and remove
+the corresponding consumer-owned test invocation.
+
+## 3. Offer a separate full vet pass
+
+### Rationale and current baseline
+
+ConfigKit selects a full `go vet` pass in addition to its test suite. ReleaseKit
+currently relies on test-time vet unless a consumer supplies an additional
+command. That leaves consumers coordinating vet coverage and repeated work.
+
+### Target end state
+
+A public API and profile option selects a separate full vet pass within shared
+candidate validation. ReleaseKit automatically omits test-time vet when that
+pass is selected. The base suite runs once, followed by the selected vet pass,
+with failures reported through the ordinary check and publication flow.
+
+The option preserves current defaults for consumers that leave it unset.
+ReleaseKit owns the offline command and its coordination with base testing.
+
+### Work needed
+
+- Add the full-vet selection to shared validation configuration and execution.
+- Coordinate the base test invocation with the separate pass so consumers
+  express the desired coverage once.
+- Document the selection and verify ordering, test-time vet omission, failure
+  handling, and unchanged default behavior through the shared validation path.
+
+Completion should replace ConfigKit's separate vet command and manual
+test-time vet setting with one declarative choice.
+
+## 4. Verify package compilation for selected targets
+
+### Rationale and current baseline
+
+ReleaseKit's existing build declaration selects executable artifacts and their
+delivery. ConfigKit is a source-only library that checks package compilation
+for Linux amd64 and arm64. Its current release script owns the cross-target
+build loop even though the underlying mechanics are shared across consumers.
+
+### Target end state
+
+The public API and profile can declare optional package-compilation targets
+independently of executable artifacts. ReleaseKit compiles the module's packages
+for those targets within candidate validation, after the selected test and vet
+work. `Check` and `Publish` share this behavior and report compilation failures
+through their existing outcomes.
+
+A source-only library retains page-only delivery. Package-compilation checks
+require no binary name, version smoke command, or artifact manifest. Successful
+compilation establishes build compatibility; execution on a target remains a
+separate concern. Consumers select targets for their support commitments.
+
+### Work needed
+
+- Add a package-compilation target declaration to validation configuration,
+  distinct from the existing artifact build specification.
+- Reuse internal Go environment and target handling for offline compilation,
+  replacing consumer-owned loops and preserving one base test execution.
+- Document the distinction between compatibility checks and deliverables, and
+  verify selected-target compilation, failure reporting, and unchanged
+  source-only delivery behavior.
+
+Completion should let ConfigKit declare its two Linux targets and remove its
+release-specific compilation loop.
+
+## 5. Check an optional expected publication endpoint
+
+### Rationale and current baseline
+
+ReleaseKit resolves and captures the selected remote's push endpoint and
+rechecks it during publication. ConfigKit additionally declares an expected
+authoritative destination in its release script. Retaining that expectation
+outside ReleaseKit would duplicate destination-resolution work.
+
+### Target end state
+
+An optional public API and profile setting declares the expected publication
+destination. `Publish` compares it with the resolved push endpoint before
+candidate validation and publication. A mismatch produces a clear failure.
+The existing captured-endpoint, recheck, and recovery machinery continues to
+govern the operation.
+
+The expectation applies to the publication destination. Fetch configuration
+retains its existing semantics, and `Check` retains its local-only behavior.
+Consumers that omit the expectation keep the current remote-selection model.
+
+### Work needed
+
+- Add the optional expectation to the facade and profile and compare it at
+  the existing publication endpoint-resolution boundary.
+- Reuse captured-endpoint handling and define the destination-comparison
+  semantics in GoDoc and consumer guidance.
+- Verify matching, mismatching, and omitted expectations, including resolved
+  Git URL behavior, while preserving existing recheck and recovery coverage.
+
+Completion should let consumers declare the intended push destination without
+maintaining their own publication preflight logic.