Plan Notarius configuration profile support

docs/roadmap/notarius-config-profile.md

@@ -0,0 +1,151 @@
+# Notarius Configuration Profile Selection
+
+Status: Proposed; not implemented.
+
+## Goal and Authority
+
+Implement the consumer behavior in the
+[feature request](feature-request-notarius-config-profile.yml): let a Narratio
+configuration overlay explicitly select a Notarius configuration overlay.
+Operators can select testing once in Narratio while each application retains
+ownership of its own model choices and other settings.
+
+This roadmap describes the target state and required change areas, not an
+implementation sequence; the [implementation plan](implementation.md) owns
+the ordered work and implementation decisions. The feature request is the scope
+authority; the mechanisms suggested below do not establish additional
+user-facing contracts.
+
+## Underlying Issue
+
+Narratio can select its own testing profile, but extraction currently invokes
+Notarius without a configuration-profile selector. Consequently, a Narratio
+testing invocation cannot explicitly select the independently deployed Notarius
+testing overlay through pipeline configuration.
+
+Adding individual downstream model or tuning fields would duplicate Notarius's
+configuration responsibilities. Passing its existing profile selector provides
+the requested flexibility without that duplication.
+
+## Targeted End State
+
+### Explicit Configuration Composition
+
+`pipeline.notarius.config_profile` is an optional Notarius configuration-profile
+name, usable in Narratio's base configuration and ordinary overlays. For
+example, Narratio's `profiles/testing.yml` may contain:
+
+```yaml
+notarius:
+  config_profile: testing
+```
+
+Selecting Narratio's `--profile testing` then selects that explicit downstream
+profile whenever extraction executes. The two profile names need not match.
+Narratio does not automatically forward its own profile name.
+
+When supplied, the selection is passed through Notarius's `--config-profile`
+argument. Omitted or null values add no profile-selection flag and preserve
+existing downstream selection behavior. Notarius's selector semantics remain
+authoritative, including empty and `default` selections for the composed base
+configuration. Narratio does not introduce a stricter profile-name policy.
+
+This field selects a ConfigKit configuration overlay, not a PromptKit profile
+through `--llm-profile`. The Notarius overlay owns any resulting LLM-profile
+selection. Notarius resolves overlays relative to its own configuration root;
+Narratio neither resolves those files against its own root nor rewrites them.
+
+### Execution, Reuse, and Failure
+
+A changed downstream profile selection must not silently reuse Narratio's
+completed extraction from the previous selection. Existing dependent-stage
+invalidation applies when extraction changes; the feature does not change the
+pipeline order or transcript-generation behavior.
+
+Notarius continues to own downstream overlay discovery, composition, validation,
+and cache compatibility. A missing or invalid selected overlay must fail
+extraction through the existing subprocess error path, without silently falling
+back to production or reporting successful extraction.
+
+Existing resume and chunk-cache controls, including force precedence, remain
+in place. Profile selection does not itself mean forced regeneration or cache
+deletion. Narratio's decision to execute extraction and Notarius's decision to
+reuse compatible work remain separate responsibilities.
+
+Changes to private Notarius configuration behind an unchanged selector retain
+the existing operator responsibility to force extraction when needed. There is
+no new downstream file inspection or content-tracking requirement.
+
+Credential forwarding remains independently configured through
+`notarius.llm_api_key`. A Narratio testing overlay may select a different
+credential reference alongside the downstream profile; no new credential
+discovery or provider-name mapping is introduced.
+
+## Required Change Areas
+
+### Configuration and Inspection
+
+Extend the typed Notarius configuration and its existing safe effective-YAML
+projection to carry the optional field. Preserve the ordinary configuration
+composition behavior for base values, overlay overrides, and null values.
+Configuration inspection must reflect the selected field without exposing
+credential values. No replacement configuration loader or downstream preflight
+loader is needed.
+
+### Stage and Adapter Boundary
+
+Carry the selection from resolved configuration through the extraction request
+to the subprocess adapter. Construct the optional CLI flag using the existing
+argument-vector mechanism, alongside the current configuration path, references,
+credential forwarding, and cache controls. Retain normal Notarius error handling.
+
+### Extraction Reuse Evidence
+
+Account for the downstream selection in the existing extraction reuse evidence.
+The current semantic-configuration and invocation fingerprints are the relevant
+change points. Keep their treatment of selection consistent so that a profile
+change cannot bypass the required rerun and downstream invalidation.
+
+This roadmap does not require a new manifest schema, separate profile-indexed
+workspaces, historical per-profile result retention, or an upgrade-wide forced
+rerun.
+
+### Verification and Documentation
+
+Use focused behavioral coverage for configuration composition and inspection,
+explicit argument forwarding and omission, changed-selection reuse decisions,
+and ordinary subprocess failure handling. Reuse existing test coverage where
+it already protects unchanged credentials, force behavior, and invalidation;
+do not duplicate Notarius's complete profile-validation or cache test suites.
+
+When implemented, update the canonical
+[configuration reference](../config.md),
+[Notarius integration contract](../integrations/notarius.md),
+[extract internals](../internal/stage-extract.md), and relevant maintained
+examples. The development workflow in [Operations](../operations.md) should
+explain explicit profile composition and the existing need to force extraction
+after private downstream edits. Clarify that profile selection does not create
+an isolated testing workspace or separate current extraction state.
+
+## Compatibility and Scope Boundaries
+
+Notarius v0.7.0 already documents `--config-profile`; no upstream change is
+required. Document the capability needed when the option is used, without adding
+an unconditional runtime version gate for existing unconfigured deployments.
+
+This feature adds no Narratio CLI selector, automatic profile propagation,
+Notarius LLM-profile selector, downstream configuration rewriting, new
+credential mechanism, or generalized recursive orchestration. Existing output
+and receipt contracts remain unchanged.
+
+The consumer's Ansible role and suite updates are follow-up work outside this
+repository. They can deploy downstream overlays and populate this field after
+the interface is released.
+
+## Scope Review
+
+No stronger requirements or new invariants are proposed beyond the feature
+request and existing repository contracts. In particular, minimizing one-time
+upgrade invalidation and avoiding reruns between equivalent base selectors are
+implementation considerations, not additional acceptance guarantees imposed
+by this roadmap. No user decisions are currently required before planning.