Plan the standalone Narratio role

docs/roadmap/mvp.md

@@ -176,18 +176,48 @@ application-role releases in one source repository.
 
 ### Accounts, ownership, and operator access
 
-- The roles create a dedicated `narratio` user and `narratio` group as needed.
+- The standalone Narratio role creates a dedicated system `narratio` user and
+  `narratio` group. The account uses `/var/lib/narratio` as its default home
+  and has a non-login shell.
 - The `narratio` account owns Narratio's writable runtime directories.
 - Application source trees and installed binaries are owned by `root` and are
   not writable by operators or the runtime account.
 - Ordinary human users run `narratio run` and other Narratio commands directly.
 - Those operators receive the required access by membership in the `narratio`
   group.
-- Managed configuration should be owned by `root`, readable by the `narratio`
-  group where needed, and remain under Ansible control rather than being
-  routinely edited by operators on the host.
-- Shared runtime directories must grant the `narratio` group the write access
-  needed for direct operator invocations.
+- Narratio's configuration directory is owned by `root:narratio` with mode
+  `0750`, and its pipeline file is owned by `root:narratio` with mode `0640`.
+  Configuration remains under Ansible control rather than being routinely
+  edited by operators on the host.
+- The Narratio workspace, spool, and cache roots are owned by
+  `narratio:narratio` with mode `2775`, preserving the group on created content
+  and granting the shared write access needed for direct operator invocations.
+- The campaign registry root is owned by `root:narratio` with mode `0755`.
+  Its content is readable by operators but is populated by the suite role and
+  is not edited directly on the managed host.
+- The standalone role does not select human operators. The suite role owns the
+  operator list and adds those accounts to the `narratio` group.
+
+### Narratio configuration
+
+- The standalone Narratio role manages the canonical root pipeline document
+  at `/usr/local/etc/narratio/pipeline.yml` through a field-specific public
+  variable interface.
+- The role requires a caller-supplied WhisperX transcription URL because the
+  field is required by Narratio and has no valid universal deployment value.
+- Filesystem roots managed by the role have concrete defaults and are rendered
+  so application configuration agrees with managed host state. Other optional
+  application fields default to null, are omitted from the rendered document,
+  and inherit Narratio's built-in defaults.
+- Native open-ended collections such as publish outputs, Notarius references
+  and outputs, and Scriptorium artifacts and artifact families are exposed as
+  complete fields. Callers may compose their final values in inventory; the
+  role does not add merge or precedence behavior.
+- The root document may name ConfigKit imports, but the standalone role does
+  not manage imported fragments or profile overlays. A caller that selects
+  them owns their deployment.
+- Credential fields contain environment-variable names, never secret values.
+  Secret delivery remains suite-level policy.
 
 ### Execution model
 
@@ -237,16 +267,12 @@ remain to be designed.
 
 The following areas require investigation and decisions before implementation:
 
-- Exact application repository URLs, default release tags, build commands,
-  version-injection flags, and validation commands
 - Standalone role Galaxy names and the dependency-manifest/bootstrap layout
 - The mechanism used to incorporate the independently developed pipeline role
   into collection releases
-- Narratio's application configuration contract and runtime filesystem
-  requirements
 - The prompt-library destination and its integration with Scriptorium
 - Secret injection and storage
-- Operator-group membership variables and directory permission details
+- Suite-level operator-selection variables
 - Upgrade, downgrade, and removal behavior
 - Collection bootstrap and end-to-end validation details beyond the locked
   dependency and testing policies above