Prepare canonical party and derived players inputs

docs/integrations/notarius.md

@@ -41,6 +41,12 @@ selector, as direct argument-vector entries without shell interpretation. A CLI
 binding takes precedence over a matching external path in Notarius
 configuration. Narratio never emits `--without-reference`.
 
+For canonical party configuration, the `party` binding is the unchanged,
+validated authored roster and the `players` binding is its generated
+projection. Both retain their established `narratio.input.party` and
+`narratio.input.players` source IDs, and both are resolved from the prepared
+manifest rather than from campaign configuration at extraction time.
+
 The maintained D&D boundary binds only the four campaign-owned external slots:
 
 ```text

docs/integrations/party.md

@@ -47,3 +47,27 @@ must not override their party or players inputs.
 
 Use the canonical document for new campaigns. The configuration rules and
 source-relative path behavior are defined in the [Configuration Reference](../config.md).
+
+## Derived players document
+
+During `prepare`, Narratio copies the canonical party source bytes unchanged
+to `inputs/party.yml` and writes this deterministic players-only projection to
+`inputs/players.yml`:
+
+```yaml
+schema_version: narratio.players.v1
+players:
+    - name: Eric
+      character:
+        id: arannis
+        name: Arannis
+        alias:
+            - Ari
+            - The Grey Owl
+```
+
+There is one entry per character, sorted by stable character ID. Repeated
+player names remain separate entries. The optional `alias` list retains its
+declared order and is omitted when empty. The projection carries no class
+data. Its prepared manifest record is marked `derived_from_party`; it is not a
+separate user-provided `players_file`.

docs/internal/artifacts.md

@@ -39,7 +39,10 @@ ID.
 Prepared stable source IDs are `narratio.input.players`,
 `narratio.input.party`, `narratio.input.glossary`, and
 `narratio.input.spell_catalog`. Artifact policy owns their canonical manifest
-kind and prepared filename vocabulary.
+kind and prepared filename vocabulary. Canonical party mode preserves the
+party source bytes in the party record and supplies the players record from the
+deterministic `derived_from_party` projection; both remain ordinary prepared
+source IDs for consumers.
 
 ## Runtime Catalog
 

docs/internal/manifest.md

@@ -25,6 +25,12 @@ portable opaque segments. Unsafe legacy identities are rejected with migration
 guidance rather than being normalized into a different workspace or remote
 namespace.
 
+Prepare records independent `party` and `players` input checksums. In canonical
+party mode, the party record retains its campaign source identity while the
+players record uses `derived_from_party`; raw roster content is never embedded
+in manifest metadata. Both records remain the durable authority for consumers
+of their prepared input source IDs.
+
 The model admits these stage states:
 
 - `pending`

docs/internal/stage-prepare.md

@@ -39,6 +39,9 @@ Materialize canonical current-session inputs before processing stages.
 - materializes a configured spell catalog with checksum and provenance, or
   safely removes an obsolete canonical spell catalog and its manifest record
   when the effective input is omitted.
+- in canonical party mode, copies the validated raw party bytes unchanged and
+  deterministically generates the prepared players projection; legacy mode
+  continues to copy its opaque party and explicit players sources.
 - scans enabled configured artifact inputs for `narratio.previous_session.artifact.*` requirements.
 - clears managed `previous/` state on every invocation, then, when requirements exist:
   - resolves the pointer-selected previous source through the shared resolver;
@@ -62,7 +65,8 @@ mapping, while the isolated legacy reader rejects ambiguous fallback matches.
 Prepare records a versioned semantic-configuration fingerprint for the
 resolved campaign/session selection, local-versus-S3 audio mode and canonical
 audio names, stable-input ownership/presence, previous-session identity, and
-the effective previous-artifact requirement set. A change reruns prepare and
+the party mode plus canonical players projection version, and the effective
+previous-artifact requirement set. A change reruns prepare and
 stales its fixed descendants. Existing successful records without this
 evidence rerun once when selected.
 

docs/operations.md

@@ -237,6 +237,11 @@ prepared inputs. Their canonical locations are `inputs/party.yml`,
 `inputs/spell_catalog.json`. Extraction supplies Notarius with verified copies
 under `runs/<run_id>/extract/references/` so a concurrent refresh of canonical
 prepared files cannot change the bytes consumed by an in-flight invocation.
+For a canonical party, preparation retains the validated authored party bytes
+at `inputs/party.yml` and generates `inputs/players.yml` from that roster.
+The manifest records their checksums separately, with the players input marked
+as derived from the party; refresh preparation after changing the roster rather
+than editing either prepared file.
 Inspect the effective stable-input inventory and
 prepared-file readiness with:
 

docs/roadmap/implementation.md

@@ -705,7 +705,7 @@ enforce one unambiguous canonical versus legacy input mode.
 
 ## Stage 12 — Canonical Party And Derived Players Preparation
 
-**Status: Pending**
+**Status: Completed**
 
 ### Goal