Resolve prebuilt assets from the selected module

docs/roadmap/next-release-notes.md

@@ -46,6 +46,10 @@ version, complete tag, source commit, normalized build settings, and artifact
 declarations. Older and unversioned receipts are rejected; rebuild with the
 updated `build` command before using `deliver --assets DIR`.
 
+Relative `build --output DIR` and `deliver --assets DIR` paths both use the
+selected module directory. Nested-module consumers can use the same relative
+directory for building and retrying delivery; absolute directories remain usable.
+
 The maintained [multi-module example](../../examples/multi-module/) shares a
 four-column `release-modules.tsv` and POSIX selector between its local launcher
 and mapped Woodpecker workflow. The workflow verifies and detaches the triggering

docs/roadmap/remediation.md

@@ -99,7 +99,14 @@ later partial-artifact behavior intact.
 
 ## Issue 3: Use the module path base for relative prebuilt assets (P2)
 
-Status: open. Category: incomplete module path adoption.
+Status: complete. Category: incomplete module path adoption.
+
+**Completion:** Build output and CLI prebuilt assets share the selected module's
+directory resolver. CLI and pending migration guidance describe the common base.
+Local hosted regression tests verify root and nested relative build/delivery
+pairs, absolute output, module binding, and rejection of changed artifact content
+before hosted requests. Existing receipt/content checks and nested build cases
+pass offline.
 
 **Evidence:** [CLI prebuilt delivery](../../cmd/releasekit/main.go) joins a
 relative `--assets` directory to `invocation.Repository`. Builds now resolve