Put stable D&D prompt content before transcripts

docs/internal/modules.md

@@ -51,15 +51,12 @@ declarations, prompt-input assembly, and source-unit/citation helpers belong in
 D&D scene chunker and spell, NPC, and combat-turn extractors use ordered
 package-local prompt manifests for both rendering and prompt fingerprinting, so
 only the shared fragments each prompt actually renders participate in either
-operation. The three extraction prompts share the order system, extraction
-evidence, in-world identity, transcript, and campaign references, with
-ephemeral cache control on identity, transcript, and references. Spell and
-combat prompts append immediate resolution and an ephemeral NPC registry before
-lane-specific material; the NPC prompt appends its task and instructions. The
-scene prompt uses system, transcript, and campaign references before its
-lane-specific task and instructions, with ephemeral cache control on transcript
-and references. Stage contracts expose only Notarius structured-completion
-types, not Scriptorium public types.
+operation. Extraction prompts place stable shared and lane-specific context
+before the variable transcript and use shared assets for wording common across
+lanes. The canonical ordering and cache-boundary policy is documented in
+[LLM Runtime](llm.md#dd-extraction-prompt-ordering-and-cache-boundaries). Stage
+contracts expose only Notarius structured-completion types, not Scriptorium
+public types.
 
 The shared `ChunkPromptMaterial` helper owns common transcript material
 preparation for the spell, NPC, and combat-turn extractors. It clones supplied
@@ -240,15 +237,14 @@ assigns source identity and deterministic NPC IDs, and preserves source
 references for deterministic validation. It uses the shared campaign
 references only for disambiguation and does not consume the optional NPC
 registry slot. Its prompt and private response schema are package-owned. The
-prompt uses the common evidence, identity, transcript, and campaign-reference
-messages, then the NPC-specific task and instructions; only the identity,
-transcript, and campaign-reference messages carry ephemeral cache control.
+prompt follows the shared D&D extraction ordering and cache policy documented
+in [LLM Runtime](llm.md#dd-extraction-prompt-ordering-and-cache-boundaries).
 
 ### `internal/modules/dnd/extract/combatturns`
 
 The combat extractor prepares one structured request per supplied chunk using
-the shared extraction-evidence, identity, transcript, campaign-reference,
-immediate-resolution, and NPC-grounding prompt inputs. It
+the shared extraction-evidence, identity, campaign-reference,
+immediate-resolution, NPC-grounding, and transcript prompt inputs. It
 maps the private response to `dnd.CombatTurnList`, assigns the current source
 identity, removes exact duplicate source ranges, and orders turns by valid
 source-document position while preserving malformed candidate fields for
@@ -256,11 +252,11 @@ deterministic validators. Its package-owned private response schema enforces
 only the structural JSON envelope; semantic artifact constraints remain with
 the validator chain. Its prepared metadata and checkpoint fingerprints contain
 only prompt/schema/mapping identities plus an optional NPC registry digest.
-The prompt renders immediate resolution and the NPC registry before the
-combat-specific task and instructions; identity, transcript, campaign
-references, and the NPC registry use ephemeral cache control. The package
-exposes typed registration and is included in the production D&D registrar with
-the default combat extraction chain.
+The prompt follows the shared D&D extraction ordering and cache policy
+documented in
+[LLM Runtime](llm.md#dd-extraction-prompt-ordering-and-cache-boundaries). The
+package exposes typed registration and is included in the production D&D
+registrar with the default combat extraction chain.
 
 The combat normalizer accepts only the optional structured NPC registry.
 Campaign references remain extractor-only LLM context and are not materialized
@@ -448,6 +444,10 @@ When adding a production module or validator:
 2. expose and test its spec, constructor, and registration function;
 3. keep format or domain parsing inside the concrete package;
 4. add package-owned prompt/schema assets when the extension is LLM-backed;
+   new LLM-backed D&D extraction modules must follow the stable-to-variable
+   prompt ordering, shared-asset ownership, and cache-boundary policy in
+   [LLM Runtime](llm.md#dd-extraction-prompt-ordering-and-cache-boundaries), or
+   document the implemented exception and its evidence there;
 5. register it through its package-family registrar and add a default chain
    there only when production policy requires one;
 6. add resolution and composition coverage for capabilities, options,