Record the forthcoming module release support

docs/roadmap/modules.md

@@ -1,7 +1,8 @@
 # Optional integration modules
 
 Status: module boundary accepted in ADR 0010; implementation planning remains
-in progress and no module extraction has begun.
+in progress and no module extraction has begun. The next minor ReleaseKit
+release will support individual module releases; CommandKit adoption is pending.
 
 ## Purpose and authority
 
@@ -146,6 +147,45 @@ shapes merely because they already exist.
   when changes span modules; independent versions do not imply an exhaustive
   compatibility matrix.
 
+### Selected multi-module release approach
+
+Adopt the next minor ReleaseKit version with module-release support. This is a
+planned tooling upgrade from the current v0.3.0 baseline, not an implemented
+CommandKit capability. Use ReleaseKit's public contracts for checking and
+publishing one explicitly selected module per invocation; do not build a separate
+CommandKit publication engine or temporary compatibility path.
+
+Use one shared launcher with small per-module profiles. Each profile selects its
+repository-relative module directory and product identity; each invocation
+supplies that module's independently selected semantic version. ReleaseKit owns
+module-tag derivation, selected-module validation, repository publication guards,
+and publication outcomes. Root releases use unprefixed tags. Nested releases use
+their Go module-subdirectory prefixes, and notes belong at
+`<module-directory>/docs/releases/<version>.md`. Source and licensing links use
+the complete Git tag, while note titles identify the product and semantic version.
+
+Run the selected module's standard suite once with workspace mode disabled and
+prepared dependencies. Repository cleanliness, branch, candidate commit, and
+endpoint guards remain repository-wide. A root-module release does not implicitly
+validate independently released nested modules; composition checks are selected
+deliberately where needed. Keep successful source-tag publication as completion,
+without CI, hosted delivery, proxy-availability, or installation gates.
+
+CommandKit's preferred shared file inputs are repository-root `COPYRIGHT`,
+`LICENSE`, and `docs/oss/attribution.md`, when present, rather than the entire
+root `docs/` tree. Use the forthcoming configurable list or its defaults as
+documented by ReleaseKit. Shared inputs affect enabled file checks, not Go suite
+scope; resolving references does not add surrounding directories to the inputs.
+
+Keep module selection and profile lookup repository-relative, module-owned
+validation settings and product-command execution module-relative, and diagnostic
+paths repository-relative. Use the provided repository context for shared scripts.
+Confirm exact profile fields, command syntax, context exposure, and shared-file
+selection semantics against the released public documentation during adoption.
+These are integration tasks, not remaining choices between publication engines.
+Nested-module artifact builds, hosted delivery, and batch publication are not
+needed for CommandKit's source-only releases.
+
 ## Work sequence
 
 ### 1. Align policy and settle implementation boundaries
@@ -235,10 +275,14 @@ exhaustive matrix of historical dependency versions.
   migration guide. Prepare initial module versions and notes under the
   [release policy](../policy/release.md); unpublished prototype API changes do
   not require a compatibility release or a version bump solely for relocation.
-- Adapt release profiles, module discovery, validation, note locations, version
+- Upgrade the module-selected ReleaseKit tool to the next minor release providing
-  reporting, and publication commands to the selected release model. Verify
+  module-release support. Adopt its released public API and CLI/profile contracts
-  ReleaseKit's supported capabilities before choosing the mechanics; the current
+  through the shared launcher and per-module profiles described above. Update
-  single-module profile is not evidence of multi-module support.
+  launcher checks, validation context, version/tag reporting, and recovery guidance
+  for selected-module publication; do not duplicate ReleaseKit-owned guards.
+- Align the release policy and procedure with module-local notes, independent
+  versions, full-tag identity, and selected-module validation. Confirm the
+  documented shared-file defaults or configure the selected files explicitly.
 - For nested modules, use Go's module-subdirectory tag prefixes and make
   release-note paths and immutable links unambiguous. Review licensing and
   attribution visibility in each distributed module under the
@@ -282,21 +326,3 @@ redundant private flags and checks rather than reproducing them publicly.
 represent ownership and collision handling if command groups cannot adequately
 express those responsibilities. It adds a lasting abstraction, so select it only
 for a demonstrated consumer or core responsibility, not to imitate current state.
-
-### Multi-module release mechanics
-
-Independent versioning is selected. Exact release tooling and per-module note
-locations still require investigation of ReleaseKit's supported capabilities.
-This is release-workflow design work, not a reason to retain the combined module.
-
-**Recommendation:** reuse shared publication machinery with explicit module
-selection, module-specific versions and notes, and the appropriate tag prefixes.
-Validate the selected candidate and publish in dependency order as required by
-actual module requirements. Keep the successful source-publication completion
-model and avoid duplicate validation of an unchanged final candidate.
-
-**Alternative:** maintain separate per-module release entry points or profiles
-using ReleaseKit's supported mechanisms. This may be simpler if ReleaseKit is
-intrinsically single-module, but risks duplicated guards and inconsistent
-procedures. Verify its capabilities before selecting exact commands; neither
-approach requires matching module versions or a new general release framework.