Plan the pipeline role composition foundation

docs/roadmap/mvp.md

@@ -108,6 +108,15 @@ role will manage the native configuration needed to connect to it.
   cross-application configuration, D&D campaign deployment, prompt-library
   deployment, operator access, the pipeline-wide secret-delivery policy, and
   end-to-end validation.
+- Unlike the generic standalone roles, the pipeline role deliberately supplies
+  opinionated, D&D-specific defaults for all five applications. It expresses
+  that policy through the standalone roles' existing field-specific variables,
+  keeps those values overrideable through ordinary inventory precedence, and
+  does not duplicate the application roles' templates or convergence logic.
+- Pipeline defaults represent policy deliberately selected for the D&D suite;
+  they do not mirror every upstream application default. Settings for which the
+  suite has selected no policy remain under the application or caller's
+  control.
 - The pipeline role uses the Git-hosted standalone application roles as
   dependencies. This is an intentional choice for the controlled project
   environment despite the additional repository and dependency structure and
@@ -116,6 +125,18 @@ role will manage the native configuration needed to connect to it.
   that installs both the collection and its standalone role dependencies; a
   plain collection installation is not assumed to resolve arbitrary Git role
   dependencies by itself.
+- The standalone application roles use the canonical installed names
+  `rakestraw.audita`, `rakestraw.narratio`, `rakestraw.notarius`,
+  `rakestraw.seriatim`, and `rakestraw.scriptorium`.
+- The pipeline role supplies a root `requirements.yml` bootstrap manifest for
+  those Git-hosted roles and a collection requirements manifest for shared
+  collection dependencies. During active development, the Git roles are
+  pinned to reviewed commits; released manifests replace those commits with
+  immutable role release tags.
+- 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
+  role variable behind a parallel alias.
 
 This design keeps repository ownership and change blast radius aligned with
 the independently released applications while retaining a single opinionated
@@ -267,10 +288,10 @@ remain to be designed.
 
 The following areas require investigation and decisions before implementation:
 
-- Standalone role Galaxy names and the dependency-manifest/bootstrap layout
 - The mechanism used to incorporate the independently developed pipeline role
   into collection releases
 - The prompt-library destination and its integration with Scriptorium
+- The campaign repository's checkout revision and deployment/update policy
 - Secret injection and storage
 - Suite-level operator-selection variables
 - Upgrade, downgrade, and removal behavior