Construct universal modules with decoded options

docs/config.md

@@ -236,6 +236,10 @@ Binding fields:
   chain; set a non-empty list to use exactly those validators in configured
   order.
 
+During resolution, each selected module's registered option validator runs.
+Production input, chunk, and output bindings reject unknown or invalid options
+with the affected binding context.
+
 Validator bindings use the same shorthand or object module-binding form, but
 only these fields are supported:
 

docs/internal/llm.md

@@ -33,10 +33,16 @@ without exposing Scriptorium types through stage contracts.
 2. creating a `ScriptoriumClient` from the effective profile source;
 3. attaching an `LLMProfileRecorder`;
 4. creating a scheduler from the effective concurrency limit;
-5. returning a `ScheduledClient` wrapper; and
-6. injecting that one shared client into complete pipeline preparation before
+5. returning a `ScheduledClient` wrapper;
+6. decorating that shared client before preparation when debug recording is
+   enabled; and
+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 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
 missing or invalid profiles fail before pipeline execution. The runtime profile

docs/internal/modules.md

@@ -17,13 +17,15 @@ validator registry. Package-family registrars compose those leaf registrations
 into the production catalog and own family-level policy such as default
 validator chains and prompt asset collection.
 
-Production extract, merge, normalize, and validator packages currently use the
-explicit legacy raw registration APIs. Typed registration is framework-ready,
-but no production artifact kind or codec is registered yet. All selected
-production implementations are constructed during pipeline preparation through
-temporary adapters around their existing zero-argument constructors. Their raw
-option maps and LLM clients remain operation inputs until each implementation
-migrates to its construction-owned decoder and injected dependencies.
+Production input, chunk, and output packages register strict option decoders and
+run-local builders. Preparation decodes their options into implementation-owned
+values and injects dependencies; their operation requests contain run context,
+not raw option maps or LLM clients. Production extract, merge, normalize, and
+validator packages still use the explicit legacy raw registration APIs and
+temporary adapters around zero-argument constructors. Their raw option maps and
+LLM clients remain operation inputs while that part of the catalog migrates.
+Typed registration is framework-ready, but no production artifact kind or
+codec is registered yet.
 
 Specs expose capability and execution metadata without constructing an
 implementation. Registry entries separately expose option validation and
@@ -51,8 +53,8 @@ evidence. The resolver and materializer behavior is described in
 The adapter decodes the supported transcript JSON, selects the source identity,
 computes canonical source provenance, validates segments, and maps each segment
 into a generic source unit with a self-reference plus speaker and timestamp
-metadata. Its spec advertises the transcript capabilities consumed by D&D
-modules.
+metadata. It accepts no module options. Its spec advertises the transcript
+capabilities consumed by D&D modules.
 
 Parsing is strict about required values and duplicate unit IDs but deliberately
 ignores unrelated Seriatim fields. The external format and derived-identity
@@ -72,6 +74,8 @@ canonical source reference from those unit references.
 The accepted options and defaults are defined in
 [Configuration](../config.md#implemented-production-modules). Generic
 framework validation canonicalizes the returned unit slices before extraction.
+The chunker decodes its options during construction and retains only the typed
+window settings used by `Chunk`.
 
 ### `internal/modules/dnd/chunk/scenes`
 
@@ -79,6 +83,9 @@ The scene chunker prepares a structured Scriptorium request from the full
 transcript, session, and optional D&D reference inputs. It validates the model's
 scene boundaries against source-unit IDs and converts them into deterministic
 chunks with canonical source references spanning each scene's units.
+Preparation injects the shared structured LLM client into the chunker; `Chunk`
+supplies only the run-specific profile, session, source, references, and
+metadata.
 
 Scene validation requires sequential, contiguous, non-overlapping coverage from
 the first source unit through the last. Each chunk contains JSON scene content

docs/internal/overview.md

@@ -60,10 +60,12 @@ 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 module families do not register typed variants yet and
-continue through explicitly named legacy raw registrations and temporary
-zero-argument constructor adapters. The current runner rejects a typed prepared
-lane instead of routing it through raw execution.
+parsing. Production input, chunk, and output modules use strict construction-time
+option decoding, and the LLM-backed scene chunker retains the injected shared
+client. Production artifact-lane modules and validators do not register typed
+variants yet and continue through explicitly named legacy raw registrations and
+temporary zero-argument constructor adapters. The current runner rejects a
+typed prepared lane instead of routing it through raw execution.
 
 ## Production Extensions
 

docs/internal/pipeline.md

@@ -74,17 +74,18 @@ support chunks, artifacts, or both. Duplicate variants and exact Go-type
 mismatches are rejected deterministically.
 
 Production composition initializes the artifact codec registry without adding
-codec entries, and production modules use the explicitly named legacy raw
-registration APIs. A raw registration cannot satisfy a typed lane.
+codec entries, and production artifact-lane modules use the explicitly named
+legacy raw registration APIs. A 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.
 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`. Existing production registrations are adapted from their
-zero-argument constructors while their implementation-owned option decoders are
-migrated separately.
+one `BuildRequest`. Production input, chunk, and output builders decode those
+options and retain typed values or injected dependencies in the constructed
+implementation. Remaining production raw-stage registrations are adapted from
+their zero-argument constructors during migration.
 
 A `ValidatorSpec` declares a validator key and execution class. Resolution uses
 the execution class to reject incompatible profile bindings before execution.
@@ -106,7 +107,11 @@ session and profile metadata, and checkpoint/debug collaborators. The runner
 parses source bytes through the already constructed input adapter. Later stage
 requests receive the generic source model; extract requests receive
 chunk-scoped input material, while chunk, merge, and normalize requests retain
-access to the original source material.
+access to the original source material. Input, chunk, and output operation
+requests do not carry raw module options. The chunk request also does not carry
+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;