Add configuration source reporting

docs/cli.md

@@ -78,11 +78,12 @@ Commands with additional positionals keep their command-specific order:
 
 ## Command Reference
 
-### `config validate` and `config show`
+### `config validate`, `config show`, and `config sources`
 
 ```bash
 narratio config validate [--config <pipeline.yml>] [--campaign <id> | --campaign-file <campaign.yml>] [--profile <name>]
 narratio config show [--config <pipeline.yml>] [--campaign <id> | --campaign-file <campaign.yml>] [--profile <name>]
+narratio config sources [--config <pipeline.yml>] [--campaign <id> | --campaign-file <campaign.yml>] [--profile <name>]
 ```
 
 These commands resolve the selected profile, defaults, ordinary paths, and—if
@@ -102,6 +103,15 @@ writes one deterministic, secret-free YAML document containing defaulted and
 expanded concrete configuration. It omits composition declarations, artifact
 family declarations, and runtime provenance.
 
+`config sources` reports the same fully validated resolution without printing
+effective values. Its header identifies the root, ordered imports, selected
+profile and overlay, selected campaign, party mode/source, and digest. The
+remaining tab-separated records are sorted as `path`, `role`, and `source`.
+Roles distinguish root, import, profile, centralized default, campaign, party,
+legacy-player, and generated family ownership. A generated party member has
+one family record and one party record at the same logical path. The output
+never reads or prints secret values.
+
 ### `version`
 
 ```bash

docs/config.md

@@ -44,10 +44,10 @@ the durable copied session input.
 
 ### Read-only effective pipeline inspection
 
-`narratio config validate` and `narratio config show` use the same `--config`,
-`--campaign`, `--campaign-file`, and `--profile` selection rules as pipeline
-commands, but do not select, discover, or load a session. They do not read
-credential values or create runtime state.
+`narratio config validate`, `narratio config show`, and `narratio config
+sources` use the same `--config`, `--campaign`, `--campaign-file`, and
+`--profile` selection rules as pipeline commands, but do not select, discover,
+or load a session. They do not read credential values or create runtime state.
 
 Campaign selection is optional only when the resolved pipeline has no
 `scriptorium.artifact_families`. When families are declared, Narratio selects a
@@ -56,7 +56,11 @@ then parses the campaign-owned party and expands concrete artifacts and any
 family publish rules before validation. `config validate` prints the resulting
 root, profile, and effective digest. `config show` emits the normalized
 effective pipeline YAML, with defaults and concrete expansion included but
-composition and family declarations omitted. The [CLI reference](cli.md#config-validate-and-config-show)
+composition and family declarations omitted. `config sources` prints a stable
+source projection instead of effective values: root/import/profile/default
+ownership plus campaign/party and generated-family records. Canonical derived
+players trace to the party; a legacy configured players file is explicitly
+marked as a legacy player source. The [CLI reference](cli.md#config-validate-config-show-and-config-sources)
 owns command syntax and output conventions.
 
 ### Identity segments

docs/internal/configuration.md

@@ -68,6 +68,17 @@ family declarations. The result contains no composition envelope or private
 provenance fields and has one trailing newline; commands do not marshal runtime
 objects directly.
 
+`EffectivePipelineSources` and `EffectiveCampaignSources` provide the separate
+safe provenance projection for `config sources`. Pipeline ownership begins with
+the complete logical field paths retained during composition and classifies
+each contributor as root, import, profile, or centralized default. The
+projection replaces generated concrete member paths with paired family and
+canonical-party records, and does the same for generated publish rules.
+Campaign records identify campaign-owned fields and party inputs; canonical
+derived players point to the party source, while legacy players retain a
+dedicated legacy-player role. The application command only joins these sorted
+records with selection metadata and never reparses configuration files.
+
 Campaign context construction also reads and classifies the campaign-owned
 party source through `ParseParty`. A canonical party retains its raw bytes and
 normalized roster in runtime-only `ResolvedParty` provenance, while a legacy

docs/roadmap/implementation.md

@@ -1002,7 +1002,7 @@ without creating a session, workspace, run, or external adapter.
 
 ## Stage 18 — Read-Only `config sources`
 
-**Status: Pending**
+**Status: Completed**
 
 ### Goal
 

docs/troubleshooting.md

@@ -71,6 +71,32 @@ Safe fix:
 
 Relevant reference: [Configuration](./config.md).
 
+## Unexpected imported or profile value
+
+Symptom:
+
+- an effective configuration value differs from the root file, or a duplicate
+  ownership/configuration error is hard to locate.
+
+Diagnostics:
+
+```bash
+narratio config sources --config /path/pipeline.yml --profile testing
+```
+
+Add `--campaign` or `--campaign-file` when the pipeline has party-driven
+artifact families. The output identifies each effective logical field's root,
+import, profile, default, campaign, party, or family source without printing
+the field value or credential contents.
+
+Safe fix:
+
+- move a duplicated base field so it has one owner;
+- correct the selected profile or its overlay; or
+- correct the campaign party/family declaration that owns generated values.
+
+Relevant reference: [Configuration inspection](./config.md#read-only-effective-pipeline-inspection).
+
 ## Audio mode conflict
 
 Symptom: