Strengthen validation retries and checkpoint safety

docs/internal/dnd.md

@@ -134,6 +134,13 @@ relatedness validators report advisory evidence concerns. The configured order
 is documented in
 [Configuration](../config.md#production-validator-keys-and-default-chains).
 
+Every D&D rejection describes the correction in transcript-grounded domain
+terms, using contextual names, artifact fields, and source segment ranges when
+useful. The guidance must not ask the model to reproduce durable entity IDs,
+hashes, validator module keys, or reason codes. Those identifiers remain in
+ordinary validation provenance; only the actionable semantic guidance is
+eligible for the correction prompt.
+
 Enemy-event extraction additionally rejects a second `engaged` observation for
 the same comparison identity within one scene-scoped result. Normalization may
 combine results from distinct scenes, so it intentionally does not apply that

docs/internal/modules.md

@@ -45,6 +45,15 @@ they need, register each leaf implementation, and add any family-owned assets
 or default validator chains. They return contextual errors so production
 composition fails at startup rather than at the first run.
 
+A validator that returns a completed rejection must supply two separate
+bounded values: a stable `ReasonCode` for provenance and actionable
+`CorrectionGuidance` for the producer. Guidance identifies the semantic defect
+and the constraints on one complete corrected replacement. It must not contain
+validator keys, diagnostic paths, opaque application IDs, or other internal
+identifiers. An operator-facing `Message` may explain the same event, but the
+framework never copies it into a model request. Missing or invalid guidance is
+a validator contract failure.
+
 An artifact family can register an optional typed evidence projector alongside
 its codec. The projector returns defensive copies of the artifact's direct
 generic source references and must use the codec's exact Go type. It does not
@@ -131,6 +140,8 @@ its domain prompt.
 4. Register the module through its typed registry helper and add it to the
    owning family registrar. Add a default validator chain only when that
    family owns the behavior; otherwise require an explicit compatible chain.
+   Every rejection path in a validator must provide actionable correction
+   guidance while retaining its stable internal reason code.
 5. Update the selectable-key and chain reference in
    [Configuration](../config.md#production-module-keys), the applicable
    integration contract, and focused tests. Keep the configuration document

docs/internal/pipeline.md

@@ -143,7 +143,11 @@ immutable candidate; it does not regenerate the producer or alter the
 validator request. Rejections stop that validator, while other configured
 validators still run. The executor retains ordered results, bounded
 deduplicated correction guidance from rejections, and only the final exhausted
-failure outcome for each validator.
+failure outcome for each validator. The correction builder keeps first
+occurrence order, omits internal reason codes, validator names, and operator
+messages, and requests one complete replacement. Missing guidance or an
+oversized aggregate is a framework contract error; guidance is never inferred
+or truncated.
 
 The runner applies the binding's retry policy around a stage operation and its
 complete validation chain. It preserves warnings only from the final accepted
@@ -163,12 +167,14 @@ settles the semantic policy immediately. Structural-output errors alone use the
 structural policy, and validation failure without rejection settles the
 validator-failure policy without regenerating the producer.
 
-Chunk planning uses this state machine for generated plans. A rejected
-automatic cache hit is not model material and therefore falls through to a
-fresh initial generation; it neither receives a correction nor overwrites the
-stored record. Only a newly generated, completely validated plan is published
-to the chunk-plan store. Rejected plans never advance, and validation-incomplete
-plans remain unpublishable.
+Chunk planning uses this state machine for generated plans. A rejected or
+validation-incomplete automatic cache hit is not model material and therefore
+falls through to a fresh initial generation at producer attempt one; it neither
+receives a correction, consumes retry budget, promotes cached-candidate
+warnings, nor overwrites the stored record. An incomplete cache validation
+under `fail_run` terminates instead. Only a newly generated, completely
+validated plan is published to the chunk-plan store. Rejected plans never
+advance, and validation-incomplete plans remain unpublishable.
 
 After terminal lane work, the runner assembles manifest provenance, normalized
 artifacts, rejections, warnings, and an optional accepted chunk map. When an
@@ -204,7 +210,12 @@ The runner writes successful checkpoint artifacts only after complete accepted
 validation. Chunk plans follow the same rule for publication. A rejection,
 invalid structured response, or incomplete validation is never reusable state;
 the current run may still hand off an otherwise valid `warn_continue` result
-according to its terminal policy. Attempt debug records retain safe kind,
+according to its terminal policy. The runner carries private reuse eligibility
+through extract, merge, normalize, and generated-reference handoff. Any stage
+derived from incomplete validation skips both checkpoint lookup and all
+checkpoint publication even when that stage's own validation completes.
+External references and fully validated generated references remain eligible.
+Attempt debug records retain safe kind,
 validator, repair-usage, policy, and terminal-decision provenance. Full
 assistant and correction content remains confined to the requested detailed
 LLM trace.