Update feature roadmap to include a named pipeline profile configuration model

docs/roadmap/documentation.md

@@ -100,42 +100,54 @@ generic runner or framework docs.
 
 ### CLI Docs Should Reflect Extensibility
 
-The CLI reference should present input modules, chunk modules, extract modules,
-merge modules, normalize modules, and output modules as selectable or
-configurable components as they become user-facing.
+The CLI reference should present named pipeline profiles as the primary
+user-facing abstraction. Individual stage modules should be visible through
+pipeline configuration and discovery commands, not through ad hoc structural
+run flags.
 
 Provisional command shape:
 
 ```sh
-notarius extract ./source.json --input seriatim --extractors dnd.spells --output ./artifacts.json
+notarius run dnd-session --input ./source.json
+notarius run dnd-session --input ./source.json --only spells,npcs
+notarius config validate
+notarius pipelines list
 ```
 
 Once implemented, `docs/cli.md` should document:
 
-- positional source input path;
-- input module selection;
-- extract module selection;
-- chunk/merge/normalize/output selection when configurable;
+- pipeline ID selection;
+- required input path flags;
+- `--only` artifact-lane selection;
 - config path behavior;
+- operational overrides such as output path, model, concurrency, and diagnostics
+  directory;
 - output path behavior;
 - diagnostics and report behavior;
 - exit codes.
 
 ### Config Docs Should Separate Framework And Plugin-Like Options
 
-`docs/config.md` should group fields by responsibility:
+`docs/config.md` should describe named pipeline profiles and the resolved
+pipeline model.
 
-- input module selection and module-specific options;
-- chunk module selection and module-specific options;
-- extract module selection and module-specific options;
-- merge module selection and module-specific options;
-- normalize module selection and module-specific options;
-- output module selection and module-specific options;
-- LLM runtime;
-- validation runtime;
-- diagnostics.
+It should cover:
 
-Module-specific config should not leak into unrelated core config sections.
+- config file locations and precedence;
+- `llm_profiles`;
+- `pipelines.<pipeline_id>.input`;
+- `pipelines.<pipeline_id>.chunk`;
+- `pipelines.<pipeline_id>.artifacts.<lane>.extract`;
+- lane `merge`, `normalize`, and validator settings;
+- output module selection;
+- string shorthand versus inline module-binding object form;
+- defaults for omitted slots;
+- capability validation;
+- pipeline digest and manifest provenance.
+
+Module-specific config should stay inline with the pipeline slot that owns it.
+Top-level named module instances should not be introduced until repeated inline
+settings create real drift. `llm_profiles` are the cross-cutting exception.
 
 ### Examples Should Stay Real
 
@@ -148,6 +160,7 @@ Likely future examples:
 examples/seriatim-minimal-transcript.json
 examples/minimal-config.yml
 examples/dnd-spells.artifacts.json
+examples/dnd-session.config.yml
 ```
 
 Examples should be secret-free and should use the same command shapes documented
@@ -179,6 +192,8 @@ Before merging docs, check:
 - Are D&D details isolated to extract module or artifact docs?
 - Is there one canonical home for the topic?
 - Do command examples match implemented CLI syntax?
+- Do config examples use named pipeline profiles rather than ad hoc module
+  flags?
 - Are examples valid, maintained, and free of secrets?
 - Did any architecture, config, CLI, stage module, validator, or artifact
   contract change require a docs update?