Close out the Scriptorium credential update

docs/decisions/0002-shared-readable-pipeline-filesystem-policy.md

@@ -48,6 +48,13 @@ file modes are `0750` and `0640`, respectively, with
 shared credentials. Configuration may contain credential reference names but
 never raw credential values.
 
+Narratio's general operational guidance recommends `0700` directories and
+`0600` files for a single-user credential store. The suite deliberately grants
+group read/traverse access instead: membership in the selected `narratio`
+runtime group authorizes both pipeline execution and use of its shared provider
+credentials. Deployments that do not trust every group member require a
+different per-user credential policy and are outside this decision.
+
 Version-controlled campaign and prompt assets may remain root-managed because
 Git is authoritative, but they are world-readable. The suite does not add
 confidentiality controls to non-secret D&D content.

docs/roadmap/application-upgrade-sequence.md

@@ -0,0 +1,88 @@
+# Application Upgrade Sequence
+
+Decision agreed: 2026-09-28
+
+## Purpose and Order
+
+Adopt the newly released applications through focused, individually reviewed
+features in this order:
+
+**Scriptorium → Audita → Notarius → Narratio → suite integration.**
+
+This document tracks the cross-feature direction, not implementation steps.
+Each feature roadmap owns its scope and decisions. Only one staged plan is
+active at a time, at [implementation.md](implementation.md).
+
+## Version Baseline
+
+These are the suite pins at the start of this upgrade, not assertions about
+what is installed on an operational host. Targets are the releases reviewed
+on the decision date; later releases require deliberate review.
+
+| Application | Starting suite version | Adoption target |
+| --- | --- | --- |
+| Scriptorium | v0.13.0 | v0.15.0 |
+| Audita | v0.9.1 | v2.0.1 |
+| Notarius | v0.7.1 | v0.8.1 |
+| Narratio | v2.2.0 | v3.0.0 |
+
+Seriatim is unchanged by this sequence.
+
+## Progress and Feature Links
+
+Release-summary and migration-guidance triage is complete. Standalone
+Scriptorium, Audita, Notarius, and Narratio adoption are complete after independent
+review. Coordinated suite integration and its three review remediations are
+complete. This upgrade sequence was closed on 2026-09-29; operational deployment
+and a new tagged release remain separate activities.
+
+- [x] [Feature 0018: Scriptorium adoption](features/0018-scriptorium-v0-15-adoption.md) — complete through role `b174c8c`; independent review found no remediation issues.
+- [x] [Feature 0019: Audita adoption](features/0019-audita-v2-adoption.md) — complete through role `c3dd59f`; independent review found no remediation issues.
+- [x] [Feature 0020: Notarius adoption](features/0020-notarius-v0-8-adoption.md) — complete through role `6aef48b`; independent review found no remediation issues; suite unchanged.
+- [x] [Feature 0021: Narratio adoption](features/0021-narratio-v3-adoption.md) — complete through role `3c0700b`; independent review found no remediation issues; suite unchanged.
+- [x] [Feature 0022: Coordinated suite integration](features/0022-coordinated-suite-upgrade.md) — complete with three review findings resolved at public pipeline `37b1cf6`, public collection `b3bc045`, and local consumer `15f0f4e`.
+
+## Adoption Boundaries
+
+Completing a standalone-role update does **not** advance the suite's application
+or role dependency pins, collection snapshot, or deployment-repository pins.
+Keep that existing compatibility set until the final integration feature
+assembles and validates the coordinated configuration.
+
+Standalone features own generic application interfaces. The integration feature
+owns D&D defaults, cross-application configuration, testing overlays, credential
+references, compatible dependency pins, and consumer upgrade guidance. Each
+feature follows roadmap → staged plan → implementation → review → closeout.
+No operational deployment is authorized merely by this sequencing decision.
+
+## Compatibility Constraints to Carry Forward
+
+- **Scriptorium is not a documentation-only upgrade from our baseline.** The
+  intervening v0.14.0 introduces ConfigKit and changes configuration acceptance,
+  selection, and retry behavior. Review those changes as well as v0.15.0's
+  licensing and dependency updates.
+- **Audita and Narratio need a coordinated suite cutover.** Audita v2 requires
+  migrated configuration; Narratio v3 expects that interface and no longer owns
+  the retired downstream settings or generated Audita configuration.
+- **Overlay terminology changes on both sides of the Notarius boundary.**
+  Narratio's selector and the suite-managed downstream files must migrate
+  together. Preserve explicit selection and independent application ownership.
+- **Existing Narratio manifests need operator migration guidance.** Carry the
+  upstream provenance-field migration into final integration planning. Preserve
+  session progress; do not infer a requirement to delete checkpoints, force all
+  stages, edit immutable remote snapshots, or automate the migration.
+- **Review retry and timeout semantics explicitly.** New transport retry and
+  repair behavior is not necessarily equivalent to the previous settings.
+  Preserve user intent without copying old values mechanically or inventing
+  new suite policy.
+
+The upstream documentation remains authoritative for exact fields and migration
+procedures:
+
+- [Scriptorium v0.14.0](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.14.0/docs/releases/v0.14.0.md)
+  and [v0.15.0](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/releases/v0.15.0.md).
+- [Audita v2 migration](https://gitea.maximumdirect.net/eric/audita/src/tag/v2.0.1/docs/migrations/v2.md).
+- [Notarius v0.8.0](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.0/docs/releases/v0.8.0.md)
+  and [v0.8.1](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.1/docs/releases/v0.8.1.md).
+- [Narratio v3.0.0](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/releases/v3.0.0.md)
+  and [migration procedures](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/operations.md#migrating-manifest-overlay-provenance).

docs/roadmap/features/0010-dnd-notarius-extraction-integration.md

@@ -1,6 +1,6 @@
 # Feature 0010: D&D Notarius Extraction Integration
 
-Status: ready
+Status: done
 
 ## Summary
 

docs/roadmap/features/0011-managed-pipeline-credential-delivery.md

@@ -0,0 +1,389 @@
+# Feature 0011: Managed Pipeline Credentials and Notarius Reuse
+
+Status: done
+
+## Summary
+
+Upgrade the generic Narratio role and D&D pipeline to Narratio v2.1.0, manage
+provider credentials through Narratio's conventional ConfigKit secrets
+directory, and use the release's typed Notarius credential and checkpoint-reuse
+controls. Credential values remain outside ordinary application YAML and are
+readable only by the selected runtime user and group. Ordinary pipeline runs
+reuse compatible Notarius checkpoints, while forced extraction retains
+Narratio's native refresh behavior.
+
+## Problem or Opportunity
+
+The pipeline role currently writes credential reference names but manages no
+credential values. A caller must prepare the invoking environment through an
+external mechanism before a real run can reach the selected model providers.
+
+The installed Narratio v2.0.0 release also cannot forward a selected provider
+credential to Notarius. Its Notarius child receives a restricted environment,
+and the v2.0 configuration contract exposes no typed credential field. The
+pipeline records Notarius checkpoints but cannot ask Notarius to reuse them.
+
+Narratio v2.1.0, immutable tag `v2.1.0` at `c45e042`, resolves both application
+contract gaps. It adds optional `notarius.llm_api_key`, `notarius.resume`, and
+`notarius.chunk_cache` fields without requiring migration of existing v2
+configuration. The credential field resolves through the existing process
+environment or secrets-directory bootstrap, forwards only the exact selected
+name and value, and participates in the application's existing redaction
+boundary. Ordinary extraction may request checkpoint reuse; forced extraction
+omits resume and refreshes the active chunk plan.
+
+The suite separately configures Audita proposal and validation with different
+environment names even though both use the same endpoint and model. Narratio's
+Audita boundary accepts one typed credential. This feature therefore
+coordinates both suite-default Audita sections on `AUDITA_LLM_API_KEY` while
+retaining their existing independently overrideable variables.
+
+## Governing Policies
+
+- [The Ansible house style](../../ansible.md) governs the direct desired-state
+  implementation, native configuration interface, and ordinary module
+  convergence.
+- [The testing house style](../../testing.md) governs synthetic, native,
+  behavior-oriented validation without live provider calls or filesystem
+  metadata assertions.
+- [The MVP roadmap](../mvp.md) assigns pipeline-wide secret delivery,
+  application-version coordination, and cache policy to the suite role.
+- [Decision 0002](../../decisions/0002-shared-readable-pipeline-filesystem-policy.md)
+  defines the selected runtime group as the authorization boundary and fixes
+  `0750` directory and `0640` file modes for shared credential material.
+- [Feature 0009](0009-shared-pipeline-filesystem-and-execution.md) establishes
+  the service-user and existing-group-member invocation model.
+- [Feature 0010](0010-dnd-notarius-extraction-integration.md) establishes the
+  Notarius pipeline, FHS cache roots, automatic chunk-plan reuse, and checkpoint
+  recording extended by this feature.
+- Narratio's immutable v2.1.0 release documentation and current configuration
+  and Notarius integration references are authoritative for the application
+  fields, resolution semantics, forced-run behavior, and redaction contract.
+
+## Scope
+
+- Advance the standalone Narratio role's selected application release from
+  v2.0.0 to v2.1.0 without changing its established source-build task flow.
+- Expose the three new native optional fields through nullable, field-specific
+  role variables: `narratio_notarius_llm_api_key`,
+  `narratio_notarius_resume`, and `narratio_notarius_chunk_cache`.
+- Keep the standalone role generic. All three variables default to null and
+  are omitted unless a caller selects them, leaving Narratio's native defaults
+  in control.
+- Advance the pipeline role's compatible Narratio application version to
+  v2.1.0 and pin its Narratio role dependency to the reviewed revision that
+  provides the new interface.
+- Use `/usr/local/etc/narratio/secrets`, the conventional directory adjacent
+  to `/usr/local/etc/narratio/pipeline.yml`, as the suite's sole managed
+  credential location.
+- Create that directory as the selected pipeline runtime user and group with
+  mode `0750`.
+- Add one public `dnd_pipeline_secrets` mapping from environment-variable names
+  to string file contents. Each supplied entry means that the named credential
+  file must be present with that content; an omitted key is unmanaged.
+- Default `dnd_pipeline_secrets` to an empty mapping so the role never invents
+  credentials and remains usable with externally prepared process environment
+  values.
+- Validate selected keys as environment-variable names and values as strings
+  before constructing a destination path.
+- Write supplied credential files as the selected runtime user and group with
+  mode `0640`.
+- Suppress credential values from Ansible task output during validation,
+  creation, and updates.
+- Keep ordinary application configuration limited to non-secret credential
+  reference names.
+- Coordinate Audita proposal and validation on the suite-default
+  `AUDITA_LLM_API_KEY` name and pass that name through the standalone Narratio
+  role's existing `narratio_audita_llm_api_key` interface.
+- Add `dnd_pipeline_narratio_notarius_llm_api_key`, default it to
+  `OPENROUTER_API_KEY` for Notarius's selected production profile, and pass it
+  through Narratio's typed Notarius credential field.
+- Add `dnd_pipeline_narratio_notarius_resume`, default it to true, and pass it
+  through Narratio so ordinary extraction requests reuse of the checkpoints
+  already recorded by the suite's Notarius configuration.
+- Expose Narratio's native `notarius.chunk_cache` in the standalone role but do
+  not duplicate it behind a suite variable or set it from the pipeline role.
+  The suite already configures Notarius's ordinary chunk-plan mode as `auto`;
+  Narratio v2.1.0 independently owns its forced-extraction refresh override.
+- Preserve Scriptorium's application-owned `api_key_env` profile selection.
+  Narratio's secrets bootstrap supplies the selected environment value and the
+  existing Scriptorium adapter passes that named credential to its child.
+- Document the mapping interface, Ansible Vault inventory pattern, process
+  environment precedence, shared-group authorization boundary, application
+  credential flow, and checkpoint-reuse policy.
+- Add focused integration coverage using distinctive synthetic values and
+  native Narratio configuration loading. No default test contacts a model
+  provider.
+
+## Non-goals
+
+- Storing raw credentials in Narratio, Audita, Notarius, or Scriptorium YAML.
+- Providing real credentials, unencrypted example values, or a default secret
+  mapping.
+- Implementing Ansible Vault, choosing a vault password mechanism, or requiring
+  one specific inventory encryption workflow.
+- Integrating an external secret manager, cloud vault, hardware-backed key
+  store, or dynamic credential broker.
+- Making the pipeline role authoritative for files omitted from
+  `dnd_pipeline_secrets`, purging the whole directory, or recursively changing
+  pre-existing content.
+- Adding a launcher script, shell profile, environment file, systemd unit,
+  scheduler, or persistent service merely to inject credentials.
+- Passing arbitrary caller-defined environment variables through Narratio's
+  subprocess boundary.
+- Managing human accounts or their membership in the runtime group.
+- Running Audita, Notarius, or Scriptorium against a live endpoint during the
+  default integration suites.
+- Testing Notarius checkpoint reuse end to end in the Ansible role. Narratio
+  and Notarius own that behavior; the role validates the selected native
+  configuration and immediate Ansible convergence.
+- Setting Narratio's optional `notarius.chunk_cache` field redundantly when
+  the deployed Notarius configuration already selects `auto`.
+- Changing Narratio's native forced-extraction refresh policy.
+- Rotating credentials, retaining prior values, validating provider
+  authorization, or recovering deliberately corrupted secret files.
+- Adding storage or publishing credentials before the suite selects a storage
+  or publishing feature.
+- Modifying any upstream application source.
+
+## Target End State
+
+The standalone Narratio role installs v2.1.0 by default and can render all
+three new Notarius fields when a caller supplies them. It owns no credential
+files and selects no D&D-specific credential or cache policy.
+
+The pipeline role owns this conventional restricted subtree:
+
+```text
+/usr/local/etc/narratio/
+├── pipeline.yml
+└── secrets/                  narratio:narratio 0750
+    ├── AUDITA_LLM_API_KEY    narratio:narratio 0640
+    └── OPENROUTER_API_KEY    narratio:narratio 0640
+```
+
+The filenames are suite-selected reference names, never credential values.
+The selected runtime user and group remain configurable through the existing
+pipeline interface.
+
+A consumer may keep encrypted values in inventory without embedding any value
+in ordinary configuration:
+
+```yaml
+dnd_pipeline_secrets:
+  AUDITA_LLM_API_KEY: "{{ vault_dnd_audita_llm_api_key }}"
+  OPENROUTER_API_KEY: "{{ vault_dnd_openrouter_api_key }}"
+```
+
+The role owns only the supplied named entries for this invocation and leaves
+every omitted name alone. The actual `vault_dnd_*` values belong in encrypted
+inventory and must not appear in examples, plans, test logs, commits, or
+ordinary generated configuration.
+
+When Narratio runs without `--secrets-dir`, it discovers the sibling directory
+and loads its immediate regular files before resolving the pipeline. An
+already-set process environment value wins over the corresponding file. The
+base and `testing` profiles use the same delivery mechanism; profiles select
+models and application profiles, not a second credential store.
+
+The suite deliberately uses `narratio:narratio`, directory mode `0750`, and
+file mode `0640` rather than Narratio's general single-user recommendation of
+`0700` and `0600`. Membership in the selected runtime group is an explicit
+authorization to invoke this pipeline with its shared provider credentials.
+No world access is granted. Deployments that do not trust every group member
+must use separate process-environment or `--secrets-dir` provisioning and are
+outside this shared-operator policy.
+
+Audita's proposal and validation configuration both reference
+`AUDITA_LLM_API_KEY` by default. Narratio resolves that typed reference and
+passes the value explicitly to the Audita child. Callers may still override
+the existing Audita reference variables, but a custom split-key design also
+requires an application boundary capable of forwarding both values and is not
+promised by this feature.
+
+Narratio's effective Notarius configuration names `OPENROUTER_API_KEY`, or a
+caller-selected replacement, through `notarius.llm_api_key`. Narratio resolves
+the named secret and forwards only that exact name and value to Notarius. It
+does not infer a provider from Notarius configuration or forward unrelated
+credentials.
+
+Ordinary extraction sets `notarius.resume: true`. Notarius continues to own
+checkpoint recording, identity, and storage beneath the configured
+`/var/cache/notarius/checkpoints` root. Narratio requests reuse but does not
+inspect the cache. The pipeline leaves Narratio's `notarius.chunk_cache` field
+unset because the Notarius root configuration already selects `auto` at the
+native owner. Forced extraction follows Narratio v2.1.0 behavior: resume is
+omitted and the active chunk plan is refreshed without deleting unrelated
+cache content.
+
+Scriptorium continues to select credential names through its PromptKit
+profiles. The Narratio process receives those names from the secret bootstrap,
+and its existing adapter forwards the selected profile credential.
+
+## Repository Ownership
+
+- `../narratio` at immutable tag `v2.1.0` is the read-only application
+  authority for secrets bootstrap, typed Notarius credential forwarding,
+  checkpoint reuse, forced refresh, and subprocess redaction.
+- `ansible-role-narratio` advances the application release and exposes the
+  three native Notarius fields through its generic field-specific interface.
+  It does not manage secret files or select suite policy.
+- `ansible-role-dnd-pipeline` owns the conventional secrets directory, managed
+  credential mapping, suite-level Audita and Notarius reference coordination,
+  checkpoint-reuse selection, consumer documentation, and behavioral tests.
+- `ansible-workspace-dnd` owns this roadmap, the settled MVP policy, progress,
+  and independent review record.
+- The Audita, Notarius, and Scriptorium application roles remain unchanged;
+  they continue to own only their native configuration interfaces.
+- The collection, asset, remaining application, and reference repositories
+  remain unchanged.
+
+## Constraints and Settled Decisions
+
+- Raw credential bytes never enter ordinary application YAML, Git-tracked
+  examples, workspace plans, or committed test fixtures.
+- The role manages secret values only through `ansible.builtin.copy` content
+  or an equally direct secret-safe module operation with `no_log: true`.
+- The conventional directory path is fixed because automatic Narratio
+  discovery depends on its relationship to the fixed root pipeline document.
+- Credential filenames must match the environment-variable grammar accepted
+  by ConfigKit. Validation exists to prevent a caller-controlled key from
+  becoming a path outside the secrets directory.
+- Credential values are written as supplied strings. ConfigKit and the typed
+  application reference own any nonempty-value requirement when a credential
+  is selected for use.
+- An omitted mapping key is outside the role's ownership. Exact-directory
+  mirroring and deletion of unlisted files are intentionally excluded.
+- The shared runtime group is an authorization group. Its members may read the
+  managed credentials; all other local users are denied access.
+- The suite's group-readable credential policy deliberately differs from
+  Narratio's general single-user mode recommendation. ConfigKit does not
+  enforce those recommended modes, and the selected policy grants no world
+  access.
+- Application adapters, rather than Ansible, own the secure transfer of loaded
+  values to child processes. Ansible does not create wrappers or reconstruct
+  the subprocess environment.
+- Notarius's root configuration remains the single owner of ordinary
+  chunk-plan mode. Narratio's native `resume` field expresses the distinct
+  request to load compatible recorded checkpoints.
+- Production convergence performs no provider call, credential validity test,
+  cache probe, content checksum bookkeeping, backup, or post-write reread.
+
+## Simplest Viable Implementation Shape
+
+The standalone Narratio role needs only a release update and three nullable
+field-specific variables rendered through its existing template. It remains
+generic and does not own credential files or suite policy.
+
+The pipeline role needs one empty credential mapping, two Narratio Notarius
+policy variables, coordinated Audita reference defaults, and ordinary
+dependency wiring. Credential convergence consists of one directory task, one
+validation loop, and one copy loop for supplied entries. Both secret-bearing
+loops suppress their output.
+
+Documentation and focused native integration coverage complete the public
+interface. No state probe, handler, template assembly, manifest, wrapper,
+directory scan, or role-private bookkeeping is required. The validation loop
+is deliberate: the mapping key becomes a filesystem path, so rejecting
+anything other than a valid environment-variable name protects the declared
+destination boundary.
+
+## Rationale and Alternatives
+
+Narratio's native ConfigKit bootstrap is preferable to a shell wrapper or
+service-specific environment file because every pipeline-loading command uses
+the same application-owned behavior, whether invoked by the service account or
+an authorized human operator. It also preserves the application's existing
+environment-precedence and redaction rules.
+
+A mapping is more ergonomic for inventory than a list of file objects because
+the native identity of each entry is already its environment-variable name.
+Omitted files remain unmanaged so consumers can combine Ansible-managed
+credentials with another provisioning mechanism. Credential removal and
+directory mirroring remain outside this feature until an operator-facing
+lifecycle requirement is expressly selected.
+
+Per-user `0700` directories would follow Narratio's general recommendation but
+would require separate keys or an additional invocation convention for every
+authorized human. The selected shared group already defines who may execute
+the suite with shared state, so group-readable and world-inaccessible
+credentials provide the intended operational model with less duplication.
+
+Selecting Narratio checkpoint reuse completes the suite's earlier decision to
+enable every available Notarius cache. Duplicating `chunk_cache: auto` in both
+Narratio and Notarius configuration would add no ordinary behavior, so the
+pipeline leaves the optional Narratio override unset and relies on each
+application's documented ownership boundary.
+
+## Acceptance Criteria
+
+- The standalone Narratio role installs an explicitly selected v2.1.0 and can
+  render representative non-null and falsey values for
+  `narratio_notarius_llm_api_key`, `narratio_notarius_resume`, and
+  `narratio_notarius_chunk_cache` while omitting null values.
+- The pipeline role selects Narratio v2.1.0 and pins the reviewed standalone
+  role revision that provides its native fields.
+- The pipeline role creates `/usr/local/etc/narratio/secrets` with the selected
+  runtime ownership and suite credential-directory mode.
+- `dnd_pipeline_secrets` defaults to an empty mapping and accepts valid
+  environment names with string values.
+- Invalid names and non-string values fail before any destination outside the
+  declared secret directory can be constructed.
+- Supplied entries converge to regular files with the selected runtime
+  ownership and mode `0640`; omitted names remain unmanaged.
+- Credential values are suppressed from Ansible output and never appear in
+  application YAML, generated examples, native effective-configuration output,
+  test logs, or committed fixtures.
+- Audita proposal and validation use `AUDITA_LLM_API_KEY` by default, and
+  Narratio's typed Audita field names that reference so the adapter explicitly
+  supplies the loaded value.
+- Narratio's effective pipeline selects `OPENROUTER_API_KEY` through the typed
+  Notarius field and selects checkpoint resume for ordinary extraction.
+- Narratio's optional chunk-cache override remains absent from the suite
+  configuration while Notarius's effective root configuration continues to
+  select `auto`.
+- Scriptorium continues to receive the credential named by its selected
+  profile through the existing adapter behavior.
+- A synthetic pipeline integration invocation with the relevant ambient
+  variables unset loads credentials through the conventional directory and
+  succeeds at native offline configuration validation as the service account
+  and one existing-group-member fixture.
+- A distinctive synthetic secret never appears in captured integration output.
+- The baseline credential application reports `changed=0` and `failed=0` on
+  an immediate identical repeat.
+- Syntax checking, production-profile lint, and the complete standalone
+  Narratio and pipeline integration entry points pass.
+- No live provider, WhisperX service, storage backend, model call, or
+  application cache execution occurs in default tests.
+
+## Dependencies and Follow-up Work
+
+- Features 0005, 0006, 0008, 0009, and 0010 are complete prerequisites.
+- Narratio v2.1.0 at immutable tag `c45e042` satisfies the former typed
+  Notarius credential and cache-control prerequisite.
+- The completed upstream feature request was removed from Narratio's active
+  roadmap during its v2.1.0 release cleanup; the release reference now owns the
+  delivered behavior.
+- The standalone Narratio-role commit produced by this feature must be
+  available from its canonical Git origin before the pipeline's isolated
+  dependency test can use it.
+- Collection assembly should follow this feature so the first assembled
+  collection packages a pipeline with complete credential delivery and cache
+  reuse.
+- Storage and publishing policy may later add S3 or other credential reference
+  names to consumer inventory without changing the file-delivery mechanism.
+- Operator selection, group-membership management, services, scheduling,
+  upgrades, removal, and external secret-manager integration remain separate
+  features.
+
+## Potential Future Hardening
+
+- Integrate a dedicated external secret manager or short-lived credential
+  broker.
+- Support distinct per-operator secret directories for deployments that do
+  not treat runtime-group membership as shared credential authorization.
+- Add explicit credential rotation orchestration and provider-side validity
+  checks.
+- Add an explicit credential-removal or directory-lifecycle contract if an
+  operator need is identified.
+- Add platform-specific mandatory-access-control policy for credential files.

docs/roadmap/features/0012-collection-assembly.md

@@ -0,0 +1,304 @@
+# Feature 0012: Assemble the D&D Collection
+
+Status: done
+
+## Summary
+
+Turn the existing `ansible-collection-dnd` repository into a valid, buildable
+`rakestraw.dnd` Ansible collection that exposes the independently developed
+pipeline role as `rakestraw.dnd.pipeline`. The collection will carry a
+self-contained snapshot of the pipeline role, publish the collection
+dependencies Ansible can resolve natively, and provide one consumer bootstrap
+manifest for the five Git-hosted application roles.
+
+## Problem or Opportunity
+
+The standalone application roles and the opinionated pipeline role are now
+implemented and independently tested, but the collection repository still
+contains only a placeholder README and repository metadata. A consumer cannot
+build or install `rakestraw.dnd`, invoke the intended fully qualified role
+name, or reproduce the reviewed combination of application-role dependencies
+from that repository.
+
+The pipeline role must remain independently developed, versioned, and usable.
+At the same time, the collection artifact must contain the role it advertises;
+it cannot depend on a sibling checkout, a symbolic link, or workspace-only
+tooling at runtime. The assembly boundary therefore needs an explicit,
+repeatable source-import convention and focused integration coverage of the
+packaged result.
+
+## Governing Policies
+
+- [The Ansible house style](../../ansible.md) governs collection metadata,
+  dependency declarations, documentation, and the preference for native
+  Ansible packaging behavior.
+- [The testing house style](../../testing.md) governs behavior-oriented,
+  state-based validation and the avoidance of tests that merely restate file
+  layout or implementation details.
+- [The MVP roadmap](../mvp.md) establishes the collection name, independently
+  released role repositories, Git-hosted application-role dependencies, and
+  the collection as the compatibility record for an assembled release.
+- Features [0006](0006-pipeline-role-composition-foundation.md) through
+  [0011](0011-managed-pipeline-credential-delivery.md) define the pipeline
+  role behavior being assembled; this feature does not reopen those contracts.
+
+## Scope
+
+- Add valid Ansible Galaxy metadata for collection namespace `rakestraw`, name
+  `dnd`, development version `0.1.0`, the repository's existing license and
+  README, and its supported Ansible version.
+- Declare the exact `ansible.posix` and `community.general` versions already
+  selected by the pipeline role as collection dependencies.
+- Import the complete standalone pipeline-role repository into
+  `roles/pipeline` as a squashed Git subtree at an explicitly reviewed commit.
+- Treat `ansible-role-dnd-pipeline` as authoritative: changes are made and
+  reviewed there first, then deliberately imported into the collection. Do
+  not edit role behavior directly beneath the collection's subtree prefix.
+- Document the initial subtree import and subsequent update commands so the
+  source relationship is reproducible without custom tooling or private
+  knowledge.
+- Ensure the standalone pipeline role's collection-facing documentation
+  distinguishes its standalone role name and invocation from
+  `rakestraw.dnd.pipeline` use without changing its public behavior.
+- Add `meta/runtime.yml` with `requires_ansible: ">=2.18.0"`, matching the
+  implemented roles' supported baseline.
+- Add one root `requirements.yml` that combines the five Git-hosted
+  application-role dependencies with the two collection dependencies needed
+  to bootstrap the assembled suite.
+- Pin application roles to the exact reviewed commits already selected by the
+  standalone pipeline role during development. Keep the root bootstrap
+  manifest and the imported role's dependency manifests consistent.
+- Configure collection builds to omit development-only content embedded in the
+  role subtree, including its integration suite, local Ansible configuration,
+  and nested dependency manifests. Retain operator-facing role documentation
+  and licensing in the source collection unless Ansible packaging requires
+  otherwise.
+- Replace the collection's placeholder README with concise instructions for
+  dependency bootstrap, collection build and installation, FQCN invocation,
+  subtree provenance and updates, supported platform, and the distinction
+  between development commit pins and future released role tags.
+- Add a focused collection integration suite that starts with isolated role
+  and collection paths, installs the root bootstrap manifest and the locally
+  built collection artifact, invokes `rakestraw.dnd.pipeline`, validates the
+  assembled pipeline through the applications' native configuration
+  interfaces, and verifies an immediate second application converges with no
+  reported changes.
+
+## Non-goals
+
+- Publishing the collection to Ansible Galaxy, Automation Hub, Gitea, or any
+  other registry.
+- Creating the first collection release tag or application-role release tags.
+- Replacing development commit pins with immutable role tags before those tags
+  exist.
+- Vendoring any of the five standalone application roles into the collection.
+- Moving authoritative pipeline-role development into the collection
+  repository or permitting collection-local role forks.
+- Changing pipeline defaults, host convergence, application versions,
+  application configuration, asset deployment, credentials, or runtime
+  behavior.
+- Adding collection plugins, modules, filters, playbooks, execution
+  environments, CI workflows, release automation, or a general-purpose sync
+  framework.
+- Repeating every standalone pipeline integration scenario inside the
+  collection suite or asserting the exact contents of metadata and manifests
+  as an implementation snapshot.
+- Supporting installation without network access. The collection artifact is
+  self-contained for the pipeline role, but its declared external role and
+  collection dependencies must still be made available to Ansible.
+
+## Target End State
+
+The collection repository has this durable shape:
+
+```text
+ansible-collection-dnd/
+├── galaxy.yml
+├── meta/
+│   └── runtime.yml
+├── requirements.yml
+├── roles/
+│   └── pipeline/             imported pipeline-role subtree
+├── tests/
+│   ├── converge.yml
+│   ├── integration           assembled-artifact behavior test
+│   └── inventory
+├── LICENSE
+└── README.md
+```
+
+`ansible-galaxy collection build` produces a valid
+`rakestraw-dnd-0.1.0.tar.gz` artifact. After the documented bootstrap installs
+the root dependency manifest and the built artifact into clean Ansible paths,
+a consumer can invoke:
+
+```yaml
+- name: Install and configure the D&D transcript pipeline
+  hosts: pipeline_hosts
+  roles:
+    - role: rakestraw.dnd.pipeline
+```
+
+The collection contains ordinary role files at `roles/pipeline`; it has no
+runtime link to the standalone repository. Git history records that directory
+as a squashed subtree import from `ansible-role-dnd-pipeline`. Maintainers make
+pipeline changes in the standalone repository, validate and commit them there,
+then update the collection subtree from the desired reviewed commit.
+
+The root bootstrap manifest is the consumer-facing compatibility manifest for
+development. It contains the same five application-role sources and reviewed
+commit pins as the imported pipeline role, plus exact versions of
+`ansible.posix` and `community.general`. The collection's Galaxy metadata also
+declares those two collection dependencies because Ansible can resolve them as
+native collection dependencies. This intentional duplication serves two
+different installation boundaries and must remain consistent.
+
+Development-only files may remain in the subtree source for faithful
+provenance, but they are excluded from the built artifact. The collection's
+own integration suite exercises the artifact rather than the repository role
+directory, with role and collection paths isolated from ordinary user
+installations.
+
+## Repository Ownership
+
+- `ansible-collection-dnd` owns collection metadata, the consumer bootstrap
+  manifest, the imported pipeline snapshot, collection-facing documentation,
+  build exclusions, and assembled-artifact integration coverage.
+- `ansible-role-dnd-pipeline` remains authoritative for all pipeline-role code,
+  defaults, templates, dependency metadata, standalone documentation, and its
+  comprehensive integration suite. This feature changes only the wording
+  needed to document both standalone and collection use.
+- The five standalone application-role repositories remain authoritative for
+  their roles and are read-only inputs to this feature.
+- `campaigns` and `narratio-prompts` remain independently managed asset
+  repositories and are read-only integration inputs.
+- `ansible-workspace-dnd` owns this feature roadmap, progress tracking, and the
+  later independent review record.
+- Application source repositories and `rakestraw-ansible` remain unchanged.
+
+## Constraints and Settled Decisions
+
+- The collection is `rakestraw.dnd`; the bundled role's FQCN is
+  `rakestraw.dnd.pipeline`.
+- A squashed Git subtree is the selected incorporation mechanism. It yields a
+  normal, self-contained collection artifact while preserving an auditable
+  upstream relationship and avoiding submodule checkout requirements,
+  symbolic links, manual copying, or custom synchronization state.
+- The subtree prefix is `roles/pipeline`, and the standalone pipeline
+  repository remains the only place where role behavior is authored.
+- The first development build uses collection version `0.1.0`. This version
+  enables ordinary Galaxy build and install validation but does not itself
+  authorize publication or establish a release tag.
+- Development dependencies use exact reviewed commits. A later release pass
+  must replace all application-role commit pins with immutable role release
+  tags and revalidate the assembled artifact before publishing.
+- Collection dependencies remain exactly `ansible.posix` 2.2.0 and
+  `community.general` 13.3.0, matching the existing reviewed pipeline
+  manifests.
+- Galaxy metadata cannot install arbitrary standalone Git roles. The root
+  unified requirements manifest and documented bootstrap are therefore part
+  of the collection's public installation contract.
+- The collection integration suite must not receive dependencies from the
+  developer's normal Ansible paths. Its success must demonstrate that the
+  documented manifest and built artifact are sufficient.
+- The collection suite owns only the packaging boundary: buildability,
+  dependency bootstrap, FQCN resolution, representative assembled behavior,
+  native configuration acceptance, and convergence. Detailed pipeline feature
+  matrices remain in the standalone role's tests.
+- The collection does not add probes, manifests, checksums, copied-file
+  comparisons, or private state to police the subtree. Git and the documented
+  subtree workflow are the provenance mechanism.
+
+## Simplest Viable Implementation
+
+Use Ansible's conventional collection layout and metadata directly. Import the
+reviewed pipeline repository with ordinary `git subtree add --squash`, then
+exclude only the subtree's development fixtures and nested bootstrap files
+from Galaxy builds. No wrapper role, generated role, symbolic link, submodule,
+or synchronization script is required.
+
+Derive the root unified dependency manifest directly from the pipeline role's
+two existing manifests. The only deliberate duplication is the collection
+dependency declaration in `galaxy.yml`, because the artifact and the source
+bootstrap have distinct native Ansible dependency interfaces.
+
+Use one representative integration path: build into a temporary directory,
+install dependencies and the artifact into isolated temporary Ansible paths,
+apply `rakestraw.dnd.pipeline` using the same offline synthetic inputs already
+proven by the standalone suite, run native application configuration
+validation, and apply the play a second time to assert `changed=0` and
+`failed=0`. This tests the behavior unique to collection assembly without
+duplicating the standalone role's full test matrix.
+
+## Rationale and Alternatives
+
+A squashed subtree is preferable to a Git submodule because Ansible collection
+archives require real role content and should build correctly from an ordinary
+checkout without a second initialization step. It is preferable to a symbolic
+link because archive behavior and installed collection paths would be fragile.
+It is preferable to an unrecorded copy because subtree history retains the
+source relationship and provides a standard update command. Squashing avoids
+injecting the pipeline repository's entire development history into the
+collection while still recording each reviewed import.
+
+Moving the role permanently into the collection would simplify assembly, but
+would discard the settled requirement that the suite role remain independently
+developed, tested, versioned, and usable. A thin collection wrapper that
+depends on `rakestraw.dnd_pipeline` would avoid source import but would not
+actually bundle the role or satisfy the desired FQCN without adding another
+runtime dependency layer.
+
+Keeping one unified root requirements file gives consumers one bootstrap
+command for both dependency kinds. Retaining the imported role's own
+requirements files in source preserves standalone repository fidelity; build
+exclusion prevents those nested development interfaces from confusing users
+of the installed artifact.
+
+## Acceptance Criteria
+
+- The collection repository is recognized by `ansible-galaxy` as
+  `rakestraw.dnd` version `0.1.0` and builds successfully from a clean checkout.
+- The built archive contains `roles/pipeline` and excludes the imported role's
+  development-only integration suite, local Ansible configuration, and nested
+  dependency manifests.
+- The role content at `roles/pipeline` is traceable to a documented reviewed
+  commit of `ansible-role-dnd-pipeline` through the repository's squashed
+  subtree history.
+- The standalone pipeline README accurately documents both
+  `rakestraw.dnd_pipeline` and `rakestraw.dnd.pipeline` consumption without
+  changing role behavior.
+- `meta/runtime.yml` selects Ansible 2.18 or newer, and Galaxy metadata declares
+  the exact two collection dependencies used by the pipeline.
+- The root bootstrap manifest contains all five standalone application roles
+  at the same reviewed commits used by the imported pipeline role and the
+  exact two required collections.
+- Collection documentation provides sufficient commands to install the
+  bootstrap dependencies, build and install the artifact, invoke the pipeline
+  FQCN, and update the subtree from a future reviewed pipeline commit.
+- The integration suite starts with isolated Ansible role and collection
+  paths, installs only the declared bootstrap inputs and built artifact, and
+  resolves `rakestraw.dnd.pipeline` without access to a sibling role checkout.
+- The representative assembled deployment passes the applications' native
+  configuration validation and an immediate identical second run reports
+  `changed=0` and `failed=0`.
+- Existing standalone pipeline-role validation continues to pass after its
+  documentation-only change.
+- No application role, application source, asset behavior, or pipeline host
+  convergence behavior changes as part of this feature.
+
+## Dependencies and Follow-up Work
+
+- Features 0001 through 0011 and their reviewed role commits are prerequisites.
+- A subsequent release feature must create immutable role tags, replace
+  development commit pins, select the release collection version, validate the
+  tagged combination, create release notes and tags, and publish or distribute
+  the artifact.
+- CI automation may later run the collection integration suite after a local,
+  repeatable workflow exists.
+
+## Potential Future Hardening
+
+- Sign collection artifacts or publish checksums and software bills of
+  materials when a distribution threat model requires them.
+- Automate subtree provenance checks and dependency-pin synchronization if
+  manual collection updates become frequent enough to justify that machinery.

docs/roadmap/features/0013-first-coordinated-suite-release.md

@@ -0,0 +1,285 @@
+# Feature 0013: Publish the First Coordinated Suite Release
+
+Status: done
+
+## Summary
+
+Publish the reviewed D&D pipeline as the first immutable, remotely installable
+release of its five application roles, standalone pipeline role, and
+`rakestraw.dnd` collection. The release establishes `v0.1.0` tags in the
+projects' public Gitea repositories, replaces development commit pins with
+those role tags, and makes the built `rakestraw-dnd-0.1.0.tar.gz` collection
+artifact available from the collection's Gitea release.
+
+## Problem or Opportunity
+
+The application roles, pipeline role, and collection have been implemented,
+reviewed, and tested as one compatible suite. Their current dependency
+manifests still select application roles by development commit, however, and
+none of the seven Ansible repositories has an immutable release tag. The
+collection documentation consequently describes a development build rather
+than a published release, and a consumer cannot bootstrap the reviewed suite
+entirely from named releases and a published collection artifact.
+
+The initial release should turn the existing reviewed compatibility set into a
+durable public installation boundary without changing application behavior or
+introducing release automation. It must prove that the release is consumable
+from Gitea alone rather than from sibling repositories or unpublished local
+artifacts.
+
+## Governing Policies
+
+- [The Ansible house style](../../ansible.md) governs dependency manifests,
+  collection packaging, and concise consumer documentation.
+- [The testing house style](../../testing.md) governs release validation. The
+  feature reuses behavior-oriented repository suites and adds only validation
+  specific to the remote publication boundary.
+- [The planning policy](../../planning.md) governs the cross-repository
+  implementation and review workflow.
+- [The MVP roadmap](../mvp.md) defines independent role releases, immutable
+  release pins, the collection as the compatibility record, and public Gitea
+  as the release source.
+- [Feature 0012](0012-collection-assembly.md) defines the authoritative
+  pipeline subtree, unified consumer manifest, and assembled-artifact testing
+  boundary that this feature releases without redesigning.
+
+## Scope
+
+- Publish `v0.1.0` as the initial release of each standalone application role:
+  `rakestraw.audita`, `rakestraw.narratio`, `rakestraw.notarius`,
+  `rakestraw.seriatim`, and `rakestraw.scriptorium`.
+- Point those application-role tags at the exact reviewed commits already
+  selected by the pipeline compatibility manifest. No application-role code
+  or default changes are part of release preparation.
+- Replace the five development commit pins in the authoritative pipeline
+  role's root dependency manifest with the corresponding immutable `v0.1.0`
+  role tags.
+- Update the pipeline documentation to describe the released dependency pins
+  and its standalone installation path without changing its role interface or
+  runtime behavior.
+- Validate and publish `v0.1.0` of the standalone pipeline role after its
+  release manifest and documentation are complete.
+- Import the published pipeline `v0.1.0` state into the collection's
+  `roles/pipeline` subtree using the established remote-only, squashed subtree
+  workflow.
+- Replace the collection's five application-role commit pins with the same
+  `v0.1.0` tags used by the authoritative pipeline role, retaining the exact
+  `ansible.posix` and `community.general` version pins already selected.
+- Retain collection version `0.1.0` in `galaxy.yml`, update collection
+  documentation from development-build language to released installation
+  instructions, and identify the release as the compatibility record for the
+  seven selected component versions.
+- Create and push public, immutable `v0.1.0` tags for all seven Ansible
+  repositories.
+- Build `rakestraw-dnd-0.1.0.tar.gz` from the tagged collection content and
+  create a concise public Gitea `v0.1.0` collection release whose attachment
+  is that exact artifact.
+- Validate that a clean consumer can obtain the tag-pinned dependency manifest
+  and collection archive from their public Gitea URLs, install them into
+  isolated Ansible paths, invoke `rakestraw.dnd.pipeline`, and obtain an
+  immediate clean repeat.
+- Record the completed release and its immutable compatibility set in the
+  workspace status and durable release-facing documentation.
+
+## Non-goals
+
+- Changing application versions, role defaults, pipeline configuration,
+  filesystem policy, credentials, assets, or deployed runtime behavior.
+- Synchronizing future versions of independently released roles. The shared
+  initial version is a convenient baseline, not a lockstep release policy.
+- Publishing the collection to Ansible Galaxy, Automation Hub, or another
+  package registry.
+- Vendoring the five application roles into the collection or changing the
+  selected pipeline subtree model.
+- Adding CI/CD, a release script, a changelog generator, dependency-update
+  automation, or a general-purpose release framework.
+- Adding tests that snapshot manifest text, tag names, defaults, task traces,
+  or other implementation details. Release validation should exercise the
+  public installation and deployed behavior.
+- Signing tags or artifacts, generating checksums or software bills of
+  materials, mirroring dependencies, or adding other supply-chain hardening.
+- Defining upgrade, downgrade, removal, scheduling, or optional human-operator
+  account management.
+
+## Target End State
+
+Each public application-role repository has an immutable `v0.1.0` tag for the
+exact role revision already reviewed as part of the assembled suite:
+
+| Role | Released revision |
+| --- | --- |
+| `rakestraw.audita` | `66ebea9a47ce82bfdbdc5e2855f3dfaaff8e2a16` |
+| `rakestraw.narratio` | `292d8669e7aad5cfe80b0c469d22b6177e8cf0f1` |
+| `rakestraw.notarius` | `14a38e04e35ef524d6a97fa7fb5a04981a0a2161` |
+| `rakestraw.seriatim` | `e08c63c0b078658bdfa2d10a2e6e1e4f9372a075` |
+| `rakestraw.scriptorium` | `8b4c86e48e7d8655e479b26dc510bf01683a0c8f` |
+
+The standalone pipeline role has its own immutable public `v0.1.0` tag. Its
+role dependency manifest selects all five application roles with
+`version: v0.1.0`, and its collection dependency manifest retains
+`ansible.posix` 2.2.0 and `community.general` 13.3.0. The pipeline release is
+independently installable under `rakestraw.dnd_pipeline`.
+
+The collection's `roles/pipeline` subtree is a faithful squashed import of the
+published pipeline `v0.1.0` release. Its consumer-facing `requirements.yml`
+contains the same five role tags and collection versions as the standalone
+pipeline manifests. `galaxy.yml` remains version `0.1.0`, and the collection
+repository has an immutable `v0.1.0` tag and corresponding public Gitea
+release to carry the built artifact.
+
+The collection release includes the archive produced from that released tree,
+named `rakestraw-dnd-0.1.0.tar.gz`. Its public release notes identify the exact
+five application-role versions, pipeline-role version, native collection
+dependencies, supported platform, and consumer bootstrap steps. A consumer
+can fetch the tagged manifest and archive through public Gitea URLs and
+install the suite without access to this development workspace.
+
+## Repository Ownership
+
+- The five standalone application-role repositories own their respective
+  `v0.1.0` tags. Their reviewed role content remains unchanged by this
+  feature.
+- `ansible-role-dnd-pipeline` owns its tag-pinned role manifest, standalone
+  release documentation, and `v0.1.0` tag.
+- `ansible-collection-dnd` owns the released pipeline subtree, unified
+  tag-pinned consumer manifest, collection release documentation, collection
+  tag, built artifact, and Gitea release attachment.
+- `ansible-workspace-dnd` owns this roadmap, cross-repository compatibility
+  record, active implementation plan, progress tracking, and independent
+  release review.
+- The application source repositories, campaign repository, prompt-library
+  repository, and `rakestraw-ansible` are unchanged release inputs.
+
+## Constraints and Settled Decisions
+
+- Public repositories beneath
+  `https://gitea.maximumdirect.net/eric/` are the authoritative publication
+  channel for this release.
+- Every Ansible repository uses initial release tag `v0.1.0`. The collection's
+  Galaxy version remains the corresponding unprefixed `0.1.0`, as required by
+  collection metadata and artifact naming.
+- Tags are immutable release boundaries. A release candidate must be validated
+  before its tag is created and pushed; published tags must not be moved to
+  repair a failed release.
+- The five application-role tags identify the exact reviewed commits shown in
+  the target end state. Release metadata must not create otherwise unnecessary
+  commits in those repositories.
+- Released role dependency manifests use tag names, not branches or commit
+  hashes. Application repositories remain independently versioned after this
+  shared initial baseline.
+- The pipeline repository remains authoritative. Its release must be pushed
+  to Gitea before the collection imports the `v0.1.0` revision through the
+  documented remote-only subtree command.
+- The collection tag identifies the exact source tree from which the attached
+  artifact is built. The attached file must not be rebuilt from a later or
+  dirty tree while retaining the same version.
+- The public collection release attachment is the selected binary publication
+  interface. The repository tag remains the source publication interface.
+- Consumer validation must not use sibling checkouts, normal user Ansible
+  paths, preinstalled project roles, or an unpublished local collection
+  archive.
+- The collection's Gitea release description and existing repository
+  documentation are
+  sufficient for the initial release. This feature does not introduce
+  repository-local changelog files solely to duplicate those notes.
+
+## Simplest Viable Implementation
+
+Use ordinary Git tags, one collection Gitea release, existing Ansible
+dependency manifests, the established subtree command, and `ansible-galaxy
+collection build`. The five application roles need validation and tags only.
+The pipeline and collection need small manifest and documentation changes
+before their respective release tags are created.
+
+Reuse the existing repository-local integration entry points as release gates.
+The collection integration suite already exercises isolated dependency
+bootstrap, archive construction and installation, FQCN resolution, native
+application behavior, and clean repeated convergence. Adapt its inputs only as
+necessary to consume the release tags, and use a focused final smoke path to
+download the published manifest and attached archive from Gitea. Do not add a
+second release framework or duplicate the detailed behavior matrices owned by
+the standalone repositories.
+
+Publication is intentionally manual for the first release. The work does not
+yet justify release scripts, workflow files, persistent staging state, or a
+new packaging service.
+
+## Rationale and Alternatives
+
+Immutable role tags give consumers meaningful versions while preserving the
+settled model of independently released repositories. Publishing only commit
+hashes would be reproducible but would not establish the named release
+contract required by the MVP. Publishing branches would not be immutable.
+
+Using `v0.1.0` for every initial role and the collection makes the first
+compatibility baseline easy to understand. Future role releases remain
+independent, and future collection releases record whatever combination is
+then supported; no synchronized-version policy is implied.
+
+Attaching the Galaxy-built archive to the public Gitea collection release
+provides a direct installation artifact without introducing another registry.
+Requiring consumers to clone and build the collection would expose unnecessary
+development steps, while publishing to Ansible Galaxy or Automation Hub would
+add an unselected distribution channel and account lifecycle.
+
+Manual publication is appropriate for one initial release and keeps the
+release contract visible. Automation can be considered after repeated release
+work demonstrates a stable process worth encoding.
+
+## Acceptance Criteria
+
+- Each application-role repository advertises a public, immutable `v0.1.0`
+  tag at the exact reviewed revision listed in this roadmap.
+- Each application role's existing syntax, lint, integration, and clean-repeat
+  validation passes for the candidate being tagged; no role behavior is
+  changed merely to create the release.
+- The pipeline role's released manifest selects all five application roles by
+  `v0.1.0`, and its collection dependency versions remain unchanged.
+- The pipeline's existing validation installs its application-role
+  dependencies from the public Gitea tags, exercises the role through its
+  public interface, and passes its immediate clean repeat.
+- The pipeline repository advertises a public, immutable `v0.1.0` tag at the
+  validated release commit.
+- The collection subtree matches the published pipeline `v0.1.0` tree outside
+  repository-specific Git metadata and records the remote Gitea import in Git
+  history.
+- The collection's root manifest uses the same five `v0.1.0` application-role
+  pins and exact native collection versions as the released pipeline role.
+- `ansible-galaxy collection build` from the collection release candidate
+  produces `rakestraw-dnd-0.1.0.tar.gz`, and the existing artifact-boundary
+  exclusions remain effective.
+- The collection's existing integration suite passes against the release
+  candidate, including isolated bootstrap, installed-artifact FQCN use,
+  representative native application checks, and immediate `changed=0` and
+  `failed=0` convergence.
+- The collection repository advertises a public, immutable `v0.1.0` tag and
+  matching Gitea release. The archive attached to that release is the artifact
+  built from the tagged tree.
+- A clean remote-only smoke validation downloads the public tag-pinned
+  manifest and public collection attachment, installs into isolated paths,
+  resolves `rakestraw.dnd.pipeline`, and completes with a clean immediate
+  repeat without referencing any sibling repository or unpublished artifact.
+- Release-facing documentation no longer describes collection `0.1.0` or the
+  role release tags as future or unpublished, and it gives the complete public
+  Gitea installation path without requiring the development workspace.
+- All participating repositories are clean, their release commits and tags
+  are present upstream, and workspace status records the published
+  compatibility baseline.
+
+## Dependencies and Follow-up Work
+
+Feature 0012 and its remediation must remain complete. Credentials capable of
+pushing commits and tags and creating the public collection Gitea release and
+attachment must be available during implementation.
+
+Potential later features include release automation, publication to an Ansible
+registry, independently versioned follow-up releases, optional suite-level
+operator membership management, and defined upgrade, downgrade, or removal
+behavior. None is required for the initial release.
+
+## Potential Future Hardening
+
+- Signed Git tags or release artifacts.
+- Published checksums, provenance attestations, or software bills of
+  materials.
+- Automated verification and publication in a controlled CI environment.

docs/roadmap/features/0014-existing-pipeline-operator-enrollment.md

@@ -0,0 +1,240 @@
+# Feature 0014: Enroll Existing Pipeline Operators
+
+Status: done
+
+## Summary
+
+Let consumers name existing human accounts that the D&D pipeline role should
+add to its shared runtime group. The interface is empty by default, manages
+membership additively, and leaves account creation and removal outside the
+role.
+
+## Problem or Opportunity
+
+The pipeline's shared filesystem and credential policy already supports
+invocation by the dedicated `narratio` service account or by a human member of
+the selected runtime group. The role does not yet select human operators or
+manage their membership. Consumers must currently repeat a small
+`ansible.builtin.user` task beside the role even though group enrollment is a
+natural suite-level access choice.
+
+The role must not silently become a general account-management interface.
+Human account identity, login policy, credentials, home directories, and
+removal remain host or organization concerns. The pipeline needs only a
+concise way to enroll explicitly selected existing accounts in the group that
+already defines pipeline authorization.
+
+## Governing Policies
+
+- [The Ansible house style](../../ansible.md) requires the smallest direct
+  desired-state implementation and permits state inspection only when its
+  result is independently required.
+- [The testing house style](../../testing.md) requires a representative
+  public-interface test of deployed behavior and immediate clean convergence,
+  without retesting `getent` or `user` module internals.
+- [The MVP roadmap](../mvp.md) defines the runtime group as the shared
+  operator and credential-authorization boundary.
+- [Feature 0009](0009-shared-pipeline-filesystem-and-execution.md) establishes
+  the service-user and human-group-member execution model.
+- [Feature 0011](0011-managed-pipeline-credential-delivery.md) establishes
+  that runtime-group membership authorizes access to the suite's shared
+  credentials.
+- [Feature 0012](0012-collection-assembly.md) makes the standalone pipeline
+  repository authoritative and requires reviewed changes to enter the
+  collection through its public Gitea subtree source.
+
+## Scope
+
+- Add `dnd_pipeline_operator_users`, a list of existing account names that
+  defaults to an empty list.
+- Declare the variable as a list of strings in the pipeline role's argument
+  specification.
+- Require every selected account to exist before changing any selected
+  account's group membership.
+- Add each selected account to `dnd_pipeline_runtime_group` with additive
+  supplementary-group semantics.
+- Preserve the existing account, its primary group, and all other
+  supplementary groups.
+- Leave omitted accounts and memberships unmanaged.
+- Document the existing-account contract, additive behavior, authorization
+  consequence, and need to begin a new login session before newly granted
+  supplementary membership is visible to a long-lived user session.
+- Adapt the existing pipeline integration fixture to exercise enrollment
+  through the new public variable and retain its representative configuration,
+  secret-access, shared-cache, and clean-repeat behavior.
+- Import the reviewed, pushed pipeline commit into the collection through the
+  established squashed subtree workflow and validate the assembled artifact.
+
+## Non-goals
+
+- Creating, deleting, locking, or otherwise managing human accounts.
+- Managing UIDs, primary groups, passwords, SSH keys, shells, home
+  directories, sudo access, or login policy.
+- Removing a user from the runtime group when the user is omitted from the
+  list or removed from a later inventory value.
+- Managing external identity-provider or directory-service membership.
+- Adding per-user access controls, separate credential sets, or a second
+  operator group.
+- Changing the `narratio` service account, runtime group, filesystem modes,
+  ACL policy, credential policy, or application configuration.
+- Adding handlers, sidecar state, membership snapshots, post-change
+  verification, or a custom account-management abstraction.
+- Publishing a new pipeline-role or collection release as part of this
+  implementation.
+
+## Target End State
+
+The pipeline role exposes this optional interface:
+
+```yaml
+dnd_pipeline_operator_users:
+  - eric
+  - alice
+```
+
+The default is `[]`, so existing consumers retain their current behavior. If
+the list is nonempty, every named account must already exist on the managed
+host. The role fails before its enrollment task when any selected account is
+absent; it does not create a partially specified account as a side effect.
+
+Each existing selected account is an additive member of
+`dnd_pipeline_runtime_group`. Existing primary and supplementary memberships
+remain intact. Membership in that group grants the pipeline access already
+defined by Features 0009 and 0011, including shared writable runtime roots and
+group-readable suite credentials. Existing login sessions may need to be
+restarted before the operating system exposes newly granted supplementary
+membership.
+
+Removing a name from `dnd_pipeline_operator_users` does not revoke membership.
+Account and access removal require an explicit lifecycle policy and remain
+separate work.
+
+The collection's `rakestraw.dnd.pipeline` role contains the same reviewed
+interface through a squashed import from the authoritative public pipeline
+repository. The published `v0.1.0` release remains unchanged until a later
+release feature selects and validates a new version.
+
+## Repository Ownership
+
+- `ansible-role-dnd-pipeline` owns the public variable, existing-account
+  prerequisite, additive enrollment, operator documentation, and detailed
+  behavioral integration coverage.
+- `ansible-collection-dnd` owns the faithful subtree import and its existing
+  assembled-artifact validation boundary. It does not independently
+  reimplement or duplicate the pipeline behavior test.
+- `ansible-workspace-dnd` owns this roadmap, the settled MVP decision, active
+  implementation plan, status, and review record.
+- The standalone application roles, application sources, asset repositories,
+  and `rakestraw-ansible` remain unchanged.
+
+## Constraints and Settled Decisions
+
+- The public interface is a simple list of usernames, not a mapping of account
+  definitions. A richer structure would imply ownership of account creation
+  and login policy that this feature expressly excludes.
+- All selected accounts must exist before enrollment begins. A single
+  `ansible.builtin.getent` loop over the `passwd` database is justified because
+  `ansible.builtin.user` with `state: present` would otherwise create a missing
+  account. No registered fact, separate assertion, or post-enrollment query is
+  required.
+- The enrollment task uses `ansible.builtin.user` with the selected runtime
+  group and `append: true`. The module owns membership convergence; the role
+  does not inspect or reconstruct current group lists.
+- The enrollment task uses `become: true`. The account-existence lookup does
+  not require elevation.
+- The runtime group continues to be created by the existing Narratio role
+  dependency before the pipeline role's ordinary tasks execute.
+- Empty input naturally skips both loops. No separate conditional, fact, or
+  branching task is needed.
+- Omission is unmanaged, not absent. The feature adds access but does not
+  define revocation or exact-list reconciliation.
+- No username grammar stricter than the managed host's account database is
+  introduced. The `getent` lookup and `user` module retain ownership of their
+  native input and error handling.
+
+## Simplest Viable Implementation
+
+Add the empty-list default and matching argument-spec entry. Add one
+`ansible.builtin.getent` task that loops over the selected names with database
+`passwd` and relies on its default missing-key failure, followed by one
+privileged `ansible.builtin.user` task that loops over the same names, selects
+`dnd_pipeline_runtime_group`, and uses `append: true`.
+
+Replace the README's consumer-owned membership example with the role variable
+and its exact ownership boundary. In the existing integration driver, create
+the temporary operator without `narratio` membership before the first role
+application, pass that account through `dnd_pipeline_operator_users`, and
+retain the existing native configuration and shared-access exercises. Do not
+add a missing-user test, inspect `/etc/group`, assert module return data, or
+create a second operator scenario.
+
+After the authoritative pipeline change is committed, validated, and pushed,
+use the documented public Gitea `git subtree pull --squash` workflow to import
+that exact commit into `ansible-collection-dnd`. Run the collection's existing
+artifact-boundary integration suite without expanding its detailed feature
+matrix.
+
+## Rationale and Alternatives
+
+Keeping membership entirely in each consumer play would avoid two role tasks,
+but it leaves every deployment to reproduce access policy already owned by the
+suite. An empty-by-default list adds the ergonomic path without affecting
+consumers that prefer external membership management.
+
+Passing complete account definitions to the pipeline role would permit it to
+create users, but it would also require defaults and policy for homes, shells,
+authentication, IDs, and account removal. Those concerns are not pipeline
+requirements and belong to host identity management.
+
+Calling `ansible.builtin.user` without first checking existence would be more
+compact but would create missing accounts with implicit properties. The
+`getent` lookup is therefore independently required to enforce the selected
+ownership boundary; it is not defensive re-verification of state already
+owned by another module.
+
+Exact-list reconciliation would make removal declarative, but omission has
+not been selected as revocation and could remove access managed elsewhere.
+Additive enrollment is the smaller and safer contract until lifecycle policy
+is designed explicitly.
+
+## Acceptance Criteria
+
+- `dnd_pipeline_operator_users` defaults to an empty list and is declared as a
+  list of strings in the public argument specification.
+- An empty list introduces no account or membership change.
+- Every explicitly selected account must already exist, and a missing account
+  causes convergence to fail before the enrollment task can create or modify
+  any selected account.
+- Each selected existing account is added to
+  `dnd_pipeline_runtime_group` additively without replacing its other groups.
+- Omitted accounts and prior memberships remain unmanaged.
+- The role uses only one account-existence task and one enrollment task; it
+  adds no handler, registered fact, assertion layer, command, private state,
+  or post-change verification.
+- The pipeline documentation explains the variable, existing-account
+  prerequisite, additive non-removal behavior, group authorization boundary,
+  and login-session caveat.
+- The existing temporary-operator integration scenario enrolls its fixture
+  through the public variable, demonstrates representative pipeline access,
+  and the immediate identical second role application reports `changed=0`
+  and `failed=0`.
+- Syntax checking, production-profile lint, the complete standalone pipeline
+  integration suite, and `git diff --check` pass.
+- The exact reviewed pipeline commit is pushed to public Gitea before the
+  collection imports it.
+- The collection subtree contains the reviewed pipeline change through the
+  documented remote-only squashed import, and the existing collection
+  integration suite passes against the built and installed artifact.
+- No application repository, asset repository, release tag, published
+  artifact, application configuration, filesystem policy, or credential value
+  changes.
+
+## Dependencies and Follow-up Work
+
+Features 0009, 0011, 0012, and 0013 are prerequisites. The completed Feature
+0013 workspace and collection closeout commits should be pushed before the
+implementation sprint begins so local and remote baselines agree.
+
+Upgrade, downgrade, account revocation, exact-membership reconciliation,
+application removal, and publication of a release containing this feature
+remain separate future work.

docs/roadmap/features/0015-dnd-s3-storage-and-publishing.md

@@ -0,0 +1,424 @@
+# Feature 0015: Enable D&D S3 Storage and Publishing
+
+Status: done
+
+## Summary
+
+Make the D&D pipeline operational with Narratio's current S3 storage,
+publication, caching, cleanup, and restore capabilities. The pipeline role
+will select the established Backblaze B2 destination, reference two typed
+object-storage credentials delivered through its existing secrets directory,
+publish the useful transcript and D&D artifact outputs, and retain maximum S3
+audio caching.
+
+The standalone Narratio role already exposes Narratio v2.1.1's complete
+configuration surface for this behavior. This feature supplies D&D suite
+policy through that existing interface; it does not add another storage
+implementation or credential mechanism.
+
+## Problem or Opportunity
+
+The pipeline role currently installs Narratio v2.1.0 and configures the full
+processing graph, but deliberately leaves Narratio storage and publishing at
+their application-level defaults. Its README consequently describes storage,
+publishing, and end-to-end external execution as deferred. The resulting suite
+can validate configuration and process local state, but it does not select the
+remote archive or publish the outputs needed for an operational deployment.
+
+Narratio v2.1.0 also rejected a valid publish list when a rule explicitly set
+`required` while omitting a derivable `dest`. Narratio v2.1.1 corrects that
+resolution bookkeeping defect without changing the publish schema or
+destination rules. This feature therefore advances the pipeline application
+pin to v2.1.1 and retains explicit suite-owned requiredness together with
+native destination derivation.
+
+The prior test-machine configuration records the intended Backblaze B2
+endpoint, bucket, prefix, credential names, publication set, and post-publish
+workspace cleanup. Narratio's current contract has since replaced the legacy
+credential field names and secrets configuration with ConfigKit typed
+references and a conventional sibling `secrets/` directory. The Ansible suite
+already implements that new credential-delivery boundary for Audita and
+Notarius, so S3 needs only to join the same path.
+
+## Governing Policies
+
+- [The Ansible house style](../../ansible.md) requires suite policy to flow
+  through the standalone role's field-specific interface and optional fields
+  to remain application-owned unless the suite deliberately selects them.
+- [The testing house style](../../testing.md) requires representative
+  public-interface and native-application validation without duplicating AWS
+  SDK, ConfigKit, or Ansible module behavior.
+- [The MVP roadmap](../mvp.md) makes the pipeline role responsible for
+  cross-application configuration and end-to-end validation.
+- [Feature 0011](0011-managed-pipeline-credential-delivery.md) establishes the
+  managed Narratio secrets directory and typed credential-forwarding policy.
+- [Feature 0012](0012-collection-assembly.md) makes the standalone pipeline
+  repository authoritative and imports reviewed changes through public
+  Gitea.
+- [Feature 0016](0016-deploy-dnd-pipeline-to-pipeline-dnd.md) consumes this
+  feature's reviewed interface for the first real-host deployment.
+
+## Scope
+
+- Advance the suite's Narratio application version from `v2.1.0` to the
+  backward-compatible `v2.1.1` bugfix release.
+- Add suite-owned pipeline variables for the selected Narratio workspace,
+  S3, cache, and publish settings.
+- Select the S3 backend with these D&D deployment defaults:
+
+  | Setting | Suite default |
+  | --- | --- |
+  | Endpoint | `https://s3.us-east-005.backblazeb2.com` |
+  | Bucket | `rakestraw-assets` |
+  | Root prefix | `dnd` |
+  | Region | `us-east-1` |
+  | Force path style | `true` |
+  | Access-key reference | `OBJECT_STORAGE_KEY_ID` |
+  | Secret-key reference | `OBJECT_STORAGE_KEY` |
+
+- Pass the two credential reference names to the standalone Narratio role.
+  Their values use the existing `dnd_pipeline_secrets` map and managed
+  `/usr/local/etc/narratio/secrets/` directory.
+- Enable S3 audio caching explicitly so the suite retains Narratio's maximum
+  available audio reuse.
+- Enable run publication and publish these complete native output rules:
+
+  | Source | Required |
+  | --- | --- |
+  | `narratio.transcript.final` | `true` |
+  | `narratio.transcript.final_trimmed` | `true` |
+  | `narratio.transcript.final_markdown` | `true` |
+  | `narratio.transcript.final_trimmed_markdown` | `true` |
+  | `narratio.artifact.session_recap` | `true` |
+  | `narratio.artifact.hostile_rumors` | `true` |
+  | `narratio.artifact.deranged_rumors` | `false` |
+
+- Let Narratio derive each destination from the built-in transcript path or
+  configured artifact output path rather than duplicating those paths in the
+  publish list.
+- Enable workspace cleanup only after Narratio records successful run
+  publication. Leave spool-audio deletion under Narratio's existing default
+  because the suite has selected no policy requiring source-audio removal.
+- Keep the production and `testing` profile storage and publishing behavior
+  identical. The existing overlay remains limited to model-profile selection.
+- Document the four credentials normally required by the operational suite:
+  `AUDITA_LLM_API_KEY`, `OPENROUTER_API_KEY`,
+  `OBJECT_STORAGE_KEY_ID`, and `OBJECT_STORAGE_KEY`.
+- Document the operator-visible publication, restore, S3-session-audio, lock,
+  caching, and cleanup capabilities enabled by the selected configuration,
+  while linking Narratio's canonical CLI and operations documentation for
+  command details.
+- Preserve every accepted Notarius lane as its existing
+  `narratio.extraction.<output_key>` source. Future Narratio artifact
+  definitions can consume those sources during analyze without first making
+  the extraction lanes separate published outputs.
+- Adapt the existing pipeline integration scenario to resolve synthetic S3
+  credentials and validate one explicitly supplied representative storage and
+  publishing configuration through Narratio's native interface without
+  contacting object storage.
+- Import the reviewed public pipeline commit into the collection through the
+  established squashed subtree workflow, adapt the collection's artifact-level
+  fixture to supply the added credential names, and validate the assembled
+  artifact.
+
+## Non-goals
+
+- Implementing an S3 client, publication engine, remote commit format,
+  restore mechanism, publish-lock mechanism, or audio cache in Ansible.
+  Narratio owns all of those behaviors.
+- Placing credential values in role defaults, templates, documentation,
+  tests, ordinary inventory, or the generated pipeline configuration.
+- Adding a second secret-delivery mechanism, environment wrapper, service
+  unit, credential synchronizer, or AWS configuration-file manager.
+- Managing Backblaze buckets, object lifecycle policy, application keys,
+  retention policy, versioning, encryption, quotas, or network access.
+- Managing per-session `session.yml` files or selecting local versus S3 audio
+  input for an individual session.
+- Running a paid or networked publication test from a repository-local test
+  suite. Feature 0016 owns the representative live end-to-end exercise.
+- Publishing every Notarius extraction lane as a named current output. The
+  lanes remain available as analyze inputs independently of publication; stable
+  remote destinations require an explicit operator need.
+- Setting Narratio's optional `notarius.chunk_cache` override. The managed
+  Notarius configuration remains the single owner of its ordinary `auto`
+  cache policy, and Narratio v2.1 already requests refresh for forced
+  extraction.
+- Adding notification providers. Narratio v2.1 supports only its existing
+  `noop` notification mode.
+- Releasing new role or collection versions as part of this implementation.
+- Modifying Narratio, ConfigKit, or the standalone Narratio role. Narratio
+  v2.1.1 is an already published prerequisite, and the existing generic role
+  can install the selected application tag through `narratio_version`.
+
+## Target End State
+
+The standalone pipeline role exposes these suite variables with the selected
+defaults:
+
+```yaml
+dnd_pipeline_narratio_version: v2.1.1
+dnd_pipeline_narratio_workspace_cleanup_after_publish: true
+dnd_pipeline_narratio_storage_backend: s3
+dnd_pipeline_narratio_storage_s3_bucket: rakestraw-assets
+dnd_pipeline_narratio_storage_s3_root_prefix: dnd
+dnd_pipeline_narratio_storage_s3_region: us-east-1
+dnd_pipeline_narratio_storage_s3_endpoint: >-
+  https://s3.us-east-005.backblazeb2.com
+dnd_pipeline_narratio_storage_s3_force_path_style: true
+dnd_pipeline_narratio_storage_s3_access_key_id: OBJECT_STORAGE_KEY_ID
+dnd_pipeline_narratio_storage_s3_secret_access_key: OBJECT_STORAGE_KEY
+dnd_pipeline_narratio_cache_s3_audio: true
+dnd_pipeline_narratio_publish_enabled: true
+dnd_pipeline_narratio_publish_upload_run: true
+dnd_pipeline_narratio_publish_outputs:
+  - source: narratio.transcript.final
+    required: true
+  - source: narratio.transcript.final_trimmed
+    required: true
+  - source: narratio.transcript.final_markdown
+    required: true
+  - source: narratio.transcript.final_trimmed_markdown
+    required: true
+  - source: narratio.artifact.session_recap
+    required: true
+  - source: narratio.artifact.hostile_rumors
+    required: true
+  - source: narratio.artifact.deranged_rumors
+    required: false
+```
+
+Each value is declared in the pipeline argument specification and passed
+directly to its corresponding `narratio_*` variable in the pipeline role's
+Narratio dependency. Narratio's existing root template renders the native
+configuration. No new pipeline fragment or production task is required.
+
+The ordinary generated configuration contains only the credential names:
+
+```yaml
+storage:
+  backend: s3
+  s3:
+    access_key_id: OBJECT_STORAGE_KEY_ID
+    secret_access_key: OBJECT_STORAGE_KEY
+```
+
+Consumers supply the two values beside the existing model-provider values
+through encrypted inventory:
+
+```yaml
+dnd_pipeline_secrets:
+  AUDITA_LLM_API_KEY: "{{ vault_dnd_audita_llm_api_key }}"
+  OPENROUTER_API_KEY: "{{ vault_dnd_openrouter_api_key }}"
+  OBJECT_STORAGE_KEY_ID: "{{ vault_dnd_object_storage_key_id }}"
+  OBJECT_STORAGE_KEY: "{{ vault_dnd_object_storage_key }}"
+```
+
+The example defines references only; no roadmap, role, or test contains real
+credential values. The existing credential task writes the selected entries
+with the suite's established group-authorized secret modes. Omitted map keys
+remain unmanaged, as defined by Feature 0011.
+
+With valid credentials, Narratio can accept either local or S3 audio selected
+by each session file, cache S3 audio beneath `/var/cache/narratio`, publish an
+immutable run and the selected stable outputs, use remote publication locks,
+restore committed state, and clean the published workspace. These are native
+Narratio commands and lifecycle rules rather than additional Ansible tasks.
+
+The ten accepted Notarius outputs continue to enter Narratio's artifact
+catalog as `narratio.extraction.*` sources. Analyze-stage Scriptorium artifacts
+may reference those sources directly in their input mappings. Feature 0015
+does not yet add such artifact definitions, but its publication choices do not
+remove, rename, or constrain this future composition path.
+
+## Repository Ownership
+
+- `ansible-role-dnd-pipeline` owns the D&D suite variables, opinionated
+  defaults, dependency mappings, consumer documentation, and representative
+  integration scenario.
+- `ansible-role-narratio` remains the generic owner of installation and native
+  pipeline rendering. Its reviewed `v0.1.0` role interface is compatible with
+  Narratio v2.1.1 and already covers every
+  configuration field required by this feature and should remain unchanged.
+- `ansible-collection-dnd` owns the faithful pipeline subtree import, the
+  unified consumer dependency manifest, and artifact-boundary validation.
+- `ansible-workspace-dnd` owns this roadmap, the later implementation plan,
+  status, and independent review record.
+- `narratio` v2.1.1 is the released compatibility prerequisite and a read-only
+  source of storage, publication, credential, caching, cleanup, restore, and
+  CLI contracts during this implementation.
+- `rakestraw-ansible` remains unchanged until Feature 0016 consumes this
+  interface on `pipeline-dnd`.
+
+## Constraints and Settled Decisions
+
+- The S3 endpoint, bucket, prefix, region, and path-style values are deliberate
+  D&D suite defaults. They are ordinary variables and remain overrideable by
+  inventory.
+- Credential references are also policy defaults, but credential values have
+  no defaults. Operators must supply matching entries through
+  `dnd_pipeline_secrets` or another environment source supported by Narratio.
+- The two credential-reference variables are nullable as a pair. Setting both
+  to `null` omits the references and preserves Narratio's AWS SDK provider-chain
+  path; configuring only one remains invalid under Narratio's native contract.
+- The role does not assert that the secrets map contains particular keys.
+  Narratio's native loader owns typed-reference resolution, and external
+  environment values remain a supported higher-precedence source.
+- `dnd_pipeline_narratio_publish_outputs` is one complete native list. A caller
+  replacing it assumes responsibility for the entire selected publication
+  set; the role does not merge rules.
+- Publish destinations remain omitted where Narratio can derive them. The
+  configured source identity and artifact output path remain the single source
+  of truth.
+- Narratio v2.1.1 is the minimum application version for this feature because
+  it preserves destination derivation when `required` is explicit. Do not work
+  around older behavior by duplicating destinations or omitting deliberate
+  requiredness.
+- Workspace cleanup is gated by Narratio's own successful-publication
+  evidence. Ansible does not independently inspect remote state or remove
+  runtime content.
+- S3 audio caching is enabled, and ordinary cleanup preserves the cache.
+  Explicit operator cache clearing remains a Narratio CLI operation.
+- The testing profile does not silently disable Notarius, storage,
+  publication, cleanup, or credentials. It continues to differ only in the
+  already selected inexpensive Scriptorium model profile.
+- S3 storage also enables Narratio's native restore and publication-lock
+  commands without another configuration surface. Ansible documentation may
+  describe availability but must not duplicate Narratio's detailed operating
+  manual.
+- Notarius extraction-source availability and remote publication are separate
+  concerns. Analyze consumes `narratio.extraction.*` sources from the accepted
+  extraction catalog; `publish.outputs` selects only which sources also receive
+  stable published destinations.
+
+## Simplest Viable Implementation
+
+Advance `dnd_pipeline_narratio_version` to v2.1.1. Add the selected variables to
+the pipeline defaults and argument specification, then map them into the
+existing `rakestraw.narratio` dependency. Update the pipeline README to document
+the policy, credential names, complete-list replacement semantics, and native
+capabilities now available. Do not add a template, task, handler, fact, probe,
+or storage-specific validation layer.
+
+In the existing pipeline integration driver, extend the synthetic secrets map
+with object-storage values and explicitly supply representative S3 and publish
+variables. Use `narratio config validate` and its secret-safe effective
+configuration output to prove that the public inputs compose into a valid
+configuration. Retain the immediate clean repeat and secret non-disclosure
+checks. Do not call a real S3 service or assert that the representative values
+equal current role defaults.
+
+Push the reviewed pipeline commit, import that exact public revision into the
+collection through `git subtree pull --squash`, and extend only the
+collection-level fixture inputs needed for native validation. The collection
+suite should continue to prove artifact installation and one representative
+assembled convergence rather than duplicate the detailed pipeline matrix.
+
+## Rationale and Alternatives
+
+Implementing storage behavior in Ansible would duplicate a mature native
+application boundary. Narratio already owns credential resolution, AWS SDK
+provider construction, immutable commits, verification, locks, restore,
+caching, and cleanup. Passing declarative configuration through the generic
+role is both smaller and more reliable.
+
+Using the AWS SDK's ambient provider chain would avoid named secret files, but
+the initial deployment has explicit Backblaze application credentials and the
+suite already has a suitable managed typed-secret path. Keeping the two
+credential-reference variables nullable preserves the ambient-provider
+alternative: consumers can set both suite variables to `null` when their
+deployment uses another provider.
+
+Copying destinations into every publish rule would make the output layout more
+visible locally, but it would duplicate paths already owned by Narratio's
+built-in sources and the configured artifact definitions. Native destination
+derivation keeps path coordination automatic.
+
+Omitting explicit `required: true` values would avoid the v2.1.0 failure only
+by relying on an unrelated defaulting path. Changing the generic role's YAML
+format would not repair the underlying sequence-resolution mismatch. Narratio
+v2.1.1 fixes the owning application boundary, allowing the suite to state its
+requiredness policy directly without duplicating destinations.
+
+Deleting spool audio after publication would minimize transient disk usage,
+but no such retention policy has been selected, and local-audio sessions may
+depend on that content. Leaving the field omitted preserves Narratio's default
+while enabling the explicitly requested S3 audio cache.
+
+Publishing all ten Notarius extraction lanes would create stable remote output
+contracts that have not been requested. It is also unnecessary for the stated
+future use: analyze-stage artifacts can consume `narratio.extraction.*`
+directly. The immutable published run retains the processing result, while the
+selected transcript and human-facing artifact outputs match the known
+operational workflow.
+
+## Acceptance Criteria
+
+- The pipeline role declares and documents every suite variable shown in the
+  target state, with matching argument-spec entries and direct Narratio
+  dependency mappings.
+- The pipeline installs Narratio v2.1.1, whose released configuration loader
+  supports explicit requiredness together with derived publish destinations.
+- The two credential-reference variables accept paired `null` overrides so a
+  caller can deliberately select Narratio's ambient AWS SDK provider chain.
+- The default effective Narratio configuration selects the specified
+  Backblaze-compatible S3 destination, typed credential names, S3 audio cache,
+  successful-publication workspace cleanup, run upload, and seven output
+  rules.
+- The publish list relies on Narratio's native destination derivation and
+  retains `deranged_rumors` as optional while the other six outputs are
+  required.
+- Spool-audio deletion remains unset by the pipeline role, and the testing
+  profile introduces no storage or publication override.
+- `dnd_pipeline_secrets` remains a generic empty-by-default mapping; the role
+  documents all four expected operational entries without embedding any
+  credential value.
+- No new production task, template, handler, fact, state file, wrapper, or
+  storage-validation command is introduced.
+- The standalone Narratio role remains unchanged because its `v0.1.0` role
+  interface can install Narratio v2.1.1, renders the required native fields,
+  and preserves null omission.
+- The existing pipeline integration scenario explicitly supplies
+  representative S3 and publish inputs, resolves synthetic values for all four
+  typed credentials, passes Narratio's native configuration validation, and
+  exposes no synthetic value in captured output.
+- The immediate identical second pipeline application reports `changed=0`
+  and `failed=0`; syntax checking, production-profile lint, the complete
+  standalone integration suite, and `git diff --check` pass.
+- The exact reviewed pipeline commit is pushed to public Gitea before the
+  collection imports it through the documented remote-only squashed subtree
+  workflow.
+- The collection fixture supplies the added synthetic credential names, and
+  its existing build, isolated installation, FQCN resolution, native
+  validation, and clean-repeat suite passes without a duplicate S3 behavior
+  test.
+- No real object-storage request, paid model request, application repository
+  change during the remaining implementation, asset change, new release tag,
+  or published artifact is required. The existing Narratio v2.1.1 release is a
+  prerequisite rather than an implementation deliverable.
+- Pipeline documentation links operators to Narratio's canonical procedures
+  for S3 session audio, publish, restore, locks, status, and cleanup and no
+  longer describes storage and publishing as deferred.
+- Documentation distinguishes accepted Notarius extraction sources from
+  published outputs and confirms that future analyze-stage artifacts may use
+  `narratio.extraction.<output_key>` inputs without publishing those lanes.
+
+## Dependencies and Follow-up Work
+
+Features 0009, 0011, 0012, 0013, and 0014 and the public Narratio v2.1.1 bugfix
+release are prerequisites. In particular, Feature 0011 supplies the credential
+directory and Feature 0014 supplies the human-operator access needed for the
+eventual live deployment.
+
+[Feature 0016](0016-deploy-dnd-pipeline-to-pipeline-dnd.md) follows this work.
+It will put the four actual values in encrypted host inventory, pin the exact
+reviewed suite revision in `rakestraw-ansible`, converge `pipeline-dnd`, and
+exercise one real session through remote publication. Bucket lifecycle policy,
+backup policy, credential rotation, additional publish outputs, automated
+scheduling, and cleanup of the proof-of-concept deployment remain separate
+future work.
+
+A later artifact-development feature may add D&D-specific Narratio artifact
+definitions whose Scriptorium input mappings consume selected
+`narratio.extraction.*` sources. That feature should define each artifact's
+purpose, inputs, prompt, output contract, and publication choice; it does not
+require a storage-interface change.

docs/roadmap/features/0016-deploy-dnd-pipeline-to-pipeline-dnd.md

@@ -0,0 +1,149 @@
+# Feature 0016: Prepare the D&D Deployment Playbook for `pipeline-dnd`
+
+Status: done
+
+## Summary
+
+Write and commit the consumer playbook, necessary host variables, dependency
+manifest, and concise usage documentation in `rakestraw-ansible`. This feature
+ends with repository preparation. Deployment to a controller or target host
+and execution of the pipeline are separate operator work.
+
+## Scope
+
+- `playbooks/pipeline/dnd.yml` targets the existing `pipeline-dnd` alias and
+  applies `rakestraw.dnd.pipeline`, using only hosts and roles.
+- Host choices belong in `inventory/host_vars/pipeline-dnd/`: the WhisperX
+  endpoint, initial operator `eric`, default campaign `dilfs`, and credential
+  references. Unknown required values are explained in adjacent comments.
+- Inherit the reviewed suite's storage, publication, caching, cleanup, and
+  application defaults. Retire obsolete legacy host variables.
+- Root `requirements.yml` selects the reviewed public collection snapshot and
+  its role/native collection dependencies, preserving unrelated entries.
+- Document local validation and eventual operator use. Commit the completed
+  repository changes without requiring remote access or real credentials.
+
+## Non-goals
+
+- Installing or updating anything on the operational controller or target.
+- Connecting to `pipeline-dnd`, validating its platform or sudo access,
+  converging the host, checking runtime identities, or executing a real session.
+- Obtaining API keys, choosing a Vault password, populating real credentials,
+  or selecting acceptance audio/session data.
+- Changing application/role behavior, publishing a new suite release, adding
+  orchestration layers, or retiring the proof-of-concept role/playbook.
+
+## Target End State
+
+The committed playbook is:
+
+```yaml
+---
+- hosts:
+    - pipeline-dnd
+  roles:
+    - rakestraw.dnd.pipeline
+...
+```
+
+Existing connection variables remain in the host's `main.yml`. Its
+`narratio.yml` contains the following public configuration and comments:
+
+```yaml
+dnd_pipeline_operator_users:
+  - eric
+
+dnd_pipeline_whisperx_transcribe_url: >-
+  https://transcription.ai.rakestrawhome.com/transcribe
+
+narratio_campaigns_default_campaign_id: dilfs
+
+# Before deployment, define the four vault_dnd_* variables below in an
+# Ansible Vault-encrypted host_vars/pipeline-dnd/vault.yml file.
+# Values are not known here; leave these references unresolved until supplied.
+# Do not put API keys or object-storage credentials in this plaintext file.
+dnd_pipeline_secrets:
+  AUDITA_LLM_API_KEY: "{{ vault_dnd_audita_llm_api_key }}"
+  OPENROUTER_API_KEY: "{{ vault_dnd_openrouter_api_key }}"
+  OBJECT_STORAGE_KEY_ID: "{{ vault_dnd_object_storage_key_id }}"
+  OBJECT_STORAGE_KEY: "{{ vault_dnd_object_storage_key }}"
+```
+
+The references and comments are a complete deliverable for unknown secrets.
+No encrypted file, placeholder key, or real credential is required for feature
+completion. Future operator-supplied values should be Vault-encrypted in Git;
+the suite's existing restricted runtime secrets files remain the delivery path.
+
+The manifest pins the collection to
+`2a53979069ff8d091172650729ae2135c1603163`, containing pipeline commit
+`f48008aa38e1c50adde18aa455d12a8ad77023c2` with Narratio v2.1.2.
+Its five standalone role dependencies
+use their reviewed `v0.1.0` tags, with `ansible.posix` `2.2.0` and
+`community.general` `13.3.0`. Suite Git dependencies use public Gitea URLs;
+native collections come from Galaxy. Local sibling checkouts are not dependencies.
+
+The runbook explains that the selected collection snapshot still reports
+`0.1.0`, so eventual operator installation must explicitly refresh it from
+the pinned commit if an older `0.1.0` is installed. This is an instruction
+for future use, not an operation required by this feature.
+
+## Repository Ownership
+
+- `rakestraw-ansible`: consumer files, comments, dependency manifest, and runbook.
+- Workspace: roadmap, staged plan, progress, and independent review record.
+- Roles, collection, applications, and assets: read-only contract references.
+
+## Constraints and Settled Decisions
+
+The workspace [Ansible](../../ansible.md), [testing](../../testing.md), and
+[planning](../../planning.md) policies apply. Feature 0015 has passed review
+and supplies the required suite interface.
+
+- Keep playbooks minimal and settings in inventory. Preserve `pipeline-dnd`
+  and its connection identity; do not rename it to `pipeline.dnd`.
+- Preserve `dilfs` using the existing standalone Narratio variable. Remove
+  legacy `narratio_s3_*` and `narratio_default_campaign_id` host settings.
+- Missing operational inputs are documented, not treated as implementation
+  blockers. No remote controller, SSH identity, Vault password, or session is
+  required for repository preparation.
+- Local dependency installation and syntax/host-selection checks are permitted.
+  Existing passing evidence may be reused when relevant inputs are unchanged.
+- `ansible-doc` rendering is not an acceptance gate. Missing role argument
+  descriptions are a separate documentation improvement.
+
+## Simplest Viable Implementation
+
+Retain the already-committed minimal playbook, manifest, and public inventory.
+Add adjacent comments for unresolved credentials, align the runbook with the
+repository-only scope, perform appropriate local checks, and commit. No new
+Ansible task, runtime test harness, or deployment automation is needed.
+
+## Acceptance Criteria
+
+- The playbook targets only `pipeline-dnd` and applies only the collection role.
+- Host inventory expresses the known choices above and documents unknown
+  credentials next to their references without real or fake secret values.
+- The dependency manifest contains the reviewed public pins and preserves
+  unrelated dependencies. Public installation and local syntax/host-selection
+  evidence are available; no documentation-rendering check is required.
+- The runbook distinguishes repository readiness from future deployment and
+  explains how the operator supplies missing values and eventually invokes it.
+- Changes are committed in the owning repositories, with clean working trees
+  for the feature's changes. No controller deployment, target convergence,
+  clean-repeat run, or real pipeline execution is required or claimed.
+- Historical role/playbook files remain available.
+
+## Dependencies and Follow-up Work
+
+Features 0013–0015 supply public dependencies, operator enrollment, and storage
+policy. Consumer preparation was completed in `716a80e`, `12b2462`, and
+`7f8353d`, and passed independent review with no remediation findings.
+Public dependency installation, target-only host listing, syntax checking,
+and whitespace validation passed. Subsequent consumer commit `7f4c90a`
+updates the collection pin for the Narratio v2.1.2 bug fix; collection build
+and syntax validation passed. These changes are committed and published.
+
+The operator may later provision Vault values, install dependencies on their
+controller, deploy to the host, and validate real processing/publication.
+Those actions require a separate request and are not unfinished Feature 0016
+acceptance requirements.

docs/roadmap/features/0017-notarius-testing-overlay.md

@@ -0,0 +1,199 @@
+# Feature 0017: Notarius Testing Overlay
+
+Status: done
+
+## Summary
+
+Selecting Narratio's `testing` profile also selects a separately managed
+Notarius `testing` configuration overlay. Operators can develop D&D assets
+with economical extraction settings without modifying production configuration
+or invoking Notarius separately.
+
+## Problem or Opportunity
+
+The suite's existing testing overlay changes Scriptorium selections but leaves
+Notarius on its production configuration. Narratio v2.2.0 now provides the
+explicit `pipeline.notarius.config_profile` interface requested by this consumer.
+Notarius v0.7.1 retains the corresponding `--config-profile` option and updates
+PromptKit and its provider catalogs. This feature adopts v0.7.1 as its baseline.
+
+## Scope
+
+- Expose the optional native selector in the standalone Narratio role.
+- Update standalone Notarius and suite version defaults to v0.7.1, with
+  matching current-version documentation and collection distribution.
+- Deploy a Notarius ConfigKit testing overlay through the suite role.
+- Explicitly select that overlay from Narratio's existing testing overlay.
+- Select `gpt-terra-latest` for production and `gpt-luna-latest` for testing,
+  while retaining inventory overrides for both choices.
+- Document and validate the composed configuration, then distribute the
+  updated suite through the collection and refresh the consumer dependency pin.
+
+## Non-goals
+
+- Further upstream application changes or a Narratio-side LLM-profile override.
+- Automatically propagating profile names between applications.
+- Disabling Notarius, caching, publishing, or other pipeline stages for testing.
+- New credentials, cache layouts, other production tuning, or deployment automation.
+- Live controller/target deployment or paid model calls as completion gates.
+
+## Target End State
+
+### Standalone Narratio Interface
+
+`narratio_notarius_config_profile` defaults to `null`. The role omits
+`notarius.config_profile` when null and serializes explicitly supplied values,
+including an empty string. Documentation and argument specifications expose
+the field without duplicating or narrowing Narratio's selector semantics.
+
+### Explicit Suite Composition
+
+The suite leaves the base selector unset. Its existing Narratio
+`profiles/testing.yml` includes:
+
+```yaml
+notarius:
+  config_profile: testing
+```
+
+The suite deploys `/usr/local/etc/notarius/profiles/testing.yml`. That file
+overlays the selected suite pipeline's `llm_profile`, using
+`dnd_pipeline_narratio_notarius_pipeline_id` as the pipeline key and a new
+`dnd_pipeline_notarius_testing_llm_profile` variable as the value. It does not
+copy the full pipeline definition. ConfigKit performs the ordinary merge.
+
+The default suite pipeline currently inherits its LLM selection at pipeline
+level. Caller-supplied binding-level selections retain Notarius's native
+precedence; this feature does not rewrite arbitrary caller pipelines or promise
+that a pipeline-level default overrides explicit binding choices.
+
+### Production and Testing LLM Defaults
+
+The suite's base `dnd-session` pipeline selects `llm_profile: gpt-terra-latest`
+instead of `dnd-extraction`. Callers can continue overriding that choice through
+the existing `dnd_pipeline_notarius_pipelines` mapping. The new
+`dnd_pipeline_notarius_testing_llm_profile` defaults to `gpt-luna-latest`.
+
+Both IDs are supplied by the OpenRouter catalog `v2.20260922.1` selected by
+Notarius v0.7.1. Use those native catalog profiles directly; no operator profile
+asset or profile-source setting is needed for these defaults. Retain the
+existing `OPENROUTER_API_KEY` credential reference. These are deliberately
+moving `latest` selections, not promises of immutable underlying model versions.
+This production-model policy belongs to the suite, not the standalone role.
+
+Notarius stays enabled and retains its configured caching, output contracts,
+references, and production defaults outside this overlay. Existing Scriptorium
+testing overrides remain intact. Credentials continue through the existing
+typed reference and suite secrets interfaces; no credential values enter YAML.
+
+Configuration files and directories use the suite's existing owner, group,
+and mode variables. The selector and overlay add no new runtime identity or
+filesystem-permission policy.
+
+## Repository Ownership
+
+- `ansible-role-narratio`: generic optional selector, documentation, and tests.
+- `ansible-role-notarius`: v0.7.1 installation default and corresponding
+  documentation; existing profile-source settings remain sufficient.
+- `ansible-role-dnd-pipeline`: testing policy, overlay assets, and composition.
+- `ansible-collection-dnd`: imported pipeline snapshot and compatible dependency
+  manifest. Its current Narratio-role `v0.1.0` pin must advance to include the
+  new public variable; changing only the sibling role is insufficient.
+- `rakestraw-ansible`: matching dependency pins and concise operator guidance.
+- Workspace: roadmap, implementation plan, progress, and review.
+- Narratio and Notarius applications: read-only authoritative contracts.
+  The standalone Notarius role already exposes profile-source settings and
+  does not need D&D-specific overlay policy.
+
+## Constraints and Settled Decisions
+
+Follow the [MVP roadmap](../mvp.md), [Ansible house style](../../ansible.md),
+and [testing house style](../../testing.md). Narratio v2.2.0 is already selected
+by the suite; Notarius v0.7.1 is the selected target. Consult these tags, not
+only newer application checkouts.
+
+### Notarius v0.7.1 Compatibility
+
+The [upstream release notes](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.7.1/docs/releases/v0.7.1.md)
+describe unchanged CLI, configuration, artifact, and subprocess contracts.
+The application-owned `dnd-extraction` fallback retains its settings and no
+configuration migration is required. Independently of that upstream behavior,
+the user has selected `gpt-terra-latest` as this suite's new production default.
+
+Profile selection must use the catalogs selected by v0.7.1 (PromptKit v0.10.0).
+The removed `deepseek-3-2`, `deepseek-4-flash`, and `deepseek-4-pro` catalog IDs
+must not be assumed available or silently replaced by similarly named profiles.
+This is deployment guidance, not a request for an Ansible catalog validator.
+
+Existing checkpoints with the previous profile-source identity are not reused;
+source-keyed chunk plans and existing output artifacts are unaffected. Document
+this upstream upgrade behavior without deleting caches or forcing Narratio
+extraction automatically.
+
+Each application owns its configuration. Narratio selects the downstream
+overlay; Notarius resolves and validates it. Existing application behavior owns
+extraction reuse when selections change and explicit-force handling for changes
+behind a stable profile name. Do not add Ansible state tracking for either.
+
+## Simplest Viable Implementation
+
+Add one nullable role field and its conditional template output. Extend the
+suite's existing directory/template management to deploy the Notarius overlay
+and extend the existing Narratio testing template with the explicit selector.
+Use native serialization and ordinary file/template modules. Select the two
+existing catalog IDs rather than deploying duplicate profile definitions. No assembly facts,
+preflight state probes, or generic overlay-management framework is required.
+
+## Rationale and Alternatives
+
+A downstream ConfigKit overlay can own model choices and later Notarius tuning
+without expanding Narratio's configuration surface for each setting. Direct
+LLM-profile forwarding would solve only the model-selection case. Automatic
+profile propagation would couple unrelated profile names and is not selected.
+
+## Acceptance Criteria
+
+- The standalone role omits an unset selector and preserves explicitly supplied
+  representative values, including the empty-string base selector.
+- Native configuration inspection shows Narratio testing selecting Notarius
+  testing, and Notarius testing selecting the requested LLM profile. Base
+  configuration retains its production selection.
+- A representative inventory-supplied testing selection is supported. Tests
+  exercise behavior rather than asserting that today's default model stays fixed.
+- Notarius's deployed-version validation accepts the composed pipeline and
+  selected profile. No paid inference is required.
+- Existing integration coverage remains valid, and immediate repeated role
+  convergence reports no changes. Do not independently retest file-module
+  ownership, modes, or template-file existence.
+- The built collection works with its declared public role dependencies; no
+  local sibling checkout is needed by consumers. Subtree imports follow the
+  documented public-Gitea workflow, and published tags remain immutable.
+
+## Dependencies and Follow-up Work
+
+The upstream selector shipped in Narratio v2.2.0; the downstream baseline is
+now Notarius v0.7.1. Git history preserves the completed implementation plan.
+Future testing-specific Notarius settings belong in its overlay but are not
+implicitly included in this feature.
+
+## Completion and Review Evidence
+
+Completed and published in Narratio role `330afe7`, Notarius role `a82a83d`,
+pipeline role `c56a942`, collection `ce5b838`, and consumer `0ced48c`.
+
+Implementation reported passing full integration suites for both changed
+application roles, the pipeline, and the collection, including clean repeated
+convergence. Independent review found no code-quality issues, architecture gaps,
+or unnecessarily strengthened requirements requiring remediation.
+
+The review independently verified collection build and public dependency
+installation, syntax and shell checks, native configuration validation,
+consistent dependency pins, and exact subtree/source agreement. It reviewed
+the recorded integration results without rerunning host-mutating suites.
+Operational deployment and paid inference were neither required nor performed
+as part of this feature review.
+
+## Open Questions
+
+None. The user selected `gpt-luna-latest` for testing and `gpt-terra-latest`
+for production; both are available in the catalog selected by Notarius v0.7.1.

docs/roadmap/features/0018-scriptorium-v0-15-adoption.md

@@ -0,0 +1,163 @@
+# Feature 0018: Adopt Scriptorium v0.15.0 in the Standalone Role
+
+Status: done
+
+## Summary
+
+Update the standalone Scriptorium role from v0.13.0 to v0.15.0 and expose its
+new application-configuration settings using our existing nullable-variable
+conventions. This is the first feature in the agreed
+[application upgrade sequence](../application-upgrade-sequence.md).
+
+## Problem or Opportunity
+
+Although v0.15.0 primarily changes licensing and dependency versions, the
+intervening v0.14.0 adopted ConfigKit and added application imports, overlays,
+inspection, and transient retry controls. A version bump alone would leave
+new configuration settings unavailable through the role's public interface.
+
+The current role already emits `{}` for an unconfigured installation, omits
+null optional fields, serializes mappings, and retains explicit falsey values.
+Those practices remain compatible with the stricter upstream configuration
+contract; no new production validation or migration mechanism is needed.
+
+## Scope
+
+- Adopt v0.15.0 as the standalone role's default source version.
+- Expose ConfigKit imports and the application transient-retry setting.
+- Confirm existing configuration variables and representative backend mappings
+  remain usable with the new application version.
+- Update role documentation and focused offline integration coverage.
+- Record completion and the role revision for later coordinated integration.
+
+## Non-goals
+
+- Changing pipeline, collection, consumer, or other application-role pins.
+- D&D model choices, production/testing policy, or new provider credentials.
+- Deploying prompt/profile/schema libraries or managing arbitrary overlay files.
+- Selecting a runtime overlay for callers, managing a service, or adding HTTP
+  request/CLI-only controls such as execution reports and run deadlines to YAML.
+- Upstream application changes, paid inference, or operational host deployment.
+- Relicensing this Ansible role or copying upstream source/license material
+  into the role repository merely because the installed application changed.
+
+## Target End State
+
+### Installation and Existing Configuration
+
+`scriptorium_version` defaults to `v0.15.0`. Retain the existing source checkout,
+Go build, ownership, and permission behavior and the caller-selected version
+interface. No build-toolchain change is required: the current Go 1.26 selection
+satisfies the release's Go requirement.
+
+Existing application fields keep their public variable names. Optional variables
+remain null by default and are omitted; explicit supported zero/empty values
+are serialized without truthiness checks. An installation with no application
+settings still receives `{}`, not an empty file.
+
+### New Public Variables
+
+| Variable | Default | Rendered field |
+| --- | --- | --- |
+| `scriptorium_configkit_imports` | `null` | `configkit.imports` |
+| `scriptorium_transient_retries` | `null` | `transient_retries` |
+
+Imports are a native list of mapping entries, consistent with the other roles'
+ConfigKit interfaces. Serialize the supplied list without reinterpreting path,
+glob, or optional-entry semantics. Emit the parent section only when selected.
+The caller owns referenced fragment and overlay files; ordinary inventory can
+compose the list without a second raw-configuration interface.
+
+Transient retries is an optional integer. Null means omit and inherit the
+application/PromptKit default; zero explicitly disables additional transient
+attempts. The standalone role does not freeze the upstream default or add a
+retry budget of its own. Argument specifications and documentation describe
+both variables consistently.
+
+### Compatibility Guidance
+
+Document the distinction between ConfigKit `overlays/` selected by
+`--config-overlay` and PromptKit LLM profiles. Imports are configuration-root
+relative, while application path values retain their process-working-directory
+semantics. Link upstream for detailed validation and precedence rules.
+
+Call out stricter YAML acceptance and changed retry behavior, plus the removal
+of legacy DeepSeek catalog IDs, without installing compatibility aliases or
+inventing role-side configuration guards. New fields should only be supplied
+when selecting an application version that supports them.
+
+Mention that Scriptorium v0.15.0's application grant is GPL-3.0-or-later and link
+its tagged licensing notices. Do not conflate the application's grant with the
+role's license or introduce legal approval as a deployment gate.
+
+## Repository Ownership
+
+- `ansible-role-scriptorium`: default version, variables, argument specification,
+  template, README, and repository-local tests.
+- Workspace: feature roadmap, staged plan, progress, and review evidence.
+- Scriptorium application: read-only tagged configuration/release contracts.
+- Pipeline, collection, consumer, and asset repositories remain unchanged.
+
+## Constraints and Settled Decisions
+
+Follow the [Ansible house style](../../ansible.md),
+[testing house style](../../testing.md), [MVP roadmap](../mvp.md), and
+[upgrade sequence](../application-upgrade-sequence.md). Review the tagged
+v0.15.0 contract rather than assuming later application changes apply.
+
+The existing suite continues installing its current Scriptorium role/application
+pins until final integration. Standalone adoption is not suite publication.
+
+## Simplest Viable Implementation
+
+Update the version default and extend the existing defaults, argument
+specification, and single configuration template with the two optional fields.
+Include both in the empty-document condition. Reuse the existing source/build
+and file/template tasks unchanged. No additional runtime tasks are needed.
+
+## Acceptance Criteria
+
+- The default role installs v0.15.0 and native offline configuration validation
+  accepts the default and representative managed configurations.
+- Representative non-null and falsey values remain correctly rendered; the new
+  retry field preserves explicit zero and is omitted when unset.
+- A caller-supplied import is composed successfully by native configuration
+  inspection using a small externally supplied test fragment. An optional test
+  overlay can demonstrate native composition without adding role-owned overlay
+  management or retesting ConfigKit's complete precedence/error matrix.
+- Existing offline profile/backend inspection remains useful and passes.
+  Application validation alone does not prove PromptKit source validity.
+- Immediate repeated role application reports no changes. Tests assert supplied
+  configuration outcomes, not today's upstream/default version, catalog contents,
+  task arrangement, or file-module postconditions.
+- Syntax/lint and repository integration checks pass without provider calls,
+  real secrets, or operational controller access.
+- Suite and consumer pins remain unchanged, and completion identifies the role
+  commit available for the final integration feature.
+
+## Dependencies and Follow-up Work
+
+Git history preserves the completed staged plan.
+Audita adoption is next. The eventual suite integration
+feature owns propagation of the new role revision, deployment settings, and
+coordinated upgrade guidance.
+
+## Completion and Review Evidence
+
+Completed in role commits `61dcafe`, `2fce529`, and `b174c8c`. Implementation
+reported passing integration tests, including native configuration validation,
+offline profile inspection, imports, explicit retry zero, and clean repeat
+convergence. Independent review found no code-quality issues, implementation
+gaps, or unnecessarily strengthened requirements requiring remediation.
+
+Independent syntax, production-profile lint, shell syntax, whitespace, native
+configuration validation, and focused template checks passed. The review used
+recorded integration evidence without rerunning host-mutating suites. No new
+production tasks or suite/collection/consumer pin changes were introduced.
+No operational deployment is claimed.
+
+## Upstream References
+
+- [v0.15.0 configuration](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/config.md)
+- [v0.14.0 migration notes](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.14.0/docs/releases/v0.14.0.md)
+- [v0.15.0 release and licensing notes](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/releases/v0.15.0.md)

docs/roadmap/features/0019-audita-v2-adoption.md

@@ -0,0 +1,199 @@
+# Feature 0019: Adopt Audita v2.0.1 in the Standalone Role
+
+Status: done
+
+## Summary
+
+Replace the standalone Audita role's version-1 configuration interface with
+Audita v2.0.1's native interface. Keep provider and D&D policy outside the
+generic role. This is the second feature in the agreed
+[application upgrade sequence](../application-upgrade-sequence.md).
+
+## Problem or Opportunity
+
+The role currently installs Audita v0.9.1 and renders version-1 configuration.
+Audita v2 requires version-2 YAML, named backends, and selected PromptKit
+profiles. Old per-role endpoint/model/credential/concurrency settings no longer
+apply. A version-only update would produce an unusable deployment.
+
+Unlike the previous minimal configuration, a valid v2 configuration requires
+at least one backend and a proposal profile whose file exists. The generic role
+must not invent a provider, endpoint, model, or credential to meet that contract.
+The caller-input boundary is settled below.
+
+## Scope
+
+- Default to Audita v2.0.1 and configuration version 2.
+- Replace retired public configuration variables with native v2 settings.
+- Preserve still-supported domain controls and inventory composition.
+- Document the breaking role-variable migration and caller prerequisites.
+- Adapt offline integration tests to real v2 configuration/profile fixtures.
+
+## Non-goals
+
+- Updating pipeline, collection, or consumer application/dependency pins.
+- Choosing D&D models, endpoints, credentials, concurrency, or retry budgets.
+- Compatibility shims, automatic v1 conversion, or a dual-schema template.
+- Live inference, operational deployment, report ingestion, service management,
+  or runtime configuration validation tasks.
+- Imports: Audita deliberately disables ConfigKit imports. Do not add an import
+  variable merely because other applications expose one.
+- Automatically provisioning secret values or selecting runtime overlays.
+
+## Target End State
+
+### Installation and Schema
+
+`audita_version` defaults to `v2.0.1`; `audita_config_version` defaults to `2`.
+Retain the existing source checkout, conditional Go build, dependency management,
+configuration location, and owner/group/mode interfaces. Go 1.26 remains suitable.
+The role renders v2 only; selecting an older application does not translate its
+configuration. Operators needing v1 retain the previous role revision.
+
+### Public Configuration Interface
+
+Use these field-specific variables; optional settings default to null and are
+omitted, allowing Audita to own defaults. Serialize native values and preserve
+intentional zero, false, empty strings, and empty collections where supported.
+
+| Role variable | Native field | Ownership |
+| --- | --- | --- |
+| `audita_profiles_dir` | `profiles_dir` | Optional caller profile location |
+| `audita_backends` | `backends` | Caller-supplied native mapping |
+| `audita_llm_proposal_profile` | `llm.proposal_profile` | Caller-selected required profile |
+| `audita_llm_validation_profile` | `llm.validation_profile` | Optional; omission inherits proposal |
+| `audita_llm_transient_retries` | `llm.transient_retries` | Optional native retry budget |
+| `audita_llm_repair_attempts` | `llm.repair_attempts` | Optional native repair budget |
+| `audita_llm_operation_timeout` | `llm.operation_timeout` | Optional duration string |
+| `audita_validation_max_prompt_tokens` | `validation.max_prompt_tokens` | Optional batching control |
+| `audita_reporting_enabled` | `reporting.enabled` | Optional report policy |
+| `audita_reporting_stdout_dir` | `reporting.stdout_dir` | Optional report destination |
+| `audita_diagnostics_debug` | `diagnostics.debug` | Optional debug policy |
+
+Retain existing variables for modules, output schema, chunking, normalization,
+thresholds, context description, and diagnostics work directory. Normalization
+gap/duration fields now represent numeric seconds, not duration strings.
+Argument specifications must accept the native integer/fractional values without
+turning them into quoted strings in YAML. Do not add a duration-conversion layer.
+
+Remove the old `audita_llm_{proposal,validation}_{base_url,model,api_key_env,timeout,max_retries}`,
+`audita_concurrency_{total_llm,proposal_llm,validation_llm}`, and
+`audita_diagnostics_retention` interfaces from defaults, templates, argument
+specifications, and current examples. Document their replacements rather than
+silently interpreting them under different semantics or adding deprecation probes.
+
+The backend mapping carries endpoint, credential reference, concurrency, and
+queue capacity using Audita's schema. Inventory can compose it with ordinary
+Jinja expressions. Credential values stay outside the role; every surviving
+backend reference must be available when Audita loads configuration, even when
+that backend is not selected. Do not introduce separate per-role secret variables.
+
+Null role variables mean omission, not literal YAML null. In particular, omit
+an unset validation profile so Audita can inherit the proposal selection.
+Backend mapping values retain native semantics, including a null credential.
+
+### Profile and Overlay Ownership
+
+Callers provide `audita_backends` and `audita_llm_proposal_profile`; neither has
+a fabricated concrete default. Callers also deploy the selected profile files
+before invoking Audita. `audita_profiles_dir` may be supplied or omitted to use
+Audita's conventional sibling `profiles/` directory. Keep profile documents and
+ConfigKit `overlays/` content caller-owned in this feature.
+
+The later suite feature will own its D&D profile assets and coordinate their
+deployment with Narratio's new external Audita configuration contract. The role
+does not start processing or validate file availability during convergence.
+
+## Repository Ownership
+
+- `ansible-role-audita`: generic installation/configuration interface, migration
+  documentation, and local tests.
+- Workspace: roadmap, active plan, progress, and review evidence.
+- Audita application: read-only tagged schema, migration, and profile contracts.
+- Other applications/roles, assets, pipeline, collection, and consumer: unchanged.
+
+## Constraints and Settled Decisions
+
+Follow the [Ansible house style](../../ansible.md),
+[testing house style](../../testing.md), [MVP roadmap](../mvp.md), and
+[upgrade sequence](../application-upgrade-sequence.md). The suite continues to
+use its old compatible role/application set until final integration; Narratio v2
+must not be accidentally paired with Audita v2 through a changed suite pin.
+
+Old timeouts and retries do not map one-to-one to profile per-attempt timeouts,
+logical-operation deadlines, transport retries, and structural repair. Expose
+native controls without choosing replacement tuning for the D&D suite here.
+
+## Simplest Viable Implementation
+
+Update the version/schema defaults and replace the single configuration template's
+retired sections with native v2 sections. Align argument specifications and the
+README. Keep ordinary file/template/source/build tasks. Use the existing test
+harness with caller-owned local backend/profile fixtures; add no state assembly,
+profile resolver, migration command, or production probe.
+
+## Acceptance Criteria
+
+- The role installs v2.0.1 and renders native v2 configuration from supplied
+  backend/profile choices and optional settings.
+- Native offline validation and effective-settings/profile inspection accept
+  representative configuration with an externally supplied profile and local
+  fixture endpoint; no provider request is needed.
+- Tests cover supplied mapping composition, omission/inherited validation
+  selection, representative numeric seconds, and meaningful zero/false values.
+  Avoid a comprehensive schema matrix or assertions of current upstream defaults.
+- Existing useful build and clean-repeat coverage remains. Immediate repeated
+  role convergence reports no changes; do not test module postconditions.
+- Documentation explains required caller inputs and the breaking variable/schema
+  migration, linking Audita for full field and report semantics.
+- No suite, collection, or consumer pins change. Completion records the reviewed
+  standalone role revision for the final integration feature.
+
+## Rationale and Alternatives
+
+Native backend mappings and named profiles preserve Audita's ownership instead
+of reproducing per-role endpoint/model settings in Ansible. A dual-schema role
+would add maintenance and ambiguity without a selected requirement; retaining
+the previous role revision is the simpler boundary for old deployments.
+
+## Dependencies and Follow-up Work
+
+Git history preserves the completed staged plan. Notarius adoption is next.
+D&D backend/profile assets,
+tuning migration, testing overlays, credential lists, and coordinated deployment
+belong to the later integration feature.
+
+## Settled Caller-Input Decision
+
+The user approved required `audita_backends` and `audita_llm_proposal_profile`
+inputs through the ordinary role argument interface, with caller-owned profile
+files. Do not give these variables null or fabricated defaults. A no-input role
+invocation is no longer valid; examples and tests supply explicit choices.
+Role-managed profile definitions are not part of this feature.
+
+## Open Questions
+
+None.
+
+## Completion and Review Evidence
+
+Completed in role commits `6137ff2`, `52f67fe`, and `c3dd59f`. Implementation
+reported passing integration tests with native v2 validation, offline profile
+inspection, mapping composition, omission, numeric seconds, falsey values,
+build/recovery coverage, and clean repeated convergence.
+
+Independent review found no code-quality issues, implementation gaps, or
+unnecessarily strengthened requirements needing remediation. Independent
+Ansible syntax, production-profile lint, shell syntax, whitespace, and focused
+template checks passed. The review used recorded native/integration results
+without rerunning the host-mutating suite.
+
+No production tasks were added. Profile files remain caller-owned, and suite,
+collection, and consumer pins remain unchanged. No operational deployment or
+paid inference was performed as part of this review.
+
+## Upstream References
+
+- [v2.0.1 configuration](https://gitea.maximumdirect.net/eric/audita/src/tag/v2.0.1/docs/config.md)
+- [v2 migration guide](https://gitea.maximumdirect.net/eric/audita/src/tag/v2.0.1/docs/migrations/v2.md)
+- [v2.0.1 release](https://gitea.maximumdirect.net/eric/audita/src/tag/v2.0.1/docs/releases/v2.0.1.md)

docs/roadmap/features/0020-notarius-v0-8-adoption.md

@@ -0,0 +1,173 @@
+# Feature 0020: Adopt Notarius v0.8.1 in the Standalone Role
+
+Status: done
+
+## Summary
+
+Update the standalone Notarius role from v0.7.1 to v0.8.1, expose the new
+PromptKit transient-retry setting, and document the ConfigKit overlay rename.
+This is the third feature in the agreed
+[application upgrade sequence](../application-upgrade-sequence.md).
+
+## Problem or Opportunity
+
+Notarius v0.8.0 renamed configuration selection to `--config-overlay` and
+`overlays/<name>.yml`, removing the previous flag and lookup directory. It also
+introduced configurable provider transport retries. v0.8.1 updates ConfigKit
+and PromptKit to v0.4.2 and v0.11.2 without further intentional configuration or
+subprocess-contract changes.
+
+The standalone role currently renders schema version 5, supports native imports
+and caller-supplied pipelines, and leaves profile assets externally managed.
+Those boundaries remain appropriate. The suite, however, still uses the old
+downstream selector; its application and dependency pins must not advance yet.
+
+## Scope
+
+- Default the standalone role to Notarius v0.8.1.
+- Expose `promptkit.transient_retries` through one nullable role variable.
+- Verify existing imports, pipeline composition, profile-source settings, and
+  cache configuration remain compatible with the target release.
+- Update standalone compatibility guidance and focused offline tests.
+- Record the reviewed role revision for later coordinated suite integration.
+
+## Non-goals
+
+- Updating suite, collection, consumer, or other application-role pins.
+- Migrating suite-owned testing files or Narratio's downstream selector.
+- Deploying arbitrary overlay or LLM-profile assets in the generic role.
+- Choosing D&D model, retry, timeout, or credential policy.
+- Automatic renames, compatibility aliases, cache deletion, forced extraction,
+  or production validation tasks.
+- Upstream application changes, live inference, or operational deployment.
+
+## Target End State
+
+### Installation and Configuration
+
+`notarius_version` defaults to `v0.8.1`. Configuration remains schema version 5.
+Preserve existing build, dependency, path, and owner/group/mode interfaces.
+The existing Go selection remains unchanged.
+
+Add `notarius_promptkit_transient_retries: null`, documented and declared as an
+optional integer in argument specifications. When non-null, serialize it as
+`promptkit.transient_retries`. Include it in the parent-section condition so a
+retry-only configuration renders correctly. Null means omit the field; zero
+disables additional transient attempts. Do not copy PromptKit's default into
+role defaults, add a second retry mechanism, or reinterpret existing module
+and validator retry settings.
+
+Keep all existing supported native configuration variables. Preserve caller
+mapping/list composition and omission of unset optional settings. The role does
+not resolve, inspect, or rewrite caller-owned profile or overlay files.
+
+### Overlay Migration Guidance
+
+Document `--config-overlay` and the conventional `overlays/` directory for
+operators invoking the new application. The old `--config-profile` and ConfigKit
+`profiles/` lookup no longer work. This does not rename PromptKit LLM-profile
+sources: `notarius_promptkit_profile_dir`, `notarius_promptkit_profile_file`,
+pipeline `llm_profile`, and `--llm-profile` retain their separate meanings.
+
+Caller-owned configuration overlay files must be migrated by their owner. In
+this workspace the D&D suite owns its testing overlay, so that migration belongs
+to final integration together with Narratio's new selector. Do not add generic
+file-moving tasks or broaden this feature to fix the old suite in place.
+
+### Retry and Checkpoint Compatibility
+
+Explain that transport retries are additional attempts per generation and are
+separate from pipeline/validator retries. Omission inherits upstream behavior;
+operators may explicitly select zero. Later suite planning will review combined
+retry and timeout budgets rather than copying old values mechanically.
+
+Document v0.8.1's changed profile-source checkpoint identity: old matching
+checkpoint identities are not reused, while source-keyed chunk plans and
+published output are unaffected. Leave cache lifecycle with Notarius and do not
+delete data or force Narratio stages as part of installing the role.
+
+## Repository Ownership
+
+- `ansible-role-notarius`: version default, optional retry field, argument
+  specification, template, documentation, and repository-local tests.
+- Workspace: feature roadmap, staged plan, progress, and independent review.
+- Notarius application: read-only tagged configuration/release contracts.
+- Pipeline, collection, consumer, other roles, and assets remain unchanged.
+
+## Constraints and Settled Decisions
+
+Follow the [Ansible house style](../../ansible.md),
+[testing house style](../../testing.md), [MVP roadmap](../mvp.md), and
+[upgrade sequence](../application-upgrade-sequence.md). Use v0.8.1's contract,
+including the intervening v0.8.0 migration notes, not assumptions from a newer
+application checkout.
+
+Retain meaningful tests that explicitly install v0.7.0 to prove caller-selected
+version behavior. Leave the new retry field unset in those older-version cases;
+do not change them merely because the role default advances.
+
+## Simplest Viable Implementation
+
+Update the application version and add one optional variable, argument-spec
+entry, and conditional template field. Extend the existing integration fixture
+with explicit retry zero and native configuration inspection. No new production
+tasks, state probes, compatibility framework, or role-managed assets are needed.
+
+## Rationale and Alternatives
+
+The role manages persistent configuration; application invocation owns overlay
+selection. Adding an overlay-selection variable or file-migration tasks here
+would confuse those responsibilities. Documenting the breaking invocation
+change and coordinating it later preserves independently usable roles and the
+existing suite compatibility set.
+
+## Acceptance Criteria
+
+- The default role installs v0.8.1, and native offline validation accepts the
+  baseline and representative managed configurations.
+- Null retry selection is omitted; explicitly supplied zero is rendered and
+  visible through native effective-configuration inspection. A retry-only
+  configuration produces its enclosing PromptKit section.
+- Existing useful coverage for native import/pipeline composition, profile
+  configuration, cache settings, selected application version, and supplied Go
+  executable remains valid. Do not add a comprehensive upstream schema matrix.
+- Immediate repeat convergence reports no changes. Tests assert supplied values
+  and role outcomes, not today's version/catalog defaults or module postconditions.
+- Documentation accurately distinguishes configuration overlays from LLM
+  profiles and describes retry/checkpoint upgrade consequences.
+- Syntax/lint and repository integration checks pass without live provider
+  calls or operational-host access.
+- Suite, collection, and consumer pins stay unchanged; the reviewed standalone
+  revision is recorded for final integration.
+
+## Dependencies and Follow-up Work
+
+Implementation and independent review are complete. Git history preserves the
+completed staged plan. Narratio v3 standalone adoption is next. Final integration
+owns the coordinated overlay/credential/configuration migration and public suite
+dependency updates. No open product decision is required for this narrow scope.
+
+## Implementation Evidence
+
+- Standalone role commits: `b1b922c` (v0.8.1 default and optional retry
+  interface), `380b6a3` (integration coverage), and `6aef48b` (upgrade
+  guidance). No production tasks or suite dependencies changed.
+- Syntax check and production-profile lint passed. `bash -n` and the local
+  integration harness passed with native offline configuration validation,
+  rendered/effective retry checks, older-version and supplied-Go behavior,
+  import and pipeline composition, and clean immediate repeats. Role and
+  workspace whitespace checks passed.
+- Independent review of all three role commits found no required remediation
+  or unjustified strengthening of requirements. Syntax, production-profile
+  lint, shell syntax, whitespace checks, and installed v0.8.1 native
+  configuration validation passed again during review. The review used the
+  recorded successful integration run rather than rerunning its host-mutating
+  scenarios. No remediation document was changed.
+- Reviewed standalone revision: `6aef48b`. Narratio adoption and coordinated
+  suite migration remain separate follow-up work; suite pins are unchanged.
+
+## Upstream References
+
+- [v0.8.1 configuration](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.1/docs/config.md)
+- [v0.8.0 migration notes](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.0/docs/releases/v0.8.0.md)
+- [v0.8.1 release notes](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.1/docs/releases/v0.8.1.md)

docs/roadmap/features/0021-narratio-v3-adoption.md

@@ -0,0 +1,234 @@
+# Feature 0021: Adopt Narratio v3.0.0 in the Standalone Role
+
+Status: done
+
+## Summary
+
+Update the standalone Narratio role from v2.2.0 to v3.0.0 and align its
+configuration interface with the new Audita and Notarius contracts. This is
+the fourth feature in the agreed
+[application upgrade sequence](../application-upgrade-sequence.md). Suite
+integration remains a separate, subsequent feature.
+
+## Problem or Opportunity
+
+Narratio v3 replaces configuration-profile terminology with overlays, replaces
+singular downstream credential references with lists, and delegates Audita v2
+configuration to Audita. The existing role still exposes retired fields that
+v3 rejects. Advancing only the executable would therefore leave callers and
+the representative configuration fixture with an incompatible interface.
+
+## Scope
+
+- Default the standalone role to Narratio v3.0.0.
+- Align defaults, argument specifications, template, examples, and tests with
+  the changed downstream configuration fields.
+- Document operator migration, ownership boundaries, and native compatibility
+  consequences without automating session or asset migration.
+- Record the independently reviewed role revision for final suite integration.
+
+## Non-goals
+
+- Updating pipeline, collection, consumer, or other application-role pins.
+- Deploying downstream applications, changing D&D defaults, or migrating
+  suite-owned testing overlays and credentials.
+- Creating arbitrary overlay assets or selecting Narratio's runtime overlay
+  through an installer variable.
+- Compatibility aliases, dual-version template branches, automatic migration
+  of existing manifests, cache deletion, or forced stage reruns.
+- New production validation, credential discovery, runtime version gates,
+  forwarding/redaction machinery, or upstream application changes.
+- Live providers, operational deployment, or publication.
+
+## Target End State
+
+### Standalone Installation
+
+`narratio_version` defaults to `v3.0.0`. Preserve source-build behavior, Go
+selection, service account, filesystem paths, owner/group/mode interfaces, and
+the required caller-supplied WhisperX URL. Configuration continues to use the
+existing root document shape and one ordinary template task. Unchanged native
+fields and caller composition remain supported.
+
+### Audita Interface
+
+Add the following optional variables with null defaults. Field paths below
+refer to the root configuration document's `audita` section; upstream prose
+also calls this `pipeline.audita`.
+
+| Role variable | Native field | Argument type |
+| --- | --- | --- |
+| `narratio_audita_credentials` | `audita.credentials` | list of strings |
+| `narratio_audita_overlay` | `audita.overlay` | string |
+| `narratio_audita_proposal_profile` | `audita.proposal_profile` | string |
+| `narratio_audita_validation_profile` | `audita.validation_profile` | string |
+
+Remove these retired role variables and their rendered fields:
+
+- `narratio_audita_llm_api_key`
+- `narratio_audita_base_url`
+- `narratio_audita_model`
+- `narratio_audita_total_llm_concurrency`
+- `narratio_audita_proposal_llm_concurrency`
+- `narratio_audita_validation_model`
+- `narratio_audita_validation_llm_concurrency`
+- `narratio_audita_work_dir_retention`
+- `narratio_audita_report`
+
+Retain binary, timeout, modules, transcript description, config path, and output
+schema variables. Null modules are omitted; explicit `[]` means no correction
+modules. Audita owns backend definitions, model/profile contents, concurrency,
+reporting, and debug policy. Document migration to Audita's own configuration
+without trying to infer replacements for those policies.
+
+### Notarius Interface
+
+Replace `narratio_notarius_config_profile` with
+`narratio_notarius_config_overlay`, an optional nullable string rendered as
+`notarius.config_overlay`. Preserve supplied empty strings, `default`, and
+named selectors exactly; null omits the selector. Selection is independent of
+Narratio's own overlay and is not a PromptKit LLM-profile selection.
+
+Replace `narratio_notarius_llm_api_key` with
+`narratio_notarius_credentials`, an optional nullable list of strings rendered
+as `notarius.credentials`. Preserve other Notarius configuration interfaces,
+including cache controls, references, and output mappings.
+
+### Rendering and Credential Ownership
+
+Use `is not none`, appropriate serialization, and parent-section conditions
+covering the new variables. Null omits a field; empty lists and strings remain
+explicit. Do not copy native defaults into optional role defaults.
+
+Credential lists contain environment-variable/secret-reference **names**, not
+secret values. Narratio resolves and forwards them under their exact names.
+The role neither resolves credentials nor infers them from downstream files.
+Null omits the field and `[]` emits an explicit empty list; Narratio overlays
+replace lists rather than append to them. Operators must list every backend
+credential needed by the selected Audita configuration, including configured
+but unselected backends. Notarius likewise requires names matching its selected
+provider configuration. Resolution occurs at pipeline loading, even when a
+downstream stage will not execute.
+
+Removing retired variables is a documented breaking role-interface migration.
+Do not add alias precedence, version-dependent rendering, or special guards
+for old inventory. Users retaining old deployments retain their old role pin.
+
+### Operator Upgrade Guidance
+
+- Replace Narratio `--profile` with `--overlay` and selected `profiles/` files
+  with `overlays/`. Explicit imports from a directory named `profiles` remain
+  valid; this is not a blanket filesystem rename or an LLM-profile rename.
+- Migrate downstream Notarius selection to `config_overlay` and its selected
+  files to `overlays/`. Named selection needs a supporting Notarius executable;
+  v0.8.1 is the tested baseline, not a new unconditional role version gate.
+- Audita v2 must be configured independently before running polish. Narratio
+  does not generate its config or infer downstream overlay/profile selectors.
+- Link the tagged manifest migration procedure: back up old manifests and
+  migrate `effective_config.selected_profile` to `selected_overlay` while
+  preserving progress/checkpoint state. Do not rewrite immutable remote
+  snapshots or infer that every stage must rerun.
+- Note the native extraction-resume consequence for renamed named Notarius
+  selectors: the next applicable run regenerates extraction with normal
+  dependent invalidation. Omitted/base selections do not gain invalidation
+  solely from this rename. The role does not implement this behavior.
+
+## Repository Ownership
+
+- `ansible-role-narratio`: standalone interface, template, documentation, and
+  repository-local tests.
+- Workspace: roadmap, later staged plan, status, and independent review.
+- `../narratio`: read-only authoritative v3.0.0 contracts.
+- Pipeline, collection, consumer, assets, and other roles remain unchanged.
+
+## Constraints and Settled Decisions
+
+Follow the [Ansible house style](../../ansible.md),
+[testing house style](../../testing.md), [MVP roadmap](../mvp.md), and
+[upgrade sequence](../application-upgrade-sequence.md). Use tagged v3.0.0
+contracts rather than assuming a newer checkout has the same interface.
+
+Keep meaningful explicit v2.1.0 version-selection and supplied-Go recovery
+tests where their baseline inputs remain compatible. Do not turn configurable
+version selection into a promise that new configuration fields work on old
+applications; new fields stay unset in those cases.
+
+## Simplest Viable Implementation
+
+Change the version default and the affected defaults, argument-spec entries,
+and conditional template fields. Adapt existing representative fixtures and
+native validation to the new public interface. No additional production tasks,
+state probes, file migration, or configuration assembly mechanism is needed.
+
+## Rationale and Alternatives
+
+Expose the native v3 interface directly instead of retaining aliases or
+translating legacy Audita tuning into guessed backend/profile definitions.
+This preserves application ownership and avoids a compatibility framework in
+the generic installer. Coordinated suite migration can then make explicit D&D
+policy choices against already-reviewed standalone roles.
+
+## Acceptance Criteria
+
+- The default role installs Narratio v3.0.0; native offline validation accepts
+  baseline and representative rendered configuration.
+- Added and renamed fields agree across defaults, argument specifications,
+  template, examples, and documentation. Retired native fields are not emitted.
+- Focused behavioral cases demonstrate null omission, supplied credential-name
+  lists, explicit empty lists, named/empty downstream selectors, and existing
+  meaningful falsey and artifact-composition behavior. Keep this representative,
+  not a matrix of every native rule or a snapshot of today's defaults.
+- Native validation uses synthetic credential values supplied only to the test
+  process as needed; managed configuration contains names, not values. No live
+  provider calls or reimplementation of upstream forwarding/redaction tests is
+  required. Preserve existing useful log checks without expanding their scope.
+- Immediate identical role application reports no changes. Selected-version
+  and supplied-Go/missing-binary outcomes remain covered.
+- Syntax/lint and local repository integration checks pass. No operational
+  controller, target deployment, downstream pipeline execution, or real keys
+  are prerequisites for standalone-role acceptance.
+- Documentation explains breaking variable changes and links upstream upgrade
+  procedures. No production validation or automatic migration has been added.
+- Suite, collection, and consumer pins remain unchanged. Independent review
+  records the standalone revision for coordinated integration.
+
+## Dependencies and Follow-up Work
+
+Standalone adoption and independent review are complete for all four upgraded
+applications. Git history preserves the completed staged plan. The next,
+coordinated integration feature owns D&D
+configuration, credentials, overlay assets, coordinated dependency pins,
+collection assembly, and consumer migration guidance. It must deliberately
+review retry/timeout budgets rather than copying retired tuning mechanically.
+
+## Open Questions
+
+None identified for this standalone scope.
+
+## Implementation Evidence
+
+- Standalone role commits: `a28f22c` (v3 interface and migrated fixtures),
+  `45f6836` (selector and credential-list coverage), and `3c0700b` (upgrade
+  guidance). Production tasks, suite dependencies, collection, and consumer
+  remain unchanged.
+- `bash -n` and the local integration harness passed. The harness includes
+  syntax check and production-profile lint and exercised native offline
+  baseline, named, and explicit-empty validation, selected v2.1.0 behavior,
+  supplied-Go recovery, synthetic credential loading, and clean immediate
+  repeats. Role and workspace whitespace checks passed.
+- Independent review on 2026-09-29 found no required remediation or unjustified
+  strengthening of requirements. Syntax checks, production-profile lint, shell
+  syntax, whitespace checks, and native v3.0.0 configuration validation passed
+  again during review. The review used recorded successful integration runs
+  rather than rerunning their host-mutating scenarios. No remediation document
+  was changed.
+- Reviewed standalone revision: `3c0700b`. Coordinated suite migration remains
+  separate follow-up work; suite, collection, and consumer pins are unchanged.
+
+## Upstream References
+
+- [Narratio v3.0.0 release](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/releases/v3.0.0.md)
+- [Configuration](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/config.md)
+- [Audita integration](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/integrations/audita.md)
+- [Notarius integration](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/integrations/notarius.md)
+- [Operator migration procedures](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/operations.md)

docs/roadmap/features/0022-coordinated-suite-upgrade.md

@@ -0,0 +1,300 @@
+# Feature 0022: Integrate the Reviewed Application Upgrades
+
+Status: done
+
+## Summary
+
+Bring the four reviewed standalone upgrades into the D&D pipeline role,
+collection, and deployment consumer as one compatible configuration set.
+This completes the agreed
+[application upgrade sequence](../application-upgrade-sequence.md).
+
+## Problem or Opportunity
+
+The standalone roles now support the new releases, but the suite intentionally
+retains its previous pins and configuration. Audita still receives v1 settings;
+Narratio and Notarius testing selection still uses retired profile terminology.
+Updating executable versions alone would break the deployed configuration.
+
+## Scope
+
+- Adopt the reviewed application/role versions together.
+- Provide Audita v2 backend configuration and suite-owned PromptKit profiles.
+- Migrate Narratio credential forwarding and Narratio/Notarius testing overlays.
+- Preserve D&D processing, artifact composition, storage/publishing, shared
+  filesystem, and operator-access behavior.
+- Update the collection snapshot, public dependency manifests, consumer pins,
+  operator guidance, and focused offline integration coverage.
+
+## Non-goals
+
+- Deploying to the operational controller or `pipeline-dnd` host, running real
+  transcripts, or calling inference, WhisperX, or object-storage services.
+- New models, prompts, artifact families, extraction lanes, or processing policy
+  beyond migration choices expressly approved here.
+- Automatic manifest conversion, cache deletion, forced stage reruns, broad
+  directory cleanup, compatibility aliases, or runtime version/integrity probes.
+- Changing generic standalone-role ownership or adding production validation.
+- A newly tagged collection release or replacement of published 0.1.0 assets.
+  This feature updates the public development compatibility set; formal release
+  packaging remains a separate decision.
+
+## Target End State
+
+### Coordinated Versions and Distribution
+
+| Application | Suite version | Reviewed standalone role revision |
+| --- | --- | --- |
+| Scriptorium | v0.15.0 | `b174c8c` |
+| Audita | v2.0.1 | `c3dd59f` |
+| Notarius | v0.8.1 | `6aef48b` |
+| Narratio | v3.0.0 | `3c0700b` |
+| Seriatim | v1.5.0, unchanged | existing v0.1.0 role pin |
+
+Dependency manifests use full immutable revisions resolved from these reviewed
+commits. The pipeline role remains authoritative; the collection imports its
+completed revision through the established public Gitea subtree workflow, never
+by editing `roles/pipeline` directly. The collection continues bundling the
+pipeline role and declaring standalone role dependencies separately.
+
+Relevant reviewed commits must be published to their existing public origins
+before downstream manifests/subtree imports depend on them. Publication of the
+required Git commits is part of the eventual implementation workflow, not this
+roadmap-writing pass. Do not rewrite tags or publish unrelated changes.
+
+The consumer keeps its minimal playbook and host-vars organization. Its role
+and collection pins select the same compatibility set. No controller install
+or remote playbook execution is an acceptance gate.
+
+### Audita Backend and Profile Ownership
+
+The pipeline role supplies `audita_backends`, profile selection, and schema-2
+settings to the standalone Audita role. The pipeline owns the missing profile
+assets under `/usr/local/etc/audita/profiles/`, using its runtime owner/group and
+configuration modes. This directory contains PromptKit LLM profiles, not
+ConfigKit overlays; it must not be renamed to `overlays`.
+
+Approved suite interface:
+
+- `dnd_pipeline_audita_backends`: native backend map, defaulting to one backend
+  named `dnd`, endpoint `https://inference.ai.rakestrawhome.com/v1`, credential
+  reference `AUDITA_LLM_API_KEY`, and shared concurrency `4`. Omit queue capacity
+  to inherit the native default.
+- `dnd_pipeline_audita_profiles`: a native profile mapping keyed by file/profile
+  ID, with complete `dnd-proposal` and `dnd-validation` entries. Each selects
+  backend `dnd`, model `google/gemma-4-31b-it`, and per-attempt
+  `timeout_seconds: 900`. Other model controls inherit native behavior.
+- `dnd_pipeline_audita_llm_proposal_profile` and
+  `dnd_pipeline_audita_llm_validation_profile` select those respective IDs.
+
+Render each supplied profile as one safely serialized native mapping with its
+matching ID. Document profile-map keys as filename-safe IDs. Do not introduce
+per-provider templates, profile merging, or discovery of external assets.
+Callers can compose native maps in inventory and replace the supplied maps.
+As with existing managed secrets, removing a map entry does not imply pruning
+arbitrary files; only selected profiles participate in normal execution.
+
+Preserve the ordered module sequence, `audita-v1` output, chunking values,
+thresholds, context description, and normalization limits. Convert normalization
+duration defaults from `3s`, `3s`, and `240s` to numeric `3.0`, `3.0`, and
+`240.0` seconds. Preserve meaningful setting names where native semantics are
+unchanged; update argument types accordingly.
+
+Remove retired per-role endpoint/model/credential/concurrency/retry variables
+in favor of the native backend/profile interface. Document their replacements;
+do not infer a conversion from arbitrary old inventory. Remove diagnostics
+retention; leave debug disabled through native defaults. Retain the existing
+diagnostics work-directory choice where still supported. Reporting follows
+Audita's native configuration; Narratio consumes its ordinary output contract.
+
+Production and testing continue using the same Audita endpoint and model.
+No separate Audita testing overlay is needed for an identical configuration.
+
+### Credential Lists and Overlay Selection
+
+Replace the suite's singular Narratio Notarius credential variable with
+`dnd_pipeline_narratio_notarius_credentials`, default `[OPENROUTER_API_KEY]`.
+Add `dnd_pipeline_narratio_audita_credentials`, default `[AUDITA_LLM_API_KEY]`.
+Pass both through the reviewed Narratio role's native list variables. These
+lists contain names, never values, and can be replaced with `[]`. Operators
+overriding Audita backends must explicitly list all referenced credentials;
+the suite does not inspect configurations to discover names.
+
+Preserve `dnd_pipeline_secrets`, existing secret names, Vault references,
+protected secret directory/files, and ordinary world-readable nonsecret
+configuration. No credential rotation, secret relocation, or forwarding logic
+is required in Ansible.
+
+Deploy the suite-owned testing files at:
+
+- `/usr/local/etc/narratio/overlays/testing.yml`
+- `/usr/local/etc/notarius/overlays/testing.yml`
+
+Narratio testing sets `notarius.config_overlay: testing`; production omits the
+selector. Notarius remains enabled in both modes. Its production pipeline
+continues selecting `gpt-terra-latest`, testing selects `gpt-luna-latest`, and
+the existing caller-overridable pipeline map/ID behavior remains intact.
+Scriptorium testing still selects `gemini-flash-latest`; production continues
+using the prompt assets' selections. Retain separate artifact/family fragments.
+
+Use Narratio `--overlay testing` and Notarius `--config-overlay testing` in
+tests and operator examples. Deploy the new files declaratively; leave ignored
+legacy `profiles/testing.yml` files alone and document that they are obsolete.
+Do not delete `profiles/` directories or conflate them with PromptKit profiles.
+
+### Runtime Paths and Existing Suite Behavior
+
+Keep Narratio's explicit downstream binaries/config paths, output handoffs,
+Notarius `/var/cache/notarius` roots and resume behavior, shared writable
+directories/ACLs, service user, operator enrollment, and S3/publishing choices.
+Audita profiles are configuration assets, not shared output directories.
+No new runtime storage architecture is required.
+
+### Retry and Timeout Policy
+
+Retain the previously selected per-attempt Audita profile timeouts of 900
+seconds while inheriting the new applications' retry,
+repair, and whole-operation defaults. Expose nullable suite pass-throughs for
+`audita_llm_transient_retries`, `audita_llm_repair_attempts`,
+`audita_llm_operation_timeout`, `notarius_promptkit_transient_retries`, and
+`scriptorium_transient_retries`, prefixed with `dnd_pipeline_` in the public
+suite interface. Null means omit; explicit zero is preserved where valid.
+
+Do not mechanically translate old `max_retries: 3` into both transport retries
+and structural repairs. Preserve explicitly authored Notarius module retries;
+they are a separate behavior. Keep Narratio stage timeouts unchanged. Explain
+the nested budgets and the changed semantics, not a guarantee of identical
+provider cost or timing.
+
+## Repository Ownership
+
+- `ansible-role-dnd-pipeline`: suite defaults, argument specs, dependency wiring,
+  Audita profile assets, testing overlays, documentation, and integration tests.
+- `ansible-collection-dnd`: imported pipeline snapshot, dependency manifest,
+  collection tests, and compatibility guidance.
+- `rakestraw-ansible`: matching dependency pins and deployment guidance; adjust
+  host variables only where required. Preserve Vault content and unrelated
+  inventory. Keep the hosts-and-roles playbook minimal.
+- Standalone role repositories: reviewed commits are reused/published, not
+  redesigned. Application and campaign/prompt repositories are read-only
+  contracts/assets unless a concrete incompatibility is raised for discussion.
+- Workspace: roadmap, later staged plan, decisions, progress, and review.
+
+## Constraints and Settled Decisions
+
+Follow the [Ansible](../../ansible.md), [testing](../../testing.md), and
+[planning](../../planning.md) policies, [MVP roadmap](../mvp.md), and
+[upgrade sequence](../application-upgrade-sequence.md). New D&D policy remains
+in the pipeline role; optional generic application defaults remain null.
+
+## Simplest Viable Implementation
+
+Update dependency variables/pins and existing templates, add an ordinary
+Audita profile directory task and one looped template deployment, and change
+testing destinations to `overlays/`. Reuse existing declarative convergence,
+secret delivery, and collection assembly. No production validation, state
+fingerprints, migration framework, or generated credential inference is needed.
+
+## Acceptance Criteria
+
+- Pipeline and collection installations produce a compatible set of the four
+  upgraded applications while Seriatim remains unchanged.
+- Native offline inspection/validation accepts Audita settings and selected
+  profiles, Notarius base/testing configurations, Scriptorium configuration,
+  and Narratio base/testing composition with synthetic credential inputs.
+  Direct Audita validation receives credential environment variables explicitly:
+  it does not bootstrap Narratio's secrets directory on its own.
+- Focused cases prove caller-supplied backend/profile configuration and
+  credential lists, testing selection, and existing important composition and
+  path handoffs. Assert supplied values, not fixed copies of today's defaults.
+- Immediate repeated convergence is clean. Existing meaningful shared-user,
+  cache, artifact-composition, and installed-collection behavior remains covered
+  without expanding into upstream module/runtime regression matrices.
+- Collection build/install and consumer syntax checks use the established
+  public dependency manifests. No sibling application/role checkout is needed
+  by an external consumer. Required referenced commits exist on public Gitea.
+- Consumer inventory retains comments/Vault references for unknown secrets;
+  no actual keys or operational deployments are required for completion.
+- Guidance covers breaking inventory fields, new CLI selectors, obsolete
+  testing-file locations, and upstream manifest migration. Back up and migrate
+  local provenance without deleting progress or editing immutable snapshots;
+  document normal named-selector invalidation rather than forcing reruns.
+
+## Open Questions
+
+None. The user approved deferring to application defaults wherever possible,
+with nullable inventory overrides, and confirmed retaining the existing
+900-second Audita per-attempt policy. Do not freeze native retry, repair, or
+operation-deadline defaults in suite variables. Operators should note that an
+attempt may consume the entire logical-operation budget; these are separate
+controls, not additive timeout guarantees.
+
+## Dependencies and Follow-up Work
+
+Features 0018–0021 provide the reviewed standalone revisions. Implementation,
+independent review, and remediation are complete. Git history preserves the
+completed staged implementation plan. Actual deployment,
+session migration, live processing, and a formal tagged release are separate
+operator actions, not completion gates for this feature.
+
+## Implementation Evidence and Review Handoff
+
+On 2026-09-29, the four reviewed standalone role revisions were published to
+their existing public Gitea `origin/main` branches and verified after fetch:
+Scriptorium `b174c8c2990bb79f8149d8f288c5e06ccb42bd73`, Audita
+`c3dd59f5ac9b942306ffe540ae9e71d493998137`, Notarius
+`6aef48b7e12e3651971444b8c224d96ff1879e6c`, and Narratio
+`3c0700b5323293d44e3b1e67a50074d82d7a3bff`.
+
+The pipeline role at public revision
+`ea8b09e190419586ede6df3815d1ea999a0f4391` passed `bash -n`, its full
+`tests/integration` harness twice (configuration migration and representative
+override coverage), and `git diff --check`. The collection imported that exact
+public revision by subtree; public collection revision
+`3d77eb382bcb4c1742015d3c32e23630bb8c73bf` passed `bash -n`, its full
+artifact-based `tests/integration`, and `git diff --check`. Both harnesses used
+synthetic credentials and offline native application validation, with clean
+repeats. The consumer's local commit
+`f694dad9426ee21138b175e44a3855d42be99d4b` passed public dependency
+installation into disposable paths, real-inventory `--list-hosts` limited to
+`pipeline-dnd`, `--syntax-check`, and `git diff --check`. Its commit was not
+pushed. Seriatim and native collection pins remain unchanged, and manifests
+across the three repositories agree.
+
+The local integration harnesses converged only the development installation;
+there was no operational deployment or live inference, transcription, or object
+storage call. Vault values and target access were not needed or verified.
+After the override harness passed, a formatting-only split of its fixture JSON
+line was checked with `bash -n`, JSON parsing, and `git diff --check` without
+rerunning the long integration harness. Independent review subsequently found
+the three issues resolved below. No tagged release was created.
+
+## Remediation Follow-up
+
+The three independent-review findings are resolved; see
+[remediation evidence](../remediation.md). Public pipeline `37b1cf6` and
+collection `b3bc045` remove default-identity assertions and correct migration
+and credential guidance. Local consumer `15f0f4e` selects the corrected public
+snapshot. Shell/whitespace checks, pipeline and installed-collection syntax and
+lint, collection build/install, and real-inventory consumer target/syntax checks
+passed. Full host-mutating convergence was not rerun for these documentation
+and test-only changes. Application versions/defaults and runtime behavior are
+unchanged.
+
+## Closeout
+
+Closed on 2026-09-29 after independent review and resolution of all three
+findings. This completes the agreed application upgrade sequence. The active
+implementation plan is retired; no additional implementation is required for
+this feature. Consumer commits remain local. Operational upgrade, session
+migration, live production/testing checks, and any new tagged release require
+separate operator action and were not performed as part of closeout.
+
+## Upstream References
+
+- [Audita v2 migration](https://gitea.maximumdirect.net/eric/audita/src/tag/v2.0.1/docs/migrations/v2.md)
+- [Audita configuration](https://gitea.maximumdirect.net/eric/audita/src/tag/v2.0.1/docs/config.md)
+- [Narratio v3 release](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/releases/v3.0.0.md)
+- [Narratio operations and migration](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/operations.md)
+- [Notarius v0.8.0 migration](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.0/docs/releases/v0.8.0.md)
+- [Scriptorium v0.14.0 migration](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.14.0/docs/releases/v0.14.0.md)

docs/roadmap/features/0023-narratio-scriptorium-credentials.md

@@ -0,0 +1,206 @@
+# Feature 0023: Adopt Narratio v3.1.0 and Forward Scriptorium Credentials
+
+Status: done
+
+## Summary
+
+Update the standalone Narratio role and D&D pipeline to Narratio v3.1.0 and
+expose its Scriptorium credential list. Deliver the coordinated change through
+the collection and existing deployment consumer without deploying to a host.
+
+## Problem or Opportunity
+
+The operator's deployment to `pipeline-dnd` failed during trim bounds generation
+with Scriptorium reporting HTTP 401. Narratio v3.0.0 filtered provider keys out
+of the child environment without offering a public Scriptorium credential
+selection. Analyze had the same forwarding gap. Provisioning a key through
+Ansible alone could not repair that boundary.
+
+Upstream has released explicit Scriptorium credential forwarding in v3.1.0.
+The original report is preserved in Narratio commit `9389f69`;
+the upstream change is `44a3186`, with release documentation at `40cbf42`.
+These are planning references, not substitutes for the released application tag.
+
+## Scope
+
+- Adopt Narratio v3.1.0 in the standalone role and suite version selections.
+- Expose its native credential-list field through the standalone role and
+  supply overrideable D&D defaults through the pipeline role.
+- Refresh the Narratio role dependency, public pipeline subtree snapshot,
+  collection dependency manifest, and existing consumer pins together.
+- Extend existing configuration/composition coverage and document operator
+  credential requirements and normal retry behavior.
+
+## Non-goals
+
+- Changing upstream applications, other application versions, models, prompts,
+  profile selections, or the existing filesystem and credential-storage policy.
+- Adding a credential loader, wrapper, environment file, provider discovery,
+  or per-stage credential-selection interface.
+- Live inference, deployment to a controller or `pipeline-dnd`, credential
+  verification against providers, or modifying Vault contents.
+- Publishing new Ansible release tags or collection release artifacts.
+- Reimplementing upstream credential forwarding, redaction, or checkpoint
+  behavior in Ansible or its test suites.
+
+## Target End State
+
+### Standalone Narratio role
+
+`narratio_version` defaults to `v3.1.0`. The optional public variable
+`narratio_scriptorium_credentials` defaults to null, is documented as a list
+of strings, and renders `scriptorium.credentials` in the native root pipeline
+file only when non-null. An explicit empty list renders `credentials: []`;
+nonempty lists preserve the caller's exact credential names. Include the field
+in the enclosing Scriptorium-section condition so it works independently of
+other optional Scriptorium variables. No provider-specific default belongs in
+the standalone role.
+
+### D&D pipeline policy
+
+`dnd_pipeline_narratio_version` selects `v3.1.0`.
+`dnd_pipeline_narratio_scriptorium_credentials` defaults to
+`[OPENROUTER_API_KEY]` and is passed through the existing Narratio dependency
+variables. Inventory can replace the list, including with `[]`, or set null
+to omit the field through the standalone role's interface.
+
+The testing overlay inherits this list; no duplicate testing-specific setting
+is needed for the currently selected profiles. The existing Notarius reference
+to the same key remains independent. Operators selecting different providers
+can supply the corresponding names through the ordinary inventory interface.
+
+Credential bytes continue to come from Narratio's process environment or its
+existing secrets mechanism. `dnd_pipeline_secrets` remains an optional managed
+file-provisioning mechanism, not the only valid credential source. No new secret
+file or migration is needed where `OPENROUTER_API_KEY` is already provisioned.
+
+### Upstream contract and operator handoff
+
+Narratio calls the field `pipeline.scriptorium.credentials` internally; the
+root pipeline YAML uses `scriptorium: {credentials: [...]}` without an extra
+`pipeline:` wrapper. The list applies to trim, analyze (including character
+families), and render-debug calls. It forwards names and resolved values without
+overriding Scriptorium's own provider/profile selection.
+
+Upstream resolves selected names to nonempty values at configuration load,
+including for commands that do not execute Scriptorium. Tests and operator
+guidance must account for that existing contract. Omitted/null/empty lists
+forward nothing; a native overlay replaces the full list. After upgrading and
+provisioning the selected key, retry failed trim/analyze normally; do not force
+successful work solely because a credential was added or rotated. See the
+upstream references below for the authoritative behavior.
+
+## Repository Ownership
+
+- `ansible-role-narratio`: version default, public variable, argument spec,
+  template, documentation, and focused configuration tests.
+- `ansible-role-dnd-pipeline`: suite version/credential defaults, dependency
+  wiring and pin, documentation, and composition coverage.
+- `ansible-collection-dnd`: exact public pipeline subtree import, matching
+  dependency manifest, and installed-artifact validation.
+- `rakestraw-ansible`: updated consumer dependency pins and concise upgrade
+  guidance only; preserve its minimal playbook, inventory, and Vault content.
+- Workspace: feature tracking, later staged plan, and review evidence.
+- Narratio and the remaining applications/assets: read-only upstream contracts.
+
+## Constraints and Settled Decisions
+
+Follow the [Ansible](../../ansible.md), [testing](../../testing.md), and
+[planning](../../planning.md) policies and the [MVP architecture](../mvp.md).
+Preserve generic application roles versus opinionated suite policy. Reuse the
+existing declarative source-build and template tasks; add no production checks.
+Required dependency commits must be public before external consumer use; subtree
+imports use public Gitea, not sibling paths. Do not alter unrelated pins.
+
+## Simplest Viable Implementation
+
+Add one nullable standalone configuration variable and its ordinary template,
+argument-spec, and documentation entries. Add one suite default and dependency
+mapping. Advance the Narratio version and coordinated dependency pins, then
+reuse the existing collection import and consumer refresh workflow. No new
+production task or persistent state is needed.
+
+## Acceptance Criteria
+
+- The standalone role and assembled suite build the released v3.1.0 source.
+  Any version assertion explicitly supplies the version under test rather than
+  freezing the current default.
+- Representative explicit credential names reach the deployed native
+  configuration; null omission and explicit `[]` are supported. Extend existing
+  cases rather than adding a separate exhaustive matrix.
+- Suite composition preserves an explicitly supplied credential list in base
+  and testing configurations. Use synthetic credential values for offline
+  native validation; do not assert today's default list as a permanent invariant.
+- The real role and installed collection pass their existing relevant
+  validation, including immediate repeated convergence with no changes.
+  Credential-forwarding internals and provider authentication remain upstream
+  responsibilities; no live service or new subprocess simulation is required.
+- Collection and consumer manifests resolve the coordinated public revisions;
+  consumer host listing/syntax checks work without deployment or Vault
+  decryption. Leave the existing hosts-and-roles playbook unchanged.
+- Guidance explains load-time credential requirements, existing environment or
+  file provisioning, dependency refresh, and ordinary retry after the fix.
+
+## Dependencies and Follow-up Work
+
+The public Narratio v3.1.0 tag was verified on 2026-09-29 at
+`40cbf4243838b0a1db6caf4c8f790d914ccb96cc`, matching the reviewed release
+documentation and configuration contract. The release prerequisite is satisfied.
+Use that release rather than substituting a moving branch.
+
+The completed staged implementation plan is preserved in Git history.
+Required Ansible dependency commits are public as recorded below. Operational
+deployment and a paid/live smoke run remain separate operator activities, not
+feature-completion gates.
+
+## Implementation Evidence
+
+Implementation completed on 2026-09-29. The public Narratio role revision is
+`758aed7a74c9a64ad02e13ff551b4f7aea16b3af`; the public D&D pipeline role
+revision is `0f841fd91ffc533aeec0ec688e81c24bd187a845`; the public
+collection revision is `002e86c9deb90820a2f1c2f55e1f4d8be59b7c96`.
+The consumer revision `67cc22f37f042fa12ada09547efa677022242284` is
+committed locally and not published, preserving its earlier local commits.
+The collection's imported pipeline Git tree exactly matches the public source
+revision. No release tag or artifact was created.
+
+The Narratio role, pipeline role, and collection each passed `bash -n
+tests/integration`, their full `./tests/integration` harnesses, and `git diff
+--check`. The role and collection harnesses passed on their first runs. The
+pipeline harness's first run encountered a public Git HTTPS timeout; an
+unchanged retry passed, including native base/testing configuration inspection
+and a zero-change repeat. The consumer installed the collection manifest's D&D
+dependencies and exact collection revision in disposable paths; `--list-hosts`
+selected only `pipeline-dnd`, `--syntax-check` passed, and `git diff --check`
+passed. No operational controller or target host was contacted.
+
+No implementation scope deviation was needed. Offline configuration and
+convergence checks do not prove that the
+operator's actual key is valid or that a live trim request will succeed.
+
+## Independent Review and Closeout
+
+Closed on 2026-09-29 after independent review found no actionable code-quality
+issues or implementation gaps. Null omission, explicit empty lists, suite
+credential selection, testing-overlay inheritance, and coordinated dependency
+pins match the approved feature. No additional production machinery was added.
+The imported pipeline Git tree matches the authoritative source exactly.
+
+Independent shell syntax, whitespace, role syntax/lint, collection build/install,
+public role dependency installation, and real-inventory consumer target/syntax
+checks passed. Review used the recorded full integration and clean-repeat
+results rather than rerunning host-mutating convergence. No operational host or
+live provider was contacted. No remediation document change was needed.
+
+The active plan is retired. Consumer and workspace commits remain local;
+operational deployment and provider-key validity remain outside this closeout.
+
+## Open Questions
+
+None identified.
+
+## Upstream References
+
+- [Narratio v3.1.0 release notes](../../../../narratio/docs/releases/v3.1.0.md)
+- [Scriptorium credentials](../../../../narratio/docs/config.md#scriptorium-credentials)
+- [401 troubleshooting](../../../../narratio/docs/troubleshooting.md#scriptorium-returns-http-401-during-trim-or-analyze)

docs/roadmap/implementation.md

@@ -1,613 +1,12 @@
-# Implementation Plan 0010: D&D Notarius Extraction Integration
+# Implementation Plan
 
-Status: ready
+No implementation plan is currently active.
 
-Target executor: GPT-5.6-Terra
+[Feature 0023](features/0023-narratio-scriptorium-credentials.md) was closed on
+2026-09-29 after implementation and independent review with no actionable
+findings. Its roadmap retains the completion evidence; Git history preserves
+the completed staged implementation plan.
 
-Feature roadmap:
-`docs/roadmap/features/0010-dnd-notarius-extraction-integration.md`
-
-Active plan location: `docs/roadmap/implementation.md`
-
-## Objective
-
-Upgrade the generic Notarius role to the v0.7.0 configuration contract, then
-have the D&D pipeline role deploy the maintained ten-lane extraction pipeline,
-enable it through Narratio, bind prepared campaign references, accept all ten
-lane contracts, and provision the shared FHS cache policy established by
-Feature 0009.
-
-The feature roadmap remains authoritative for scope, rationale, target end
-state, and acceptance criteria. Decisions 0001 and 0002 remain authoritative
-for direct Ansible convergence and the shared-readable filesystem boundary.
-
-## Execution Rules
-
-- Execute stages in numeric order.
-- Before each stage, confirm its preconditions and the working-tree state of
-  its owning repository.
-- Before each stage, reread every document listed in that stage's Required
-  Policy Review. Do not rely on policy recalled from an earlier stage.
-- Preserve unrelated and pre-existing changes. Stop if an owning repository is
-  unexpectedly dirty at a stage boundary.
-- Keep `ansible-role-notarius` generic. ConfigKit import support is a native
-  application interface; the D&D pipeline, campaign bindings, cache policy,
-  and Narratio coordination belong only to `ansible-role-dnd-pipeline`.
-- Use the Notarius v0.7.0 maintained complete pipeline as the topology and
-  contract authority. Remove external path references, but retain generated
-  artifact handoffs and canonical version 5 binding objects.
-- Trust the existing application-role templates and Ansible modules. Do not
-  add production validation commands, preliminary probes, manual comparisons,
-  handlers, checksums, manifests, state files, or corrective permission tasks.
-- Create only the shared Notarius cache root. Notarius owns creation of its
-  configured `chunk-plans` and `checkpoints` children during actual use.
-- Keep the existing Narratio `testing` overlay unchanged so it inherits the
-  enabled Notarius stage and `dnd-extraction` workload profile.
-- Do not add credentials, a PromptKit profile file, campaign paths, a global
-  Notarius output or debug root, checkpoint resume, extraction execution,
-  model calls, storage, publishing, services, schedules, or user-membership
-  management.
-- Test public behavior through the installed applications' native inspection
-  and validation interfaces. Do not snapshot complete configuration files,
-  parse production task results, inspect filesystem metadata, or reproduce
-  application and Ansible validators in assertions.
-- Run every stage's validation before committing it. Commit each completed
-  stage when it leaves the owning repository valid, using the plain-English
-  commit intent specified by that stage.
-- Do not begin a dependent stage after an earlier stage fails validation.
-- The pipeline integration suite installs role dependencies from their
-  canonical Git origins. The Stage 1 Notarius-role commit must therefore be
-  reachable from its canonical origin before Stage 2 begins. If it is not,
-  stop after Stage 1 and report the commit hash for publication; do not use a
-  branch, local path, or weakened dependency test as a substitute.
-
-## Starting State and Preconditions
-
-- The workspace control repository contains the reviewed Feature 0010 roadmap
-  and this implementation plan on `main` in a clean planning commit descended
-  from `f91871ba0f90da19592eb56824f5abb9e7868285`.
-- Features 0001 through 0009 and the standalone-role test-suite simplification
-  are complete.
-- The implementation repositories are clean on `main` at these reviewed
-  starting commits:
-
-  | Repository | Starting commit |
-  | --- | --- |
-  | `ansible-role-notarius` | `e9ae2dc34023e1e8462bf0991de62b97d8c0e0ee` |
-  | `ansible-role-dnd-pipeline` | `b15fe8dcf57a53784bc3b0b8bf04aa97d39edb3f` |
-
-- The Notarius-role starting commit matches `origin/main`. The pipeline role
-  is intentionally ahead of its canonical origin and must not be reset or
-  replaced.
-- `../notarius` is clean at the immutable `v0.7.0` tag,
-  `4e77725b24cb62bd1f96ee31b4d17b4a2ed68ba7`.
-- `../narratio` is clean at the immutable `v2.0.0` tag,
-  `ed4623bc415901134c765fe9cf06d59aa7891500`.
-- Notarius v0.7.0 preserves the subprocess receipt and extraction-artifact
-  contracts consumed by Narratio v2.0.0 while requiring Notarius
-  configuration version 5.
-- The workspace `.venv` provides Ansible Core 2.21.3 and ansible-lint 26.8.0.
-- The local integration environment remains an accepted proxy for Ubuntu
-  26.04, supports task-level privilege escalation, and provides ordinary POSIX
-  ACL behavior.
-
-## Repository Scope
-
-Repositories that change:
-
-- `ansible-role-notarius`: v0.7.0 selection, configuration version 5,
-  nullable native ConfigKit imports, generic documentation, and focused
-  integration coverage.
-- `ansible-role-dnd-pipeline`: compatible Notarius role and application pins,
-  opinionated D&D pipeline configuration, Narratio integration, shared cache
-  root, documentation, and focused integration coverage.
-- `ansible-workspace-dnd`: implementation progress and review handoff only
-  after the role stages are complete.
-
-Repositories that may be inspected but must remain unchanged:
-
-- `../notarius` and `../narratio`, which are read-only application authorities.
-- `ansible-role-narratio`, whose generic Notarius adapter already exposes all
-  fields required by this feature.
-- `ansible-role-audita`, `ansible-role-seriatim`,
-  `ansible-role-scriptorium`, and `ansible-collection-dnd`.
-- `assets/campaigns`, `assets/narratio-prompts`, and `assets/configs`.
-- `rakestraw-ansible` and every other repository in `workspace.yml`.
-
-## Stage 1: Upgrade the Generic Notarius Role
-
-Status: complete (`14a38e04e35ef524d6a97fa7fb5a04981a0a2161`)
-
-### Objective
-
-Make the standalone role install Notarius v0.7.0, render configuration version
-5, and expose the application's native ConfigKit import list without adding
-D&D-specific policy.
-
-### Required Policy Review
-
-Before beginning this stage, read:
-
-- `AGENTS.md`
-- `docs/orientation.md`
-- `docs/conventions.md`
-- `docs/ansible.md`
-- `docs/testing.md`
-- `docs/roadmap/features/0010-dnd-notarius-extraction-integration.md`
-- `docs/decisions/0001-minimal-module-driven-ansible.md`
-- `../notarius/docs/releases/v0.7.0.md`
-- `../notarius/docs/config.md`
-- `../notarius/docs/cli.md`
-- `../notarius/examples/dnd-complete.config.yml`
-- `../notarius/examples/pipelines/dnd-session.yml`
-- `ansible-role-notarius/defaults/main.yml`
-- `ansible-role-notarius/meta/argument_specs.yml`
-- `ansible-role-notarius/templates/config.yml.j2`
-- `ansible-role-notarius/tests/integration`
-- `ansible-role-notarius/tests/verify-config.yml`
-- `ansible-role-notarius/README.md`
-
-### Preconditions
-
-- `ansible-role-notarius` is clean at its stated starting commit.
-- The repository's existing `tests/integration` entry point passes before
-  modification.
-- The v0.7.0 upstream files listed above remain at the reviewed immutable tag.
-
-### Owning Repository
-
-`ansible-role-notarius`
-
-### Required Changes
-
-1. Advance `notarius_version` from `v0.6.0` to `v0.7.0` and
-   `notarius_config_version` from `4` to `5`. Do not change the established
-   source-build task flow or other generic defaults.
-2. Add `notarius_configkit_imports: null` as one optional public variable and
-   add a matching argument-specification entry using a list of native mapping
-   objects. Do not create field aliases for import entries or add role-owned
-   merge behavior.
-3. Render a top-level `configkit.imports` section only when
-   `notarius_configkit_imports is not none`. Serialize the supplied list with
-   an established Ansible/Jinja data filter; do not manually construct YAML or
-   alter `notarius_pipelines`.
-4. Keep every other optional field governed by its current null-omission
-   behavior. The role manages only its root configuration and must not create
-   any caller-selected imported fragment.
-5. Update the README's version, configuration version, variable list, and
-   configuration discussion. Explain that ConfigKit imports are caller-owned
-   native composition inputs and that relative imports resolve from the
-   managed root configuration directory. Do not mention the D&D suite's fixed
-   fragment or cache policy as a standalone default.
-6. Migrate the integration fixture from configuration version 4 shorthand to
-   canonical version 5 module-binding objects. Use a test-owned imported
-   fragment to exercise `notarius_configkit_imports`; fixture creation is test
-   setup and must not become a production role task.
-7. Exercise an explicitly selected `notarius_version: v0.7.0`, caller-side
-   composition of two small pipeline maps, an intentional falsey cache value,
-   a representative cache override, and the existing caller-supplied Go
-   executable/missing-binary recovery behavior. Use v0.7.0 for cases that need
-   a configuration-compatible executable.
-8. Validate the representative imported pipeline with
-   `notarius config validate --pipeline <id>` and observe composition and the
-   cache override through `notarius config effective` or another native
-   inspection command. Remove direct managed-file assertions from
-   `tests/verify-config.yml`; delete that playbook if it has no remaining
-   behavioral purpose.
-9. Retain an immediate identical repeat that reports `changed=0` and
-   `failed=0`. Do not assert that v0.7.0 remains the role default, test
-   ConfigKit itself, or add production validation and state inspection.
-
-### Validation
-
-Run from `ansible-role-notarius`:
-
-```text
-tests/integration
-git diff --check
-git status --short
-```
-
-Expected result: syntax and production-profile lint pass; the explicitly
-selected v0.7.0 binary reports its selected version; native Notarius commands
-validate and inspect the representative composed version 5 configuration;
-missing-binary recovery still works with the caller's Go executable; all
-immediate repeats report `changed=0` and `failed=0`; and only intended role,
-test, and README files are modified.
-
-### Completion Criteria
-
-- Defaults, argument specification, template, README, and tests expose one
-  coherent generic ConfigKit import interface.
-- The root document is version 5 and no D&D pipeline or caller-owned fragment
-  is embedded in the standalone role.
-- Tests observe native application behavior and do not snapshot defaults or
-  re-test Ansible module guarantees.
-- The repository is valid and the stage is committed.
-
-### Commit
-
-Commit intent: `Upgrade the Notarius role to version 0.7.0`
-
-## Stage 2: Implement the Suite Notarius Integration
-
-### Objective
-
-Add the pipeline role's complete D&D Notarius configuration, Narratio wiring,
-and shared cache convergence using the reviewed standalone-role interface.
-
-### Required Policy Review
-
-Before beginning this stage, read:
-
-- `AGENTS.md`
-- `docs/orientation.md`
-- `docs/conventions.md`
-- `docs/ansible.md`
-- `docs/testing.md`
-- `docs/roadmap/features/0010-dnd-notarius-extraction-integration.md`
-- `docs/decisions/0001-minimal-module-driven-ansible.md`
-- `docs/decisions/0002-shared-readable-pipeline-filesystem-policy.md`
-- the committed Stage 1 changes in `ansible-role-notarius`
-- `../notarius/docs/releases/v0.7.0.md`
-- `../notarius/docs/config.md`
-- `../notarius/docs/consumers/dnd-pipeline.md`
-- `../notarius/examples/dnd-complete.config.yml`
-- `../notarius/examples/pipelines/dnd-session.yml`
-- `../narratio/docs/integrations/notarius.md`
-- `../narratio/examples/pipeline.full.annotated.yml`
-- `ansible-role-dnd-pipeline/defaults/main.yml`
-- `ansible-role-dnd-pipeline/meta/argument_specs.yml`
-- `ansible-role-dnd-pipeline/meta/main.yml`
-- `ansible-role-dnd-pipeline/requirements.yml`
-- `ansible-role-dnd-pipeline/tasks/main.yml`
-- `ansible-role-dnd-pipeline/templates/testing.yml.j2`
-- `ansible-role-dnd-pipeline/tests/integration`
-
-### Preconditions
-
-- Stage 1 is committed, validated, and clean.
-- The Stage 1 commit is reachable from the canonical
-  `ansible-role-notarius` Git origin. Stop and report the hash if a fresh Git
-  or Galaxy fetch cannot resolve it.
-- `ansible-role-dnd-pipeline` is clean at its stated starting commit or an
-  expected reviewed descendant.
-- Its existing `tests/integration` entry point passes before modification.
-
-### Owning Repository
-
-`ansible-role-dnd-pipeline`
-
-### Required Changes
-
-1. Set `dnd_pipeline_notarius_version: v0.7.0` and pin the
-   `rakestraw.notarius` entry in `requirements.yml` to the exact Stage 1
-   commit. Retain the canonical Git URL and every unrelated dependency pin.
-2. Add these required, defaulted suite variables and matching argument
-   specifications:
-   `dnd_pipeline_notarius_pipelines` as a complete native map,
-   `dnd_pipeline_notarius_cache_root` as a path,
-   `dnd_pipeline_notarius_cache_chunk_plans_mode` as a string,
-   `dnd_pipeline_notarius_cache_checkpoints_enabled` as a boolean,
-   `dnd_pipeline_narratio_notarius_pipeline_id` as a string,
-   `dnd_pipeline_narratio_notarius_references` as a complete native map, and
-   `dnd_pipeline_narratio_notarius_outputs` as a complete native map.
-3. Default the pipeline map to one `dnd-session` entry adapted from the
-   Notarius v0.7.0 maintained fragment. Preserve its embedded
-   `dnd-extraction` profile ID, Seriatim input, `dnd/scenes` chunker with two
-   retries, three ordered steps, ten lanes, canonical object bindings,
-   generated artifact handoffs, JSON chunk map, and nine-lane evidence-context
-   selection with a three-unit window.
-4. Remove every external `path` reference from the adapted pipeline: omit the
-   example's `party`, `glossary`, and binding-local `spell_catalog` paths.
-   Retain only generated `artifact` references between steps. Do not install a
-   PromptKit profile file or set global output/debug roots.
-5. Default the selected pipeline ID to `dnd-session`. Default the Narratio
-   reference map to `party: narratio.input.party`,
-   `players: narratio.input.players`, and
-   `glossary: narratio.input.glossary`; do not add `spell_catalog` until a
-   deployed campaign supplies that optional input.
-6. Default the Narratio output map to all ten exact lane, media type, schema
-   ID, schema version, and module-key descriptors recorded in the feature
-   roadmap and Narratio's maintained example. Keep both maps replaceable as
-   whole native values through normal inventory precedence.
-7. Default the cache root to `/var/cache/notarius`, chunk-plan mode to `auto`,
-   and checkpoint recording to `true`. Derive
-   `/var/cache/notarius/chunk-plans` and
-   `/var/cache/notarius/checkpoints` in dependency wiring rather than adding
-   independent suite variables.
-8. Pass the fixed relative import `pipelines/dnd-session.yml`, selected cache
-   settings, and derived child paths to `rakestraw.notarius`. Leave its
-   root-level `notarius_pipelines` unset so the standalone role continues to
-   own only the root document.
-9. Pass `narratio_notarius_enabled: true`, the selected pipeline ID,
-   `/usr/local/etc/notarius` working directory, and the reference/output maps
-   to `rakestraw.narratio`. Retain the established binary and configuration
-   paths, leave its native three-hour timeout in control, and do not change the
-   Narratio role or testing-overlay template.
-10. Create `/var/cache/notarius` directly as the selected runtime user and
-    group with mode `2775` before ACL convergence. Add that root to both
-    existing access and default ACL loops; do not create its child stores or
-    add a second ACL implementation.
-11. Create `/usr/local/etc/notarius/pipelines` directly with the suite
-    configuration owner, group, and directory mode. Add one template that
-    serializes only `pipelines: dnd_pipeline_notarius_pipelines` to
-    `dnd-session.yml` with the suite file metadata. Do not duplicate the
-    standalone root template or manually render every nested map field.
-12. Keep production convergence limited to the existing role dependencies,
-    one cache-root file operation, the existing ACL loops, one configuration
-    directory operation, and one template operation. Do not add commands,
-    `stat`, handlers, validation tasks, state bookkeeping, secrets, extraction,
-    or retention behavior.
-
-### Validation
-
-Run from `ansible-role-dnd-pipeline`:
-
-```text
-tests/integration
-git diff --check
-git status --short
-```
-
-Expected result: isolated dependency installation resolves the exact Stage 1
-commit; syntax and production-profile lint pass; the five applications install
-successfully; Notarius natively validates the imported `dnd-session` pipeline;
-Narratio validates the assembled base and testing configurations; the baseline
-repeat reports `changed=0` and `failed=0`; and only intended pipeline-role
-files are modified.
-
-### Completion Criteria
-
-- The suite installs Notarius v0.7.0 through the exact reviewed role revision.
-- The complete path-free D&D pipeline is owned by one suite fragment and is
-  imported through the standalone role's public interface.
-- Narratio enables and selects the pipeline with the three prepared campaign
-  references and all ten exact accepted outputs.
-- The FHS cache root and inherited access policy use direct module-owned
-  convergence; child stores remain application-owned.
-- The unchanged testing overlay inherits Notarius enablement and pipeline
-  selection.
-- The repository is valid and the stage is committed.
-
-### Commit
-
-Commit intent: `Integrate Notarius extraction into the D&D pipeline`
-
-## Stage 3: Document and Exercise the Integration Contract
-
-### Objective
-
-Document the suite's Notarius policy and add the smallest behavioral coverage
-that proves native composition, Narratio coordination, shared access,
-customization, and immediate idempotence.
-
-### Required Policy Review
-
-Before beginning this stage, read:
-
-- `AGENTS.md`
-- `docs/orientation.md`
-- `docs/conventions.md`
-- `docs/ansible.md`
-- `docs/testing.md`
-- `docs/roadmap/features/0010-dnd-notarius-extraction-integration.md`
-- `docs/decisions/0002-shared-readable-pipeline-filesystem-policy.md`
-- the committed Stage 1 and Stage 2 changes
-- `../notarius/docs/cli.md`
-- `../notarius/docs/consumers/dnd-pipeline.md`
-- `../narratio/docs/cli.md`
-- `../narratio/docs/integrations/notarius.md`
-- `ansible-role-dnd-pipeline/README.md`
-- `ansible-role-dnd-pipeline/tests/integration`
-- `ansible-role-dnd-pipeline/tests/converge.yml`
-
-### Preconditions
-
-- Stages 1 and 2 are committed, validated, and clean.
-- The pipeline's isolated dependency installation resolves the Stage 1 commit.
-- The deployed baseline can be restored through the existing integration
-  driver's cleanup path.
-
-### Owning Repository
-
-`ansible-role-dnd-pipeline`
-
-### Required Changes
-
-1. Update the README's compatible-version table to Notarius v0.7.0 and replace
-   the statement that Notarius remains disabled with the implemented
-   extraction behavior.
-2. Document the seven new suite variables, the fixed root import and fragment
-   path, caller-side map replacement/composition with Jinja `combine`, the
-   prepared-reference boundary, all ten accepted output sources, and the
-   optional future `spell_catalog` extension. Distinguish native maps from
-   field-specific scalar controls.
-3. Document `/var/cache/notarius`, `auto` chunk plans, recorded-but-not-resumed
-   checkpoints, derived child paths, `2775` setgid/default-ACL policy, and use
-   by either the service account or an existing member of the runtime group.
-   Retain the world-readable non-secret policy and the deferred restricted
-   credential boundary.
-4. Document that base and `testing` configurations use the same
-   `dnd-extraction` profile and pipeline. Do not claim that testing avoids
-   Notarius model calls during a real run; integration tests perform only
-   offline configuration inspection.
-5. Extend the baseline integration path to run
-   `notarius config validate --pipeline dnd-session` and inspect
-   `notarius config effective`. Observe one generated artifact handoff and one
-   cache setting from the native effective output without reading the managed
-   YAML file or enumerating every pipeline option.
-6. Use Narratio's native `config validate` for both `centaurs` and `dilfs` in
-   the base configuration and at least one campaign under `testing`. Use
-   `config show` or another native inspection surface to observe Notarius
-   enablement, the selected pipeline, one prepared reference, and one output
-   descriptor. Keep the existing check that the testing overlay changes only
-   its intended Scriptorium profile selections.
-7. As the existing uniquely named operator fixture in the runtime group, run
-   one native Notarius validation or inspection command against the same root
-   and imported fragment used by the service account. Add one actual
-   service/operator read-write exchange beneath `/var/cache/notarius`, or move
-   the existing representative exchange there, to exercise the new shared
-   root without parsing ACLs or mode bits. Do not add an exhaustive root or
-   identity matrix.
-8. Add one alternate convergence case that supplies two small version 5
-   pipeline maps and composes them into
-   `dnd_pipeline_notarius_pipelines` with Jinja `combine`, selects a matching
-   alternate pipeline ID, and overrides one cache choice. Observe the two
-   pipeline IDs and effective cache choice through native Notarius inspection,
-   then require one immediate identical repeat with `changed=0` and
-   `failed=0`.
-9. Retain the baseline clean repeat, immutable local asset inputs, isolated
-   dependency installation, cleanup safety, and existing representative
-   application checks. Restore the default deployment during cleanup.
-10. Do not run extraction, contact an LLM or WhisperX endpoint, snapshot a
-    complete rendered document, assert every nested pipeline field, test
-    filesystem metadata, or reproduce Notarius, Narratio, ConfigKit, PromptKit,
-    or Ansible behavior.
-
-### Validation
-
-Run from `ansible-role-dnd-pipeline`:
-
-```text
-tests/integration
-git diff --check
-git status --short
-```
-
-Expected result: isolated role and collection installation, syntax checking,
-and production-profile lint pass; native Notarius validation and effective
-inspection prove composition and representative policy; Narratio validates
-both campaigns and the testing profile; a supported group member can inspect
-the same Notarius configuration and exchange representative cache content;
-the combined-map/cache override is observable; all immediate repeats report
-`changed=0` and `failed=0`; and documentation matches the public interface.
-
-### Completion Criteria
-
-- Documentation describes the implemented suite policy, public customization
-  boundary, shared cache, testing behavior, and deliberate exclusions.
-- Tests protect role-owned integration behavior without freezing complete
-  defaults or testing module internals.
-- Both deployed campaigns validate, and the base and testing configurations
-  retain the enabled Notarius stage.
-- Baseline and representative override applications converge cleanly on their
-  immediate repeats.
-- The repository is valid and the stage is committed.
-
-### Commit
-
-Commit intent: `Document and test the D&D Notarius integration`
-
-## Stage 4: Record the Implementation for Review
-
-### Objective
-
-Record the completed implementation and validation evidence in the workspace
-without declaring the feature complete before independent review.
-
-### Required Policy Review
-
-Before beginning this stage, read:
-
-- `AGENTS.md`
-- `docs/orientation.md`
-- `docs/conventions.md`
-- `docs/planning.md`
-- `docs/roadmap/features/0010-dnd-notarius-extraction-integration.md`
-- `docs/roadmap/implementation.md`
-- `docs/status.md`
-
-### Preconditions
-
-- Stages 1 through 3 are committed and their owning repositories are clean.
-- Both complete integration entry points pass at the committed revisions.
-- The workspace control repository is clean at the planning commit.
-
-### Owning Repository
-
-`ansible-workspace-dnd`
-
-### Required Changes
-
-1. Update this plan's Progress Notes with the three implementation commit
-   hashes and concise validation results.
-2. Update `docs/status.md` so Feature 0010 is `in_progress`, its evidence names
-   the implementation commits, and the current focus is independent review of
-   the completed implementation.
-3. Keep the feature roadmap `ready`; do not mark Feature 0010 `done`, clean the
-   durable roadmap, or create `docs/roadmap/remediation.md`. Those actions
-   belong to the independent review and closeout workflow.
-4. Do not change implementation repositories or unrelated workspace policy in
-   this stage.
-
-### Validation
-
-Run from the workspace root:
-
-```text
-git diff --check
-./scripts/status
-git status --short
-```
-
-Expected result: the status report identifies only the intended workspace
-tracking edits before commit; both implementation repositories are clean; and
-the dashboard and progress notes point to the exact completed stage commits.
-
-### Completion Criteria
-
-- The implementation and validation evidence is traceable across repositories.
-- Feature 0010 remains awaiting independent review rather than being marked
-  complete.
-- The workspace control repository is valid and the stage is committed.
-
-### Commit
-
-Commit intent: `Record the D&D Notarius integration implementation`
-
-## Final Validation and Handoff
-
-After Stage 4, rerun both owning repositories' complete integration entry
-points:
-
-```text
-cd ansible-role-notarius && tests/integration
-cd ../ansible-role-dnd-pipeline && tests/integration
-```
-
-Then, from the workspace root, run:
-
-```text
-git diff --check
-./scripts/status
-```
-
-The final handoff must:
-
-- identify the Stage 1 through Stage 4 commit hashes and confirm each changed
-  repository has a clean working tree;
-- confirm syntax and production-profile lint pass in both changed roles;
-- confirm the standalone role installs an explicitly selected Notarius v0.7.0,
-  validates and inspects composed version 5 configuration natively, and
-  immediately converges cleanly;
-- confirm the pipeline installs the exact immutable Notarius-role commit,
-  validates the complete D&D pipeline and both Narratio campaign resolutions,
-  preserves Notarius under `testing`, supports the representative shared-user
-  path, and immediately converges cleanly;
-- confirm no upstream application, asset, collection, unrelated standalone
-  role, secret, external service, or real human account was modified;
-- summarize any deviation, blocker, or deferred work, including any pause
-  required to publish the Stage 1 dependency commit;
-- report any production complexity beyond the planned public variables,
-  dependency wiring, one imported fragment, one cache-root task, and extension
-  of the existing ACL loops, together with the acceptance criterion that
-  required it; and
-- leave Feature 0010 `in_progress` for independent review rather than marking
-  it `done`.
-
-## Progress Notes
-
-No implementation stages have begun. Record only concise stage commit hashes,
-validation results, and blockers here during execution; preserve detailed
-evidence in the implementation commits and final handoff.
+Discuss and select the next unit of work before preparing another plan.
+Operational deployment and live provider validation remain separate operator
+activities and are not authorized by this notice.

docs/roadmap/mvp.md

@@ -16,9 +16,9 @@ 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. 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.
+runtime identity or under an explicitly selected existing human account that
+belongs to the `narratio` group, processing D&D session recordings into
+transcripts and related artifacts.
 
 ## Locked Decisions
 
@@ -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
@@ -172,13 +183,24 @@ application-role releases in one source repository.
 
 - Development dependency manifests may temporarily refer to branches or
   commits while the roles are changing rapidly.
+- The projects' public repositories beneath
+  `https://gitea.maximumdirect.net/eric/` are the authoritative release
+  sources. Standalone roles are published through immutable Git tags.
 - Every released dependency manifest must pin each Git-hosted role dependency
   to an immutable role release tag.
 - The collection release is the compatibility record for the exact set of
   application-role versions it composes.
+- A collection release consists of its immutable repository tag, matching
+  Gitea release, and the `ansible-galaxy collection build` archive produced
+  from that tagged tree and attached to the Gitea release.
 - 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
@@ -231,9 +253,18 @@ application-role releases in one source repository.
 - Application source trees and installed binaries are owned by `root` and are
   not writable by operators or the runtime account.
 - 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.
+  commands either as the dedicated `narratio` account or as an existing human
+  account selected through the pipeline role's
+  `dnd_pipeline_operator_users` list. The list defaults to empty.
+- Every selected human account must exist before pipeline convergence. The
+  role adds selected accounts to the runtime group with additive supplementary
+  membership and does not create accounts, replace other group memberships,
+  or manage omitted accounts.
+- Removing a name from `dnd_pipeline_operator_users` does not revoke existing
+  membership. Account and access removal remain outside the MVP until an
+  explicit lifecycle policy is selected.
+- Newly granted supplementary membership may require the operator to begin a
+  new login session before it becomes visible to that session.
 - 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
@@ -255,9 +286,28 @@ application-role releases in one source repository.
 - 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.
+- Credential material lives beneath the conventional
+  `/usr/local/etc/narratio/secrets` subdirectory owned by
+  `narratio:narratio`, with directory mode `0750` and file mode `0640`.
+  Membership in the `narratio` group is an explicit authorization to use the
+  suite's shared credentials. This deliberately differs from Narratio's
+  general single-user `0700` and `0600` recommendation while retaining no
+  world access. Ordinary configuration contains only credential reference
+  names.
+- The pipeline role exposes one empty-by-default credential mapping from valid
+  environment-variable names to string file contents. Supplied entries manage
+  the corresponding files; omitted names remain unmanaged. Credential values
+  are expected to come from encrypted inventory such as Ansible Vault and are
+  suppressed from task output. Credential removal and directory mirroring are
+  outside the MVP.
+- Narratio's native ConfigKit secrets bootstrap owns loading these files and
+  process-environment precedence. The suite does not add a wrapper, shell
+  profile, service environment file, or parallel credential loader.
+- The suite coordinates Audita proposal and validation on the
+  `AUDITA_LLM_API_KEY` reference and selects `OPENROUTER_API_KEY` for
+  Notarius's production extraction profile. Narratio v2.1.0 resolves those
+  typed references and forwards only the selected credentials to the
+  corresponding subprocesses.
 - [Decision 0002](../decisions/0002-shared-readable-pipeline-filesystem-policy.md)
   records the complete rationale and boundary for this policy.
 
@@ -309,8 +359,9 @@ application-role releases in one source repository.
   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.
+  policy. Chunk plans are reused automatically. Narratio v2.1.0 requests reuse
+  of compatible recorded checkpoints during ordinary extraction; forced
+  extraction omits checkpoint loading and refreshes the active chunk plan.
 - 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
@@ -319,6 +370,15 @@ application-role releases in one source repository.
 - 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.
+- The D&D suite selects its Backblaze-compatible S3 archive, typed
+  `OBJECT_STORAGE_KEY_ID` and `OBJECT_STORAGE_KEY` references, maximum S3 audio
+  caching, run publication, human-facing transcript and artifact outputs, and
+  cleanup of successfully published workspace state. Feature 0015 owns the
+  exact overrideable defaults and publication set.
+- Accepted Notarius lane outputs remain addressable inside Narratio as
+  `narratio.extraction.<output_key>` sources. Future analyze-stage Scriptorium
+  artifacts may consume those sources directly; publishing an extraction lane
+  to a stable remote destination is an independent policy choice.
 
 ### Execution model
 
@@ -338,7 +398,7 @@ later design decision changes them:
 - `/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/etc/narratio/secrets` for suite-managed restricted credentials
 - `/usr/local/share/narratio/campaigns` for version-controlled campaign data
 - `/usr/local/share/narratio/prompt-library` for version-controlled prompts
   and schemas
@@ -374,12 +434,6 @@ managed host. The prompt-library checkout retains its upstream `prompts/` and
 
 ## Design Work Still Open
 
-The following areas require investigation and decisions before implementation:
+The following area requires investigation and decisions before implementation:
 
-- The mechanism used to incorporate the independently developed pipeline role
-  into collection releases
-- Secret injection and storage
-- 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

docs/roadmap/remediation.md

@@ -1,90 +1,144 @@
-# Feature 0009 Remediation Review
+# Feature 0022 Remediation Review
 
 Status: resolved
 
-Reviewed implementation commits:
+Reviewed on 2026-09-29:
+- Pipeline `8ea8621` and `ea8b09e`.
+- Collection subtree import through `a78c309` and assembly `3d77eb3`.
+- Consumer `f694dad`.
 
-- `66ebea9 Make Audita configuration ownership configurable`
-- `e9ae2dc Make Notarius configuration ownership configurable`
-- `8b4c86e Make Scriptorium configuration ownership configurable`
-- `eeb1105 Make Narratio configuration ownership configurable`
-- `901ae35 Apply shared configuration ownership to the D&D pipeline`
-- `dddc5ee Manage shared pipeline access with ACLs`
-- `f53da82 Test shared pipeline access across users`
-- `608d5be Document the shared pipeline execution model`
+The production wiring implements the approved coordinated versions, Audita
+backend/profile assets, credential lists, overlay paths, and nullable retry
+controls. The collection's imported pipeline tree exactly matches the source
+role. The following test-policy and operator-documentation issues were found
+and have now been addressed as recorded below.
+Git history preserves the previously resolved Feature 0013 remediation record.
 
-## Review Summary
+## Finding 1: New assertions freeze unconfigured suite defaults
 
-The production architecture and behavioral coverage implement Feature 0009 as
-planned. The four standalone roles expose generic configuration ownership and
-mode controls, and the pipeline selects its opinionated service-owned,
-world-readable policy through those interfaces. Narratio establishes the
-runtime identity first. The pipeline then installs ACL support and directly
-converges access and default ACLs on the three existing shared roots. Focused
-integration coverage exercises actual cross-identity configuration access and
-bidirectional writes under a restrictive umask while preserving immediate clean
-convergence.
+Priority: P2
+Owners: pipeline role and collection tests.
 
-No production code or test-suite remediation is required. One small consumer
-documentation inconsistency remains.
+Locations:
+- `ansible-role-dnd-pipeline/tests/integration:172`–173.
+- `ansible-collection-dnd/tests/integration:104`–105 and 108–109.
 
-## Finding 1: Operator Support Is Documented Inconsistently
+The new baseline assertions require specific Audita profile IDs and Narratio
+credential lists, but the cases do not explicitly supply the corresponding
+selection/list variables. Supplying synthetic values in `dnd_pipeline_secrets`
+does not select the credential lists. These assertions therefore fail when
+legitimate defaults change, even if installation and caller overrides work.
 
-Severity: low
+Required correction: remove redundant default-identity assertions from the
+baseline smoke case, or explicitly supply the relevant public inputs and
+assert those values. The pipeline already has a useful custom-credential
+override case; prefer reusing its coverage. Keep native validation and clean
+repeats. Do not replace literals by reading role defaults into expectations;
+that would still test implementation identity rather than caller behavior.
 
-`ansible-role-dnd-pipeline/README.md:201-217` first lists "operator access" as
-deferred, then correctly states that invocation by an existing member of the
-selected runtime group is supported. The likely deferred concern is operator
-selection and group-membership management, not operator access itself.
+This strengthens acceptance beyond the user's state-based testing policy.
+The approved plan explicitly asked for supplied-value tests, not default
+snapshots.
 
-The adjacent YAML fragment defines an otherwise unexplained
-`operator_group_members` variable but shows no consumer task or role that uses
-it. As written, copying the example does not manage any membership and may lead
-a reader to believe that the pipeline role consumes that variable.
+## Finding 2: Upgrade guidance confuses configuration with session migration
 
-### Required Remediation
+Priority: P2
+Owners: pipeline README and consumer deployment guidance.
 
-- Replace "operator access" in the deferred list with the precise deferred
-  behavior: operator selection and group-membership management.
-- Replace the inert variable fragment with a concise, complete consumer-side
-  example that actually adds a selected account to the runtime group, or omit
-  the example and state the prerequisite directly.
-- Keep human account and membership management outside the production pipeline
-  role.
+Locations:
+- `ansible-role-dnd-pipeline/README.md:166`–168 and 337–338.
+- `rakestraw-ansible/docs/pipeline-dnd.md:86`–104.
 
-## Resolution
+The pipeline links “Audita's v2 manifest migration” to Audita's configuration
+migration guide, but does not identify Narratio's actual session-manifest
+migration. The consumer likewise refers to “Audita manifests” and only
+generically warns about Narratio manifests. The roadmap specifically requires
+guidance on backing up and migrating local provenance while preserving
+progress and immutable snapshots. Existing Narratio manifests containing
+`effective_config.selected_profile` are rejected by v3.
 
-Resolved in pipeline-role commit `b15fe8d`. The deferred-work summary now
-names operator selection and group-membership management rather than operator
-access. The shared-filesystem section retains existing-group-member invocation
-as supported behavior and provides a complete consumer-owned
-`ansible.builtin.user` example that adds a selected account to the runtime
-group. No production role behavior changed.
+Required correction:
+- Describe Audita's change as a configuration/backend/profile migration.
+- Link Narratio v3's exact operations section
+  `#migrating-manifest-overlay-provenance`; briefly explain backup and
+  `effective_config.selected_profile` → `selected_overlay` (or removal as
+  upstream permits), preserving stage/checkpoint state and leaving immutable
+  remote snapshots unchanged. Do not add automatic migration or forced reruns.
+- Correct or remove the stale claim that Notarius v0.8.1 selects PromptKit
+  v0.10.0. Its tagged release specifies v0.11.2; prefer linking upstream release
+  notes over duplicating dependency/catalog versions.
 
-## Required Validation
+This is a missing operator handoff, not a request for additional runtime code.
 
-After the documentation correction, run:
+## Finding 3: Documentation makes managed secret files mandatory
 
-```text
-cd ansible-role-dnd-pipeline && tests/integration
-git diff --check
-```
+Priority: P2
+Owners: pipeline README and consumer deployment guidance.
 
-The expected result remains successful native configuration checks,
-representative cross-identity access, and immediate repeats with `changed=0`
-and `failed=0`.
+Locations:
+- `ansible-role-dnd-pipeline/README.md:160`–163.
+- `rakestraw-ansible/docs/pipeline-dnd.md:69`–71.
 
-## Review Validation Evidence
+The new text requires each credential to be supplied through
+`dnd_pipeline_secrets`. Runtime behavior does not require that: Narratio can
+resolve listed names from its process environment or existing secret files.
+The README's existing managed-credentials section already describes environment
+precedence and an empty default secrets map.
 
-The independent review inspected the complete diffs for all eight stage
-commits and confirmed that every dependency pin resolves to the intended
-standalone-role commit. `git diff --check` passed across all five changed role
-repositories. The complete pipeline `tests/integration` entry point passed its
-isolated dependency installation, syntax check, production-profile lint,
-native application checks, cross-identity access exercise, configurable
-profile and version cases, and immediate clean repeats. All repositories were
-clean before this review document was revised.
+Required correction: require the credential names in the forwarding lists,
+but describe managed secret files as the suite-supported provisioning option,
+not the only permitted source. Preserve the consumer's chosen Vault workflow
+without imposing it on every standalone suite user. No code or new tests are
+needed for this wording correction.
 
-After remediation, the complete pipeline integration entry point and
-`git diff --check` passed again. The test fixture was removed and the baseline
-Seriatim version and pipeline configuration were restored during cleanup.
+This is an unintended documentation-level strengthening of the requirements.
+
+## Review Validation
+
+Shell syntax, changed-commit whitespace checks, pipeline syntax checking with
+locally available collections, production-profile lint, and collection build
+passed. Source and imported pipeline Git tree hashes match exactly. Reviewed
+the recorded successful role/collection integration and consumer syntax runs;
+did not rerun host-mutating convergence. A fresh dependency installation stalled
+and was stopped, so this review does not independently establish a complete
+fresh public dependency installation. No operational host was contacted.
+
+## Remediation Boundaries
+
+Fix authoritative pipeline files first, then publish and re-import the corrected
+pipeline revision through the existing public Gitea subtree workflow. Do not
+edit its collection copy directly. Update collection-owned tests and consumer
+pins/links to the corrected public snapshot as needed. Preserve all agreed
+application versions, configuration defaults, and runtime behavior. Validate
+affected tests in proportion to the changes; no operational deployment,
+credentials, live inference, or session migration is required.
+
+## Resolution Evidence
+
+All three findings were addressed on 2026-09-29:
+
+- Finding 1: pipeline `37b1cf6` removes redundant baseline credential-list
+  assertions while preserving custom-input coverage; collection `d9abb62`
+  removes default profile-ID and credential-list assertions. Native profile
+  inspection, configuration validation, and immediate clean-repeat checks remain.
+- Findings 2 and 3: pipeline `37b1cf6` and consumer `15f0f4e` distinguish
+  Audita configuration migration from Narratio session migration, link the
+  exact provenance procedure, preserve progress and immutable snapshots,
+  and allow environment or file-based credential provisioning. The stale
+  Notarius dependency/catalog claim is replaced by tagged release guidance.
+- The public pipeline revision is
+  `37b1cf6fab71c6a1212e49357c2e825cb0237a00`; collection subtree import and
+  public revision `b3bc0457efb7ea14ed11789978edd440537860fc` contain its exact
+  Git tree. Both remote branch heads were independently checked with
+  `git ls-remote`. Consumer `15f0f4e` selects that collection and links the
+  corrected source README; the consumer commit remains local.
+- Shell syntax and whitespace checks passed. Pipeline and installed-collection
+  syntax checks and production-profile lint passed. Collection build and
+  disposable artifact installation passed. Consumer real-inventory host
+  listing selected only `pipeline-dnd`, and syntax checking passed without
+  deployment or Vault decryption.
+- Validation used the previously downloaded public role dependencies and
+  available local collections. Full host-mutating integration was not rerun:
+  production code/defaults are unchanged, test changes remove assertions and
+  unused parsing, and prior full-run evidence remains applicable to unchanged
+  behavior. No operational system or session state was modified.

docs/status.md

@@ -1,11 +1,18 @@
 # Workspace Status
 
-Last updated: 2026-09-15
+Last updated: 2026-09-29
 
-Current milestone: M1-03 suite-level pipeline role
+Current milestone: Operational D&D pipeline deployment
 
-Current focus: Publish the completed Notarius role revision required to resume
-Feature 0010.
+Current focus: Feature 0023 is complete after independent review with no findings.
+Narratio v3.1.0 and Scriptorium credential selection are wired through the
+standalone role, D&D suite, collection, and local consumer pins. No active
+implementation plan remains. Deployment of this update and live credential
+validation remain operator activities; neither was performed by this feature.
+Feature 0022 and the application upgrade sequence remain complete. Broader
+downgrade/removal policy remains unselected design work.
+See the [upgrade sequence](roadmap/application-upgrade-sequence.md) and
+[feature evidence](roadmap/features/0023-narratio-scriptorium-credentials.md).
 
 | ID | Deliverable | Owner | State | Evidence or next step |
 | --- | --- | --- | --- | --- |
@@ -16,8 +23,8 @@ Feature 0010.
 | M0-05 | Suite-level role repository | ansible-role-dnd-pipeline | done | Repository created and added to `workspace.yml` |
 | M1-01 | Remaining MVP design decisions | workspace | done | Feature 0003 roadmap fixes the Notarius configuration interface |
 | M1-02 | Standalone application roles | role repositories | done | All five standalone roles implemented and independently reviewed |
-| M1-03 | Suite-level pipeline role | ansible-role-dnd-pipeline | blocked | Publish the completed Notarius role revision, then resume Feature 0010 |
-| M1-04 | Collection assembly | ansible-collection-dnd | proposed | Select and implement the pipeline-role incorporation mechanism |
+| M1-03 | Suite-level pipeline role | ansible-role-dnd-pipeline | done | Features 0006 through 0011 completed through remediation commit `de1b191` |
+| M1-04 | Collection assembly | ansible-collection-dnd | done | Implemented and independently reviewed through collection remediation commit `da67b34` |
 | F0001 | Install Seriatim from pinned source | ansible-role-seriatim | done | Implementation, integration coverage, and final remediation completed through `fb8dc41` |
 | F0002 | Install and configure Audita | ansible-role-audita | done | Field-specific configuration completed in `e61f02f` and `847c4c3`; full suite passed |
 | F0003 | Install and configure Notarius | ansible-role-notarius | done | Implemented and validated through remediation commit `eb4f511` |
@@ -27,8 +34,21 @@ Feature 0010.
 | F0007 | Deploy D&D campaigns and prompt assets | ansible-role-dnd-pipeline, campaigns, and narratio-prompts | done | Implemented and validated through remediation commit `7572fa3` |
 | F0008 | Define opinionated D&D processing configuration | ansible-role-dnd-pipeline | done | Implemented and independently reviewed through remediation commit `3e253d7` |
 | F0009 | Establish shared pipeline filesystem and execution | configuration-bearing application roles and ansible-role-dnd-pipeline | done | Implemented and independently reviewed through remediation commit `b15fe8d` |
-| F0010 | Integrate D&D Notarius extraction | ansible-role-notarius and ansible-role-dnd-pipeline | blocked | Stage 1 completed in Notarius role commit `14a38e04e35ef524d6a97fa7fb5a04981a0a2161`; publish it to the canonical origin before Stage 2 |
+| F0010 | Integrate D&D Notarius extraction | ansible-role-notarius and ansible-role-dnd-pipeline | done | Implemented and independently reviewed through remediation commit `bbf01e1` |
+| F0011 | Deliver pipeline credentials and Notarius reuse | ansible-role-narratio and ansible-role-dnd-pipeline | done | Implemented and independently reviewed through remediation commit `de1b191` |
+| F0012 | Assemble the D&D collection | ansible-collection-dnd and ansible-role-dnd-pipeline | done | Pipeline `600eb21` assembled and validated through collection remediation commit `da67b34` |
+| F0013 | Publish the first coordinated suite release | all Ansible repositories and workspace | done | Public [`rakestraw.dnd` 0.1.0 release](https://gitea.maximumdirect.net/eric/ansible-collection-dnd/releases/tag/v0.1.0); documentation remediation completed in pipeline `78afffe` and collection `5e695f3` |
+| F0014 | Enroll existing pipeline operators | ansible-role-dnd-pipeline, ansible-collection-dnd, and workspace | done | Pipeline `c13f726` and collection import `c0b0ebd` passed their complete integration suites and independent review with no remediation findings |
+| F0015 | Enable D&D S3 storage and publishing | ansible-role-dnd-pipeline, ansible-collection-dnd, and workspace | done | Pipeline `51566afcf69083cdbb5b5718f2544c86b079001c`, collection fixture `cf3de016ee09edf91afc3bc1addfd926d4a172ad`, collection squash `77f67adbc0f700e88bc15554e02052eaa22f1033`, and collection merge `46913446765e86ecfb29ebad9955d579ef6a4c7e` passed the complete repository suites and independent review with no remediation findings |
+| F0016 | Prepare the D&D deployment playbook for `pipeline-dnd` | rakestraw-ansible and workspace | done | Consumer `716a80e`, `12b2462`, and `7f8353d` passed independent review with no findings; public dependency installation, target-only host listing, syntax and whitespace checks passed. Follow-up `7f4c90a` pins collection `2a53979` for Narratio v2.1.2; collection build and syntax checks passed |
+| F0017 | Compose the Notarius testing overlay | Narratio role, pipeline role, collection, consumer, and workspace | done | Published through Narratio `330afe7`, Notarius `a82a83d`, pipeline `c56a942`, collection `ce5b838`, and consumer `0ced48c`; independent review found no remediation issues; validation evidence is in the feature roadmap |
+| F0018 | Adopt Scriptorium v0.15.0 | Scriptorium role and workspace | done | Role commits `61dcafe`, `2fce529`, and `b174c8c` passed independent review with no findings; feature roadmap records validation; suite pins unchanged |
+| F0019 | Adopt Audita v2.0.1 | Audita role and workspace | done | Role `c3dd59f`, following `6137ff2` and `52f67fe`, passed independent review with no findings; [roadmap](roadmap/features/0019-audita-v2-adoption.md) records validation; suite pins unchanged |
+| F0020 | Adopt Notarius v0.8.1 | Notarius role and workspace | done | Role `6aef48b`, following `b1b922c` and `380b6a3`, passed independent review with no findings; [feature roadmap](roadmap/features/0020-notarius-v0-8-adoption.md) records evidence; suite pins unchanged |
+| F0021 | Adopt Narratio v3.0.0 | Narratio role and workspace | done | Role `3c0700b`, following `a28f22c` and `45f6836`, passed independent review with no findings; [feature roadmap](roadmap/features/0021-narratio-v3-adoption.md) records evidence; suite pins unchanged |
+| F0022 | Integrate the reviewed application upgrades | Pipeline role, collection, consumer, and workspace | done | Closed after review and resolution of all three findings; public pipeline `37b1cf6`, public collection `b3bc045`, local consumer `15f0f4e`; [remediation evidence](roadmap/remediation.md) |
 | A0001 | Audit completed standalone-role test suites | workspace and standalone roles | done | Findings recorded in `docs/roadmap/test-suite-audit-findings.md` |
+| F0023 | Adopt Narratio v3.1.0 and forward Scriptorium credentials | Narratio role, pipeline role, collection, consumer, and workspace | done | Public Narratio role `758aed7a`, pipeline `0f841fd`, collection `002e86c`; local consumer `67cc22f`. Independent review found no actionable issues; [feature evidence](roadmap/features/0023-narratio-scriptorium-credentials.md) |
 | R0001 | Simplify completed standalone-role test suites | workspace and standalone roles | done | Role commits `e08c63c`, `d2d0b9d`, and `cfecf37` passed implementation and independent review |
 
 ## Updating This File