Cleanup and complete the validator refactor

docs/internal/pipeline.md

@@ -162,8 +162,8 @@ chunk metadata. Extractors and downstream stages therefore see canonical source
 units, while `SourceChunk.Metadata` remains the supported place for
 chunker-owned context.
 
-If chunk validation rejects a chunk after configured retries, the runner records
-a rejected raw output and skips downstream lane execution. Framework-level
+If chunk validation rejects the chunk result after configured retries, the runner
+records a rejected raw output and skips downstream lane execution. Framework-level
 chunking or validation errors that remain after configured retries fail the run.
 
 The framework does not require complete source-unit coverage and does not reject

docs/roadmap/future.md

@@ -22,6 +22,16 @@ future work only.
 - Cross-chunk semantic deduplication.
 - Additional validator packages and production default chains for future
   modules.
+- Production LLM-backed validators when there is a concrete review policy that
+  benefits from model judgment.
+- Validator diagnostics and timing summaries if operators need more detail than
+  `manifest.json`, `rejected.json`, and `warnings.json` provide.
+- Media-type validators for non-JSON module outputs when such modules are
+  introduced.
+- Validator compatibility metadata if real deployments need config-time
+  enforcement that a validator is suitable for a specific stage or module.
+- Batching or context-window controls for LLM-backed validators if validator
+  inputs become large enough to require them.
 - Parallel execution where it preserves deterministic manifests and diagnostics.
 - Additional output encoders.
 

docs/roadmap/implementation.md

@@ -1,16 +0,0 @@
-# Validation Refactor Implementation
-
-The validation refactor described by this temporary implementation plan has
-been completed.
-
-Current behavior is documented in:
-
-- [Configuration](../config.md)
-- [CLI Reference](../cli.md)
-- [Pipeline Internals](../internal/pipeline.md)
-- [Modules](../internal/modules.md)
-- [JSON Output](../integrations/json-output.md)
-- [Troubleshooting](../troubleshooting.md)
-
-Remaining future validation ideas, if any, belong in
-[Validation Roadmap](validation.md).

docs/roadmap/validation.md

@@ -1,31 +0,0 @@
-# Validation Roadmap
-
-The first-class raw-output validation system is implemented. Current behavior is
-documented outside roadmap files, especially in [Configuration](../config.md),
-[CLI Reference](../cli.md), [Pipeline Internals](../internal/pipeline.md), and
-[JSON Output](../integrations/json-output.md).
-
-Implemented behavior includes:
-
-- a single raw module-output validator contract for chunk, extract, merge, and
-  normalize outputs;
-- validator specs with deterministic and LLM-backed execution classes;
-- central production validator registration and default chain mappings;
-- stage-local config overrides that distinguish omitted, explicit empty, and
-  explicit non-empty validator chains;
-- manifest provenance for resolved validator chains;
-- generic JSON validators and D&D spell validators under `internal/validators`;
-- production defaults for the `dnd/spells` extractor.
-
-## Future Work
-
-- Add production LLM-backed validators when there is a concrete review policy
-  that benefits from model judgment.
-- Add validator diagnostics and timing summaries if operators need more detail
-  than `manifest.json`, `rejected.json`, and `warnings.json` provide.
-- Add media-type validators for non-JSON module outputs when such modules are
-  introduced.
-- Add compatibility metadata only if real deployments need config-time
-  enforcement that a validator is suitable for a specific stage or module.
-- Add batching or context-window controls for LLM-backed validators if validator
-  inputs become large enough to require them.