Document shared pipeline filesystem policy

docs/roadmap/mvp.md

@@ -14,9 +14,11 @@ Build independently usable Ansible roles for the five Narratio applications
 and compose them through a suite-level role developed in its own repository.
 The `rakestraw.dnd` collection exposes that role as `rakestraw.dnd.pipeline`.
 The suite-level role installs and configures the complete D&D transcript
-processing pipeline on a single supported host. Human operators invoke
-Narratio commands directly to process D&D session recordings and produce
-transcripts and related artifacts.
+processing pipeline on a single supported host. Operators or unattended
+automation invoke Narratio commands either under the dedicated `narratio`
+runtime identity or under a human account that belongs to the `narratio`
+group, processing D&D session recordings into transcripts and related
+artifacts.
 
 ## Locked Decisions
 
@@ -224,24 +226,40 @@ application-role releases in one source repository.
 - 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.
+- The `narratio` account owns the suite's application configuration and
+  writable runtime directories; `narratio` is also the shared operator group.
 - 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.
-- 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 supported operational model runs `narratio run` and other processing
+  commands either as the dedicated `narratio` account or as a human account
+  that is already a member of the `narratio` group. The suite does not yet
+  select those human accounts or manage their membership.
+- Application configuration directories and files are owned by
+  `narratio:narratio`, use modes `0755` and `0644`, respectively, and are
+  world-readable. Configuration remains under Ansible control rather than
+  being routinely edited by operators on the host.
+- Workspace, spool, and cache roots are owned by `narratio:narratio` with mode
+  `2775`. Setgid and managed default ACLs preserve shared group write access
+  and world read/traverse access for newly created directories and files even
+  when invocation identities have different ordinary umasks.
+- The pipeline role installs the host `acl` package and uses the declared,
+  pinned `ansible.posix` collection to manage access and default ACL entries on
+  those shared writable roots.
 - 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.
+  Its content is world-readable but is populated by the suite role and is not
+  edited directly on the managed host.
+- Configuration, transcripts, caches, generated artifacts, logs, campaign
+  data, and prompt assets are deliberately non-secret D&D content and remain
+  world-readable. API keys and similar credentials are the sole confidential
+  category.
+- Debug output is not enabled by the MVP. Any later debug feature must either
+  produce world-readable non-secret D&D diagnostics or identify and justify a
+  narrower application contract before deployment.
+- Credential material will live beneath a restricted `secrets/` subdirectory
+  owned by `narratio:narratio`, with directories mode `0750` and files mode
+  `0640`. Ordinary configuration contains only credential reference names.
+- [Decision 0002](../decisions/0002-shared-readable-pipeline-filesystem-policy.md)
+  records the complete rationale and boundary for this policy.
 
 ### Narratio configuration
 
@@ -287,6 +305,20 @@ application-role releases in one source repository.
   Scriptorium artifacts and families. Audita initially uses the same endpoint
   and models in production and testing; identical values are inherited rather
   than duplicated in the overlay.
+- The D&D suite enables Notarius's `auto` chunk-plan cache and checkpoint
+  cache beneath `/var/cache/notarius`. That FHS cache root is owned by the
+  `narratio` account and group with mode `2775` and the suite's shared default
+  ACL policy. Notarius v0.7.0 leaves cache-entry access to that deployment
+  policy. Chunk plans are reused automatically; checkpoints are recorded but
+  Narratio does not yet request their reuse.
+- The standalone Notarius role exposes Notarius v0.7.0's native ConfigKit
+  import list while remaining independent of D&D content. The pipeline role
+  owns an imported `pipelines/dnd-session.yml` fragment containing its
+  opinionated, inventory-composable D&D pipeline map; the standalone role
+  continues to own only the version 5 root document.
+- The Narratio `testing` profile keeps the Notarius stage enabled and inherits
+  the same D&D pipeline and extraction profile as production until a distinct
+  testing extraction policy is selected.
 
 ### Execution model
 
@@ -303,7 +335,10 @@ later design decision changes them:
 - `/usr/local/etc/narratio` for Narratio configuration
 - `/usr/local/etc/audita/config.yml` for Audita configuration
 - `/usr/local/etc/notarius/config.yml` for Notarius configuration
+- `/usr/local/etc/notarius/pipelines` for suite-owned imported Notarius
+  pipeline definitions
 - `/usr/local/etc/scriptorium/config.yml` for Scriptorium configuration
+- `/usr/local/etc/narratio/secrets` for future restricted credential material
 - `/usr/local/share/narratio/campaigns` for version-controlled campaign data
 - `/usr/local/share/narratio/prompt-library` for version-controlled prompts
   and schemas
@@ -312,6 +347,8 @@ later design decision changes them:
 - `/var/lib/narratio` for durable workspace and session state
 - `/var/spool/narratio` for spool data
 - `/var/cache/narratio` for cached data
+- `/var/cache/notarius` for suite-provisioned Notarius chunk-plan and
+  checkpoint caches
 
 The Narratio role creates and configures the campaign root; the pipeline role
 populates it from the selected campaign source. `/usr/local/share` assumes Git
@@ -342,7 +379,7 @@ The following areas require investigation and decisions before implementation:
 - The mechanism used to incorporate the independently developed pipeline role
   into collection releases
 - Secret injection and storage
-- Suite-level operator-selection variables
+- 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