Remove legacy raw pipeline contracts

docs/internal/llm.md

@@ -39,9 +39,9 @@ without exposing Scriptorium types through stage contracts.
 7. injecting that one shared client into complete pipeline preparation before
    the source file is read or the runner is invoked.
 
-The D&D scene chunker retains this injected client and uses it for every scene
-completion. Later legacy LLM-backed operations still receive the same shared
-client through their operation requests.
+The D&D scene chunker and spell extractor retain this injected client and use
+it for every structured completion. Operation requests do not carry an LLM
+client.
 
 The CLI separately gathers explicit profile IDs from resolved LLM-capable stage
 and validator bindings. It prepares a small internal check prompt for each ID so

docs/internal/modules.md

@@ -112,8 +112,8 @@ 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`. 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
+stages, using the codec only for checkpoint, debug, and output boundaries.
+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
@@ -123,16 +123,14 @@ The durable payload and manifest metadata shapes are defined in the
 
 ### `internal/modules/generic/merge/appendorder`
 
-The typed merger passes values to an injected combine function in framework
+The merger passes typed values to an injected combine function in framework
 source-chunk order. The D&D registrar specializes it with a spell-list append
-function. Its temporary raw implementation retains the prior JSON merge
-behavior for the current runner.
+function.
 
 ### `internal/modules/generic/normalize/noop`
 
-The typed normalizer returns the merged domain value unchanged and is reusable
-for any registered artifact type. Its temporary raw implementation defensively
-clones the accepted payload for the current runner.
+The normalizer returns the merged domain value unchanged and is reusable for
+any registered artifact type.
 
 ## Output Encoder
 

docs/internal/overview.md

@@ -47,8 +47,8 @@ validator set before the runner receives source bytes.
 | `internal/framework/checkpoint` | Workspace-backed checkpoint loading, recording, and payload serialization. |
 | `internal/framework/debug` | Workspace-backed framework and LLM debug recording. |
 
-Framework contracts provide both the production raw stage interfaces and typed
-artifact, provenance-wrapper, chunk-validator, serialized-validator, and
+Framework contracts provide typed artifact, provenance-wrapper, chunk-validator,
+serialized-validator, and
 typed-validator interfaces. The runner owns handoff provenance, validation
 sequencing, rejection handling, checkpoint and debug boundaries, and final
 manifest assembly.
@@ -60,15 +60,13 @@ type equality across the lane, and records schema identity in the resolved lane
 and pipeline digest. Registry entries carry separate option-validation and
 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, 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.
+parsing. Production modules use strict construction-time option decoding, and
+LLM-backed modules retain the injected shared 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 lanes through
+private exact-type-checked closures and serializes artifacts only through their
+codec at checkpoint, debug, and output boundaries.
 
 ## Production Extensions
 

docs/internal/pipeline.md

@@ -75,20 +75,18 @@ mismatches are rejected deterministically.
 
 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.
+serialized JSON validators. Every artifact lane resolves through the typed
+registries and a matching codec.
 
 A `ModuleSpec` declares its stage plus required and provided capabilities.
 Chunk, extract, merge, and normalize specs may also declare reference slots.
 Registry implementations defensively copy spec metadata, reject duplicate keys,
 and verify that a constructed implementation reports the registered key.
-Builder registrations accept `ModuleDependencies` and cloned raw options through
-one `BuildRequest`. Production input, chunk, and output builders decode those
-options and retain typed values or injected dependencies in the constructed
-implementation. A typed extractor registration may explicitly supply a raw
-adapter builder for a still-raw downstream lane; the adapter is selected as one
-unit and does not expose the typed value to raw consumers. Remaining production
-raw-stage registrations are adapted from their zero-argument constructors.
+Builder registrations accept `ModuleDependencies` and cloned configuration
+options through one `BuildRequest`. Builders decode those options and retain
+typed values or injected dependencies in the constructed implementation.
+Extractors declare their artifact kind, and merger, normalizer, and validator
+resolution selects the matching typed variant.
 
 A `ValidatorSpec` declares a validator key and execution class. Resolution uses
 the execution class to reject incompatible profile bindings before execution.
@@ -116,10 +114,9 @@ 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.
 
-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.
+Prepared lanes retain exact-type-checked erased operation closures. The runner
+uses those closures to keep each value typed through extraction, validation,
+merge, and normalization.
 
 Source validation requires every unit to carry a canonical self-reference to
 its containing document and its own unit ID. Explicit clone, checkpoint, and
@@ -225,7 +222,7 @@ and recorder implementation are inventoried in
 The runner owns manifest assembly and handoff summaries but not the durable JSON
 schema. It records resolved module and lane provenance, validator chains,
 source/reference identities, selected LLM profiles, normalized and rejected
-summaries, status, and timing. Raw payload bytes remain outside the manifest.
+summaries, status, and timing. Serialized artifact content remains outside the manifest.
 Module metadata providers may add non-secret singleton or lane-scoped metadata.
 
 Execution errors include stage, module, lane, or validator context. Once a