Preserve simple consumers and resolve module identity once

docs/roadmap/module-releases.md

@@ -81,8 +81,11 @@ and complete tag are available throughout candidate handling and public evidence
 
 **Work:** Add an optional repository-relative module selection to the public
 request and profile, with root defaults. Resolve it against the captured
-repository and committed module declaration. Derive tags using Go's standard
+repository and committed module declaration once at the operation entry point.
-module conventions, including major-version directories: a `/v2` module stored
+Pass the resolved identity through the operation's validation, publication,
+build, and delivery collaborators. Standalone operations use the same resolution
+logic. Derive tags using Go's standard module conventions, including
+major-version directories: a `/v2` module stored
 at `integrations/ckconfig/v2` uses `integrations/ckconfig/v2.0.0` for `v2.0.0`.
 The same module stored at `integrations/ckconfig` uses that complete tag too.
 Support both physical layouts and distinguish the module directory from its
@@ -178,6 +181,8 @@ verified tagged checkout. Resolve the physical module directory and profile
 before tool bootstrap, and keep the selection consistent with the derived tag.
 Verify the event commit before resolving that mapping and use the tagged
 source's selected module files on retries.
+For ordinary root tags, use the root profile and module bootstrap defaults.
+Consumers using that pattern supply no module/profile mapping declaration.
 Preserve temporary bootstrap metadata and existing credential handling. Cover
 major-version directory layouts without assuming that trimming the tag always
 identifies the physical module directory. Include page-only and binary examples.
@@ -199,6 +204,9 @@ showing root and integration profiles and a small shared launcher. Show dependen
 preparation before offline validation and sequential sibling releases when a
 dependency version must be published first. Keep product checks focused on
 consumer assertions instead of repeating the standard suite.
+Preserve the [simple root-module experience](#simple-single-module-experience),
+including a small
+profile, launcher, and CI workflow with no additional required declarations.
 
 ### 7. Verify and document the complete behavior
 
@@ -226,6 +234,9 @@ nested-module build/version-injection, new-format receipt ownership and cutover,
 Gitea page/asset, and CI tag/profile/tool-selection coverage. Use local HTTP servers for delivery and
 isolated synthetic module proxies for bootstrap tests. Verify that retries use
 the original module selection and full tag after the default branch changes.
+Verify a representative simple root-module API call, profile, launcher, and CI
+workflow using the new interface's defaults. Confirm that routine use adds no
+required configuration fields, mapping declarations, or consumer decisions.
 
 Update GoDoc, CLI/configuration references, check/publication/build/delivery guides,
 adoption examples, CI templates, and recovery guidance together. Supply migration
@@ -241,6 +252,31 @@ examples. Synthetic dependency fixtures use isolated module caches.
 
 ## Resolved decisions
 
+### Resolve identity once
+
+Each ReleaseKit operation resolves repository directory, selected module
+directory and declaration, semantic version, and complete tag once through
+shared resolution logic. Pass that identity through candidate handling,
+validation, callbacks, publication, builds, receipts, delivery, and evidence.
+Subsystems consume the resolved module and tag. Repository-state, tagged-source,
+and artifact verification continue against that identity through their existing
+guards.
+
+### Simple single-module experience
+
+Ordinary root-module consumers use the new interface's defaults: omitted module
+selection means the repository root, the complete tag equals the semantic
+version, notes use `docs/releases/<version>.md`, and validation and builds run
+from the root module. Shared-file defaults apply with input deduplication.
+Root-tag CI uses the ordinary profile and repository-root tool bootstrap.
+
+Routine use requires no additional configuration fields, module mapping
+declarations, or recurring consumer decisions. A representative root-module
+profile, launcher, and CI workflow remain equally small after migration.
+Consumers supply their existing product facts through the new interface.
+One-time API updates and receipt regeneration belong in the next release's
+migration guidance under the clean-cutover decision below.
+
 ### Module boundaries
 
 Use committed nested `go.mod` locations as module boundaries for ordinary source