Run D&D spell lanes through typed artifacts

docs/internal/modules.md

@@ -20,11 +20,11 @@ validator chains and prompt asset collection.
 Production input, chunk, output, and D&D spell-extract packages register strict
 option decoders and run-local builders. Preparation decodes their options into
 implementation-owned values and injects dependencies. The spell extractor is
-typed over the canonical D&D model; a temporary raw adapter preserves the
-current runner path. D&D validators, merge, and normalize use typed variants;
-JSON representation validators use serialized requests; and unconditional
-validators expose separate chunk and typed variants. Narrow legacy
-registrations preserve current raw execution until the runner migrates.
+typed over the canonical D&D model. D&D validators, merge, and normalize use
+typed variants; JSON representation validators use serialized requests; and
+unconditional validators expose separate chunk and typed variants. The D&D
+production registrar does not register raw spell-stage implementations in
+parallel.
 
 Specs expose capability and execution metadata without constructing an
 implementation. Registry entries separately expose option validation and
@@ -111,10 +111,10 @@ The extractor owns its private model-response DTO, embedded prompt, LLM response
 schema, strict option decoder, injected shared LLM client, and prompt/schema
 manifest metadata. The separate `internal/modules/dnd/codec/spells` package
 owns the durable schema and stable JSON representation for artifact kind
-`dnd/spell-list`. Production composition currently wraps the typed extractor
-with a raw adapter that encodes through this codec, so existing validators and
-later stages remain unchanged. Shared D&D helpers keep prompt input names and
-source-unit reference conversion consistent with the scene chunker.
+`dnd/spell-list`. The runner keeps the result typed through validators and later
+stages. Explicit migration-only codec adapters preserve the existing raw
+checkpoint, debug, and output envelopes. Shared D&D helpers keep prompt input
+names and source-unit reference conversion consistent with the scene chunker.
 
 The durable payload and manifest metadata shapes are defined in the
 [D&D spell artifact contract](../integrations/dnd-spell-artifacts.md).

docs/internal/overview.md

@@ -62,13 +62,13 @@ run-local construction closures. Preparation injects shared dependencies and
 constructs input, chunk, validators, ordered lanes, and output before source
 parsing. Production input, chunk, and output modules use strict construction-time
 option decoding, and the LLM-backed scene chunker retains the injected shared
-client. The D&D family registers the canonical `dnd/spell-list` codec and a
-typed spell extractor. A temporary raw adapter serializes that typed result for
-the current runner. The D&D family also registers typed spell validators and
-kind-specific generic merge and normalize strategies; generic JSON validators
-use the serialized-validation contract. Narrow legacy registrations preserve
-the existing raw runner path until typed execution lands. The current runner
-rejects a typed prepared lane instead of routing it through raw execution.
+client. The D&D family registers the canonical `dnd/spell-list` codec, typed
+spell extractor and validators, and kind-specific generic merge and normalize
+strategies; generic JSON validators use the serialized-validation contract. The
+runner executes the production D&D lane through private exact-type-checked
+closures and uses migration-only codec adapters for the existing raw
+checkpoint, debug, and output envelopes. Legacy raw lanes retain their separate
+executor while they migrate.
 
 ## Production Extensions
 

docs/internal/pipeline.md

@@ -73,13 +73,10 @@ separate target namespaces; serialized registrations declare whether they
 support chunks, artifacts, or both. Duplicate variants and exact Go-type
 mismatches are rejected deterministically.
 
-Production composition registers the D&D spell-list codec. The typed spell
-extractor also registers a temporary raw adapter, which resolution selects
-until runner execution is typed. The D&D family registers matching typed merge,
-normalize, and semantic-validator variants, while JSON validators register for
-serialized chunk and artifact targets. Narrow legacy registrations preserve the
-current raw runner path. A standalone raw registration cannot satisfy a typed
-lane.
+Production composition registers the D&D spell-list codec and typed extractor,
+matching typed merge, normalize, and semantic-validator variants, and
+serialized JSON validators. The production D&D lane has no parallel raw stage
+registration. A standalone raw registration cannot satisfy a typed lane.
 
 A `ModuleSpec` declares its stage plus required and provided capabilities.
 Chunk, extract, merge, and normalize specs may also declare reference slots.
@@ -119,10 +116,10 @@ an LLM client; an LLM-backed chunker receives the shared client during
 preparation. Their operation requests retain run-specific source, reference,
 profile, session, and metadata context as applicable.
 
-Typed lanes can be composed, resolved, and prepared but are not executed by the
-current raw runner. The runner rejects such input before source work;
-production lanes are still resolved and executed exclusively through the
-legacy raw path.
+Prepared typed lanes retain exact-type-checked erased operation closures. The
+runner uses those closures to keep each value typed through extraction,
+validation, merge, and normalization. Legacy raw lanes continue through their
+existing executor while they migrate independently.
 
 Source validation requires every unit to carry a canonical self-reference to
 its containing document and its own unit ID. Explicit clone, checkpoint, and
@@ -153,7 +150,7 @@ and validators while performing these transitions:
 
 1. extract once per accepted chunk and add runner-owned lane, source, and chunk
    provenance;
-2. validate each raw extract result and omit rejected results from merge input;
+2. validate each extract result and omit rejected results from merge input;
 3. skip the rest of the lane when no extract result is accepted;
 4. merge accepted extract results in their existing order;
 5. validate the merge result and skip normalization on rejection;
@@ -180,10 +177,11 @@ chunks; stricter coverage policy belongs to the chunk implementation.
 ## Validation And Retries
 
 Chunk, extract, merge, and normalize results pass through the resolved validator
-chain for their stage and module. Each validator receives the raw payload plus
-the relevant source, chunk, prior-stage, schema, reference, session, LLM, option,
-and run context. Validators execute in resolved order and stop at the first
-error or rejection. An empty chain approves the result.
+chain for their stage and module. Chunk validators receive canonical chunks;
+typed validators receive the domain value; and serialized validators receive
+canonical chunk JSON or artifact codec bytes. Validators execute in resolved
+order and stop at the first error or rejection. An empty chain approves the
+result.
 
 `runWithRetry` applies the effective retry policy around module execution and
 its complete validation chain. A module or validator error becomes a framework
@@ -201,8 +199,10 @@ The runner depends on recorder and loader interfaces, using no-op
 implementations when collaborators are absent. Each checkpointed workflow
 boundary records a running, succeeded, or failed transition. Reuse decisions
 are consulted in workflow order and accepted payloads are cloned before
-entering the normal handoff path. Dependency fingerprints connect later
-checkpoints to the exact accepted results on which they depend.
+entering the normal handoff path. The typed D&D executor uses explicit
+migration-only codec adapters to read and write the existing raw artifact
+checkpoint envelopes. Dependency fingerprints connect later checkpoints to the
+exact accepted results on which they depend.
 
 Debug instrumentation wraps run, stage, attempt, validator, and structured LLM
 boundaries. Context scopes associate nested LLM calls with the module or