Plan the D&D collection assembly

docs/roadmap/mvp.md

@@ -106,6 +106,13 @@ role will manage the native configuration needed to connect to it.
 - The collection bundles and exposes the independently developed suite-level
   role as `rakestraw.dnd.pipeline`, providing one opinionated interface for
   consumers.
+- The collection incorporates the pipeline role at `roles/pipeline` as a
+  squashed Git subtree. The standalone pipeline repository remains
+  authoritative; maintainers change and validate the role there, then import
+  a reviewed commit into the collection rather than editing the subtree copy.
+- The subtree makes the collection artifact self-contained for its bundled
+  role without requiring submodule initialization, symbolic links, sibling
+  repositories, or custom synchronization tooling.
 - The pipeline role owns compatible application-version selection,
   cross-application configuration, D&D campaign deployment, prompt-library
   deployment, operator access, the pipeline-wide secret-delivery policy, and
@@ -135,6 +142,10 @@ role will manage the native configuration needed to connect to it.
   collection dependencies. During active development, the Git roles are
   pinned to reviewed commits; released manifests replace those commits with
   immutable role release tags.
+- The collection supplies one consumer-facing root `requirements.yml` that
+  combines those same Git-hosted role pins with the shared collection
+  dependencies. Its Galaxy metadata separately declares the native collection
+  dependencies that Ansible can resolve while installing a collection.
 - The pipeline role composes the five roles through ordinary Ansible role
   dependency metadata. It exposes suite-prefixed variables for the small set
   of values the suite must coordinate, and does not duplicate every downstream
@@ -179,6 +190,11 @@ application-role releases in one source repository.
 - Collection integration tests must install and exercise the same pinned role
   combination delivered to consumers, starting from an environment in which
   the dependencies are not already installed.
+- Collection integration tests build and install the collection artifact into
+  isolated Ansible paths, resolve `rakestraw.dnd.pipeline`, validate one
+  representative assembled deployment through native application interfaces,
+  and confirm immediate convergence. Detailed pipeline feature matrices remain
+  the standalone pipeline role's testing responsibility.
 - Updating one application role in the suite requires updating its pinned
   version in the collection, validating the assembled suite, and releasing a
   new collection version. Unrelated application-role repositories remain
@@ -396,9 +412,5 @@ managed host. The prompt-library checkout retains its upstream `prompts/` and
 
 The following areas require investigation and decisions before implementation:
 
-- The mechanism used to incorporate the independently developed pipeline role
-  into collection releases
 - Optional suite-level operator-selection and group-membership management
 - Upgrade, downgrade, and removal behavior
-- Collection bootstrap and end-to-end validation details beyond the locked
-  dependency and testing policies above