Start the v0.2.0 roadmap

docs/roadmap/v0.2.0.md

@@ -0,0 +1,64 @@
+# ReleaseKit v0.2.0 roadmap
+
+Status: Draft scope for the next release.
+
+This roadmap catalogs improvements to ReleaseKit v0.1.0. Each item records its
+rationale, target state, and scope of work. A staged implementation plan will
+follow once the release scope is finalized.
+
+The priorities in [ADR 0002](../adr/0002-routine-releases.md) guide this work:
+minimize application-owned release code, duplicated mechanics, and routine
+developer decisions through a standard, minimal API.
+
+## 1. Use the application's module-selected ReleaseKit version in CI
+
+### Rationale and current baseline
+
+The maintained [CI template](../../examples/woodpecker/tag-delivery.yml) selects
+ReleaseKit through a separate `RELEASEKIT_VERSION` value and invokes its command
+with an explicit `@version`. The [adoption guidance](../consumers/delivery.md#woodpecker-tag-workflows)
+instructs consumers to maintain that workflow pin.
+
+Audita demonstrates the resulting duplication: its local release wrapper builds
+ReleaseKit using the application's module dependencies, while CI independently
+selects ReleaseKit v0.1.0. A dependency upgrade can leave CI using an older tool.
+Maintainers must remember to coordinate both declarations.
+
+Using the application's module-selected version for both paths gives upgrades
+one dependency declaration and keeps local publication and CI delivery aligned.
+
+### Target end state
+
+For applications that declare ReleaseKit as a module dependency, the standard
+CI integration uses the ReleaseKit version selected by the released source's
+module configuration. The workflow verifies the triggering tag and commit and
+checks out that source before resolving and building the release tool.
+
+Local publication and CI delivery use the same module-based selection approach.
+Updating the application's ReleaseKit dependency updates both paths. The
+consumer workflow supplies the CI event, environment, and credentials; the
+application profile continues to supply product and delivery settings.
+
+Tool bootstrap and dependency preparation remain distinct from offline
+validation and builds. Source publication and hosted delivery retain separate
+outcomes. ReleaseKit's own source bootstrap and consumers using a separately
+installed tool remain supported use cases.
+
+### Work needed
+
+- Revise the maintained CI template to establish the tagged checkout before
+  selecting and building the module's ReleaseKit command. Remove the separate
+  version setting from this module-based integration and keep bootstrap logic
+  small and reusable.
+- Update adoption and upgrade guidance to explain module-based selection,
+  compatible Go environments, dependency preparation, and migration from the
+  existing workflow pin. Explain the applicable bootstrap for consumers that
+  use a separately installed tool.
+- Adapt workflow verification to exercise tool selection from the tagged
+  module configuration, including a dependency-version change, while preserving
+  tag/commit checks and existing source-only and binary delivery behavior.
+- Apply the revised integration to Audita as the first consumer migration and
+  confirm that its local wrapper and CI use the same module-selected tool.
+
+Completion should leave downstream maintainers with one ReleaseKit dependency
+update for this integration and a maintained template they can adopt directly.